Миф: RAG избавляет модель от галлюцинаций

MAATRIX

«Подключите RAG — и модель перестанет выдумывать факты» — эту фразу слышит почти каждый, кто впервые собирает ассистента по своим документам. Звучит логично: раз модель галлюцинирует из-за нехватки знаний, подсуньте ей знания прямо в промпт — и проблема решена. На практике RAG действительно заметно снижает частоту галлюцинаций, но не убирает их как класс, и если строить критичный продукт в расчёте на «RAG = ноль ошибок», рано или поздно система выдаст уверенный, хорошо оформленный, но неверный ответ — причём именно тогда, когда цена ошибки высока.

Откуда взялся миф про RAG как лекарство от галлюцинаций

Миф не случаен — у него есть реальное основание. Классическая причина галлюцинаций разобрана в статье про механику галлюцинаций LLM: модель не хранит факты в базе, а предсказывает правдоподобный следующий токен по статистике обучающих данных. Если факт редкий или отсутствовал в датасете, распределение вероятностей размывается, и модель «додумывает» правдоподобное продолжение. RAG на первый взгляд бьёт точно в эту причину: вместо того чтобы модель вспоминала факт из размазанных по весам паттернов, ей подают нужный текст прямо в контекст запроса — остаётся не вспомнить, а пересказать.

И для типовых кейсов — короткий, однозначный вопрос, один релевантный документ, чёткий ответ прямо в тексте — это действительно работает почти как обещано: доля явных выдумок падает в разы по сравнению с «голой» моделью без контекста. Именно этот ранний положительный опыт и рождает миф: если на десятках тестовых вопросов RAG ни разу не соврал, легко сделать вывод, что проблема закрыта архитектурно, а не просто снижена по вероятности. Дальше происходит типичная ошибка обобщения: «в моих тестах не было ошибок» превращается в «система не может ошибаться», хотя тестовая выборка почти никогда не покрывает все реальные сценарии продакшена — двусмысленные вопросы, противоречивые документы, устаревшие версии текста, неполные фрагменты после чанкинга.

Маркетинг вокруг RAG-продуктов эту иллюзию только усиливает: словосочетание «grounded generation» (генерация, «заземлённая» в источниках) звучит как гарантия, хотя технически означает лишь то, что модели *подали* релевантный текст — а не то, что она *обязательно и точно* его использует. Между «источник был в контексте» и «ответ полностью соответствует источнику» лежит целый пласт возможных ошибок, которые разберём дальше.

Почему модель может ошибиться даже с правильным контекстом

Ключевое заблуждение — считать, что если retrieval нашёл верный документ, дальше модель просто «читает и копирует». На самом деле генерация ответа поверх найденного контекста — это та же самая механика предсказания токенов, что и без RAG, просто с дополнительным текстом во входной последовательности. У модели по-прежнему нет отдельного режима «точное цитирование» с формальной проверкой соответствия — есть один процесс: предсказать правдоподобное продолжение с учётом всего, что сейчас во входе, включая найденные фрагменты.

Отсюда несколько типичных сбоев, которые случаются даже при идеальном retrieval:

• Смешение похожих сущностей. Если в контекст попали два документа про близкие, но разные объекты (два тарифных плана, две версии API, два похожих продукта), модель может приписать характеристику одного другому — не потому что «не увидела» текст, а потому что при генерации отдельного токена локально более вероятным оказался паттерн из соседнего фрагмента.
• Инверсия отрицания и условий. Модель может упустить «не» или условие «только если», особенно если оно расположено на границе смыслового блока, а сам фрагмент длинный. Итоговый ответ грамматически правильный, стилистически уверенный — и содержательно перевёрнутый.
• Конфликт версий документа. Если retrieval вернул старую и новую редакцию одного документа (частая ситуация, если база знаний не чистится от устаревших файлов), модель не обязана «понимать», какая версия актуальна — она может смешать цифры из обеих или взять устаревшую, если она статистически более «типична» по формулировке.
• Игнорирование части контекста при длинном промпте. Чем больше найденных фрагментов подано в контекст, тем выше риск, что модель уделит им неравное внимание — это известная проблема деградации качества использования информации в середине длинного контекста, знакомая по работе с большими окнами вообще, а не только в RAG.

Ни один из этих сценариев не является «отказом системы» в привычном смысле — с точки зрения логов всё выглядит штатно: retrieval сработал, документ найден, модель дала связный ответ. Именно поэтому такие ошибки особенно опасны — их не видно без отдельной проверки содержания, а не факта наличия источника.

Смешение найденного контекста с параметрической памятью

Отдельная и менее очевидная причина — у модели одновременно есть два источника «знаний»: то, что подано в контексте (retrieval), и то, что зашито в весах после обучения (параметрическая память). Модель не помечает для себя, откуда взялся конкретный факт в ответе, и не обязана явно разделять эти источники при генерации — оба участвуют в едином процессе предсказания следующего токена.

