Corrective RAG (CRAG)

What is Corrective RAG (CRAG)?

Corrective RAG (CRAG) is a retrieval-augmented generation pattern that checks whether retrieved context is good enough before the model answers. If the documents look weak or incomplete, the system can correct course by rewriting the query or falling back to web search.

Understanding Corrective RAG (CRAG)

In a standard RAG pipeline, the retriever finds documents and the generator answers from them. CRAG adds a lightweight evaluation step between those stages, so the system can judge retrieval quality instead of trusting every result equally. The original paper describes a retrieval evaluator that assigns a confidence signal, then triggers different knowledge actions based on that assessment, including web search for broader coverage when a static corpus is not enough. (arxiv.org)

In practice, CRAG is useful when the first search pass is noisy, stale, or only partially relevant. Rather than pushing weak context straight into generation, the workflow can decompose and clean the retrieved material, or reformulate the question and try again. That makes CRAG a good fit for production systems where answer quality depends on whether the retrieved evidence is actually on topic and complete. (arxiv.org)

Key aspects of Corrective RAG include:

1. Retrieval grading: A classifier or evaluator estimates whether the retrieved documents are trustworthy enough for generation.
2. Corrective branching: Low-quality retrieval can trigger query rewriting, document refinement, or a fresh search step.
3. Web fallback: CRAG can widen the search beyond a static corpus when local retrieval is too narrow.
4. Noise filtering: The pipeline can downweight irrelevant chunks before they reach the model.
5. Plug-and-play design: CRAG can be inserted into existing RAG systems without rebuilding the whole stack.

Advantages of Corrective RAG (CRAG)

1. Better answer grounding: The model is less likely to rely on weak or off-target context.
2. More resilient retrieval: The system can recover when the first retrieval pass fails.
3. Smarter use of search: Web search is used selectively, not on every request.
4. Cleaner prompts: Better evidence selection usually means less noisy context in the final prompt.
5. Production-friendly: It fits naturally into agentic and multi-step LLM workflows.

Challenges in Corrective RAG (CRAG)

1. Extra orchestration: You need logic for scoring, branching, and recovery paths.
2. Evaluation quality: The retriever judge must be reliable, or it can misroute good queries.
3. Latency tradeoffs: Query rewriting and web fallback can slow responses.
4. Prompt complexity: More steps often means more prompts to maintain and test.
5. Source consistency: Mixing corpus retrieval with web search can introduce uneven citation quality.

Example of Corrective RAG (CRAG) in Action

Scenario: a support assistant answers questions about a product release from a private knowledge base.

A user asks about a recently changed policy, but the retriever returns older documents and a few loosely related FAQs. CRAG scores that retrieval as low confidence, rewrites the query with the missing policy terms, and searches the web or a broader indexed source for fresher material. The final answer is then generated from the improved evidence set instead of the original weak hits.

That workflow is especially helpful when the first retrieval pass is technically successful but semantically incomplete. In that case, the system does not need a human to notice the mismatch, because the corrective step is built into the pipeline.

How PromptLayer helps with Corrective RAG (CRAG)

PromptLayer helps teams build, inspect, and iterate on CRAG-style workflows by tracking each prompt, branch, and model response across retrieval, rewrite, and generation steps. That makes it easier to compare which fallback path works best, spot retrieval failures, and keep your RAG prompts organized as the pipeline evolves.

Ready to try it yourself? Sign up for PromptLayer and start managing your prompts in minutes.