Oracle：AI 不必再加一個資料庫

InfoWorld 認為，多數 AI 應用應直接在既有資料庫做向量檢索，而不是再建一套向量庫。

2026 年 5 月 11 日，InfoWorld 文章點名企業 AI 的老問題：向量資料庫的必要性正在下降。作者 Matt Asay 的核心主張很直接，既有主流資料庫已經補上向量型別、索引與檢索能力，團隊應優先把 embedding 放進現有系統。

這篇快訊的重點不是「向量檢索還重不重要」，而是「它要放在哪裡」。當 Oracle、Microsoft、MongoDB 與 Postgres 生態都把向量能力塞進資料平台，企業就更難合理化再多維護一套獨立資料源。

發生了什麼

文章認為，向量資料庫當初的賣點是「專門處理 embedding」。但現在，這個能力已經被主流資料庫快速吸收，從資料型別、向量索引到相似度搜尋都變成標配。對企業來說，這代表 AI 檢索不再一定要靠一個獨立產品來完成。

Asay 點名的例子很清楚，包括 Oracle AI Database 26ai、SQL Server 2025、MongoDB Atlas Vector Search 與 pgvector。這些產品把向量能力往資料平台內部收攏，讓開發者少跳一層工具堆疊。

他同時指出，向量供應商也在往上層走。像 Pinecone、Weaviate、Milvus、Qdrant 這類廠商，開始把重點放到檢索品質、延遲、治理與開發體驗，而不是只比誰能存 embedding。

• RAG、推薦、個人化與 agent 記憶都需要向量檢索。
• 企業 AI 還要接上交易資料、文件、權限與政策規則。
• 雙資料源容易造成 embedding 過期、答案不一致。
• 文章主張檢索應靠近受管控資料，而不是放在旁路系統。

為什麼重要

對開發者來說，這篇文章的意思很務實：如果資料本來就在資料庫裡，就先從那裡做向量搜尋。這能少掉同步管線、降低 glue code，還能讓權限與資料新鮮度維持一致。對客服助理、內部知識庫、發票查詢這類場景，這個差異尤其明顯。

這也會改變採購與架構決策。過去團隊常把向量庫當成 AI 專案的預設元件，現在則更可能先問：既有資料庫能不能直接做？如果答案是可以，第二套系統就必須拿出更強的延遲、排名、隔離或多租戶能力，才有機會站得住腳。

但這不代表專用向量庫會消失。若檢索本身就是產品核心，或服務需要極低延遲、大規模多租戶與高度客製排名，專門系統仍有位置。只是對多數企業應用，預設架構正在往「資料庫內建向量能力」靠攏，向量廠商接下來要比的不只是儲存，而是整體檢索品質。

問題已經不是向量搜尋值不值得做，而是團隊到底需不需要再養一個資料庫。對多數企業 AI 來說，答案可能是：先把現有資料庫用好，再談新增一套。