TL;DR
Если дать модели инструмент (калькулятор, проверку по базе, поиск), результат инструмента всегда один и тот же. Но решение «звать инструмент или нет» модель принимает сама, по тексту вопроса. Эта работа показывает: от перефразировки зависит, будет ли вызов вообще. Точность при этом почти целиком определяется частотой вызова: позвала — права, не позвала — угадала.
Боль выглядит так. В одной формулировке модель вызывает инструмент и отвечает верно. Стоит поставить данные перед вопросом, и она начинает считать «в уме» прямо в тексте, не делает ни одного вызова, пока не кончится лимит токенов, и отвечает неверно. Когда тот же результат инструмента заранее вставили в промпт, модель отвечала правильно при любой формулировке. Значит, ломается не использование результата, а его получение. Поэтому сравнение двух моделей с инструментами при одной формулировке может поменять победителя при другой.
Что делать: не полагаться на то, что модель сама решит позвать инструмент. Варианты, которые авторы проверили: подставить результат в промпт заранее, подключить инструмент через нативный интерфейс модели (вызов как структурированный ход, не строка текста), поменять описание инструмента, потребовать вызов перед ответом. При сравнении моделей или промптов прогонять несколько формулировок, а не одну.
Схема метода
Это не одна техника, а диагностика и набор рычагов.
ШАГ 1: Одну и ту же задачу записать в 5 формулировках → таблица «вызвал инструмент / нет»
ШАГ 2: Сравнить с вариантом, где результат инструмента вставлен в промпт → если там стабильно, проблема в вызове
ШАГ 3: Вмешаться в вызов: нативный интерфейс / другое описание инструмента / «без вызова не отвечай»
ШАГ 4: Повторить ШАГ 1 → частота вызова должна выровняться
Шаги требуют отдельных запросов: по одному прогону на каждую формулировку.
Пример применения
Сильная зона метода: инструмент сам даёт готовый ответ. Не «калькулятор, результат которого надо ещё собрать в вывод», а «запрос к базе вернул то, что нужно».
Задача: Вы настраиваете ассистента для продавца на Ozon. Клиенты пишут в чат по-разному: - «Сколько у вас осталось красных худи L?» - «Худи красное, размер L. Есть в наличии?» - «Хочу взять 3 штуки. Худи красное L. Хватит?»
Остатки отдаёт инструмент get_stock(sku). Иногда бот отвечает «по памяти» из старого контекста. Нужно проверить, как часто он вызывает инструмент при разных формулировках.
Промпт (тестовый прогон в вашем агенте или в конструкторе, где подключён инструмент):
Прогоню один и тот же вопрос в пяти формулировках. Для каждой записываю: вызвал ли ассистент get_stock до ответа.
Формулировка 1 (стандартная): Сколько осталось красных худи L?
Формулировка 2 (данные до вопроса): Худи, красное, L, артикул HD-RED-L. Есть в наличии?
Формулировка 3 (вопрос до данных): Хватит ли на заказ? Худи красное L, нужно 3 шт.
Формулировка 4 (с контекстом): Я у вас уже брал худи, хочу ещё одно красное L. Остались?
Формулировка 5 (коротко): худи красное L есть?
Результат: Вы получите таблицу из пяти строк «вызвал / не вызвал» и ответ бота в каждой. Если частота вызова скачет между формулировками, значит, точность бота зависит от того, как клиент напишет. Тогда включайте рычаги: описание инструмента, правило «без вызова не отвечай», подстановка остатков в контекст.
Почему это работает
Слабость. В цикле с инструментами модель сначала читает формулировку, и только потом решает, звать ли ей программу. На это решение влияют мелочи: порядок данных и вопроса, длина, вводная фраза. Если модель решила «посчитаю сама», она пишет рассуждение в тексте и может исчерпать лимит токенов, так и не вызвав инструмент. Для некоторых моделей это зависит от формулировки очень сильно.
Сильная сторона. Если результат инструмента уже лежит в контексте, модель читает его и отвечает верно почти всегда. Даже когда в 20–27% отчётов подставили заведомо неверный вариант, разброс по формулировкам не расширялся. Читать данные из контекста модели не мешает ни формулировка, ни рассуждение перед ответом.
Как метод обходит слабость. Он убирает решение «звать или нет» или делает его одинаковым при любой формулировке. Рычаги управления: - Подстановка результата в промпт. Самый стабильный вариант, если данные можно получить заранее. Вызова нет, поэтому нет и нестабильности. - Нативный интерфейс инструментов. В молекульном тесте при нём все три проверенные модели вызывали инструмент в 100% случаев. - Описание инструмента. Одна из двух проверенных альтернативных формулировок описания дала почти постоянную частоту вызова. Другая нет. Описание нужно тестировать, а не выбирать наугад. - Принудительный вызов («без вызова не отвечай, один раз вернём»). Для Qwen3-8B разброс вызовов упал с 0.43 до 0.01. Для Phi-4 и Llama-3.1-8B помогло слабее. - Бюджет токенов. Увеличение лимита в четыре раза разброс не убрало.
Шаблон промпта
Метод авторов — протокол сравнения, поэтому шаблон здесь диагностический: он генерирует набор формулировок для проверки.
У меня задача для агента с инструментом {название_инструмента}.
Он делает: {что_делает_инструмент}.
Типовой вопрос пользователя: {типовой_вопрос}
Напиши 5 формулировок этого вопроса, которые отличаются только записью:
1. Стандартная.
2. Данные идут ПЕРЕД вопросом.
3. Вопрос идёт ПЕРЕД данными.
4. С вводной фразой или лишним контекстом.
5. Очень коротко, как в мессенджере.
Не добавляй подсказок про инструмент. Смысл вопроса и ответ должны остаться теми же.
Выдай нумерованный список.
Что подставлять:
- {название_инструмента} и {что_делает_инструмент}: как называется и что возвращает ваш инструмент.
- {типовой_вопрос}: реальный вопрос из вашей практики.
Каждую формулировку прогоните в своём агенте и запишите: звал ли он инструмент, верен ли ответ. Чем разнообразнее записи, тем честнее картина.
Ограничения
⚠️ Нет коммерческих моделей: Проверяли только открытые модели от 4B до 72B. Как ведут себя Claude, GPT и Gemini в тех же условиях, из статьи не следует.
⚠️ Особые задачи: В молекулах и графах инструмент сразу выдаёт правильный ответ. Там вызов решает всё. В таблицах и математике инструменты (калькулятор, решатель) не помогли, а у большинства моделей даже ухудшили точность: сам цикл вызовов стоил больше, чем давали инструменты.
⚠️ Плохой инструмент вредит: Когда инструмент ошибался (в музыке он был прав в 63% вопросов о тональности), точность падала на 4–10 пунктов. Частый вызов плохого инструмента хуже, чем отсутствие вызова.
⚠️ Стабильность ≠ правильность: Когда 50% отчётов подменили неверными, разброс по формулировкам сузился, но точность упала. Стабильно ошибающаяся модель ничем не лучше нестабильной.
⚠️ Статья про оценку, не про промпты: Тексты описаний инструментов, которые вызывают нужное поведение, вынесены в приложение к статье. Здесь я их не видел, поэтому конкретную формулировку описания придётся подбирать самому.
Как исследовали
Авторы взяли шесть открытых моделей и пять областей: молекулы, графы, ноты, таблицы (FinQA) и математику (MATH-500). Каждый вопрос задавали в пяти формулировках, а данные записывали в нескольких формах (например, молекулу как SMILES, InChI или название). Главная мера — разброс: насколько меняется разница точности двух моделей при смене формулировки.
Затем они постепенно разбирали, что именно вносит нестабильность. Сравнивали чтение ответа по первому токену и по строке «ANSWER:», добавление рассуждения, цикл с инструментами, тот же цикл, но с инструментами, отвечающими «нет информации», и вариант, где результат инструмента просто вставлен в промпт.
Результаты: - В молекулах медианный разброс пары моделей был 0.17 с циклом и 0.02 со вставленным результатом. - У 37 из 60 молекульных пар разброс вырос по сравнению с рассуждением без инструментов. - При десяти формулировках вместо пяти разброс с инструментами вырос в 2,88 раза. Без инструментов только в 1,12. - Порядок моделей разворачивался у 4 из 15 пар в музыке и молекулах. Без инструментов не разворачивался ни у одной пары. - Нативный интерфейс свёл разброс вызовов к нулю у трёх проверенных моделей: все вызывали инструмент всегда. - Принудительный вызов помог Qwen3-8B, но не всем.
Удивило, что детерминированный инструмент не гарантирует стабильного сравнения: нестабильность создаёт не он, а решение его позвать. Побочный вывод: при выборе лучшего ответа из нескольких вариантов (A–D) надёжнее читать букву после строки «ANSWER:», а не по первому токену. На графах так разброс 36 из 45 пар сузился, медиана упала с 0.25 до 0.05.
Адаптации и экстраполяции
Это мои переносы идей статьи. Авторы их в таком виде не проверяли.
💡 Адаптация для инструкции агенту: Принудительный вызов в петле перенесён в системный промпт. В статье он реализован в обвязке: цикл один раз отказывается принять ответ без вызова. Текстом это можно приблизить правилом. Эффект на вашей модели нужно проверить, как в шаблоне выше.
Перед ответом о {предметная_область: остатках, ценах, статусах заказов} ты ВСЕГДА вызываешь инструмент {название_инструмента}. Если ты не вызвал инструмент, ответь: «Сейчас проверю» и вызови его. Отвечай только после получения результата. Не используй данные из памяти.
🔧 Техника: данные из инструмента до вопроса → убрать нестабильность. Если результат можно получить заранее (остатки, курс, статус), не заставляйте модель его запрашивать. Сначала соберите данные отдельным шагом (в автоматизации: узел «запрос в базу» → узел «ответ клиенту») и вставьте в промпт. В статье это условие «supplied report»: самый устойчивый вариант.
🔧 Техника: строка ответа вместо первого слова. Если вы оцениваете модели или промпты на вопросах с вариантами A–D, добавьте в конец промпта
ANSWER:и читайте букву отсюда. Читать «первое, что напишет» ненадёжно.
💡 Адаптация для сравнения промптов: Тот же принцип применим к выбору промпта или модели для вашего агента. Не выбирайте победителя по одной формулировке. Прогоните 5–10 реальных перефразировок и посмотрите, сохраняется ли порядок.
Ресурсы
- Prompt Sensitivity in Tool-Augmented Model Comparisons
- Авторы: Mateusz Modrzejewski, Tomasz Radzikowski, Institute of Computer Science, Warsaw University of Technology
- Связанные работы: ReAct (Yao et al., 2022); Sclar et al., 2023 и Mizrahi et al., 2023 о чувствительности к формулировке; Wang et al., 2024 о чтении ответа по первому токену; Fatemi et al., 2023 (графы); FinQA (Chen et al., 2021); MATH-500 (Hendrycks et al., 2021; Lightman et al., 2023).