Учимся отличать галлюцинации от плохого контекста

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

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

Модель, к примеру, могла проигнорировать релевантный контекст или не получить его вовсе. А могла сгенерировать ответ из параметрической памяти и задним числом подобрать «подходящую» цитату.

В этой статье мы разберём, как диагностировать каждый случай, с соответствующими примерами и методикой, которую можно применить к своему пайплайну.

Одинаковые сценарии

Представьте, что во внутренней сети вашей организации используется корпоративный ассистент по документации. Сотрудник спрашивает: «Каков максимальный размер сообщения в Apache Kafka?» Эталонный ответ — 1 МБ, и он есть в документации, которую система должна была найти.

Теперь рассмотрим другой вариант, когда контекст был, но модель его проигнорировала. В таком случае наш Retriever нашёл нужный чанк, он попал в промпт, но модель выдала «10 МБ» — число, которое выглядит правдоподобно для очереди сообщений, но противоречит документу.

Это классическая контекстуальная галлюцинация, когда контекст точно присутствовал, но не повлиял на генерацию ответа.

А ещё контекст может полностью отсутствовать, но модель его додумывает. Здесь Retriever по какой-то причине не вернул нужный чанк, например, из-за плохого эмбеддинга, чанкинг разорвал предложение, а фильтр по метаданным отсёк документ.

Модель, не имея опоры, сгенерировала ответ (возможно, даже правильный!) из общих знаний о Kafka-совместимых очередях. Формально это тоже галлюцинация, но корень проблемы здесь кроется в retrieval, а не в генераторе.

Модель может не просто что-то додумывать, но и откровенно жульничать, подбирая нужный ответ.

Давайте рассмотрим самый коварный случай. Модель из параметрической памяти знает, что такое Apache Kafka, генерирует ответ, а затем «сканирует» контекст на предмет совпадения токенов и прикрепляет ссылку на документ, который лишь поверхностно совпадает по теме.

Ответ тоже может быть даже правильным, но цитата неточная, потому что документ не был причиной генерации. Кстати, такой болезнью часто страдают поисковики, выдавая в результатах страницы, совершенно не относящиеся к теме запроса.

Как видно, у моделей возможны различные случаи некорректной работы, которые могут привести к выдаче неверного результата. Далее давайте посмотрим, как можно отличить один случай от другого.

Почему нельзя «просто проверить, есть ли факт в контексте»

Кажется, что самое простое решение — это взять NLI-модель и с её помощью проверить, поддерживает ли контекст утверждение. Но в таком случае мы сможем решить только часть проблемы.

Исследователи из Vectara, авторы бенчмарка FaithBench, показали, что даже продвинутые детекторы галлюцинаций на сложных примерах работают немногим лучше случайного угадывания.

Так, большинство state-of-the-art-моделей детекции имеют точность около 50% на специально собранном наборе «трудных» галлюцинаций от десяти современных LLM.

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

Пример из той же работы наглядно иллюстрирует эту ловушку.

Например, на вопрос «Какой город является столицей Германии?» ответ в документе 1: «Столица Германии — Берлин». А вот в документе 2 написано: «В Берлине лучшие ночные клубы».

Возможны три ситуации:

• Если модель использовала документ 1, то цитата полностью верная.

• Если модель знала ответ из памяти и прикрепила документ 1, потому что он совпал токенами, то, хоть цитата и правильная, это угадывание.

• А если модель прикрепила документ 2, потому что там встретилось слово «Берлин», то это и вовсе абсурд, который, однако, может пройти поверхностную проверку на «упоминание сущности». 

Разбираем сбой на практике

Чтобы методика не осталась абстрактной, пройдём весь путь на примере конкретного сбоя.

Допустим, у нас снова есть облачный сервис Kafka. Возьмём вопрос из поддержки:

Можно ли восстановить удалённый топик в Apache Kafka и сколько это стоит?

Система ответила:

Да, удалённый топик можно восстановить в течение 7 дней через консоль управления. Восстановление бесплатно.

В документации написано иначе: удаление необратимо, восстановления нет; есть только 7-дневное хранение данных перед физическим удалением, и оно не позволяет «вернуть» топик.

Как видно, некорректный ответ налицо. Давайте посмотрим, каким должен быть алгоритм наших действий в данном случае.

Шаг 1. Проверяем результаты Retriever.

Для начала смотрим, что вернул ретривер на top-5. Например, в выдаче:

• чанк про «7 дней хранения данных»;

• чанк про «удаление топика необратимо»;

• три нерелевантных фрагмента про лимиты и квоты.

Ключевой факт «восстановления нет» присутствует, но разнесён по двум чанкам, и ни один не содержит слово «восстановить».

