What is Hybrid Search?
Updated on
Hybrid Search is a retrieval architecture that runs two or more complementary candidate generators, deduplicates their results, and applies an explicit fusion policy to produce one ranked list.
Quick Facts
| Full Name | Hybrid Search in Information Retrieval |
|---|---|
| Created | Rapidly became the standard technology for improving recall quality in RAG systems during the LLM boom of 2023-2024. |
| Specification | Official Specification |
How It Works
Candidate Windows Set the Recall Ceiling
Each branch should declare its query transformation, index revision, filter semantics, candidate depth and timeout. Results need a stable document or chunk ID so the orchestrator can deduplicate the same evidence across branches while retaining provenance. Fusion cannot add a document absent from every branch window, so increase or redistribute candidate budgets only after measuring branch-level Recall@K. A large final topK does not compensate for shallow per-branch windows.
Choose Fusion by the Signal Contract
[Reciprocal Rank Fusion](https://qubittool.com/glossary/reciprocal-rank-fusion) combines positions and avoids assuming that BM25 and vector scores share a scale, but it discards score gaps and remains sensitive to rank constant, weights and window size. Score fusion preserves magnitude only after a documented normalization or calibration rule. A study of lexical-semantic fusion found tuned convex combinations competitive with and often stronger than RRF in its evaluated settings, so neither fixed alpha=0.5 nor one RRF default is a universal optimum.
Release the Pipeline, Not One Parameter
Compare every branch alone, the fused list, and fused-plus-reranked output on identical judgments. Report candidate Recall@K, MRR or nDCG, zero-result rate, duplicate rate, permission violations, p50/p95 latency and per-branch timeout rate. Slice exact identifiers, paraphrases, languages, negation, versions and fresh documents. Validate the selected policy on held-out queries, then shadow changes to analyzers, embedding models, corpus revisions, filters, branch depth and fusion configuration as one versioned retrieval artifact.
Key Characteristics
- Combines multiple candidate generators whose relevance signals and failure modes differ
- Operates over bounded branch windows, which impose an upper bound on recoverable evidence
- Requires stable document identity for cross-branch deduplication and provenance
- Supports rank-based, normalized-score, learned, or rule-aware fusion policies
- Adds index, query, latency, timeout, and consistency costs for every retrieval branch
- Must be evaluated against each constituent branch instead of assumed to improve relevance
Common Use Cases
- Searching technical documentation with both natural-language questions and exact error codes
- Retrieving products by descriptive intent while preserving model numbers, brands, and attributes
- Combining multilingual semantic retrieval with language-specific lexical indexes
- Merging rewritten-query, graph, dense, and sparse candidates before reranking
- Building a high-recall RAG candidate layer with explicit permissions and latency budgets
Example
Loading code...Frequently Asked Questions
Is hybrid search always better than dense or lexical search alone?
No. It helps only when branches make complementary errors and the fusion policy exploits them. Correlated branches can add cost without useful candidates, and poor fusion can demote the best result. Compare every branch and the fused pipeline on the same held-out judgments.
Should hybrid search always use BM25 and dense vectors?
No. That is the common baseline, not the definition. A hybrid system can combine learned sparse, graph, structured, multilingual, rewritten-query, freshness, authority, or other retrieval signals as long as identities and ranking semantics are explicit.
Should scores be averaged with alpha equal to 0.5?
Not by default. Raw scores can have incompatible ranges and distributions. Choose a normalization or calibration rule, tune the weight with representative labels, and verify it on held-out queries. A fixed equal weight is only an experiment baseline.
Can fusion recover a relevant document outside every branch window?
No. Fusion sees only candidates returned by its branches. Measure branch and union Recall@K before tuning final ordering, and budget enough depth for the reranker or context selector without exceeding latency and cost targets.
How should a partial branch failure be handled?
Define the policy before release. Optional branches may degrade with an explicit provenance and metric, while permission or tenant-filter failures should normally fail closed. Never silently label a single surviving branch as the fully evaluated hybrid result.