What Is Hybrid Search?

You search your docs for the exact error code a user pasted, and the one page that can fix it calls that error something slightly different, so you get nothing back. Search the phrase instead, and now you get everything except that page. Every retrieval engine quietly makes you pick which of those two misses you can live with. Hybrid search is the one that refuses to pick: it runs both kinds of search at once and merges what they find.

Keyword search matches the literal words you typed against the literal words in your documents. Semantic search turns your query and your documents into vectors, numbers that encode meaning, and finds the ones whose meaning sits closest to yours. Hybrid search runs both and fuses the two result lists into one ranking.

The interesting part is why you would run two search engines instead of one, which only makes sense once you see what each is bad at.

What Does Keyword Search Get Right and What Does It Miss?

Keyword search, or lexical retrieval if you prefer, is the search your systems have been quietly running for years. It scores how much a document’s terms overlap your query, usually with a ranking function like BM25. Paste in an error code or a part number and it lands, every time. The token is either in the document or it isn’t. No interpretation, no cleverness, nothing to get wrong.

That literal-mindedness is also the ceiling. Keyword search matches characters, not meaning, and it has no idea there’s a difference. Search “movie” and every document that says “film” stays invisible. Not ranked low. Invisible. To a lexical scorer those two words are as related as “movie” and “kumquat,” which becomes your problem the moment users start describing the same thing six different ways.

What Does Semantic Search Understand and Where Does It Break?

That blind spot is exactly what semantic search was built to fix. It embeds your query and every document as dense vectors, then ranks them by cosine similarity, a measure of how closely two vectors point in the same direction. Because vectors encode meaning instead of characters, someone searching “portable gaming PC” finally finds your page about a “lightweight laptop for gaming.” Zero shared words. Still the right answer.

Then it breaks in the exact mirror image. An embedding model only knows the meanings it saw in training. Hand it a token it has never seen, a SKU you shipped last week or your team’s internal codename for a service, and it maps that token to whatever it happens to sit near. You don’t get an error. You get a confident, well-ranked, completely wrong answer. The precise identifiers keyword search never misses are the exact inputs semantic search is most likely to fumble.

How Does Hybrid Search Fuse Two Rankings?

Each retriever goes blind precisely where the other one sees. Run both, merge, done. Except merging is where this gets awkward: the two rankings aren’t comparable. A BM25 score and a cosine similarity live on different scales with no shared zero, so if you add or average them, the larger scale simply wins. You haven’t merged anything. You’ve let one retriever outvote the other on bad math.

The fix is to stop comparing scores and start comparing positions. Reciprocal Rank Fusion throws the raw scores away and keeps only where each document landed in each list. Every document earns 1/(k + rank), summed across both lists, where k is a smoothing constant that defaults to 60 and stops any single top-ranked result from running away with the merge. Documents both retrievers liked collect points twice and rise. At query time, this costs you almost nothing.

The bill arrives at indexing instead. Hybrid retrieval means two indexes over one corpus, a sparse keyword index and a dense vector index, and you keep both in sync as content changes.

Warning: The sparse keyword index is cheap to keep current. The dense vector index is not: change your embedding model and you re-embed the whole corpus, and the two indexes drift out of sync every time a document changes.

That re-embedding bill, not the fusion math, is what decides whether hybrid search belongs in your stack.

When Is Hybrid Search Worth the Double Index?

A second index earns its keep wherever retrieval quality decides the final output, and nowhere more than in retrieval-augmented generation. In a RAG system the retrieved passages are the only facts your model has, so a retrieval miss doesn’t degrade gracefully. It fails silently. If semantic-only retrieval skips the one clause naming the exact contract number, your model never sees that clause, but answers confidently from whatever it got. Measured against dense-only retrieval on noisy real-world queries, keyword and semantic together outperform either method alone, because most real queries carry both an exact token and a fuzzy intent.

Winning on average isn’t the same as winning on your traffic, so the second index needs an evaluation set before it needs tuning. Label a few hundred real queries with the passage that should come back, then measure whether it lands in the top k your generator actually sees. Score each retriever separately as well as fused, because separate scores are the only way to tell which half missed, and a lexical gap and an embedding gap need opposite fixes.

Once you can measure your query mix, the only question left is who absorbs the index cost. Progress Agentic RAG treats the retrieval mix as configuration rather than a build. Retuning the weighting leaves your index alone, while swapping embedding models still costs you a re-embed. That’s the distinction worth pricing: whether serving a new use case takes an afternoon or a rebuild.

Real query traffic refuses to be purely lexical or purely semantic, which is why single-strategy retrievers keep failing half of it. So before you ship, sample your actual queries. Split them into those that hinge on an exact token and those that hinge on a paraphrased concept, then count how many need both at once. That ratio is your answer: either one index holds, or the second one is insurance you should have bought already.

FAQ

A few questions come up once hybrid search meets real traffic.

Do I Need to Tune the k Value in Reciprocal Rank Fusion?

Rarely, and not on day one. The default of 60 is a safe starting point. Lowering k sharpens the pull of each list’s top results, while raising it spreads weight across more ranks. Tune it only when your evaluation set shows the fused order leaning too hard on a few top-ranked results.

Can I Weight Keyword and Semantic Results Instead of Using Reciprocal Rank Fusion?

You can, and weighted score combination is common, but it forces you to normalize two scores on different scales, and the right weights drift as your corpus changes. Reciprocal Rank Fusion fuses on rank instead, which makes it a robust default. Weighting pays off once your evaluation data shows one retriever deserves more trust on your traffic.

Does Running Both Retrievers Slow Down Query Time?