An underwriter types a question into the internal knowledge assistant: what is the flood sub-limit on policy HX-2291-B? The system answers confidently, citing a policy schedule. The schedule belongs to HX-2291-A, a sibling policy with a different sub-limit.
Nothing in that exchange looks like a failure. Retrieval returned a relevant, well-formed passage about flood sub-limits on a commercial property policy. The model summarised it faithfully and added a citation. The answer was still wrong, because the question depended on one exact string and the retriever was built to match meaning.
This is the most common retrieval failure in enterprise private RAG, and it rarely appears in demos. Demo questions are phrased in natural language. Production questions are full of identifiers.
What embeddings are bad at
An embedding model turns a passage into a point in a vector space, placing similar meanings near each other. That is exactly what you want for how do we handle a customer who disputes a charge?, where the relevant policy might say “chargeback”, “contested transaction” or “billing complaint”.
It is exactly what you do not want for strings whose meaning sits in their exact characters:
- Identifiers: policy numbers, claim references, contract IDs, ticket numbers, account numbers.
- Codes: part numbers, SKUs, error codes, ICD or tariff codes, internal cost-centre codes.
- References: “clause 14.3(b)”, “Article 9(1)”, “section 4.2 of the SLA”.
- Rare or new vocabulary: product names, project codenames and internal acronyms that the embedding model never saw in training.
To an embedding model, HX-2291-A and HX-2291-B are almost the same thing. So are part 7731-004 and 7731-040. Their vectors land next to each other, and nearest-neighbour search cannot tell them apart. In regulated work, that difference is often the whole question.
Keyword retrieval fails in the opposite direction. BM25 and its relatives score documents on exact term overlap, weighted by how rare each term is. They find HX-2291-B instantly and precisely. They also miss the “contested transaction” policy when the user typed “dispute”, and they handle cross-language queries poorly. Neither retriever is sufficient on its own, and their failures barely overlap. That is why combining them works.
How hybrid retrieval works
A hybrid retriever sends the query to both indexes in parallel and merges the two ranked lists. The merge step is where most of the design decisions sit.
| Fusion method | How it works | Strengths | Watch-outs |
|---|---|---|---|
| Reciprocal rank fusion (RRF) | Each document scores the sum of 1 / (k + rank) across retrievers | No score normalisation; one parameter; robust default | Ignores how confident each retriever was |
| Normalised score combination | Scale each retriever’s scores (for example min-max), then take a weighted sum | Can express “trust lexical more for this query type” | Weights need a labelled evaluation set to set honestly |
| Query-dependent routing | Classify the query, then weight or select retrievers per class | Handles identifier-heavy and conversational queries differently | Adds a classifier that must itself be tested |
Reciprocal rank fusion comes from a 2009 SIGIR paper by Cormack, Clarke and Büttcher. In their experiments, this simple rank-based merge beat every individual system it combined, and beat Condorcet fusion and the rank-learning methods it was compared against. Elasticsearch ships RRF as a retriever with a default rank constant of 60. OpenSearch offers a normalisation processor for score-based combination. PostgreSQL can do the same with full-text search next to a vector extension, with the fusion done in SQL. You do not need a specialised vector product to run hybrid retrieval on premises.
A practical default is RRF first, then measure. Move to weighted or routed fusion only when your evaluation set shows a specific query class that RRF handles poorly.
Getting the keyword side right
Most hybrid deployments that underperform have a weak lexical side, and the cause is usually tokenisation. A default text analyser may split HX-2291-B into “hx”, “2291” and “b”, and each of those fragments matches thousands of documents. The fixes are simple once someone looks:
- Index identifiers as exact-match fields alongside the analysed text, so a policy number matches as one token.
- Extract identifiers at ingestion into metadata. That lets the retriever apply an exact filter when the query contains a recognisable pattern, not just a scoring boost.
- Add character n-grams for codes where users type partial references or swap separators.
- Carry context into the lexical index too. Anthropic’s published contextual retrieval work prepended a short document-level context to each chunk before both embedding it and building the BM25 index. In their evaluation, contextual embeddings plus contextual BM25 cut the top-20 retrieval failure rate by 49%, and by 67% with reranking added. Your corpus will give different numbers, but the direction holds. Chunks that know which document they came from retrieve better on both sides. The same idea is covered in our guide to chunking enterprise documents for private RAG.
Where hybrid search sits in the pipeline
The order of operations matters more than the choice of fusion method:
- Permission pre-filter. Resolve the caller’s entitlements from the authenticated session and apply them to both retrievers. A keyword index without the same metadata filters is a side door around your access model.
- Parallel retrieval. Lexical and vector search each return a candidate list, typically a few dozen passages.
- Fusion. RRF or weighted combination merges them into one list.
- Reranking. A cross-encoder reranker reorders the fused pool by reading the query and each passage together.
- Generation. The model answers only from the top passages and cites them.
Hybrid retrieval increases recall. The reranker restores precision. Neither can recover a document that the permission filter correctly excluded, and neither should.
Measuring whether it helped
“Hybrid is better” is a hypothesis to test against your own queries, not a fact to assume. Split your evaluation set by query shape. Keep one slice of identifier-bearing questions (policy numbers, part codes, clause references) and one slice of conversational questions. Measure recall at k for each slice under vector-only, keyword-only and hybrid configurations.
Expect hybrid to help most on the identifier slice and to roughly hold steady on the conversational slice. If the conversational slice drops, the fusion is over-weighting the lexical side. Our private RAG evaluation framework describes how to build and maintain the labelled set these comparisons need.
On-premises considerations
Running hybrid search inside your own infrastructure adds three operational duties that are easy to miss:
- Two stores, one boundary. The inverted index holds readable text and is often more directly sensitive than the vectors. It belongs in the same network zone, under the same encryption and access controls.
- Deletion must reach both. When a document is erased or superseded, both indexes need updating. The data deletion guide lists the lexical index among the copies most often forgotten.
- Synchronisation must reach both. A permission change that updates vector metadata but not the keyword index leaves an inconsistent access model, and inconsistent access controls fail silently.
How VDF AI handles retrieval
VDF AI’s enterprise RAG combines semantic and keyword search with metadata filters, reranking and optional knowledge-graph retrieval. Permission checks run at query time against the caller’s identity. Embedding models, rerankers and the indexes themselves run inside the customer’s environment, so documents, identifiers and retrieval logs stay inside the security boundary. Retrieval is traced, so an answer about HX-2291-B can be checked against the exact passages it came from.
Sources and further reading
- Cormack, Clarke and Büttcher — Reciprocal rank fusion outperforms Condorcet and individual rank learning methods (SIGIR 2009)
- Elasticsearch Reference — Reciprocal rank fusion
- OpenSearch Documentation — Hybrid search
- Anthropic — Introducing Contextual Retrieval
- Choosing embedding models and rerankers for on-premises RAG
- Why Private RAG Fails on Tables and Spreadsheets
- Permission-Aware Private RAG: Preserve Document Access Controls
Private RAG returning the right topic but the wrong policy? Talk to us about testing hybrid retrieval against your own identifiers.