Retrieval-Augmented Generation

Corrective RAG (CRAG)

Grade retrieval, correct weak context, and know when the extra loop pays off.

Corrective RAG inserts a retrieval-quality evaluator before generation. When context is incomplete, stale, or off-topic, the system can refine, rewrite, search, or abstain — instead of answering from bad evidence.

When to use it Use Corrective RAG when retrieval can fail and wrong answers carry real cost.
How it works Retrieve → grade → refine if correct, rewrite or search if weak → generate from corrected context.
When to skip it Skip for static KBs, tight latency budgets, or environments where external search is not allowed.

System conditions

Tune your retrieval setup, risk profile, and constraints — the recommendation updates live.

Fit recommendation

Score reflects need for a correction loop — not whether your implementation is production-ready.

Correction loop fit: 0

Adjust the controls to calculate a recommendation.

Use Corrective RAG selectively

What drove this result

    Plain RAG

    Control pointUsually at generation time, after retrieval.
    Failure modeBad context can still be used confidently.
    CostLower latency and fewer model or tool calls.

    Corrective RAG (CRAG)

    Control pointBefore generation, via a retrieval evaluator.
    Failure modeWeak context routes to rewrite, search, or abstention.
    CostMore latency, orchestration, and observability overhead.

    Pipeline architecture

    Vertical swimlanes show each CRAG stage — click a node or press Play to walk the correction loop.

    Input Retrieve Evaluate Correct Merge Generate Output ✓ Correct ? Ambiguous ✕ Incorrect User query intent + question Retriever vector / hybrid top-k Retrieval evaluator Refine docs strip noise, keep evidence Rewrite query targeted search form External search web, API, or tool Context refinement merge, filter, validate LLM generator grounded synthesis Answer or abstain Knowledge base LLM / classifier Single active branch

    When to use Corrective RAG

    Add a correction loop when retrieval quality must be validated before the model answers.

    Use

    Open-domain or changing facts

    Market data, policy pages, product docs, incidents, pricing, rules, and facts that drift outside a static vector store.

    Use

    Low recall retrieval

    When the retriever returns adjacent but insufficient chunks, Corrective RAG can flag weak context and route to correction.

    Use

    High cost of hallucination

    Customer support, compliance, finance, healthcare, security, or internal ops where a confident wrong answer is expensive.

    Use

    Mixed internal and external knowledge

    Some questions need internal policy plus fresh external facts. Corrective RAG can merge and refine both before answering.

    Use

    You can observe retrieval failures

    If evals show poor recall, irrelevant passages, or weak faithfulness, Corrective RAG gives a clear place to intervene.

    Use

    Abstention is acceptable

    Corrective RAG shines when the system may say “not enough evidence” instead of forcing an answer from weak context.

    When not to use Corrective RAG

    It is a control loop — skip it when plain RAG already meets your product constraints.

    Avoid

    Very low latency interactions

    If the answer must arrive in a tight real-time budget, extra evaluator, rewrite, and search calls may be too slow.

    Avoid

    External sources are not allowed

    If policy forbids web or tool calls, use stronger internal retrieval, curated fallback docs, or abstention instead.

    Avoid

    Small, stable, well-covered KB

    If your domain is narrow and evals already show strong recall and faithfulness, Corrective RAG may add complexity without benefit.

    Careful

    No trusted correction source

    Correction can hurt quality if web search or fallback corpora are noisier than the original retrieval.

    Careful

    No monitoring or eval loop

    Without logs, metrics, and failure review, the evaluator route can silently become another untested model decision.

    Careful

    Simple routing is enough

    Sometimes a confidence threshold, better chunking, metadata filters, or query expansion fixes the issue more cheaply.

    Real-world scenarios

    Pick a product situation and see whether Corrective RAG is a good fit.

    ← Back to all guides