Come si valuta un agente IA? Attività, traiettorie, affidabilità e costi

Valutare un agente IA significa verificare se porta a termine attività rappresentative in modo affidabile, segue percorsi accettabili, rispetta i propri limiti e offre un valore adeguato rispetto al costo. La sola risposta finale non basta, perché un agente può raggiungere un risultato plausibile attraverso azioni non sicure, affermazioni non supportate, tentativi eccessivi o per pura fortuna.

Valutare un agente è difficile perché il sistema agisce nel tempo. Il modello sceglie gli strumenti, osserva ambienti che cambiano e può seguire un percorso diverso a ogni esecuzione. Per questo, valutazioni efficaci misurano i risultati e le traiettorie attraverso prove ripetute.

La terminologia delle valutazioni degli agenti

La guida di Anthropic per fare chiarezza sulle valutazioni degli agenti propone una serie di termini utili:

• Attività: un singolo caso di test con un obiettivo, un ambiente, degli input e criteri di successo.
• Prova: un tentativo dell’agente di portare a termine un’attività.
• Trascrizione o traiettoria: la sequenza di messaggi, decisioni, chiamate agli strumenti, osservazioni e azioni durante la prova.
• Valutatore: una regola, un programma, un modello o una persona che assegna un punteggio a una parte della prestazione.
• Infrastruttura di valutazione: il sistema che prepara gli ambienti, esegue le prove, raccoglie le tracce, attiva i valutatori e presenta i risultati.

Tenere distinti questi concetti evita un errore comune: considerare una singola dimostrazione riuscita come prova del fatto che l’agente si comporterà in modo affidabile.

Partire da una definizione chiara dell’attività

Una descrizione utile dell’attività da valutare specifica lo stato iniziale, gli strumenti disponibili, i vincoli, il risultato atteso e i comportamenti importanti da evitare. Il test dovrebbe somigliare al lavoro reale senza indicare un unico percorso prestabilito.

Per un agente di assistenza, «risolvi il ticket» è troppo vago. Una definizione più efficace specifica la scheda del cliente, la politica applicabile, le misure correttive consentite, le comunicazioni richieste e le modifiche che devono risultare nel sistema di registrazione. In questo modo, la prestazione può essere valutata in modo oggettivo.

Quattro livelli di valutazione degli agenti

Questi livelli dovrebbero restare distinti nei report. Riunirli in un’unica media può nascondere comportamenti inaccettabili: per esempio, un punteggio elevato di completamento delle attività potrebbe mascherare frequenti tentativi non autorizzati di usare strumenti. I team possono innanzitutto definire soglie di sicurezza inderogabili e poi confrontare la qualità dei risultati e l’efficienza delle esecuzioni che le rispettano.

1. Qualità del risultato

L’agente ha raggiunto l’obiettivo? I valutatori del risultato possono verificare modifiche precise dello stato, campi obbligatori, esiti dei test, accuratezza fattuale, supporto delle citazioni o qualità in base a una griglia di valutazione.

Quando possibile, è preferibile basarsi sullo stato finale dell’ambiente anziché su quanto afferma l’agente. Un agente di programmazione non ha risolto un bug solo perché dice di averlo fatto: devono confermarlo i test pertinenti e il comportamento del sistema.

2. Qualità della traiettoria

L’agente ha seguito un percorso corretto? La valutazione della traiettoria può rilevare accessi ai dati non necessari, uso di strumenti vietati, errori ripetuti, verifiche omesse, osservazioni inventate o violazioni delle procedure di approvazione.

Non ogni deviazione dal percorso di riferimento è un errore. Gli agenti possono trovare soluzioni valide che i valutatori non avevano previsto. I valutatori dovrebbero far rispettare i requisiti effettivi, consentendo al contempo approcci alternativi ed efficienti.

3. Sicurezza e conformità alle politiche

L’agente è rimasto entro i limiti della propria autorità? I test dovrebbero includere prompt injection, istruzioni in conflitto, dati sensibili, intenzioni dell’utente ambigue e richieste che richiedono un rifiuto o un’escalation.

