Testare un agente IA non è né test del software né benchmark di modelli. Un agente percorre un cammino che cambia da un’esecuzione all’altra: l’unica misura sensata è quindi una distribuzione — stesso compito, stesse condizioni, venti esecuzioni, quante si concludono correttamente. L’aritmetica è semplice e brutale: un agente accurato al 95 % a ogni passo porta a termine correttamente solo il 60 % circa dei compiti da dieci passi. Un impianto di valutazione funzionante ha quattro parti: un insieme di casi tratto dalla realtà, una misurazione su quattro livelli, una campagna di regressione a ogni modifica e il monitoraggio in produzione.
Perché il collaudo software tradizionale qui non funziona
Il collaudo software convenzionale presuppone il determinismo: lo stesso input produce lo stesso output, quindi basta coprire i percorsi. In un agente quel presupposto cade. Lo stesso input può produrre un percorso diverso, un ordine di strumenti diverso e un risultato diverso — non per un bug, ma per il modo stesso in cui opera il modello.
La domanda di collaudo cambia quindi natura. Al posto di superato o fallito, la domanda diventa: con quale frequenza riesce, e quanto dista dalla media il fallimento peggiore. I team che si scottano sono quelli che hanno visto una demo riuscita, ne hanno concluso che il sistema funziona, e hanno scoperto in produzione che la demo era la migliore esecuzione su cinque.
La metrica di successo più citata nel settore misura un singolo successo in condizioni ottimali. In produzione ciò che conta è la stabilità: stesso compito, molte esecuzioni. La distanza fra quei due numeri è la distanza fra una demo e un sistema.
L’aritmetica che spiega quasi tutto
Un agente esegue un compito come una catena di passi. Se ogni passo è indipendente, il tasso di successo del compito è il prodotto delle probabilità. Sembra banale finché non si mettono i numeri.
| Accuratezza per singolo passo | Compito da 5 passi | 10 passi | 20 passi |
|---|---|---|---|
| 90 % | 59 % | 35 % | 12 % |
| 95 % | 77 % | 60 % | 36 % |
| 98 % | 90 % | 82 % | 67 % |
| 99 % | 95 % | 90 % | 82 % |
Ne derivano due conclusioni operative. Primo: accorciare il compito vale più che migliorare il modello. Passare da venti passi a dieci, con accuratezza del 95 %, quasi raddoppia il tasso di successo, dal 36 % al 60 %. Secondo: le catene lunghe richiedono un’accuratezza per passo molto difficile da raggiungere, perciò i compiti lunghi impongono punti di controllo e validazioni intermedie invece di un unico ciclo continuo.
È anche il motivo per cui compiti insolitamente lunghi falliscono ancora nella maggior parte dei casi, persino con i migliori modelli disponibili. Spezzare il lavoro in sotto-compiti con validazioni intermedie non è un compromesso ingegneristico: è l’unica strada che la matematica consente.
Come costruire un insieme di casi che insegni davvero qualcosa
Un insieme di test scritto da chi ha costruito l’agente fallirà in produzione, perché riflette ciò che lo sviluppatore ha immaginato. L’insieme giusto nasce da tre fonti.
| Tipo di caso | Da dove proviene | In che misura |
|---|---|---|
| Percorso nominale | Le ultime venti richieste gestite manualmente | ~40 % dell’insieme |
| Casi limite reali | Reclami, rimborsi, casi che hanno richiesto un’escalation | ~40 % dell’insieme |
| Casi avversari | Tentativi di injection, input mancante, contraddizioni, richieste fuori perimetro | ~20 % dell’insieme |
Ogni caso ha bisogno di una condizione di successo definita in anticipo. Non un punteggio soggettivo, ma una condizione verificabile: il campo è stato aggiornato con il valore corretto, l’e-mail è partita all’indirizzo corretto, il totale coincide con il calcolo manuale, oppure l’agente si è rifiutato di agire e ha fatto escalation. Un caso senza condizione di successo non è un caso di test, è un’impressione.
Una dimensione di partenza ragionevole: da 40 a 80 casi, ciascuno eseguito da cinque a dieci volte. Sembra molto, ma sono pochi minuti di esecuzione e pochi euro di costo — contro un solo cliente che ha ricevuto una risposta sbagliata.
Quattro livelli di misurazione
Misurare solo l’esito nasconde la causa. Un impianto utile misura quattro livelli in parallelo.
| Livello | Che cosa viene misurato | Che cosa rivela |
|---|---|---|
| Esito | Se la condizione di successo è stata soddisfatta | Se il sistema supera l’asticella di business |
| Percorso | L’ordine degli strumenti scelti e il numero di passi | Dove l’agente inizia a derivare, prima che l’esito si rompa |
| Strumento | Percentuale di chiamate con argomento errato o strumento inadatto | Quali descrizioni degli strumenti vanno corrette |
| Costo | Token, chiamate e tempo per compito | Se la soluzione resta economica su larga scala |
Il livello percorso è il più importante per il debug. Un errore dell’agente emerge di solito lontano dal punto in cui è nato, quindi senza un log completo di ogni chiamata e di ogni risultato non c’è modo di trovare il passo che ha avviato la deriva. Il contesto strutturale è spiegato in Anatomia di un agente IA aziendale.
Regressione: che cosa rompe un agente che nessuno ha toccato
L’agente è uno dei pochi sistemi capaci di rompersi senza che nessuno abbia modificato una riga al suo interno. Le cause principali sono tre.
Aggiornamento del modello. Il fornitore rilascia una nuova versione e il comportamento si sposta — di solito migliore in media e peggiore su casi specifici che erano stati calibrati sulla versione precedente. Ogni aggiornamento del modello richiede quindi un’esecuzione completa dell’insieme prima del passaggio.
Modifica dello schema di uno strumento. Un campo aggiunto, un nome cambiato, un nuovo valore predefinito. L’agente non andrà in errore; continuerà a chiamare lo strumento nel modo che era corretto ieri.
Deriva dei dati. La forma delle richieste in ingresso cambia nel tempo, arrivano nuovi prodotti, cambia il modo in cui i clienti si esprimono. Un insieme di test vecchio di un anno sta testando un mondo che non esiste più.
Una regola pratica semplice: l’insieme viene eseguito automaticamente a ogni modifica del prompt, degli strumenti o del modello, e viene rinfrescato ogni trimestre a partire dal traffico reale.
Monitoraggio in produzione — l’unica cosa che misura la verità
L’insieme misura ciò che avete pensato di testare. La produzione misura ciò che accade. Quattro metriche bastano a intercettare in tempo quasi ogni problema.
- Tasso di completamento. La quota di compiti conclusi senza intervento umano e senza fallimento.
- Tasso di escalation. Quanto spesso l’agente si è fermato chiedendo un essere umano. Un aumento improvviso segnala un cambiamento negli input; un calo improvviso segnala eccesso di sicurezza.
- Tasso di correzione. Quanto spesso una persona ha modificato ciò che l’agente proponeva. È la metrica più vicina alla qualità reale.
- Costo per compito riuscito. Non il costo per chiamata. I compiti che falliscono e vengono rilanciati sono il costo vero — il lato finanziario è dettagliato nella guida alla riduzione del costo di inferenza.
Il tasso di correzione è anche il segnale più chiaro del fatto che il punto di approvazione si trovi nel posto giusto. Se quasi nessuno corregge nulla, l’approvazione è diventata un timbro automatico — un tema trattato nella guida all’approvazione umana.
Una checklist prima che l’agente tocchi un cliente
- Ogni caso dell’insieme ha una condizione di successo inequivocabile, scritta prima dell’esecuzione.
- Ogni caso viene eseguito almeno cinque volte, e la metrica riportata è la stabilità e non l’esecuzione migliore.
- L’insieme comprende casi avversari, incluse le tentate injection attraverso ogni canale di input — si veda la guida ai permessi.
- Per ogni esecuzione esiste un log completo delle chiamate agli strumenti e dei risultati, archiviato e consultabile.
- È stata definita un’asticella di business numerica per andare in produzione, invece di una sensazione di abbastanza buono.
- È stato definito uno scenario di ripiego: che cosa succede quando l’agente fallisce e chi riceve il compito.
Domande frequenti
Che cosa sono le valutazioni (evals) di un agente IA?
Un impianto di test che misura il comportamento dell’agente su un insieme di casi predefinito, ogni caso su più esecuzioni, e riporta la distribuzione dei risultati invece di un singolo successo. Copre l’esito, il percorso, l’uso degli strumenti e il costo.
Quanti casi di test servono?
Un insieme iniziale di 40-80 casi copre gran parte del comportamento di un agente monocompito, a patto che sia ripartito fra percorso nominale, casi limite reali e casi avversari. Più importante del numero di casi è il numero di esecuzioni per caso, che dovrebbe essere almeno cinque.
Perché un agente che funzionava nella demo fallisce in produzione?
Perché la demo misurava una sola esecuzione in condizioni comode. In produzione il compito è più lungo, gli input sono più sporchi e gli errori si compongono passo dopo passo. Un agente accurato al 95 % per passo porta a termine correttamente solo il 60 % circa dei compiti da dieci passi.
Si può usare un modello per giudicare l’agente?
Sì, ma solo come strato complementare. Il giudizio automatico si adatta a misure qualitative come il tono o la completezza di una risposta, non a condizioni di successo verificabili in modo deterministico. Ogni caso verificabile confrontando valori va verificato così.
Quando si esegue l’insieme di test?
A ogni modifica del prompt, degli strumenti o della versione del modello, più un rinfresco periodico dell’insieme a partire dal traffico reale. Un agente può rompersi anche senza che nessuno lo abbia toccato, principalmente dopo un aggiornamento del modello o una modifica dello schema di uno strumento.
Continua a leggere
Agenti IA self-hosted: quando l’infrastruttura interna si giustifica – Le valutazioni decidono il rilascio. Il luogo in cui l’agente gira decide che cosa potrete registrare, misurare e rieseguire dopo.