Self-RAG vs Corrective RAG (CRAG): Which Self-Correcting Pattern Should You Use?

Short answer: CRAG fixes the evidence — it evaluates retrieved documents before generation and repairs bad retrieval (e.g. falling back to web search). Self-RAG fixes the reasoning — a fine-tuned model emits reflection tokens to decide when to retrieve and to critique its own output. Use CRAG when you're behind a closed API (GPT-4o, Claude); use Self-RAG when you control an open model you can fine-tune (Llama, Mistral).

The core difference

Both patterns add self-correction to plain RAG, but they intervene at different points in the pipeline.

• CRAG (Corrective RAG) evaluates document quality before generation. A lightweight retrieval evaluator scores each retrieved chunk as correct, ambiguous, or incorrect, then acts: keep good docs, decompose-and-refine ambiguous ones, or trigger a web-search fallback when retrieval is bad. The generator model is untouched.
• Self-RAG critiques its own outputs during and after generation. The model is fine-tuned to emit special reflection tokens — deciding on-the-fly whether to retrieve (Retrieve), whether a passage is relevant (IsRel), whether the generation is supported by evidence (IsSup), and whether it's useful (IsUse). It reflects over the evidence rather than repairing the evidence.

Comparison table

Dimension	CRAG	Self-RAG
What it fixes	Retrieval quality (the inputs)	Reasoning over evidence (the outputs)
Mechanism	External retrieval evaluator + web fallback	Reflection tokens generated by the model
Fine-tuning required	No	Yes — reflection tokens are trained in
Model access needed	Any LLM, including closed APIs	Open weights you can fine-tune
Added cost	One eval step (+ optional web search)	Training cost upfront; more decode tokens at runtime
Best fit	GPT-4o, Claude, closed endpoints	Llama, Mistral you host

When to use CRAG

Reach for CRAG when you cannot fine-tune the generator — which is most production teams on closed APIs. CRAG is a bolt-on: it wraps your existing retriever with an evaluator and a fallback path. Since it needs no fine-tuning and only adds an evaluation step, it's the cheaper and faster pattern to ship. It shines when your failure mode is bad retrieval — stale indexes, thin corpora, out-of-domain queries — because the web-search fallback directly attacks that.

When to use Self-RAG

Reach for Self-RAG when you own the model and can invest in fine-tuning. Because reflection tokens require training, Self-RAG fits open models like Llama and Mistral that you control (customgpt.ai). It shines when your failure mode is unsupported or over-eager generation — the model hallucinating past its evidence, or retrieving when it doesn't need to. The IsSup token gives you an attribution signal per sentence, which is valuable for grounded, auditable answers.

How to combine them

They are complementary and can be stacked. The clean division of labor:

1. CRAG cleans the inputs. Evaluate and repair retrieval — filter junk, refine ambiguous chunks, fall back to web search when confidence is low.
2. Self-RAG reflects on the outputs. Feed the cleaned evidence to the fine-tuned generator, which uses reflection tokens to gate retrieval and verify support.

You get corrected evidence and a model that checks its own work over that evidence.

Implementation notes and gotchas

• CRAG's evaluator is a cost/latency knob. A tiny fine-tuned classifier (T5-scale) is cheap; using a large LLM as judge per query gets expensive fast. Keep the evaluator small.
• CRAG's web fallback needs guardrails. Uncurated web results can inject noise or prompt-injection payloads. Sanitize and re-rank before they hit the generator.
• Self-RAG can't run on GPT-4o or Claude natively. Reflection tokens don't exist in those vocabularies. You can approximate the behavior with a critique prompt, but that's prompted self-reflection, not true Self-RAG.
• Reflection tokens add decode overhead. Every IsRel/IsSup decision is extra tokens generated, so watch throughput on long answers.
• Don't double-pay for retrieval. If you stack them, let CRAG own retrieval and configure Self-RAG's Retrieve token to trust the pre-supplied context rather than re-fetching.

Bottom line: pick CRAG if you're on a closed API and your problem is retrieval; pick Self-RAG if you host the model and your problem is grounding — and stack them when you have both.

Related: more writing.