Your pipeline works. Then real users arrive and it fails in ways lesson 7 never anticipated: it retrieves policy text to answer "thanks, bye"; it answers confidently from chunks that were only vaguely related; it cannot handle a question whose answer lives in two documents connected by a person's name. Each of those failures has a named fix — Self-RAG, Corrective RAG, multi-hop, agentic RAG, GraphRAG — and interviewers use these names to check whether you know the vocabulary. This lesson is that vocabulary, plus the judgment about when to not use it.
Four failures basic RAG cannot fix
Classic RAG makes three hard assumptions: every question needs retrieval, one retrieval is enough, and whatever comes back is good enough to answer from. Real traffic breaks all three:
| Failure | What basic RAG does | The named fix |
|---|---|---|
| "thanks, that helps!" | retrieves policy chunks anyway and answers oddly | Self-RAG (decide whether to retrieve) |
| Retrieved chunks are only vaguely related | answers from them confidently | Corrective RAG (grade, then act) |
| Answer needs two linked facts | retrieves once, misses half the answer | multi-hop / agentic RAG |
| "How are these two entities connected?" | returns chunks that each mention one entity | GraphRAG |
Self-RAG — the model reflects on its own process
Self-RAG adds self-reflection at three points: do I need to retrieve for this turn?, is this retrieved chunk actually relevant?, and is my draft answer supported by what I retrieved? Instead of a fixed pipeline, the model gets a say in its own control flow.
The first check alone is worth a lot in production: it stops the bot performing a database search to answer "good morning", which saves latency, cost and a class of strange answers. The last check — grading its own draft for groundedness — is what turns "hopefully grounded" into "checked before sending".
Corrective RAG — a quality gate before generation
CRAG puts a grader between retrieval and generation: score the retrieved chunks, and if they're poor, do something else instead of ploughing ahead — rewrite the query and retry, widen to another source (web search, a different index), or refuse honestly.
def corrective_answer(question, attempt=0):
chunks = retrieve(question, k=5)
good = [c for c in chunks if is_relevant(question, c)] # cheap LLM grader
if good:
return generate(question, good)
if attempt == 0:
return corrective_answer(rewrite_query(question), attempt + 1)
return "I don't have that information - please contact support."Three production details hide in those seven lines: the grader is a cheap model (it runs k times per query), the retry is capped (no infinite loops), and the last branch refuses rather than degrading to memory. Bad retrieval no longer guarantees a bad answer.
Wait — some questions can't be searched in one go
"Did the manager who approved invoice #4471 also sign off the vendor-onboarding policy?" You cannot write that as one search. You must find who approved #4471 first — and only then can you write the second query, using a name you didn't have a moment ago.
This is multi-hop retrieval, and no amount of embedding quality or top-k fixes it: it's a control-flow limitation, not a ranking one. Which leads directly to the next idea.
Agentic RAG — retrieval becomes a tool, not a step
In classic RAG, retrieval is a fixed pipeline stage: always once, always from one index. In agentic RAG, retrieval becomes a tool the model can choose to call — zero, one, or several times, across several sources — with the model deciding after each result whether it has enough.
That single change handles multi-hop questions, mixed questions ("compare our policy with the client's contract"), and no-retrieval-needed turns, all with one mechanism. It also multiplies latency, token cost and failure modes — an agent that loops badly can run up a bill and still answer nothing. Bounded loops and step limits are mandatory, which is the whole subject of the AI Agents course.
GraphRAG — when the answer is a relationship
Chunks capture text. Some questions are about relationships: "which suppliers share a director with a blacklisted firm?", "summarize everything connecting these two projects". No single chunk contains that answer, so top-k similarity retrieves passages that each mention one piece of it.
GraphRAG extracts entities and relationships from the documents into a knowledge graph, then retrieves paths and community summaries rather than isolated passages. The payoff is real for connection-style and whole-corpus-summary questions. The cost is also real: entity extraction over the whole corpus is expensive, the graph needs maintenance, and for ordinary policy Q&A it's pure overkill.
The cost of clever — the answer that impresses
Every technique here adds LLM calls, latency, cost, and new ways to fail. A Self-RAG + CRAG + multi-query + reranking pipeline can be three times slower and five times more expensive than the lesson-7 version — and, if the real problem was bad chunking, no better.
Name the variants, then say you'd add one only after evaluation shows the specific failure it fixes. That sentence is worth more in an interview than reciting all five, because it's what separates someone who reads papers from someone who ships systems.
Selection-round radar: "Have you used advanced RAG techniques?" is best answered as: name Self-RAG, CRAG, multi-hop/agentic and GraphRAG in one line each → say which failure each addresses → close with "I'd measure first and add the one the data justifies." Product-company follow-up: "which would you add to a bot that answers confidently from irrelevant chunks?" — answer: CRAG's relevance gate (plus a reranker).
Common mistakes
- Adding advanced variants before fixing chunking, hybrid search and reranking — the cheaper wins.
- Stacking three techniques at once, so nobody can tell which helped.
- Uncapped retry/agent loops — latency spikes and runaway cost.
- Using an expensive model as the relevance grader; it runs several times per query.
- Reaching for GraphRAG on a corpus where nobody asks relationship questions.
- Treating "agentic" as a quality upgrade rather than a control-flow change with real costs.
Quick recap
| Technique | One-liner | Use when |
|---|---|---|
| Self-RAG | model decides whether to retrieve and critiques its own answer | mixed traffic; groundedness must be checked, not assumed |
| Corrective RAG | grade chunks; rewrite, widen or refuse when they're poor | answers built on irrelevant context |
| Multi-hop | second query written from the first result | answers that join two linked facts |
| Agentic RAG | retrieval as a tool the model calls as needed | open-ended questions, several sources |
| GraphRAG | entities and relations, retrieve paths not passages | relationship and corpus-summary questions |
| The rule | measure first; add the one variant the data justifies | always |
Practice Zone — PYQs from real selection rounds
Six MCQs and two tasks — implement a relevance gate, then match four real failures to the right upgrade (one of them isn't a retrieval problem at all).
Self-RAG adds which capability to a basic pipeline?
Asked in
Corrective RAG (CRAG) is best described as:
Asked in
Which question fundamentally requires multi-hop retrieval?
Asked in
Agentic RAG differs from classic RAG mainly because:
Asked in
GraphRAG (knowledge-graph-augmented retrieval) is most valuable when:
Asked in
What is the honest engineering trade-off of these advanced variants?
Asked in
Hands-on tasks:
Implement the core of Corrective RAG: grade retrieved chunks with an LLM and branch — answer if good, rewrite-and-retry if not, refuse after one retry. Sketch it in code.
Asked in
Match the failure to the right upgrade: 1) The bot answers chatty greetings by quoting random policy text. 2) Users ask questions whose answers span two documents linked by a person's name. 3) Retrieval often returns loosely-related chunks and the bot answers from them anyway. 4) Answers are correct but users can't tell which of the 5 pasted chunks was used.
Asked in
FAQ
Is 'agentic RAG' just RAG with extra steps?
It's RAG with decisions. The model chooses whether, where and how often to retrieve instead of following a fixed pipeline. That flexibility solves multi-hop and mixed questions, and costs latency, tokens and predictability — a genuine trade, not marketing.
What is CAG (Cache-Augmented Generation)?
Preloading a small, stable corpus directly into the model's context (with prompt caching) instead of retrieving per query. Viable when the knowledge is small and rarely changes; it doesn't replace RAG for large or fast-moving corpora.
How do I decide which advanced technique my system needs?
Build the evaluation first (lesson 9), then read the numbers: low recall@k → retrieval fixes; high recall but low faithfulness → CRAG/Self-RAG or prompt work; failures concentrated in multi-part questions → multi-hop.
Next lesson: the measurement that makes every decision above possible — Lesson 9: Evaluating RAG →