Advanced RAG

Overview

Advanced RAG is retrieval-augmented generation with extra steps around the retriever. Before retrieval, it improves the query through rewriting, expansion or routing, and it improves the index through better chunking and metadata. After retrieval, it reranks the candidates, removes noise and compresses the context before the language model reads it. The goal is to raise the precision and recall of the evidence that reaches the model.

The idea is simple: the quality of an answer depends on the quality of the evidence. A naive RAG pipeline retrieves once and hopes. Advanced RAG treats retrieval as a stage that can be engineered, measured and tuned. It keeps a fixed, predictable flow, which makes it a good fit for production systems that need steady latency and clear debugging. When questions are too varied for any fixed flow, designs such as Modular RAG and Agentic RAG take over.

What it is

Advanced RAG is a family of techniques applied to the standard index, retrieve, generate pipeline. There is no single product called advanced RAG. The label covers a set of upgrades that are added in a sensible order, each one aimed at a specific failure.

Three zones of improvement

• Indexing zone: better parsing, chunking, metadata and embeddings.
• Pre-retrieval zone: query rewriting, expansion, decomposition and routing.
• Post-retrieval zone: hybrid fusion, reranking, filtering, compression and ordering.

Think of a good reference librarian. Before looking anything up, they ask a clarifying question and rephrase your request in the catalogue's language. They search several catalogues. They then read the top results, drop the weak ones, and hand you a short stack ordered by usefulness. Advanced RAG automates that behaviour.

What stays the same

The overall shape is still a straight line. A question enters, the pipeline runs its stages in a fixed order, and an answer leaves. The stages can contain loops of their own, such as retrying a search once, but the programmer still decides the order. That is the main difference from agentic designs.

A map of the techniques

Where it came from

Early RAG systems from around 2020 used one dense retriever and one generator. As teams moved them into products, the same weaknesses appeared in many places: poor matching for short queries, missed keywords, and noisy context. Practitioners and researchers began to add fixes one by one.

Building blocks with their own histories

• Keyword ranking with BM25 is decades old and still strong for exact terms.
• Dense retrieval with learned embeddings, including the DPR line of work from 2020, improved matching by meaning.
• Late interaction models such as ColBERT kept token-level information for finer matching.
• Cross-encoder rerankers, which read the query and a passage together, came from the passage ranking literature and proved very effective as a second stage.
• Query expansion has a long history in information retrieval. Newer variants use a language model to write the expansion.
• HyDE, published in 2022, proposed embedding a model-written hypothetical answer rather than the raw question.
• Work on lost-in-the-middle behaviour, published in 2023, showed that models use information at the start and end of a long context better than information in the middle, which motivated ordering and compression.
• Contextual retrieval added short context notes to chunks before embedding them.

The naming

Survey writing in 2023 and 2024 grouped RAG designs into naive, advanced and modular stages. Advanced RAG is the middle stage: a fixed pipeline with pre and post processing. The labels are teaching aids, and real systems often borrow from all three.

How it works

This section walks through an advanced RAG request from the moment a question arrives until the answer is returned, with everyday analogies.

Step 1: Prepare the index well

The work starts before any question arrives. Good indexing is the foundation.

• Parse documents with structure in mind. Keep headings, lists and tables.
• Split on natural boundaries. A section is a better unit than a fixed number of words.
• Attach metadata such as title, section path, date, product and language.
• Optionally add a short summary or a few likely questions to each chunk and embed those too.
• Consider a two-level index: small chunks for matching, larger parent sections for reading.

Analogy: a well-organised archive has labelled folders, not a pile of loose pages.

Step 2: Understand the query

Real queries are messy. "And what about the second one?" means nothing without the chat history. A pre-retrieval step cleans this up.

• Rewrite: turn the question into a standalone, search-friendly sentence using the chat history.
• Expand: add synonyms, acronyms and related terms.
• Decompose: split a multi-part question into sub-questions.
• Classify: decide which index, filter or pipeline suits the question.

Chat history: user asked about the Pro plan limits.
Latest message: "and does it include the audit log?"
Rewritten query: "Does the Pro plan include the audit log feature?"

