Галлюцинации нейросети: почему выдумывает и что делать

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

Откуда это берётся

Механизм объясняет всё дальнейшее, поэтому начнём с него.

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

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

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

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

Выдумка неотличима по стилю. Все привычные человеческие признаки вранья — неуверенность, оговорки, уход от темы — здесь не работают. Скорее наоборот: чем меньше модель знает, тем ровнее звучит ответ.

Пять типов выдумок

Полезно различать, потому что лечатся они по-разному.

Несуществующие сущности. Функция библиотеки, которой нет; статья, которая не выходила; статья закона с придуманным номером. Самый частый и самый заметный тип.

Перепутанные детали при верной сути. Событие было, но не в том году; цитата настоящая, но не того автора; цифра из соседней строки таблицы. Опаснее первого типа, потому что проверка «в целом похоже на правду» его пропускает.

Достроенное по шаблону. В документе указаны четыре поля из пяти, а модель заполняет пятое тем, что обычно там бывает. Особенно часто срабатывает при строгой схеме, где поле объявлено обязательным.

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

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

Что действительно снижает долю

Приёмы по убыванию эффекта. Первые два дают почти весь результат.

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

Требуйте ссылку на источник. Не просто ответ, а ответ с указанием фрагмента, из которого он взят. Дальше ваш код проверяет, что фрагмент существует и содержит утверждение. Ответ без подтверждённой ссылки считается неполученным — как получить структуру, пригодную для проверки.

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

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

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

Дробите задачу. «Найди в договоре пункт про сроки» и «оцени, нарушен ли он» — два запроса, а не один. В слитном виде ошибка на первом шаге незаметно уезжает во второй.

Что помогает слабо

Список, на который тратят время напрасно.

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

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

Более дорогая модель. Сильные модели ошибаются реже, но не перестают. Переход с дешёвой на дорогую снижает долю, а не обнуляет её, и стоит денег — как сравнивать по делу.

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

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

Как встроить проверку

Порядок для тех, кто делает не демонстрацию, а сервис.

1. Определите, что в ответе критично. Обычно это несколько полей: суммы, даты, идентификаторы, имена. Остальное можно не проверять.
2. Требуйте эти поля в структуре, а не в тексте. Проверять поле проще, чем предложение.
3. Проверяйте существование программно. Есть ли такой заказ, такая статья, такая функция в вашей версии библиотеки.
4. Возвращайте ошибку, а не худший ответ. Не прошло проверку — это отказ, а не повод показать пользователю что-нибудь.
5. Логируйте расхождения. Через неделю такой лог покажет, на каких запросах модель уплывает, — что писать в логи.

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

Где выдумка стоит дороже всего

Три места, где последствия несоразмерны.

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

Действия, а не тексты. Если модель не просто отвечает, а вызывает функции, выдумка превращается в выполненное действие — почему решает ваш код, а не модель.

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

Как объяснить это заказчику

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

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

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

Три вопроса, которые стоит задать до начала работы:

Что показываем, когда ответа нет? Отказ, форму для человека, телефон поддержки. Ответ «такого не будет» — неправильный.

Кто отвечает за неверный ответ? Если система выдаёт информацию от имени компании, это обязательство компании перед клиентом, независимо от того, что его сформулировала модель.

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

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

Чего мы не утверждаем

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

Не обещаем, что перечисленное убирает явление. Оно снижает долю. Полностью не убирает ни один известный приём.

Не даём готовых промптов. Формулировки пишутся под предметную область.

Что держать в голове

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

Работают ровно две вещи: подать данные вместо того, чтобы полагаться на память модели, и проверить критичные поля своим кодом. Всё остальное — либо косметика, либо самоуспокоение.

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Прогнать свои проверки на нескольких моделях по одному ключу: keydealer.ru/login.