A corrective RAG design needs an explicit route for sufficient, ambiguous and insufficient evidence. Bound any extra web retrieval and define what happens when the budget is exhausted. A simple three-way router is a useful application pattern, but it is not a complete reproduction of the CRAG paper.
Give each evidence state a different action
| Evidence assessment | Action | Stop condition |
|---|---|---|
| Sufficient and relevant | Generate within accepted evidence | Answer remains inside the support record |
| Ambiguous or conflicting | Review or make a bounded additional query | Conflict resolved or budget exhausted |
| Insufficient | Search/read under a finite budget or abstain | No unsupported claim is emitted |
Make the corrective step accountable
Retain the assessment inputs, the additional query and the sources selected for reading. A model score alone should not erase an unresolved conflict. Validate required passages and dates before admitting new evidence into the context.
Use typed state for attempt count, remaining budget and support status. The accompanying graph fixture demonstrates a finite stop condition; it does not implement every module, dataset or evaluation in the CRAG research paper.
Test the exhausted-budget route
No particular retry count is correct for every application. The page’s contribution is a bounded corrective decision and its acceptance cases, not a claimed answer-quality gain.
- Supply a sufficient fixture and confirm that no additional retrieval is scheduled.
- Supply a conflicting fixture and keep both support records.
- Supply an insufficient fixture with no remaining calls and require an unresolved answer.
- Keep failed extraction separate from a source that was read but did not support the claim.
Reference documentation: arxiv.org — /abs/2401.15884; docs.langchain.com — /oss/python/langgraph/graph-api.
