Галлюцинации LLM: причины, типы и методы борьбы

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

В этой статье — почему LLM галлюцинируют, какие бывают типы галлюцинаций, в каких задачах они опаснее всего, какие методы снижения работают на практике, какие метрики и инструменты используются для контроля качества в production-системах.

Что такое галлюцинации в LLM

Галлюцинация — генерация моделью контента, который не соответствует фактической реальности или предоставленному контексту. Термин пришёл из психиатрии, где означает восприятие несуществующих вещей. В случае LLM это «восприятие» — продукт статистических закономерностей в обучающих данных, не имеющий связи с реальными фактами.

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

Знаменитые случаи галлюцинаций в production: юрист, использовавший ChatGPT для подготовки судебных документов, представил в суде шесть несуществующих прецедентов с конкретными номерами и цитатами. ИИ-ассистент Air Canada дал клиенту ложную информацию о возврате денег, и суд обязал авиакомпанию выполнить обещание ассистента. Эти случаи стали учебными примерами рисков необдуманного использования LLM.

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

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

Когда пользователь спрашивает «какие книги написал Пушкин в 1827 году», модель:

• Понимает контекст: вопрос о Пушкине, литература, конкретный год
• Активирует статистические закономерности, связанные с этими понятиями
• Генерирует ответ, выглядящий правдоподобно

Если в обучающих данных есть точная информация о книгах Пушкина 1827 года — модель воспроизведёт её. Если нет — она сгенерирует «правдоподобный» ответ, опираясь на похожие закономерности (стиль ответов о литературе того периода, типы названий русских произведений 19 века). Это и есть галлюцинация.

Основные причины галлюцинаций:

• Пробелы в обучающих данных. Модель не видела точную информацию по запросу.
• Противоречивые источники. Разные документы говорят разное, модель усредняет или выбирает один из вариантов.
• Устаревшие знания. Cutoff date не охватывает свежую информацию.
• Чрезмерное обобщение. Модель экстраполирует паттерны на случаи, где они не работают.
• Sampling-эффекты. Высокая температура повышает случайность, что увеличивает риск галлюцинаций.
• Предвзятость к «уверенным» ответам. Модели обучаются давать конкретные ответы, что подавляет признание неуверенности.

Типы галлюцинаций

Не все галлюцинации одинаково опасны. Классификация по типам помогает понять, где сосредоточить усилия по контролю.

Factual hallucinations (фактические)

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

Пример: «Алгоритм Дейкстры был разработан в 1965 году» (на самом деле в 1959).

Contextual hallucinations (контекстные)

Ответ противоречит предоставленному контексту (документу в RAG-системе или истории диалога). Модель «изобретает» детали, которых нет в источнике.

Пример: пользователь предоставил документ о компании Acme. Модель пишет «согласно вашему документу, компания Acme имеет 50 сотрудников» — хотя в документе про число сотрудников не упоминалось.

Source attribution hallucinations

Модель ссылается на несуществующие источники: книги, статьи, исследования, веб-страницы. Часто с правдоподобными деталями: имя автора, журнал, страница.

Пример: «Согласно исследованию Smith et al. (2023) в Nature, опубликованному на странице 45…» — все детали выдуманы, но звучат правдоподобно.

Logical hallucinations

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

Mathematical hallucinations

Ошибки в вычислениях, особенно сложных. Модель «генерирует» правдоподобный, но неверный результат. Эта проблема частично решена через интеграцию calculator-tools в современные модели.

Code hallucinations

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

Когда галлюцинации опаснее всего

Не все приложения LLM одинаково чувствительны к галлюцинациям. Критические области:

• Медицина. Неверная информация о лекарствах, дозировках, симптомах может привести к причинению вреда здоровью.
• Юриспруденция. Несуществующие прецеденты, неверная интерпретация законов, выдуманные нормы.
• Финансы. Неверные финансовые показатели, выдуманные ставки, ложные характеристики инструментов.
• Научная коммуникация. Ложные ссылки на исследования, искажение результатов.
• Журналистика. Распространение дезинформации, ложные цитаты.
• Технические инструкции. Неверные шаги настройки, выдуманные опции.
• Образование. Передача неверных знаний учащимся.
• Customer support. Обещание условий, которых нет в политиках компании.

