Home / Hybrid search / Reciprocal Rank Fusion (RRF) Explained, and Why k=60

Reciprocal Rank Fusion (RRF) Explained, and Why k=60

Reciprocal rank fusion (RRF) is a method for merging several ranked result lists into one. Each document scores 1 divided by (k plus its rank) in every list, and the scores are added up. It uses only positions, never the raw scores, so it can combine BM25 and vector results whose scores live on different scales. Cormack, Clarke, and Buettcher introduced it in 2009 and fixed k at 60 after a pilot study. Their own data shows that value was near-optimal but not critical: retrieval quality barely changed between k = 30 and k = 100. RRF is the standard fusion method in Elasticsearch and many hybrid search systems. Weaviate offers it as ranked fusion, though its default is relative score fusion, which Weaviate’s own benchmark found recovered about 6% more relevant results.

What is reciprocal rank fusion?

Reciprocal rank fusion is a rank aggregation method that combines result lists from different retrievers by rewarding documents that rank highly in any of them. “Reciprocal” refers to taking 1 over the rank, so first place counts most.

The problem it solves is common in hybrid search. A BM25 keyword search returns scores like 5.0 or 12.7. A vector search returns cosine distances like 0.18. The two cannot simply be added, because they measure different things on different scales. RRF sidesteps the issue by looking only at each document’s position in each list.

The idea comes from Gordon Cormack and Charles Clarke of the University of Waterloo and Stefan Buettcher of Google. Their 2009 SIGIR paper is titled “Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods.” They found that this simple formula beat both established fusion methods and the best individual systems they combined. Today RRF appears in search engines, vector databases, and RAG pipelines wherever several retrievers must agree on one list. The formula is short.

How does the reciprocal rank fusion formula work?

The reciprocal rank fusion formula works by summing, over every result list, 1 divided by k plus the document’s rank in that list. In the paper’s notation:

RRF_score(d) = sum over ranked lists r of  1 / (k + r(d))

r(d) = position of document d in list r (1 = first)
k    = a constant, 60 in the original paper

Two design choices shape the result. The reciprocal makes scores fall quickly at the top of a list and slowly further down. The paper’s authors chose it because highly ranked documents matter more, but lower-ranked documents should not count for nothing, as they would with an exponential decay.

The constant k softens the top of each list. Without it, first place scores 1 and second place 0.5, so a single list could dominate. With k = 60, first place scores 1/61 and second place 1/62, which are close. The paper explains that k mitigates the impact of high rankings by outlier systems. A document then needs support from several lists, or a high place in one, to rise.

A document missing from a list simply gets nothing from that list. Rank numbering varies by engine: Weaviate’s ranked fusion uses 1/(rank + 60) with ranks counted from 0, while Elasticsearch counts the first result as rank 1. The ordering is effectively the same; only the absolute scores shift. Working through a case shows how.

How do you calculate reciprocal rank fusion by hand?

You calculate reciprocal rank fusion by writing down each document’s rank in every list, computing 1 over (k plus rank) for each, and adding the values per document. We worked through the five-document case from Weaviate’s documentation.

A keyword search ranks five documents in the order 1, 0, 2, 4, 3. A vector search ranks them 2, 4, 0, 1, 3. With k = 60 and ranks starting at 1:

Document 2 wins because it is first in one list and third in the other. Document 1 is first for keywords but only fourth for vectors, so it lands second. Notice how close the scores are. With k = 60, RRF rewards consistent placement more than any single first place.

The same calculation takes a few lines of Python, which is all an RRF calculator needs:

def rrf(ranked_lists, k=60, weights=None):
    weights = weights or [1.0] * len(ranked_lists)
    scores = {}
    for ranking, w in zip(ranked_lists, weights):
        for rank, doc in enumerate(ranking, start=1):
            scores[doc] = scores.get(doc, 0.0) + w / (k + rank)
    return sorted(scores.items(), key=lambda kv: kv[1], reverse=True)

keyword = ["1", "0", "2", "4", "3"]
vector  = ["2", "4", "0", "1", "3"]
print(rrf([keyword, vector]))   # [('2', 0.0323), ('1', 0.0320), ('0', 0.0320), ...]

