WildToolBench: Почему ни одна LLM не превышает 15% точности сессии в реальных сценариях использования инструментов

Бенчмарки для оценки использования инструментов, за которыми я слежу — BFCL, ToolBench, τ-bench — объединяет один общий недостаток: задачи в них строятся на основе воображения авторов о том, что делают пользователи. WildToolBench, принятый на ICLR 2026, обращается к логам реальных пользователей и исследует, что они делают на самом деле. Ответ отрезвляет: из 57 протестированных LLM ни одна не превысила 15% точности сессии.

Исследование

Пейцзе Юй, Вэй Лю, Ифань Ян и их коллеги из Alibaba представляют WildToolBench (arXiv:2604.06185) — бенчмарк, состоящий из 256 сценариев многоходовых диалогов с 1024 задачами, взятыми из подлинных паттернов поведения пользователей и основанными на ~1600 публичных API. Основной аргумент авторов заключается в том, что существующие бенчмарки близки к насыщению не из-за совершенства моделей, а из-за искусственности задач. Реальные пользователи объединяют запросы, опускают контекст, которым они делились два шага назад, и переключаются между вопросом к инструменту, светской беседой и просьбой о пояснении — иногда в рамках одного сообщения. WildToolBench формализует эти режимы отказа в три структурированные категории проблем и измеряет как точность на уровне задач, так и гораздо более строгую точность на уровне сессии, которая требует успешного выполнения всех четырех задач в диалоге.

Ключевые идеи

• Точность сессии падает до однозначных чисел для большинства моделей: Gemini-2.0-Flash-Thinking лидирует с точностью сессии 14,45%, Claude-4-Sonnet — 12,50%, GPT-4o — 11,72%. Успешное выполнение всех задач в четырехходовой сессии настолько сложно, что даже 60% точности на уровне отдельных задач превращаются в менее чем 15% точности сессии — своего рода «налог» совокупной вероятности на каждое взаимодействие.
• Композиционная оркестрация — самый сложный барьер: Смешанные последовательно-параллельные топологии инструментов ограничивают топовые модели точностью в 25% на задачу, по сравнению с 54–62% для чисто параллельных или последовательных цепочек. Когда задача требует параллельного разветвления с последующим последовательным слиянием, проблема координации превышает возможности любой современной модели.
• Скрытые намерения — более значительный разрыв, чем измерялось ранее: WildToolBench гарантирует, что 100% задач включают неявную или межходовую информацию; в BFCL v3 таких задач лишь 15,7%. Задачи с долгосрочными зависимостями — где недостающая информация находится более чем в двух ходах назад — являются самым сложным подтипом, где ни одна модель не преодолевает порог в 50% даже на уровне отдельных задач.
• Переходы между инструкциями накапливают ошибки линейно: Каждое дополнительное переключение политики (задача для инструмента → чат → уточнение → задача для инструмента) снижает точность примерно на 5–15 процентных пунктов. При трех переходах наиболее пострадавшие модели теряют 30 пунктов. Авторы называют это «самообуславливанием» (self-conditioning): предыдущие ответы смещают интерпретацию последующих инструкций моделью таким образом, который трудно исправить в середине сессии.
• Доля оптимальных путей остается ниже 43%: Даже когда модели выполняют задачи правильно, они тратят избыточное количество вызовов API. Claude-4-Sonnet достигает лучшего показателя доли оптимальных путей (Optimal Path Rate) — 42,74%, что означает, что большинство успешных выполнений требуют больше шагов, чем необходимо. Это прямые затраты на задержку (latency) и токены для любой промышленной системы.
• Специализированные модели для работы с инструментами уступают общим флагманским моделям: xLAM-2-70B и ToolACE2-8B демонстрируют частоту ошибок из-за неверных имен функций выше 30%, что хуже показателей GPT-4o или Claude-4-Sonnet. Тонкая настройка на узких корпусах использования инструментов, похоже, создает хрупкость, а не устойчивость при столкновении с реальным пользовательским поведением.

Что подтверждается, а что нет

Дизайн бенчмарка силен там, где это важнее всего. Разграничение между точностью задач и точностью сессии абсолютно верно: именно накопление ошибок губит реальные внедрения, а большинство предыдущих работ сообщают цифры на уровне задач, которые маскируют эту проблему. Таксономия трех проблем (композиционная оркестрация, скрытые намерения, переходы между инструкциями) хорошо обоснована и подтверждена эмпирически — кривые деградации производительности по типам проблем выглядят реально и впечатляюще.

Слабое место — масштаб. 1024 задачи из 256 сценариев — это достойный исследовательский артефакт, но маловато для лидерборда, призванного отслеживать 57 моделей во времени. Авторы признают это и упоминают автоматизированный конвейер масштабирования в будущих работах. Другая проблема заключается в том, что формулировка «основано на реальных логах» подразумевает много допущений: финальные задачи частично синтетические, сконструированы мультиагентной системой на основе исходных паттернов, а затем проверены людьми. Утверждение обосновано, но данные не являются «дикими» в буквальном смысле — они вдохновлены ими. Это важно для того, насколько буквально стоит воспринимать потолок в 15%; часть разрыва может сократиться, если конвейер генерации вносит искусственную сложность, которую реальные пользователи на самом деле не проявляют.

Я также скептически отношусь к анализу переходов между инструкциями как к архитектурному утверждению. Статья приписывает это фундаментальному ограничению, но несоответствие распределения обучающих данных между целями RLHF и мультимодальными пользовательскими сессиями кажется более простым объяснением. Это устранимая проблема, а не структурная.

Почему это важно для финансового ИИ

Три режима отказа почти идеально накладываются на то, как реальные пользователи взаимодействуют с агентом обратной записи Beancount. Пользователь спрашивает: «сколько я потратил на продукты в прошлом месяце, и заодно добавь сегодняшний чек из Whole Foods» — это композиционная задача, объединенная в один ход. Затем следует: «на самом деле там 47,23 доллара, а не 42, я проверил» — это корректировка параметров, требующая от агента отслеживания состояния сессии. Затем они спрашивают: «эта категория верна?» — это запрос на уточнение, и агент не должен повторно выполнять операцию записи, которую он только что завершил. Ограничение в 25% на смешанную оркестрацию и падение на 30 пунктов из-за переходов между инструкциями — это именно те режимы отказа, которые проявятся у бухгалтерского агента, обрабатывающего реальные пользовательские сессии.

Вывод о том, что специализированные модели уступают флагманским, особенно актуален. Если мы рассматриваем возможность тонкой настройки небольшой открытой модели на примерах вызова инструментов Beancount — очевидный ход для снижения затрат — WildToolBench служит прямым предупреждением: специализация может принести в жертву устойчивость к распределению реального пользовательского поведения. Показатель доли оптимальных путей также важен: агент, который использует в два раза больше вызовов API для выполнения задачи, не просто неэффективен; для операций записи в учетную книгу избыточные промежуточные вызовы могут оставить ее в несогласованном состоянии.

Что почитать дальше

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — основополагающая структура обучения, которой WildToolBench открыто противопоставляет себя; понимание её синтетического дизайна оценки проясняет, что именно добавляет исполнение в реальном времени.
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045) — наиболее близкая предыдущая работа по реалистичному многоходовому использованию инструментов; сравнение доменов розничной торговли и авиаперевозок τ-bench с охватом публичных API в WildToolBench показывает широту обобщения проблемы.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — если проблема переходов между инструкциями решаема путем автоматического поиска лучших рабочих процессов агентов, а не масштабирования обучающих данных, то AFlow является наиболее перспективным механизмом для этого.