{"post":{"slug":"rank-fusion-explained-2026","title":"Rank Fusion: Combining Search Results That Do Not Compare","excerpt":"Vector similarity and keyword scores live on incomparable scales. Fusing by rank position rather than score sidesteps the problem and needs no tuning.","category":"ai","date":"January 8, 2026","author":"ByteLedger Team","content":"<span class=\"dropcap\">Y</span>ou 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.\n\nNow 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.\n\n## What changed in 2026\n\n- **Hybrid retrieval became the default.** Combining lexical and semantic search consistently outperformed either alone, which made fusion a routine requirement.\n- **Reciprocal rank fusion became the standard method.** Its tuning-free property made it the pragmatic default over weighted score blending.\n- **More signals entered the mix.** Metadata filters, recency, and multiple embedding models joined the ensemble in production systems.\n- **Fusion moved before reranking.** The settled pipeline shape became fuse-then-rerank rather than one or the other.\n\n## Why scores do not combine\n\nEach retrieval method produces a score with its own meaning and distribution.\n\nVector 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.\n\nNormalising 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.\n\nWeighted blending compounds this by requiring you to pick weights, which are corpus-specific, query-type-specific, and go stale.\n\n## Fusing by position instead\n\nReciprocal 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.\n\nThree properties make this the practical default:\n\n**No normalisation problem.** Position is position, in any list, from any retriever.\n\n**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.\n\n**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.\n\n| | Score blending | Reciprocal rank fusion |\n| --- | --- | --- |\n| Needs normalisation | Yes | No |\n| Needs weight tuning | Yes | No |\n| Sensitive to result set composition | Yes | No |\n| Rewards multi-retriever agreement | Indirectly | Directly |\n| Uses score magnitude | Yes | No |\n\nThe 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](/blog/rerankers-explained-2026).\n\n## Where it fits\n\nThe 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.\n\nFusion 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.\n\nAdding 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.\n\n## Common mistakes\n\n- **Adding raw scores.** Different scales, meaningless sum.\n- **Normalising per result set.** Introduces set-dependent distortion.\n- **Tuning weights that go stale.** A maintenance burden fusion avoids.\n- **Adding retrievers without measuring their unique contribution.** Cost with no recall gain.\n- **Fusing after reranking.** The order is fuse, then rerank.\n- **Assuming hybrid always wins.** On some corpora one method dominates; measure.\n\n## FAQ\n\n**Does this replace a reranker?**\nNo, they do different jobs at different stages. Fusion builds the candidate pool from multiple signals; reranking orders it precisely. Most production pipelines use both.\n\n**How many retrievers is worth it?**\nUsually two — semantic and lexical — with a third only if it demonstrably surfaces documents the others miss. Returns fall off quickly.\n\n**Is there a tuning parameter?**\nThere is a dampening constant, and the common default works well across corpora. That insensitivity is much of the method's appeal.\n\n**Can I fuse results from different indexes?**\nYes, 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.\n\n## Where to go next\n\nFor ordering the fused candidates, read [rerankers](/blog/rerankers-explained-2026). For measuring whether fusion improved anything, [retrieval metrics](/blog/retrieval-metrics-explained-2026), and for the indexing-side improvement, [contextual retrieval](/blog/contextual-retrieval-explained-2026).","hue":215,"metaTitle":"Rank Fusion: Combining Incomparable Search Results","metaDescription":"Why vector and keyword search scores cannot be compared directly, how reciprocal rank fusion combines them by position, and when hybrid retrieval helps.","keywords":["rank fusion","reciprocal rank fusion","hybrid search","combining search results","bm25 and vector search","score normalization","retrieval ensemble","rag retrieval 2026"],"tldr":["**Scores from different retrievers are not comparable** — a 0.82 cosine similarity and a keyword score of 12 mean nothing together.","**Reciprocal rank fusion uses position, not score** — which removes the normalisation problem entirely.","**It needs no weight tuning to work well** — a genuine advantage over score-based blending.","**Documents found by several retrievers rise** — agreement across methods is the signal it exploits.","**Skip:** fusion when one retriever clearly dominates for your corpus. Measure before adding a second."],"readTime":"4 min read","wordCount":868},"related":[{"slug":"hybrid-search-bm25-2026","title":"Hybrid Search: Why Keywords Still Beat Embeddings Sometimes","excerpt":"Dense retrieval misses exact matches that keyword search finds instantly. Here is how hybrid search combines them, and how fusion actually works.","category":"ai","date":"July 25, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":209},{"slug":"sparse-embeddings-explained-2026","title":"Sparse Embeddings: Keyword Search That Learned Semantics","excerpt":"Learned sparse retrieval produces vectors over vocabulary terms with model-assigned weights. Here is how it bridges keyword and dense search, and where it fits.","category":"ai","date":"July 26, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":216},{"slug":"semantic-search-vs-keyword-search-2026","title":"Semantic search vs keyword search in 2026: which to use","excerpt":"Keyword search matches words; semantic search matches meaning. Here is the 2026 guide to how each works, where each wins, and why hybrid search usually beats picking one.","category":"ai","date":"June 30, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":240}],"sameCategory":[{"slug":"agent-cost-attribution-2026","title":"Agent Cost Attribution: Finding Where the Tokens Went","excerpt":"A single monthly API bill tells you that agents are expensive. It does not tell you which feature, which customer, or which retry loop is responsible. That gap is fixable.","category":"ai","date":"August 19, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":220},{"slug":"human-in-the-loop-agents-2026","title":"Human-in-the-Loop Agents: Where to Put the Approval Gate","excerpt":"Approve everything and the agent is a slow autocomplete. Approve nothing and you have handed irreversible actions to a system that can be talked into things.","category":"ai","date":"August 19, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":197},{"slug":"reasoning-effort-controls-2026","title":"Reasoning Effort Controls: Tuning How Hard a Model Thinks","excerpt":"Fixed thinking budgets gave way to effort levels, and the default is rarely the right setting. Here is how the dial behaves and where each level actually belongs.","category":"ai","date":"August 19, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":210},{"slug":"retrieval-metrics-explained-2026","title":"Retrieval Metrics: Measuring the Half of RAG That Fails","excerpt":"When a RAG system answers badly, the retrieval usually failed before the model ever spoke. Measuring generation quality alone hides that entirely.","category":"ai","date":"August 19, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":215}],"newer":{"slug":"qsbs-rollover-explained-2026","title":"QSBS Rollover: Deferring Gain Into Another Small Business","excerpt":"Selling qualified small business stock before the holding period completes forfeits the exclusion. Rolling the proceeds into other qualifying stock preserves the position, within sixty days.","category":"finance","date":"January 8, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":291},"older":{"slug":"recursive-ctes-explained-2026","title":"Recursive CTEs: Querying Hierarchies in One Statement","excerpt":"Walking an org chart or a category tree in application code means N queries. A recursive common table expression does it in one, and it needs a termination condition you supply.","category":"code","date":"January 8, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":300}}