Step 3: Optionally draft a hypothetical answer

With HyDE, a model writes a short fake answer and the system embeds that text. An answer-shaped text often sits closer to real passages than a question does. The fake answer is used only for searching, never shown as fact.

Analogy: describing the book you want rather than reciting the question you have.

Step 4: Retrieve with more than one signal

A hybrid retriever runs a dense search for meaning and a keyword search for exact terms, then merges the two result lists. A common merge method is reciprocal rank fusion, which scores each item by its rank in each list.

def rrf(rank_lists, k=60):
    scores = {}
    for ranks in rank_lists:
        for pos, doc_id in enumerate(ranks, start=1):
            scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + pos)
    return sorted(scores, key=scores.get, reverse=True)

Analogy: asking two experts, one who knows the topic well and one who remembers exact wording, and trusting the items both mention.

At this stage the system retrieves more than it needs, often 30 to 100 candidates. The aim is high recall. Precision comes next.

Step 5: Apply metadata filters

Filters narrow the candidates by date, product, language or access rights. They are cheap and remove a lot of noise. Access filters are also a security control and should run before results reach the model.

Step 6: Rerank

A reranker reads the query and each candidate together and gives a relevance score. A cross-encoder is more accurate than comparing two precomputed vectors, because it sees both texts at once. It is also slower, which is why it runs only on the shortlist.

Analogy: the first round of a talent show picks fifty people from thousands by quick checks. The judges' panel then watches each of the fifty perform and picks the final ten.

Step 7: Select, deduplicate and order

From the reranked list, keep the top few. Remove near duplicates. If neighbours of a chosen chunk help, add them, or swap in the larger parent section. Place the strongest evidence first, and also near the end if the context is long.

Step 8: Compress

Compression trims each chunk to the sentences that matter for the question. It can be extractive, keeping only relevant sentences, or abstractive, summarising them. It lowers cost, reduces distraction and fits more sources into the window. The risk is dropping a detail that mattered, so test it.

Step 9: Generate with guardrails

The prompt tells the model to use only the evidence, to cite sources and to say when the evidence is insufficient. Some systems add a final check that each claim is supported by a cited passage, using an LLM-as-judge or a smaller verifier.

Step 10: Log and learn

Every stage writes to a log: the original and rewritten queries, the candidate lists, rerank scores, the final context and the answer. Logs reveal which stage fails and feed the test set.

The pipeline as code

def advanced_rag(question, history, deps):
    q = deps.rewrite(question, history)
    subs = deps.decompose(q)
    pooled = []
    for sub in subs:
        dense = deps.dense_search(sub, top_k=50, filters=deps.filters)
        sparse = deps.keyword_search(sub, top_k=50, filters=deps.filters)
        pooled.extend(rrf([dense, sparse])[:50])
    candidates = deps.dedupe(pooled)
    ranked = deps.rerank(q, candidates)[:6]
    context = deps.compress(q, ranked)
    answer = deps.generate(q, context)
    return answer, ranked

Key concepts and terms

A worked example

A company keeps a technical knowledge base with product manuals, release notes and troubleshooting guides. A naive RAG assistant gives uneven answers. The team upgrades it step by step and measures after each step.

Baseline

On a test set of 100 questions, the naive pipeline retrieves the gold passage in its top 5 for only some of them. The team lists the failures by type:

Upgrade 1: hybrid search

Adding keyword search fixes the error-code failures, because the code is matched as a literal token. Recall rises on those questions at almost no cost.

Upgrade 2: query rewriting with history

A rewriting step turns "And on the older version?" into "How do I configure the export feature in version 2 of the product?" The retriever now has something to work with.

Upgrade 3: reranking

The retriever fetches 40 candidates and a cross-encoder reorders them. The gold passage that was at rank 9 moves to rank 2. The final context uses the top 5 after reranking, so the prompt stays the same size but contains better evidence.

Upgrade 4: compression and ordering

Each chunk is trimmed to the sentences related to the question. The prompt gets shorter, generation is quicker, and answers cite the right lines.

Results table shape

