Advanced RAG: what you actually run in production

Four moves turn the naive baseline into something that survives real traffic — hybrid search, reranking, query rewriting, and metadata filtering. Each fixes a specific failure and each costs you.

Jun 30, 2026

The problem

The naive pipeline from the last article gets a team about 70% of the way there, and then it stalls. The pattern is always the same: the demo answers were good, the corpus grew, the questions got more varied, and recall quietly fell off a cliff. A query that names an exact product code returns ten semantically-fuzzy chunks and misses the one document that actually mentions the code. A user phrases a question nothing like how the document was written, and the right chunk never clears the similarity threshold. The team adds more documents hoping to help, and makes it worse — more haystack, same needle.

None of this is a model problem, and a bigger embedding model won’t fix it. It’s the knowledge layer — the part of an agent system that decides reliability in production and is an engineering discipline in its own right — hitting the limits of pure top-*k* vector search. Advanced RAG is the set of moves that push past those limits. There are four worth knowing, and the discipline is in knowing which failure each one fixes and what it costs you, because none of them is free.

The four moves

Here’s the naive pipeline with the four upgrades dropped into place — the Article 2 baseline with four new boxes wired in.

Article content — Figure 1 — Advanced RAG. Query rewriting at the front, hybrid retrieval feeding a fusion step, metadata filtering, and a reranker before the context is assembled. Each box is an independent decision with its own cost.

Move 1 — Hybrid search (BM25 + vectors)

The failure it fixes: pure vector search is blind to exact tokens. Embeddings encode meaning, so a part number like SKU-44918, a statute reference, or a rare acronym embeds into roughly the same region as its neighbours and gets lost. Keyword search — BM25, the decades-old probabilistic ranking function that still backs Elasticsearch and OpenSearch — is exact where vectors are fuzzy. Hybrid search runs both and combines the result lists, usually with Reciprocal Rank Fusion, which scores a document by the reciprocal of its rank in each list and needs no tuning to merge them.

What it costs: a second index to build and keep in sync, and a fusion step. Operationally modest — pgvector plus a Postgres full-text index, or a single store that does both, keeps it to one system. Anthropic’s Contextual Retrieval write-up (September 2024) put a number on the payoff: contextual embeddings alone cut their top-20 retrieval failure rate by 35%, and adding contextual BM25 took the cut to 49%. Skip it when your corpus has no exact-match vocabulary — pure prose with no codes, IDs, or names — where keyword matching adds noise instead of signal.

Move 2 — Reranking

This is the highest-leverage single move, and the first one to reach for when retrieval is “almost there.”

The failure it fixes: the top-*k* chunks from a similarity search are ranked by a cheap approximation — cosine distance between independently-computed embeddings, which never actually compared the query and the chunk against each other. A reranker is a cross-encoder: it reads the query and each candidate chunk together and scores genuine relevance. You retrieve a generous longlist (say top-50 cheaply), then rerank to a precise shortlist (top-5). It’s a recruiting funnel — a cheap CV screen gets you fifty plausible candidates, and the expensive interview reads each one carefully before you pick five.

In practice: Cohere’s Rerank 4 (*Introducing Rerank 4*, December 2025 — Fast and Pro variants, a 32k context window, 100+ languages) and Voyage’s rerank-2.5 are the two production defaults. A realistic before/after on a mid-sized corpus: retrieve-then-rerank takes recall@5 from around 0.6 to 0.85, and p99 latency from roughly 200 ms to 600 ms. In the Anthropic numbers above, adding reranking on top of contextual hybrid search took the failure-rate cut from 49% all the way to 67%.

What it costs: an extra network call per query and that latency bump — the reranker has to score every candidate, so 80–150 ms is typical on top of retrieval, more if your longlist is large. Skip it when your corpus is so small that the top-*k* is already the whole relevant set, or when sub-200 ms latency is a hard product requirement you can’t spend.

Move 3 — Query rewriting

