Valutare un agente IA significa controllare se raggiunge l’obiettivo dell’utente lungo tutto il percorso di esecuzione: dalle decisioni intermedie alle chiamate agli strumenti, fino alla risposta finale. Un flusso proposto da Google parte da scenari realistici e tracce di esecuzione, poi trasforma gli errori ricorrenti in controlli ripetibili.
Il percorso, dall’obiettivo alla produzione
La sequenza conta: prima si definisce che cosa vuol dire riuscire, poi si mettono alla prova scenari e tracce, si rendono confrontabili le esecuzioni e si automatizzano i controlli. Le osservazioni raccolte in produzione possono infine aggiornare i test.
1. Definisci il successo con un percorso utente
Descrivi una persona, il suo obiettivo, i vincoli e le condizioni che permettono di verificare il risultato. Google chiama questo scenario un percorso critico dell’utente: ogni sua condizione può diventare un punto di valutazione. La guida di Google sul flusso di valutazione degli agenti usa, per esempio, il caso di un analista operativo che deve individuare una transazione contestata, verificarla nel registro interno e preparare una risposta.
Traduci il percorso in domande controllabili: l’agente ha individuato la transazione corretta? Ha consultato il registro previsto? Ha preparato una risposta coerente con il caso? Quando possibile, formula i controlli come esiti sì/no: sono più facili da applicare in modo uniforme di un voto soggettivo da 1 a 5.
2. Prova scenari realistici e leggi le tracce
Costruisci un caso ordinario e casi limite: informazioni incomplete, errori di battitura o una conversazione che cambia direzione. Le simulazioni con utenti sintetici permettono di iniziare prima che esistano molte interazioni reali; quando arrivano le tracce di produzione, si possono aggiungere anche quelle.
Prima di automatizzare un controllo, esamina manualmente le tracce: prompt, passaggi intermedi, argomenti passati agli strumenti e risultati finali. Google propone di partire, come esercizio iniziale, dalla revisione di 5–20 tracce. Cerca schemi di errore ricorrenti e trasformali in verifiche precise: per esempio, un dato mancante che porta l’agente a scegliere lo strumento sbagliato.
Per confrontare due versioni, mantieni stabile il gruppo di casi di riferimento e cambia una variabile alla volta. Se cambiano insieme l’agente e i test, un punteggio diverso non chiarisce quale modifica abbia inciso.
3. Rendi confrontabili le esecuzioni
Un agente può seguire percorsi diversi da un’esecuzione all’altra, mentre un servizio esterno o una base dati possono cambiare. Braintrust raccomanda più prove per attività e dipendenze controllate, per esempio servizi simulati (stub) o dati salvati in snapshot. La sua guida alla valutazione degli agenti descrive anche sandbox e iniezione di guasti, come timeout, risposte malformate e campi mancanti.
Questi accorgimenti aiutano a separare le variazioni dell’agente da quelle dell’ambiente e a provare come reagisce agli errori. Braintrust non indica un numero universale di prove: sceglierne una sola, però, non basta a descrivere percorsi che possono variare.
4. Combina i controlli e calibra il giudice LLM
Un processo di valutazione può affiancare quattro tipi di controllo: test unitari, metriche deterministiche, rubriche valutate da un modello linguistico e test d’integrazione. I test unitari isolano singole funzioni; quelli d’integrazione controllano il comportamento quando entrano in gioco più componenti. Le metriche deterministiche verificano criteri definiti, mentre un giudice LLM valuta risposte secondo una rubrica. Per calibrare quest’ultimo, confronta i suoi giudizi con tracce esaminate da persone.
IBM Technology descrive tre possibili distorsioni dei giudici LLM: il bias di posizione, che favorisce una risposta per il posto in cui appare; quello di verbosità, che premia risposte più lunghe; e l’auto-esaltazione, quando il modello favorisce un testo che ha generato. Per sondare il bias di posizione, inverti l’ordine delle due risposte e controlla se cambia il giudizio. È una verifica mirata a quell’effetto.
Accanto alla qualità delle risposte, misura anche il comportamento operativo: latenza, uso di token, costo delle API e numero di chiamate agli strumenti. Una risposta corretta può comunque comportare un percorso più lento o un uso diverso delle risorse.
5. Mantieni una base stabile e blocca le regressioni
Esegui la stessa serie di casi dopo ogni modifica e controlla sia il risultato complessivo sia i criteri fondamentali che prima erano superati. Un gate CI/CD può impedire l’integrazione di una modifica quando il punteggio generale scende sotto la soglia scelta o peggiora un controllo centrale. Google cita il 95% come esempio di soglia, non come valore valido per ogni agente o progetto.
Se il giudice automatico e chi revisiona una traccia non sono d’accordo, registra la decisione e la motivazione, chiarisci la regola di valutazione e aggiungi il caso, insieme a un esempio diverso, ai test di regressione. È una proposta emersa in una discussione tra professionisti su Reddit: rende più esplicito il criterio usato quando quel tipo di divergenza ricompare.
Per gruppi che usano orchestratori diversi, Google descrive agent-eval come uno strumento che standardizza le tracce OpenTelemetry con le convenzioni OpenInference e dichiara il supporto per Google ADK, LangGraph e runtime personalizzati. È una capacità dichiarata dagli autori dello strumento.
6. Riporta le osservazioni di produzione nei test
La valutazione online può seguire interazioni e risultati reali. Microsoft descrive un ciclo in cui i problemi emersi in produzione aggiornano i dati di test offline; anche Google raccomanda di aggiungere ai casi di riferimento gli errori limite incontrati sul campo. Così il gruppo di test può coprire situazioni che gli scenari iniziali non avevano previsto.
