2.6 選擇向量資料庫：考量因素

向量資料庫的選項很多，功能也在快速變化。與其背誰比較好，不如學會「看什麼條件」，之後遇到新工具也能自己判斷。

要考慮的因素

資料規模

• 幾千到幾十萬筆：幾乎所有選項都撐得住，連暴力搜尋都可以。
• 幾百萬到上億筆：要看索引效率、能不能分散到多台機器、記憶體用量。

部署方式

• 嵌入在程式裡 / 本機檔案：最簡單，開發快，但不方便多人、多服務共用。
• 自己架設的服務：彈性大，要自己維運。
• 全託管的雲端服務：省事，但要付費，資料也存在別人那裡。

搜尋功能

• Metadata 過濾：能不能依條件篩選，而且過濾後搜尋仍然準又快。這在企業文件、多使用者的場景很常用。
• 混合檢索：能不能同時用關鍵字和向量搜尋。
• 多種距離量法：有沒有支援你的模型建議的那一種。

效能

• 查詢延遲：使用者能接受多久？
• 每秒查詢量：同時有多少人在用？
• 寫入速度：資料更新頻繁嗎？

成本

• 雲端服務看用量和資料量計費。
• 自己架設則是機器和維運的人力成本。
• 向量越多、維度越高，需要的記憶體和儲存空間就越多。

整合與生態系

• 跟你用的框架（LangChain、LlamaIndex 等）接得起來嗎？
• 有沒有你用的程式語言的套件？
• 文件和社群資源夠不夠？

資料安全與權限

• 資料能不能放在雲端？有沒有加密？
• 能不能依使用者權限限制可以搜尋的範圍？

注意　權限控制要特別小心。如果沒有在檢索這一步過濾，沒有權限的內容就可能被送進模型，再出現在回答裡。

維運負擔

備份、升級、監控、擴充，這些誰來做？小團隊或個人，維運成本常常比功能差異更重要。

依情境選的一般建議

這些是一般性的起點，不是標準答案：

情境	可以考慮
學習、做原型、資料量不大	Chroma，或直接用 FAISS
已經在用 PostgreSQL，資料量中等	pgvector，不用多維護一套系統
需要完整功能、可自己架設	Qdrant、Weaviate、Milvus
想省維運，願意付費	Pinecone 這類全託管服務
資料很敏感，不能離開內網	自己架設的方案

實務上的建議

1. 先用最簡單的開始。 原型階段不需要擔心上億筆資料，先把流程跑通。
2. 把資料庫包在一層介面後面。 這樣之後想換，只要改這一層，不用動整個系統。
3. 換資料庫比換嵌入模型容易。 換資料庫只是搬資料；換嵌入模型要重新產生所有向量。所以嵌入模型的選擇更值得先花時間測試。

選好之後，我們就用一個簡單的例子，實際把文字變成向量。