Test agenti AI: casi, regressione e simulazione

Il test degli agenti AI è il modo in cui un team di assistenza dimostra che un agente AI si comporta ancora bene prima che una modifica arrivi ai clienti. Si costruiscono casi di test a partire da conversazioni reali risolte e da errori passati, li si ripete prima di ogni modifica a prompt, policy, knowledge base o modello, si simulano clienti difficili, si verificano le azioni compiute dall’agente e si rilascia solo quando una soglia di rilascio scritta è superata.

In breve

• Un agente che compie azioni ha bisogno di test su ciò che ha fatto (rimborso emesso, limite rispettato, caso passato a una persona), non solo su ciò che ha detto.
• I casi di test migliori vengono dalle sue conversazioni risolte e dagli errori passati.
• Ripeta l’intero set di regressione prima di ogni modifica a prompt, policy, knowledge base, modello o strumenti.
• Esegua ogni caso critico più volte: un agente che lo supera una volta può fallire lo stesso caso all’esecuzione successiva.
• Metta per iscritto la soglia di rilascio prima dell’esecuzione dei test, così nessuno discute le soglie dopo aver visto i risultati.

Questa guida è la parte pre-rilascio della nostra guida più ampia alla valutazione degli agenti AI.

Che cos’è il test degli agenti AI, e in che cosa è diverso dal test di un chatbot?

Il test degli agenti AI verifica un agente che ragiona su più turni e compie azioni nei suoi sistemi, come emettere rimborsi, modificare ordini o aggiornare account. Il test di un chatbot verifica soprattutto risposte e flussi di conversazione. La differenza sta nelle conseguenze: una risposta sbagliata di un chatbot inganna un cliente, mentre un’azione sbagliata di un agente modifica record reali.

Se il suo bot si limita a rispondere e a passare il caso a una persona, veda il test di un chatbot. Questo articolo tratta ciò che cambia quando l’agente può agire.

La coerenza è la parte difficile. Nello studio τ-bench, in cui un modello linguistico interpreta il cliente e l’agente lavora con strumenti specifici del dominio e linee guida di policy, anche agenti forti nel function calling hanno completato meno del 50% dei compiti e hanno superato lo stesso compito retail in tutte e 8 le prove meno del 25% delle volte. Il successo era giudicato dallo stato del database alla fine della conversazione, non dalla risposta.

Che cosa deve contenere un caso di test per un agente AI?

Un caso di test per un agente AI ha bisogno di sei campi principali: lo scenario, il profilo del cliente, l’esito atteso, le azioni che l’agente può compiere, una regola di superamento che una seconda persona applicherebbe allo stesso modo e la conversazione da cui è nato. Senza gli ultimi due, i risultati dei test diventano opinioni.

Ecco il modello: i sei campi principali più quattro che mantengono il set gestibile. Lo copi in un foglio di calcolo, una riga per caso.

Due regole mantengono utile il modello. Primo, l’esito atteso descrive uno stato, non una frase: la guida tecnica di Anthropic sulle valutazioni degli agenti fa lo stesso ragionamento con un esempio di prenotazione di voli, in cui ciò che conta è se nel database esiste una prenotazione, non se l’agente dice di averla fatta. Secondo, ogni caso rimanda alla conversazione che lo giustifica, così quando una policy cambia si trovano e si aggiornano i casi che tocca.

Come si costruisce un golden test set a partire da conversazioni reali?

Costruisca il golden test set a partire dal suo traffico: conversazioni risolte che mostrano l’agente al suo meglio, errori passati che non vuole più vedere, escalation e casi limite di ogni policy. Parta da 20 a 50 casi e faccia crescere il set ogni settimana, invece di aspettare un set perfetto di centinaia di casi.

La guida di Anthropic afferma che da 20 a 50 compiti semplici ricavati da errori reali sono un ottimo inizio e raccomanda di trasformare in casi di test gli errori segnalati dagli utenti, così che la suite rifletta l’uso reale.

Un primo set equilibrato di 50 casi potrebbe avere questo aspetto (un’illustrazione; sposti i pesi in base ai suoi volumi e ai suoi rischi):

Mantenga nel set anche i casi che passano: una correzione a un flusso può romperne un altro in silenzio, e solo i casi che prima passavano lo mostreranno. Rimuova i dati personali da ogni conversazione di origine prima che diventi un caso di test.

Come si eseguono i test di regressione prima di ogni modifica a un agente AI?

