Qdrant：以 Rust 打造的向量資料庫，過濾與混合搜尋的務實選擇

它解決什麼問題，誰需要它

Qdrant 是向量相似度搜尋引擎，也是向量資料庫。它把神經網路產生的 embedding 儲存起來，並提供 API 去搜尋最相近的向量。這類工具在 RAG、語意搜尋、推薦系統與去重任務中扮演關鍵角色。與其說它是資料庫，不如說它是專為向量查詢設計的服務。它特別強調延伸過濾支援，也就是在搜尋時同時根據 payload 條件縮小範圍。這對電子商務的分面搜尋、多租戶隔離或帶條件的推薦特別有用。若你只是要對幾萬個向量做暴力比對，用 numpy 就夠了。但當向量數量成長到百萬級，且需要低延遲回應時，Qdrant 這類專用引擎才有意義。它用 Rust 撰寫，這在記憶體安全與效能之間取得平衡，對高併發查詢有實質幫助。

實際運作機制：向量、payload 與索引

Qdrant 的核心概念是 point，每個 point 包含一個向量與額外的 payload。payload 是任意 JSON 結構，像是顏色、價格或類別。搜尋時，Qdrant 會同時考量向量相似度與 payload 過濾條件。文件指出它支援密集向量、稀疏向量與多向量搜尋。密集向量適合語意相似度，稀疏向量則接近全文檢索的詞袋表示。多向量讓你可以用多個 embedding 表示一個項目，例如不同角度的影像特徵。索引方面，Qdrant 使用 HNSW 這類近似最近鄰演算法，並提供量化機制來壓縮向量，減少記憶體使用。量化會犧牲一些精確度，但能換取更高的吞吐量。分片與複製讓資料可以分散到多個節點，這對大規模部署是必要的。整體資料流是：客戶端透過 REST 或 gRPC 寫入 point，Qdrant 建立索引，查詢時以向量搜尋搭配 payload 過濾，最後回傳符合條件的結果。

部署與啟動：從 Docker 到用戶端

最直接的啟動方式是 Docker。官方 README 給的指令是 docker run -p 6333:6333 qdrant/qdrant。這會啟動一個沒有認證的服務，且開放所有網路介面。文件明確警告這是不安全的部署方式，生產環境必須參考安全指南設定 API 金鑰與網路限制。啟動後，你可以用 Python 用戶端連線：QdrantClient(url="http://localhost:6333")。Python 用戶端是官方維護的，另外還有 Go、Rust、JavaScript/TypeScript、.NET/C# 與 Java 用戶端。社群也提供 Kotlin 與 PHP 用戶端。REST API 有 OpenAPI 3.0 規格，你可以下載 openapi.json 來產生其他語言的客戶端。gRPC 介面則提供更低延遲的查詢，適合生產環境。若你的應用需要離線或邊緣運算，Qdrant Edge 是另一種選擇。它直接嵌入應用程式程序，資料儲存在本地，並可與伺服器同步。

Qdrant Edge：程序內嵌的離線變體

Qdrant Edge 是輕量版本，設計給資源受限的裝置或需要低延遲與離線功能的場景。它不像伺服器版採用客戶端伺服器架構，而是直接跑在應用程式程序內。資料儲存在本地，查詢也在本地完成。這代表你可以把向量搜尋能力塞進手機或 IoT 裝置，不需要網路連線。Edge 使用 EdgeShard 類別來管理資料。Python 範例顯示，你可以用 EdgeShard.create("./shard", EdgeConfig(...)) 建立一個分片，然後用 update 方法 upsert points。它支援與 Qdrant 伺服器同步，但文件沒有詳細說明同步的衝突解決機制。這是一個潛在的弱點：如果你的裝置離線時寫入資料，之後同步時可能發生衝突。Edge 適合快取或本地推薦，但不適合需要嚴格一致性的分散式系統。

限制與失敗模式：不是萬能搜尋引擎

Qdrant 的強項是向量搜尋，但它不是全文檢索的替代品。稀疏向量可以處理部分詞彙比對，但複雜的布林查詢、詞幹分析或同義詞擴展仍需外部工具。文件沒有提到內建的語法分析器，這表示你必須自己處理文字前處理。另一個限制是量化與 HNSW 的參數調整。預設值可能不適合你的資料分佈，錯誤的參數會導致召回率下降或記憶體暴增。你必須實驗 m、ef_construction 與量化位元數，這需要時間。此外，docker run 指令的預設行為是沒有認證的，若直接暴露在網路上，任何人都可以讀寫資料。文件雖然警告了，但新手可能忽略。最後，Qdrant Edge 的同步機制不明確，若你的應用需要多裝置同步，這可能成為瓶頸。

替代方案：Milvus 與 Weaviate 的取捨

談向量資料庫，不能不提 Milvus 與 Weaviate。Milvus 也是開源向量資料庫，但它採用分離式架構，將儲存與計算分開，這讓它更容易水平擴展到數十億向量。Qdrant 則偏向單體服務，透過分片與複製擴展，但架構相對簡單。如果你的資料量極大，且需要動態擴展儲存節點，Milvus 的架構可能更有優勢。Weaviate 則內建了更多的整合功能，例如直接與 Hugging Face 模型連接，以及內建的 GraphQL 介面。Qdrant 的 API 是 REST 與 gRPC，沒有 GraphQL。若你的團隊偏好 GraphQL 或需要開箱即用的模組化整合，Weaviate 更友善。Qdrant 的優勢在於 Rust 的效能與精簡的 API 設計。它沒有過多的抽象層，學習曲線較低。但這也代表你需要自己拼裝額外功能，例如文字前處理或模型管理。

編輯結論

若你的專案需要密集向量搭配精確的 payload 過濾，且重視 Rust 帶來的低延遲與高吞吐，Qdrant 是值得考慮的選項。若你只需要純向量搜尋、不需要複雜過濾，或團隊對 Java 或 Go 生態較熟悉，Milvus 或 Weaviate 可能更順手。採用前應先驗證三件事：一是量化與 HNSW 參數對召回率的實際影響，二是分片與複製策略在目標資料量下的效能，三是 Qdrant Edge 的同步機制是否滿足離線需求。Qdrant 的 Apache-2.0 授權允許商用，但雲端版本與 Edge 的額外功能需注意授權範圍。最後，務必設定 API 金鑰並限制網路存取，官方文件明確警告預設的 docker run 指令是不安全的。

官方來源

1. Official documentation
2. Official README
3. Project repository
4. Release notes