Advanced RAG Techniques: Rewrite, Retrieve, Rerank

A customer types: “does the 44-A one work with mine or do I need the older bracket?” Your retriever embeds that sentence, takes the three nearest passages, and hands back category marketing copy and a page about warranty registration. The model writes a confident, useless answer from them.

Nothing crashed. Nothing logged an error. Retrieval simply returned the wrong three passages — and once it does, no prompt engineering downstream will rescue the answer. This is the ordinary failure of naive RAG.

The techniques below are usually presented as a menu. They are better read as specific answers to specific complaints.

What does “advanced RAG” actually mean?

Naive RAG is a straight line: embed the question, take the top-k nearest chunks, paste them into the prompt. Advanced RAG keeps that line and adds work at three points along it — pre-retrieval (improve the query before searching), retrieval (change how the search works), post-retrieval (fix the passages that came back).

That split matters more than any individual trick, because it tells you where to intervene. If the right passage was never in the index in retrievable form, reranking cannot help you. If it came back ranked seventh and you passed three, rewriting the query is beside the point. Diagnose the stage first.

How do you fix the query before you search?

The query you receive is rarely the query you should search with. Users write like people, not like search engines, and embeddings are less forgiving about that than everyone hopes.

Query rewriting is the cheapest fix and the one every chat interface needs immediately. The third message in a conversation is “and what about the bigger one?” — a sentence containing nothing retrievable. Rewriting folds the history back into a standalone question: “what is the return window for the 12-inch model?” Skip it and your assistant looks brilliant on the first question and lost by the fourth.

Query expansion attacks vocabulary mismatch. Customers say “broken”; your documentation says “defective on arrival”. Embeddings absorb some of that, but not trade jargon they never saw in training and not your internal product nicknames. Expansion generates a few alternative phrasings, searches with all of them and pools the results — at the price of more searches per question and a real risk of drifting somewhere the user did not ask about.

HyDE — hypothetical document embeddings — is the clever one, worth understanding rather than just switching on. Questions and answers do not look alike. A question is short and interrogative; the passage answering it is declarative prose full of policy nouns. Comparing an embedded question against embedded passages measures similarity across two different kinds of text, and that mismatch costs you.

So HyDE does something that sounds wrong at first. It asks a model to invent an answer, with no retrieval at all, then embeds that fabrication and searches with it. The invented answer may be factually wrong — that genuinely does not matter, because nobody ever sees it. It only has to be answer-shaped: right register, right vocabulary, right length. And answer-shaped text lands far closer to real answers in vector space than question-shaped text does. You are searching with a decoy that resembles what you are hunting for. It shines on knowledge bases written in consistent prose, and misfires when the guess wanders into a topic your corpus does not cover.

Metadata filtering is the least glamorous item here and often the highest return. Before ranking anything by similarity, restrict the candidate set: this brand, this language, this document version, visible to this user’s role. Permissions belong here and nowhere else — query time is the only safe place to enforce them. Filtering usually makes retrieval faster too, since you search a smaller space.

Decomposition handles the compound question. “Which grinder is quieter, and which ships to the UAE?” is two searches wearing one sentence; a single embedding of it averages two topics and lands near neither. Split it, retrieve per part, answer once from the combined context.

What changes during retrieval itself?

Pure vector search has one blind spot that is expensive in commerce: exact tokens. Ask a dense retriever for “44-A” and it returns things that are vaguely part-number-ish and semantically nearby. It has no notion of that string being the one you must match. A keyword index treats a rare token as enormously informative precisely because it is rare, and puts the exact match on top.

Hybrid search runs both: dense vectors for meaning, sparse BM25-style scoring for literal tokens. For a catalogue this is not a marginal gain. SKUs, model codes, error codes, invoice references — these are where a semantic-only system fails most visibly, and where the user is most certain they typed the right thing. If you sell anything with a part number, treat hybrid as the default and pure vector search as the exception.

The two searches produce lists whose scores are not comparable — cosine similarity and a BM25 score live on different scales — so you need a fusion step. Normalise both onto a common range and take a weighted sum, which gives you a tuning knob and makes you responsible for it. Or discard the scores and use rank positions alone, in the spirit of reciprocal rank fusion: a document placing respectably in both lists beats one that tops a single list and is absent from the other. Rank-based fusion is the sturdier default — no calibration, and nothing breaks when you swap embedding models.

The third decision here is one people file under “ingestion” and never revisit: chunking. Boundaries decide what is even possible to retrieve, and overlapping windows stop a sentence on a boundary from being orphaned. More useful still, parent–child retrieval (small-to-big) separates the unit you match from the unit you return: embed small, precise chunks so scoring is sharp, then return the surrounding section so the model has room to reason. Matching one specification line and handing back the whole spec table is usually correct — and that is a chunking decision, not a prompt one.

What do you do with the passages that come back?

Post-retrieval work assumes retrieval was roughly right and is now too noisy, too long, or in the wrong order.

