A retrieval-augmented generation (RAG) system often has more than one useful way to find evidence. Keyword retrieval is good at exact names, identifiers, and rare terms. Embedding retrieval can find passages that express the same idea with different wording. Using both can improve candidate coverage, but it creates a practical problem: their scores usually do not mean the same thing.

A keyword score of 12.4 and a cosine similarity of 0.81 cannot be safely averaged just because both are numbers. Their scales, distributions, and even direction conventions depend on the retrieval methods and implementations.

Reciprocal rank fusion (RRF) avoids that score-comparison problem. It combines ranked lists using only the position of each document in each list. This article builds RRF from a small example, explains what its formula rewards, and shows where it fits in a practical RAG retrieval pipeline.

Start with two useful but different rankings

Suppose a developer asks an internal support assistant:

Why does error E104 appear after rotating a service token?

A keyword retriever returns:

rank 1: A - E104 error reference
rank 2: B - service token rotation procedure
rank 3: C - E104 troubleshooting checklist
rank 4: D - authentication overview

An embedding retriever returns:

rank 1: B - service token rotation procedure
rank 2: E - cached credentials after token replacement
rank 3: C - E104 troubleshooting checklist
rank 4: F - credential propagation delays

Both lists contain useful evidence. The keyword retriever puts the exact error reference first. The embedding retriever surfaces a passage about stale credentials even though it may not contain the literal string E104.

A simple system could choose one retriever, but that throws away complementary evidence. It could also concatenate both lists, but then duplicates and ordering become arbitrary. RRF gives the system one combined ranking without pretending that the original retrieval scores are directly comparable.

Think in ranks instead of raw scores

For a document d, standard RRF assigns the score

RRF(d) = sum over lists of 1 / (k + rank(d))

where:

  • rank(d) is the document’s one-based position in a ranked list;
  • a document absent from a list contributes nothing from that list;
  • k is a positive constant that controls how sharply the contribution falls with rank.

The important idea is simpler than the notation: a high position contributes more than a low position, and appearing near the top of several lists accumulates evidence.

The constant k should be treated as part of the retrieval configuration, not as a universal value. Larger values make differences between adjacent ranks less pronounced. Smaller values make the very top positions matter more strongly. If a library exposes RRF with a fixed or default constant, check that implementation rather than assuming a particular value.

Work through the smallest useful example

Use k = 10 for a compact teaching example. Consider documents A, B, and C from the two rankings.

Document A is rank 1 in keyword retrieval and absent from embedding retrieval:

RRF(A) = 1 / (10 + 1)
       = 1 / 11
       ≈ 0.0909

Document B is rank 2 in keyword retrieval and rank 1 in embedding retrieval:

RRF(B) = 1 / 12 + 1 / 11
       ≈ 0.0833 + 0.0909
       ≈ 0.1742

Document C is rank 3 in both lists:

RRF(C) = 1 / 13 + 1 / 13
       ≈ 0.1538

So the fused order among these three is:

B > C > A

This result demonstrates the central behavior of RRF. A document that performs well across multiple retrieval methods can outrank a document that is excellent in only one list. That is useful when the retrievers capture different signals and agreement between them is meaningful.

Notice what RRF did not use. It did not need the keyword score, the embedding similarity, or a conversion between them. It needed only document identity and rank.

Build fusion as a separate retrieval stage

A practical hybrid retrieval pipeline can be expressed as:

query
  -> keyword retrieval ----\
                           -> RRF -> top candidates -> optional reranker -> context
  -> embedding retrieval --/

Keeping fusion as a separate stage makes the responsibilities clear.

Each retriever first produces a ranked candidate list. RRF then combines those lists. A later reranker, if used, can inspect the query and candidate text more deeply before the final context is assembled.

RRF and reranking therefore solve different problems. RRF combines evidence from multiple rankings cheaply. A reranker estimates relevance again, often with a model that jointly considers the query and each candidate. They can be used together rather than treated as alternatives.

A minimal implementation is straightforward:

scores = empty map

for each ranked_list:
    for rank, document in ranked_list starting at 1:
        scores[document.id] += 1 / (k + rank)

return documents sorted by scores descending

The document ID matters. The same passage must resolve to the same identity across retrievers, or the fusion stage will treat duplicate results as different documents and lose the benefit of agreement.

Retrieve enough candidates before fusing

RRF can only combine documents that the component retrievers return. If each retriever returns only two candidates, a highly useful document ranked third in both lists never reaches fusion.

That creates an important distinction between two limits:

retrieval depth: how many candidates each retriever contributes
final depth:     how many fused candidates continue downstream

For example, a system might retrieve 30 candidates from each of two retrievers, fuse the union, then pass the top 15 fused candidates to a reranker. The final context may contain only 5 passages.

Those numbers are application-specific. Increasing retrieval depth can improve the chance that useful evidence reaches fusion, but it also increases retrieval, deduplication, fusion, and possibly reranking work. Measure recall and latency rather than increasing the depth without a target.

Understand what the fusion constant changes

The constant k smooths the effect of rank.

With k = 10:

rank 1 contribution = 1/11 ≈ 0.0909
rank 10 contribution = 1/20 = 0.0500

With k = 60:

rank 1 contribution = 1/61 ≈ 0.0164
rank 10 contribution = 1/70 ≈ 0.0143

