Галлюцинация ≠ ошибка?

Представьте ситуацию, что корпоративный бот сообщает пользователю: "Активированную подписку можно вернуть в течение 60 дней.". А в актуальной политике продукта указано обратное, что после активации возврат невозможен.

Почему так может быть? Модель галлюцинирует? Возможно. Однако система могла найти устаревший документ, применить правило другого региона или неверно обработать результат внешнего инструмента.

Галлюцинация — это особенность LLM, которую легко можно принять за ошибку. Но не каждый неправильный ответ AI-системы возникает из-за галлюцинации LLM.

Поэтому задача QA не просто обнаружить “странный” ответ, а доказать, что именно произошло и на каком этапе.

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

Такой механизм создает правдоподобное продолжение, но не гарантирует его истинность. Обучение дает модели множество закономерностей и фактов, но не полную и актуальную базу знаний со встроенным фактчекером. Модель будет продолжать работать, даже если сама постановка вопроса содержит невозможное условие. Если информации недостаточно, LLM может заполнить пробел убедительной деталью.

Риск галлюцинации повышается, когда:

Даже длинное контекстное окно не решает проблему автоматически. Исследование Lost in the Middle показало, что качество ответа может зависеть от положения важного факта внутри контекста.
Галлюцинация является ожидаемым риском генеративной модели. Но странный ответ ещё ничего не доказывает. Маловероятный факт может оказаться правдой, а отсутствие подтверждения не всегда означает ложь.

Еще больше материала про AI QA и тестирование AI-приложений в Telegram-канале ModernQA

Сначала QA должен установить, что конкретное утверждение неверно или не основано на разрешенном контексте. Затем определить источник ошибки.

Противоречие надежному источнику доказывает неправильность ответа, но ещё не доказывает галлюцинацию LLM. Причиной могли стать ошибочный поиск, устаревшие данные, сбой API или дефект бизнес-логики вокруг модели.

Также важно заранее определить критерий корректности. Если бот обязан отвечать только по внутренним документам, даже правдивый, но не подтвержденный ими факт нарушает groundedness (привязку ответа к разрешенному контексту).

Для поиска доказательств или опровержений галлюцинации можно придерживаться следующих действий:

Сохраните запрос, системные инструкции, историю диалога, контекст, результаты инструментов, модель, параметры генерации, дату и исходный ответ.

Например: при повторе система может найти другой документ, и без исходного контекста воспроизвести ошибку уже не получится.

Длинный ответ лучше воспринимать как набор атомарных фактов и проверять каждый отдельно. Такой принцип используется в FActScore.

Например: фраза бота содержит два утверждения о том, что активированную подписку можно вернуть, а срок возврата составляет 60 дней.

Источником истины может быть спецификация, регламент, запись в БД, ответ API, состояние системы, предметный эксперт или авторитетный внешний источник.

Например: правило нужно сверять с актуальной политикой продукта для нужного региона и типа подписки, а не с ее старой версией.

Утверждение может быть подтверждено, опровергнуто, не подтверждено разрешенным контекстом либо оставлено без оценки из-за недостатка данных.

Чтобы отнести дефект к генерации, по логам или трассировке нужно убедиться, что правильное правило действительно вошло в контекст, переданный LLM, результаты инструментов не были искажены, а постобработка не изменила ответ.

Например: если актуальное правило было передано модели без искажений, но в ответе появилось противоположное утверждение, дефект можно локализовать на этапе генерации или использования контекста.

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

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

Это сигналы для расследования, но не источники истины.

Исследование The Coin Flip Judge? показало, что при повторном сравнении одной и той же пары ответов вердикт LLM-судьи в среднем в 13,6% случаев отличался от наиболее частого решения. В исследовании проверили только две модели OpenAI, поэтому результат нельзя автоматически распространять на других LLM-судей. Но исследование хорошо показывает, почему единичную автоматическую оценку нельзя считать окончательным доказательством. В критичных сценариях нужны повторные оценки и агрегация результатов, но они не заменяют проверку по надежному источнику.

Для нашего примера итоговое описание может звучать так:

"Бот сообщает, что активированную подписку можно вернуть в течение 60 дней, хотя политика продукта версии 3.2 запрещает возврат после активации. По логам подтверждено, что актуальное правило присутствовало в контексте, фактически переданном модели, инструменты вернули корректные данные, а постобработка не изменила ответ. Следовательно, дефект возник на этапе генерации или использования контекста. Ошибка воспроизвелась в 4 из 10 запусков. Severity — High. Ответ влияет на финансовое решение пользователя."

В описании есть проверяемая последовательность:

утверждение → источник → противоречие → локализация → частота → риск

Доказанные случаи можно превращать в evals: сохранять запрос, контекст, источник истины и запрещенные утверждения, а после изменений в AI-системе запускать проверку повторно.

Сказать, что “модель врет”, недостаточно. Именно здесь проявляется сильная сторона QA-инженера — сомнение, превращенное в проверку, какое именно утверждение неверно, какой источник это доказывает и при каких условиях система выдала такой ответ.

Только после проверки всей цепочки можно утверждать, что перед нами галлюцинация LLM, а не ошибка другого компонента AI-системы.

#тестирование #qa #qaengineer #ai