Галлюцинации LLM: 6 причин, почему модель выдумывает, и как это ловить
TL;DR. Галлюцинация LLM — это правдоподобное, но неверное утверждение, которое модель выдаёт уверенным тоном. Причина не в «злой воле» модели, а в самой механике: она предсказывает вероятное продолжение текста, а не сверяется с базой фактов. Полностью убрать галлюцинации нельзя, но можно резко снизить их частоту и, что важнее, цену ошибки: привязать ответ к документам, требовать цитаты, проверять критичные утверждения и ограничивать модель там, где она не знает ответа.
Разбор подготовлен AI Digest (ai-digest.ru) для команд, которые уже используют модели в работе и устали от фразы «нейросеть ошиблась». Если нужна база, начните с материала что такое LLM и как она работает: без понимания механики предсказания токенов борьба с галлюцинациями превращается в набор суеверий.
Что такое галлюцинация LLM и чем она не является
Галлюцинация — это сгенерированное утверждение, которое выглядит достоверно, но не соответствует действительности или не подтверждается доступными источниками. Типичный пример: аккуратно оформленная ссылка на статью, которой не существует, или уверенно названная дата релиза, которой не было.
Важно отделять галлюцинацию от смежных проблем. Ошибка в исходных данных — это не галлюцинация: модель добросовестно пересказала неверный документ. Устаревшее знание — тоже не галлюцинация, а ограничение даты обучения. А вот выдуманная деталь, которой не было ни в данных, ни в знаниях, — классическая галлюцинация.
Разделение нужно потому, что лечатся эти проблемы по-разному. Если виноват контекст, поможет чистка базы знаний. Если виновата модель, помогут другие методы: grounding, проверка, ограничения формата.
Почему модель выдумывает: шесть рабочих причин
Первая причина — вероятностная природа генерации. Модель выбирает следующий токен по распределению вероятностей. Когда знания нет, распределение всё равно существует: модель подставит что-то правдоподобное, потому что «правдоподобно» — это и есть критерий, на котором её обучали.
Вторая — пробелы в знаниях. Чем уже тема и чем свежее события, тем выше шанс, что в обучающих данных нужного факта просто не было. Модель не умеет честно сказать «не знаю», если её к этому отдельно не приучили и не разрешили.
Третья — конфликт контекста и инструкций. Если в документах противоречивые сведения, а в системной инструкции требование «отвечай кратко и уверенно», модель склеит компромиссный вариант. Он будет звучать гладко и при этом не соответствовать ни одному источнику.
Четвёртая — давление формата. Просьба «дай пять примеров» или «заполни все поля таблицы» заставляет модель заполнять пустоты. Там, где у неё нет данных, появляется вымысел, потому что пустая ячейка воспринимается как нарушение задачи.
Пятая — отсутствие проверки. Один проход генерации не содержит шага «а теперь сверься с источником». Если этот шаг не добавлен архитектурно, модель не проверяет себя сама.
Шестая — длинный контекст с шумом. Когда в промпт попадает много нерелевантных фрагментов, модель может «приклеить» деталь из постороннего документа. Это особенно частая проблема в системах поиска по внутренней базе.
Как отличить галлюцинацию от плохого ответа
Практический признак: галлюцинация всегда выглядит лучше, чем должна. В ней есть конкретика, которой нет в источниках: числа, имена, ссылки, даты. Плохой ответ обычно расплывчат и осторожен, галлюцинация — уверенна и детальна.
Поэтому проверка начинается не с текста, а с источника. Если утверждение нельзя проследить до конкретного документа, это гипотеза, а не факт, независимо от того, насколько убедительно она сформулирована.
| Тип проблемы | Как выглядит | Что помогает |
|---|---|---|
| Выдуманный факт | Дата, число или событие, которого не было | Grounding на документы, требование цитат |
| Фиктивная ссылка | Аккуратный URL, который не открывается | Запрет ссылок без проверки, ручная валидация |
| Смешение источников | Деталь из чужого документа в ответе | Сужение контекста, цитирование фрагментов |
| Устаревшее знание | Верный на момент обучения, но старый факт | Свежие данные в контексте, дата в ответе |
| Ложная уверенность | Категоричный тон при отсутствии данных | Разрешение «не знаю», калибровка формулировок |
Какие методы реально снижают число галлюцинаций
Самый надёжный метод — привязка к источникам. Модель получает не абстрактный вопрос, а конкретные фрагменты документов и инструкцию отвечать только по ним. Это не устраняет выдумки полностью, но переводит задачу из «вспомни» в «прочитай и перескажи», а пересказ проверять проще. Подробнее этот подход разобран в материале что такое RAG.
Второй метод — требование цитат. Если ответ должен содержать ссылку на фрагмент источника, у вымысла резко падает пространство для маневра: выдуманному утверждению некуда прикрепиться. Дополнительно это даёт проверяемость: человек видит, откуда взялась фраза.
Третий — явное разрешение не отвечать. Формулировка «если данных нет, скажи об этом и перечисли, чего не хватает» снижает долю выдумок сильнее, чем кажется. Модели мешает не злая воля, а установка «обязательно дай ответ».
Четвёртый — декомпозиция. Вместо одного запроса «сделай анализ рынка» — цепочка: выделить утверждения, проверить каждое, собрать итог. На каждом шаге проще заметить расхождение.
Пятый — регрессионные тесты. Набор из нескольких десятков вопросов с известными правильными ответами и «ловушками» (вопросы о несуществующих сущностях) позволяет увидеть, как изменение промпта или модели влияет на частоту выдумок. Без такого набора любая правка — стрельба вслепую.
Как выстроить проверку ответов в продакшене
Начните с классификации рисков. Разделите сценарии на те, где ошибка стоит денег или репутации (юридические формулировки, медицинские рекомендации, финансовые расчёты), и те, где достаточно пометки «сгенерировано ИИ». Уровень контроля должен зависеть от цены ошибки, а не от удобства команды.
Дальше добавьте обязательную проверку фактов в критичных сценариях. Это может быть сверка с базой, вызов внешнего инструмента или человек на финальном шаге. Ключевое правило: модель не должна быть единственным источником истины там, где ошибка недопустима.
Затем настройте логирование. Сохраняйте вопрос, контекст, ответ и пометку «подтверждено / опровергнуто». Через пару недель у вас будет собственный набор типовых ошибок — он ценнее любой общей статьи, включая эту.
И последнее: не обещайте пользователям безошибочности. Формулировка «мы проверяем ответы и показываем источники» честнее и полезнее, чем «наша нейросеть никогда не ошибается».
Частые вопросы
Можно ли полностью убрать галлюцинации?
Нет. Можно снизить их частоту и сделать ошибки заметными: привязать ответы к источникам, требовать цитаты, проверять критичные утверждения. Полная гарантия недостижима, потому что генерация вероятностна по своей природе.
Помогает ли более новая модель?
Часто да, но не как универсальное решение. Новые модели лучше калиброваны и реже выдумывают детали, однако на узких темах и свежих событиях проблема остаётся. Архитектура проверки важнее версии модели.
Почему модель уверенно называет несуществующие ссылки?
Потому что ссылка выглядит как типичный шаблон URL, а модель предсказывает правдоподобное продолжение. Проверка ссылок должна быть отдельным шагом: автоматическая валидация или запрет генерировать URL вручную.
Достаточно ли понизить температуру?
Понижение температуры делает ответы стабильнее, но не устраняет вымысел: при отсутствии знания модель всё равно выберет наиболее вероятный вариант. Это косметическая мера, а не решение.
Как понять, что ответ надо перепроверить?
Смотрите на концентрацию конкретики: числа, даты, имена, цитаты, ссылки. Чем больше деталей в ответе и чем меньше источников приложено, тем выше риск. Отсутствие источника при наличии деталей — главный красный флаг.
Итог. Галлюцинации — не баг, который однажды починят патчем, а свойство технологии. Работающая стратегия выглядит скучно: источники в контексте, цитаты в ответе, разрешение сказать «не знаю», тесты на регрессию и человек там, где ошибка дорого стоит. Если вы хотите выстроить это системно, читайте разборы AI Digest по RAG, промптам и инфраструктуре — там есть практические схемы без обещаний магии.
