2026 RAG 向量資料庫三選一

2026 年做 RAG，向量資料庫早就不是看品牌。真正要看的是延遲、規模、查詢方式，還有你團隊願不願意養這套系統。Qdrant、Milvus、Weaviate 都很能打，但強項完全不同。

講白了，RAG 最怕的不是 embedding 不準。最怕的是檢索慢、過濾難、資料一多就炸。你如果做客服聊天機器人，100ms 跟 300ms 的差距，使用者體感差很多。你如果做企業搜尋，查詢量一上來，架構選錯就會很痛。

這篇不講空話。直接看三個產品怎麼選，哪個適合小團隊，哪個適合大規模，哪個適合混合搜尋。也順便把常見的部署成本和開發體驗攤開來看。

三者各自最擅長什麼

三個資料庫都在解同一題。就是把向量搜尋做好。可是路線完全不同。Qdrant 主打低延遲和 payload filter。Milvus 主打分散式擴展。Weaviate 則是把向量搜尋和關鍵字搜尋放在同一條查詢路徑。

如果你做的是 RAG，這個差異很重要。因為真實世界的查詢，常常不是純語意。使用者會打關鍵字、會輸入縮寫、會加時間條件、會指定部門。資料庫如果只會向量相似度，實戰就會卡住。

Qdrant 用 Rust 寫，這點很討喜。它在記憶體使用和延遲穩定性上，通常表現很漂亮。Milvus 則是為叢集設計，適合資料量很大、節點很多的場景。Weaviate 的優勢是整合感強，團隊不用自己東拼西湊就能做 hybrid search。

• Qdrant： Rust 架構，低延遲，filter 很強
• Milvus： 分散式架構，適合超大規模
• Weaviate： 混合搜尋強，API 直覺
• 共同點： 都能做 RAG 檢索層

架構差異，決定你後面痛不痛

很多團隊一開始只看 demo。這很正常。可是 demo 跟上線是兩回事。Qdrant 文件會讓你很快上手，因為它的定位很清楚。就是向量搜尋加強力過濾。對中大型資料集來說，這種設計很實用。

Milvus 文件就完全是另一種風格。它很在意叢集、索引、節點分工、GPU 加速。你如果要撐到十億級向量，Milvus 的設計會比小型向量庫更對路。代價也很直接，就是維運複雜度高。

Weaviate 文件則偏向開發體驗。它把語意搜尋、關鍵字搜尋、資料模型整合得比較順。你可以少接幾個服務。對產品團隊來說，這通常代表少一點雜事，多一點時間做功能。

“The future is already here — it’s just not evenly distributed.” — William Gibson

這句話放在向量資料庫很貼切。技術都能用了。差別只在你要的是什麼。低延遲、超大規模、還是搜尋品質，三者很難一次全拿。

我自己的看法很直接。你要穩定查詢和細緻過濾，先看 Qdrant。你要撐大資料量和高吞吐，先看 Milvus。你要混合搜尋，Weaviate 很順手。這不是信仰問題，是工程問題。

數字怎麼看，才不會被行銷話術帶走

看 benchmark 時，要先注意測試條件。不同廠商會用不同硬體、不同索引、不同 recall 設定。直接比數字，常常會誤判。不過，三者的方向還是很清楚。

Qdrant 在公開資料裡，常見說法是 1 億向量、95% recall、延遲低於 100ms。Milvus 常被拿來展示 10 億級部署，QPS 可以到 100,000 以上，延遲低於 200ms。Weaviate 則常見在 5 億向量、92% recall、延遲約 150ms 的區間。

這些數字的重點，不是誰最猛。重點是它們反映不同取捨。Qdrant 偏向低延遲和效率。Milvus 偏向極限吞吐和擴展。Weaviate 偏向搜尋品質和查詢彈性。你如果拿錯標準，選型就會歪掉。

