WildToolBench: Защо нито един LLM не надвишава 15% точност на сесиите при използване на инструменти в реалния свят

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

Докладът

Peijie Yu, Wei Liu, Yifan Yang и техните колеги от 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): предишните отговори влияят на интерпретацията на последващите инструкции от модела по начини, които са трудни за коригиране в средата на сесията.
• Процентът на оптималния път (Optimal Path Rate) остава под 43%: Даже когато моделите изпълняват задачите правилно, те изразходват излишни API повиквания. Claude-4-Sonnet постига най-добрия процент на оптимален път от 42,74%, което означава, че по-голямата част от правилните завършвания отнемат повече стъпки от необходимото — пряк разход на латентност и токени за всяка производствена система.
• Специализираните модели за използване на инструменти се представят по-зле от общите авангардни модели: 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 е най-надеждният механизъм за това.