如何為本地部署 RAG 選擇向量資料庫：ChromaDB vs Qdrant vs Milvus vs FAISS

如果你正在建構一個完全在自有基礎設施上執行的 RAG 管線，你面臨的首要決策之一就是使用哪個向量資料庫。向量儲存位於檢索層的核心——它保存你的文件嵌入，並提供為 LLM 提供上下文的最近鄰查詢。

在生產 RAG 部署中，有五個自託管向量資料庫持續出現：ChromaDB、Qdrant、Milvus、Weaviate 和 FAISS。每個在設置複雜度、可擴展性、元資料過濾和營運開銷方面做出了不同的權衡。本指南梳理這些權衡，幫助你為本地部署 RAG 選擇最佳向量資料庫，既不過度設計也不欠缺建構。

為什麼向量儲存的選擇很重要

你的向量資料庫不僅僅是一個儲存層。它直接影響：

• 檢索延遲。 緩慢的最近鄰搜尋意味著緩慢的回應。在規模化場景下，暴力掃描和最佳化索引之間的差異就是 20ms 和 2 秒的差異。
• 過濾精度。 大多數 RAG 系統需要元資料過濾——按文件類型、日期範圍、部門或存取級別。並非所有向量儲存都能同樣出色地處理這一點。
• 營運負擔。 有些儲存只需一個 pip install。其他則需要 Kubernetes、etcd 和分散式儲存後端。正確的選擇取決於你的團隊願意管理多少基礎設施。
• 可擴展性上限。 一個擁有 50,000 個向量的原型與一個擁有 5000 萬個向量的生產系統有著不同的需求。在專案中途遷移向量儲存是痛苦的。

五種選項的比較

以下是針對本地部署 RAG 最重要維度的實用比較。

ChromaDB

ChromaDB 是從零到可用 RAG 檢索的最快路徑。它嵌入執行在你的 Python 程序中，或作為輕量級伺服器執行。你用 pip 安裝它，指向一個目錄，然後開始插入向量。無需配置基礎設施。

權衡在於規模。ChromaDB 在單節點上可以很好地處理幾百萬個向量，但不提供分散式模式進行水平擴展。元資料過濾涵蓋基本的等值和範圍查詢，但缺乏 Qdrant 或 Weaviate 的表達力。

何時選擇 ChromaDB： 你是一個小團隊，正在建構文件少於 500 萬的 RAG 系統，你重視簡單性勝過原始效能。你想讓檢索本週就能運作，而不是下個季度。

Qdrant

Qdrant 是一個用 Rust 編寫的專用向量搜尋引擎。它作為單個 Docker 容器執行用於獨立部署，或在多個節點間以分散式模式執行。效能強勁——Rust 的記憶體模型使 Qdrant 具有持續的低查詢延遲，無垃圾回收停頓。

Qdrant 的突出之處在於過濾。其 payload 索引系統支援巢狀欄位、地理查詢和複雜的布林條件。對於需要將檢索範圍限定到特定部門、日期範圍或文件類別的 RAG 管線，Qdrant 原生處理這些需求，無需應用端後過濾。

何時選擇 Qdrant： 你需要具有豐富元資料過濾的生產級檢索，並且想要單容器部署。你的語料庫在低百萬到數千萬向量範圍。你想要強效能而不需要分散式資料庫的營運複雜度。

Milvus

Milvus 是重量級選項。它專為十億級向量搜尋設計，作為分散式系統執行，具有獨立的查詢節點、資料節點、索引節點和協調服務。最小的 Milvus 部署需要 etcd 用於元資料、MinIO 用於物件儲存，以及 Milvus 服務本身。

這種複雜性在規模化時是合理的。Milvus 支援多種索引類型（IVF、HNSW、DiskANN），處理自動資料壓縮，並可透過新增節點水平擴展。如果你正在索引大型企業的整個文件語料庫——數千萬份文件、數億個分塊——Milvus 就是為這種工作負載建構的。

