向量資料庫怎麼選?Pinecone、Weaviate、pgvector、Milvus 實戰比較

半年前,一家做跨境電商的客戶把我拉進一場架構會議。他們的工程主管很興奮:團隊選了 Milvus,說是「業界最強、GitHub 星星最多」,叢集也架好了。我問了一個問題:你們現在的知識庫有多少筆資料?答案是四萬多段文件。

四萬段。這個規模,一張中階雲主機上的 pgvector 就綽綽有餘,他們卻先花了三週維護一套為十億級向量設計的分散式系統。系統沒錯,錯的是把「未來可能的規模」當成「今天的需求」在買單。

這是我們做向量資料庫比較時最想先講清楚的一件事:選型不是選「最強的」,是選「跟你當下規模、團隊維運能力、預算對得上的那一個」。RAG 知識系統的成敗,九成不在模型,在你能不能把檢索層穩穩地養在生產環境裡。

四個候選人,先認清各自的性格

先用一句話定位這四個常見選項。Pinecone 是全託管的雲服務,你不碰基礎設施,刷卡就能用;Weaviate 是開源、原生支援混合檢索與模組化 embedding,自架或用雲版都行;Milvus 為超大規模、分散式高吞吐而生,能力強但零件多;pgvector 則是 PostgreSQL 的一個擴充,把向量檢索直接長在你可能早就在用的關聯式資料庫裡。

它們不是同一個量級的東西。把 Milvus 和 pgvector 放在一起比,有點像拿貨櫃輪跟廂型車比載重——答案取決於你要送的是什麼、送去哪。

選型矩陣:依規模、成本、自架難度、中文支援

下面這張表是我們實際幫客戶評估時會攤開的四個維度。數字是量級參考,不是精確承諾。

關於中文支援要特別說一句:向量資料庫本身不「懂」中文,真正決定中文檢索品質的是你的 embedding 模型和切段策略。與其糾結哪個 DB 對中文友善,不如把力氣花在選一個中文語意表現好的 embedding、以及把長文件切得夠乾淨。DB 只負責存和算距離。

為什麼我們多數時候先建議 pgvector

如果你的資料在千萬向量以內、團隊已經在用 PostgreSQL、而且沒有專職的資料庫維運人力——先上 pgvector,幾乎不會錯。

理由很現實。第一,它跟你的業務資料住在同一個資料庫,做 metadata 過濾時可以直接 JOIN,不用在向量庫和主庫之間對帳,這在權限控管嚴格的金融、醫療場景省掉大量麻煩。第二,維運成本趨近於零,你原本怎麼備份、怎麼監控 PG,現在照舊。第三,它讓你把預算和注意力留給真正影響體感的地方:切段、embedding、重排序。

我們踩過的雷是反過來的——有客戶一開始就上專用向量庫,結果每次 RAG 回答不準,要同時排查向量庫、主資料庫、同步管線三個地方,除錯成本翻倍。後來搬回 pgvector,問題面積直接少一塊。

那什麼時候該升級?訊號很具體:單表向量逼近數千萬、檢索延遲在 HNSW 調參後仍壓不下來、或需要多租戶的水平擴展。這時再上 Milvus 或 Pinecone,你已經有真實流量數據,選型會準得多。先用 pgvector 把產品跑起來、拿到使用者行為,再拿這些數據決定要不要換更重的基礎設施——這個順序,比一開始就賭一套大系統務實太多。

選型不是終點,上線才是

Demo 裡的 RAG 都很聰明,因為問題是你自己挑的。真正的考驗是上線後,使用者用你沒預期過的問法、丟進髒掉的 PDF、在意每一次答錯。向量資料庫選得對只是把地基打平,後面的切段、重排序、評測回路,才是決定它有沒有人在用的關鍵。

在 Tenten,我們幫客戶導入 RAG 時,幾乎都是從 pgvector 起步,把檢索品質的評測管線先建起來,等真實用量說話了,才討論要不要換更重的向量庫。工程師會待在你的現場,盯著使用率爬上去為止——因為對我們來說,能被同事每天打開來用的系統,才算真的上線。