Почему модель отвечает по-разному и ошибается уверенно

Зачем это нужно

Коллега показывает, как агент за минуту починил тест. Вы повторяете тот же промпт на той же ветке — и агент идёт другим путём, а в конце уверенно вызывает функцию, которой в проекте нет. Это не поломка инструмента. Так устроена модель, и, если понимать почему, понятно и что с этим делать.

Как это устроено

Модель предсказывает следующий token. На вход — последовательность tokens, на выходе — вероятности для кандидатов на продолжение. Для «мой любимый цвет —» это может быть «красный» с 32 %, «синий» с 28 %, «оранжевый» с 14 % и так далее.

Выбирает sampler. Он не всегда берёт самый вероятный вариант: выбор случайный, но взвешенный. Параметр temperature регулирует, насколько: при высокой выбор свободнее, при низкой — ближе к самому вероятному.

Кажется, что для кода нужна нулевая temperature: правильный ответ ведь один. Но исследования показывают обратное — это likelihood trap: если убрать разнообразие совсем, люди оценивают ответы как более слабые. К тому же даже при нулевой temperature вычисления идут параллельно, и порядок операций влияет на результат, так что ответы всё равно различаются. Недетерминированность встроена в модель, убрать её нельзя.

Та же механика даёт галлюцинации — уверенно неверный ответ. Модель выдаёт правдоподобное продолжение, а не проверенный факт. Галлюцинации бывают двух видов.

• Factuality — неверный факт о мире: несуществующая функция, чужая сигнатура API, устаревшая цена. Причина — parametric knowledge: всё, что модель «знает», сжато в её параметры в момент обучения. Сжатие теряет детали, а всё, что появилось после knowledge cutoff, модель не видела вовсе. Дописать знания в параметры нельзя — только переобучить модель.
• Faithfulness — нужная информация есть в контексте, но модель её игнорирует, уходит от неё или искажает. Чаще всего так бывает, когда контекст переполнен и модели трудно найти главное; об этом — Bite про smart zone и dumb zone.

Отсюда простое дерево решений.

Знание из контекста (contextual knowledge) надёжнее памяти модели: ответ лежит перед ней, а не вытаскивается из размытых параметров. Поэтому хороший агент сначала читает код, а не вспоминает его.

Вторая защита — проверка, которую агент может запустить сам. Документация Claude Code прямо говорит: Claude останавливается, когда работа выглядит готовой, и без проверки «выглядит готовой» — единственный сигнал. Тесты, сборка, линтер дают pass или fail, и агент сам видит, что выдуманная функция не существует.

Практика

В Claude Code в проекте Cadence дважды, в двух новых сессиях, дайте один и тот же промпт: «Предложи, как улучшить обработку ошибок в одном из файлов проекта. Ничего не меняй».

Сравните ответы:

• выбрал ли агент тот же файл и тот же план;
• на что он опирался: читал файлы перед ответом или рассуждал «в целом»;
• есть ли в ответе имена функций или модулей, которых вы не нашли в коде, — кандидаты в factuality-галлюцинации.

Обратите внимание: различие ответов — норма. Ненормально, если агент утверждает что-то о коде, не открыв его.

Подводные камни

• «Умная модель неделю вела себя хорошо — можно дать ей больше прав». Неделя — выборка, а не гарантия: у недетерминированной системы всегда есть ненулевой шанс сделать что-то странное и опасное. Права решайте исходя из худшего случая.
• «Отправлю тот же промпт ещё раз — авось получится». Это ставка на случайность вместо устранения причины. Сначала решите, что перед вами — factuality или faithfulness.
• Цены, версии, лимиты «по памяти». Если агент называет их без источника, считайте это гипотезой и попросите его найти документацию.

Проверь себя

Источники

• Anthropic, Best practices for Claude Code
• По мотивам AI Coding Crash Course, AI Hero