Self-RAG и Corrective RAG: как работает самопроверка в RAG

Self-RAG — работа, впервые выложенная на arXiv 17 октября 2023 года и затем опубликованная на ICLR 2024; Corrective Retrieval-Augmented Generation (CRAG) — статья, появившаяся на arXiv 29 января 2024 года. Обе работы пытаются решить одну и ту же практическую проблему: в RAG ошибается не только генератор, но и сам retrieval, а значит «подкладывание источников» не гарантирует фактологичность. Ниже — обзор именно этой волны работ 2023–2024 годов, без подмены темы более поздними agentic-RAG пайплайнами 2025–2026 годов. Главное различие простое: Self-RAG встраивает самокритику внутрь генерации, а CRAG выносит проверку в отдельный модуль вокруг retrieval.

Контекст

Классический RAG в формулировке Lewis et al. из NeurIPS 2020 усиливает генератор внешними документами: retriever находит релевантные фрагменты, а модель отвечает с их учетом. Это решает часть проблем параметрической памяти, но создает новую: если найденный контекст нерелевантен, устарел или просто шумный, модель может стать не точнее, а увереннее в ошибке.

К 2023 году стало ясно, что retrieval не обязан быть одноразовым и фиксированным. Работа Active Retrieval Augmented Generation показала, что retrieval можно вызывать по ходу длинной генерации, когда это действительно нужно. Но даже такой шаг не отвечает на два вопроса, которые и стали центральными для Self-RAG и CRAG: когда retrieval вообще нужен и что делать, если retrieved context плохой.

Исторически Self-RAG и CRAG удобно читать вместе. Self-RAG решает проблему изнутри модели: генератор учится не только отвечать, но и высказывать суждение о полезности retrieval и об опоре ответа на источник. CRAG решает проблему снаружи: предполагается, что retrieval уже сработал, но его результат нужно проверить, исправить и только потом отдавать генератору.

Метод

Как устроен Self-RAG

В статье Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection модель расширяет словарь специальными reflection tokens. Таблица 1 работы перечисляет четыре группы токенов: Retrieve решает, нужен ли retrieval сейчас; ISREL оценивает релевантность passage; ISSUP оценивает, насколько passage поддерживает уже сгенерированный фрагмент; ISUSE оценивает общую полезность ответа.

Архитектурно это не просто «сначала поиск, потом ответ». Self-RAG разбивает генерацию на сегменты и на каждом шаге может выбрать один из режимов: не искать вовсе, запросить документы, продолжить генерацию с учетом уже найденного контекста, а затем ранжировать кандидатов по комбинации обычной вероятности и вероятностей reflection tokens. Важная деталь: в training loop участвуют две модели — critic и generator; на inference сам generator уже должен уметь предсказывать reflection tokens без внешнего критика.

Практический смысл такой: Self-RAG пытается научить модель экономить retrieval там, где он не нужен, и строже наказывать ответы, слабо поддержанные источником, там, где он нужен. Это делает метод ближе к управляемой политике генерации, чем к обычному «обвесу» вокруг RAG.

Как устроен Corrective RAG (CRAG)

В Corrective Retrieval Augmented Generation центр тяжести другой. Здесь вводится отдельный retrieval evaluator, и в статье для него используется дообученный T5-large. Его задача — оценить, хороши ли retrieved documents для данного запроса, и отнести ситуацию к одному из трех действий: Correct, Incorrect или Ambiguous.

Если срабатывает Correct, CRAG не отправляет документы в генератор как есть, а запускает refinement: документ декомпозируется на более мелкие полосы знания, нерелевантные части фильтруются, а полезные — recomposed обратно в компактный контекст. Если срабатывает Incorrect, исходный retrieval отбрасывается, запрос переписывается в более поисковую форму, и дальше подключается веб-поиск. Если срабатывает Ambiguous, система смешивает внутреннее и внешнее знание.

