Как уменьшать галлюцинации в LLM-системах

Слабая защита

Модель просто просят быть точной.

• слабый поиск
• нет правила для отказа
• свободная форма ответа
• один расплывчатый общий балл

Система с опорой на источники

Система устроена так, чтобы говорить только там, где есть подтверждение.

• поиск ограничен задачей и поддаётся разбору
• неподтверждённые утверждения можно остановить
• ответы остаются проверяемыми
• evals и валидаторы бьют по конкретным классам ошибок

1. Хватит считать галлюцинации только модельной проблемой

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

Модель часто ругают за факты, которые ей никто не дал, за формат, который ей не показали, или за отказ, который ей по сути не разрешили сделать.

Обычно всё упирается в комбинацию из:

• слабого контекста
• расплывчатой задачи
• слишком свободной формы ответа
• невнятных правил отказа
• отсутствия внешних проверок

Замена модели иногда сглаживает симптомы. Архитектуру это редко лечит.

2. Дисциплина поиска сильнее, чем просто большой объём контекста

Опора на источники обычно улучшается не тогда, когда система поднимает больше текста, а тогда, когда поднимает меньше, но точнее.

Нормальный паттерн такой:

• искать только то, что относится к конкретному вопросу
• сохранять идентичность источника до самого ответа
• требовать от модели отвечать из найденного набора или отказаться
• разбирать сбои поиска отдельно от сбоев генерации

Плохой паттерн — набить промпт всем, что хоть как-то связано с темой. Шума это добавляет быстрее, чем пользы.

3. Промпт должен делать неопределённость законной

Промпт полезен там, где задаёт границы.

Хороший промпт для рискованных сценариев обычно:

• точно определяет задачу
• задаёт формат ответа
• говорит, что считать достаточным подтверждением
• явно разрешает сказать, что ответа нет в источниках

Если промпт по смыслу требует отвечать всегда, система очень часто именно так и поступает.

4. Примеры задают поведение сильнее, чем стиль

Сильные примеры делают больше, чем просто улучшают тон ответа.

Они учат модель:

• цитировать только при наличии опоры
• оставаться краткой, когда подтверждений мало
• держать строгую JSON или markdown схему
• отказываться, если поле нечем обосновать

Именно поэтому несколько хороших примеров часто полезнее ещё одного красивого абзаца инструкций.

5. Ограничения полезны только внутри ясной модели угроз

Ограничения помогают тогда, когда вы честно понимаете, что именно они покрывают.

Они подходят для:

• проверки правил
• структурных доменных правил
• ограниченной проверки после ответа
• конкретных рискованных паттернов, которые можно распознать надёжно

Но они не превращают весь ответ в истину автоматически.

OWASP LLM Top 10 полезен именно этим: он заставляет смотреть шире, чем «модель иногда фантазирует». Prompt injection, утечки данных, небезопасная обработка ответа и лишняя автономия нередко делают галлюцинацию уже не досадной, а дорогой.

6. Проверять лучше утверждения, а не общее впечатление от ответа

Гораздо полезнее спрашивать не «ответ хороший?», а более узкие вещи:

• какие утверждения опираются на найденные источники
• какие чувствительны к датам и числам
• какие завязаны на правила
• где система должна отказаться, если опоры нет

Так можно убирать или переписывать только опасные куски, а не выбрасывать ответ целиком всякий раз, когда что-то выглядит подозрительно.

7. Evals ловят регрессии, которые ручной просмотр промпта пропускает

Текущие материалы OpenAI по evals по-прежнему задают правильную оптику: если вам важна правдивость в проде, evals должны стать частью пути к релизу.

Мне нравится хотя бы такой пятислойный набор:

1. проверки ответа на опору в источниках
2. проверки отказа для неподтверждённых утверждений
3. проверки ссылок на источники
4. проверки структурированного ответа
5. red-team кейсы для рискованных доменов

Главное тут не только сам набор. Главное — привычка прогонять его после смены промпта, слоя поиска, модели или reranking.

8. Стриминг создаёт отдельную проблему

Стриминг — хороший продуктовый выбор. И способ быстрее пожалеть о неудачной архитектуре.

Поскольку система показывает текст по кускам, нельзя надеяться только на финальную проверку ответа. Если неподтверждённый или чувствительный контент не должен появляться в публичном интерфейсе, нужны более жёсткие меры:

• более узкие рамки генерации
• буферизация или задержка для самых рискованных полей
• очистка по кускам с удержанием хвоста
• отдельный нестриминговый путь для самых чувствительных типов ответа

Именно поэтому формальные проверки после генерации часто живут за нестриминговыми или частично буферизованными сценариями.

9. Лучший запасной вариант — это полезный отказ

Хороший отказ — не вежливая отписка. Это точная граница.

Примеры полезных отказов:

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

Отказ должен сохранять доверие и подсказывать следующий шаг.

Что ещё почитать

• Безопасность LLM-продукта без театра
• Как устроить evals для LLM-систем в проде

Источники и ссылки

• OpenAI: Evaluation best practices
• OWASP Top 10 for LLM Applications
• NIST AI Risk Management Framework
• Anthropic prompt engineering overview