The table shows the direction of change to expect, not measured numbers. Your results depend on data and models, so measure your own.

A rewriting prompt

Rewrite the user's last message as a standalone search query.
Use the chat history to resolve words like "it", "that" and "the second one".
Keep product names, codes and numbers exactly as written.
Return only the query.

A sample configuration

pipeline: advanced-v2
pre_retrieval:
  rewrite: true
  decompose: true
  hyde: false
retrieval:
  dense_top_k: 50
  keyword_top_k: 50
  fusion: rrf
  filters: [product, language, access_group]
post_retrieval:
  reranker: cross-encoder
  rerank_top_n: 6
  compress: extractive
  dedupe_threshold: 0.9
generation:
  cite_sources: true
  refuse_if_unsupported: true

Strengths and limitations

Strengths

• Clear gains in retrieval quality over the naive baseline, especially for exact terms and vague queries.
• A fixed flow with predictable latency and cost bounds.
• Each stage can be measured, tuned and replaced on its own.
• Easy to debug, because each stage leaves a log.
• Reuses mature ideas from search engineering.
• Works well with filters and access control for enterprise data.

Limitations

• More moving parts to build, tune and maintain.
• Extra model calls for rewriting, reranking and compression add latency and cost.
• Each stage can introduce its own errors. A bad rewrite can lose the user's intent.
• Compression can remove a needed detail.
• The flow is fixed, so very varied questions may still fall through. A question that needs a SQL query or a second round of search is outside the design.
• Gains are uneven. On a small, clean corpus the extra steps may add cost without benefit.
• Tuning many settings at once can lead to overfitting to a small test set.

Trade-off view

How it compares with alternatives

Advanced RAG versus agentic RAG

Both can retry and rewrite. In advanced RAG the programmer fixes the order of steps and the number of retries. In agentic RAG the model chooses. Advanced RAG is easier to bound and test. Agentic RAG copes with more variety. Many teams start with advanced RAG and add an agent only for the question types that need it.

Advanced RAG versus a bigger model

A stronger generator can ignore some noise, but it cannot use evidence it never received. Improving retrieval is usually cheaper and more reliable than raising model size, and it helps any model that sits on top.

Choosing a vector backend

Advanced RAG needs filters, hybrid search and updates. Options include pgvector inside PostgreSQL, Elasticsearch, Qdrant, Weaviate, Milvus and Pinecone. Pick based on scale, filtering needs and the team's existing stack. Approximate indexes such as HNSW and libraries such as FAISS sit underneath many of them.

Role in tabular foundation models

Tabular foundation models learn from raw tables. A table has rows and columns, mixed types such as numbers, categories and text, missing values and sometimes no useful column names. These models are usually pre-trained on large numbers of synthetic or real tables and then use in-context learning: they read labelled example rows in the prompt and predict for new rows without updating weights. TabPFN is a well-known example, and FT-Transformer is a related deep model for tabular inputs.

Advanced RAG is a text-oriented pattern, but its ideas carry over to tables in concrete ways.

Better context rows, not just nearest rows

In-context learning depends on which example rows are placed in the prompt. The advanced RAG mindset applies directly:

• Pre-retrieval: describe the target row in terms of the features that matter, and filter by segment, time window or class.
• Retrieval: combine two signals, such as distance in a numeric feature space and exact matches on key categorical fields. This mirrors hybrid search.
• Post-retrieval: rerank candidate rows by a task-aware score, remove near duplicates and balance classes before packing the context.
• Compression: drop columns that do not help, and round or bin numbers to save space.

The result is a smaller, cleaner set of context rows, which usually helps a model that reads its examples in the prompt.

Hybrid search over rows and documents

A data assistant often needs two things: rows that look like the target and documents that explain them. A hybrid layer can query a row index and a document index and merge the results, with filters for access rights. The tabular model predicts from the rows, and the language model explains using the documents.

Missing values and absent column names

Dense retrieval over serialised rows struggles when columns are named "c1" and "c2" or when many cells are empty. Pre-retrieval steps can help: profile the table, infer plausible column meanings, and fill gaps with an imputation step such as imputation networks. Semantic labelling work, such as semantic sector heads, aims to tell what a table is about from its structure and values, which in turn lets a router pick the right index or tool.

