Che cosa stabilisce davvero il punteggio di un benchmark per agenti AI?

Scrivete l’affermazione prevista prima di scegliere un benchmark¶

Agent Evaluation Reliability: More Tasks Won’t (Always) Fix An Agent Leaderboard, preprint presentato il 30 settembre 2026 da Michael Hardy, Ruhana Azam, Anka Reuel, Mykel Kochenderfer e Sanmi Koyejo, distingue due domande a cui una classifica può rispondere. La prima chiede quale sistema completo si colloca più in alto. La seconda chiede quale modello sottostante si colloca più in alto. Gli autori applicano una scomposizione bayesiana della varianza a 22 benchmark: nove dell’Holistic Agent Leaderboard (HAL) e tredici dell’Harbor Index.

Gli autori riportano che le classifiche di sistemi fissi composti da modello e scaffold erano più affidabili delle classifiche dei modelli sottostanti. Le loro misure di affidabilità descrivono quanto stabilmente una classifica regge per i modelli, gli scaffold e i compiti campionati. Non dicono nulla sulla frequenza con cui un agente completa un compito e non stabiliscono se una classifica misuri la capacità giusta. Non abbiamo verificato l’accettazione del paper. Leggi il paper.

Uno scaffold è il software che circonda il modello: gestisce lo stato, espone gli strumenti e trasforma gli output del modello in azioni. Un acquirente che seleziona un’applicazione di agenti completa dovrebbe includere quel software nel sistema valutato. Un team che sceglie un modello sostitutivo dovrebbe trattare lo stesso software come una condizione da mantenere fissa o da variare di proposito.

Scrivete la conclusione prevista in una frase prima di costruire o leggere una valutazione. Per esempio: «Questa configurazione è in grado di preparare un’istruzione di pagamento autorizzata a partire da questi tipi di documento, secondo questa policy di approvazione.» La frase fissa il processo, l’azione e le condizioni che le prove devono coprire. Un’affermazione generale sulle capacità di un agente richiederebbe un disegno di valutazione molto più ampio.

Dichiarate il perimetro testato¶

Evaluation Profiles for AI Agent Security Assessment, di Han, Chen, Fan e Wu, è stato pubblicato il 23 ottobre 2026. Organizza la valutazione attorno a profili di infrastruttura e di scenario, chiede ai rapporti di dichiarare i profili scelti e la loro configurazione e chiede di contrassegnare esplicitamente le metriche non applicabili. Il documento è la revisione 00 di un Internet-Draft individuale. Non ha l’avallo dell’IETF né valore di standard; qui lo usiamo come proposta concreta di reporting ancora in fase di sviluppo. Leggi la proposta e il suo stato.

Per un processo aziendale, una dichiarazione del perimetro indica le parti del sistema che hanno prodotto il risultato e il soggetto che lo ha giudicato:

La persistenza richiede una voce a sé. Una sessione pulita non può mostrare come un agente gestisce le informazioni trasmesse da una sessione all’altra, una questione affrontata nella nota sulle policy nella memoria degli agenti. Uno strumento simulato sostiene affermazioni sulla simulazione. Un’affermazione su un servizio reale richiede prove che coprano l’interazione con il servizio e lo stato che ha lasciato.

• Modello: identificatore dello snapshot e impostazioni di inferenza.
• Scaffold: il software operativo e la sua versione.
• Strumenti e permessi: quali strumenti l’agente poteva chiamare e che cosa ciascuno poteva modificare.
• Stato iniziale: i dati di partenza del caso di test e il modo in cui sono stati ripristinati tra un caso e l’altro.
• Destinazioni degli effetti: i sistemi che ricevono gli effetti e se ciascuno è simulato o reale.
• Osservatore: che cosa poteva leggere il valutatore. Un valutatore che legge la conversazione dell’agente dispone di prove diverse da quelle di un osservatore che legge un database ufficiale dopo l’esecuzione.

Verificate che cosa stabiliscono gli strumenti e il valutatore¶

Do Agent Benchmarks Do What They Say?, preprint presentato il 29 settembre 2026 da Rohith Reddy Bellibatlu, Zichong Wang e Wenbin Zhang, tratta il comportamento dichiarato di ogni strumento come un contratto e verifica l’implementazione rispetto a esso. Su quattro benchmark, gli autori riportano sette difetti negli strumenti e una proprietà del valutatore a commit fissati. I difetti già noti hanno in parte guidato la scelta dei benchmark, quindi i rilievi sono esempi e non indicano un tasso generale di difetti. Lo snapshot di codice precedente degli autori usa termini diversi; noi seguiamo la classificazione del paper. Leggi l’audit.

Il precedente paper MedAgentBench (versione 2, 12 febbraio 2025) mostra un limite dichiarato nei suoi stessi metodi. La sua configurazione di valutazione invia richieste GET all’ambiente, verifica i payload POST e segnala all’agente l’esito positivo dell’esecuzione; la valutazione delle azioni controlla il payload richiesto. Gli autori documentano questa impostazione, quindi i lettori possono interpretare i risultati delle azioni al suo interno. Leggi i metodi originali, sezioni 2.4–2.4.3.

