Qdrant 為 AI 應用加上向量搜尋

Qdrant 是一個用 Rust 寫的向量資料庫，主打語意搜尋、混合檢索，還能支援 AI 應用的雲端與邊緣部署。

說真的，這類工具現在很重要。Qdrant 在 GitHub 有 31.5k stars、2.3k forks、419 個 open issues，還有 133 個 pull requests。這種數字不只是熱度，還代表很多人真的拿去跑。

它的定位也很直接。這不是拿來做一般資料庫的附加功能。它是專門處理 embedding、相似度搜尋、payload filter 的工具。講白了，就是給 AI app 找資料用的。

Qdrant 到底在做什麼

Qdrant 是一個向量相似度搜尋引擎，也是向量資料庫。它會把 embeddings 存起來，再用距離計算找出最接近的資料。這很像搜尋，但比傳統關鍵字搜尋更懂語意。

它還有一個很實用的設計。每個 point 都能掛 payload。你可以把分類、價格、地區、時間這些條件一起拿來篩。這點很重要，因為真實產品幾乎都不是單純比向量距離。

你可能會想問，這跟一般搜尋引擎差在哪。差在它更偏向 AI 工作流。推薦系統要相似度，也要商業規則。語意搜尋要懂意思，也要能過濾。RAG pipeline 要快，也要能控結果。Qdrant 就是往這個方向設計。

• 用 Rust 寫，偏向效能與記憶體安全
• 支援 payload filter，能做條件查詢
• 有 REST 和 gRPC API
• 提供多種 client：Python、JavaScript、Go、Java、.NET

功能不是噱頭，是真的能上線

Qdrant 的功能表很務實。它支援 dense vectors、sparse vectors，還有 multivector search。這代表它不只懂語意，也能處理文字型檢索，甚至像 ColBERT 這類模型的需求。

更實用的是 hybrid search。這種做法會把語意訊號和關鍵字訊號混在一起。因為現實世界很少只有一種查法。有人打錯字，有人想找精準詞，有人只是想找意思接近的內容。

另一個數字很有感。Qdrant 提到內建 quantization 最多可把 RAM 用量降到原本的 3%。也就是說，最高可減少 97%。對要省伺服器成本的團隊來說，這不是小事。

• dense、sparse、multivector 都是核心功能
• hybrid search 可搭配 RRF、DBSF 等融合方法
• quantization 最多可減少 97% RAM
• 支援 sharding、replication、零停機更新

Rust、Edge、Agent，三條線一起推

Qdrant 用 Rust，這點很合理。Rust 的優勢很明確。速度快，記憶體控制也穩。對資料量大、查詢多的服務來說，這種底層選擇會直接影響成本。

但我覺得更有意思的是部署方式。你可以走一般 client-server 模式，也能直接用 Docker 起一個服務。官方範例很直白：docker run -p 6333:6333 qdrant/qdrant。這種做法對開發者很友善。

它還有 Qdrant Edge。這是比較輕量的版本，可直接放進應用程式裡。對低延遲、離線、端側推論場景，這條路很實際。官方也把 agent skills 放進來，像 quantization、sharding、tenant isolation、hybrid search、model migration。

“Qdrant is a vector database and similarity search engine designed to store embeddings and payloads, and to provide fast filtering and search.” — Qdrant README

這句話很老實，也很到位。它沒有把自己包裝成什麼萬能平台。它就是做檢索、做過濾、做搜尋。這種產品定位反而比較可信。

跟其他方案比，差在哪裡

如果你現在在選向量資料庫，重點不是誰 demo 比較炫。重點是誰比較好維運，誰比較省資源，誰比較適合你的資料流。

Qdrant 的強項是控制力。你可以自己架，也可以用 Qdrant Cloud。你可以跑雲端，也可以跑 edge。這種彈性對團隊很重要，因為很多專案一開始只想先試，後面才會遇到規模問題。

和其他常見方案比，差異很清楚。Pinecone 偏 managed-first。Weaviate 偏 schema 與語意資料模型。PostgreSQL 加 pgvector 則適合已經深度使用 SQL 的團隊。Qdrant 比較像專門為 retrieval 場景設計的工具。

• Pinecone：主打託管服務
• Weaviate：強調 schema 與資料建模
• PostgreSQL + pgvector：適合既有 SQL 架構
• Qdrant：偏向檢索、過濾、混合搜尋

我自己的看法很簡單。若你的產品重點是 RAG、推薦、語意搜尋，Qdrant 會比通用資料庫 extension 更順手。因為它把很多你遲早會碰到的細節，先做進去了。

這個專案為什麼現在值得看

Qdrant 已經不是只靠概念撐場面的專案。它有 6,041 個 commits，有多種 client library，也有 cloud 和 edge 兩條路。這代表它在解決真實問題，不是在做簡報用的 demo。

放到 AI 應用的脈絡裡看，vector search 早就不是加分項。它常常是產品能不能用的底層能力。你要找文件、找知識、找商品、找訊息，都會碰到它。

所以我會建議開發團隊直接測三件事。第一是 payload filter。第二是 hybrid query。第三是 RAM 用量。這三個測完，你就知道它適不適合你的資料量和成本預算。

如果你今年要做 RAG、企業搜尋，或 agent 檢索層，我會先把 Qdrant 放進候選清單。先跑小型資料集，再拉到真實資料。這比看規格表準多了。