選哪個向量資料庫，通常不是你的瓶頸——RAG 做不好的真正原因

企業技術團隊準備自建 RAG 知識庫時，最常問的第一個問題是：「市面上十幾款向量資料庫，哪一款最適合？」

這個問題本身沒錯，但它通常不是決定成敗的那一個。做過幾輪之後會發現：檢索效果不好的時候，九成的原因不在資料庫。

先講向量檢索在做什麼

傳統關鍵字搜尋是字面比對。你搜「紅色水果」，一份標題叫《富士蘋果栽培指南》的文件不會被找到，因為字面上沒有交集。

向量檢索的作法是把文字轉成高維空間中的座標，語意相近的內容座標也相近。查詢時計算距離，找出最近的幾筆。所以「紅色水果」能找到「蘋果」，因為它們在語意空間裡本來就靠在一起。

向量資料庫負責的就是在幾百萬個座標裡快速找出最近的 K 個。這件事各家都做得不錯，差異多半在毫秒等級——而那通常不是你的使用者會感受到的瓶頸。

真正決定成敗的三件事

一、切塊策略（chunking）。這是影響最大、也最常被忽略的一環。

文件要先切成小段才能建立向量。切得太大，一段裡混雜多個主題，檢索出來的內容有一半不相關；切得太小，語意不完整，模型讀了也答不出來。更麻煩的是切在錯的位置——把一個表格從中間切開、把「條件」和「例外」拆到兩段，檢索時只拿到一半，答案就會是錯的。

實務上這一步的投報率遠高於換資料庫。同一份文件，切法改一次，檢索品質的差異通常很明顯。

二、混合檢索（hybrid search）。純向量檢索有個弱點：對專有名詞、料號、型號這類「必須精確命中」的查詢不可靠。

使用者搜「B200-X3 的扭力規格」，向量檢索可能找回一堆語意相近但型號不對的段落。實務上的解法是關鍵字檢索與向量檢索並用，再把兩邊結果合併排序。對製造業、零售這類充滿型號與料號的場景，這一步幾乎是必要的。

三、後段重排序（reranking）。先用向量檢索撈回較多候選（例如 30 筆），再用一個較精細的模型重新排序，取前幾筆給大模型。這比直接取前 5 筆準確得多，成本增加有限。

那什麼時候才真的需要專用向量庫

如果公司已經在用 PostgreSQL，pgvector 擴充套件在很多情境下就夠了。它的好處是不必多維運一套系統——備份、監控、權限管理都沿用既有的，這對人力有限的中小企業是實質差異。

會需要 Qdrant、Milvus 這類專用向量庫的，通常是碰到下列其中一項：

• 資料量級大　向量數量到達數百萬以上，且查詢頻繁。
• 複雜的條件過濾　例如「只在這個部門、這個年份、這個產品線的文件裡搜」。專用向量庫在「過濾 + 相似度搜尋」同時進行時的效率明顯較好，這是它們與 pgvector 差距最大的地方。
• 需要頻繁更新與重建索引　文件變動快、要即時反映。

判準可以簡化成一句：先用既有系統做出可用的版本，遇到具體的效能瓶頸再換。反過來先選一套最強的資料庫，再回頭發現切塊策略沒做好，是常見的順序錯誤。

關於「精準度 99%」這類數字

向量資料庫的行銷素材常出現很高的精準度數字。看到時要問三件事：用什麼資料集測的、怎麼定義正確、K 值取多少。

檢索品質的常見指標是 recall@k——前 K 筆結果裡有沒有涵蓋正確答案。同一套系統，k=1 和 k=20 的數字可以差非常多。而且這個數字高度依賴資料本身：條理分明的技術手冊，跟散亂的客服對話紀錄，難度完全不同。

別人的數字對你沒有參考價值。務實的做法是自己準備 30 到 50 題真實的問題與正確答案，換設定就重跑一次。這是唯一能反映你自己資料的指標，而且做一次的成本很低。

資料落地的考量

選型時還有一個技術以外的因素：託管服務還是自架。

託管省事，但向量庫裡存的是公司文件的語意表示，多數情況下仍應視為敏感資料。對於受客戶保密協議限制的產業，這一項通常直接決定選項——這也是為什麼封測廠評估後全部選擇地端部署。開源且可自架，在這類情境是硬性條件而非偏好。

常見問題

RAG 檢索不準，該換向量資料庫嗎？

通常不該。檢索效果不佳的主要原因多為切塊策略不當（切得過大、過小或切在錯誤位置）、缺少關鍵字與向量的混合檢索、或未做後段重排序。建議依序檢查這三項，這些調整的投報率遠高於更換資料庫。各家向量資料庫在相似度搜尋本身的差異多在毫秒等級，通常不是使用者感受得到的瓶頸。

已經有 PostgreSQL，還需要另外裝向量資料庫嗎？

多數中小企業規模不需要。pgvector 擴充套件足以應付常見需求，且不必額外維運一套系統，備份、監控與權限管理都沿用既有機制。需要專用向量庫的情況通常是：向量數量達數百萬以上且查詢頻繁、需要複雜的條件過濾與相似度搜尋同時進行、或索引需頻繁重建。

怎麼判斷自己的 RAG 檢索品質好不好？

自行建立測試集是唯一可靠的方法。準備 30 到 50 題真實使用者會問的問題並標註正確答案來源，計算前 K 筆結果中涵蓋正確答案的比例（recall@k）。每次調整切塊策略或檢索設定後重跑同一份測試集比較。廠商公布的精準度數字使用不同資料集與定義，對個別企業沒有參考價值。

向量資料庫該用託管還是自架？

取決於資料敏感度與合規要求。向量庫儲存的是公司文件的語意表示，多數情況應視為敏感資料。若受客戶保密協議約束或有資料不得出境的要求，開源可自架是硬性條件。無此類限制時，託管服務可省下維運成本。

出處

Qdrant 相關資訊依其開源專案公開文件（GitHub: qdrant/qdrant）。文中關於切塊策略、混合檢索、重排序與 recall@k 評估方法之說明，為 RAG 系統建置的一般性工程實務，讀者可自行查證。各資料庫之效能表現請以自身資料集實測為準。