Anomaly detection with evidence

For anomaly detection, a detector scores a row. An advanced RAG layer can then retrieve the nearest normal rows for comparison and related notes such as change logs. Reranking puts the most explanatory evidence first, and the language model writes a short, cited explanation. The detector finds the oddity, and retrieval supplies the story.

Keeping predictions fresh

Tabular data changes over time. Because in-context learning uses rows from the prompt, a retriever that pulls recent, similar rows adapts the model's behaviour without retraining. This is a light form of continual adaptation. It does not replace retraining when the schema or distribution shifts a lot.

Limits to keep in mind

• Advanced RAG does not learn from tables. A tabular foundation model does that.
• Text similarity is a poor proxy for similarity between rows. Use feature-space distance where it fits.
• Reranking rows needs a task-aware score. A text reranker trained on documents is not a drop-in choice.
• Leakage is a real risk. Never retrieve rows that contain the answer for the row being evaluated.
• Row data can be sensitive. Apply access filters before results reach the prompt.

See /model/architecture, /model/research and /model/benchmarks for background on how such models are built and measured.

Practical guidance and best practices

Add one technique at a time

Run the test set after each change. Keep what helps and remove what does not. A pipeline with seven techniques where only three help is slower and harder to maintain.

A sensible order is:

1. Fix parsing and chunking.
2. Add metadata and filters.
3. Add hybrid search.
4. Add reranking.
5. Add query rewriting for conversational use.
6. Add compression and ordering if context is long.
7. Add decomposition or HyDE only for question types that need them.

Build a real test set

Collect real user questions. For each, record the gold passage and a reference answer. Include hard cases: exact codes, follow-ups, multi-part questions and questions with no answer in the corpus. Review the set regularly.

Measure each stage

Tools such as RAGAS and TruLens provide several of these metrics, and an LLM-as-judge can scale faithfulness checks. Review a sample by hand to keep the judge honest.

Retrieve wide, then narrow

Use a generous candidate pool, then cut with a reranker. Retrieving only five items and reranking them cannot fix a recall problem. Retrieving fifty and reranking to five often can.

Keep rewriting conservative

Tell the rewriting prompt to keep names, codes and numbers exactly. Compare original and rewritten queries in the logs. If rewriting hurts a class of questions, skip it for that class.

Choose a reranker by testing

Try a lightweight cross-encoder first. Measure the gain and the added latency. A larger reranker may help only slightly. If latency is tight, rerank fewer candidates.

Be careful with compression

Prefer extractive compression, which keeps original sentences, over summaries that may rewrite facts. Check that numbers, dates and negations survive.

Protect the pipeline

• Filter by access rights before ranking.
• Treat retrieved text as data, never as instructions. See prompt injection defense.
• Add guardrails on inputs and outputs.
• Log enough to audit an answer, while respecting privacy rules.

Control cost and latency

• Use small models for rewriting and classification.
• Cache rewritten queries, embeddings and frequent answers.
• Run dense and keyword searches in parallel.
• Set timeouts on each stage and fall back to the previous stage's result if a stage fails.

Frameworks

Libraries such as LlamaIndex and LangGraph offer building blocks for these stages. Use them for speed, but keep the logic readable so that you can test each part.

Common mistakes

• Adding many techniques at once and being unable to tell which one helped.
• Judging by a few demo questions instead of a real test set.
• Rewriting queries without checking that names and codes survive.
• Reranking too few candidates, so the gold passage never enters the pool.
• Reranking too many candidates with a heavy model and blowing the latency budget.
• Using keyword and dense scores directly without normalising or using rank fusion.
• Compressing so hard that numbers, dates or negations are lost.
• Ignoring metadata, then wondering why old versions of a document are returned.
• Applying access control after the model has seen the text.
• Forgetting to re-index after a change of embedding model.
• Letting HyDE write a confident fake answer that pulls retrieval toward the wrong topic.
• Tuning on the same few questions until the pipeline overfits.
• Not logging intermediate results, which makes failures hard to diagnose.
• Treating the pipeline as finished. Data, users and models change, so evaluation must continue.

