What Is Hybrid Search?
Hybrid search runs a lexical query and a vector query over the same corpus and combines the two ranked lists into one. The interesting part is not the retrieval, which is two ordinary retrievals; it is the combination, because the two lists arrive carrying scores that share no scale and no meaning.
Why the two lists cannot simply be added together
A lexical score and a vector score are different quantities. A term-weighting score is unbounded above, is computed partly from statistics of the collection, and is dependable only for ordering within one query's results. A cosine similarity sits inside a fixed range and is comparable at least in the weak sense that its endpoints always mean the same thing. Adding one to the other, or averaging them, produces a number whose behaviour shifts as the corpus grows, because one half drifts with the collection and the other does not.
The first family of answers normalises before combining. Each list is rescaled — most simply by mapping its own smallest and largest score onto a fixed range — and the rescaled values are summed, usually with a weight per channel. This keeps the margin information the raw scores carried, and it introduces a dependency that is easy to miss: a rescaled score depends on which other documents came back alongside it, so one unrelated candidate entering or leaving the list changes the score of everything else in it.
The second family ignores the scores entirely and fuses on rank. Reciprocal rank fusion gives each document, in each list where it appears, a contribution of one divided by a constant plus its rank, and sums those contributions across the lists. A document ranked well by both channels beats one ranked well by either. The constant damps the advantage of the very top position, so a first place in one list does not automatically outrank a strong showing in both. Nothing needs normalising, since ranks are already on the same scale, and that is what makes the method a common default; the price is that everything the scores knew about margin is thrown away, and a runaway first place looks identical to a narrow one.
| Fusion method | What it does, and what it costs |
|---|---|
| Normalised score sum | Rescales each list, then adds with a weight per channel. Keeps margins; makes every score depend on the rest of the list. |
| Reciprocal rank fusion | Adds one over a constant plus rank, across lists. Needs no normalisation; discards margins. |
| Channel weighting | A multiplier per channel, applied under either method. Tuned against a query mix, not against a corpus. |
| Fuse, then rescore | Fuses to a shortlist, then reorders it with a scorer that reads query and passage together. |
| No fusion at all | Interleave the two lists. Simple, and it dilutes both channels instead of combining their evidence. |
Whichever rule is chosen, the gain hybrid retrieval reliably delivers is on the candidate set rather than on the order. Two channels that fail on different queries return, between them, a shortlist containing the answer more often than either does alone. Getting that answer to the top of the shortlist is a separate problem, and it is normally handed to a separate stage.
What has to be true before a fusion means anything
The two channels must be searching the same things, identified the same way. If the lexical index holds whole documents while the vector store holds passages, the two lists are not about comparable units and a fusion over them silently mixes granularities. If the two disagree about identifiers, one document arrives as two entries and collects two partial scores instead of one combined one, which is the exact failure a fusion is supposed to prevent.
Both channels also have to be worth fusing. A weak lexical configuration — the wrong analysis chain, a field that was never indexed — does not sit neutrally in a fusion; it contributes rankings that push good candidates down. The same holds on the other side for an embedding space that suits the corpus poorly. A fusion rule combines evidence, and it combines wrong evidence exactly as faithfully as right evidence.
The weighting between channels is a property of the queries rather than of the corpus, which is why it cannot be inherited from anyone else. A workload of identifiers, error strings and part numbers wants the lexical side to dominate; a workload of descriptive questions wants the opposite. A single weight fixed over a mixed workload is a compromise on every query in it, and systems with a clearly bimodal mix sometimes route the query to one channel rather than fusing at all.
How the Registry classifies a two-channel retrieval task
Retrieving candidates by keyword match and by vector distance and fusing the two lists is filed as information retrieval in this registry's classification, and the fusion step does not disturb that. A fusion rule is arithmetic over positions in lists: it can promote a document and it cannot introduce one, so the result stays a subset of what the corpus already held.
The Registry's canonical brief for this entry is filed as:
Retrieve candidates by keyword match and by vector distance, then fuse the two ranked lists into one.
Submitted for assessment it is
classified as Information retrieval, and its wording is hashed once — to
ec83fde7a4de10fb…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/retrieval.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about hybrid search
No fusion rule is recommended here, no channel weighting is suggested, and no retrieval quality is published for any combination of the two, because this registry has measured none of it. The canonical brief above fixes the operation and not the query mix, and it is the query mix that decides which weighting is right.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about hybrid search
- What is hybrid search?
- Hybrid search runs a keyword query and a vector query over the same corpus and merges the two ranked lists into a single result. It exists because the two retrieval methods fail on different kinds of query, so the union of their candidates covers more of a workload than either one alone.
- What is reciprocal rank fusion?
- It is a fusion rule that scores each document by one divided by a constant plus its rank in each list, and sums those contributions across the lists. Because it reads ranks rather than scores, it needs no normalisation between lists whose scores sit on unrelated scales.
- Why not simply add the keyword score and the vector score?
- They are not on a common scale. A term-weighting score is unbounded and depends on collection statistics that shift as documents are indexed; a similarity is bounded and does not. A sum of the two is dominated by whichever happens to be larger, and the balance drifts with the corpus.
- Does hybrid search need a reranker?
- It does not require one, and the two solve different problems. Fusion decides which candidates reach the shortlist; a reranking pass decides the order within it. A system missing answers has a candidate problem, and a system whose answers arrive at position nine has an ordering problem.
- How should the two channels be weighted?
- By the query mix the system actually receives, measured on that system. Exact identifiers and error strings favour the lexical channel; descriptive questions favour the vector channel. No general weighting is published here, because no such measurement has been taken at this registry.
Related entries
Order an assessment for information retrieval tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.