The function also accepts weights, which matter later. The obvious next question is where 60 came from.

Why is k set to 60 in reciprocal rank fusion?

k is set to 60 in reciprocal rank fusion because the original authors fixed it at 60 during a pilot study, where it performed near-optimally, and then kept it unchanged for all later tests. It was not derived from theory.

The paper says so directly: k = 60 was fixed during a pilot investigation and not altered during subsequent validation. The pilot fused 30 configurations of the Wumpus search engine on TREC topics. Its Table 1 reports mean average precision, or MAP, for different values of k:

The numbers explain the folklore. Quality rises from k = 0 (MAP 0.2072) to a plateau around k = 50 to 90, peaking at 0.2147 for k = 80. It dips only at the extreme of k = 500 (0.2098). The authors concluded that k = 60 was near-optimal but that the choice was not critical. Every tested value also beat the best single system, at 0.2016, and both rival fusion methods.

Engines have kept 60 as a default. Weaviate’s ranked fusion uses 60, and Elasticsearch’s rank_constant defaults to 60. Not every engine agrees: Qdrant’s documentation sets its RRF constant to 2 by default. A small k makes the top of each list count more; a large k spreads credit further down. The plateau suggests most values between 30 and 100 will behave alike. How well the method works overall is the more important question.

How well does reciprocal rank fusion perform?

Reciprocal rank fusion performed better than Condorcet fusion, CombMNZ, and the best individual system by 4% to 5% on average in its original paper. The results held across several TREC collections.

The authors fused real TREC submissions for the TREC 3, TREC 5, and TREC 9 ad hoc tasks and the 2004 Robust track. RRF’s MAP beat Condorcet fusion in every case and CombMNZ in all but one. It also beat the best individual run, except on TREC 9, where the best run used a human in the loop. A sign test showed the differences were statistically significant.

They also used RRF to combine learning-to-rank methods on the LETOR 3 dataset. The fused result beat each individual method and, by the authors’ account, any previously reported result on that benchmark. Their explanation is that RRF harnesses diversity: one or two systems ranking a document highly can lift it, while Condorcet’s majority voting tends to favor documents that many systems rank moderately.

Two cautions keep this in proportion. The experiments fused many systems, often 30, while hybrid search usually fuses two. And newer fusion methods have since been proposed, as covered further on. Still, RRF’s mix of simplicity and robustness explains why it became a default. One common tweak adds weights.

How does weighted reciprocal rank fusion change results?

Weighted reciprocal rank fusion multiplies each list’s contribution by a weight, so one retriever, such as keyword search, can count more than another. Even small weights can change the top result.

In the worked example, document 2 won with equal weights. Doubling the keyword list’s weight changes that. With weight 2 for keywords and 1 for vectors, document 1, the top keyword match, scores 0.04841 and moves to first place. Document 2 drops to second with 0.04814.

Weights suit collections where one signal is more reliable, such as product catalogs where part numbers matter. They also undo part of RRF’s appeal, since weights need tuning. Elastic’s reference stresses that each child retriever carries equal weight in its standard RRF. In Weaviate, the alpha parameter plays the weighting role for both fusion methods: 0 is pure keyword, 1 is pure vector. Balancing keyword and vector scores covers tuning. Weighting is one answer to RRF’s main limitation; score-based fusion is another.

How does RRF compare with relative score fusion and DBSF?

RRF compares with relative score fusion and DBSF as the rank-only option: RRF discards score sizes, relative score fusion rescales scores between 0 and 1, and DBSF rescales them using their statistical spread. Each makes a different trade-off.

Weaviate’s documentation shows the difference on the same five documents. Keyword scores were 5 for document 1 and 2.6 or less for the rest, a clear winner. Vector scores were nearly tied for the top four. Ranked fusion, which is RRF, put document 2 first. Relative score fusion put document 1 first, because its large keyword lead survived normalization.

