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

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

Почему это происходит

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

Ключевая ловушка: уверенность тона не связана с правильностью. Модель одинаково уверенно звучит и когда воспроизводит реальный факт, и когда достраивает несуществующий. Тон — не сигнал истинности.

Где галлюцинации вероятнее всего

Риск не равномерный. Он резко растёт там, где данных было мало или их не могло быть:

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

Как снижать риск

Полностью убрать галлюцинации нельзя — можно резко снизить их вероятность и цену:

  • Заземляйте на данные. Не спрашивайте «из головы» — дайте нужный кусок документации, кода, фактов прямо в запрос. Тогда модель опирается на них, а не на вероятности. Это же делают внешние источники через вызов инструментов (поиск, доступ к базе).
  • Просите проверяемое. Требуйте ссылки на источник, конкретные места в коде, обоснование. Выдумку проще поймать, когда её можно сверить.
  • Проверяйте выход. Скомпилировать, запустить тесты, свериться с реальной документацией — проверка результата ИИ должна быть не опцией, а частью процесса. Особенно это касается ревью AI-кода.
  • Разрешайте «не знаю». Явно скажите модели, что лучше признать незнание, чем выдумать. Это снижает уверенные ошибки.
  • Не доверяйте фактам без проверки. Числа, ссылки, API-имена, цитаты — всегда сверяйте с первоисточником, даже если звучит убедительно.

Что это значит на практике

Галлюцинации — не повод отказаться от ИИ, а причина строить работу так, чтобы выдумка не доехала до продукта. Продукт-инженер относится к любому ответу модели как к черновику от очень начитанного, но иногда фантазирующего помощника: полезно, быстро, но проверяется прежде, чем идёт в дело. Чем выше цена ошибки (факты для пользователя, деньги, безопасность) — тем строже проверка.

Дальше

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