Reranking with a cross-encoder is the most effective single addition available. Vector search uses a bi-encoder: question and document are embedded separately, never having seen each other, and relevance is the distance between two independently written summaries. A cross-encoder is structurally different — it takes the query and one passage as a single input, lets attention run across both, and outputs a relevance score. It can notice that a passage mentions your exact model number only to say it is excluded from the policy. Cosine similarity cannot notice that. Ever.

The catch is cost. Nothing can be precomputed, so a cross-encoder runs once per candidate at query time, and scoring a whole corpus that way is simply not available to you. So it runs on a shortlist: retrieve broadly and cheaply, fifty candidates rather than five, then rerank down to the handful you pass on. That two-phase shape is the point — you raise recall without drowning the model in noise, because a precise judge sits in between.

Contextual compression handles passage bloat. You retrieved eight hundred tokens; two sentences answer the question. Trimming the rest saves context budget and removes distractors. It costs another model call and carries one risk worth naming: compressors love to drop qualifying clauses. Losing “except for opened items” from a returns policy turns a correct answer into a support ticket.

Deduplication and ordering are nearly free and routinely skipped. The same paragraph often appears in three documents; passing all three wastes the window and can make the model treat a repeated claim as better supported than it is. Ordering matters because attention over long context is uneven — material near the start and end of a prompt gets used more reliably than material buried in the middle. Do not dump ranked passages down the centre of the prompt. Put the strongest one where the model will actually read it.

What does each of these cost you?

Everything here is paid for in latency, money per query, or both. That is the part vendor documentation tends to skim.

A decision rule we will defend in a room full of engineers: turn on metadata filtering immediately — it is free or better, and permissions demand it anyway. Then add the reranker. Nothing else returns as much answer quality per millisecond added: no re-indexing, no re-embedding, it drops in behind your existing retriever, and it lets you widen recall without paying for that width in the prompt. Two improvements for one step. Then hybrid search, if people search by identifiers — in commerce, they do. Query rewriting once the interface is conversational. HyDE and decomposition last, because each puts a full generation round-trip in front of every search, and you should be able to point at logged failures that justify it.

When does adding techniques become the problem?

Every item above is defensible on its own. The trouble is what a pipeline looks like after a year of adding them one incident at a time: a rewriter nobody owns, an expansion step added for one customer, two rerankers because the first was never removed, fusion weights tuned by a contractor who left. Nobody can say what any single component contributes, so nobody dares delete anything.

That is a failure of structure, not of the techniques — and it is exactly the pressure Modular RAG exists to relieve, by making each stage a swappable component with a defined contract instead of another branch in one long function. Four or five additions in, with change starting to feel risky? That is your signal. For the wider map of how these approaches relate, start from the RAG overview.

Frequently asked questions

Is advanced RAG a different architecture from naive RAG?

No — it is the same pipeline with extra steps at three points. That is good news: you migrate incrementally, one technique at a time, measuring each. There is no rewrite and no moment where you discard what you built. Anyone quoting a from-scratch rebuild to “upgrade to advanced RAG” is selling you something you do not need.

If I can only add one thing, what should it be?

A cross-encoder reranker, assuming metadata filtering is already in place. It fixes the most common naive failure — the right passage came back, just not in the top few — without touching your index, embeddings or ingestion, and it changes the economics of retrieval, because once it sits in the path you can safely fetch fifty candidates instead of five.

Does HyDE work if the model invents a factually wrong answer?

Usually yes, which surprises people. The hypothetical answer is never shown to a user and never enters the final prompt — it exists to be embedded and thrown away. What matters is that it carries the vocabulary and structure of a real answer, since that is what makes it land near real answers in vector space. HyDE fails when the guess concerns a topic your corpus does not contain, at which point it steers the search confidently nowhere.

Do I need hybrid search if my embedding model is good?

If your content contains identifiers people type verbatim, yes. Better embedding models narrow the gap on natural language but do not close it on rare literal tokens, because matching exact strings is not the job dense vectors do. A shopper searching a part number wants that part, and returning something semantically similar fails in the most visible way available.

How much latency should I expect to add?

It depends on which steps you add and where they run, so treat any single quoted number with suspicion. The useful model: reranking adds one bounded step over a shortlist, hybrid search mostly adds work you can run in parallel with the vector query, and anything that generates text before searching — rewriting, expansion, HyDE — puts a full model round-trip in front of every request. Measure your own pipeline end to end and budget per stage.

Can Ecarter help us upgrade an existing RAG pipeline?

Yes. Retrieval tuning is a large part of our AI development and LLM development work, including AI for e-commerce catalogues on CS-Cart, Magento and Shopify. We usually start by building an evaluation set from your real failed questions, because without one you cannot tell whether any of these additions helped.

Have a RAG system that answers well in demos and badly in production? Talk to Ecarter about a retrieval audit — we will tell you which of these three stages is actually costing you answers before you spend on any of them.