Hybrid Search
Hybrid search is retrieval that runs two different matching methods over the same collection — normally a term-based one and a vector-based one — and merges their separate ranked lists into a single result set.
It exists because the two methods fail in complementary ways. Term matching cannot find a passage that shares no words with the query. Vector matching cannot reliably distinguish one exact identifier from a similar-looking one. Neither weakness is fixable within the method, so both methods are run and their outputs combined.
The defining work is the merge. Two lists arrive with scores on incompatible scales: keyword scores are unbounded and depend on collection statistics, embedding similarities are bounded and depend on the model. Adding them directly is meaningless, so the merge either normalises the scores first or ignores them and uses rank positions.
“Hybrid” says only that more than one signal was used. It does not specify which signals, how they were weighted, or where the combination happened, and those details determine the behaviour entirely.
In practice
Both retrievers query the same corpus independently, each returning its own candidates. The merge then produces one ordered list. Two approaches dominate.
Rank-based fusion discards the scores and combines by position, giving each document credit for placing highly in either list and extra credit for appearing in both. It needs no calibration, which is its main appeal — nothing has to be known about either scoring scale.
Weighted score combination normalises each list’s scores to a common range and blends them with a weight controlling the balance. It preserves the strength of a match rather than just its position, at the cost of requiring a normalisation that holds up across queries.
A third arrangement is sometimes also called hybrid: run one method first as a filter and the other to rank what survives. This is a pipeline rather than a fusion, and the first stage’s misses cannot be recovered.
Whichever is used, an important property is that hybrid search increases the candidate pool. A document need only be found by one retriever to enter the merged list, so recall is at least that of the better single method on any given query. The cost is that the merged list contains more marginal results, which is why a reranking pass often follows.
Operationally it means maintaining two indexes over one corpus, kept in step. A document added to one and not the other is retrievable by one method only, and the resulting inconsistency is difficult to notice from query results.
Commonly confused with
Semantic search. One of the two halves. A system doing only vector retrieval is not hybrid, however the interface describes it. See semantic search.
Reranking. A second pass that reorders one candidate list with a more accurate model. Hybrid search combines two lists produced by different methods; reranking rescores a list already produced. They are often used together, and the fusion step is sometimes loosely called reranking, which blurs a real distinction. See reranking.
Filtering. Restricting results by a metadata condition — date, source, permission. Filtering removes candidates by a rule; hybrid search adds candidates from a second matching method. Both are commonly enabled at once and both are described as “combining signals.”
Multi-vector retrieval. Storing several vectors per document, or querying several representations from one model. Still a single method, and not hybrid in this sense.
Hybrid deployment. In vendor material, “hybrid” often means an infrastructure arrangement spanning local and cloud. Unrelated, and the collision appears in the same documentation sets.
Usage notes
The weighting is a real parameter and frequently left at a default. How much the keyword side counts relative to the vector side changes results substantially, and the appropriate balance depends on the corpus — identifier-heavy collections want more weight on terms, prose-heavy ones less. A default is a starting point, not a setting.
Some products implement it inside the engine and some expect the application to do it. When a single API call accepts a query and returns fused results, the normalisation and weighting are the vendor’s choices and may be undocumented. When two calls are made and merged in application code, they are the application’s choices. The word describes both.
Sparse-plus-dense is the usual pairing but not the only one. Two embedding models, or a general and a domain-specific retriever, also make a hybrid. What matters is that the signals fail differently; two similar retrievers merged add cost without adding coverage.
It does not remove the need for exact-match handling. A hybrid system still tokenises and normalises text on the keyword side, and a term that fails to match there is missing from that list regardless of fusion. See BM25.