Поэтому CRAG — это не «самокритика ответа» в строгом смысле, а «коррекция входного знания до генерации». Авторы прямо позиционируют метод как plug-and-play надстройку над существующими RAG-подходами и отдельно показывают режим Self-CRAG, где corrective layer ставится поверх Self-RAG.

Ключевое различие в одной таблице

Вопрос	Self-RAG	CRAG
Где живет проверка	Внутри генератора через reflection tokens	Во внешнем retrieval evaluator
Что проверяется первым	Нужен ли retrieval и насколько passage поддерживает ответ	Насколько хорош весь набор retrieved documents
Что нужно дообучать	Generator и critic-пайплайн под reflection tokens	Отдельный evaluator; генератор можно оставить прежним
Что происходит при плохом контексте	Модель может не искать, искать заново или менять выбор passage при ранжировании	Исходный retrieval исправляется через refinement, query rewrite и web search
Инженерный профиль	Ближе к model-level adaptation	Ближе к modular RAG engineering

Результаты

Сравнивать две работы напрямую не идеально: у Self-RAG в основной статье шесть задач и больше метрик, а у CRAG — четыре датасета. Но у них есть общая зона пересечения: PopQA, Biography с FactScore, PubHealth и ARC-Challenge. Это позволяет хотя бы частично сопоставить методы в общей системе координат. Для сопоставимости CRAG использует retrieval results, предоставленные пайплайном Self-RAG на базе Contriever.

Общая задача	Метрика	Self-RAG 7B	Self-CRAG на том же backbone
PopQA	Accuracy	54.9	61.8
Biography	FactScore	81.2	86.2
PubHealth	Accuracy	72.4	74.8
ARC-Challenge	Accuracy	67.3	67.2

Числа для строки Self-RAG 7B совпадают в статье Self-RAG и в таблице baseline статьи CRAG. Числа для Self-CRAG в этой таблице я привожу только по статье CRAG, то есть как авторскую оценку без независимой репликации в используемых здесь источниках. Из них видно важное: corrective layer дает заметный выигрыш не везде одинаково. На PopQA и Biography прибавка в отчете авторов CRAG выглядит существенной, на PubHealth — умеренной, а на ARC-Challenge улучшения уже нет.

Есть и еще один показательный результат, который тоже нужно читать осторожно. В отдельном эксперименте авторы CRAG сообщают, что их retrieval evaluator на PopQA точнее различал качество retrieval, чем промптованный ChatGPT: 84.3 против 58.0, 62.4 и 64.7 для трех вариантов prompting. Это полезный сигнал в пользу специализированного evaluator, но сравнение проведено внутри одной статьи и без внешней репликации.

У Self-RAG своя сильная сторона проявляется не только в accuracy. В основной работе авторы показывают, что метод улучшает citation precision и recall на ASQA и позволяет регулировать поведение на inference через веса критериальных токенов и порог retrieval. Для практики это значит, что Self-RAG задуман не просто как способ «поднять score», а как способ управлять компромиссом между опорой на источник, полнотой ответа и частотой retrieval.

Интерпретация

Наш комментарий

На наш взгляд, Self-RAG и CRAG лучше понимать не как прямых конкурентов, а как ответы на разные точки отказа в RAG-системе. Self-RAG спрашивает: может ли генератор сам дисциплинировать себя и retrieval-процесс, если обучить его правильным внутренним маркерам? CRAG спрашивает: можно ли считать retrieval недоверенным модулем и поставить перед генератором «санитарный кордон»?

Из этого следует практический выбор. Если у вас есть контроль над весами модели, пайплайном дообучения и желание встроить поведение проверки внутрь самой генерации, Self-RAG выглядит более цельным направлением. Если же у вас уже есть работающий RAG на API-модели или на стандартном open-weight генераторе, CRAG-подход часто проще ментально: вы не переписываете генератор, а добавляете evaluator, query rewrite, refinement и альтернативный поиск.