Метрика Recall@5 (какая доля всех релевантных объектов найдена в топ-5 результатов ранжирования) по эталонному факту формально есть, но семантически факт разорван.

В итоге мы можем сделать вывод, что retrieval частично виноват, так как чанкинг разбил утверждение, а реранкер поднял наверх фрагмент про 7 дней, который модель и ухватила.

Шаг 2. Проводим абляцию.

Далее мы проводим абляцию, то есть убираем чанк про 7 дней из промпта и повторяем запрос.

Ответ меняется:

В документации не указано, что удалённый топик можно восстановить.

Значит, контекст влиял, но модель слепила из «7 дней хранения» ложное утверждение о «7 днях на восстановление».

Здесь контекст был, но модель его переработала неверно, достроив причинно-следственную связь, которой в документе нет.

Шаг 3. Проводим атрибуцию утверждений.

Теперь разбиваем ответ на претензии (claims):

• «Восстановить можно в течение 7 дней» — в контексте нет поддерживающего фрагмента (есть только про хранение).

• «Через консоль управления» — не поддерживается вовсе, чистая параметрическая генерация.

• «Бесплатно» — тоже ниоткуда.

В итоге из трёх утверждений ноль обоснованы, хотя рядом лежал чанк, опровергающий первое.

Шаг 4. Проверяем зависимость ответа от контекста.

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

Если ответ не меняется и модель выдаёт всё ту же фразу про 7 дней и бесплатность, то это означает, что часть ответа сгенерирована из памяти, а документ про хранение был использован как «декоративная» опора.

Таким образом, мы видим, что здесь у нас совмещение двух проблем из первого и третьего сценариев.

В итоге мы починили сразу несколько элементов нашей модели.

• Во-первых, чанкинг по смысловым блокам вместо фиксированного окна: утверждение про необратимость удаления теперь лежит в одном чанке с заголовком раздела.

• Во-вторых, добавили в промпт явное требование о том, что, если в контексте нет прямого утверждения, нужно отвечать «в документации не указано», а не достраивать.

• В-третьих, завели проверку атрибуции на критичных вопросах: каждое число и срок должны иметь поддерживающий фрагмент (supporting span), иначе ответ уходит на ручную проверку.

После правок на том же наборе вопросов доля необоснованных утверждений упала с 34% до 9%, при этом доля ответов «не указано» выросла, что для поддержки честнее, чем уверенная выдумка.

Что делать с каждым классом ошибок

Если при сбоях доминирует плохой retrieval, то вам необходимо инвестировать в гибридный поиск, реранкинг и более аккуратный чанкинг.

Промпт-инжиниринг здесь бесполезен, так как модель не может использовать то, чего нет.

Практическим минимумом здесь будет логирование для каждого ответа top-k чанков и эталонного чанка, если он известен, чтобы считать Recall@k на реальном трафике, а не на синтетике.

А если доминирует игнорирование или неверная переработка контекста, то проверьте, не конфликтует ли контекст с параметрической памятью модели.

Модели склонны доверять своим «знаниям» больше, чем документу, особенно если документ выглядит неполным.

Помогают:

• явные инструкции приоритета контекста;

• примеры с обязательной опорой на фрагмент;

• требование отвечать «не указано» при отсутствии прямого утверждения.

В случае, если модель часто жульничает, угадывая ответ, нужна причинная проверка, а не только проверка на поддержку.

На практике для критичных ответов логируйте, какие чанки были в промпте, и проводите выборочную абляцию, скажем, на 5% трафика или на всех ответах, где модель сослалась на источник.

Это дорого, но дешевле, чем доверие к некорректным цитатам, которые «выглядят правильно».

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

Главный вывод

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

Система, которая просто помечает ответ как «hallucinated», не даёт этой информации. А вот система, которая для каждого сбоя отвечает на вопрос «был ли контекст и использовался ли он», превращает диагностику из гадания в инженерию.

Самый дешёвый первый шаг доступен почти всем. Необходимо начать логировать, какие чанки попали в промпт, и хотя бы выборочно проверять ответы абляцией. В таком случае вы сможете быстрее и эффективнее решать проблемы с некорректной работой ваших моделей.

Хотите научиться находить причины ошибок в RAG-системах, а не просто исправлять некорректные ответы? Разберитесь, как устроен поиск по документам, как формируется контекст и что влияет на качество генерации. Это поможет проектировать более надёжные LLM-системы и понимать, на каком этапе возникает сбой.

Приглашаем на бесплатные открытые уроки:

• 19 ноября, 18:00. «Qdrant: поиск по документам с фильтрацией по метаданным». Записаться

• 17 декабря, 20:00. «Проектирование RAG-систем: от базового пайплайна до продвинутых решений». Записаться

А если хотите изучить и другие направления ИТ, загляните в дайджест бесплатных открытых уроков ноября.