Multiple ranked lists, one better result
When you run hybrid retrieval, you don't get one ranked list — you get several. Dense retrieval returns its top candidates sorted by cosine similarity. BM25 or SPLADE returns its own list sorted by term-frequency scores. Multi-query generation produces N lists, one per rephrased query. Each list is internally sorted, but the scores are incomparable: a cosine similarity of 0.87 and a BM25 score of 14.3 don't live on the same scale.
Fusion is the mechanism that turns multiple ranked lists into a single, better-ranked list. Getting it right is the difference between a hybrid system that's genuinely stronger than either of its components and one where you've just added infrastructure complexity for no quality gain.
Ranks, not scores
The insight that makes RRF work is that you don't need scores — only rank positions. A document ranked 3rd by dense retrieval and 7th by BM25 is likely more relevant than one ranked 1st by dense but absent from BM25's top 20. RRF captures this by scoring each document as the sum of 1/(k + rank_i) across all lists, where k=60 is a smoothing constant that dampens the gap between rank 1 and rank 2 without over-weighting documents that happen to land at the very top.
The practical consequence is that RRF is robust to score scale differences by construction. Dense cosine similarities and BM25 scores can never be directly compared — but their ranks can. You need no normalization, no calibration step, and no per-domain tuning. The moment you have ranked lists, you have everything RRF needs.
This is why RRF has become the default fusion method for hybrid search. Weaviate, Qdrant, Elasticsearch, and LangChain all ship it as their out-of-the-box fusion strategy. When you see "hybrid search" in a vendor's documentation without further explanation, it almost always means dense ANN + BM25, fused with RRF.
RRF works even when component systems use completely different scoring functions — you can combine dense retrieval, SPLADE, and BM25 all in one pass without any additional configuration. The only thing required is that each system produces a ranked list.
Better lists to begin with
RRF tells you how to combine multiple lists. RAG-Fusion tells you how to get better lists to combine in the first place.
The pattern chains two ideas together. First, use an LLM to generate N rephrased versions of the original query — typically 3 to 5. Different phrasings activate different parts of the embedding space and different term matches: a query about "transformer attention" phrased as "how does self-attention work" and as "query-key-value mechanism in neural networks" will retrieve overlapping but distinct document sets. Second, run retrieval independently for each phrasing, then apply RRF across all result lists simultaneously.
The result is meaningfully broader recall. Documents that appear consistently across multiple phrasings — regardless of how the user originally expressed the query — rise to the top of the fused ranking. RAG-Fusion typically adds 10–20% recall improvement over single-query retrieval on knowledge-intensive tasks, and it compounds with whatever first-stage retrieval system you're already using.
The cost: N retrieval calls per user query multiplies first-stage latency. Three rephrased queries is the practical sweet spot — strong recall lift with manageable overhead. Beyond 4 or 5, weaker models start generating phrasings that are too similar to add real diversity, and returns diminish sharply.
When you have a prior worth expressing
RRF's strength — ignoring raw scores entirely — is also its limitation. Sometimes the scores carry real information about relative confidence, and discarding them in favor of rank alone throws that signal away. Linear score fusion lets you express a domain prior directly: final_score = α × dense_score + β × sparse_score.
If you're building code search, you might set α = 0.3 and β = 0.7, because exact function name and token matches matter more than semantic similarity in that domain. A medical literature system might reverse those weights, favoring semantic understanding over keyword overlap. The weights encode what you know about the retrieval task before any query arrives.
The catch is normalization. Dense cosine similarities might cluster between 0.6 and 0.95; BM25 scores might range from 0 to 40. Before you can add them, both must live on a common scale — typically min-max normalization or softmax per query. This calibration work is exactly what RRF avoids. Without validated domain priors confirming that one signal consistently outperforms the other, the normalization complexity rarely justifies the added failure surface.
Linear fusion earns its place when you have retrieval evaluation data showing that one signal dominates your specific domain. Without that evidence, you're likely adding a calibration step that introduces new ways to fail without a corresponding quality improvement over RRF.
Classic IR, still in the wild
CombSUM simply sums normalized scores across all retrieved lists. CombMNZ multiplies the CombSUM score by the count of lists in which the document appeared, penalizing documents that surface in only one retrieval pass. That document-count weighting accomplishes something similar to RRF's rank damping: documents showing up consistently across passes are rewarded, while results retrieved by only one system face a discount.
These methods predate learned retrieval by decades and are rarely the right choice for new systems — RRF is simpler, requires less normalization, and performs comparably or better in most benchmarks. You'll encounter them in older literature and enterprise systems with long-running IR infrastructure. Knowing them helps when you're working alongside legacy code or reading papers from before 2015.
Fusion is what makes hybrid search actually hybrid
Without fusion, you have two retrieval systems running in parallel that can't talk to each other. With it, you have a combined signal that's demonstrably stronger than either pass alone — but only if the combination is principled.
RRF is the right default in almost every case. It requires no normalization, no calibration data, and no per-domain tuning. If you're combining dense and sparse retrieval, start here. If you're building RAG-Fusion, RRF is the merge step at the center of the pattern. Reach for linear fusion only once you've done the retrieval evaluation work to confirm a domain prior worth encoding.
In the next lesson, we'll look at how documents get into the index in the first place — chunking strategies that determine whether retrieval even has a chance at finding the right passage.