Тестирование галлюцинаций

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

В этой статье рассматриваются:

  1. Что такое галлюцинация
  2. Почему возникают галлюцинации
  3. Основные типы галлюцинаций
  4. Как проектировать тест-кейсы на галлюцинации
  5. Как измерять и фиксировать частоту галлюцинаций

Что такое галлюцинация

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

Почему возникают галлюцинации

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

  • Вопрос касается темы, выходящей за пределы или на границе того, на чём обучалась модель.
  • Запрос сформулирован неоднозначно, и модель заполняет пробелы правдоподобным на вид предположением.
  • От системы требуют очень конкретный факт (дату, статистику, цитату), где бегло, но неверно сформулированный ответ модели произвести легко, а пользователю — трудно заметить.
  • Систему вынуждают всегда давать ответ, вместо того чтобы позволить ей честно признать незнание.

Основные типы галлюцинаций

Галлюцинации — не единый паттерн сбоя, и полезная тест-стратегия обычно различает несколько типов:

  • Фактические галлюцинации — прямое ложное утверждение: неверная дата, имя или число.
  • Контекстные галлюцинации — ответ противоречит информации, напрямую данной в запросе или исходном документе.
  • Выдуманные источники — придуманные ссылки, цитаты или источники, которые звучат правдоподобно, но не существуют.
  • Логические галлюцинации — отдельные факты в ответе могут быть верны, но связывающая их логика на самом деле не работает.

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

Как проектировать тест-кейсы на галлюцинации

Эффективное тестирование галлюцинаций обычно сочетает несколько техник:

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

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

Измерение и фиксация частоты галлюцинаций

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

Дополнительные материалы

Тестирование галлюцинаций в чат-ботах
Retrieval-Augmented Factuality
Решение проблемы нестабильности LLM на маркетплейс-платформах

Содержание