Hybrid Retrieval: When Keyword Search Beats Your Embeddings

A support engineer types an exact Oracle error into your shiny new RAG search box: ORA-01555 snapshot too old. There is one runbook in the knowledge base that fixes exactly this error. It does not come back. The top result is a general page about database tuning, the second is about connection pooling, and the runbook that names the error is somewhere on page three, below things that have nothing to do with it.

Nothing failed. The vector search ran, the embedding model worked, the latency was fine. The system returned five confident results and the one document that mattered was not among them. To the model reading that context, the runbook does not exist, so the answer it gives is generic and wrong. This is the quiet kind of retrieval failure: no exception, no alert, just a slightly worse answer that nobody can trace back to a missing document.

Here is the part that stings. Before you replaced it, the old keyword search box found that runbook instantly, because the runbook contains the literal string ORA-01555 and so did the query. You upgraded to embeddings to catch the questions users phrase in their own words, and in doing so you broke the questions that are just an exact string. You did not trade a worse system for a better one. You traded one set of blind spots for a different set, and the new blind spot happens to sit exactly where your most precise users live: the ones who paste an error code, a SKU, or a function name and expect the machine to find the one document that names it.

This is not a bug in your embedding model. It is what embeddings are. This lesson is about why dense search and keyword search fail in opposite places, why you cannot tune your way out of either gap, and why the fix that production teams reach for is not choosing one but running both and merging the results into a single ranked list.