Reciprocal Rank Fusion (RRF) for RAG: Merging Search Results the Simple Way

Hybrid search runs two kinds of retrieval and has to combine their results: one that matches meaning (vector search) and one that matches words (keyword search such as BM25). The awkward part is that the two produce scores on different scales. A vector similarity of 0.62 and a keyword score of 14.3 cannot simply be added. Reciprocal rank fusion, or RRF, sidesteps the problem with a beautifully simple idea: ignore the scores and use only the ranks. A passage that appears near the top of either list scores well, and one that appears near the top of both scores best. This guide explains RRF in plain terms, shows the formula and a worked example, discusses the constant everyone asks about, describes weighted variants and limits, and shows how to check on your own data that the merge helps. It builds on our guide to hybrid search for RAG.

The problem RRF solves

Adding or averaging these is meaningless. Normalising them is possible but fragile, because the distributions change with the query and the data. RRF avoids the issue by throwing away the scores and keeping only the order.

The formula

For each passage, RRF adds up a contribution from every list in which it appears. The contribution is one divided by a constant plus the passage's rank in that list. With rank starting at 1 and a constant k, a passage's score is the sum over lists of 1 / (k + rank).

The differences between adjacent ranks are small, which is intentional: RRF rewards appearing in several lists more than it rewards being first in one.

A worked example

A visitor asks: 'Do you do skin fades for kids on Saturdays?' Vector search and keyword search each return five passages. Passages are labelled A to F.

Passages A and B, found by both methods, top the ranking. F is not first in either list but appears in both, so it scores higher than C, D or E, which each appear in only one. This is the behaviour you want: agreement between two very different retrieval methods is a strong signal of relevance.

What the constant k does

The constant controls how quickly the reward falls with rank. A small k, such as 1 or 10, makes the top ranks count far more than lower ranks. A large k, such as 60, flattens the curve, so a passage that is ranked tenth in two lists can beat one ranked first in only one. The value 60 comes from the original research and is a widely used default because it performs well across many datasets. It is a good place to start and rarely needs tuning.

Weighting the lists

Plain RRF treats every list as equal. Sometimes you know that one method should count more: keyword search for a product catalogue full of codes, vector search for conversational FAQs. A weighted variant multiplies each list's contribution by a weight, for example 1.0 for vectors and 0.6 for keywords. Start with equal weights, and only add weights if an evaluation on your own questions shows a benefit. Some systems also add a small bonus for the vector similarity score itself, as a tie-breaker, without letting scores dominate.

Why it works so well in practice

• Scale independence: it does not care what the scores mean.
• Robustness: an odd score in one list cannot swamp the rest.
• Simplicity: a few lines of code, with one parameter.
• Fusion of any number of lists: you can add a third retriever, such as a title match, without redesign.
• Speed: the arithmetic is trivial next to the searches.

Limits of RRF

• It ignores how much better rank 1 is than rank 2. Two nearly identical candidates and one runaway winner look the same.
• It cannot rescue a list that does not contain the right passage at all.
• Candidates missing from every list are invisible; retrieval depth matters, so take at least 15 to 25 from each method.
• It does not judge relevance itself; a reranker can do that as a second step.

These are reasons to see RRF as the merge step in a pipeline, not a complete solution. See document chunking strategies for the step before, and reranking below for the step after.

Reranking after fusion

A common pipeline retrieves 20 to 30 candidates with each method, merges them with RRF to a shortlist of 10 to 20, then reranks the shortlist with a model that reads the question and each passage together, and finally passes the top few to the language model. Reranking costs more per query but only touches a small set, and it can correct cases where the fusion order was slightly off. Crescelo's retrieval combines vector and keyword search, merges with reciprocal rank fusion, and applies a lighter reranking step, with an optional cross-encoder for higher accuracy.

How to test that fusion helps on your data

1. Collect 30 to 50 real questions and note which passage should answer each.
2. Run three retrievals: vector only, keyword only and RRF.
3. For each question, check whether the right passage is in the top 3 and top 5.
4. Compute hit rate and mean reciprocal rank for each method.
5. Look at the questions where RRF lost to a single method and see why.
6. Try k = 20, 60 and 100 and one weighting, and keep changes only if they help consistently.

On a small English test set of our own, hybrid retrieval with fusion put the needed passage in the top five for about 95 percent of questions. Your numbers will differ with your content, which is why testing on your data matters. See benchmarking RAG retrieval for business.

Implementation notes for developers

• Fuse by a stable passage identifier so duplicates merge.
• Keep ranks 1-based and be consistent.
• Break ties deterministically, for example by the better vector similarity.
• Return each passage's per-method rank and score for debugging.
• Do the fusion inside the database if you can, to save round trips, or in application code for flexibility.
• Cache repeated queries; retrieval results for the same question rarely change.

Frequently asked questions

See how retrieval feeds answers in the AI assistant, try grounded answers in the playground and read why chatbots make things up.

Further reading

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al.): The original research paper behind retrieval-augmented generation.
• Google Search Central: creating helpful, people-first content: What Google looks for in useful pages.