Rank fusion: merging a keyword list and a vector list into one order
In short
Rank fusion merges 2 ranked result lists — usually one from keyword matching and one from vector similarity — by combining the positions a document occupies in each, not its scores. Position 3 means the same thing in both lists, while a lexical relevance score and a vector distance share no unit, no bounded range and no stable meaning from one query to the next.
Key takeaways
- Fusion combines positions, not scores. That is what makes it work without calibrating anything.
- A keyword score and a vector distance have no common unit and no stable range across queries.
- Documents that both retrievers found rise to the top. Agreement between 2 methods is the signal.
- The damping constant decides how much a first place beats a third. It is the one knob worth reading.
- Fusion cannot promote a document neither list returned. It inherits both lists' recall ceilings.
Rank fusion is how 2 retrievers become one result set. Run a keyword search and a vector search over the same corpus and you get 2 ordered lists that overlap partially and disagree about the order of what they share. Fusion produces one ordering by scoring each document on where it appeared in each list, then sorting by that combined figure. The retrievers' own scores are discarded, and that discarding is the point rather than a shortcut: it is what lets you add a second retriever without a calibration project.
Why the two scores cannot be put on one scale
A lexical relevance score is unbounded and corpus-dependent: it rises with term rarity and length normalisation, so 14 on one query and 14 on another are unrelated quantities. A vector similarity is bounded, typically between -1 and 1, with its useful range compressed into a narrow band near the top — the gap between an excellent match and a mediocre one might be 0.04. Neither is a probability, so a weighted sum of the raw numbers is arithmetic without meaning.
Min-max normalising each list per query looks like the fix and imports a new defect: it stretches whatever the list contains to fill the range, so a query where every candidate is poor still yields a top result scoring 1.0. Position survives all of this. Ranked first by the keyword arm and third by the vector arm are facts of the same kind, and they mean roughly the same thing regardless of query or corpus size.
A worked merge of two five-item lists
The standard method is reciprocal rank fusion: each list contributes 1 divided by a constant plus the document's rank, and the contributions are summed. The constant, often 60, damps the advantage of first place so a document ranked 1st in one list does not automatically beat one ranked 2nd and 3rd in both.
| Document | Keyword rank | Vector rank | Fused score | Final |
|---|---|---|---|---|
| annual-plan-terms | 2 | 1 | 0.03252 | 1 |
| billing-policy-refunds | 1 | 3 | 0.03227 | 2 |
| support-macro-refunds | 3 | 5 | 0.03126 | 3 |
| subscription-lifecycle | — | 2 | 0.01613 | 4 |
| pricing-faq | 4 | — | 0.01563 | 5 |
| renewal-email-copy | — | 4 | 0.01563 | 6 |
| cancellation-flow-spec | 5 | — | 0.01538 | 7 |
Two things read off that table. The top 3 are exactly the documents both retrievers returned, in an order neither list produced alone — agreement between 2 different methods is the signal fusion exploits. And a document found by only one arm still places, so a strong lexical hit on a part number is not discarded because the vector arm missed it.
The weight, and the one thing it cannot express
Each list can carry a multiplier, so a corpus where exact terms matter can lean on the lexical arm. Two constraints before touching it: the weight is global, applying to every query including the ones where the other arm was right, and the damping constant interacts with it, because a larger constant flattens the gaps between positions and leaves the weight dominant.
Choosing those numbers without labelled data is a procedure rather than a guess, and a page of its own: tuning the lexical and semantic blend. What a weight cannot express is per-query preference — that some questions are identifier lookups and some are conceptual — which is a routing decision made before retrieval, not a constant applied after.
What fusion cannot repair
It only reorders what the 2 lists contain, so it inherits both recall ceilings: a passage neither arm returned cannot appear, however the merge is configured. It is also not admissibility — whether a document may be seen at all is decided before either search runs, the distinction drawn in metadata filters, and the difference between filtering and ranking. A fused list is a ranking, and a ranking never excludes.
Two upstream stages change what fusion receives. If a rewrite runs first, decide which arm gets which text, because the expanded phrasing that helps the vector arm often hurts the lexical one — query rewriting before retrieval covers the trade. And a question whose second retrieval depends on the first is not a merging problem at all; see what makes a question multi-hop.
One operational note. Fusion is deterministic given 2 lists, but the vector list moves the moment the embedding model behind it moves, so a silently upgraded endpoint changes your ordering with no deployment on your side — the reason to pin, argued in alias versus pinned snapshot in production calls. Corpora mixing identifiers with prose feel it most, as in the operational document sets discussed in AI for healthcare operations. Building and running this sits with AI agents and automation; neighbouring terms are in retrieval and grounding, part of the engineering library.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is rank fusion in hybrid search?
It merges 2 ranked result lists into one order by combining each document's position in each list rather than its score. A document appearing high in both rises above one that appeared very high in a single list, and the retrievers' own scores are discarded. That is what lets a keyword arm and a vector arm combine without being calibrated against each other.
Why not just normalise the two scores and add them?
Because normalising per query stretches whatever that query returned to fill the range, so a query where every candidate is poor still produces a top result scoring 1.0. Lexical scores are unbounded while vector similarities are bounded and compressed, and neither is a probability. Positions are comparable across queries in a way the raw numbers are not.
What does the damping constant in reciprocal rank fusion do?
It controls how much a top position beats a lower one. A small constant makes first place dominant, so one confident retriever decides the result; a larger one flattens the curve, so agreement between the 2 lists matters more than either ordering. Values around 60 are a common starting point, to be tuned on your own queries rather than adopted as a default.
Can rank fusion recover a document that neither retriever returned?
No. Fusion operates only on the lists it is given, so its ceiling is the union of what the 2 arms retrieved. If a passage is missing from both, the repair is upstream — a wider candidate depth, different chunking, or an arm suited to the query type.
- hybrid search
- ranking
- retrieval
- definitions
The work behind this page
Builds from our portfolio that this page draws on.
AskVault
An AI internal knowledge-search platform that answers employee questions from your own docs — grounded in citations, with knowledge gaps surfaced and deflection tracked.
Productivity AIBrief Forge
Contract review AI for solo lawyers and small firms — extract, score, and redline contracts in minutes.
Legal TechRead next
- What a reranking stage does to a candidate listA reranker rescores a list that already exists. It reads the query and each passage together, which a stored vector cannot — and it can only ever reorder what the first stage found.definition
- Metadata filters, and the difference between filtering and rankingA filter decides which passages may compete. A boost decides how they place. Treating one as the other produces empty result sets and permission leaks.definition
- Recall@k, and why it is the number retrieval lives or dies byRecall@k is the share of questions whose answer-bearing passage made the top k. It gates everything downstream, because no reranker or prompt recovers a passage that was never fetched.definition
- Adding one new source made unrelated answers worseNothing about the old passages changed. A new source ranks moderately well on a great many queries, and a fixed top-k has to give it those slots by taking them from something else.diagnostic
- Chunk overlap: what it protects against and what it duplicatesOverlap is insurance against a chunk boundary landing in the middle of one idea. The premium is paid in duplicated candidates crowding a fixed number of prompt slots.definition
- Facts in the middle of a long context get missedHold the passage set constant, walk the answer-bearing chunk from first position to last, and measure. The shape of the resulting curve is the diagnosis, and it takes about an hour to produce.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation