Hallucination

hallucination — когда модель уверенно выдаёт неверный факт

Раздел
Языковые модели
Обновлено
05.09.26

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

Коротко

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

Что это такое

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

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

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

Типичные случаи:

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

Как это работает

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

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

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

Уменьшить риск помогают несколько разных мер:

  1. Дать подходящие источники. RAG находит документы и передаёт нужные фрагменты модели. Качество ответа зависит и от того, что нашёл поиск.
  2. Обозначить границы ответа. Например: «Используй только этот документ. Если сведений нет, укажи это».
  3. Связать утверждения с фрагментами. Просить не просто список ссылок, а указание, какой источник подтверждает каждый существенный вывод.
  4. Проверить результат независимо. Сумму можно пересчитать, код — запустить в тестовой среде, цитату — найти в оригинале.
  5. Предусмотреть отказ от ответа. Пустое поле или просьба уточнить данные иногда полезнее заполненного наугад.

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

Пример на практике

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

Выбери из документа функции, которые относятся к работе с цветом.
Для каждой укажи название и раздел документа.
Не добавляй сведения из других версий.
Если из текста непонятно, когда появилась функция, так и напиши.

После ответа редактор открывает указанные разделы. Он проверяет не только существование функции, но и версию, редакцию программы и условия доступности. Так выявляется распространённая подмена: функция действительно есть, но новинкой выбранного выпуска она не является.

Такую цепочку можно собрать и в ComfyUI с подходящими узлами поиска и LLM. Локальность при этом определяется выбранными компонентами: узел, который вызывает облачный API, отправляет данные наружу независимо от того, где открыт интерфейс.

С чем часто путают

  • Галлюцинация и любая ошибка. Термин обычно используют для неподтверждённого или ложного содержания. Ошибку вычисления или нарушение формата полезнее описывать точнее: тогда понятнее способ проверки.
  • Галлюцинация и художественный вымысел. В сказке придуманное событие уместно. В справке о реальном человеке та же свобода превращается в ошибку.
  • Галлюцинация и устаревшие сведения. Описание старой версии могло когда-то быть верным. Его нужно привязать ко времени, а не смешивать с вымышленными новыми функциями.
  • Галлюцинация и обман. По одному неверному ответу нельзя заключить, что система намеренно вводила человека в заблуждение.

Частые ошибки и заблуждения

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

Связанные термины

  • RAG — поиск документов, на которые модель может опереться при ответе.
  • LLMязыковая модель, создающая текст по контексту.
  • Promptзапрос с задачей, данными и ограничениями.
  • Context Window — объём информации, доступный модели в одном обращении.
  • Benchmark — набор задач для оценки качества, в том числе фактической точности.

Частые вопросы

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

RAG полностью устраняет галлюцинации? Нет. Поиск может вернуть неподходящий документ, а модель — неверно его пересказать. Проверять нужно оба этапа.

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

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

Что делать, если ошибка недопустима? Критические значения лучше получать из проверяемых данных и обрабатывать по явным правилам. Если LLM формулирует пояснение, оно проходит отдельную проверку перед использованием. Возможность не выдать ответ должна оставаться частью системы.

Главное

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