Why fuse ranks instead of raw scores?

Dense and sparse systems commonly produce scores on different scales. A dense similarity score is not automatically comparable to a BM25 relevance score, even when both lists are ordered from most to least relevant.

RRF avoids assuming that the underlying scores mean the same thing. It uses each document’s position in a ranked list, rewarding documents that appear near the top of either list and giving an additional boost to documents supported by both retrievers.

  • Dense retrieval can surface semantic matches that do not share exact wording with the query.
  • BM25 can preserve precision for product names, error codes, document IDs, and quoted terms.
  • Rank-based fusion removes the need to directly normalize incomparable score scales.

Apply reciprocal rank fusion to Talqora result lists

For each user query, request a candidate list from the S3 Vectors-backed dense path and a candidate list from the Quickwit BM25-backed sparse path. Ensure that both lists return a stable shared document identifier, such as a chunk ID or source record ID.

For every unique document, calculate an RRF score by summing 1 divided by k plus its rank for each list in which it appears. The constant k reduces the difference between adjacent ranks and helps prevent a single first-place result from overwhelming the merged list.

  • Use one-based ranks: the first item in a result list has rank 1.
  • A common formula is: RRF(d) = Σ 1 / (k + rank_i(d)).
  • Choose one k value for both lists and evaluate it on representative queries.
  • Deduplicate by the shared document or chunk identifier before returning results.

Make the fusion layer observable and testable

Log the query, the top ranks from each retriever, the fused rank, and which retrieval paths contributed to each returned result. This makes it easier to distinguish a retrieval issue from a fusion issue when a result looks surprising.

Build an evaluation set containing semantic questions, exact-lookup queries, acronym-heavy queries, and queries with mixed natural language plus identifiers. Compare dense-only, sparse-only, and fused rankings using the relevance judgments available to your team rather than relying on a single query style.

  • Inspect whether useful results are found by only one retrieval path or by both.
  • Watch for duplicate chunks from the same source overwhelming the final list.
  • Keep candidate-list sizes explicit; fusion cannot recover a document neither retriever returned.
  • Use application-side metadata filters consistently across dense and sparse retrieval when the query requires them.