The absolute score values are not important by themselves. The comparison shows that a larger k compresses the difference between early ranks. As a result, repeated presence across lists can matter relatively more than a small difference in position near the top.

Do not tune k by looking only at a few attractive examples. Evaluate it on representative retrieval queries using metrics that match the stage you care about, such as recall at a candidate cutoff or ranking metrics when graded relevance judgments are available.

Decide whether every retriever should count equally

Basic RRF gives each ranked list the same contribution. That is a reasonable starting point when the retrievers are similarly trustworthy, but it is not automatically appropriate.

Imagine a documentation search system where exact product codes are critical. Keyword retrieval may be especially reliable for queries containing identifiers, while semantic retrieval may be more useful for natural-language descriptions.

One extension is weighted reciprocal rank fusion:

score(d) = sum over lists of weight_i / (k + rank_i(d))

Weights can express that one ranking source should influence the fused order more strongly. However, weights add parameters that need evidence. A weight chosen from intuition can make the system look configurable without making it better.

Another option is query-dependent routing: use different retrieval strategies for different query types. That can be useful when query classes are reliably detectable, but it is more complex than static fusion and introduces another decision that must be evaluated.

Start with equal contributions unless measurements show a consistent reason not to.

Deduplicate at the right level

Hybrid retrieval often exposes duplicate or near-duplicate content. Exact identity is the easy case: both retrievers return the same chunk ID, so RRF naturally combines their contributions.

Near-duplicates are harder. Two chunks may contain nearly identical text but have different IDs because they came from overlapping windows, duplicated documents, or separate versions of a page. RRF will treat them as separate candidates.

This can waste downstream context even if the fused ranking itself is correct. Depending on the corpus, useful controls include:

  • stable canonical document and chunk identifiers;
  • removal of exact duplicate content during indexing;
  • version filtering so obsolete and current copies do not compete;
  • a later diversity step when several highly relevant candidates repeat the same evidence.

Do not merge merely similar passages blindly. Two passages can look alike while differing in a condition, version, limit, or exception that matters to the answer.

Know what RRF does not solve

RRF is a ranking-combination method, not a relevance guarantee.

If every component retriever misses the necessary evidence, fusion cannot recover it. If one retriever consistently returns misleading candidates, its rankings can add noise. If the corpus contains stale or incorrect documents, RRF does not determine which source is authoritative.

It also discards information contained in score magnitudes. Suppose a vector retriever gives one document a similarity far above every other result. RRF sees only that it is rank 1. In another query where the first and second results are almost tied, rank 1 receives the same rank-based contribution. This loss of magnitude information is the price of avoiding cross-retriever score calibration.

When scores have a meaningful, stable interpretation and can be calibrated onto a comparable scale, score-level fusion may use information that RRF ignores. Achieving that comparability reliably can require additional evaluation and maintenance, especially when retrievers or embedding models change.

Avoid common implementation mistakes

Fusing positions after truncating too aggressively

Very shallow component lists can make RRF unstable because useful consensus candidates never enter the union. Choose retrieval depth based on measured candidate recall and operational cost.

Treating RRF scores as probabilities

An RRF score is a ranking score. A value such as 0.08 does not mean an 8% probability of relevance. Its scale depends on the number of lists, their weights, the constant, and the ranks present.

Using inconsistent document identities

If keyword retrieval identifies a passage as doc-7#chunk-2 while vector retrieval represents the same passage with an unrelated generated ID, the contributions cannot combine. Normalize identity before fusion.

Assuming agreement proves correctness

Two retrievers can agree because they share the same corpus bias or both favor a repeated but outdated passage. Agreement is useful ranking evidence, not independent verification of truth.

Comparing RRF only with one weak baseline

A hybrid system should be compared with its individual retrievers as well as simple alternatives. If keyword retrieval alone already satisfies the application, adding vector retrieval and fusion increases complexity and cost without a demonstrated benefit.

Evaluate retrieval separately from generation

End-to-end answer quality matters, but it can hide where a RAG system fails. Evaluate the retrieval stage directly before attributing improvements or regressions to the language model.

A useful evaluation set contains queries and the passages or documents that provide the evidence needed to answer them. Then compare configurations such as:

keyword only
embedding only
RRF(keyword, embedding)
RRF -> reranker

Measure whether relevant evidence appears within the candidate budget that reaches the next stage. Also record latency and resource cost. A fused system that improves retrieval recall but doubles an already tight latency budget may still be the wrong production choice.

After retrieval is healthy, evaluate the complete RAG pipeline for answer correctness, grounding, citation behavior, and any application-specific requirements. Retrieval success is necessary for many RAG questions, but it does not guarantee that the generator will use the evidence correctly.

When RRF is a good fit

RRF is particularly useful when you have multiple ranked retrieval methods that capture complementary signals and their raw scores are not naturally comparable. Keyword plus embedding retrieval is a common example, but the method is not limited to two lists or those specific retrievers.

A simpler approach can be better when one retriever already performs well enough, when latency or operational simplicity dominates, or when the second ranking adds little independent signal. Score fusion may be preferable when scores are demonstrably calibrated and their magnitudes contain useful information that rank-only fusion would discard.

The practical mental model is: let each retriever rank in its own language, then combine their positions instead of forcing their scores onto an artificial common scale. RRF is valuable because it makes that combination simple, interpretable, and easy to evaluate as one stage of a larger retrieval system.

Artificial Intelligence RAG Retrieval Embeddings