Match each advanced RAG variant to its defining mechanism

Match pairs·Medium·4.0 · 0·~2 min·Asked atCred Pinterest Promptlayer

Attempt it

Drag each answer to line up with its matching prompt

Self-RAG

Routes each query to a strategy sized to its complexity: no retrieval, single shot, or iterative multi-step

CRAG (corrective RAG)

Builds a knowledge graph with community summaries so it can answer global, aggregative questions across the corpus

GraphRAG

A lightweight evaluator grades retrieved chunks and triggers correction or a web search fallback when they are weak

Adaptive RAG

The model emits reflection tokens that decide on the fly whether to retrieve and whether to critique its own output

These four are all upgrades to the plain retrieve then generate loop, but each one changes a different part of it. The trick to matching them is to ask what part of the pipeline each variant touches. **Self-RAG** changes the generator. The model is trained to emit special reflection tokens that let it decide, mid-generation, whether it even needs to retrieve, and after generating, whether its own output is actually supported by the evidence. The model critiques itself. CRAG, short for corrective RAG, adds a separate judge. A lightweight evaluator scores the retrieved chunks; if they look weak or irrelevant, it triggers a correction step or falls back to a web search to get better evidence before generating. GraphRAG changes the index itself. Instead of a flat pile of chunks, it builds a knowledge graph and precomputes summaries of the graph's communities, which lets it answer broad, whole-corpus questions like "what are the main themes here?" Adaptive RAG changes the routing. It looks at each query first and sends it down a path sized to its difficulty: answer directly with no retrieval for easy questions, single-shot retrieval for medium ones, iterative multi-step retrieval for hard ones.

The clean way to match these is by the part of the RAG loop each variant rethinks. Three of them add a decision step around an otherwise normal retrieve then generate flow; one of them rebuilds the index. **Self-RAG** puts the decision inside the model. Through trained reflection tokens, the model decides on the fly whether retrieval is needed. It then critiques whether its own generation is supported by the retrieved passages. The judge and the generator are the same model. CRAG puts the decision in a separate component. A lightweight retrieval evaluator grades the chunks that came back. When they are weak it triggers corrective action: refining the retrieved knowledge, or falling back to web search, so the generator is not handed bad evidence. The judge is external to the generator. Adaptive RAG puts the decision at the front door. A classifier routes each query to a strategy matched to its complexity. The choices are no retrieval for questions the model already knows, single-shot retrieval for straightforward fact lookups, and iterative multi-step retrieval for multi-hop questions. It is about spending the right amount of effort per query. GraphRAG is the odd one out because it does not add a runtime decision — it changes the offline index. It extracts entities and relationships into a knowledge graph and precomputes community summaries, which lets it answer global, aggregative questions that flat top-k handles poorly. Matching it correctly hinges on spotting that it is an indexing change, not control flow.

TL;DR

Self-RAG self-critiques with reflection tokens, CRAG grades chunks with a web fallback, GraphRAG indexes a knowledge graph for global questions, and Adaptive RAG routes each query by complexity.

Memory aid

Easy to grasp

Imagine four students writing a report from library books. The first student (Self-RAG) keeps stopping to ask herself out loud, 'do I even need to look this up? Is what I just wrote actually supported?' — checking her own work as she goes. The second (CRAG) hands each book to a helper who skims it and says 'this one's useless, go ask the internet instead.' The third (GraphRAG) doesn't just grab books; he first draws a giant map of how every character and idea connects, so he can answer big-picture questions like 'what are the main themes?' The fourth (Adaptive RAG) sizes up each question first: easy ones he answers from memory, medium ones need one book, hard ones need several rounds of digging. Same goal, four different habits.

Key concepts

Retrieval-Augmented Generation Agents

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Advanced RAG variants are a favorite interview topic because the names sound similar and the marketing blurs them together, yet the underlying mechanisms are genuinely distinct. A candidate who has only skimmed blog posts will say all four are "agentic RAG that adds a smart loop" and stop there. A candidate who understands the field can name exactly what each one changes and why.

