TL;DR
Если длинный вывод инструмента лежит в файле, а не в контексте, часть моделей перестаёт смотреть в официальный отчёт. Вместо него они берут числа из собственных файлов, которые сами создали по ходу работы. Лечится это тремя предложениями в описании инструмента и в системном промпте: вот эталонный источник, он уже в нужной точности, бери значение оттуда, а не из своих файлов.
Агент посчитал правильно, но ответил неверно. В отчёте инструмента число напечатано так, как нужно: 2.751. В собственном файле агента оно длиннее: 2.75065. Модель обрезает хвост вместо округления, получает 2.750 и выбирает соседний неверный вариант. Это видно по логам: правильное значение агент получает так же часто, как раньше. Теряется шаг «из чего я отвечаю». У GPT-5.1 и GPT-5.2 в таком режиме до 60% запусков вообще не открывают отчёт. Точность падает на 8–11 пунктов. Claude почти не страдает.
Метод простой: назвать эталонный источник и запретить отвечать из черновых файлов. Просьба «округляй правильно» почти не помогает: модели всё равно обрезают. Работает указание, откуда брать значение. Это вернуло точность на 6–8 пунктов у трёх GPT-моделей. Альтернатива — класть отчёт прямо в контекст, если он помещается.
Схема метода
ШАГ 1: Определи, какой вывод инструмента — эталон (отчёт, итоговая таблица, лог)
ШАГ 2: Добавь в описание инструмента 3 предложения:
• значения в [файл] — авторитетные и в нужной точности
• бери значение из соответствующего раздела [файл]
• не отвечай из своих промежуточных файлов: там значения не округлены
ШАГ 3: Продублируй эти же предложения в системном промпте / CLAUDE.md
ШАГ 4: Если отчёт короткий — положи его прямо в контекст вместо файла
Всё делается текстом, в одном промпте или файле инструкций.
Пример применения
Задача: Вы настраиваете агента в Cursor. Он считает налог ИП на УСН «Доходы минус расходы» по выгрузке из Тинькофф Бизнеса. Скрипт calc_usn.py пишет подробный report.txt, где каждая сумма округлена до рубля по правилам. Агент любит ещё и сам сохранять debug_dump.csv с копейками и десятыми долями копеек. Клиенту нужен ответ, например «минимальный налог к уплате — 123 457 ₽». Но агент берёт 123 456,78 из дампа, обрезает до 123 456 и называет цифру на рубль меньше.
Промпт (в описание инструмента и в системные инструкции):
Инструмент calc_usn.py пишет итоговый файл report.txt.
Значения в report.txt — авторитетные, они уже округлены до рубля
по правилам расчёта налога.
Для ответа бери сумму из нужного раздела report.txt.
Не отвечай из debug_dump.csv и других своих промежуточных файлов:
там значения не округлены, и при округлении можно получить
соседнюю, неверную сумму.
В ответе укажи раздел report.txt, откуда взято число.
Результат: Агент открывает report.txt и находит нужный раздел. Сумма в ответе совпадает с официальной округлённой. Дамп с копейками остаётся рабочим материалом и в ответ не попадает. Последняя строка про указание раздела — добавка к методу, в статье её нет (см. «Адаптации»).
Почему это работает
Слабость. Когда отчёт лежит в контексте целиком, он единственный источник перед глазами. Когда он в файле, он конкурирует с другими источниками, в том числе с файлами самого агента. Файлы агента короче и точнее по числу знаков, поэтому модель их охотно читает. Но числа в них не подогнаны под формат ответа. Модель их обрезает вместо округления, и ответ уезжает на соседний вариант.
Сильная сторона. Модель хорошо выполняет ясное указание, откуда брать данные. Когда ей говорят «бери из отчёта», она идёт туда: пропуск отчёта падает с ~50–60% до 0–2%, а доля верных ответов при увиденном значении поднимается до 99%.
Как метод это использует. Выбор источника ломался на стороне модели. Инструкция делает этот выбор за неё. Просьба «округляй вниз/вверх правильно» ничего не меняет, потому что поведение чтения остаётся прежним: модель всё равно идёт в свои файлы и всё равно обрезает.
Рычаги: - Название файла и раздела → чем конкретнее, тем надёжнее. «Эталонный вывод» без имени файла не работает: инструкцию нужно привязать к имени. - Объяснение причины («там значения не округлены») → помогает модели понять, зачем запрет. - Место размещения → авторы клали текст и в описание инструмента, и в каждый результат вызова. Дублируйте в системный промпт и файл инструкций. - Размер вывода → если отчёт помещается в контекст, показывайте его целиком и без инструкции. Это сработало так же и сэкономило токены.
Шаблон промпта
Инструмент {инструмент} возвращает {что_возвращает}.
Значения в {эталонный_файл} — авторитетные: они напечатаны
в нужной точности ({формат_точности}).
Для ответа бери значение из соответствующего раздела {эталонный_файл}.
Не отвечай из {черновые_файлы}: там значения не округлены
или не приведены к нужному формату, и можно получить соседний,
неверный вариант.
Что подставлять:
- {инструмент} — скрипт, тест-раннер, симулятор, API-обёртка.
- {эталонный_файл} — отчёт, из которого берутся финальные цифры.
- {формат_точности} — «до рубля», «2 знака», «в процентах».
- {черновые_файлы} — выгрузки, дампы, логи, которые агент создаёт сам.
Ограничения
⚠️ Зависит от модели: у Claude (Opus и Sonnet 4.6) потерь при работе с файлом практически нет, у GPT-5.4 общий итог тоже около нуля. Эффект сильнее всего у GPT-5.1 и GPT-5.2.
⚠️ Просьба «округляй правильно» не работает: модели всё равно обрезают, хотя им прямо сказали не обрезать. Помогает только указание конкретного источника.
⚠️ Нужно знать эталон: инструкция требует назвать, какой вывод считается каноническим. Если эталона нет или он неочевиден, метод не сработает.
⚠️ Проверено на одном инструменте: это геохимический симулятор и вопросы с четырьмя вариантами, где варианты различаются последней цифрой. Перенос на другие задачи логичен, но в статье не проверен.
⚠️ Не лечит всё: у GPT-5.1 остаётся недобор до уровня «отчёт в контексте». Он лежит уже не в округлении, а в самом расчёте и в других этапах.
⚠️ Контрольный прогон один: сравнение инструкции с контролем опирается на единичный запуск каждой модели. Основной вывод подтверждён и другими сравнениями, но цифры приблизительные.
Как исследовали
Исследователи взяли PHREEQC — реальный геохимический симулятор Геологической службы США. Его отчёты доходят до 847 тысяч символов, а результат полностью детерминирован, поэтому каждое напечатанное число можно проверить. Для теста взяли 158 вопросов с четырьмя вариантами ответа, ключи которых перепроверили запуском: из исходных 200 вопросов 42 оказались дефектными. Варианты ответов отличаются последней цифрой, поэтому угадать нельзя, число нужно считать.
Сравнивали два способа выдачи отчёта: целиком в контекст (до 100 тысяч символов) или оглавление с чтением по строкам. Дополнительно проверили поиск по ключевым словам. Тестировали модели Claude Opus 4.6, Sonnet 4.6, GPT-5.1, 5.2, 5.4 и Gemini 3 Flash. Gemini исключили: почти половина ответов у неё не распарсилась.
Главный ход исследования — перезапуск всех 11 007 вызовов симулятора из логов. Для каждой траектории стало видно три вещи: посчитал ли агент нужное значение, дошло ли оно до него и ответил ли он по нему верно. Оказалось, что GPT-5.1 и GPT-5.2 считают так же часто, как раньше. Теряется шаг чтения: агент часто не открывает отчёт и берёт значение из своего файла с лишними знаками. Из 35 «ловушек» (значение округляется в правильный вариант, но обрезается в соседний) GPT-5.2 выбрал соседний вариант в 26 случаях, а Sonnet — в одном.
Затем сделали интервенцию: три предложения с указанием источника. Пропуск отчёта упал почти до нуля, верность ответов при увиденном значении выросла до ~99%. Точность поднялась на 6–8 пунктов у трёх GPT-моделей. У GPT-5.4 есть любопытная деталь: итоговая точность не менялась, потому что плюс в расчётах скрывал минус в чтении. Если смотреть только на итог, проблему не увидишь.
Адаптации и экстраполяции
💡 Адаптация для файла инструкций агента (CLAUDE.md / AGENTS.md): Статья проверяла инструкцию в описании инструмента и в результате вызова. Тот же принцип можно записать в постоянные инструкции проекта.
## Источник истины для чисел Итоговые цифры бери только из reports/summary.txt. Файлы в tmp/ и debug/ — рабочие черновики, значения там не округлены. Не используй их для ответа пользователю.
🔧 Техника: добавить ссылку на источник → проверка своими глазами. Попросите агента в конце ответа указать, из какого файла и раздела взято каждое число. В статье это не проверялось, но так можно быстро увидеть подмену источника без разбора логов.
К каждому числу в ответе добавь: [файл, раздел].
💡 Экстраполяция (не проверено в статье): тот же принцип пригодится, где агент сам создаёт промежуточные версии данных: выгрузки из CRM, отчёты по рекламе, расчёты юнит-экономики. Назовите официальную версию и объясните, чем черновики хуже. Проверяйте на своей модели: у Claude эффекта может не быть.
Ресурсы
- Работа: Same Simulation, Different Evidence: Where Retrieved Tool Output Costs LLM Agents Accuracy
- Авторы: Ke Zhang, Maziar Raissi (University of California, Riverside); Sahchit Chundur, Jerry Peprah Owusu, Mohammad Javad Abdolhosseini Qomi (University of California, Irvine)
- Инструмент: PHREEQC (USGS), Parkhurst & Appelo, 2013
- Связанные работы: Sen et al. (2026) о доставке результатов поиска файлами; Xie et al. (2026) о том, что модели не всегда используют контекст; Zhang et al. (2026b) о наборе вопросов.
- Дословный текст трёх предложений авторы приводят в Приложении B, в полученном фрагменте его нет.