Weaviate made relative score fusion its default in version 1.24. Its engineering team reports that on the FIQA dataset, relative score fusion gave about 6% better recall than ranked fusion in internal benchmarks. It also works with autocut, which needs meaningful score gaps. Qdrant offers DBSF from version 1.11, describing it as normalizing each score with the mean and three standard deviations as endpoints. Relative score fusion and score fusion methods go deeper. A separate confusion is whether RRF reranks at all.

Is reciprocal rank fusion a reranker like a cross-encoder?

Reciprocal rank fusion is not a reranker in the usual sense; it merges existing rankings by position, while a reranker such as a cross-encoder reads the query and each document together and scores relevance afresh. They solve different problems and often work together.

RRF never looks at content. It cannot tell that a document mentions the answer; it only knows where each retriever placed it. That makes it extremely fast and free of models. A cross-encoder, by contrast, runs a transformer over every query and document pair. It is far more accurate at judging relevance but much slower, so it is applied only to a short candidate list. Bi-encoders versus cross-encoders explains the trade-off.

The common pipeline uses both. Retrieve candidates with BM25 and vector search, fuse them with RRF, then rerank the fused top 50 or 100 with a cross-encoder. The pgvector documentation, for instance, suggests either RRF or a cross-encoder to combine results. What is reranking covers the second stage.

RRF is also unrelated to mean reciprocal rank, or MRR, despite the similar name. MRR is an evaluation metric: the average of 1 over the rank of the first relevant result across queries. RRF combines rankings; MRR measures them. Mean reciprocal rank explains the metric. Using RRF in Weaviate takes one parameter.

How do you use reciprocal rank fusion in Weaviate?

You use reciprocal rank fusion in Weaviate by running a hybrid query with fusion_type set to ranked fusion; the default is relative score fusion. The alpha parameter still sets the balance between keyword and vector search.

import weaviate
from weaviate.classes.query import HybridFusion, MetadataQuery

client = weaviate.connect_to_local()
docs = client.collections.use("Document")

for fusion in (HybridFusion.RANKED, HybridFusion.RELATIVE_SCORE):
    response = docs.query.hybrid(
        query="reset two-factor authentication",
        alpha=0.5,                 # equal weight to keyword and vector
        fusion_type=fusion,        # RANKED is Weaviate's RRF-style fusion
        limit=5,
        return_metadata=MetadataQuery(score=True),
    )
    print(fusion, [o.properties["title"] for o in response.objects])

client.close()

Comparing both fusion types on real queries is the quickest way to choose. Weaviate Academy suggests ranked fusion when you want to ignore score magnitudes entirely, for example when one search produces wildly different score ranges from the other. Relative score fusion suits most other cases and is required for autocut with hybrid search. The same choice comes up in RAG pipelines.

When should you use reciprocal rank fusion in RAG?

You should use reciprocal rank fusion in RAG when several retrievers or query variants each return candidates and you need one list to pass to the language model. In AI applications, that is the main use of RRF.

Three RAG patterns rely on it. Hybrid retrieval fuses a keyword and a vector search, as described throughout. Multi-query retrieval asks a language model to rewrite the question several ways, searches with each, and fuses the lists, as in multi-query retrieval. Multi-source retrieval fuses results from different collections or indexes. In each case, the retrievers’ scores are not comparable, which is exactly where rank-only fusion helps.

A few practical points apply. Keep enough candidates per list, such as 50, so documents that appear in several lists can surface. Fuse before reranking, not after. And measure on your own questions: if one retriever is clearly better, a weighted RRF or score-based fusion may beat plain RRF. Hybrid search for RAG, how hybrid search works, and score normalization cover the surrounding choices.

Reciprocal rank fusion merges ranked lists by summing 1 over (k plus rank), so it combines retrievers whose scores cannot be compared. Its k = 60 default comes from a 2009 pilot where quality was nearly flat between k = 30 and 100, and the method beat rival fusion methods by 4% to 5%. RRF ignores score gaps, which is why Weaviate defaults to relative score fusion and offers ranked fusion as an option. The practical step is to try both fusion types on your own queries, keep RRF where score scales disagree, and add a cross-encoder reranker after fusion when precision matters.