BM25 and dense retrieval do the same job (find documents that match a query) but they look at the query through different lenses, and they fail on different kinds of queries.
BM25 is a classical lexical retriever. It counts how often the exact words in the query appear in each document, with adjustments for word rarity and document length. It is fast, deterministic, and excellent when the query and document share specific tokens like 'gpt-5.5', 'invoice #18472', or 'E_BUSY_503'. It is bad when the query and document say the same thing in different words.
Dense retrieval embeds the query and documents into vectors using a neural model, then matches by cosine similarity. It captures meaning across paraphrases ('cancel my plan' matches 'terminate my subscription') but can blur exact-token hits into a fuzzy semantic neighborhood.
**Hybrid retrieval** runs both, then merges the two ranked lists, usually with Reciprocal Rank Fusion. Because the two retrievers fail on uncorrelated queries, the merged list catches both kinds of hits. Recall goes up; precision usually does too.
The two retrievers have uncorrelated failure modes, which is exactly why combining them works.
**BM25** is a lexical model. It scores by exact term overlap with TF-IDF style weighting. It excels on rare tokens: product names, version strings, error codes, proper nouns, and code identifiers. A query containing 'voyage-embed-v3' will match the document that contains that exact token and ignore documents about general embeddings. The failure mode is paraphrase. 'How do I cancel my plan' will miss a document titled 'terminating your subscription' because the words barely overlap.
**Dense retrieval** is a semantic model. The embedding model collapses synonyms and paraphrases into the same vector region, so 'cancel my plan' and 'terminate my subscription' land near each other. The failure mode is exact-token specificity. The model treats 'voyage-embed-v3' as roughly equivalent to 'voyage embedding model', so the query may rank generic documents above the specific match.
Because the failure modes are largely independent, fusing the two rankings catches both. The standard fusion algorithm is Reciprocal Rank Fusion. Score each candidate as the sum of `1 / (k + rank)` across both rankings (k around 60), then re-sort. RRF is robust because it does not require calibrated scores between the two retrievers; only ranks. Production hybrid systems consistently lift recall by 5-15 points over either retriever alone.
Quick reference
TL;DR
BM25 nails exact-token hits like IDs and proper nouns; dense vectors nail paraphrase and concept matches. Their failure modes are uncorrelated, so fusing the rankings lifts recall on both axes.
Imagine searching a library with two helpers. The first helper has a perfect memory for unusual words. Ask for the book that mentions a specific product code or a rare author's name and they find it instantly, but ask for a book on 'how to cook without dairy' and they get lost if the book actually says 'milk free recipes'. The second helper is great at understanding meaning. They know 'milk free' and 'without dairy' are the same thing, but they sometimes forget which book had that specific product code in chapter seven. The trick is to send both helpers, see what each one brings back, and merge the results. Each one covers the other's blind spot, and almost nothing falls through the cracks.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Corpus and queries are purely paraphrase heavy with no exact-token signal BM25 contributes little, so the operational cost of maintaining a second index is unjustified. Dense-only with a reranker is simpler.
Tight latency budget where two retrievals plus fusion exceed the deadline Hybrid retrieval doubles index lookups. If P99 is already at the edge with dense alone, the parallel BM25 call may push you over.
Tiny corpus where any retriever returns the right doc trivially Recall is already saturated; fusion adds complexity without measurable lift.
Quick scan · 2–4 min
Everything important, quickly.
3 min: contrast lexical versus semantic priors, give concrete queries each one wins on, explain why RRF beats raw score averaging, then close with how a reranker layers on top of the fused candidates.
Code example
python
from collections import defaultdict
def reciprocal_rank_fusion(rankings, k=60, top_k=20):
"""
rankings: dict of retriever_name -> ordered list of doc_ids (best first).
Returns fused top_k by RRF.
"""
scores = defaultdict(float)
for retriever, doc_ids in rankings.items():
for rank, doc_id in enumerate(doc_ids):
scores[doc_id] += 1.0 / (k + rank + 1)
fused = sorted(scores.items(), key=lambda kv: kv[1], reverse=True)
return [doc_id for doc_id, _ in fused[:top_k]]
# Usage in a hybrid RAG pipeline
bm25_hits = bm25_index.search(query, top_k=50) # list of doc ids
dense_hits = vector_index.search(embed(query), top_k=50) # list of doc ids
fused = reciprocal_rank_fusion({
"bm25": bm25_hits,
"dense": dense_hits,
}, k=60, top_k=20)
# Optional: rerank fused with a cross-encoder before passing to the LLM.
Side-by-side
Property
BM25 (lexical)
Dense retrieval (semantic)
Matches on
Exact token overlap with IDF weighting
Cosine similarity of learned embeddings
Strong on
Rare tokens, IDs, code, proper nouns
Paraphrase, synonyms, conceptual queries
Weak on
Synonyms and paraphrased intent
Specific rare tokens, exact strings
Cost at query
Inverted-index lookup, very fast
ANN over vector index, moderate
Indexing cost
Tokenize and update postings
Embed each chunk through a model
Output
Score per doc, easy to interpret
Cosine in [-1, 1], requires calibration
Real-world examples
Real products, models, and research that use this idea.
1Weaviate's hybrid search combines BM25 and dense vectors with RRF fusion in a single query call; Pinecone and Qdrant expose similar hybrid endpoints.
2pgvector paired with PostgreSQL full text search (or paradedb) is the standard hybrid stack inside an existing Postgres deployment.
3Cohere's reranker is commonly applied on top of fused BM25 plus dense candidates to add precision after recall.
4Elastic's ELSER (learned sparse) sits between BM25 and dense, sparse retrieval with learned weights, increasingly used in production hybrid stacks alongside or instead of BM25.
5OpenAI text-embedding-3-large or Voyage Embed v3 paired with Lucene BM25 inside Elasticsearch or OpenSearch is one of the most shipped 2026 RAG stacks.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy use Reciprocal Rank Fusion instead of simply averaging scores from BM25 and dense?
Sign in or go Pro to see the approach for this follow-up.
QWhere do learned sparse retrievers like SPLADE and ELSER fit in this picture?
Sign in or go Pro to see the approach for this follow-up.
QHow would you tune the BM25-versus-dense weight in your fusion?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Assuming modern dense embeddings make BM25 obsolete. They do not. Lexical hits on IDs, codes, and rare tokens remain a category where BM25 wins.