Corrective RAG (CRAG): Grading Retrieval Before Generating

Corrective RAG (CRAG) is the Yan et al. (2024) architecture that grades retrieved documents with a lightweight evaluator and triggers one of three actions — Correct (refine), Incorrect (web fallback), or Ambiguous (blend both) — before generation. It trades an extra evaluate/correct step, and sometimes a web call, for robustness when retrieval is wrong.

What is Corrective RAG (CRAG)?

Corrective Retrieval Augmented Generation (CRAG) is a plug-and-play pattern introduced by Shi-Qi Yan, Jia-Chen Gu (equal contribution), Yun Zhu and Zhen-Hua Ling in Corrective Retrieval Augmented Generation (arXiv:2401.15884, 2024). It inserts a retrieval-quality gate between retrieve and generate so the generator is not fed irrelevant or misleading top-k hits the way naive retrieve-then-generate does. Official code is published at github.com/HuskyInSalt/CRAG.

The problem CRAG targets is specific: when the retriever is wrong, prepending those documents can worsen hallucinations rather than fix them (Yan et al., 2024, Introduction and Figure 1). That is the same surface practitioners hit as a wrong chunk retrieved or as hallucination despite context — CRAG’s answer is to grade and correct the retrieval set before generation, not to retrain the generator. Orientation across architecture patterns is at RAG architectures; the primary-source card sits in RAG research.

One naming trap up front: CRAG is also the abbreviation for Meta’s Comprehensive RAG Benchmark. That is a different paper and a different job — see the disambiguation section below and RAG benchmarks.

How does Corrective RAG grade retrieval before generating?

CRAG scores every retrieved document against the query with a fine-tuned T5-large retrieval evaluator (about 0.77B parameters), producing a relevance score on [−1, 1] per query–document pair (Yan et al., 2024, §4.2). Those scores are compared to an upper and a lower threshold; the outcome triggers one of three actions.

• Correct — at least one document scores above the upper threshold. CRAG keeps the internal corpus hits and runs decompose-then-recompose knowledge refinement: split documents into strips, re-score strips with the same evaluator, drop weak strips (paper filter threshold −0.5, top strips kept), and concatenate what remains (Yan et al., 2024, §4.3–4.4; Appendix B.3).
• Incorrect — all documents score below the lower threshold. CRAG discards the corpus hits and replaces them with web search knowledge: the query is rewritten into keywords (the paper used a ChatGPT rewrite prompt) and a search API returns pages that are then refined the same way (Yan et al., 2024, §4.3, §4.5; Google Search API in the paper’s experiments).
• Ambiguous — scores fall between the thresholds. CRAG blends refined internal knowledge with web knowledge so neither source has to carry the answer alone (Yan et al., 2024, §4.3).

Thresholds are set empirically per dataset in the paper’s Appendix B.3 — for example PopQA used (0.59, −0.99), PubHealth and Arc-Challenge used (0.5, −0.91), and Biography used (0.95, −0.91). On PopQA, the T5 evaluator’s accuracy at judging overall retrieval quality was 84.3%, ahead of the ChatGPT prompt baselines the authors compared (Yan et al., 2024, §5.5). How information-retrieval metrics quantify the same failure surface is at measuring retrieval; end-to-end LangGraph walkthroughs belong at building a RAG pipeline.

What are Corrective RAG’s capabilities and limits?

No CRAG capability without the ceiling that rides with it. Each row pairs what the pattern gives you with the limit that makes the number usable — so you know what a published accuracy gain does not buy in production.

The two rows that surprise teams first are the mandatory evaluator fine-tune and the web path’s hidden latency. Both get their own treatment below rather than a single cell.

What does Corrective RAG cost in latency and compute?

Yan et al. publish a generation-phase overhead estimate on PopQA (Table 6). Against standard RAG, CRAG rises from 26.5 to 27.2 TFLOPs per token and from 0.363 s to 0.512 s average executing time per instance. Against Self-RAG, Self-CRAG is reported at 27.2–80.2 TFLOPs per token and 0.908 s versus Self-RAG’s 26.5–132.4 TFLOPs and 0.741 s (Yan et al., 2024, Table 6).

Read that table with the authors’ own caveat: retrieval and data-processing stages are not included — so web search, page fetch, and strip filtering sit outside those numbers. When the Incorrect or Ambiguous action fires a web call, production latency is higher than Table 6 and is not published as a single end-to-end figure in the paper. That is the honest cost of the escape hatch: modest generation overhead on the Correct path, and an unbound web path when retrieval fails. Where multi-step RAG budgets break in practice is covered at RAG latency.

How does Corrective RAG compare to Self-RAG?

Both patterns add a quality-control loop; they put the critic in different places. CRAG grades retrieved documents with an external T5 evaluator and can replace a bad retrieval set with web knowledge without retraining the generator (Yan et al., 2024). Self-RAG (Asai et al., 2023) trains the generator with reflection tokens to decide when to retrieve and to critique passages and outputs — which means instruction-tuning is part of the product. Yan et al. report that Self-RAG’s advantage collapses on untuned LLaMA2-hf-7b while CRAG stays competitive, because CRAG does not require the generator to emit special critic tokens (§5.3).

The paper also couples the two as Self-CRAG. On SelfRAG-LLaMA2-7b, Self-CRAG versus Self-RAG improves PopQA by 6.9 percentage points, Biography FactScore by 5.0, and PubHealth by 2.4 percentage points (Yan et al., 2024, §5.3). Depth on reflection tokens is at Self-RAG.

• Agentic RAG — a broader control loop that may choose whether, what and how many times to retrieve (and which tools to call). CRAG is one corrective gate; agentic systems can embed that gate among other decisions — agentic RAG.
• Speculative RAG — draft-and-verify for speed rather than a retrieval grader for trust. Different optimisation target — speculative RAG.

Which pattern wins for a given corpus is not this profile’s call. Start from the failure you actually have: indiscriminate top-k is the naive RAG baseline CRAG was designed to harden.

When should you use Corrective RAG?

Use Corrective RAG when your dominant failure is bad or incomplete retrieval that still reaches the generator, and you can afford an evaluate/correct step — plus an occasional web call. That is the fit: open-domain or stale static corpora, high cost of a confidently wrong answer, and a retriever you want to keep while adding a plug-in gate (the shape secondary guides describe as when CRAG earns its complexity).

Skip or constrain it when latency budgets cannot absorb even the published generation bump (+0.149 s on the paper’s PopQA CRAG vs RAG timing) plus an unbound web path; when you cannot fine-tune or monitor an external evaluator (Yan et al., 2024, §6); or when private documents must not leave the perimeter via web search. Implementing the graph end-to-end is building a RAG pipeline.

Is Corrective RAG the same as the CRAG benchmark?

No. Corrective RAG / CRAG (Yan, Gu, Zhu and Ling, 2024; arXiv:2401.15884) is an architecture that grades and corrects retrieval before generation. The Comprehensive RAG Benchmark — also abbreviated CRAG (Yang et al., Meta; arXiv:2406.04744; KDD Cup 2024) — is an evaluation suite for open-domain factual RAG with mock search APIs. Same four letters; different papers; different jobs. Live search for “yan et al crag” surfaces both, which is why the collision belongs on this page. What the Meta benchmark measures is at RAG benchmarks; the architecture paper card is at RAG research.