• Qdrant： 1 億向量，95% recall，低於 100ms
• Milvus： 10 億向量，100,000+ QPS，低於 200ms
• Weaviate： 5 億向量，92% recall，約 150ms
• 解讀方式： 看你的瓶頸是延遲、吞吐，還是搜尋品質

硬體需求也很有參考價值。Qdrant 常見配置是 4 到 8 顆 CPU、8 到 16GB RAM、SSD。Milvus 則常看到 16 到 32 顆 CPU、32 到 64GB RAM、NVMe，還可能加 GPU。Weaviate 介於兩者之間，通常是 8 到 16 顆 CPU、16 到 32GB RAM、SSD。

這代表什麼？代表 Milvus 的天花板最高，但你也要付出最多資源。Qdrant 最省心，單機或小叢集都好養。Weaviate 則在功能和成本之間，抓了一個中間值。

功能差異，才是開發者每天會碰到的事

功能面才是日常。因為你不是只在看向量。你還要看 tenant、文件類型、時間區間、權限。Qdrant 的 payload filtering 在這裡很有感。它讓你在檢索時直接加條件，不用繞一大圈。

Milvus 的強項是索引選擇多。像 IVF、HNSW、SCANN 都能玩。這對想調 recall、速度、記憶體用量的團隊很重要。你可以根據資料分布和負載去調整，不會被單一路線綁死。

Weaviate 的優勢則是混合搜尋。它把 BM25 和向量排序放一起，對搜尋產品很實際。使用者常常既想要精準詞，也想要語意相近。這種場景，單純向量搜尋往往不夠。

• Qdrant： payload filter 強，適合多租戶和權限控制
• Milvus： 索引選擇多，適合調校型團隊
• Weaviate： hybrid search 直接整合
• 整合面： Weaviate 對 ML 工具鏈比較友善

如果你團隊已經用 Hugging Face，Weaviate 會很順。它對多模態 embedding 也比較友善。你如果要做文字、圖片、音訊一起搜，這種整合會省很多工。

成本也不能忽略。Qdrant 常常是每台機器效率最好。Milvus 雖然貴，但它買來的是容量和吞吐。Weaviate 的價值在於少接幾個元件，讓整體系統比較簡單。

產業背景，為什麼 2026 會這樣選

RAG 在 2026 年已經不是新玩具。它變成很多 AI 產品的標配。客服、知識庫、企業搜尋、推薦系統，都在用。問題也從「能不能做」變成「能不能穩定跑」。

這也是為什麼向量資料庫會分化。早期大家都想做通用解法。現在不行了。你要的是低延遲、還是高吞吐、還是混合搜尋，答案會直接影響架構。資料庫選錯，後面就會一直補洞。

另一個背景是資料治理。企業越來越在意 metadata、權限、租戶隔離。這讓 Qdrant 這類強 filter 的方案更有吸引力。反過來說，如果你的搜尋產品本來就很重 query relevance，Weaviate 的定位就更合理。

還有一點很現實。很多團隊不是缺模型，是缺維運人力。你如果只有 2 到 3 個工程師，Milvus 的複雜度可能太重。你如果有成熟平台團隊，Milvus 的擴展性就很香。這就是選型的殘酷地方。

結論：先看瓶頸，再選資料庫

如果你要我一句話總結，我會這樣分。Qdrant 是速度和控制。Milvus 是規模和吞吐。Weaviate 是混合搜尋和整合體驗。這三個方向都合理，差別只在你的產品卡在哪裡。

我的建議很直接。先拿你自己的資料做測試。看延遲、recall、filter 複雜度、部署成本。不要先信簡報。真實資料一跑，答案通常很快就出來。

如果你的 RAG 服務要面對即時查詢，我會先試 Qdrant。 如果你的資料量已經往十億級走，我會優先看 Milvus。 如果你的產品需要語意加關鍵字一起搜，Weaviate 很值得先試。

下一步最實際的做法，就是拿同一批 embeddings，跑三套原型。各自測 100、1,000、10,000 筆查詢。你會很快知道哪個最適合你的工作負載。這種答案，比任何型錄都準。