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

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

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

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

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

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

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

Галлюцинация это системная ошибка

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

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

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

Дисциплина поиска сильнее объёма

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

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

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

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

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

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

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

Примеры задают поведение

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

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

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

Ограничения внутри модели угроз

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

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

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

Проверять утверждения, не впечатление

Полезнее спрашивать не «ответ хороший?», а более узкие вещи. Какие утверждения опираются на источники. Какие чувствительны к датам и числам. Какие завязаны на правила. Где система должна отказаться, если опоры нет.

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

Evals ловят то, что ручной просмотр пропускает

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

Пятислойный набор:

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

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

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

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

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

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

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

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

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

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

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

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

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

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