Галлюцинации ИИ: почему LLM выдумывают факты и как это снизить

Почему модель выдумывает

Галлюцинация — это ответ, который звучит уверенно и грамотно, но не соответствует фактам: несуществующая статья закона, выдуманная функция библиотеки, неверная дата.

Причина в самом устройстве модели. LLM обучена продолжать текст наиболее правдоподобным образом. У неё нет встроенной базы фактов, к которой она обращается перед ответом. Если модель «не знает», она всё равно генерирует текст, похожий на правильный ответ.

Основные причины:

• Пробелы в обучающих данных. О редких, локальных или свежих темах модель знает мало, но всё равно отвечает.
• Устаревшие знания. Данные обучения заканчиваются на определённой дате, а мир меняется.
• Давление вопроса. Вопрос «Какой номер у постановления о...» подразумевает, что номер существует, и модель охотно его «вспоминает».
• Длинный или шумный контекст. Когда в запросе много документов, модель может смешать детали из разных источников.
• Стиль вместо сути. Модель хорошо воспроизводит форму (ссылки, цифры, термины) даже там, где содержания нет.

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

• Юридические, медицинские и финансовые ответы.
• Конкретные цифры, даты, имена, ссылки и цитаты.
• Код с вызовами API, которых нет в библиотеке.
• Ответы клиентам от имени компании: цены, условия, сроки.

Чем дороже ошибка, тем больше уровней защиты нужно.

Как снизить галлюцинации на практике

1. Опора на источники (grounding)

Самый действенный приём — дать модели нужные данные прямо в запросе. Это и есть RAG (Retrieval-Augmented Generation): система находит релевантные фрагменты в ваших документах и передаёт их модели вместе с вопросом. Модель отвечает по тексту, а не «по памяти».

2. Требование цитат

Попросите модель указывать, из какого фрагмента взят каждый факт. Это дисциплинирует ответ и позволяет быстро проверить его. Если цитату найти нельзя — утверждение под вопросом.

3. Разрешение отказаться

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

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

4. Шаги проверки

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

5. Настройки и формулировки

• Низкая temperature делает ответы менее «творческими» для фактических задач.
• Узкая роль и чёткие рамки лучше, чем «ответь на любой вопрос».
• Разбивайте сложную задачу на шаги вместо одного огромного запроса.

6. Оценка (evals)

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

Типичные ошибки

• Доверять ответу, потому что он звучит уверенно.
• Подключить RAG, но не проверить, находит ли поиск нужные фрагменты. Плохой поиск — частая причина ошибок.
• Не тестировать на вопросах, ответа на которые в базе нет.
• Пускать ответы ИИ клиентам без какой-либо проверки в чувствительных темах.