Модель пишет: «Функция доступна во всех тарифах», прикладывает уверенное объяснение и даже называет раздел документации. Вы открываете ссылку — такого раздела нет, а функция работает только в старшей редакции. Ответ был удобным, быстрым и неправильным.
Галлюцинацией называют ответ модели, который выглядит связным, но содержит выдуманный или искажённый факт. Это может быть несуществующая ссылка, неверная дата, придуманная функция продукта или уверенный вывод без достаточных оснований. В профиле рисков генеративного ИИ NIST использует близкий термин confabulation: уверенно представленное ошибочное или ложное содержание.
Почему модель продолжает, даже когда не знает
LLM обучена создавать вероятное продолжение текста. У неё нет встроенной границы между «знаю» и «не знаю» в человеческом смысле. Если контекста недостаточно, модель всё равно может собрать ответ из похожих закономерностей.
Риск растёт, когда вопрос неоднозначен, требует свежих данных, содержит редкие сущности или просит точную цитату без предоставленного источника.
Важно различать три ситуации. Первая: факт существовал в данных обучения, но модель воспроизвела его неверно. Вторая: нужная информация вообще не попала в доступный контекст. Третья: источник был передан, но система нашла не тот фрагмент или неверно его истолковала. Снаружи результат похож, а исправления нужны разные.
Типовые причины ошибок
- в обучающих данных не было нужного факта или он устарел;
- в запросе недостаточно контекста;
- документы противоречат друг другу;
- модель пытается выполнить требование пользователя любой ценой;
- длинный диалог вытеснил важную инструкцию из контекста;
- интеграция передала неполные результаты поиска;
- формат ответа создаёт ложное ощущение точности.
Удобно искать не абстрактную «причину галлюцинации», а конкретное место отказа:
| Где возникла проблема | Что видно в ответе | Что изменить | Как проверить |
|---|---|---|---|
| Нет нужного знания | Общие слова вместо факта | Дать актуальный источник | Задать вопрос с известным ответом |
| Плохой поиск | Ссылка ведёт не на тот раздел | Улучшить разбиение и ранжирование документов | Проверить найденные фрагменты отдельно от генерации |
| Конфликт документов | Ответ смешивает версии | Передавать дату и приоритет источника | Тест на старой и новой редакции |
| Давление на обязательный ответ | Модель угадывает | Разрешить отказ и уточнение | Измерять корректные отказы |
| Ошибка интеграции | Цитата не соответствует данным | Логировать вход инструмента | Сопоставить журнал вызова с ответом |
Почему «не галлюцинируй» не решает проблему
Инструкция быть точной полезна, но она не добавляет модели недостающих данных и не создаёт механизм проверки. Промпт может попросить обозначать неопределённость, ссылаться на контекст и отказываться при отсутствии сведений. Это снижает риск, но не заменяет архитектуру.
OpenAI связывает часть устойчивых галлюцинаций не только с предобучением, но и с тем, как ответы оцениваются: если за угадывание иногда дают балл, а признание неуверенности всегда считается проигрышем, модель получает стимул отвечать даже без достаточных оснований. Для продукта из этого следует практическое правило: правильный отказ должен быть допустимым и измеряемым исходом.
Как уменьшить риск
Передавайте проверенный контекст и требуйте отвечать только на его основе. Для корпоративных знаний используйте поиск по документам и возвращайте ссылки на конкретные фрагменты. Проверяйте структурированные поля программно. Разделяйте генерацию и принятие решения.
Один из распространённых подходов — RAG, когда перед генерацией система ищет релевантные фрагменты во внешней базе. В исходной работе о retrieval-augmented generation авторы объединяли параметры модели с извлечёнными документами и показывали более фактический текст в исследованных задачах. Но RAG не является переключателем «истина»: плохой поиск, устаревший документ или неверная интерпретация сохраняют риск.
Поэтому я разделяю контур на этапы:
- система получает вопрос и определяет, каких данных не хватает;
- поиск возвращает документы с версиями и прямыми ссылками;
- модель отвечает только в пределах найденных фрагментов;
- код проверяет структуру и обязательные поля;
- критические утверждения подтверждает человек.
Для повторяемых задач соберите набор тестовых примеров: обычных, сложных и провокационных. Измеряйте не только красивый результат, но и долю отказов, точность ссылок и последствия ошибки.
В тестовый набор стоит добавить не только вопросы с ответом, но и вопросы, на которые система обязана сказать «не знаю». Иначе вы не узнаете, умеет ли она останавливаться. Отдельно проверяйте свежесть: тариф, регламент или интерфейс продукта могут измениться, хотя ответ модели остался лингвистически безупречным.
Минимальные метрики для такого набора:
- доля утверждений, подтверждённых источником;
- доля ссылок, которые открываются и содержат заявленный тезис;
- корректность отказа при отсутствии данных;
- число критических ошибок, прошедших до человека;
- стабильность результата после смены модели, промпта или базы документов.
Когда нужен человек
Человек особенно важен там, где ответ влияет на деньги, права, безопасность или отношения с сотрудниками и клиентами. Его роль должна быть частью процесса, а не неформальным пожеланием «потом перепроверить».
Нужно заранее определить, что именно он подтверждает. Формальное нажатие «одобрить» после длинного ответа почти бесполезно. Гораздо лучше показать отдельные спорные утверждения, источник рядом с каждым и последствия решения. Тогда проверка становится действием, а не ритуалом.
Практический алгоритм я собрал в отдельном разборе по фактчекингу ответов нейросети. Если пока неясно, почему модель вообще генерирует ответ вероятностно, начните с объяснения как работает LLM.
Что делать после первой галлюцинации
Не ограничивайтесь исправлением одной фразы. Сохраните запрос, контекст, найденные документы, версию модели и финальный ответ. Затем определите, где возник сбой: в данных, поиске, инструкции, генерации, интеграции или человеческой проверке. Добавьте этот случай в тестовый набор и только потом меняйте систему.
Так единичная ошибка превращается в контрольный пример. Если просто переписать ответ вручную, процесс ничего не узнает и повторит проблему при следующем похожем запросе.
Главное
Галлюцинации нельзя полностью убрать обещанием модели. Ими управляют через качественный контекст, ограничения, источники, тестирование и продуманное распределение ответственности.