AWS 把向量搜尋塞進資料庫
AWS 將向量搜尋原生放進 Aurora PostgreSQL、MemoryDB、Bedrock Knowledge Bases 和 Neptune，讓 RAG、GraphRAG 更容易直接在 AWS 資料庫堆疊上做。
AWS 把向量搜尋原生放進多個資料庫服務，讓 RAG 和 GraphRAG 可以直接在 AWS 堆疊上做。
AWS 這次不是只加一個小功能。它是把向量能力往資料庫底層塞。對開發者來說，這很實際。你可能不用再多養一套向量資料庫。
它點名 Amazon Aurora PostgreSQL、Amazon MemoryDB、Amazon Bedrock Knowledge Bases，還有 Amazon Neptune。這不是單點更新。這是整條產品線一起動。
| 面向 | AWS 服務 | 官方說法 |
|---|---|---|
| 關聯式向量 | Amazon Aurora PostgreSQL | 適合關聯式工作負載 |
| 非關聯式向量 | Amazon MemoryDB | 在 AWS 常見向量資料庫中，主打最快搜尋與最高 recall |
| RAG 編排 | Amazon Bedrock Knowledge Bases | 負責資料匯入與執行期編排 |
| GraphRAG | Amazon Neptune | 用圖資料做關係推理與可解釋檢索 |
AWS 為什麼把向量放進資料庫
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
講白了，向量已經不是研究玩具。它是 RAG、語意搜尋、Agent 檢索的基本零件。只要你在做 LLM 應用，幾乎躲不掉。
向量的意思也不難懂。它就是把內容變成數字座標。兩筆資料越接近，語意通常越像。這讓系統可以找「意思相近」的內容，不只看關鍵字。
AWS 的策略很明顯。它想把向量變成資料庫原生功能。不是叫你再買一套專用向量庫，而是先看你手上的資料庫能不能直接上。
- 向量能表示語意，適合做語意搜尋。
- 把 embeddings 跟業務資料放一起，管理會簡單很多。
- 少一套服務，就少一堆同步、權限、監控問題。
- AWS 想讓向量搜尋像 SQL 一樣自然。
AWS 這次主打哪些工作負載
對關聯式工作負載，AWS 先推 Aurora PostgreSQL。這很合理。很多團隊本來就靠 PostgreSQL 吃飯。交易、Join、索引、延伸套件，這些都還是主戰場。
如果你的系統偏非關聯式，AWS 則推 MemoryDB。它主打低延遲和高 recall。官方頁面沒有把完整 benchmark 數字攤開，所以你最好把它當成方向性訊號，不要直接拿來跟別家硬比。
我覺得這裡最有意思的地方，是 AWS 沒把向量搜尋綁死在單一產品。它是在說：不同資料模型，用不同資料庫。這比「什麼都丟同一個向量庫」務實多了。
“AWS has incorporated native support for vectors across a broad set of our databases.”
這句話很直白。AWS 想傳達的是，向量不是附加功能。它是資料庫層的標配方向。對要上 production 的團隊來說，這種定位比 demo 話術有用多了。
如果你已經在 AWS 上跑服務，這會直接影響架構選擇。你可能先問：現有資料庫能不能處理 embeddings？能的話，就別急著再加一層。
RAG 才是 AWS 真正在賣的東西
AWS 這次一直講 RAG，原因很簡單。RAG 已經不是概念展示。它是很多企業 AI 服務的標配做法。模型負責生成，資料庫負責找上下文。
Amazon Bedrock Knowledge Bases 是 AWS 的管理式 RAG 層。它負責資料匯入，也負責執行期編排。AWS 還說 Aurora 有 1-click 整合，意思就是少寫一堆 glue code。
這很重要。RAG 專案常常不是死在模型，而是死在管線。切 chunk、建索引、更新資料、權限控管、檢索調校，這些才是最煩的地方。有人幫你包起來，工程成本就會降。
- Bedrock Knowledge Bases 負責資料匯入。
- 它也負責 runtime orchestration。
- Aurora 有 1-click 整合。
- 目標是把內部資料接到 foundation model。
GraphRAG 讓檢索更有結構
AWS 也把 GraphRAG 拉進來。這套做法會先建立知識圖，再用圖的關係去幫檢索。這樣一來，系統不只看相似度，也能看關聯。
這裡的核心差別很清楚。向量擅長找意思相近的內容。圖資料擅長表示擁有關係、階層、依賴。像產品文件、組織架構、零件關聯，這些就很適合用圖。
AWS 說 Neptune 可以跟 Bedrock Knowledge Bases 一起做圖生成與 traversal。它也提到 Amazon S3 可以餵資料進來。這表示文件、票單、產品目錄，都有機會直接進圖檢索流程。
- 向量搜尋適合找語意相近內容。
- 圖檢索適合找關係與路徑。
- GraphRAG 把兩者合在一起。
- 當你要解釋答案來源時，圖很有用。
跟其他做法比，差在哪裡
如果拿 AWS 的做法跟專用向量庫比，差別不只在效能。差別還在維運。專用向量庫像 Pinecone、Weaviate、Qdrant，強項是檢索體驗和調校彈性。
但 AWS 的路線是把向量塞回既有資料層。這對已經用 Aurora 或 MemoryDB 的團隊很省事。少一個系統，就少一個故障面。這句話很土，但是真的。
不過，專用向量庫還是有它的價值。當你的檢索量很大、資料更新很快、召回和延遲要精細調校時，專用方案通常還是比較好控。AWS 的原生整合比較像「夠用而且好接」。
- 專用向量庫強在檢索控制與調校。
- AWS 原生整合強在部署簡單。
- 對既有 AWS 用戶，遷移成本較低。
- 對複雜搜尋系統，專用方案仍有空間。
這波更新反映了什麼產業脈絡
這件事其實很像雲端平台一貫的套路。先把新能力標準化，再塞進既有服務。以前是物件儲存、容器、Serverless。現在輪到向量搜尋。
原因也不難懂。企業想要的是少維運，不是多一個名詞。只要資料庫能直接處理 embeddings，很多 AI 應用就可以少掉一層基礎設施。
這也反映出 LLM 應用的成熟方向。大家不再只問模型多大。大家開始問資料怎麼接、權限怎麼管、檢索怎麼做、答案怎麼追溯。這些問題，最後都會回到資料庫和中介層。
對台灣開發者來說，這很有感。很多團隊本來就用 AWS。現在如果要做內部知識庫、客服助理、文件搜尋，先看 Aurora、MemoryDB、Bedrock，通常比先找一套新工具更快。
接下來你該怎麼看
如果你正在規劃 RAG 系統，我會先問三件事。你的資料現在在哪裡。你的延遲要求多少。你要的是語意搜尋，還是還要圖關係。
我的判斷很直接。小型到中型 production app，會很快吃下這種原生向量功能。大型團隊還是會留一部分專用搜尋架構，因為他們要的不是「能用」，而是「可控」。
所以接下來最實際的動作，不是追新名詞。是去看你現有 AWS 資料庫，能不能先把 embeddings 放進去。能少一套就少一套。這才是省錢又省事的做法。