Галлюцинации больше не сводятся к одному трюку. Это целый стек: поиск по базе, prompts, формат ответа, явный отказ от ответа и проверки после генерации, которые честно знают свои границы. Модели редко не хватает уверенности. Системе чаще не хватает дисциплины.
Слабая защита
Модель просто просят быть точной.
- слабый поиск
- нет правила для отказа
- свободная форма ответа
- один расплывчатый quality score
Система с опорой на источники
Система устроена так, чтобы говорить только там, где есть опора.
- поиск ограничен задачей и поддаётся разбору
- неподтверждённые утверждения можно остановить
- ответы проверяются автоматически
- evals бьют по конкретным классам сбоев
1. Галлюцинации редко бывают только модельной проблемой
В продакшене галлюцинации часто возникают из-за системных ошибок:
- слабого или отсутствующего контекста
- расплывчатой постановки задачи
- слишком свободной формы ответа
- неясных правил отказа
- отсутствия downstream checks
Замена модели иногда уменьшает симптомы, но редко лечит архитектуру.
2. Дисциплина поиска сильнее, чем просто большой объём контекста
Опора на источники обычно улучшается не тогда, когда система поднимает больше текста, а тогда, когда поднимает меньше, но точнее.
Рабочий паттерн обычно такой:
- искать только документы, относящиеся к конкретному вопросу
- сохранять идентичность источника до самого ответа
- требовать от модели отвечать из найденного набора или отказаться
- разбирать сбои поиска отдельно от сбоев генерации
Плохой паттерн — stuffed prompt из всего, что хоть как-то связано с темой. Шума это почти всегда добавляет быстрее, чем правды.
3. Prompt должен делать неопределённость законной
Prompt полезен там, где задаёт границы.
Хороший prompt для high-stakes ответа обычно:
- точно определяет задачу
- задаёт формат ответа
- говорит, что считается достаточным подтверждением
- явно разрешает сказать, что ответа нет в источниках
Если prompt подразумевает, что ответ нужно выдать всегда, система нередко именно так и поступит.
4. Few-shot examples задают не стиль, а поведение
Примеры полезны не только для tone. Они задают pattern of behavior:
- когда цитировать
- когда отвечать коротко
- когда держаться строгой схемы
- когда отказываться, если поле нечем подтвердить
Сильные examples нередко дают больше, чем ещё один абзац инструкций.
5. Guardrails полезны только внутри честных границ
Любой guardrail хорош ровно настолько, насколько честно вы описали его рамки.
Их стоит использовать для:
- policy checks
- структурных доменных правил
- контролируемой проверки после ответа
Но не как магическое обещание, что весь ответ автоматически стал истинным.
6. Проверять лучше утверждения, а не общее впечатление от ответа
Гораздо полезнее задавать не вопрос «ответ в целом хороший?», а более узкие вопросы:
- какие утверждения опираются на найденные источники?
- какие завязаны на policy?
- какие чувствительны к числам и датам?
- где система должна отказаться, если подтверждения не найдено?
Так можно переписать или отбросить только опасные части, а не весь ответ целиком.
7. Evals ловят регрессии, которые prompt review пропускает
Сильный набор evals обычно разделяет хотя бы такие классы сбоев:
- промах поиска
- уверенное, но неподтверждённое утверждение
- несоответствие цитаты источнику
- ошибку с отказом
- ошибку формата
- регрессию по задержке или стоимости
Если всё сводится к одному общему quality score, вы теряете диагностическую силу.
8. Надёжная production-позиция
Самый полезный сдвиг — перестать оптимизировать «убедительность» и начать оптимизировать дисциплину работы с подтверждениями.
В high-stakes системах лучший ответ нередко выглядит скромнее, чем хотелось бы команде. Это нормально. Вежливое извинение — ещё не полезный отказ. Слабый, но честный отказ лучше сильной, но ничем не подтверждённой формулировки.