Section 7 · Learn · Retrieval
Hybrid retrieval
Running lexical and dense retrieval independently and merging their results, because each finds passages the other misses.
Running lexical and dense retrieval independently and merging their results, because each finds passages the other misses.
What it is
Two retrievers with different failure modes are run over the same corpus and their ranked lists are combined into one.
Why it is needed
Lexical search fails on paraphrase; dense search fails on rare exact strings. Their errors are largely independent, so the union recovers passages either alone would lose.
How it works
Both retrievers return a ranked list. The lists are merged by rank rather than score, because the two scoring scales have nothing in common.
At a glance
| Finds | Misses | |
|---|---|---|
| Lexical (BM25) | exact terms, identifiers, defined phrases | paraphrase, synonymy |
| Dense (bge-small) | paraphrase, related concepts | rare exact strings, precise identifiers |
| Overlap measured here | 5 of 20 | — |
In this project
Measured on real queries against the real corpus: of the top 20 from each path, the two agree on only 5 on average. Three quarters of each list is unique to that path. That number is the entire argument for fusion, and it is visible in the walkthrough demo.
Trade-offs
Advantages
- Recovers what either path alone would lose
- Failure modes are largely independent
- Needs no training
Limitations
- Two indexes to build and keep in sync
- Two sets of latency
- Fusion parameters are another thing to tune
Common mistakes
- Merging by raw score instead of rank
- Assuming more candidates always helps — precision falls
When to use it
Reach for it when
- Mixed vocabulary between users and documents
Avoid it when
- When one path demonstrably dominates on your query set
How it interacts with the rest of the system
BM25 and lexical searchEmbeddings and dense retrievalReciprocal Rank FusionCross-encoder reranking