Hybrid Search

Hybrid search runs a lexical retriever and a dense vector retriever over the same corpus and merges their two ranked lists into one. The lexical side, usually BM25, matches literal tokens; the dense side matches meaning through embeddings; a fusion step decides the final order, most often reciprocal rank fusion, which combines documents by their rank positions instead of their raw scores.

The fusion step is where naive implementations go wrong. BM25 emits an unbounded relevance score and a vector index emits a cosine similarity between -1 and 1, so averaging the two compares incompatible scales and quietly lets one side dominate. Reciprocal rank fusion sidesteps this by discarding scores entirely and summing 1/(k + rank) across the lists, where k is a smoothing constant that Elasticsearch and several other engines default to 60. A document both retrievers rank highly rises to the top; a document only one of them found still surfaces, which is the entire point of running both.

Hybrid exists because dense retrieval has a specific, reproducible failure. Embedding models are trained to generalize across paraphrase, and that generalization is bought by discarding exact strings. Ask a dense index for an error code like E-4021 or a part number like MPX-7842X and the query vector lands in a generic neighborhood of identifier-shaped tokens, returning a confidently wrong neighbor such as MPX-7842Y. The same happens with rare proper nouns, version numbers, ticker symbols, and quoted phrases a user typed precisely because they wanted that exact string. BM25 has the mirror-image blind spot: it will not connect "automobile" to "car". The two failure modes barely overlap, which is why merged results usually beat either retriever alone on mixed query traffic rather than one method being better in general. If you want a number for your own corpus, run both retrievers over the same logged queries and compare NDCG against the merged list; public leaderboards on datasets like WANDS tell you about e-commerce product titles, not about your documents.

For product builders the decision is usually not whether to implement hybrid retrieval but whether your vendor already has. Most vector databases and search engines now ship it natively. On the web-search side, several independent APIs expose both modes: Exa offers a neural mode alongside a keyword mode and an auto setting that picks per query, Brave Search API serves a keyword index built from its own crawl that you can layer semantic ranking on top of, Seltz runs a hybrid index over its own Rust crawler, and Linkup retrieves across licensed publisher content. If your product handles part numbers, CVE identifiers, statute references, or company names that collide with common words, ask which retrieval modes an API exposes and whether you can force one per query. An API that only does neural search will fail on exactly the queries where the user is most certain they typed the right thing.

Two operational notes. Hybrid costs storage, because you maintain a lexical index alongside the vector index, and it costs a second query plus a merge, usually single-digit milliseconds next to an LLM call. Weighting is query-dependent: identifier lookups want the lexical side weighted heavily, conceptual questions want the dense side, and a fixed 50/50 split is a compromise rather than an answer. Routing by query shape beats one global setting once you have enough traffic to tell the two apart.