CRAG — Corrective RAG
CRAG в 2026 полезно понимать как corrective retrieval policy. Базовая мысль очень здравая: retrieved documents не надо принимать на веру. Система сначала оценивает, насколько retrieval действительно годится для ответа, и только потом решает, отвечать по найденному, очищать контекст, искать дополнительно или честно отказываться.
Это делает CRAG важной промежуточной ступенью между обычным 2-step RAG и более дорогими agent workflows.
1. Какую проблему решает CRAG
Обычный RAG имеет опасный implicit assumption:
если retriever вернул top-k, значит по ним можно отвечать.
На практике это не так. Часто бывает:
- найдено что-то похожее, но не то;
- документы частично релевантны;
- ответ есть только наполовину;
- в базе ответа нет вовсе.
CRAG делает шаг назад и говорит: retrieval — это hypothesis, а не truth.
2. Что именно добавляет corrective layer
Минимально — evaluator, который определяет:
- retrieval good enough;
- retrieval partially useful;
- retrieval insufficient / bad.
После этого уже можно запускать разные routes:
- direct answer;
- answer after context refinement;
- fallback retrieval;
- web search;
- abstain / escalation.
Именно это делает CRAG operationally полезным: он не пытается быть “умным агентом”, но уже перестаёт быть слепым pipeline.
3. Decompose-then-recompose остаётся сильной идеей
Одна из полезных частей original CRAG — не просто оценить документ целиком, а разложить retrieved text на smaller knowledge units и собрать обратно только то, что реально относится к вопросу.
В 2026 эту идею можно понимать шире:
- sentence-level filtering;
- chunk compression;
- quote extraction;
- evidence-only context assembly.
То есть даже если вы не воспроизводите paper буквально, вы всё равно можете использовать CRAG-style context refinement.
4. CRAG — хороший ответ на unstable retrieval, но не на все проблемы
CRAG полезен, если беда в том, что retriever:
- иногда приносит шум;
- иногда приносит partial evidence;
- иногда требует fallback.
Но он не заменяет:
- хороший chunking;
- hybrid retrieval;
- reranking;
- metadata filters;
- access control.
Если baseline retrieval совсем слабый, corrective layer будет только часто говорить, что всё плохо.
5. Чем CRAG отличается от agentic RAG
CRAG:
- проще;
- дешевле;
- локальнее в логике;
- сфокусирован на “trust or don't trust retrieval”.
Agentic RAG:
- шире в orchestration;
- умеет работать с несколькими tools и sources;
- лучше на multi-step задачах;
- дороже в support.
Поэтому CRAG часто полезно использовать как первый upgrade после 2-step RAG, а не сразу прыгать в agentic systems.
6. Чем CRAG отличается от Self-RAG
Self-RAG встроен в trained model behavior.
CRAG чаще реализуется как внешний workflow:
- retrieve;
- evaluate;
- correct;
- answer.
Это делает CRAG проще для real-world adoption:
- не требует специальной модели;
- лучше дебажится;
- легко добавляется поверх существующего retrieval stack.
7. Как применять CRAG practically в 2026
Чаще всего в более простой форме, чем в paper:
- retrieval quality classifier;
- evidence sufficiency gate;
- fallback retriever or web search;
- answer suppression when evidence weak.
Такой corrective layer уже сильно улучшает trustworthiness production RAG без огромной orchestration complexity.
8. Где CRAG особенно оправдан
Хорошо работает в сценариях:
- unstable corpora;
- docs with stale pages;
- internal KB + public docs combos;
- systems, где cost of wrong answer выше cost of abstain.
Менее нужен там, где:
- retrieval already high quality and stable;
- все ответы живут в чистой curated базе;
- latency budget очень жёсткий;
- проще сразу честно переходить в no-answer.
Плюсы
- Добавляет полезный trust gate между retrieval и generation
- Снижает риск отвечать по плохому retrieval
- Хорошо сочетается с fallback retrieval и web search
- Проще внедряется, чем full agentic RAG
Минусы
- Добавляет ещё один decision layer и latency
- Не заменяет strong baseline retrieval
- Требует настройки thresholds и fallback logic
- Слишком агрессивный evaluator может резать полезный контекст