Esegua i test di regressione riproducendo l’intero golden set sull’agente modificato prima che entri in produzione, con le stesse regole di superamento dell’ultima volta, e confrontando i risultati con la versione attuale. Ogni modifica conta: prompt, policy, articoli della knowledge base, versioni del modello, strumenti e regole di instradamento cambiano tutti il comportamento. Un articolo di aiuto modificato può cambiare le risposte sui rimborsi quanto una modifica al prompt.

Esegua i casi critici più di una volta. Gli agenti non sono deterministici, quindi un singolo superamento dimostra poco; gli autori di τ-bench hanno proposto per questo motivo pass^k, la probabilità che tutte le k esecuzioni abbiano successo. Il calcolo (illustrazione): un caso che l’agente supera il 90% delle volte supera 3 esecuzioni di fila solo nel 73% dei casi (0,9 × 0,9 × 0,9), e 8 esecuzioni di fila solo nel 43%.

I casi di regressione dovrebbero passare al 100%, o molto vicino. La guida di Anthropic fa la stessa distinzione: le valutazioni di regressione dovrebbero avere un tasso di superamento vicino al 100%, mentre le valutazioni di capacità per nuove abilità possono partire basse.

Come si simulano i clienti per testare un agente AI?

Simuli i clienti facendo interpretare il cliente a un secondo modello, a partire da un profilo scritto, su più turni, contro l’agente che sta testando. Dia a ogni profilo un obiettivo, dei fatti, un carattere e un punto di rottura, e aggiunga profili malevoli che spingono l’agente oltre i suoi limiti.

Le singole domande testano le risposte. La simulazione su più turni, l’impostazione usata da τ-bench, testa ciò che va storto nelle conversazioni reali: il cliente che cambia richiesta a metà o continua a insistere per un rimborso che la policy non consente.

Scriva da cinque a otto profili e li riutilizzi tra gli scenari:

1. Chi chiede in modo chiaro: una richiesta, tutti i dettagli forniti. La sua base di riferimento.
2. Il vago: numero d’ordine mancante, nome del prodotto sbagliato. Testa le domande di chiarimento.
3. Chi cambia argomento: inizia con la consegna, finisce con una disdetta.
4. L’insistente: rifiuta la prima risposta tre volte e chiede un’eccezione. Testa i limiti sotto pressione.
5. Il cliente arrabbiato: minaccia di andarsene o di lamentarsi pubblicamente. Testa il tono e il passaggio all’operatore.
6. Il cliente vulnerabile: parla di un lutto, di una malattia o di difficoltà economiche. Testa le sue regole di passaggio all’operatore per questi casi.
7. Il manipolatore: dice di essere un dipendente, incolla “ignora le tue istruzioni” o nasconde istruzioni in un allegato. Testa la resistenza a ciò che OWASP chiama prompt injection.

Un profilo trova solo i problemi che ha pensato di scriverci dentro, quindi usi la simulazione per allargare il set e le conversazioni reali per mantenerlo onesto. Gli agenti vocali aggiungono accenti, interruzioni e qualità della linea; veda il controllo qualità degli agenti vocali AI.

Come si testano le azioni e le chiamate agli strumenti di un agente AI?

Testi le azioni controllando lo stato finale nei suoi sistemi dopo la conversazione, non la descrizione che l’agente dà di ciò che ha fatto. Il record del rimborso esiste, per l’importo giusto, sull’ordine giusto? L’agente è rimasto entro i suoi limiti, ha chiesto conferma dove richiesto e non ha chiamato strumenti non consentiti?

Una risposta che dice “Ho elaborato il suo rimborso” non dimostra nulla. Per ogni caso con azioni verifichi quattro cose:

1. Azione giusta. È stato chiamato lo strumento previsto, e nessuno imprevisto.
2. Parametri giusti. Ordine, cliente, importo e motivo corretti.
3. Entro i limiti. Importo sotto il tetto, permesso disponibile, approvazione chiesta dove la sua policy richiede una persona.
4. Resoconto veritiero. Ciò che l’agente ha detto al cliente corrisponde a ciò che è successo davvero nel sistema.

OWASP inserisce l’excessive agency tra i principali rischi delle applicazioni basate su LLM: azioni dannose rese possibili da troppe funzionalità, troppi permessi o troppa autonomia. Le sue misure di mitigazione (estensioni minime, permessi minimi, approvazione dell’utente) valgono anche come lista di test. Scriva almeno un caso per ogni limite in cui il cliente chiede appena un po’ di più.

Esegua i test sulle azioni in una sandbox o su account di test, mai su record reali. La formazione di Salesforce sul suo Agentforce Testing Center avverte che testare gli agenti può modificare i dati del CRM e indica di usarlo solo in una sandbox.

