You run two searches for the same query. Vector search returns documents with cosine similarities around 0.7 to 0.9. Keyword search returns documents with relevance scores of 3 to 40, on a scale with no upper bound that depends on term frequencies in your corpus.
Now combine them. Adding the numbers is meaningless. Normalising each to zero-to-one imposes a scale the scores never had, and the normalisation shifts every time the result set changes.
What changed in 2026
- Hybrid retrieval became the default. Combining lexical and semantic search consistently outperformed either alone, which made fusion a routine requirement.
- Reciprocal rank fusion became the standard method. Its tuning-free property made it the pragmatic default over weighted score blending.
- More signals entered the mix. Metadata filters, recency, and multiple embedding models joined the ensemble in production systems.
- Fusion moved before reranking. The settled pipeline shape became fuse-then-rerank rather than one or the other.
Why scores do not combine
Each retrieval method produces a score with its own meaning and distribution.
Vector similarity is bounded and clustered — most results in a corpus fall in a narrow band, so the difference between a good and a mediocre match may be a few hundredths. Keyword scores are unbounded and depend on document length and how rare the query terms are in your specific corpus.
Normalising each set to a common range seems to solve it and introduces its own distortion: the normalisation depends on the maximum and minimum in this result set, so the same document gets different normalised scores depending on what else was returned. A query where all vector results are similar produces a normalised spread that exaggerates trivial differences.
Weighted blending compounds this by requiring you to pick weights, which are corpus-specific, query-type-specific, and go stale.
Fusing by position instead
Reciprocal rank fusion discards the scores entirely and uses only rank position. Each document receives a contribution from each list based on where it appeared, with a constant that dampens the influence of the very top positions, and the contributions are summed.
Three properties make this the practical default:
No normalisation problem. Position is position, in any list, from any retriever.
No weights to tune. It works well out of the box, which is unusual and genuinely valuable — one less thing to maintain as the corpus changes.
Agreement is rewarded. A document appearing in several lists accumulates contributions from each, so consensus across retrieval methods rises to the top. That is exactly the signal you want: documents that both the semantic and lexical view consider relevant are the strongest candidates.
|
Score blending |
Reciprocal rank fusion |
| Needs normalisation |
Yes |
No |
| Needs weight tuning |
Yes |
No |
| Sensitive to result set composition |
Yes |
No |
| Rewards multi-retriever agreement |
Indirectly |
Directly |
| Uses score magnitude |
Yes |
No |
The tradeoff is discarding magnitude. A document that is overwhelmingly the best match by score is treated as merely first. In practice that costs little, because the reranking stage afterwards restores fine-grained ordering — see rerankers.
Where it fits
The standard pipeline is: several retrievers run in parallel, fusion combines their rankings into one candidate list, a reranker orders that list properly, and the top few go into the prompt.
Fusion is doing the job of building a good candidate pool from complementary signals. Vector search finds paraphrases and conceptual matches; keyword search finds exact identifiers, error codes, and proper nouns that embeddings blur together. Neither catches everything the other does, which is precisely why combining them works.
Adding a third signal — a second embedding model, or metadata-boosted results — is straightforward with rank fusion and typically shows diminishing returns quickly. Measure whether each retriever contributes documents the others miss before keeping it.
Common mistakes
- Adding raw scores. Different scales, meaningless sum.
- Normalising per result set. Introduces set-dependent distortion.
- Tuning weights that go stale. A maintenance burden fusion avoids.
- Adding retrievers without measuring their unique contribution. Cost with no recall gain.
- Fusing after reranking. The order is fuse, then rerank.
- Assuming hybrid always wins. On some corpora one method dominates; measure.
FAQ
Does this replace a reranker?
No, they do different jobs at different stages. Fusion builds the candidate pool from multiple signals; reranking orders it precisely. Most production pipelines use both.
How many retrievers is worth it?
Usually two — semantic and lexical — with a third only if it demonstrably surfaces documents the others miss. Returns fall off quickly.
Is there a tuning parameter?
There is a dampening constant, and the common default works well across corpora. That insensitivity is much of the method's appeal.
Can I fuse results from different indexes?
Yes, and that is a strength — the lists need not come from the same store or even the same modality. Position is comparable regardless of source.
Where to go next
For ordering the fused candidates, read rerankers. For measuring whether fusion improved anything, retrieval metrics, and for the indexing-side improvement, contextual retrieval.