Why rank fusion is safer than score fusion

A dense retriever typically ranks items by vector similarity, while BM25 ranks documents using term statistics and query terms. Even when both systems return numeric scores, those numbers do not necessarily have the same range, direction, or meaning. Adding them directly can make one retriever dominate simply because its score scale is larger.

RRF avoids score normalization. It rewards an item for appearing near the top of either result list, and gives additional credit when the item is highly ranked by both. This is especially helpful when a query contains a product name, identifier, or phrase that BM25 can match exactly alongside an intent that dense retrieval can interpret semantically.

  • Dense retrieval can surface semantically related wording.
  • BM25 can preserve exact tokens, rare terms, and identifiers.
  • RRF consumes ordered lists, not comparable raw scores.
  • Fusion can be implemented in the application layer that calls retrieval APIs.

Apply reciprocal rank fusion to the two result lists

For each query, request a candidate list from dense retrieval and another from BM25. Use a stable document or chunk identifier to join the results. For every occurrence of an item at one-based rank r, add 1 divided by k plus r to that item's fused score: RRF(d) = Σ 1 / (k + rank_i(d)). The sum runs across the result lists in which the item appears.

The constant k reduces the gap between adjacent ranks near the top of a list. A commonly used starting value is 60, but it is a tuning parameter rather than a universal rule. Keep the candidate depth and k explicit in configuration so that changes are reviewable and can be evaluated against representative queries.

  • Fetch the same candidate depth from dense and sparse retrieval to start.
  • Deduplicate candidates by a stable ID before producing the final ranking.
  • Use one-based ranks consistently; rank 1 is the top result.
  • Break equal fused scores deterministically, such as by best individual rank and then ID.

Operate fusion as a retrieval boundary

Treat hybrid fusion as a small, observable boundary between retrieval and downstream generation or application logic. Record the query class, the IDs and ranks returned by each retriever, and the final fused order. These records make it possible to investigate why an exact-match document rose or fell without relying on opaque combined scores.

Start with a query set that reflects real traffic: short natural-language questions, quoted phrases, identifiers, abbreviations, and queries with multiple constraints. Inspect not only whether a desired document appears, but where it lands in each list and in the fused ranking. If one source is absent or errors, define the fallback deliberately: return the available ranked list rather than silently inventing a combined score.

  • Evaluate dense-only, BM25-only, and fused rankings on the same query set.
  • Log source rank alongside the fused score for each returned item.
  • Watch for duplicate chunks or multiple IDs representing the same underlying document.
  • Version fusion settings so ranking changes can be traced to a configuration update.