Прямой ответ: что такое галлюцинация и почему она возникает
Галлюцинация LLM — это генерация текста, который выглядит правдоподобно, но содержит фактические ошибки: несуществующие ссылки, выдуманные API, искажённые данные или события, которых не было. Модель не «лжёт» намеренно. Она предсказывает наиболее вероятную последовательность токенов, и если в обучающих данных не было точного ответа, заполняет пробел статистически правдоподобным, но неверным продолжением.
Полностью устранить галлюцинации невозможно — это следствие самой архитектуры autoregressive language models. Но долю ошибок можно существенно снизить комбинацией методов: retrieval-augmented generation, structured output, настройка параметров декодирования и пост-валидация.
Механизмы галлюцинаций на разных уровнях
Обучение: сжатие, конфликты и временной срез
LLM не хранит факты в виде записей базы данных. Знания «впечатаны» в веса модели через предсказание следующего токена на огромном корпусе текстов. Это создаёт несколько системных проблем:
- Конфликт источников. Если в обучающих данных одно утверждение встречается чаще другого (даже если второе верное), модель склонна воспроизводить более частотный вариант. Частотность в корпусе не равна истинности.
- Разреженность знаний. Для узкоспециальных тем — редкие CVE, внутренние API, локальные нормативные акты — модель видела мало примеров и вынуждена интерполировать. Интерполяция между далёкими точками часто даёт бессмысленный результат.
- Временной срез. Обучение завершается на определённой дате. Всё, что произошло после, модели неизвестно, но она может генерировать правдоподобные, но вымышленные события, «заполняя» пробел после cutoff.
- Сжатие с потерями. Модель с конечным числом параметров не способна точно запомнить весь корпус. Она хранит сжатое представление, и при извлечении редких или детальных фактов точность падает.
Декодирование: как параметры сэмплирования влияют на ошибки
На этапе генерации модель на каждом шаге строит распределение вероятностей по словарю. Параметры сэмплирования определяют, как из этого распределения выбирается токен:
| Параметр | Эффект на галлюцинации |
|---|---|
temperature = 0 (greedy) | Минимизирует случайность, но может «зациклить» неверный путь, если первый токен уже ошибочный |
temperature > 1 | Увеличивает разнообразие, но повышает шанс выбора маловероятного и неверного токена |
top_p (nucleus sampling) | Ограничивает выборку наиболее вероятными токенами; слишком широкий top_p допускает редкие и потенциально ошибочные варианты |
top_k | Жёстко обрезает хвост распределения; малое k снижает разнообразие, но и риск галлюцинации |
Ни одна настройка не гарантирует отсутствие ошибок — она лишь смещает баланс между креативностью и точностью.
Контекст: потеря внимания и противоречия
При длинных контекстах модель может «терять» информацию из начала промпта. Это явление описывается как lost in the middle: факты, расположенные в середине длинного контекста, извлекаются хуже, чем те, что в начале или конце. Если в контексте есть противоречивые данные, модель не всегда выбирает корректный источник.
Практическое следствие: даже если правильный ответ присутствует в контексте, модель может его проигнорировать или смешать с неверными фрагментами.
Формат: вынужденная генерация
Когда пользователь запрашивает конкретный формат (JSON, таблицу, список с определённым числом элементов), модель стремится его заполнить, даже если данных недостаточно. Это порождает выдуманные поля, несуществующие записи и «заполнители», которые выглядят как реальные данные.
Пример: запрос «верни JSON с 5 последними обновлениями пакета» при наличии только 3 обновлений в контексте приведёт к тому, что модель «дорисует» два недостающих.
Методы снижения галлюцинаций
Retrieval-Augmented Generation (RAG)
RAG подаёт модели актуальные и релевантные фрагменты из внешнего источника (документация, база знаний, поисковый индекс) непосредственно в контекст запроса. Модель отвечает, опираясь на предоставленные фрагменты, а не на «память» весов.
Ключевые принципы эффективного RAG:
- Качество чанков. Фрагменты должны быть самодостаточными: содержать заголовок, контекст и конкретный факт. Слишком короткие чанки теряют смысл, слишком длинные размывают релевантность.
- Ранжирование. Не все найденные фрагменты одинаково полезны. Реранкинг по релевантности к запросу снижает шум.
- Инструкция модели. Явное указание «отвечай только на основе предоставленных фрагментов; если информации нет — скажи, что не знаешь» критически важно. Без него модель всё равно может дополнять ответ из весов.
- Цитирование. Требование указывать источник для каждого утверждения позволяет пользователю проверить ответ и одновременно дисциплинирует модель.
Подробный разбор архитектуры RAG — в материале Что такое RAG: как подключить собственные данные к LLM и не утонуть в галлюцинациях.
Structured Output и constrained decoding
Если задача требует строгого формата (JSON, XML, таблица), использование constrained decoding или structured output снижает вероятность того, что модель «придумает» лишние поля или нарушит схему.
Библиотеки вроде vLLM поддерживают генерацию структурированного вывода через xgrammar или guidance, что гарантирует синтаксическую валидность ответа на уровне грамматики.
Это не устраняет фактические ошибки внутри полей, но убирает целый класс проблем: неверный формат, лишние ключи, незакрытые скобки, которые часто воспринимаются как «галлюцинации» на уровне интеграции.
Детали работы со structured output — в Structured Output: как получать от LLM валидный JSON и не парсить ответ регулярками.
Настройка параметров декодирования для точности
Для задач, где точность важнее креативности:
Код:
temperature: 0.0–0.3
top_p: 0.9–0.95
max_tokens: ограничить разумным потолкомНизкая температура делает распределение более «острым»: модель чаще выбирает токен с максимальной вероятностью. Это снижает случайные отклонения, но не гарантирует фактической корректности — если наиболее вероятный токен уже ошибочен, greedy decoding его воспроизведёт.
Важно: параметры декодирования влияют на стабильность галлюцинаций, а не на их наличие. Модель может уверенно и стабильно выдавать неверный факт.
Пост-валидация и self-consistency
- Self-consistency. Генерация нескольких ответов на один запрос (с
temperature > 0) и выбор наиболее частого или согласованного варианта. Если модель «уверена» в факте, он воспроизводится стабильно; галлюцинации часто нестабильны между запусками.
- Внешняя проверка. Сверка сгенерированных фактов с авторитетным источником (поисковый API, база данных, документация). Самый надёжный, но и самый дорогой метод.
- Цепочки рассуждений (Chain-of-Thought). Просьба к модели сначала рассуждать, а затем давать ответ. В некоторых задачах это снижает долю ошибок, потому что модель «проходит» через промежуточные шаги, а не перепрыгивает к выводу.
- Исполняемая проверка. Если ответ — код, SQL-запрос или API-вызов, его можно прогнать через исполняемую среду и зафиксировать ошибки. Это превращает задачу оценки из субъективной в объективную.
Speculative Decoding и квантизация: косвенное влияние
Speculative decoding ускоряет генерацию, используя черновую модель для предложения токенов, которые затем верифицируются основной моделью. Сам по себе он не снижает галлюцинации, но позволяет запускать более крупные и точные модели в том же бюджете latency.
Квантизация (INT8, INT4, FP8) уменьшает потребление памяти, но может незначительно ухудшать качество генерации. Для критичных к точности задач стоит проверять, не увеличивает ли квантизация долю ошибок на конкретном бенчмарке.
Подробнее: Speculative Decoding: как черновая модель ускоряет генерацию LLM без потери качества и Квантизация LLM: AWQ, GPTQ и FP8 — как уменьшить память без лишней потери качества.
Типичные ошибки при борьбе с галлюцинациями
| Ошибка | Почему не работает |
|---|---|
| «Просто попросить модель не галлюцинировать» | Без внешнего источника знаний модель не может отличить факт от интерполяции |
| Увеличение контекста без фильтрации | Шумные фрагменты ухудшают внимание и могут сами стать источником ошибок |
temperature = 0 как панацея | Greedy decoding воспроизводит наиболее вероятный, но не обязательно верный токен |
| Доверие к confidence score | Вероятность токена не коррелирует с фактической точностью; модель может быть «уверенно неверной» |
| Отсутствие ground truth для оценки | Без размеченного набора примеров невозможно измерить, снизился ли уровень галлюцинаций после изменений |
| Один метод вместо комбинации | Каждый метод закрывает только часть проблемы; без комбинации остаются слепые зоны |
Как измерить долю галлюцинаций
Единого стандартного бенчмарка нет, но рабочие подходы:
- Ручная разметка. Взять выборку ответов модели, классифицировать каждый как «верный / частично верный / галлюцинация». Дорого, но даёт точную картину.
- Автоматическая сверка. Если задача допускает (генерация SQL, API-вызовов, конфигураций), прогонять ответ через исполняемую среду и фиксировать ошибки.
- LLM-as-judge. Использовать другую (или ту же) модель для оценки фактической корректности ответа. Быстрее ручной разметки, но вносит собственную погрешность.
- Сравнение A/B. Замерить долю ошибок до и после внедрения RAG, изменения промпта или параметров декодирования на одном и том же наборе запросов.
Для корректного A/B-теста важно фиксировать все переменные, кроме тестируемой: модель, версию, параметры декодирования, формат промпта.
Практический чек-лист
- Определите, какие типы галлюцинаций критичны для вашей задачи: фактические ошибки, выдуманные ссылки, неверный формат.
- Подключите RAG с качественным ранжированием и явной инструкцией «не дополняй из памяти».
- Используйте structured output, если ответ должен быть машиночитаемым.
- Установите
temperature ≤ 0.3для задач, где точность приоритетнее разнообразия.
- Внедрите пост-валидацию: хотя бы выборочную сверку с источником.
- Соберите набор тестовых запросов с известными правильными ответами и замеряйте долю ошибок при каждом изменении конфигурации.
- Не рассчитывайте на один метод: комбинация RAG + structured output + валидация даёт значительно лучший результат, чем любой из них по отдельности.
