Hallucination (галлюцинации LLM) — почему модели «выдумывают» и как это контролировать

Hallucination (галлюцинации LLM): почему это важно

• Риски продукта и бренда. Новости, финансы, юр-контент, здоровье — сферы, где ошибка дорого стоит.
• Доверие пользователей. Один «самоуверенный бред» разрушает доверие быстрее, чем десять корректных ответов.
• Стоимость эксплуатации. Галлюцинации порождают ретраи, ручные проверки и инциденты.

Наша задача — не «искоренить навсегда» (это невозможно), а снизить частоту и тяжесть, встроив контроль и верификацию на каждом этапе.

Таксономия галлюцинаций

Примечание. «Галлюцинация» охватывает и overconfident tone — когда модель уверенно пишет о неизвестном.

Откуда берутся галлюцинации

1) Статистическая природа генерации. LLM обучена максимизировать правдоподобие текста, а не истинность. Если распределение обучающих данных не покрывает кейс, модель восполняет «дыры» шаблонами.

2) Ограничения окна и контекста. Если факт не помещён в контекстное окно, модель его «не видит». Слишком длинные вводы страдают от *lost in the middle*; важное вытесняется «водой».

3) Декодирование. Высокая temperature/top_p, отсутствие штрафов за повтор/длину, длинные ответы без ограничений — всё это повышает вероятность «красиво, но неверно».

4) Промпт-давление. Формулировки вроде «любой ценой дай ответ» поощряют выдумку. Нет инструкции «скажи, что не знаешь» — модель не признаёт неопределённость.

5) Слабый retrieval. При RAG нерелевантные чанки, дубликаты и «шум» приводят к неверной сборке ответа.

6) Несогласованные инструменты. Ошибки интеграции (функции, плагины, API) → модель «симулирует» звонок к инструменту и подставляет выдуманные результаты.

7) Обновляемость фактов. Темпоральные домены (крипто-листинги, регуляторика) быстро «стареют». Без свежего контекста ответы становятся ложными.

Признаки «галлюцинации на подходе»

• Нулевая атрибуция при сложной теме, где без источника не обойтись.
• Слишком уверенный тон при низкой информированности.
• Несостыковки в числах/датах между параграфами.
• Раздутая длина без необходимости (length bias).
• Структурные ошибки в JSON/таблицах (лишние поля, непройденная валидация схемы).

Способы обнаружения (evals и сигналы)

• Faithfulness/Groundedness — сверка утверждений с контекстом (см. evals).
• Citation-precision — проверка, что ссылки реальны и указывают на верный фрагмент.
• Retrieval-precision/recall — качество подбора чанков при RAG.
• Pairwise win-rate с «моделью-судьёй» и ручной валидацией на подвыборке.
• Схемная валидация — JSONSchema для инструментальных ответов.
• Негативные тесты — вопросы без ответа: модель должна честно сказать «нет данных».

Практики снижения риска

Промпт-уровень

• Явно разрешайте «не знаю/нет данных»: это снижает давление «ответить любой ценой».
• Инструкция «опирайся только на контекст» + пометка запрещённых источников.
• Требуйте цитаты/ссылки или идентификаторы источников, если домен чувствителен.
• Регулируйте temperature/top_p, ограничивайте max_tokens по задаче.
• Якоря в длинном вводе: краткий «итоговые тезисы» в конце, единый шаблон.

RAG-уровень (см. RAG)

• Индекс: чистые чанки 400–1 200 токенов, перекрытие 50–150, дедупликация.
• Ранжирование: берите k релевантных + реферат в хвосте.
• В сборке контекста маркируйте источники [A] [B] [C] и факты, чтобы модель ссылалась однозначно.
• Не лейте «всё подряд» — шум провоцирует галлюцинации.

Декодирование

• Для фактологии ставьте низкую температуру и консервативный decoding.
• Включайте стоп-фразы (например, «Если нет источника — остановись»).
• Penalize длинные «ничего не значащие» выводы.

