Corrective RAG (CRAG) — это метод Retrieval-Augmented Generation, описанный в статье 2024 года, который сначала оценивает качество найденных документов, а затем выбирает корректирующее действие, если поиск сработал слабо. В исходной работе это может включать и масштабный веб-поиск, а после поиска применяется шаг decompose-then-recompose, чтобы выделить ключевую информацию и отфильтровать нерелевантный текст.
Английский термин: Corrective Retrieval Augmented Generation. Сокращение: CRAG.
Простыми словами
Грубо говоря, обычный RAG похож на помощника, который берёт первые найденные заметки и сразу пишет ответ. CRAG добавляет ещё одного помощника-проверяющего: он смотрит, насколько эти заметки вообще годятся, и если видит слабую подборку, отправляет систему искать лучше — вплоть до веб-поиска. После этого из найденного материала берутся не все куски подряд, а только те части, которые действительно полезны для ответа.
Для практики это важно по одной причине: в RAG система часто ошибается не потому, что модель «глупая», а потому что в контекст попал шум. CRAG нацелен именно на эту точку отказа — качество найденного контекста.
Как это работает
По исходной статье CRAG улучшает устойчивость RAG двумя основными механизмами: оценкой retrieved-документов и корректирующим retrieval, если исходный поиск слабый. Затем применяется процедура decompose-then-recompose, которая помогает сфокусироваться на ключевых фактах и убрать лишний текст.
Запрос пользователя
↓
Поиск по локальному корпусу
↓
Оценка найденных документов
├─ если качество достаточно → decompose-then-recompose → генерация ответа
└─ если поиск слабый → corrective retrieval
(в статье: в том числе веб-поиск)
↓
decompose-then-recompose
↓
генерация ответа
- Сначала идёт обычный retrieval. Система получает набор фрагментов из корпуса.
- Потом эти фрагменты оцениваются. CRAG не принимает найденный контекст «на веру», а проверяет, насколько он годится для ответа.
- Если контекст слабый, запускается corrective retrieval. В статье прямо указано, что это может включать крупномасштабный веб-поиск, когда поиск по корпусу не справился.
- После этого выполняется decompose-then-recompose. Идея в том, чтобы разложить найденный материал на более полезные части, вытащить главное и пересобрать более чистый контекст.
- Только затем модель генерирует ответ. То есть CRAG вставляет между retrieval и generation дополнительный слой контроля качества.
Это и есть ключевое отличие CRAG от упрощённого RAG-конвейера: метод работает не только с поиском, но и с проверкой результата поиска перед генерацией.
Где применяется
- RAG по внутреннему корпусу, где retrieval часто шумит. Если база знаний возвращает частично нерелевантные документы, CRAG полезен как прослойка оценки и коррекции перед ответом.
- Сценарии, где допустим внешний поиск. В исходной работе corrective retrieval может включать веб-поиск, когда локальный корпус не дал надёжного материала.
- Пайплайны, где важна проверка фактуальности на этапе экспериментов. В официальном репозитории для Bio-оценки авторы отсылают к официальному репозиторию FActScore.
- Исследовательские и инженерные RAG-эксперименты. Официальная реализация покрывает подготовку данных, обучение evaluator-компонента, подготовку знаний, inference и evaluation, то есть метод рассчитан не только на идею из статьи, но и на воспроизводимый пайплайн.
Практический пример
Если вам нужно понять CRAG не по формуле, а как рабочий сценарий, его можно представить так:
- Вы подаёте вопрос в RAG-систему, которая сначала ищет ответ во внутреннем корпусе.
- Вместо немедленной генерации CRAG оценивает качество найденных фрагментов.
- Если этого недостаточно, включается путь подготовки внешних знаний. По официальному репозиторию для этого нужны OpenAI API key и search key; в README упоминается сторонний Google Search API от Serper.dev.
- Далее найденный материал проходит через decompose-then-recompose, чтобы убрать лишние куски и оставить более полезный контекст.
- После этого запускается генерация ответа и последующая оценка результата.
С инженерной стороны официальный репозиторий указывает требование Python 3.11 и наличие скриптов для preprocessing, training evaluator, knowledge preparation, CRAG inference, Self-CRAG preparation и evaluation. Практический вывод отсюда простой: CRAG — не одна «магическая настройка», а многошаговый конвейер с внешними зависимостями.
Чем отличается от…
Ниже — короткое сравнение только в пределах того, что подтверждается проверенными источниками по CRAG.
| Подход | Что делает | Чем отличается CRAG |
|---|---|---|
| Обычный RAG | Ищет документы и передаёт их в генерацию | CRAG добавляет оценку найденных документов, может запускать corrective retrieval и использует decompose-then-recompose для очистки контекста |
| Простой fallback на веб-поиск | При проблеме с корпусом делает внешний поиск | В CRAG веб-поиск — только один из корректирующих шагов; метод шире, потому что включает отдельную оценку retrieved-документов и пересборку контекста |
| Self-RAG | Соседний подход, который в этой статье не разбирается подробно | По официальному репозиторию CRAG авторы выделяют отдельный этап Self-CRAG preparation, то есть не считают CRAG и Self-RAG тождественными. Точную архитектурную разницу лучше смотреть отдельно |
Если вам нужен базовый контекст, сначала полезно освежить, что такое RAG (Retrieval-Augmented Generation), а затем посмотреть соседний термин Self-RAG.
Ограничения и заблуждения
- Заблуждение: CRAG гарантирует правильный ответ. Проверенные источники говорят об улучшении устойчивости RAG, а не о гарантии истинности каждого ответа.
- Заблуждение: CRAG — это просто веб-поиск. Нет. Веб-поиск — только один из corrective retrieval actions. Основа метода — ещё и оценка retrieved-документов плюс шаг decompose-then-recompose.
- Ограничение воспроизводимости. В официальном репозитории для Bio evaluation указан FActScore, а также есть примечание, что ранее заявленные результаты CRAG/Self-CRAG использовали
text-davinci-003, который OpenAI сняла с поддержки 2024-01-04. Это значит, что точное повторение старых результатов на текущих моделях может отличаться. - Ограничение инфраструктуры. Путь с внешними знаниями зависит от API-ключей и сторонних сервисов. Условия доступа, квоты и стоимость таких сервисов меняются, поэтому перед воспроизведением их нужно проверять на официальных страницах.
- Ограничение стабильности реализации. По проверенному состоянию источников на 2026-08-16 у официального репозитория нет опубликованных releases. В README есть журнал обновлений, где последняя документированная запись — 2024-10-08, но стабильной версии для цитирования страница не даёт.
- Редакционное ограничение этого обзора. Здесь проверены arXiv-препринт и официальный репозиторий. Финальная журнальная или конференционная публикация по этим источникам не подтверждена.
Практический вердикт
Если ваша главная проблема в RAG — слабый или шумный retrieval, CRAG интересен тем, что добавляет явную проверку качества поиска и механизм коррекции до генерации ответа. Но если вам нужна простая и легко воспроизводимая схема «из коробки», у метода есть практическая цена: многошаговый пайплайн, внешние ключи, отсутствие опубликованных releases и зависимость части исторических результатов от устаревшей модели.
Связанные термины и инструменты
Чтобы правильно встроить CRAG в общую картину, полезно сравнить его с базовым RAG и соседним подходом Self-RAG. Для архитектурных решений вокруг retrieval стоит посмотреть разбор GraphRAG vs обычный RAG, а для no-code сценариев с агентами и RAG — карточки Dust.tt и Voiceflow.
Источники
- Corrective Retrieval Augmented Generation — исходная статья о CRAG.
- GitHub – HuskyInSalt/CRAG: Corrective Retrieval Augmented Generation — официальный код, требования, этапы пайплайна и примечания по воспроизводимости.
- GitHub – shmsw25/FActScore — репозиторий, на который ссылается CRAG для Bio evaluation.
- Serper — сервис поиска, упомянутый в CRAG-репозитории для external-knowledge preparation.
- Developer quickstart – OpenAI API — официальный справочник по API-ключу, который нужен для внешнего knowledge path в CRAG.
- Data controls in the OpenAI platform – OpenAI API — официальный документ OpenAI для проверки актуальных условий использования и ограничений по endpoint.
Вопросы и ответы
CRAG — это отдельная модель?
По проверенным источникам CRAG описан как метод и исследовательский пайплайн для RAG, а не как отдельная фундаментальная модель.
Когда CRAG полезнее обычного RAG?
Когда проблема не в самой генерации, а в слабом retrieval: CRAG сначала оценивает найденные документы и может запустить corrective retrieval, если исходный поиск оказался плохим.
CRAG всегда использует веб-поиск?
Нет. Веб-поиск в статье упоминается как возможное корректирующее действие, когда поиск по корпусу слабый. Это часть метода, а не его единственное содержание.
Можно ли сегодня точно повторить результаты статьи?
Не всегда. Официальный репозиторий предупреждает, что часть ранее reported results использовала text-davinci-003, а эта модель была снята с поддержки 2024-01-04.
Что нужно для запуска официальной реализации?
По репозиторию — Python 3.11, подготовка данных и знаний, а для внешнего knowledge path ещё OpenAI API key и search key. Также важно учитывать, что у репозитория нет опубликованных releases.