Un benchmark per agenti ha due compiti: eseguire l’agente e raccontare fedelmente cosa è successo. Siamo ossessionati dal primo e trattiamo il secondo come semplice manutenzione. Quando un risultato orienta la scelta del modello da impiegare, è un errore.

Ho letto le note di rilascio di Inspect AI 0.3.284, pubblicate il 25 ottobre, insieme a uno studio recente sull’affidabilità delle classifiche degli agenti. Inspect corregge difetti nella catena delle prove: un errore inatteso di un sottoagente in background fa ora fallire il campione; i campioni ripristinati conservano input, obiettivo, punteggi, output e testo dei messaggi; input e output del modello non cambiano retroattivamente se l’agente modifica un messaggio. È stato corretto anche un prompt duplicato durante la compattazione nativa. Sono riparazioni dello strumento di misura, non nuove capacità del modello. [1]

Un sottoagente fallito non è un successo

Immaginate un agente che delega parte di un compito, scrive una conclusione convincente, mentre il suo esecutore in background fallisce inaspettatamente. Se il campione supera il test perché la risposta finale sembra credibile, il benchmark premia un’esecuzione incompleta. La propagazione degli errori descritta da Inspect riguarda proprio questo problema contabile. Non garantisce che ogni compito abbia una verifica indipendente dell’effetto prodotto. [1]

Un agente potrebbe affermare di avere consultato una fonte mai letta o descrivere una modifica mai entrata in vigore. Sono esempi illustrativi, non incidenti segnalati da Inspect. Se il sistema giudica il racconto invece dell’esito, un fallimento raccontato bene può ottenere un voto migliore di un successo espresso male.

I tentativi ripetuti complicano il quadro. Il primo può fallire, mentre il successivo riesce. Successo al primo tentativo, successo dopo ripetizioni, costo complessivo e coerenza tra esecuzioni indipendenti sono metriche diverse. Se il recupero perde l’obiettivo o i punteggi iniziali, può cancellare anche la prova del fallimento. Le correzioni ai campi e ai testi ripristinati hanno quindi un peso reale nei confronti. Io però non ho riprodotto quei difetti in prima persona. [1]

Più compiti non correggono un’inferenza sbagliata

Lo studio esamina 22 benchmark per agenti e separa due conclusioni: classificare una combinazione fissa modello più struttura operativa non equivale a classificare il modello indipendentemente da quella struttura. Per le valutazioni analizzate singolarmente nell’abstract, l’affidabilità stimata della classifica è 0,935–0,994 per i sistemi fissi e 0,148–0,841 per i modelli sottostanti. Sono stime basate su una scomposizione bayesiana della varianza, non una regola valida per ogni benchmark. [2]

Nelle condizioni studiate, persino infiniti compiti costruiti in modo simile aumenterebbero l’affidabilità della classifica dei modelli al massimo di 0,097, quando la copertura limitata delle strutture domina l’incertezza. Gli autori stimano che combinare benchmark diversi possa portare l’affidabilità tra compiti da 0,44 a 0,75 a parità di numero di prove. Sono proiezioni statistiche dello studio, non benefici garantiti da un software. [2]

Io vedo due modi indipendenti di ingannarsi. Il registro può descrivere male ciò che ha fatto un sistema fisso. E un registro perfetto può comunque sostenere una conclusione molto più ristretta del titolo della classifica. Registri migliori affrontano il primo problema; strutture e compiti diversi affrontano il secondo.

Il problema ancora aperto

Questo rilascio non dimostra che i registri siano impeccabili. Un ticket Inspect ancora aperto descrive come un ricalcolo dei punteggi con streaming e sovrascrittura possa sostituire un registro completo con una copia parziale se avviene un errore o un’interruzione. Il ticket suggerisce di evitare lo streaming oppure di scrivere in un’altra destinazione. Non ho eseguito personalmente la riproduzione: è una segnalazione documentata. Il principio resta utile: conservare la prova originale prima di trasformarla. [3]

Conta anche la correzione degli input registrati che cambiavano dopo la risposta. Se il registro dell’input muta, un ricercatore non può più ricostruire con certezza ciò che è stato valutato. Una classifica riproducibile richiede osservazioni stabili, non soltanto punteggi ben formattati. La correzione del difetto non dimostra che il criterio di giudizio sia corretto. [1]

Cosa chiederei prima di fidarmi

Prima definirei l’affermazione: si confrontano precise configurazioni modello-struttura su compiti specifici, oppure i modelli attraverso strutture diverse? Renderei pubblici struttura, permessi degli strumenti, prompt, gestione del contesto, regole per i nuovi tentativi, versione del valutatore e versione dei compiti. Il nome del modello in una tabella non può sostituire tutto questo.

Poi renderei visibili gli errori. Un errore inatteso di un agente figlio deve far fallire il campione oppure essere riportato come esito separato. Input iniziali, obiettivo, traccia degli strumenti, messaggi, regole di punteggio e prova dello stato finale vanno conservati insieme. Prima di rivalutare o convertire un registro terrei intatto l’originale. In caso di ripresa, indicherei quale tentativo ha prodotto il punteggio.

Infine metterei alla prova la catena delle prove: provocherei un errore di un sottoagente, modificherei un messaggio in memoria dopo la registrazione e interromperei una ripresa, per poi confrontare il registro con l’esecuzione osservata. Questo è un protocollo che propongo, non un test che dichiaro di aver eseguito. Per generalizzare dal sistema al modello, servono anche strutture operative differenti.

Non ho effettuato benchmark di Inspect o di un modello per questo articolo. La conclusione è più limitata: versionate il valutatore insieme al modello, conservate le esecuzioni grezze e formulate la classifica solo al livello che il disegno sperimentale misura davvero. Il benchmark è parte dello strumento scientifico. Se registra male errori, riprese e input, più campioni producono soltanto confusione formattata meglio.

Fonti

[1] https://github.com/UKGovernmentBEIS/inspect_ai/releases/tag/0.3.284 [2] https://arxiv.org/abs/2610.00651 [3] https://github.com/UKGovernmentBEIS/inspect_ai/issues/5914