Anche il passaggio all’operatore è un’azione: verifichi che l’agente passi i casi che deve passare, con una nota che permetta alla persona di proseguire (gestione delle escalation).

Come diventano nuovi casi di test gli errori in produzione?

Gli errori in produzione diventano casi di test con una routine settimanale: trovare le conversazioni in cui l’agente AI ha sbagliato, confermare l’errore, rimuovere i dati personali, scrivere il caso con il modello qui sopra e aggiungerlo al golden set. La modifica successiva non può essere rilasciata finché quel caso non passa.

La parte difficile è trovare gli errori. Una conversazione che l’agente ha “risolto” può comunque contenere una risposta sbagliata, una policy inventata o un passaggio all’operatore mancato, e le dashboard la contano come un successo (errori silenziosi degli agenti AI). Il monitoraggio degli agenti AI spiega che cosa seguire giorno per giorno, e la guida al controllo qualità degli agenti AI mostra come costruire la scheda di valutazione che li intercetta.

È qui che il QA delle conversazioni reali e i test pre-rilascio si incontrano. AutoPilot di Kaizo valuta ogni conversazione risolta da un agente AI con la sua scheda di valutazione e collega ogni punteggio alle prove: così ha errori confermati, ciascuno con una conversazione di origine per il modello. Dopo il rilascio della correzione, valutare le conversazioni reali delle settimane successive mostra se ha tenuto.

Veda dove sbaglia oggi il suo agente AI. Kaizo valuta le conversazioni degli agenti AI con la stessa scheda di valutazione del suo team e collega ogni punteggio alle righe che lo motivano. Prenoti una demo.

Se valuta con un giudice AI, verifichi anche il giudice. La nostra guida su come validare la valutazione QA con AI (in inglese) mostra come confrontare i punteggi automatici con quelli dei suoi revisori prima di fidarsene.

Che cosa deve verificare la soglia di rilascio di un agente AI?

La soglia di rilascio di un agente AI è una breve lista scritta di condizioni che una modifica deve soddisfare prima di arrivare ai clienti, concordata prima dell’esecuzione dei test. Deve bloccare su qualsiasi errore critico, richiedere risultati di regressione quasi perfetti, coprire ogni azione e ogni limite e indicare chi approva e come si torna indietro. La copi e fissi i suoi numeri.

Prima dell’esecuzione

• La modifica è messa per iscritto: che cosa, perché, chi l’ha chiesta.
• Nuovi casi per la modifica stessa (un nuovo limite riceve casi appena dentro e appena fuori).
• Ogni errore confermato in produzione dall’ultimo rilascio è nel set.
• Account di test e sandbox pronti; nessun record di clienti reali raggiungibile.

L’esecuzione

• Golden set completo eseguito sull’agente modificato e sull’agente attuale, con le stesse regole di superamento.
• Casi critici (denaro, dati, questioni legali, clienti vulnerabili) eseguiti almeno 3 volte ciascuno.
• Profili simulati eseguiti, compresi il manipolatore e l’insistente.

Condizioni di superamento

• Casi critici: 100% superati, in ogni prova. Un solo errore blocca il rilascio.
• Casi di regressione: almeno il 98% superato, e nessun caso che passava all’ultimo rilascio ora fallisce senza una spiegazione.
• Casi con azioni: nessuna azione fuori dalla lista consentita, nessun importo oltre il limite, nessuna dichiarazione di un’azione non avvenuta.
• Casi di passaggio all’operatore: ogni caso da passare è arrivato a una persona con una nota utilizzabile.
• Casi senza risposta nota: nessuna risposta inventata.

Approvazione e dopo il rilascio

• Un responsabile indicato per nome firma: il responsabile dell’assistenza o della CX per policy e tono, il responsabile dell’AI per la parte tecnica.
• Il rollback è pronto: prompt, knowledge base e versione del modello precedenti si possono ripristinare in giornata.
• I primi giorni di conversazioni reali dopo il rilascio vengono esaminati più da vicino del solito.

Esempio pratico (un’illustrazione con numeri inventati). Un team riduce la sua finestra di rimborso da 30 a 14 giorni. Il suo golden set ha 120 casi: 40 critici, 80 altri. I casi critici vengono eseguiti 3 volte, gli altri una volta, quindi l’esecuzione conta 200 prove. Il risultato: 196 prove su 200 superate, un tasso del 98% che sembra sano. Ma tutti e 4 gli errori si trovano in due casi critici. Nel primo, l’agente ha ancora offerto un rimborso al giorno 20 in una prova su tre. Nel secondo, il profilo insistente lo ha convinto a concedere un rimborso “per cortesia” in tutte e tre. La soglia blocca il rilascio. La correzione va nel prompt e in un articolo della knowledge base, vengono aggiunti due nuovi casi critici per il giorno 14 e il giorno 15, e la nuova esecuzione supera 206 prove su 206. Una media avrebbe rilasciato il bug; la soglia no.