The key to keeping them straight is a single organizing question: which part of the retrieve then generate loop does this variant intervene in? Once you have that axis, the four stop being a memorization exercise and become four answers to four different design problems — when to trust the model's own judgment, when to add an external check, when to vary effort per query, and when the flat index itself is the limitation.

This deep dive establishes that axis, then walks each variant in turn, pays special attention to the Self-RAG versus CRAG confusion that trips up most candidates, and shows how the control-flow variants can be combined while GraphRAG sits in a category of its own.

The organizing axis: where does the variant intervene?

Plain RAG is a fixed pipeline: embed the query, retrieve top-k chunks, stuff them in the prompt, generate. Every advanced variant changes one part of that pipeline, and naming the part is the whole game.

There are four places to intervene. You can change the generator so it makes decisions about retrieval and grounding itself — that is Self-RAG. You can add an external evaluator that sits between retrieval and generation and judges chunk quality — that is CRAG. You can add a router at the front that decides how much retrieval each query deserves — that is Adaptive RAG. Or you can change the index itself so the retrieval substrate supports new kinds of questions — that is GraphRAG.

Three of these are control-flow patterns: they wrap logic around an otherwise standard retrieve and generate flow and change what happens at runtime. The fourth, GraphRAG, is structural: it changes what gets built offline, before any query arrives.

The four runtime shapes can be sketched as a single dispatch so the contrast is concrete rather than verbal:

python

def answer(query, index):
    # Adaptive RAG: route on complexity BEFORE retrieving
    plan = classify_complexity(query)          # none | single | iterative
    if plan == "none":
        return generate(query)                 # skip retrieval entirely

    chunks = retrieve(query, index)

    # CRAG: an EXTERNAL evaluator grades the chunks
    if grade(chunks) == "weak":
        chunks = web_search_fallback(query)    # reach outside the index

    # Self-RAG: the GENERATOR itself self-critiques via reflection tokens
    draft = generate_with_reflection(query, chunks)
    if draft.support_token == "unsupported":
        return abstain()
    return draft

# GraphRAG is NOT in this function: it changes how `index` was built
# offline (knowledge graph + community summaries), not the runtime flow.

Self-RAG: the model judges itself

CRAG: an external grader with a web fallback

Adaptive RAG and the GraphRAG outlier

These are not mutually exclusive — composing the patterns

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Variant	Where it intervenes	Who decides	Signature mechanism
Self-RAG	Generator	The model itself	Trained reflection tokens that gate retrieval and self-critique
CRAG	Between retrieval and generation	Separate evaluator	Grade chunks; web-search fallback when weak
Adaptive RAG	Router at the front	Complexity classifier	Route to none / single-shot / iterative retrieval
GraphRAG	Offline index	No runtime decision	Knowledge graph + precomputed community summaries

Real products, models, and research that use this idea.

Self-RAG's reflection-token training is the basis for self-critiquing assistants that abstain when evidence is missing instead of confidently hallucinating
CRAG-style chunk grading with a web-search fallback ships in production RAG stacks that must answer even when the private index has a gap

What an interviewer would ask next. Try answering before peeking at the approach.

QSelf-RAG needs trained reflection tokens. Why is that a deployment barrier compared with CRAG?

Self-RAG requires fine-tuning the generator to emit and respect the special tokens, so you cannot apply it to a frozen model without that training run. CRAG's evaluator is a separate lightweight model, so it bolts onto an existing pipeline with no change to the generator — a real advantage when you cannot retrain the base model.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Blurring Self-RAG and CRAG because both add a quality check — the difference is who judges: Self-RAG's own model via reflection tokens versus CRAG's separate lightweight evaluator that can trigger a web fallback.

60 second bullets to scan on the way to the call.

What reflection tokens do in Self-RAG and who acts as the judge
What CRAG's evaluator grades and what corrective actions it can trigger

Primary sources. Browse if you want the original framing.