В нечувствительных задачах (генерация маркетингового контента, brainstorming, переводы общей лексики) галлюцинации менее критичны, потому что результат всё равно проходит человеческую проверку.

Методы снижения галлюцинаций

1. RAG

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

Не панацея: модель может галлюцинировать даже при наличии контекста, если контекст неполный или сформулирован неоднозначно. Также модель может игнорировать контекст в пользу своих «знаний».

2. Temperature и sampling

Низкая температура (0–0.3) делает ответы более детерминированными. Это снижает разброс и уменьшает «креативность» в ответах на факты. Для извлечения структурированной информации температура 0 — стандарт.

Для фактологических задач temperature=0. Для творческих — выше, с пониманием, что галлюцинации более вероятны.

3. Constraint-based prompting

Явные ограничения в промпте: «Отвечай только на основе предоставленного контекста», «Если информация недоступна, ответь „не знаю“», «Не используй данные за пределами контекста».

Эффективно, но не абсолютно. Современные модели заметно лучше следуют таким инструкциям, чем предыдущие поколения.

4. Citation requirements

Требование указывать источник каждого утверждения. «Для каждого факта укажи источник в формате [источник]. Если источник недоступен, явно скажи об этом.»

Заставляет модель «проверять» внутреннее состояние: есть ли реальное основание для утверждения. Снижает галлюцинации в RAG-системах.

5. Self-checking

Двухэтапный процесс: модель генерирует ответ, потом проверяет его на основе тех же или дополнительных источников.

Реализация: «Сгенерируй ответ. Теперь критически проанализируй: какие утверждения могут быть неверными? Перепиши с учётом сомнений.»

6. Chain-of-Verification (CoVe)

Развитие self-checking. Модель сначала отвечает, потом генерирует список вопросов для верификации, отвечает на эти вопросы, и финальный ответ корректирует на основе проверки.

Эффективна для фактологических задач, но дорогая (несколько вызовов LLM на один запрос).

7. Reasoning-модели

Современные reasoning-модели (OpenAI o-series, Claude Extended Thinking, DeepSeek R1) показывают существенно меньше галлюцинаций на сложных задачах за счёт длинного внутреннего рассуждения перед ответом.

8. Tool use вместо «знаний»

Подключение инструментов для критических действий. Calculator вместо «вычислений» в голове. Web search вместо «памяти» о свежих событиях. Database query вместо «припоминания» статистики.

Архитектурное решение: для класса задач, где галлюцинации недопустимы, использовать tool-augmented подход.

Reasoning-модели и галлюцинации

Reasoning-модели — отдельный класс LLM, специально обученных «думать» перед ответом. Они генерируют длинные внутренние цепочки рассуждений (часто невидимые пользователю), на основе которых формируется финальный ответ.

Преимущества для борьбы с галлюцинациями:

• Модель может «обнаружить» противоречие в собственном ответе и скорректировать его
• Длинное рассуждение даёт время на проверку фактов через несколько ракурсов
• Многие reasoning-модели специально обучены признавать неуверенность

Минусы:

• Латентность: ответ занимает 10–60 секунд вместо 1–3
• Стоимость: «думающие» токены тоже оплачиваются
• Не панацея: галлюцинации всё равно возникают, особенно в специализированных доменах

В 2026 году reasoning-модели стали стандартом для критических приложений. Стоимость и латентность оправданы качеством.

Метрики качества

Измерение галлюцинаций — сложная задача. Метрики, используемые на практике:

Автоматические метрики — приближение. Полная оценка требует human evaluation, что ограничивает её применение масштабом.

Инструменты для контроля

