What Is Hybrid Search and How BM25 Plus Dense Vectors Beat Either Alone in RAG
Hybrid search fuses BM25 keyword retrieval with dense vector search using reciprocal rank fusion. Why two ranked lists beat either alone in RAG pipelines.
Contents
Hybrid Search
This topic is curated by our AI council — see how it works.
Fusion is the step every hybrid search deployment gets wrong first — not because either retriever underperforms alone, but because merging two differently-scored ranked lists into one trustworthy order is a genuinely unsolved-feeling problem. Get it wrong and every downstream stage, from reranking to query routing, inherits a shuffled candidate set it cannot recover from. That is why hybrid search sits early in the retrieval-augmented generation stack, and why production teams already treat it as the retrieval default rather than a later optimization.
- Hybrid search fuses two retrieval channels — sparse (BM25/SPLADE) for exact terms, dense vectors for meaning — typically merged with reciprocal rank fusion.
- Production leaders in three different domains — Notion, Perplexity, and Glean — already run hybrid as the retrieval default, not an experiment.
- Weaviate and Qdrant now ship hybrid as a built-in query type, but you still have to name the fusion algorithm and its k parameter explicitly.
- The hard part is the merge itself: two rankers score in different mathematical worlds, and naive averaging fails in ways that only surface in production.
The hybrid search reading path: fusion mechanics before the market noise
Start with what hybrid search is and how BM25 plus dense vectors beat either alone — it frames the two-retriever pattern and the fusion step before you touch any implementation detail. Then read BM25, SPLADE, and reciprocal rank fusion, which names the actual building blocks — a lexical index, a learned-sparse index, and the fusion algorithm that merges them — so the vocabulary in every later article stops being guesswork. Read score mismatch and tuning hell in the same sitting: it is where the theory in the first two articles meets the failure modes you will actually debug.
Once the mechanics are solid, the Weaviate, Qdrant, and SPLADE build guide turns the three specification surfaces — sparse, dense, fusion — into a working pipeline. For the market context behind that choice, how hybrid search powers production RAG at Notion, Perplexity, and Glean and the Weaviate BlockMax WAND / Qdrant Query API standardization race show where the vendors and the production leaders are converging. Close with hybrid search looks neutral but isn’t — if your corpus isn’t monolingual English, read it before you ship the defaults.
How hybrid search differs from reranking, query transformation, and contextual retrieval
Three neighbouring stages get folded into “hybrid search” in casual conversation, and each mix-up sends tuning effort to the wrong place.
- Hybrid search is not reranking. Fusion runs at retrieval time, merging two retrievers’ ranked lists into one candidate set — it widens what gets considered. Reranking runs afterward, on that already-fused shortlist, with a heavier model that reorders for precision. Tune the fusion weights to fix what gets found; tune the reranker to fix what gets found first.
- Hybrid search is not query transformation. Query transformation rewrites or expands the question before either retriever runs; hybrid search decides nothing about the query itself, only how two retrievers’ results get combined once they have both already run. Teams that add HyDE hoping it will fix a bad fusion are solving the wrong stage.
- Hybrid search is not contextual retrieval. Contextual retrieval changes what gets embedded and indexed in the first place — prepending context to each chunk — before hybrid search ever runs its two retrievers over that index. Fix the chunk first; fusion cannot recover context that was never indexed.
Common questions about hybrid search
Q: Do the major vector databases handle hybrid search the same way? A: No — Weaviate and Qdrant each ship their own fusion algorithm and query surface (Weaviate’s relativeScoreFusion and rankedFusion, Qdrant’s RRF and DBSF), and both are racing to standardize behind a single query endpoint. The BlockMax WAND / Qdrant Query API race tracks who is winning it.
Q: Which production teams are actually running hybrid search, not just benchmarking it? A: Notion, Perplexity, and Glean — three different domains, workspace AI, web search, and enterprise search — all converged on hybrid as their production default over pure-vector retrieval. How hybrid search powers production RAG at scale maps what they share.
Q: Is hybrid search worth building, or should dense-only retrieval stay the default? A: Add the sparse leg when exact terms matter — statute numbers, drug codes, function names, SKUs; dense-only stays fine when paraphrase tolerance is what your queries actually need. The Weaviate, Qdrant, and SPLADE build guide spells out the three specification surfaces before you commit.
Q: Does hybrid search retrieve fairly across languages? A: Not automatically — BM25’s lexical matching was tuned on languages with simple morphology, so the keyword leg can under-serve morphologically rich languages even while the vector leg reads them fine. Hybrid search looks neutral but isn’t traces the mechanism.
Part of the retrieval-augmented generation stack · closest neighbour: reranking. Coming to retrieval from a software background? Start with the story: Debugging RAG Failures: Why Developers Need a New Diagnostic Model.
1
Understand the Fundamentals
Hybrid search isn't just two retrievers running in parallel — the real engineering challenge lives in how their scores get fused. Understanding why dense and sparse methods fail in opposite ways is what makes the combination work.
Concepts covered
BM25, SPLADE, and Reciprocal Rank Fusion: The Building Blocks of Production Hybrid Search
BM25, SPLADE, and reciprocal rank fusion each solve a different retrieval problem. Here's how the three combine into a production hybrid search system.
Score Mismatch, Tuning Hell: The Hard Limits of Hybrid Search Fusion
Hybrid search merges BM25 and vector results, but the fusion step has hard limits. Score mismatch, RRF blindness, and tuning hell — explained.
2
Build with Hybrid Search
The build guides walk through wiring BM25 and vector search together, picking a fusion strategy, and tuning the weights without overfitting to a benchmark. Expect trade-offs around latency, index size, and how aggressively you rerank.
Tools & techniques
How to Build a Hybrid Search Pipeline with Weaviate, Qdrant, and SPLADE in 2026
Build a hybrid search pipeline by decomposing it into sparse, dense, and fusion specs. Covers Weaviate, Qdrant, and SPLADE-v3 for enterprise RAG.
3
What's Changing in 2026
Hybrid search is shifting from a hand-rolled pattern to a first-class feature in vector databases, with new fusion algorithms and query APIs landing fast. Watching which standards win matters because it shapes what you can build cheaply.
Models & benchmarks
Updated April 2026
Notion, Perplexity, and Glean: How Hybrid Search Powers Production RAG at Scale
Hybrid search is now the production RAG default. How Perplexity, Glean, and Notion combine lexical and semantic retrieval at scale, and what it signals.
Weaviate BlockMax WAND, Qdrant Query API: The 2026 Hybrid Search Race
Hybrid search is no longer a vendor differentiator. Weaviate's BlockMax WAND, Qdrant's Query API, and Postgres extensions are converging on one shape.
4
Risks and Considerations
Hybrid search looks like a neutral combination of two methods, but it inherits the biases of both — including how poorly keyword matching handles morphologically rich languages. Worth thinking about before assuming the defaults are fair.
Risks & metrics
Hybrid Search Looks Neutral but Isn't: Lexical Bias and the Languages BM25 Leaves Behind
Hybrid search looks neutral. But BM25's tokenizer favors English, and the languages it leaves behind reveal what fairness asks of retrieval systems.