待翻譯：Hybrid Search in Qdrant

AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。

Articles Qdrant Articles Hybrid Search in Qdrant Back to Search Quality Hybrid Search in Qdrant Dylan Couzon · August 24, 2026 A search result can look plausible and still be wrong. Dense retrieval can return a document on the right topic but miss an exact identifier copied into the query. Sparse retrieval can miss a relevant document when the query describes it with terms the corpus doesn’t use. Either way, your logs record a successful query. Hybrid search runs dense and sparse retrieval over the same query, then merges their result lists. Dense retrieval adds semantic similarity, so paraphrases can rank together. Sparse retrieval adds weighted term matching for exact words and identifiers. Compared with either retriever alone, hybrid search adds storage, indexing, and query work. Measure whether the gain is worth the cost instead of guessing. Dense and Sparse Retrieval Miss Different Things Dense retrieval embeds the query and each document, then ranks the documents by vector similarity. The model can place paraphrases near each other, but exact strings may lose influence among documents with similar meanings. Sparse retrieval represents text as weighted terms and scores the overlap between the query and document. BM25 sets those weights from term frequency, inverse document frequency, and document length. It requires no model inference. The product-search examples make that difference concrete. For each query, one retriever ranks a relevant product first, while the other ranks an irrelevant product first. QueryDense RetrievalSparse Retrieval french moldingfrench curves 6’’ h x 6’’ w x 1’’ d rosette applique (Relevant)french bread mold toast tray non-stick tray baking tray (Irrelevant) wayfair comforterswayfair basics comforter set (Relevant)wayfair basics peva shower curtain liner (Irrelevant) bathroom vanity knobscarran 30’’ single bathroom vanity set (Irrelevant)damask mushroom knob (Relevant) farmhouse cabinetrustic storage cabinet (Irrelevant)farmhouse 2 door accent cabinet (Relevant) For “french molding,” sparse retrieval follows the terms “french” and “mold” to the wrong product. For “bathroom vanity knobs,” dense retrieval finds the right category, while sparse retrieval follows “knobs” to the relevant product. Learned sparse models change what the sparse side matches. miniCOIL keeps BM25’s term matching but reweights each term by context, so “bat” in a sports listing and “bat” in a wildlife guide no longer share one weight. SPLADE adds related terms that the text never used. This recovers synonyms and moves sparse retrieval closer to what the dense retriever already covers. Start with BM25, which needs no model at query time, then measure a learned model against it before adopting one. Fusion Merges Two Rankings Into One In Qdrant, a prefetch runs a search and passes its candidates to the main query. Hybrid search uses one prefetch for dense retrieval and another for sparse retrieval. Fusion combines their candidate lists into one ordering. Dense similarity and BM25 scores use different scales. Dense similarity is bounded, while BM25’s magnitude depends on how many query terms match and how rare they are in the corpus. A fixed weight on the raw scores may balance one query but let BM25 dominate another. No single raw-score weight preserves the same balance across both. The dense scale stays similar, but the BM25 scale shifts across queries. RRF avoids the scale mismatch by discarding score magnitude. DBSF normalizes each score distribution per query. Reciprocal Rank Fusion, or RRF, reads only where each document landed in each list. That lets it combine a cosine similarity of 0.7 with a BM25 score of 12.4 without comparing the values directly. Cormack, Clarke, and Buettcher introduced the method in 2009, and it remains a standard way to combine ranked lists. Distribution-Based Score Fusion, or DBSF, rescales each list using its average score and score spread, then adds the rescaled scores. This preserves the size of score gaps, so a strong lead from one retriever can affect the final ranking. Neither method wins universally. Start with RRF, then compare DBSF against the same labeled queries. Formula Queries serve a different purpose: they rescore retrieved candidates with an expression over their retrieval scores and payload values. For example, a formula can boost recent or in-stock items. It does not make unnormalized dense and BM25 scores directly comparable. Custom scoring covers the expression syntax. Fusion only reorders. It works on the union of what the two prefetches returned, so a document neither one found cannot appear anywhere in the results. If a relevant document falls below a prefetch cutoff, increasing one or both prefetch limits can expose it to fusion. A larger limit adds retrieval work, and it does not help if the retrievers still miss the document at greater depth. Candidate depth explains how to test the limits, and the hybrid query documentation covers how prefetches feed fusion. The pale documents were never retrieved. If the right answer is one of them, no fusion method reaches it. What a Second Retriever Costs The setup that follows starts with a dense-only collection and adds BM25 as the second retriever. That means adding a sparse vector per point, a second index, and another search on every query. On one container serving one request at a time, the extra search raised median query latency by 0.60 to 1.47 ms. Measure the cost under your own concurrency and shard layout. Adding a sparse vector to an existing dense-only collection requires a new collection and a full reindex because the vector configuration is fixed at collection creation. The new collection declares both vector types. The sparse vector needs the IDF modifier, which gives rare terms more weight than common ones. Without it, a common word can count as much as a part number. from qdrant_client import QdrantClient, models client = QdrantClient( url="https://YOUR-CLUSTER.cloud.qdrant.io", api_key="", ) client.create_collection( collection_name="products", vectors_config={ # size matches your dense model's output dimensions. "dense": models.VectorParams(size=384, distance=models.Distance.COSINE) }, sparse_vectors_config={ "bm25": models.SparseVectorParams(modifier=models.Modifier.IDF) }, ) The hybrid search documentation covers indexing text and producing BM25 sparse vectors in every supported language. from your_embedding_models import dense_embed, sparse_embed query_text = "Samsung Galaxy S24 Ultra 512GB" results = client.query_points( collection_name="products", prefetch=[ models.Prefetch( # The same query, embedded for the dense retriever. query=dense_embed(query_text), using="dense", limit=100, ), models.Prefetch( # The same query, embedded for the sparse retriever. query=sparse_embed(query_text), using="bm25", limit=100, ), ], query=models.FusionQuery(fusion=models.Fusion.RRF), # Results returned to the caller. limit=10, ) using selects the named vector for each prefetch, and FusionQuery merges the two lists. Both prefetch limits start at 100. Measure Whether It Helps Across five public datasets, default RRF beat the stronger individual retriever on four. DBPedia-entity is the exception: fusion scores lower than dense retrieval. Run the same labeled queries with dense retrieval, sparse retrieval, and fusion. Keep the models and candidate limits unchanged. Score each run with nDCG@10, which gives more credit to relevant documents near the top. First, check whether fusion beats both retrievers. Review the queries where their rankings differ, then see whether the wins and losses cluster around important query types in your workload. If one retriever finds relevant results that fusion ranks too low, tune the fusion method or weights. How to Tune Hybrid Search covers those settings. If both retrievers miss a result, fusion has no candidate to promote. Recheck the winning setup on held-out queries. Building a labeled set covers query selection and held-out evaluation. Dense retrieval may already cover much of a natural-language-only workload, but query shape alone cannot tell you whether hybrid search will help. Keep the sparse retriever when the relevance gain justifies its measured indexing and latency cost. What to Test Next Add more stages. Multi-stage queries retrieve with a cheap representation and rescore with an expensive one. Cross-encoder reranking puts the query and chunk into a model together. When Is a Reranker Worth It? compares that approach with a tuned first stage. Tune what you have. The fusion method, the RRF constant, and the per-retriever weights can all move relevance without adding a stage. How to Tune Hybrid Search measures each one across the same five datasets. Was this page useful? Thank you for your feedback! 🙏 We are sorry to hear that. 😔 You can edit this page on GitHub, or create a GitHub issue. On this page: View as Markdown Edit on Github Create an issue