Per un processo di gestione delle fatture, tenete distinte quattro fasi e conservate ciascuna di quelle presenti. Se la valutazione si ferma a una di esse, rendete visibile quel punto di arresto nel risultato.

• Istruzione proposta: ciò che l’agente intendeva fare.
• Richiesta allo strumento: ciò che l’agente ha effettivamente inviato.
• Risposta dello strumento: ciò che lo strumento ha riferito. Un messaggio di successo è una dichiarazione dello strumento stesso.
• Effetto registrato: ciò che un osservatore indipendente ha trovato in seguito nel sistema di riferimento.

Un registro del perimetro per un pagamento a un fornitore¶

Considerate un processo fittizio di pagamento a un fornitore con tre disegni di valutazione. L’input è fisso: fornitore SUP-042, fattura INV-042 da 1.200 EUR e l’istruzione di preparare un solo pagamento che un operatore finanziario deve approvare prima che qualsiasi pagamento venga registrato. L’esecuzione del pagamento esiste solo all’interno di una simulazione locale. Non è stato eseguito alcun modello, simulatore o processo di pagamento, e lo snapshot del modello e le versioni dell’harness (l’ambiente che esegue i test) e del valutatore non sono ancora stati scelti. La tabella è un estratto del registro del perimetro della valutazione (in inglese) completo.

Il fornitore, l’importo e l’approvazione richiesta sono identici nei tre disegni, e le colonne dei risultati restano comunque separate. Aggiungere una memoria persistente introduce un nuovo comportamento da osservare. Spostare l’host degli strumenti sposta il punto in cui si verificano permessi ed effetti. Il disegno C esegue anche due sessioni, quindi il suo budget di risorse è diverso e il registro riporta questa differenza. Snapshot del modello identici non basterebbero da soli a rendere intercambiabili i tre punteggi.

Assegnate uno stato a ogni caso, anche a quelli non eseguiti¶

Il registro definisce tre casi: un normale pagamento autorizzato, un’istruzione senza approvazione e una seconda sessione che riutilizza un record del fornitore memorizzato nella prima. I casi mostrano la copertura prevista. Non stimano la frequenza dei fallimenti nella pratica, e la loro selezione non dice nulla sul fatto che un’implementazione li superi. Il caso della seconda sessione non verifica la corruzione, la revoca o la cancellazione del record memorizzato, e il caso dell’approvazione mancante non fornisce alcuna stima della robustezza contro un avversario.

Ogni risultato riceve una di cinque etichette. La bozza sui profili di valutazione chiede di contrassegnare le metriche non applicabili; il resto di questo vocabolario è una nostra proposta e nessun gruppo lo ha adottato. In questo esempio ogni risultato che dipende dall’esecuzione è «Non eseguito», e il registro non definisce alcun punteggio aggregato.

• Pubblicate per ogni caso la disponibilità delle prove e il denominatore alla base di ogni tasso.
• Escludete dal conteggio dei successi le osservazioni mancanti e i controlli non applicabili.

Che cosa abbiamo verificato nei dati pubblicati¶

Gli autori del paper sull’affidabilità pubblicano i loro dati sui risultati. Abbiamo scaricato il file dei risultati HAL dal loro repository al commit e7ec464 (29 settembre 2026) e lo abbiamo contato con la libreria standard di Python: 29.923 righe, 9 benchmark, 54 valori di nome del modello, 13 nomi di scaffold e 1.117 coppie distinte di benchmark e compito, con ogni punteggio pari a 0 o 1. Queste dimensioni corrispondono alla descrizione dei dati fornita dal repository stesso. I nomi dei modelli includono varianti per livello di ragionamento, quindi 54 è un conteggio di identificatori e sovrastima il numero di modelli di base. Repository al commit fissato, file al commit fissato.

Si è trattato di un conteggio dei dati. Non abbiamo rieseguito alcun agente, esaminato traiettorie né ristimato il modello statistico, e il conteggio non può dimostrare che le etichette e i punteggi del file siano corretti. Conferma la forma e l’identità dell’input su cui poggiano i valori di affidabilità riportati. Quei valori restano risultati degli autori.

Pubblicate il registro del perimetro insieme al risultato¶

Allegate il registro del perimetro a un risultato con lo stesso identificatore di versione e compilate i campi dell’esecuzione quando la valutazione viene eseguita:

Quando un componente cambia, indicate la modifica accanto al nuovo risultato, così i lettori possono giudicare il significato di un confronto. Un lettore può allora ricondurre una conclusione a una configurazione, a un’azione e a un’osservazione precise, e un team di assurance può decidere quali ulteriori prove servono per il proprio processo.

• ID dell’esecuzione e versioni esatte: snapshot del modello, harness, host degli strumenti, valutatore e hash del dataset.
• Impostazioni di campionamento o seed, il budget di risorse e quanto l’esecuzione ha effettivamente consumato.
• Prove del ripristino, permessi degli attori e identità di qualsiasi persona che abbia preso una decisione.
• Accesso dell’osservatore, errori di inizializzazione ed esclusioni, con il modo in cui ciascuno incide sul denominatore.
• Traccia delle azioni e differenze di stato, con i messaggi di successo degli strumenti tenuti separati dagli effetti osservati in modo indipendente.
• La regola di verdetto applicata a ciascun caso.