Еще один важный вывод: обе работы показывают, что «самопроверка» в RAG редко сводится к одному judge prompt. В сильных вариантах она почти всегда включает структуру: отдельные сигналы, отдельные действия и отдельную политику обработки плохого контекста.

Ограничения

• Self-RAG не бесплатен в интеграции. Метод требует специального обучения generator на reflection tokens и отдельного critic-пайплайна для подготовки данных. Это не тот случай, когда можно просто взять любой LLM и добавить один системный промпт.
• CRAG тоже не «безобиден» инженерно. Статья прямо признает, что без fine-tuning внешнего evaluator не обойтись. Кроме того, в репозитории используется сторонний Google Search API-провайдер, а значит поведение системы зависит от внешнего сервиса и меняющегося веба.
• Репликация не полностью стабильна во времени. Репозиторий CRAG отдельно предупреждает, что для Bio/FactScore авторские результаты считались через text-davinci-003, который позже был снят с поддержки; современные повторы могут давать другие значения.
• Набор задач узок относительно реального enterprise-RAG. В статьях есть open-domain QA, fact verification, biography generation и ARC-style reasoning, но почти нет таблиц, PDF с шумным парсингом, многошаговых tool-use сценариев и мультимодального retrieval.
• Самокоррекция не универсальна. Вне RAG-контекста работа Large Language Models Cannot Self-Correct Reasoning Yet показывает, что prompted self-correction без внешней обратной связи часто слаба. Self-RAG частично обходит это ограничение, потому что опирается на retrieval и supervised reflection tokens, но это не доказательство общей способности LLM «проверять себя» на любых задачах.
• Издержки измерены неполно. CRAG оценивает generation-phase overhead отдельно, но retrieval, web search и data processing вынесены за скобки. У Self-RAG стоимость тоже плавающая, потому что зависит от частоты retrieval и segment-level decoding.

Заключение

Self-RAG и CRAG важны не потому, что «победили RAG», а потому что четко сформулировали два разных способа сделать его надежнее. Первый способ — научить сам генератор решать, когда искать и чему верить. Второй — считать retrieval потенциально ошибочным и исправлять его до генерации. Для практиков это полезная развилка: выбирать нужно не по модному названию, а по тому, где у вас реально находится точка отказа — в модели, в retriever или в инженерной обвязке вокруг них.

Источники

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Active Retrieval Augmented Generation
• Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
• GitHub — AkariAsai/self-rag
• Corrective Retrieval Augmented Generation
• GitHub — HuskyInSalt/CRAG
• Chain-of-Verification Reduces Hallucination in Large Language Models
• Large Language Models Cannot Self-Correct Reasoning Yet

FAQ

Self-RAG и CRAG решают одну и ту же задачу?

Частично. Обе работы повышают надежность RAG, но Self-RAG встраивает проверку внутрь генерации, а CRAG исправляет качество retrieved context до генерации.

Можно ли внедрить идеи CRAG без переобучения генератора?

Да, в этом его главный инженерный плюс. Но без отдельного evaluator и без инфраструктуры refinement/search такой пайплайн не получится.

Заменяет ли Self-RAG обычный judge-подход поверх готового ответа?

Скорее нет. Self-RAG не просто «судит» финальный ответ, а учит модель принимать решения о retrieval и опоре на источник в процессе самой генерации.

Что выбрать для production-RAG?

Если у вас есть доступ к fine-tuning и вы хотите model-level контроль, смотрите на Self-RAG-подобные идеи. Если у вас уже есть рабочий RAG и боль в первую очередь в плохом retrieval, CRAG-подход обычно ближе к реальной интеграции.

Читайте также

• Длинный контекст против RAG: кто побеждает на практике
• Test-time compute: почему вычисление во время ответа стало новой осью масштабирования
• Repeated sampling: дешёвый способ поднять качество LLM