Проблема проявляется там, где найденный документ покрывает вопрос частично. Например, документация описывает основной параметр API, но не упоминает граничное значение или конкретное числовое ограничение, о котором спрашивает пользователь. Модель с высокой вероятностью не скажет «в документе этого нет» — она достроит ответ из общих статистических паттернов о том, как обычно выглядят подобные ограничения в похожих API, и подаст это тем же уверенным тоном, что и информацию, реально взятую из контекста. Внешне оба куска ответа неотличимы: ни форматирование, ни стиль изложения не выдают, что часть фразы — пересказ документа, а часть — генерация «по аналогии».

Это отличается от классической галлюцинации без RAG тем, что здесь ошибка *локальна*: 80% ответа может быть точным пересказом источника, а 20% — незаметно вплетённой выдумкой ровно там, где документ не дал прямого ответа. Такой гибридный ответ статистически более убедителен и более опасен, чем полностью выдуманный текст: полную выдумку опытный пользователь ещё может заподозрить по общей неуверенности темы, а частично верный ответ с одной подмешанной деталью выглядит полностью надёжным.

«Додумывание» при неполном или обрезанном контексте

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

Результат предсказуем: там, где человек, увидев обрезанный список, сказал бы «здесь явно есть продолжение, не видно», модель чаще всего достраивает недостающие пункты по наиболее вероятному по смыслу шаблону — грамматически безупречно, содержательно ошибочно. Разбор именно такого случая, когда неверный чанкинг привёл к практически бессмысленным ответам при формально работающем pipeline, — в статье RAG выдавал чушь: проблема была в чанкинге. Смягчить проблему помогает перекрытие чанков (overlap), сохранение структурных границ (не резать таблицы и списки по живому) и добавление метаданных о происхождении фрагмента, но полностью исключить обрыв смысла на границе чанка без ручной проверки невозможно — это структурное ограничение самого подхода «резать документ на куски», а не баг конкретной реализации.

Качество retrieval — фундамент, без которого генерация бессильна

Отдельно стоит подчеркнуть то, что часто недооценивают: RAG — это конвейер из двух принципиально разных этапов, и второй (генерация ответа) физически не может исправить ошибку первого (поиск релевантных фрагментов). Если retrieval вернул нерелевантные или частично релевантные документы, у модели просто нет доступа к правильной информации — и она либо честно скажет «в контексте нет ответа» (если явно проинструктирована так делать), либо, что случается чаще без жёсткой инструкции, добросовестно перескажет то, что нашла, — правдоподобно и не по теме вопроса.

Типичные причины слабого retrieval, встречающиеся на практике:

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

Verification-слой: не доверяйте RAG вслепую в критичных сценариях

Если снизить риск галлюцинаций полностью нельзя ни улучшением retrieval, ни промптом, для критичных применений (юридические заключения, медицинские консультации, финансовые отчёты, всё, что подписывается или на основании чего принимается решение) разумная архитектура включает отдельный слой проверки поверх сгенерированного ответа, а не только сам RAG-пайплайн.

Несколько практических механизмов, которые реально применяются, а не только звучат в теории:

Groundedness-проверка вторым проходом. После генерации ответа отдельным запросом (часто к той же модели или к более простой/дешёвой) просят проверить: каждое утверждение в ответе явно подтверждается текстом из найденного контекста, или нет. Схема запроса:

Дан контекст (набор фрагментов документов) и ответ модели на его основе.
Для каждого утверждения в ответе укажи: подтверждено ли оно
дословно или по смыслу текстом контекста (да/нет/частично).
Если хотя бы одно утверждение не подтверждено — пометь весь
ответ как требующий проверки человеком.

Контекст: {найденные фрагменты}
Ответ: {сгенерированный ответ}

Это не даёт стопроцентной гарантии (сама проверка тоже выполняется LLM и подвержена похожим ошибкам), но ловит заметную долю случаев, где модель подмешала параметрическую память в пересказ источника.

Обязательное цитирование с привязкой к источнику. Промпт требует не просто ответить, а сопроводить каждый факт ссылкой на конкретный фрагмент документа (номер чанка, страница, раздел). Это не устраняет ошибку саму по себе, но делает её проверяемой за секунды: если утверждение не сопровождается ссылкой или ссылка указывает не туда, это явный сигнал не доверять фрагменту без ручной проверки.

Оценка уверенности retrieval как триггер маршрутизации. Если оценка релевантности найденных документов ниже порога (или лучший найденный фрагмент вообще слабо соответствует запросу), система должна не подавать это в генерацию как есть, а либо честно сообщить «недостаточно данных», либо переадресовать запрос человеку — вместо того чтобы полагаться на то, что модель сама «поймёт» недостаточность контекста.

Регулярная выборочная оценка качества ответов. Автоматических проверок недостаточно без периодического контроля метрик на репрезентативной выборке реальных вопросов — как именно это делать и какие метрики использовать (точность цитирования, полнота, релевантность), разобрано в статье как оценить качество RAG-ответов.

Ни один из этих механизмов не превращает RAG в систему с нулевой погрешностью — но переводит галлюцинации из категории «невидимая случайность» в категорию «измеримый и управляемый риск», что для критичных применений принципиально важнее абстрактного «мы же используем RAG, значит всё под контролем».

Частые вопросы