Frequently asked questions

What is advanced RAG?

Advanced RAG is retrieval-augmented generation with extra steps around retrieval. Before the search it rewrites, expands or routes the query. After the search it reranks, filters and compresses the results. The flow stays fixed, but the evidence that reaches the model is better.

How is advanced RAG different from naive RAG?

Naive RAG embeds the question, fetches the nearest chunks and generates. Advanced RAG keeps that skeleton and adds pre-retrieval and post-retrieval stages, plus better indexing. It targets specific failures such as missed keywords, vague queries and badly ranked results.

Do I need reranking?

Reranking is one of the most reliable upgrades when the right passage is retrieved but ranked low. If your gold passage is usually already at the top, the gain is small. Check where the gold passage lands in your candidate list before adding it.

What is hybrid search and why use it?

Hybrid search combines dense vector search, which matches meaning, with keyword search, which matches exact terms. Dense search misses codes and rare names, and keyword search misses paraphrases. Merging both lists usually gives better recall than either alone.

Is query rewriting always helpful?

No. It helps with conversational follow-ups and vague wording. It can hurt when it changes names, codes or numbers, or when the original query was already clear. Compare original and rewritten queries on your test set and keep the rewrite only where it helps.

What is context compression?

Context compression shortens retrieved text to the parts that matter for the question. It can keep selected sentences or write a summary. It lowers cost and noise, but it can drop a needed detail, so test that important facts survive.

How many candidates should I retrieve before reranking?

A common range is 20 to 100, depending on corpus size and reranker speed. The pool must be large enough that the gold passage is usually inside it, and small enough that reranking stays fast. Measure recall of the pool, not only of the final list.

Does advanced RAG remove hallucinations?

No, it reduces them by supplying better evidence. The model can still ignore the context or stretch weak evidence. Citations, refusal rules and a faithfulness check lower the risk further.

When should I move from advanced RAG to an agent?

Move when failures come from the fixed flow itself, for example questions that need several sources, a SQL query or a second round of search based on the first results. Until then, a fixed pipeline is cheaper, faster and easier to test.

Can I use advanced RAG with tabular data?

Yes, in a supporting role. The same ideas help choose context rows for a tabular model, merge row and document retrieval, and explain predictions with retrieved notes. The table-level learning itself still comes from a tabular model.

Glossary

• Bi-encoder: a model that embeds query and passage separately for fast comparison.
• BM25: a classic keyword ranking function.
• Candidate pool: the set of items retrieved before reranking.
• Chunk: a piece of a document stored and retrieved as a unit.
• Context compression: trimming retrieved text to what matters.
• Cross-encoder: a model that reads a query and a passage together to score relevance.
• Dense retrieval: search using embeddings that capture meaning.
• Embedding: a numeric vector that represents the meaning of text.
• HyDE: embedding a hypothetical answer rather than the raw query.
• Hybrid search: combining dense and keyword search.
• Metadata filter: a rule that limits search by field values.
• Query expansion: adding related terms to a query.
• Query rewriting: turning a raw question into a clear standalone query.
• Reciprocal rank fusion: a method for merging ranked lists.
• Reranker: a second-stage model that reorders candidates.

Summary

Advanced RAG improves a basic retrieve-then-generate pipeline by working on both sides of the retriever. Before retrieval it prepares the index and rewrites or routes the query. During retrieval it blends dense and keyword signals. After retrieval it reranks, deduplicates, compresses and orders the evidence. The flow stays fixed, so cost, latency and behaviour remain predictable.

Add techniques one at a time, measure each against a real test set, and retrieve wide before narrowing. Keep rewriting and compression conservative, and protect the pipeline with access filters and guardrails. For tabular work, apply the same mindset to choose and clean context rows for a tabular foundation model and to attach explanatory documents to its predictions. Continue with Naive RAG, Modular RAG, hybrid search and /model/benchmarks.

Related

It belongs to RAG in my stack, under LLMs, retrieval, and evaluation. Others in the same group: