I benchmark sull'uso di strumenti che ho seguito — BFCL, ToolBench, τ-bench — condividono tutti un difetto di progettazione comune: costruiscono attività basandosi sull'immaginazione degli autori del benchmark di ciò che gli utenti fanno. WildToolBench, accettato a ICLR 2026, torna ai log reali degli utenti e chiede cosa gli utenti effettivamente fanno. La risposta è umiliante: 57 LLM valutati, nessuno supera il 15% di accuratezza di sessione.
L'articolo
Peijie Yu, Wei Liu, Yifan Yang e colleghi di Alibaba presentano WildToolBench (arXiv:2604.06185), un benchmark di 256 scenari di dialogo multi-turno con 1.024 attività tratte da modelli autentici di comportamento degli utenti e basate su circa 1.600 API pubbliche. L'argomentazione centrale è che i benchmark esistenti si stanno saturando non perché i modelli siano bravi, ma perché le attività sono artificiali. Gli utenti reali raggruppano richieste insieme, omettono il contesto che hanno fornito due turni prima e passano dal fare una domanda su uno strumento, al fare conversazione, al richiedere un chiarimento — a volte all'interno di un singolo messaggio. WildToolBench operazionalizza queste modalità di fallimento in tre categorie strutturate di sfide e misura sia l'accuratezza a livello di attività sia l'accuratezza a livello di sessione, molto più restrittiva, che richiede il successo in tutte e quattro le attività di un dialogo.
Idee chiave
- L'accuratezza di sessione crolla a cifre singole per la maggior parte dei modelli: Gemini-2.0-Flash-Thinking guida con il 14,45% di accuratezza di sessione, Claude-4-Sonnet al 12,50%, GPT-4o all'11,72%. Superare tutte le attività in una sessione di quattro turni è così difficile che persino un'accuratezza delle attività del 60% si traduce in meno del 15% di accuratezza di sessione — una tassa di probabilità composta su ogni interazione.
- L'orchestrazione compositiva è il gradino più ripido: Topologie di strumenti miste sequenziali e parallele limitano i modelli migliori al 25% di accuratezza delle attività, contro il 54-62% per catene puramente parallele o sequenziali. Quando un'attività richiede una diramazione parallela seguita da una fusione sequenziale, il problema di coordinamento supera ciò che qualsiasi modello attuale gestisce in modo affidabile.
- L'intento nascosto è un divario più grande di quanto chiunque abbia mai misurato prima: WildToolBench garantisce che il 100% delle attività coinvolga informazioni implicite o tra turni; BFCL v3 ne gestisce solo il 15,7%. Le attività a dipendenza a lungo raggio — dove l'informazione mancante è a più di due turni di distanza — sono il sottotipo più difficile, con nessun modello che supera il 50% nemmeno a livello di attività.
- Le transizioni di istruzione aggravano gli errori a un tasso lineare: Ogni ulteriore cambio di politica (attività strumentale → chat → chiarimento → attività strumentale) riduce l'accuratezza di circa 5-15 punti percentuali. A tre transizioni, i modelli più colpiti perdono 30 punti. Gli autori chiamano questo "auto-condizionamento": le risposte precedenti influenzano l'interpretazione del modello delle istruzioni successive in modi difficili da correggere a metà sessione.
- Il Tasso di Percorso Ottimale rimane al di sotto del 43%: Anche quando i modelli completano correttamente le attività, consumano chiamate API in eccesso. Claude-4-Sonnet raggiunge il miglior Tasso di Percorso Ottimale al 42,74%, il che significa che la maggior parte dei completamenti corretti richiede più passaggi del necessario — un costo diretto in latenza e token per qualsiasi sistema di produzione.
- I modelli specializzati nell'uso di strumenti sono inferiori ai modelli generali all'avanguardia: xLAM-2-70B e ToolACE2-8B registrano entrambi tassi di errore di nome funzione errato superiori al 30%, peggiori di GPT-4o o Claude-4-Sonnet. Il fine-tuning su corpora ristretti di uso di strumenti sembra creare fragilità piuttosto che robustezza sotto uno spostamento distributivo verso il comportamento utente reale.
Cosa regge — e cosa no
La progettazione del benchmark è solida dove conta di più. La distinzione tra accuratezza dell'attività e accuratezza della sessione è assolutamente corretta: le modalità di fallimento combinate sono ciò che uccide le implementazioni reali, e la maggior parte dei lavori precedenti riporta numeri a livello di attività che mascherano questo. La tassonomia a tre sfide (orchestrazione compositiva, intento nascosto, transizioni di istruzione) è ben motivata e comprovata empiricamente — le curve di degradazione delle prestazioni attraverso i tipi di sfida sono reali e sorprendenti.
Il punto debole è la scala. 1.024 attività da 256 scenari costituiscono un artefatto di ricerca credibile, ma sono pochi per una classifica destinata a monitorare 57 modelli nel tempo. Gli autori lo riconoscono direttamente e menzionano una pipeline di scalabilità automatica in lavori futuri. L'altro problema è che "basato su log utente reali" fa molto lavoro: le attività finali sono parzialmente sintetiche, costruite da un sistema multi-agente a partire da schemi seme, poi verificate da annotatori umani. L'affermazione è fondata, ma i dati non sono verbatim reali — sono ispirati al reale. Questo è importante per quanto letteralmente si interpreta il tetto del 15%; una parte del divario potrebbe chiudersi se la pipeline di generazione introduce una difficoltà artificiale che gli utenti reali in realtà non mostrano.
Sono anche scettico sull'analisi della transizione di istruzione come affermazione architetturale. L'articolo la attribuisce a una limitazione fondamentale, ma la discrepanza tra la distribuzione di addestramento degli obiettivi di fine-tuning RLHF e le sessioni utente multi-modali è la spiegazione più parsimoniosa. Questo è risolvibile, non strutturale.
Perché questo è importante per l'AI finanziaria
Le tre modalità di fallimento si sovrappongono quasi perfettamente a come gli utenti reali interagiscono con un agente di write-back per Beancount. Un utente chiede "quanto ho speso per la spesa il mese scorso, e già che ci sei aggiungi la ricevuta di Whole Foods di oggi" — questa è un'attività compositiva raggruppata in un turno. Poi segue con "in realtà fai €47,23 non €42, ho controllato" — questa è una correzione di parametro che richiede all'agente di tenere traccia dello stato della sessione. Poi chiede "quella categoria è giusta?" — questa è una richiesta di chiarimento, e l'agente non deve rieseguire l'operazione di scrittura che ha appena terminato. Il limite del 25% sull'orchestrazione mista sequenziale-parallela e il calo di 30 punti dalle transizioni di istruzione sono esattamente le modalità di fallimento che si manifesterebbero in un agente contabile che gestisce sessioni utente reali.
La scoperta che i modelli specializzati nell'uso di strumenti sono inferiori ai modelli generali all'avanguardia è particolarmente rilevante. Se stessimo considerando il fine-tuning di un modello open source più piccolo su esempi di chiamate a strumenti specifici per Beancount — la classica strategia di riduzione dei costi — WildToolBench è un avvertimento diretto che la specializzazione potrebbe sacrificare la robustezza alla distribuzione del comportamento utente reale. Anche la scoperta del Tasso di Percorso Ottimale è importante: un agente che usa il doppio delle chiamate API per completare un'attività non è solo inefficiente; per le operazioni di write-back, chiamate intermedie ridondanti possono lasciare il libro contabile in stati intermedi inconsistenti.
Cosa leggere dopo
- ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — il framework di addestramento fondante contro cui WildToolBench si posiziona esplicitamente; comprendere la sua progettazione di valutazione sintetica chiarisce esattamente cosa aggiunge l'esecuzione dal vivo.
- τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045) — il lavoro precedente più vicino sull'uso realistico di strumenti multi-turno; confrontare i domini retail/aerei di τ-bench con la copertura delle API pubbliche di WildToolBench mostra quanto il problema sia generalizzabile.
- AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — se il problema della transizione di istruzione è risolvibile scoprendo automaticamente flussi di lavoro dell'agente migliori piuttosto che scalando i dati di addestramento, AFlow è il meccanismo più credibile per farlo.