Le valutazioni di sicurezza devono prevedere conseguenze realistiche in un ambiente sandbox. Una frase conforme alle politiche non basta se l’agente ha già inviato il messaggio, modificato la scheda o esposto i dati.

4. Efficienza operativa

Quanto tempo e denaro sono stati necessari per raggiungere il risultato? Tieni traccia dei token del modello, delle chiamate agli strumenti, della latenza complessiva, dei tentativi ripetuti, degli interventi umani e dei costi dei servizi esterni. Un agente che riesce dopo 100 azioni superflue può essere meno utile di un flusso di lavoro più semplice.

Usare diversi tipi di valutatori

I valutatori deterministici verificano proprietà precise: se un test è stato superato, se un file è stato modificato correttamente, se un campo del database contiene il valore richiesto o se è stato chiamato un endpoint vietato. Sono rapidi e coerenti, ma coprono solo gli aspetti codificati dagli sviluppatori.

I valutatori basati su modelli esaminano aspetti come chiarezza, completezza, pertinenza e aderenza a criteri sfumati. Sono più scalabili rispetto alla revisione umana, ma devono essere a loro volta convalidati, perché possono essere distorti o incoerenti.

I valutatori umani sono importanti per le valutazioni di esperti, i casi ambigui e la convalida dei valutatori automatici. Sono più lenti e costosi, quindi spesso i team li impiegano su campioni, casi controversi e ambiti ad alto impatto.

Le suite di valutazione più efficaci combinano questi approcci. Anche la piattaforma Evals di OpenAI considera la valutazione un processo strutturato per definire test, valutatori ed esperimenti ripetuti, anziché una verifica informale.

L’affidabilità richiede prove ripetute

Eseguite ogni attività un numero sufficiente di volte per osservare la variabilità dovuta al campionamento, ai cambiamenti degli strumenti e allo stato dell’ambiente. Riportate sia le prestazioni medie sia la frequenza degli errori gravi. Nei flussi di lavoro composti da più passaggi dipendenti, l’accuratezza di ogni singolo passaggio può sembrare elevata, mentre l’affidabilità complessiva resta bassa, perché basta un solo errore per compromettere l’intera attività.

Il comportamento degli agenti è probabilistico. La stessa attività può produrre piani, chiamate agli strumenti e risultati diversi. Eseguite più volte ogni attività importante e riportate le percentuali di successo o la distribuzione dei punteggi, non solo l’esempio migliore.

Due misure di affidabilità rispondono a domande diverse:

• Pass@k: la probabilità che almeno uno dei k tentativi riesca. È utile quando sono accettabili più tentativi.
• Pass^k: la probabilità che tutti i k tentativi riescano. Indica la coerenza quando ogni esecuzione deve andare a buon fine.

Un sistema può avere un Pass@k allettante e, al tempo stesso, non essere adatto al funzionamento automatico, perché le singole esecuzioni sono inaffidabili.

Creare un insieme rappresentativo di attività

Partite dagli errori reali e dalle richieste più comuni in produzione. Includete attività semplici, casi limite difficili, input ambigui, errori degli strumenti, dati non aggiornati, informazioni mancanti e contenuti avversari.

Segmentate i risultati per tipo di attività e livello di rischio. Una media complessiva può nascondere una grave carenza nelle operazioni finanziarie, nelle attività di lunga durata o in una particolare applicazione. Conservate un insieme di dati tenuto da parte, in modo che le ripetute ottimizzazioni dei prompt non trasformino la suite di valutazione in un insieme di addestramento.

Valutare l’ambiente, non solo il modello

Le prestazioni di un agente dipendono dalle definizioni degli strumenti, dalle autorizzazioni, dalla memoria, dalla gestione del contesto, dall’interfaccia utente, dal comportamento della rete e dall’orchestrazione. Un aggiornamento del modello può ridurre un errore e, al contempo, farne emergere un altro.

Assegnate una versione all’intero stack usato per ogni esecuzione. Registrate il modello, i prompt, gli strumenti, l’istantanea dei dati, l’ambiente, i budget e le versioni dei valutatori. In caso contrario, non sarà possibile ricondurre una variazione del punteggio a una causa significativa.

