--- title: "Corrective RAG (CRAG): Retrieval Eval + Web Fallback" description: "Production CRAG: lightweight retrieval evaluator + web-search fallback when documents are weak. Catches bad retrievals before they bleed through. Stack, deploy, benchmarks, our take." source: "https://www.kensink.com/llm/rag/architectures/corrective/" canonical: "https://www.kensink.com/llm/rag/architectures/corrective/" --- ★ Corrective RAG (CRAG) Primary pattern · production default Eval-gated CORRECTIVE RAG · POST-CHECK + WEB FALLBACK # Corrective RAG. When the retrieval is weak, fall back to web search. Yan et al. (2024) introduced an explicit retrieval-evaluation step: after the initial retrieval, a lightweight evaluator rates the retrieved documents. Strong results go to generation; weak results trigger a fallback (web search or query rewrite). The corrective loop catches bad retrievals before they bleed through to bad answers. Tavily Brave Search pgvector Claude Eval pipelines [Start a conversation →](https://www.kensink.com/contact) [All architectures →](https://www.kensink.com/llm/rag/architectures) Best for Time-sensitive · long-tail queries Stack Base RAG + web fallback Trigger Retrieval evaluator confidence Cost Cheap on strong retrievals \[AT A GLANCE\] Best for: Knowledge bases with a long tail of queries the corpus does not cover well. Customer support over an evolving product, news, legal research, academic literature search. Anywhere a confident 'I do not know' is worse than reaching for web evidence. Origin Yan et al., Corrective RAG (2024) Year 2024-2026 Complexity Medium Production stage Mature \[THE PIPELINE\] ## Retrieve, evaluate, fall back if weak. CRAG runs base retrieval, then a lightweight evaluator scores the result. Strong results pass through to generation. Weak results trigger a corrective branch: query rewrite, web search, or escalation to a richer retrieval mode. The corrective branch's evidence is decomposed, refined, and merged with the original (if any). 01 ### Base retrieval Run Advanced RAG over the primary corpus. Returns top-K passages plus their fusion + rerank scores. 02 ### Retrieval evaluator Lightweight model rates the result on confidence (strong / mediocre / weak). T5-base fine-tuned is the original; prompt-only mid-tier LLMs work in production. 03 ### Strong path: use Pass through to generation with the original retrieved passages. No fallback work, no extra cost. 04 ### Weak path: web fallback Trigger Tavily, Brave Search, or similar API. Retrieved web snippets go through decomposition (extract claims) and refinement (filter to query-relevant) before merging with any kept original passages. 05 ### Generate with the corrected context Final answer prompt sees the union of strong original passages and refined web evidence. Citation discipline names each source. \[TECHNICAL STACK\] ## What we'd actually deploy. CRAG stack is Advanced RAG plus a retrieval evaluator plus a web search API. The evaluator is the operational lever; the web search adds external evidence but also external cost and review complexity. BASE RETRIEVAL ### Advanced RAG (hybrid + rerank) CRAG sits on top of normal retrieval. The corrective branch only fires when base retrieval is genuinely weak. RETRIEVAL EVALUATOR ### Claude Haiku or GPT-5.5 (low effort) for prompt-only Cheap classifier-style call rates retrieval strength. Structured output: strong / mediocre / weak with rationale. WEB SEARCH ### Tavily, Brave Search, or Bing Search API Managed web search APIs designed for LLM consumption. We pick per buyer constraint (data residency, content licensing, cost). WEB DECOMPOSITION + REFINE ### LLM-based Web snippets get decomposed (extract claim-level statements) and refined (filter to query-relevant). Keeps the noise of raw web search from poisoning the generation prompt. GENERATION ### Claude or GPT via direct API Citation-required prompt that handles both internal and external evidence. Internal evidence cited to chunk; external to URL. CACHING ### Web search result cache Common weak queries get cached web results to amortise the cost of the corrective branch. Cache TTL aligned to corpus freshness needs. \[HOW WE DEPLOY\] ## Day one to live traffic. CRAG deploys in two phases: get the retrieval evaluator calibrated against the eval set, then plug in the corrective branch. The first phase is harder than it sounds; the second is mostly integration work. 1. 01 ### Advanced RAG baseline Ship the Advanced RAG pipeline first. The eval set tells you which queries actually need a corrective branch vs. which are just naturally weak. 2. 02 ### Retrieval evaluator Lightweight evaluator (LLM call or fine-tuned classifier) rates retrieval strength. Calibrate on the eval set: target precision so we do not trigger fallback on retrievals that were actually fine. 3. 03 ### Web search integration Tavily / Brave / Bing API. Rate limits, cost controls, content-licensing review handled at integration time. 4. 04 ### Decomposition + refinement LLM-based filter on web snippets. Extracts claim-level evidence, drops off-topic noise. Eval-gated against a held-out web-fallback set. 5. 05 ### Caching + cost control Common weak queries cached. Per-query cost budget. Circuit breaker on the corrective branch if the daily web search budget exhausts. 6. 06 ### Eval set including web-fallback cases Eval set explicitly includes queries that should trigger fallback. We grade both the evaluator's decision and the final answer quality with the corrective branch enabled. \[ ACCURACY + BENCHMARKS \] ## What the numbers say. CRAG is most useful where the eval set has a long-tail of queries the corpus does not cover well. The headline metric is fallback precision (did the evaluator pick the right cases?) plus final answer quality on those cases. +10-18% Answer quality on long-tail queries Original CRAG paper + 2025 reports ~5% Production queries that trigger fallback Typical engagement Negligible Added latency on the strong-retrieval path By design $$ Web search cost on triggered cases Operational reality Our eval methodology CRAG eval grades the evaluator's decision (precision and recall on 'should fall back'), the corrective branch quality (web evidence refinement), and the final answer (faithfulness, completeness). We split metrics so a regression in any one component is locatable without rebuilding the whole pipeline. \[COMMUNITY FEEDBACK\] ## What practitioners report. CRAG is becoming a standard add-on to Advanced RAG in 2026 production. The shape is small enough to add to an existing build without restructuring; the win is concrete; the cost on the strong-retrieval path is near zero. Practitioners report the same trade we have seen: most queries do not fire the corrective branch, so the average cost addition is small. The queries that do fire get a meaningful answer-quality lift. The hard work is calibrating the evaluator so we do not over-trigger (paying for web search on queries the corpus actually answered fine) or under-trigger (missing weak retrievals that should have fallen back). \[COMMON PITFALLS\] - Evaluator that over-triggers. Pays for web search on queries the corpus already answered well. - Web evidence not refined. Raw web snippets poison the generation prompt. - Content licensing not reviewed. Some web search APIs have constraints we cannot silently inherit. - No caching. Pays repeatedly for the same long-tail query. \[KENSINK LABS EVALUATION\] ## Our honest take. We reach for CRAG when the corpus has a known long-tail (time-sensitive content, evolving product docs, regulatory updates) and the buyer accepts the web-search dependency. The pattern is cheap on most queries and lifts answer quality on the long tail. We have shipped CRAG on customer-support builds where the product docs lag the product. The corrective branch catches the newly-shipped feature questions before the docs are updated, with web evidence (often the company's own blog or release notes) cited in the answer. That bridges the docs-lag gap operationally without forcing the docs team to publish faster. \[WHEN WE REACH FOR IT\] - Customer support over a fast-moving product where docs lag. - Time-sensitive workloads (news, market data, regulatory updates). - Long-tail knowledge bases with known coverage gaps. - Builds where 'I will check the web' is an acceptable fallback for the buyer. What we'd substitute Self-RAG when the failure mode is bad generation more than bad retrieval. Plain Advanced RAG when the long tail is not material to the workload. \[RELATED PATTERNS\] ## Worth a look next. [Related pattern ### Self-RAG Sibling quality-check loop; CRAG focuses on retrieval, Self-RAG on the answer. Read playbook](https://www.kensink.com/llm/rag/architectures/self-rag/) [Related pattern ### Advanced RAG CRAG sits on top of Advanced; the base retrieval still needs to be strong. Read playbook](https://www.kensink.com/llm/rag/architectures/advanced/) [Related pattern ### Adaptive RAG Adaptive routes per query; CRAG falls back per query. Related shapes. Read playbook](https://www.kensink.com/llm/rag/architectures/adaptive/) \[COMMON QUESTIONS\] ## What buyers ask before they sign. Do we need a fine-tuned retrieval evaluator? No. The original CRAG paper used T5-base fine-tuned; production deployments mostly use a cheap LLM call with a calibrated prompt. Both work; the cheap LLM call is simpler to maintain. Which web search API? Tavily for LLM-friendly snippets; Brave for content-licensing transparency; Bing for raw breadth. Picked per buyer constraint. All three integrate cleanly behind a small abstraction. What about content licensing on web fallbacks? Reviewed at integration time. Some buyers will not accept web search at all (data residency, compliance); for those we fall back to a different mode (query rewrite, escalation to human) instead. CRAG is the pattern, not specifically web search. Self-RAG and CRAG together? Yes, sometimes. CRAG decides whether retrieval was worth keeping; Self-RAG decides whether the answer is worth shipping. Compounded latency and cost, compounded quality on high-stakes workloads. DIRECT RAG · APPLIED K ## Bring the corpus. We'll bring the build. Senior engineers, eval suite at handoff, full source ownership. We integrate against the model and the index the same way we integrate against Postgres. Sized to the work in front of you. [Start a conversation →](https://www.kensink.com/contact) [All RAG topics](https://www.kensink.com/llm/rag)