Большинство production-команд используют связку: автоматические метрики через RAGAS или TruLens + ручная проверка на репрезентативной выборке + observability для выявления проблем в реальном времени.

Типичные ошибки в работе с галлюцинациями

• Слепое доверие модели. «Если ChatGPT сказал — значит, правда». Без верификации критичных фактов галлюцинации проникают в production.
• Отсутствие метрик. Невозможно улучшать то, что не измеряется. Без бенчмарка галлюцинаций сложно оценить, помогают ли изменения.
• Использование высокой температуры для фактологических задач. Temperature=0.7 для извлечения данных из документа — гарантия повышенных галлюцинаций.
• Игнорирование RAG для специфических доменов. Корпоративные ассистенты без RAG галлюцинируют на каждом втором ответе.
• Доверие модели в качестве проверяющего. «Спроси у модели, правда ли это» — модель часто подтверждает собственные галлюцинации.
• Отсутствие fallback на «не знаю». Модели обучены давать ответ. Без явных инструкций они изобретут что-то, вместо того чтобы признать незнание.
• Игнорирование внешних источников. Не подключать web search или знание-базу там, где это уместно — пропуск возможности снизить галлюцинации.
• Универсальные prompt’ы для разных задач. Промпт для creative writing и для извлечения фактов должны быть разными.
• Отсутствие observability в production. Невозможно обнаружить проблемы, если нет мониторинга качества ответов в реальном времени.
• Перекладывание ответственности на «модель». Юридически и этически — ответственность за галлюцинации остаётся на разработчике системы. Air Canada не смогла защититься фразой «это сказал ИИ».

Часто задаваемые вопросы

Можно ли полностью устранить галлюцинации?

В обозримом будущем — нет. Это фундаментальное свойство LLM. Можно резко снизить (на порядок) через комбинацию RAG, low temperature, citation requirements, reasoning-моделей. Но идеальное «нулевое» состояние недостижимо.

Какие модели меньше галлюцинируют?

В 2026 году frontier-reasoning-модели (Claude, GPT, Gemini в reasoning-режимах) лидируют. Большие модели обычно галлюцинируют реже маленьких. Точные сравнения меняются с каждым релизом, актуальный leaderboard — на HuggingFace и Vectara.

Дороже ли работать с системами, защищёнными от галлюцинаций?

Да. RAG, reasoning-модели, self-checking — всё увеличивает количество токенов и латентность. Стоимость одного запроса может удвоиться-утроиться. Это цена за качество.

Как объяснить пользователям риск галлюцинаций?

Через явные disclaimer’ы в интерфейсе: «AI может ошибаться, проверяйте важную информацию». Через дизайн, побуждающий к проверке. Через автоматические warnings для критических доменов.

Стоит ли использовать LLM в критических областях?

Зависит от роли. LLM как ассистент специалиста (помощь врачу, юристу, финансисту) — да. LLM как автономный принимающий решения — пока нет. Граница меняется с улучшением технологий, но human-in-the-loop остаётся стандартом для high-stakes-задач.

Как обнаружить галлюцинацию в реальном времени?

Через комбинацию: автоматическая проверка фактов через web search или внешние API, citation extraction с верификацией ссылок, semantic similarity между ответом и контекстом (для RAG-систем), classifier-модели, обученные на разметке галлюцинаций. Ни один метод не идеален; комбинация работает лучше.

Заключение

Галлюцинации — фундаментальное ограничение LLM, с которым нужно научиться работать. Это не «временная проблема, которую решат в следующей версии», а свойство технологии. Команды, которые относятся к этой реальности серьёзно — внедряют RAG, мониторят метрики, обучают пользователей проверке, защищают критические сценарии через tool use — строят надёжные AI-системы. Команды, которые игнорируют риск — рано или поздно сталкиваются с проблемами в production: от потерянных клиентов до судебных исков. В 2026 году подход «защита от галлюцинаций как часть архитектуры» — норма для серьёзных AI-приложений, и эта норма продолжит ужесточаться по мере распространения технологии.