Как уменьшить галлюцинации

Галлюцинация — это когда модель уверенно утверждает то, чего нет: несуществующую функцию библиотеки, неверную дату, «факт» о клиенте, которого клиент не говорил. Полностью это не лечится, но сильно сокращается промптом. В уроке — почему модель придумывает, какие приёмы работают и что менять в собственных привычках.

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

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

Второй источник — отвлекающие данные. Если в документе есть цифра, похожая на нужную, но относящаяся к другому периоду или другой метрике, модель может взять её, потому что она «подходит по форме». В туториале это показано на годовом отчёте компании: вопрос про число подписчиков на конкретную дату, а в документе есть число на другую дату — и модель отвечает им.

Третий — вопросы с ложной предпосылкой. «В каком году вышел восьмой альбом исполнительницы?» — а у неё их семь. Модель прошлого поколения называла год восьмого альбома, которого не существует, потому что вопрос предполагает, что он есть.

Приём первый: дать выход

Самое простое и самое действенное — разрешить модели не отвечать. «Отвечай, только если уверен. Если не знаешь — так и напиши». Или строже: «Если в документе нет информации, достаточной для ответа, ответь „в документе этого нет“ и не пытайся угадать».

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

Формулировки, которые работают:

• «Если не уверен, скажи об этом прямо, а не угадывай».
• «Отметь, какие части ответа — факты из документа, а какие — твои предположения».
• «Если требования допускают несколько трактовок, перечисли их, а не выбирай одну».
• «Не придумывай названия функций, параметров и версий; если не помнишь точно, напиши „нужно проверить в документации“».

Для вопросов с ложной предпосылкой добавьте: «Сначала проверь, верна ли предпосылка вопроса».

Приём второй: сначала цитаты, потом ответ

Когда ответ должен опираться на документ, попросите модель сначала выписать дословные цитаты, относящиеся к вопросу, а потом отвечать только на их основе:

Прочитай документ и ответь на вопрос.

Сначала в тегах <quotes> приведи дословные цитаты из документа,
которые относятся к вопросу. Если подходящих цитат нет — напиши
об этом в <quotes> и в ответе скажи, что документ не содержит
нужной информации.

Затем в <answer> дай ответ, опираясь только на приведённые цитаты.

<document>
…
</document>

<question>Сколько пользователей было у сервиса на 31 мая 2020 года?</question>

Этот приём делает две вещи. Модель фокусируется на нужных фрагментах и перестаёт «видеть» отвлекающие цифры в остальном тексте. И вы получаете проверяемый след: если цитата не отвечает на вопрос, это видно сразу. В примере с отчётом модель, выписав цитату, замечает, что в ней другая дата, и правильно отвечает «данных на эту дату нет».

Для длинных документов документация советует ставить документ в начало промпта, а вопрос и инструкции — в конец: так модель лучше удерживает задачу. Больше об этом в уроке «Поиск и извлечение данных».

Приём третий: проверять, а не верить

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

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

Спрашивайте об уверенности: «оцени, насколько ты уверен в каждом пункте, и объясни почему». Модель неплохо различает, что она знает твёрдо, а что реконструирует.

Разбивайте: если ответ большой, попросите отдельно «факты из документа» и отдельно «выводы и предположения». Смешанный текст читается убедительно целиком, а раздельный показывает, где почва твёрдая.

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

Что изменилось в новых моделях

Современные модели Claude заметно реже выдумывают и лучше признают незнание. Бегемота они не придумают. Но на сложных документах, редких библиотеках, свежих событиях и собственном коде проекта галлюцинации остаются — и приёмы выше по-прежнему нужны. Для работы с кодом документация советует прямо запрещать рассуждать о файлах, которых модель не открывала: «никогда не делай утверждений о коде, который ты не прочитал».

Пример из работы

Из нашего опыта: при подготовке сайта для клиента модель заполнила карточки работ правдоподобными деталями — сроки, материалы, «шоурум», — которых клиент не называл. Текст читался гладко, и ошибка обнаружилась только при вычитке. Исправленный промпт содержал правило «публикуй факт, только если он есть в <client_materials>; если данных нет — пиши „уточнить у клиента“ вместо правдоподобного значения» и просьбу к каждому факту прикладывать цитату из материалов. Выдуманные детали исчезли, а на их месте появился список вопросов клиенту — что и требовалось.