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%, що означає, що більшість правильних завершень вимагають більше кроків, ніж необхідно — прямі витрати на затримку та токени для будь-якої виробничої системи.
• Спеціалізовані моделі для використання інструментів поступаються загальним фронтирним моделям: xLAM-2-70B та ToolACE2-8B демонструють частоту помилок із неправильною назвою функції понад 30%, що гірше, ніж у GPT-4o або Claude-4-Sonnet. Тонке налаштування на вузьких корпусах використання інструментів, схоже, створює крихкість, а не стійкість до зсуву розподілу в бік дикої поведінки користувачів.

Що підтверджується, а що — ні

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

Слабким місцем є масштаб. 1024 завдання з 256 сценаріїв — це гідний дослідницький артефакт, але замало для лідерборду, призначеного для відстеження 57 моделей протягом тривалого часу. Автори прямо визнають це і згадують про автоматизований конвеєр масштабування в майбутніх роботах. Інша проблема полягає в тому, що фраза «засновано на логах реальних користувачів» приховує велику роботу: кінцеві завдання є частково синтетичними, побудованими багатоагентною системою з базових шаблонів, а потім перевіреними людьми-анотаторами. Твердження є обґрунтованим, але дані не є дослівними «дикими» даними — вони натхненні реальністю. Це має значення для того, наскільки буквально варто сприймати стелю у 15%; частина розриву може закритися, якщо конвеєр генерації вносить штучну складність, якої реальні користувачі насправді не проявляють.

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

Чому це важливо для AI у фінансах

Три режими відмов майже ідеально відображають те, як реальні користувачі взаємодіють з агентом зворотного запису 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 є найбільш надійним механізмом для цього.