Errori comuni nella valutazione

La fuga di dati è un altro rischio. Se le attività del benchmark, le risposte attese o gli schemi di valutazione compaiono nei dati di addestramento del modello o nel contesto del prompt, il punteggio potrebbe misurare il riconoscimento anziché la capacità di generalizzare. Mantenete attività di test riservate, aggiornate i casi man mano che i sistemi cambiano e registrate il modello esatto, il prompt, le versioni degli strumenti e l’ambiente utilizzati per ogni esecuzione.

• Valutazione guidata dalle dimostrazioni: scegliere le attività dopo aver visto in cosa riesce bene l’agente.
• Valutazione basata solo sulla risposta finale: ignorare percorsi non sicuri o dispendiosi.
• Conclusioni basate su una sola esecuzione: considerare un successo fortuito come una capacità stabile.
• Test con fughe di informazioni: inserire la risposta o il percorso di riferimento nel contesto dell’agente.
• Valutatori basati su modelli non convalidati: presumere che un valutatore automatico sia corretto senza verificarne la concordanza con gli esperti.
• Ambienti statici: testare una sola interfaccia, configurazione dell’account o organizzazione dei dati.
• Assenza di test negativi: misurare il completamento delle attività senza verificare se l’agente rifiuta o inoltra la richiesta in modo appropriato.
• Ignorare gli aspetti economici: ottimizzare il successo mentre costi e latenza diventano insostenibili.

Dalle valutazioni offline al monitoraggio in produzione

Le valutazioni offline sono controllate e ripetibili. Sono ideali per confrontare prompt, modelli, strumenti e criteri prima del rilascio. Il monitoraggio in produzione fa emergere l’ampia varietà dei comportamenti effettivi degli utenti e dei cambiamenti dell’ambiente.

Un programma maturo collega i due ambiti. Gli incidenti e le tracce in produzione con un basso livello di confidenza diventano nuove attività offline. Le modifiche candidate devono superare la suite di regressione. Dopo la distribuzione, i team monitorano il successo delle attività, i tassi di intervento, gli eventi relativi ai criteri, gli errori degli strumenti, i costi, la latenza e il feedback degli utenti.

Una scheda di valutazione pratica per gli agenti

Una scheda di valutazione dovrebbe distinguere i requisiti inderogabili dalle metriche di ottimizzazione. Il rispetto dei criteri, l’autorizzazione e le prove richieste possono essere requisiti con esito positivo o negativo; accuratezza, latenza, costi e impegno dei revisori possono quindi essere confrontati tra le esecuzioni accettabili. In questo modo si evita che i team barattino un piccolo guadagno di efficienza con un peggioramento della sicurezza che un punteggio medio nasconderebbe.

Una scheda di valutazione utile può includere:

• tasso di successo delle attività e punteggio di qualità;
• coerenza tra prove ripetute;
• tasso di violazioni critiche dei criteri;
• accuratezza nella scelta degli strumenti e degli argomenti;
• tasso di recupero dopo errori degli strumenti o dell’ambiente;
• tasso di escalation e intervento umano;
• latenza mediana e di coda;
• costo di modelli, strumenti e intervento umano per ogni attività completata con successo;
• efficienza del percorso rispetto a un valore di riferimento ragionevole.

Indicate il costo per ogni attività completata con successo, non soltanto il costo per esecuzione. Un agente economico che fallisce ripetutamente può costare più di un modello più potente che riesce al primo tentativo.

Cosa ricordare su come valutare un agente IA

La valutazione degli agenti consiste nel testare un sistema completo, orientato a un obiettivo, in condizioni realistiche. Misura se il lavoro è corretto, se il percorso è accettabile, se il comportamento è ripetibile e se i costi sono ragionevoli.

Iniziate con un piccolo insieme di attività significative, più prove, valutatori su più livelli e percorsi completi. Poi trasformate ogni errore significativo in produzione in un test di regressione. Le capacità degli agenti cambiano rapidamente; un sistema di valutazione duraturo permette ai team di distinguere i progressi reali da una dimostrazione convincente.