Reciprocal Rank Fusion Explained: The Formula Behind Effective Hybrid Search
BM25 says document A scores 24.7. Vector search says document B scores 0.83. Which one is more relevant?
Trick question. You can't compare those numbers, they're not even measuring the same thing. One's an unbounded lexical score that depends on your corpus, the other's a bounded cosine similarity. Averaging them, or trying to normalize them onto some shared scale, is a bit like averaging your weight in kilograms with your height in feet and calling it a fitness score.
Reciprocal rank fusion is the disarmingly simple fix for this. Ignore the scores entirely. Use only the ranks. One line of arithmetic from a two-page 2009 information retrieval paper now quietly runs inside Elasticsearch, Azure AI Search, Qdrant, and most vector databases you'd reach for today.
This piece covers what RRF actually is, the formula itself, a worked example you can recompute by hand (nobody else on the internet seems to have bothered), where it's built into the tools you're already using, and, importantly, when it's not the right call.
What Is Reciprocal Rank Fusion (RRF)?
Reciprocal rank fusion is a rank-aggregation method that combines multiple ranked result lists into one by scoring each document as the sum of 1/(k + rank) across every list it appears in. No score normalization. No tuning required to get something reasonable out of it on day one.
It sits inside a broader family called rank fusion, which is the general idea of merging multiple ranked lists into a single ranking. What makes RRF distinct is that it never looks at the underlying scores at all, only positions. That's exactly why it works when your retrievers score on wildly incompatible scales, which, let's be honest, is basically always the case in hybrid search.
Worth pausing on the source here, because a lot of people search for it specifically. RRF comes from a two-page paper by Gordon Cormack, Charles Clarke, and Stefan Büttcher, Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods, presented at SIGIR 2009. Two pages. That's it. They showed RRF beat Condorcet fusion and individual learning-to-rank methods on TREC data, and the method has aged remarkably well for something this simple. Papers with this good a ratio of impact to length don't come around often.
Quick disambiguation, since this trips people up constantly: RRF is not MRR (mean reciprocal rank). MRR is an evaluation metric, it tells you how good a ranking is by looking at where the first relevant result landed. RRF is a technique for merging rankings. Same root word, completely different jobs. Mixing these up in an interview is a fast way to make an interviewer's eyebrow twitch.
Build an AI-First Career, Master the Complete Skillset
Choose from our industry-leading programs designed for career success
Modern Software and AI Engineering Program
Master full-stack development with AI integration
+1000 moreModern Data Science and ML with specialisation in AI
Advanced data science techniques with AI specialization
+1000 moreAdvanced AIML with Specialisation in Agentic AI
Deep dive into AIML with focus on Agentic systems
+1000 moreDevOps, Cloud & AI Platform Engineering
Build and manage AI-powered cloud infrastructure
+1000 moreAI Engineering Advanced Certification by IIT-Roorkee
Premier AI engineering certification from IIT-Roorkee
AI Forward Deployed Engineer Program
Full-stack engineering, production AI and client-facing consulting
+1000 moreThe RRF Algorithm and Formula, Explained
Here's the formula, written the way you'll see it in the paper and in most engine documentation:
RRF_score(d) = Σ 1 / (k + rankᵢ(d))
Summed over each result list i, where ranki(d) is document d's 1-based position in list i, and k is a constant, 60 in the original paper.
A few things worth spelling out:
• ranki(d) starts at 1, not 0. The top result in a list has rank 1.
• If a document doesn't appear in a given list at all, it contributes 0 from that list. Simple as that.
• You sum the contribution across every list the document shows up in, then rank documents by that total.
Now, why 60? This is the part almost nobody explains well, so let's actually do the math. With k=0, the top-ranked document scores 1/1 = 1.0, and rank 2 scores 1/2 = 0.5. That's a massive gap, the top result in any single list would basically dominate the whole fused ranking regardless of what anyone else thinks. With k=60, rank 1 scores 1/61 ≈ 0.0164, and rank 2 scores 1/62 ≈ 0.0161. The curve flattens out. A document that shows up consistently around rank 3 or 4 in two different lists can now beat a document that was #1 in only one of them.
That's the entire intuition behind k. It controls how much weight the top of a list gets relative to the rest of it. The paper picked 60 empirically, and it's stuck as the de facto default ever since. Most engines expose it as a tunable knob, Elasticsearch calls it rank_constant and defaults to 60. Higher k blends more gently across lists; lower k lets the top results dominate.
We'll get to a real worked example in a second, code-light for now, promise.
Why Hybrid Search Needs Rank Fusion in the First Place
Quick definition, since this is the umbrella term everyone actually searches for: hybrid search means running lexical retrieval (BM25, keyword matching) and semantic retrieval (vector, embedding-based) in parallel, then merging the two result sets. The idea is that exact terms like error codes, SKUs, product names, and acronyms surface through keyword matching, while paraphrases and intent-based queries surface through embeddings. Neither approach alone covers both cases well.
| Dimension | BM25 (Lexical) | Vector Search (Semantic) |
|---|---|---|
| What it matches | Exact terms, tokens | Meaning, paraphrase, intent |
| Score type | Unbounded, TF-IDF-family, corpus-dependent | Bounded similarity, roughly 0 to 1 |
| Strengths | Rare tokens, IDs, acronyms, exact phrases | Synonyms, related concepts, fuzzy intent |
| Weaknesses | Vocabulary mismatch, misses paraphrases | Can miss exact tokens, degrades out-of-domain |
| Typical index | Inverted index | Vector index (HNSW, IVF, etc.) |
Neither column wins outright, which is exactly why teams run both. The mechanics of vector indexing and how vector databases actually store embeddings are worth a deeper look on their own, that's a rabbit hole for another article.
Here's the actual fusion problem, though. BM25 scores are unbounded and depend on your specific corpus, a score of 24 might be huge in one index and mediocre in another. Cosine similarities are bounded, roughly 0 to 1, but “roughly” is doing a lot of work in that sentence. Min-max normalizing both onto a shared 0-to-1 scale per query sounds reasonable until one weird outlier query rescales the entire distribution and suddenly your “normalized” scores mean something different than they did five minutes ago. It's brittle in exactly the way you don't want in production.
RRF sidesteps the whole mess by throwing scores away entirely and working with ranks. No normalization step to get wrong, no per-query rescaling surprises. It's the simple formula that actually works, which is really the thesis of this whole article. Retrieval engineering like this has quietly become one of the core skills expected on the AI engineer roadmap, not a niche add-on anymore.
RRF Worked Example: Two Ranked Lists Become One
This is the part most competing explainers skip, or half-do with two documents in a sentence. Let's actually walk through it with a real table you can recompute yourself.
Say someone searches “python list comprehension error.” BM25 and vector search each return their own top-3, and the overlap is only partial, which is completely normal.
• BM25 top 3: Doc A (rank 1), Doc B (rank 2), Doc C (rank 3)
• Vector top 3: Doc B (rank 1), Doc D (rank 2), Doc E (rank 3)
Using k = 60, here's the fused result:
| Document | BM25 Rank | Vector Rank | RRF Calculation | RRF Score | Fused Rank |
|---|---|---|---|---|---|
| Doc B | 2 | 1 | 1/62 + 1/61 | 0.0325 | 1 |
| Doc A | 1 | — | 1/61 | 0.0164 | 2 |
| Doc D | — | 2 | 1/62 | 0.0161 | 3 |
| Doc C | 3 | — | 1/63 | 0.0159 | 4 |
| Doc E | — | 3 | 1/63 | 0.0159 | 5 (tie w/ Doc C) |
Look at what happened with Doc B. It was never the #1 result in either individual list, BM25 had it at rank 2, vector search had it at rank 1. And yet it wins the fused ranking outright, ahead of Doc A, which was BM25's actual top pick.
That's the whole point of RRF in one sentence: consensus across retrievers beats a single retriever's champion. A document that both systems mildly like will often outrank a document that only one system loved. This is also, not coincidentally, exactly the intuition interviewers are fishing for when they ask “how would you combine keyword and vector search results” in a system design round.
One more thing worth noting on ties. Doc C and Doc E land at identical RRF scores here. Real engines break ties using their own internal document order or secondary criteria, this varies by implementation and isn't something the formula itself specifies.
And to hammer home why k matters: rerun this same example with k=1 instead of 60. Doc A, sitting alone at BM25 rank 1, now scores 1/2 = 0.5. Doc B scores 1/3 + 1/2 = 0.833, still ahead, but the gap between them shrinks dramatically compared to k=60, where Doc B won by a wider relative margin. Push k low enough and a document that was rank 1 in just one list starts crowding out genuine cross-retriever consensus. That's the entire reason the constant exists in the first place.
How Scaler Transformed Careers in Different Fields
Scaler learners achieved 2.5x salary growth with average post-Scaler CTC reaching ₹23L.
Google
Amazon
Microsoft
Flipkart
Adobe1200+ moreStop learning AI in fragments—master a structured AI Engineering Course with hands-on GenAI systems with IIT Roorkee CEC Certification
AI Engineering Course Advanced Certification by IIT-Roorkee CEC
A hands on AI engineering program covering Machine Learning, Generative AI, and LLMs - designed for working professionals & delivered by IIT Roorkee in collaboration with Scaler.
Enrol Now
RRF in RAG Pipelines
Where does this actually sit in a real system? Roughly: query comes in, gets sent to a BM25 retriever and a vector retriever in parallel, the two ranked lists get RRF-fused, and the fused top-k becomes the context handed to the LLM. If you want the bigger picture of where retrieval fits alongside agents and protocols like MCP, how RAG, MCP, and AI agents fit together is worth a read.
Hybrid retrieval with RRF is one of the highest-leverage fixes available when a RAG system keeps missing exact terms, error codes, legal clause numbers, specific product SKUs, that pure vector search tends to blur past in favor of “similar enough” semantic matches.
Retrieval failures like this are the single most common reason RAG systems underperform in practice, more common than people expect going in.
There's also a pattern worth a passing mention called RAG-Fusion, which reuses the exact same RRF formula in a different way: generate several LLM-written variants of the user's query, retrieve for each one separately, then RRF-fuse all the resulting lists together. It's an advanced pattern and deserves its own deep dive elsewhere, not something to cram into a paragraph here. If you want structured, project-based coverage of this whole retrieval layer rather than piecing it together from blog posts, there are some solid generative AI courses covering LLMs, RAG, and deployment worth a look.
Turn Learning into Career Growth
Strengths, Limitations, and When to Reach for Something Else
Here's where most competing articles go quiet. Let's not do that.
What RRF actually gets right:
• No score normalization step to get wrong
• Works across any number of retrievers, not just two
• One parameter to think about, and the default is usually fine to start
• Cheap. It's arithmetic over top-k lists, no model inference involved
• Been the sturdy default since 2009, which counts for something in a field that reinvents itself every six months
Where it falls short, honestly:
RRF ignores score magnitude completely. A document with a 0.95 cosine similarity and one with a 0.55 similarity, sitting at the same rank, contribute identically to the fused score. If your retrievers' actual confidence levels carry real signal, RRF throws that signal away. Relative score fusion, which Weaviate now defaults to, keeps score magnitude in the picture instead.
It also treats every retriever as equally trustworthy. If your BM25 index is meaningfully stronger than your embedding model, or the reverse, plain unweighted RRF dilutes the better signal down to match the weaker one. Weighted RRF variants exist for exactly this reason.
And k is still a knob someone has to think about, even if 60 is a fine starting point. Guessing beats nothing, but eval-driven tuning against a labeled set, measuring recall@k or MRR, beats guessing. The performance metrics in machine learning piece covers these classical evaluation metrics if you need the grounding.
Last one, and it's important: fusion is not reranking. RRF merges lists cheaply using positions alone. A cross-encoder reranker actually re-scores each query-document pair using a model, which is slower and costs more but buys you real precision gains at the top of the list. The production pattern that tends to win in practice is both: hybrid retrieve, RRF-fuse, then rerank the fused top-k with a cross-encoder before it ever reaches the LLM.
Quick decision framework, if you're choosing:
• Just getting started, or your retrievers' scores are genuinely incomparable → RRF defaults, k=60
• One retriever is clearly stronger than the other → weighted fusion
• Score magnitudes are trustworthy and roughly same-scale → relative score fusion
• Precision at the very top of the list actually matters → add a cross-encoder reranker after fusion
If you're prepping for a RAG-focused system design interview, this section is basically the whole answer to “how would you combine keyword and vector search.” Start with RRF, then talk through weighting and reranking as the natural next steps. That's the expected shape of the answer, and now you have it.
FAQs
What is reciprocal rank fusion (RRF)?
A method for combining multiple ranked search-result lists into one. Each document scores the sum of 1/(k + rank) across every list it appears in, and higher totals rank first. It needs no score normalization, which is exactly why hybrid search engines lean on it.
What is the RRF formula?
RRF_score(d) = Σ 1/(k + ranki(d)), summed over each result list i, where ranki(d) is the document's position in list i and k is a constant, 60 in the original paper.
Why is k = 60?
It was chosen empirically in the 2009 Cormack, Clarke, and Büttcher paper. A large k flattens the score curve so no single list's top result automatically dominates. Elasticsearch exposes it as rank_constant, defaulting to 60.
Is RRF the same as reranking?
No. RRF cheaply merges ranked lists using only positions. A reranker, usually a cross-encoder model, re-scores individual query-document pairs for higher precision. Production systems often use both: fuse with RRF, then rerank the fused top-k.
Is RRF better than score normalization?
It's more robust in most cases. Min-max normalizing BM25 and cosine scores per query is fragile to outliers. RRF sidesteps score scales entirely by ignoring them. That said, relative score fusion can beat RRF when score magnitudes actually carry reliable information.
Which engines support RRF?
Elasticsearch (rrf retriever), Azure AI Search (automatic in hybrid queries), Weaviate (selectable fusion type), Qdrant, Milvus, OpenSearch, and MongoDB Atlas. In Postgres with pgvector, it's a straightforward SQL join pattern rather than a built-in feature.
Does RRF need model inference?
No, and that's a big part of its appeal. It's pure arithmetic over top-k ranked lists, adding negligible latency, which is a large part of why it became the default fusion step in so many hybrid search stacks.
Is RRF related to MRR (mean reciprocal rank)?
They share the word “reciprocal” and not much else. MRR is an evaluation metric for ranking quality. RRF is a technique for merging ranked lists. Different jobs entirely, despite the naming collision.
Wrapping Up
Hybrid search works because RRF makes fundamentally incomparable retrievers comparable, by rank, not by score. One formula, one constant, and it's now built into nearly every serious search engine and vector database you'd reach for. Know the formula, recompute the worked example above by hand once so it actually sticks, and know when to reach for weighting or a cross-encoder reranker instead of assuming RRF alone is the finish line.
Retrieval engineering, hybrid search, evaluation, and production RAG, is a core module in Scaler's AI & Machine Learning program, taught through projects that go well beyond toy pipelines.