何時選擇 Milvus： 你有專門的基礎設施團隊，你的向量數量將超過 5000 萬，你需要水平可擴展性。你願意在營運複雜度上投入，以換取無需架構變更即可擴展的能力。

Weaviate

Weaviate 將自己定位為不僅僅是向量資料庫——它是一個搜尋平台，內建向量化模組、混合搜尋（將稠密向量與 BM25 關鍵字搜尋結合）和類 GraphQL 查詢 API。它作為單個二進位檔或 Docker 容器執行，叢集可用於水平擴展。

混合搜尋能力是 Weaviate 的顯著特徵。許多 RAG 用例受益於將語意搜尋（這是什麼意思）與關鍵字搜尋（這個確切術語是否出現）結合。Weaviate 在單次查詢中處理兩者，簡化了你的檢索管線。

權衡在於組態面。Weaviate 有很多參數——結構定義、模組選擇、向量化器組態——學習曲線比 ChromaDB 或 Qdrant 更陡峭。

何時選擇 Weaviate： 你在 RAG 管線中需要混合搜尋（語意加關鍵字），並且想要一個系統同時處理兩者。你的團隊能夠接受更大的組態面以換取更多內建功能。

FAISS

FAISS（Facebook AI Similarity Search）不是資料庫——它是一個函式庫。它提供高度最佳化的最近鄰搜尋演算法，執行在 CPU 或 GPU 上，但沒有伺服器、沒有 API、沒有持久化層、沒有元資料過濾。你將向量載入記憶體中，建構索引，然後從應用程式碼中查詢。

FAISS 提供的是原始速度。對於批次檢索工作負載——對固定索引處理數千個查詢——配合 GPU 加速的 FAISS 難以超越。它支援近似最近鄰索引（IVF、PQ、HNSW），在單機上可擴展到百萬級向量。

權衡在於相似性搜尋之外的一切都是你的責任。持久化意味著手動儲存和載入索引檔案。過濾意味著在你的應用中實作。更新意味著自己重建或部分更新索引。

何時選擇 FAISS： 你有很強的工程能力，需要最大檢索吞吐量，你的用例涉及批次處理或相對靜態的索引。你能夠自行建構周圍的基礎設施（持久化、過濾、更新）。

Ertas 如何融入決策

Ertas 不取代你的向量資料庫——它處理上游的一切。Ertas 管線匯入原始文件，清洗和標準化，將文字分割成檢索最佳化的片段，生成嵌入，然後將生成的向量寫入你的團隊選擇的任何儲存中。

Ertas 中的 Vector Store Writer 節點連接到 ChromaDB、Qdrant、Milvus、Weaviate 和 FAISS。五種都在本地執行，將你的資料保留在你的基礎設施上。當你的團隊決定切換向量儲存——從 ChromaDB 原型開發轉到 Qdrant 或 Milvus 用於生產——上游管線保持不變。你改變的是目的地，而非過程。

這種分離很重要，因為 RAG 管線中最難的部分很少是向量儲存本身。而是將乾淨、分塊良好、正確嵌入的資料放入儲存中。自託管向量資料庫比較通常關注查詢效能，但檢索品質更多取決於你放入了什麼，而非你如何搜尋。

做出決策

對於大多數開始本地部署 RAG 的團隊，實用路徑是：

1. 從 ChromaDB 或 Qdrant 開始。 先用真實資料讓檢索執行起來，再最佳化基礎設施。
2. 升級到 Qdrant 或 Weaviate，當你需要更豐富的過濾、混合搜尋，或你的語料庫超出了輕量級儲存能夠舒適處理的範圍。
3. 升級到 Milvus，僅當你有專門的基礎設施團隊，且你的規模確實需要分散式向量搜尋時。
4. 使用 FAISS，當你需要最大批次處理吞吐量，且你的工程團隊能夠承擔基礎設施層的所有權。

最適合本地部署 RAG 的向量資料庫是與你團隊的營運能力和資料實際規模相匹配的那個——而不是比較表上功能最多的那個。