Верификация

• N-of-m: несколько ответов разными сидами → проверка согласия.
• Self-check: попросите модель пометить все утверждения, требующие источника, и указать, на какой фрагмент они опираются.
• Внешние проверяющие: регулярные задачи прогонять через альтернативную модель/правила.
• Тесты/компиляция для кода; проверка адресов/хешей для крипто-кейсов.

Инструменты/функции

• Строгие контракты I/O и валидация схемы.
• Логируйте каждый вызов инструмента: модель не должна «симулировать» ответ функции.
• Критичные вычисления — только через инструмент (калькулятор, курсы, трекер блокчейна), не доверяйте «в уме».

Политики и ограничения

• Определяйте «красные зоны» (регуляторика, финсоветы).
• Используйте политики и защитный слой (guardrails) для блокировок/перефразирования.

Галлюцинации в длинном контексте

Длинные вводы не гарантируют отсутствие ошибок. Проблемы:

• «Lost in the middle» — информация в середине хуже вспоминается.
• Перегрузка дубликатами и «водой».
• Вытеснение системных правил пользовательским текстом.

Приёмы:

• Краткое «резюме фактов» в хвосте окна.
• Единый шаблон: «Инструкции → Данные → Ожидаемый формат».
• Регулярная суммаризация истории с закреплением «вечных фактов». Подробности — контекстное окно.

Галлюцинации в RAG (отдельный класс)

• Вне-контекстные утверждения. Ответы «из головы», когда релевантный фрагмент не найден.
• Стык чанков. Факт «разрезан» между чанками; нужен перекрывающий сплит.
• Не тот документ. Ранжировщик выбрал похожий, но неверный фрагмент.

Снижение:

• Вводите answerability-политику: если в топ-k нет достаточного факта — отвечай «нет данных».
• Требуйте прямую цитату (extractive) перед «пересказом своими словами».
• Отдельно валидируйте retrieval precision/recall (см. evals).

Примеры доменных анти-паттернов (крипто)

• Листинги/делистинги. Модель «помнит» старые анонсы и путает даты; без свежего контекста утверждения — под запретом.
• Адреса и MEMO/Tag. Любые «сгенерированные» адреса — недопустимы; только копирование из источника/сканера.
• Комиссии/сети вывода. Вчерашние размеры и сети сегодня уже другие; утверждения возможны только с проверяемой ссылкой.

Контроль качества в проде

• PR-evals на 50–200 задач перед релизом промпта/модели.
• «Глубокий слой» еженедельно: фактичность, faithfulness, цитаты, стоимость/латентность.
• Алерты на: рост доли «уверенных без источника», падение citation-precision, всплеск ошибок схемы.

Мини-чек-лист «до/во время/после»

До генерации

1. Определите целевую строгость: нужен ли источник/цитата?
2. Настройте retrieval (если RAG): k, размер чанка, фильтр дубликатов.
3. Сформулируйте инструкции отказа («если данных нет — скажи об этом»).

Во время генерации

1. Стриминговая проверка: не уходят ли ответы в «общие слова» без фактов.
2. Ограничьте длину и добавьте стоп-критерии.

После

1. Верификация ссылок/цитат и схемы.
2. Для кода — запуск тестов; для чисел — пересчёт инструментом.
3. Логи: отметьте утверждения, потребовавшие ручной проверки.

Мини-плейбук для команд

• «Факты → из источника, а не из памяти модели». Для динамичных тем — только RAG/инструменты.
• Установите стандарт: если нет источника/цитаты — «нет данных».
• Делайте pairwise-оценки и ручные проверки для чувствительных доменов.
• Введите политику ретраев: другой сид/модель + проверка расхождений.
• Храните аудит следов: какой контекст, какая версия промпта/модели, какой инструмент вызван.

См. также

• RAG: как подбирать контекст
• Guardrails
• AI Security Hub