Dopo settimane passate a tracciare il lignaggio del table-reasoning e del text-to-SQL, ho voluto allargare lo sguardo e chiedermi una cosa diversa: quanto sono bravi, in realtà, gli agenti attuali una volta inseriti in un ciclo operativo dal vivo con un utente reale? τ-bench fornisce la risposta più onesta che abbia mai visto, e i numeri sono sconcertanti.
L'articolo
Yao, Shinn, Razavi e Narasimhan — tutti a Princeton e Sierra Research — hanno rilasciato τ-bench (arXiv:2406.12045, giugno 2024) per colmare una lacuna che è ovvia in retrospettiva: la maggior parte dei benchmark per agenti consegna al modello un compito e ne valuta la risposta finale in modo isolato. Le implementazioni reali non funzionano così. Un agente di servizio clienti viene interrotto, gli vengono poste domande di follow-up, gli vengono fornite informazioni contraddittorie e ci si aspetta che faccia rispettare le politiche aziendali durante una conversazione aperta prima di apportare qualsiasi modifica al database.
τ-bench racchiude due domini reali di servizio clienti — vendita al dettaglio e compagnia aerea — in un simulatore in cui un modello linguistico interpreta l'utente e un altro interpreta l'agente. L'agente ha accesso a API specifiche del dominio (annullare un ordine, cambiare un posto, applicare un coupon) e a un documento politico scritto che specifica quali azioni sono consentite in quali condizioni. La valutazione non assegna punteggi ai passaggi intermedi: confronta lo stato finale del database con uno stato obiettivo annotato. Gli autori introducono anche pass^k, una metrica di affidabilità che chiede in quale frazione di prove l'agente riesce coerentemente in k tentativi indipendenti dello stesso compito.
Idee chiave
- pass^k come metrica onesta: un singolo punteggio pass@1 è troppo rumoroso. pass^k espone la probabilità che un agente abbia successo in ognuno di k tentativi ripetuti dello stesso compito — un indicatore di quanto ci si possa fidare in produzione.
- Il precipizio di coerenza: GPT-4o nel settore retail ottiene 0,604 a pass@1 ma scende a 0,383 a pass@4. Ciò significa che in circa il 60% dei compiti fallisce almeno una volta su quattro tentativi — difficilmente un agente sicuro per la produzione.
- La compagnia aerea è più difficile del retail: il pass@1 di GPT-4o scende da 0,604 (retail) a 0,420 (compagnia aerea). Claude 3.5 Sonnet (versione ottobre 2024) fa meglio — 0,692 retail / 0,460 compagnia aerea a pass@1 — ma il suo pass@4 raggiunge comunque solo 0,462 e 0,225 rispettivamente.
- Il function calling batte ReAct: la variante dell'agente GPT-4o basata su chiamate di funzione (pass@1 = 0,420 nella compagnia aerea) supera sia Act (0,365) che ReAct (0,325) sullo stesso modello di base, suggerendo che le API di strumenti strutturati riducono i fallimenti legati al formato.
- La simulazione dell'utente è una variabile: gli autori usano un modello linguistico per simulare l'utente, il che introduce una propria varianza. Un simulatore utente più debole può sgonfiare o gonfiare i punteggi dell'agente a seconda di quanto fedelmente rappresenta un comportamento utente conflittuale.
- La valutazione basata sullo stato del database evita i giochi di credito parziale: confrontare lo stato finale piuttosto che i passaggi del dialogo significa che un agente che esegue un'azione corretta e poi la annulla involontariamente non riceve credito — la scelta giusta per un sistema di scrittura.
Ciò che regge — e ciò che non regge
L'inquadramento pass^k è genuinamente utile e prevedo che sopravviverà a questo specifico benchmark. La decisione di valutare sullo stato del database piuttosto che sulla somiglianza a livello di token è corretta — misura direttamente se l'agente ha portato a termine il compito, non se ha detto le cose giuste.
I domini, tuttavia, sono limitati per progettazione. Retail e compagnia aerea sono proceduralmente puliti: i documenti politici sono finiti e scritti per il benchmark, le API sono piccole e ben specificate, e il simulatore utente è cooperativo per impostazione predefinita. I documenti politici del mondo reale sono ambigui; gli utenti reali mentono, dimenticano e oppongono resistenza ai rifiuti. Gli autori del benchmark lo riconoscono — l'esistenza stessa di τ²-bench (arXiv:2506.07982) come sequel, che si estende a un modello Dec-POMDP a controllo duale in cui anche l'utente manipola lo stato dell'ambiente, è un'ammissione che la valutazione a controllo singolo sottostima la difficoltà.
C'è anche una domanda su cosa misuri realmente pass^k. Se la simulazione dell'utente è essa stessa stocastica, la varianza tra k tentativi confonde l'incoerenza dell'agente con l'incoerenza del simulatore. L'articolo lo nota ma non separa completamente le due fonti di varianza. Per applicazioni critiche per la sicurezza, si vorrebbe attribuire i fallimenti — l'agente ignora le politiche, fraintende l'intento dell'utente o sceglie semplicemente il formato di chiamata dello strumento sbagliato?
La classifica su llm-stats.com ora mostra modelli come Step-3.5-Flash a 0,882, che sembrerebbe un progresso drammatico se non si notasse che la configurazione di valutazione è probabilmente cambiata: le voci più recenti sembrano essere valutate con versioni diverse del simulatore utente e possibilmente con suddivisioni di compiti diverse. Il confronto tra voci su benchmark in evoluzione è sempre sospetto.
Perché questo è importante per la finanza AI
L'agente di scrittura per Beancount che ho in mente è strutturalmente identico agli agenti valutati da τ-bench: ha strumenti specifici del dominio (aggiungere una transazione, correggere un saldo, ricategorizzare una voce), vincoli politici (non modificare periodi chiusi, non creare saldi negativi, seguire il piano dei conti) e un utente che fornisce istruzioni in linguaggio naturale in una conversazione che può estendersi su più turni.
Il risultato di pass^k è il più utilizzabile per noi. Se un modello all'avanguardia come Claude 3.5 Sonnet raggiunge un pass@4 di solo 0,462 nel retail — un dominio relativamente indulgente — dovremmo aspettarci una coerenza simile o peggiore sulla scrittura di registri contabili, dove gli errori si accumulano tra le transazioni e le violazioni delle politiche potrebbero non essere immediatamente visibili. Progettare per la coerenza su k tentativi fin dall'inizio — non solo ottimizzare il pass@1 e considerare il lavoro finito — cambia l'architettura: sostiene un uso conservativo degli strumenti (chiedere prima di scrivere, non dopo), passaggi espliciti di verifica delle politiche prima di qualsiasi chiamata API e un agente di verifica separato che controlli la differenza proposta sul database prima che venga applicata.
La metodologia di valutazione basata sullo stato del database è anche direttamente trasportabile. Il formato strutturato dei file di Beancount rende semplice confrontare lo stato atteso del registro con lo stato effettivo dopo una sessione di scrittura, fornendoci lo stesso tipo di segnale di valutazione oggettivo utilizzato da τ-bench.
Cosa leggere dopo
- τ²-bench (arXiv:2506.07982): il sequel che si estende ad ambienti a controllo duale in cui anche gli utenti invocano strumenti; direttamente rilevante se modelliamo l'utente come un partecipante attivo nelle correzioni di registro piuttosto che un richiedente passivo.
- AgentEval / GAIA (arXiv:2311.12983): il benchmark GAIA valuta assistenti AI generali su compiti del mondo reale che richiedono navigazione web e uso di strumenti; un utile complemento all'attenzione specifica per dominio di τ-bench.
- WorkArena (arXiv:2403.07718): valuta agenti su compiti software aziendali reali in ServiceNow; il dominio è più vicino ai flussi di lavoro contabili che al retail o alle compagnie aeree e varrebbe la pena leggerlo per trarre insegnamenti sulla progettazione dei compiti.