Агенты GPT теряют до 11,3 пункта точности, когда отчёт симулятора лежит в файле

Если агент посчитал правильно, это не гарантирует правильного ответа. Новая работа, попавшая в Hugging Face Daily Papers, показывает, как это происходит в популярной схеме управления контекстом: длинный вывод инструмента сохраняется в файл, а агент ищет в нём нужное по индексу разделов. На геохимическом симуляторе PHREEQC от USGS модели GPT-5.1 и GPT-5.2 при таком режиме теряют 11,3 и 7,9 пункта точности. Claude Opus 4.6 и Claude Sonnet 4.6 заметной потери не показывают.

Полигон, где каждое число можно отследить

PHREEQC выбрали не случайно. Это широко используемый симулятор, а его отчёты доходят до 846,8 тыс. символов. Он детерминирован, поэтому любое напечатанное значение можно проследить до источника. Агенты решали 158 вопросов с выбором ответа, и правильность каждого подтверждалась выполнением. Такая постановка позволяет разделить две причины ошибки: модель неправильно запустила симуляцию или неправильно прочитала результат.

Авторы перезапустили все 11 007 залогированных вызовов симулятора и проверили, как часто агент вообще получает нужное значение. Для обеих GPT-моделей эта доля почти не изменилась. Симулировать они стали не хуже. Изменилось то, из чего они берут ответ.

Подмена доказательств

Этот сбой в работе назван evidence substitution. Когда отчёт нужно искать по индексу, GPT-модели часто пропускают его. Они отвечают по собственным выходным файлам, где числа записаны с большей точностью, и при округлении промахиваются на соседний вариант ответа. Расчёт верный, а выбран не тот вариант.

Эффект не объясняется тем, что модель хуже считает. При зафиксированной симуляции поиск по-прежнему стоит GPT-5.2 9,4 пункта. У GPT-5.4 картина интереснее: итоговое изменение неотличимо от нуля. Но это нулевое сальдо складывается из двух противоположных эффектов. Более частые правильные симуляции добавляют точности, а потеря от использования доказательств отнимает около десяти пунктов. Итоговая метрика скрывает проблему.

Ключевые цифры исследования:

• 158 задач с проверкой выполнением;
• до 846,8 тыс. символов в одном отчёте;
• 11 007 повторно прогнанных вызовов симулятора;
• −11,3 пункта у GPT-5.1 и −7,9 у GPT-5.2 при чтении через индекс;
• −9,4 пункта у GPT-5.2 при фиксированной симуляции;
• около −10 пунктов скрытой потери у GPT-5.4;
• от +6,3 до +7,9 пункта у трёх GPT-моделей, если назвать авторитетный выходной файл.

Что помогает, а что нет

Лучше всего работает прямое указание, какой вывод считать главным. Название авторитетного файла в промпте поднимает точность на 6,3–7,9 пункта по сравнению с обычным поиском для трёх GPT-моделей. Для GPT-5.1 и GPT-5.2 так же хорошо работает вставка выводов в контекст, если они помещаются. Просьба «округлять корректно» не дала эффекта: модель знает правила округления, но не понимает, какому источнику доверять.

Практический вывод для тех, кто строит агентные оболочки, один: оценивать решение о хранении вывода вне контекста по итоговой точности недостаточно. Нужно разделять качество вызова инструмента и качество использования его результата, как это сделали авторы с помощью логов. Иначе вроде бы нейтральный результат у GPT-5.4 легко принять за отсутствие проблемы.

Если отчёт помещается в контекст, проще вставить его целиком. Если нет, стоит явно назвать в инструкции главный файл и запретить подменять его промежуточными или более точными копиями. Наконец, при выборе модели для агентов с длинным выводом инструментов полезно проверять именно такой сценарий: в этом тесте Claude Opus 4.6 и Sonnet 4.6 перенесли поиск по файлам без заметной потери, а GPT-модели нет.