AWS 怎麼看向量資料庫
AWS 這篇在講向量資料庫怎麼存 embeddings、怎麼做相似度搜尋，以及為什麼 Bedrock 常搭配 OpenSearch Service。
AWS 說向量資料庫會存 embeddings，讓應用程式快速找出語意相近的資料。
說真的，這東西現在很實用。向量搜尋已經不是實驗室玩具，而是 AI 應用的基本零件。
AWS 把重點講得很直白。它把向量當成高維資料點，再用最近鄰搜尋找出意思相近的內容，不是只看字面是否一樣。
這件事會影響搜尋、推薦、聊天機器人。只要你的資料有文字、圖片、音訊，向量資料庫就很可能派得上用場。
| 主題 | AWS 說法 |
|---|---|
| 資料模型 | 向量存成高維資料點 |
| 索引方法 | k-NN、HNSW、IVF |
| Bedrock 建議 | Amazon OpenSearch Service |
| MemoryDB 數字 | 數百萬向量、毫秒級回應、每秒數萬次查詢、回收率超過 99% |
向量資料庫到底在做什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
向量資料庫存的是 embeddings。這些數字向量來自模型輸出，代表內容的語意和上下文。
講白了，它不是拿字串比對字串。它是拿向量空間裡的距離，去判斷兩筆資料像不像。
AWS 文章把核心工作講得很簡單。存向量、找向量、快速找最近鄰。
但真正上線時，事情沒那麼單純。資料庫還要處理索引、查詢規劃、權限、容錯和資料管理。
這也是為什麼大家不直接拿原始 k-NN 硬幹。演算法只是起點，真正能跑 production 的，是整套資料庫能力。
- 向量可以代表文字、圖片、音訊、掃描文件。
- 相似度搜尋可用在圖片查找和語意搜尋。
- 資料庫會補上索引、權限、容錯。
- 這些功能比單純的數學搜尋更像正式基礎設施。
AWS 為什麼一直提向量資料庫
AWS 的立場很務實。embedding 有用，前提是開發者能把它用進系統裡。
所以向量資料庫的價值，不是「能不能算距離」。而是能不能把 embeddings 建索引、查詢，還能跟 metadata 一起做 hybrid search。
這裡才是重點。你可以同時看語意和關鍵字，再用向量相似度和 BM25 一起排序。
對很多產品來說，這種做法比純語意搜尋更穩。結果比較像人類真的會接受的答案。
向量資料庫也跟生成式 AI 的幻覺問題有關。外部知識庫可以幫聊天機器人找資料，降低亂答機率。
"OpenSearch Service offers a scalable and high-performance vector database enabling vector-driven search capabilities." — Amazon Web Services
這句話很直接。AWS 沒把向量搜尋當附加功能，而是把 OpenSearch 放到 Amazon Bedrock 的檢索路線上。
對開發者來說，意思很清楚。你要做 RAG，AWS 想先讓你想到 OpenSearch Service。
- 向量搜尋可搭配 metadata 篩選。
- Hybrid search 比單一語意搜尋更穩。
- RAG 系統常需要外部知識庫。
- AWS 把 OpenSearch 放在 Bedrock 路線上。
不同 AWS 服務怎麼卡位
AWS 給了好幾條路。這很像它一貫的作風，工具很多，選項也很多。
Amazon OpenSearch Service 是 Bedrock 的推薦選項。這代表它最像通用型搜尋底座。
如果你已經在用 PostgreSQL，那 Amazon RDS for PostgreSQL 和 Amazon Aurora PostgreSQL-Compatible Edition 的 pgvector 會很順手。
如果你要的是低延遲，Amazon MemoryDB 和 Amazon DocumentDB 也都能做向量搜尋。
這種切法很實際。AWS 不是只推一種資料庫，而是看你的資料本來放哪裡。
| 服務 | 適合情境 | AWS 提到的特徵 |
|---|---|---|
| OpenSearch Service | Bedrock 檢索、通用搜尋 | 可做向量驅動搜尋 |
| PostgreSQL / Aurora PostgreSQL | SQL 資料旁邊放 embeddings | 支援 pgvector |
| MemoryDB | 低延遲、高 QPS | 數百萬向量、毫秒級回應、每秒數萬次查詢 |
| DocumentDB | 文件型工作負載 | 毫秒級延遲的向量搜尋 |
- OpenSearch Service：適合 Bedrock 檢索。
- PostgreSQL / Aurora：適合 SQL 與 embeddings 並存。
- MemoryDB：適合低延遲、高 QPS。
- DocumentDB：適合文件型工作負載。
數字怎麼看，差異在哪裡
這篇文章最有用的地方，是它把不同路線的數字放在一起。
OpenSearch Service 偏通用。MemoryDB 偏快。DocumentDB 偏文件型。pgvector 則偏工程實用。
你可以把它想成四種取捨。不是誰比較厲害，而是誰比較貼近你的系統。
如果資料已經在 PostgreSQL，硬搬到別的引擎，常常只是多一層麻煩。
如果你要的是即時查詢和更新，MemoryDB 的方向就更像你要的東西。
- OpenSearch Service：AWS 對 Bedrock 的預設建議。
- MemoryDB：數百萬向量、單位是毫秒、QPS 可到數萬。
- DocumentDB：向量搜尋加上文件資料模型。
- pgvector：最像「把 embeddings 放進既有 SQL 系統」。
這裡的關鍵不是功能名詞，而是維運成本。你多開一套系統，就多一份同步、備份、監控和權限管理。
很多團隊最後會選最接近原本資料流的方案。這很無聊，但通常最少踩雷。
產業脈絡：為什麼大家都在做
向量資料庫的熱度，跟生成式 AI 一起起來。原因很簡單，LLM 需要外部資料，不能只靠模型記憶。
你要做企業知識庫、客服助理、產品搜尋，最後都會碰到同一題：怎麼把資料找回來。
這就是向量資料庫的角色。它把非結構化資料變成可查詢的資料層。
在這之前，很多團隊只能靠關鍵字搜尋。那種做法對精準詞很有效，但對語意理解很弱。
現在的做法比較像混搭。先用 embedding 找候選，再用關鍵字、權限、時間戳去縮小範圍。
這也解釋了為什麼 AWS、Google、Microsoft 都在推相關功能。大家都知道，AI 應用最後還是要回到資料層。
你可以把 Amazon S3、Aurora、MemoryDB 想成不同的資料落點。向量資料庫只是把檢索能力接上去。
結論：開發者該怎麼選
如果你已經在 AWS 上，先看資料在哪裡，再決定要不要上 OpenSearch Service。這通常比先追新名詞更實際。
我覺得最務實的做法是這樣。SQL 資料留在 PostgreSQL，低延遲查詢放 MemoryDB，Bedrock 檢索先看 OpenSearch Service。
接下來一兩年，向量搜尋大概會變成 AI 應用的標配。問題只剩下，你要把它放在哪一層。
如果你現在正在做 RAG，我會先問一件事：你的 embeddings 是不是已經離資料太遠了？