Галлюцинации ИИ-агентов: причины и решения

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

Важно отличать галлюцинацию от обычной ошибки. Ошибка — это неправильный, но осмысленный ответ: модель неверно сложила числа или перепутала порядок аргументов функции. Галлюцинация — это вымысел: несуществующий метод, несуществующая статья, несуществующая строка в файле. Ошибку видно при внимательном чтении, галлюцинацию — только при сверке с источником.

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

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

1. Модель предсказывает токены, а не ищет факты. LLM не имеет доступа к базе данных или интернету во время генерации. Она лишь вычисляет, какой токен с наибольшей вероятностью продолжит текст. Если правдоподобное продолжение — вымысел, модель выдаст вымысел.
2. Знания сжаты в веса. Всё, что модель «знает», хранится в миллиардах чисел — весах. Это сжатая, а не точная копия данных обучения. При извлечении знания неизбежны искажения и смешения похожих фрагментов.
3. Пробелы заполняются правдоподобием. Когда модель не «знает» ответа, она не может честно сказать «не знаю» — у неё нет такого механизма. Вместо этого она генерирует наиболее вероятный по форме вариант, который часто оказывается вымыслом.
4. Форма важнее содержания. Модель отлично имитирует структуру правильного ответа — перечисление, аргументацию, ссылки, — и внутри этой красивой формы может оказаться пустота.

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

Галлюцинации удобно классифицировать по тому, что именно модель выдумала. Это помогает быстрее находить их при проверке.

Отдельно стоит упомянуть галлюцинации «с опорой на контекст»: модель выдумывает детали на основе того, что ей дали в контексте. Ей показали два файла, и она «соединила» их, приписав функции из одного файла другому. Это самый коварный вид для работы с агентом, потому что выглядит как внимательная работа с вашим кодом.

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

1. Выдуманные пути и файлы. Агент предлагает отредактировать src/utils/helpers.ts, хотя такого файла нет, — и ждёт, что вы подтвердите действие.
2. Выдуманные команды и флаги. Агент запускает команду с параметром, которого не существует в установленной версии утилиты, и получает ошибку, которую потом «объясняет» очередной галлюцинацией.
3. Выдуманные результаты. Агент сообщает «тесты прошли» или «миграция применена», не выполнив проверку, — классический сценарий, когда отчёт красивее реальности.
4. Выдуманные API. При работе с библиотекой агент обращается к методам, которых в ней нет, полагаясь на «знание» из обучения, а не на документацию версии, установленной в проекте.

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

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

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

Отсюда два практических следствия, которые проходят красной нитью через весь курс.

1. Просите указать источник. Требуйте от агента ссылок на конкретные файлы и строки: «покажи, где в коде это определено». Ответ с реальными координатами проверить легко, а выдумать точные координаты модели сложнее.
2. Сверяйте с выводом команд. Факты должны приходить из реального вывода: ls, git diff, запуск тестов. Договоритесь, что отчёт о состоянии проекта строится только на таких выводах.
3. Используйте тесты как арбитра. Вместо вопроса «это работает?» просите агента показать результат прогона тестов. Тест — объективный судья, которому не свойственны галлюцинации.
4. Проверяйте критические утверждения вручную. Для важных решений — миграции, удаления, изменения прав — не полагайтесь на слова агента. Быстрый самостоятельный взгляд на diff занимает секунды, а предотвращает дорогие последствия.
5. Переспрашивайте при сомнении. Если ответ выглядит слишком гладким или подозрительно конкретным без опоры на контекст — попросите агента перепроверить. Повторный запрос часто вскрывает вымысел.

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

1. Считать, что галлюцинации — признак «плохой модели», и менять модель вместо того, чтобы наладить контекст и проверку — галлюцинируют все модели, разница лишь в частоте.
2. Доверять отчётам агента о выполненных действиях без сверки с реальным состоянием — «тесты прошли» без вывода тестов не считается.
3. Загружать в контекст всё подряд «для полноты» — переполненный контекст уводит агента в dumb zone и увеличивает число галлюцинаций.
4. Полагаться на «знания» агента о библиотеке вместо документации установленной версии — API меняются, и память модели устаревает.
5. Не выстраивать обратные связи: без тестов, линтера и typechecker галлюцинированный код обнаруживается в лучшем случае на ревью, а в худшем — в проде.
6. Путать обычную ошибку с галлюцинацией и «лечить» её повторным запросом — ошибку повторный запрос исправит, а вымысел без опоры на факты скорее всего повторится в новой форме.

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

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

1. Галлюцинация — уверенный ответ модели, не соответствующий реальности: факту, коду или данным.
2. Ошибка — неправильный, но осмысленный ответ модели, в отличие от вымысла.
3. Веса модели — числовые параметры LLM, в которых сжаты знания из обучающих данных.
4. Правдоподобие — механизм, которым модель заполняет пробелы знаний: наиболее вероятный по форме вариант.
5. Призрачный файл — файл или путь, который модель упоминает, но которого не существует в проекте.
6. Smart Zone — состояние, в котором контекст заполнен умеренно и способность модели к рассуждению не деградирует.
7. Dumb Zone — состояние переполненного контекста, в котором модель хуже рассуждает и чаще галлюцинирует.
8. Контекст — весь текст, передаваемый модели в запросе: системный промпт, история, файлы, выводы команд.
9. Ground truth — фактические данные из реальной системы (файлы, выводы команд), на которые агент должен опираться.
10. Обратная связь — автоматическая проверка результатов (тесты, линтер, typechecker), ловящая ошибки агента.
11. Typechecker — инструмент статической проверки типов, отлавливающий вызовы несуществующих методов.