Sintesi Tecnica: Quando Termina una Valutazione di un Agente?

Definizione del Problema

Gli attuali framework di valutazione degli agenti tipicamente valutano i modelli basandosi sullo stato visibile al momento in cui viene interrotto un ciclo di esecuzione (l' "endpoint"). Questo approccio assume che l'endpoint stabilisca simultaneamente due condizioni critiche: la finalità dell'esito (il risultato è stabilito e non può cambiare) e la separazione tra le unità (l'attuale esecuzione è indipendente dalle precedenti o successive).

L'articolo sostiene che queste due condizioni siano indipendenti e spesso non soddisfatte all'endpoint.

1. Finalità dell'Esito: Un'esecuzione può interrompersi mentre operazioni asincrone (ad esempio, scritture ritardate, processi in background) sono ancora in sospeso. Valutare lo stato prima che queste operazioni si completino può portare a etichette errate (ad esempio, segnare un compito come fallito quando una scrittura ritardata avrebbe avuto successo, o viceversa).
2. Separazione tra le Unità: Se l'ambiente mantiene uno stato tra le esecuzioni (ad esempio, database condivisi, account persistenti o artefatti non puliti), un'esecuzione precedente può alterare le condizioni iniziali o l'esito di una successiva. Ciò viola l'assunto che i tentativi siano indipendenti e identicamente distribuiti (i.i.d.), rendendo invalidi le metriche aggregate (come $pass@k$).

Gli audit esistenti spesso controllano i difetti dei benchmark o i meccanismi di reset, ma non riescono a distinguere tra un esito valutato che è semplicemente "incompleto" rispetto a uno in cui il collegamento tra le esecuzioni non è stato tenuto in considerazione.

Metodologia

L'autore impiega un approccio su tre fronti per investigare questi problemi:

1. Framework Teorico (L'Argomento della Completazione):
   Il documento sviluppa un framework logico che distingue tra l'endpoint (quando l'interazione si interrompe) e la completazione (quando l'esito è stabilito e i confini sono sicuri). Definisce l'evidenza necessaria per giustificare un'etichetta finale rispetto al trattamento delle esecuzioni come tentativi separati.

2. Esperimento di Replay Controllato:
   Utilizzando AgentDojo 0.1.35, l'autore ha costruito un sistema per isolare le scelte di confine.

   • Configurazione: Un runner autonomo ha riprodotto chiamate a strumenti (tool calls) e pianificazioni di operazioni fisse. Un servizio HTTP locale ha simulato ritardi asincroni (0, 25, 100, 250 ms) e persistenza dello stato.
   • Variabili: Lo studio ha variato il tempo di valutazione (istantanea all'endpoint rispetto all'attesa dello stato terminale) e la gestione dello stato (stato condiviso vs stato con namespace vs reset verificato).
   • Metriche: L'esperimento ha misurato il disaccordo tra le etichette dell'endpoint e le etichette terminali (finalità) e la frequenza di esposizione tra le esecuzioni (separazione).

3. Revisione della Documentazione:
   L'autore ha revisionato la documentazione pubblica e i paper di dieci benchmark di agenti prominenti: WebArena, WorkArena, OSWorld, SWE-bench, tau-bench, ToolSandbox, TheAgentCompany, RE-Bench, Cybench e AgentCanary.

   • Criteri: Ha codificato le dichiarazioni esplicite riguardanti le definizioni di esecuzione, le regole di arresto, la persistenza dello stato, i meccanismi di reset e le evidenze per trattare le esecuzioni come tentativi separati.
   • Limitazioni: La revisione si è concentrata su ciò che era esplicitamente riportato, non sull'inferenza di proprietà non dichiarate.

Contributi Chiave

1. Distinzione Concettuale: Finalità dell'Esito vs Separazione tra le Unità

Il documento stabilisce che questi sono requisiti distinti che richiedono evidenze diverse:

• Finalità dell'Esito: Richiede che ogni operazione o evento rilevante che potrebbe cambiare l'esito sia risolto, limitato o confermato come cancellato.
• Separazione tra le Unità: Richiede che nessuna rotta rilevante (stato condiviso, credenziali, artefatti) permetta a un'esecuzione di influenzare le condizioni o l'esito di un'altra.
• Implicazione: È possibile ottenere la finalità senza la separazione (ad esempio, aspettando che una scrittura finisca, ma lasciando il file accessibile alla successiva esecuzione) e la separazione senza la finalità (ad esempio, isolando le esecuzioni, ma valutando prima che un'operazione ritardata si completi).

2. L'Argomento della Completazione

L'autore propone un framework decisionale per i valutatori:

• Per Etichette Finali: Un'etichetta di successo/fallimento è giustificata solo se tutte le rotte che potrebbero cambiare l'esito sono bloccate, seguite fino alla fine o strettamente limitate. Altrimenti, l'esito deve essere riportato come non risolto.
• Per Tentativi Separati: Le esecuzioni possono essere contate come unità di analisi separate solo se tutte le rotte tra di esse sono bloccate o provate incapaci di influenzare l'esito. Se esiste una connessione, le esecuzioni devono essere modellate come un'unità connessa o raggruppata.

3. Il Record degli Effetti Aperti (Open-Effects Record)

Il documento propone un nuovo standard di reporting: un record degli effetti aperti. Questo record dovrebbe elencare le operazioni o le risorse che rimangono rilevanti dopo l'endpoint, il loro stato attuale e se potrebbero cambiare l'esito valutato o influenzare un'altra esecuzione.

Risultati Sperimentali

Risultati del Replay Controllato

• Finalità: In presenza di ritardi non nulli, le etichette dell'endpoint discordavano dalle etichette terminali nel 100% dei casi (150/150 tentativi). La valutazione tramite snapshot registrava 50 successi, mentre la riconciliazione (attesa della completazione) ne registrava 200. La cancellazione verificata identificava correttamente le scritture in sospeso come fallimenti.
• Separazione: In condizioni di stato condiviso, il 75% delle coppie (150/200) mostrava un'esposizione in cui l'Esecuzione A cambiava l'esito dell'Esecuzione B. Questa esposizione è stata eliminata (0/200) sotto stato con namespace, reset verificato o quando l'Esecuzione B avveniva prima dell'Esecuzione A.
• Conclusione: L'endpoint da solo non può giustificare l'etichetta finale o l'unità di analisi. Il tempo di valutazione e la politica di gestione dello stato determinano direttamente la validità del risultato.

Risultati della Revisione della Documentazione

• Reset/Ritenzione: Documentato esplicitamente in 8/10 protocolli; parzialmente in 2/10.
• Operazioni Incompiute: Riportate in modo molto meno consistente. 6/10 protocolli esponevano shell, browser o servizi senza dichiarare se i processi discendenti o gli effetti ritardati fossero terminati, cancellati o controllati prima della valutazione.
• Evidenza per la Separazione: Solo 3/10 protocolli fornivano evidenza esplicita per trattare le esecuzioni come osservazioni separate. Sette descrivevano procedure di reset ma non dichiaravano pienamente l'ambito delle risorse coperte o come fosse stata verificata la riuscita del ripristino.
• Gap: Nessun protocollo ha documentato costantemente i periodi di tempo durante i quali gli effetti rilevanti potevano cambiare l'esito.

Significato e Rivendicazioni

Il documento sostiene che le attuali pratiche di valutazione spesso confondono la fine dell'interazione con la fine della catena causale del compito. La sua importanza risiede in:

1. Correzione della Validità delle Metriche: Dimostra che, senza verificare finalità e separazione, le metriche aggregate (come i tassi di successo) possono misurare un mix di performance del compito e artefatti ambientali.
2. Raffinamento dei Confini di Valutazione: Argomenta che il "confine di valutazione" non è un singolo momento, ma un insieme di decisioni riguardanti quando fermarsi, quando valutare e come separare le esecuzioni.
3. Proposta di uno Standard di Reporting: Introducendo il "record degli effetti aperti", il documento fornisce un meccanismo concreto affinché i valutatori possano riportare in modo trasparente gli stati non risolti e le risorse persistenti, permettendo ai lettori di valutare la validità dei risultati dichiarati.

L'autore mantiene una posizione modesta, notando che la sua revisione della documentazione è limitata a dieci protocolli e che i conteggi sperimentali riflettono condizioni costruite piuttosto che la frequenza di tali problemi nel panorama più ampio dei benchmark pubblicati. L'argomento centrale è che un'etichetta finale è giustificata solo quando tutto ciò che potrebbe ancora cambiare l'esito dichiarato è risolto, limitato o mantenuto come incertezza.