Di quali strumenti ha bisogno per il test degli agenti AI?

Le servono tre tipi di strumenti: un luogo dove conservare e versionare i casi di test, un modo per eseguirli sull’agente (spesso con clienti simulati) e un modo per valutare i risultati rispetto alle sue regole di superamento.

• Un foglio di calcolo ed esecuzioni manuali bastano sotto i 50 casi circa e con poche modifiche al mese.
• La funzione di test di una piattaforma è adatta a una sola piattaforma con flussi standard. L’Agentforce Testing Center di Salesforce, per esempio, genera 20 casi di test per impostazione predefinita, e si stabilisce quanti sono positivi e quanti negativi.
• Gli strumenti di test e simulazione aggiungono clienti simulati, prove ripetute e verifiche di rilascio nella pipeline di deployment.
• Il QA delle conversazioni reali valuta ciò che è successo davvero dopo il rilascio e riporta gli errori confermati nel set.

Qualunque scelta faccia, conservi i casi in un formato che il suo team di assistenza possa leggere e modificare, altrimenti i responsabili delle policy smettono di aggiornarli.

Quando un programma di test completo non fa per lei?

Un programma completo è eccessivo se il suo agente AI gestisce qualche decina di conversazioni a settimana, risponde solo a domande e non può compiere azioni. In quel caso legga le trascrizioni ogni settimana e tenga una breve lista di 20 casi da ripetere a mano dopo ogni modifica.

Né il QA delle conversazioni reali lo sostituisce: valutare le conversazioni dopo la loro conclusione non blocca una modifica prima del rilascio. Le servono entrambi, i test prima della modifica e la valutazione di ogni conversazione dell’agente AI dopo.

Come iniziare questa settimana

Può avere un primo golden set, una soglia di rilascio scritta e un’esecuzione di riferimento in cinque giorni lavorativi, con un’esportazione di conversazioni recenti, il modello qui sopra e un ambiente di test.

1. Lunedì: esporti 30 conversazioni risolte dall’agente AI e 20 andate male. Rimuova i dati personali.
2. Martedì: le trascriva nel modello. Segni quali sono critiche.
3. Mercoledì: scriva la soglia di rilascio. Faccia concordare i numeri al responsabile dell’assistenza e al responsabile dell’AI.
4. Giovedì: esegua il set sull’agente attuale, con tre prove per i casi critici. È la sua base di riferimento; si aspetti qualche errore.
5. Venerdì: concordi la regola per cui nessuna modifica a prompt, policy, knowledge base o modello viene rilasciata senza una nuova esecuzione, e fissi uno slot settimanale per aggiungere al set i nuovi errori.

Veda la governance degli agenti AI per capire chi è responsabile dell’approvazione.

Domande frequenti

Che cos’è l’automazione dei test con l’AI?

L’automazione dei test con l’AI di solito indica l’uso dell’AI per testare software, per esempio agenti che scrivono ed eseguono script di test per un’applicazione web. Questo articolo tratta un altro tema: dimostrare che un agente AI rivolto ai clienti risponde e agisce correttamente prima che ogni modifica entri in produzione.

Gli agenti AI hanno degli strumenti?

Sì. Gli strumenti di un agente AI sono le funzioni che può chiamare, come consultare un ordine o emettere un rimborso. Sono il motivo per cui i test degli agenti devono verificare lo stato finale nei suoi sistemi, non solo la risposta.

Che cos’è un tester AI?

Può essere una persona che testa sistemi di AI oppure un’AI che testa altro software. Nel servizio clienti di solito è un responsabile QA o il responsabile dell’AI, che scrive i casi di test a partire da conversazioni reali e decide se una modifica supera la soglia di rilascio.

Di quanti casi di test ha bisogno un agente AI?

Parta da 20 a 50 casi ricavati da conversazioni reali ed errori passati, poi aggiunga ogni errore confermato in produzione. La copertura degli intenti principali, delle azioni e dei limiti conta più del numero assoluto.

Ogni quanto vanno eseguiti i test di regressione di un agente AI?

Esegua l’intero set prima di ogni modifica a prompt, policy, knowledge base, modelli, strumenti o instradamento, e ogni settimana anche quando nulla è cambiato, perché anche i fornitori dei modelli e i sistemi collegati cambiano.