The failure it fixes: the user’s phrasing and the document’s phrasing don’t match, and one short query can’t express a multi-part question. Three sub-moves handle this. Expansion rewrites a terse query into a fuller one before embedding. Decomposition splits a compound question — “compare our refund policy for EU and US customers” — into separate retrievals that get merged. And HyDE (Hypothetical Document Embeddings, from Gao and co-authors’ Precise Zero-Shot Dense Retrieval without Relevance Labels, [arXiv 2212.10496](https://arxiv.org/abs/2212.10496), December 2022) has the model write a fake ideal answer first and embeds that instead of the question — on the theory that an answer looks more like the target document than the question does.

What it costs: an extra LLM call before retrieval even starts, which adds latency and a little money to every query, and introduces a new failure surface — a bad rewrite retrieves confidently for the wrong question. In practice this is the move to add last, after hybrid search and reranking, because its wins are real but smaller and its cost lands on every single query. Skip it for short, well-formed queries over a corpus written in the user’s own vocabulary — an internal tool where people already ask in the documents’ language gains little.

Move 4 — Metadata filtering

The failure it fixes: the naive pipeline ranks on similarity alone and has no notion that last year’s fee schedule is superseded by this year’s, or that a document belongs to a tenant the user can’t see. Metadata filtering attaches structured fields — valid_from, tenant_id, document_type, access tags — to each chunk and filters on them before or during retrieval. This is also the cheapest, most boring, and most-skipped reliability win in the whole pipeline.

What it costs: almost nothing at query time, and real discipline at index time — someone has to populate the metadata correctly and keep it correct, which is process work rather than ML work. Skip it essentially never. Even a single valid_from date filter pays for itself the first time it stops the agent from quoting a retired policy, and access-control filtering isn’t optional the moment your corpus spans more than one permission boundary.

Where the four leave you

Cost / latency / setup effort (deltas over naive RAG):

Read the table as a menu, not a recipe. The order of adoption that holds up in production, and that the costs above argue for — call it the cost-order rule: metadata filtering first (cheap, always worth it), then reranking (highest leverage), then hybrid search (cheap insurance against exact-match misses), then query rewriting last (real but smaller wins, paid on every query). And to put a boundary on the whole menu: all four together are typically a two-to-three-week retrofit on an existing pipeline, not a rebuild.

The stack a competent team converges on

Not as a prescription — as a checkpoint to measure your own choices against. After the dust settles, most teams running serious RAG land in the same place: a single store doing both vector and keyword search, Reciprocal Rank Fusion to merge them, a cross-encoder reranker (Cohere Rerank 4 or Voyage rerank-2.5) trimming the longlist to a tight shortlist, metadata filters enforcing recency and access control, and query rewriting added only where the query/document vocabulary genuinely diverges. The embedding and reranker models underneath keep moving — Voyage shipped its mixture-of-experts voyage-4-large in January 2026, the rerankers turn over every few months — but the shape of the stack has been stable for a while now, and that stability is the signal that this is the production answer, not a fashion.

If your stack looks materially different from that and you can say why — a latency budget that rules out reranking, a corpus with no exact-match vocabulary that rules out BM25 — you’re fine. If it looks different and you can’t say why, that’s worth a look.

Combinations and what’s next

Advanced RAG is still retrieval over a flat corpus — it makes the retrieval sharper, but it can’t answer a question whose answer isn’t sitting in some chunk. When the question is about relationships between entities — “which suppliers connect to the parties in this dispute?” — no amount of reranking helps, because the answer is a path through a graph, not a passage in a document. That’s where GraphRAG comes in, and it’s the next article. And when retrieval needs to become a decision the agent makes — query, judge the results, refine, query again — you’ve crossed into agentic RAG, two articles out. Advanced RAG is the substrate both of those assume you’ve already got right.

Production checklist

Measure recall@k before and after every move on a held-out golden set — never add a reranker or a rewriter on faith; prove the delta.
Log the full retrieval trace: rewritten query, both retrieval lists, fused order, reranker scores, final shortlist. When an answer is wrong, this is where you see which move failed.
Watch the latency budget per stage — query rewriting and reranking each add a measurable slice; track p99, not just the average, because the tail is what users complain about.
Keep the longlist size honest — reranking a 200-candidate list is slow and rarely beats reranking 50; tune it.
Treat metadata as a first-class schema, version it, and validate it at index time; silent metadata rot defeats the filter quietly.
Alert when the reranker’s top score is low — same principle as naive RAG, but now you have a more trustworthy signal to threshold on.
Re-evaluate the embedding and reranker models quarterly — they turn over fast, and a model swap is often a bigger win than another pipeline tweak.

The take

Advanced RAG isn’t a different technique from naive RAG — it’s the same pipeline with four targeted repairs, each aimed at a failure you can name. Add them in cost order, measure every one against your baseline, and stop when the numbers stop moving. The team that does this beats the team chasing a bigger model almost every time, because they’re fixing the layer where the failures actually live.

New articles land here first. Subscribe for the full series. I take on a small number of advisory engagements each year for teams hitting exactly these problems. The fastest way to reach me is on LinkedIn; reach out if that’s you.

The Knowledge Layer

Discussion about this post

Ready for more?