Come testare un sistema AI prima di metterlo in produzione

Molti progetti AI che mi chiedono di rivedere sono stati approvati dopo una demo. Qualcuno ha fatto dieci domande, le risposte sembravano buone e il progetto ha avuto il budget. Nessuno però sapeva dire quante volte il sistema avrebbe dato la risposta giusta sui casi che arrivano davvero il lunedì mattina. Una eval risponde a questa domanda con un numero, prima del lancio. Qui sotto spiego come lavoro, con i dati di sistemi che ho costruito e che oggi lavorano in produzione.

Cos'è una eval di un sistema AI, in parole semplici?

Una eval (valutazione) è un insieme fisso di casi reali, ognuno con la risposta attesa, più una regola che dice quando un risultato è corretto. Si fa girare il sistema AI su tutti i casi, si contano quelli superati e si confronta il punteggio con una soglia decisa prima. Dopo ogni modifica si ripete il test sullo stesso insieme, e il confronto dice se la modifica ha migliorato o peggiorato le cose.

La demo dimostra che il sistema sa dare una buona risposta. La eval misura quanto spesso la dà, sui vostri dati e con la vostra definizione di corretto. Per chi deve decidere, il punteggio della eval è il numero su cui si decide se partire, come il tasso di scarti per una linea di produzione.

Come si testa un sistema AI, passo per passo?

Da dove prendere i casi di test per una eval?

Dal vostro storico. Gli esempi scritti apposta per il test escono puliti e brevi, mentre quelli reali hanno refusi, tre richieste nella stessa email, il documento fotografato storto col telefono. Se il sistema dovrà leggere ticket, servono ticket passati. Se dovrà leggere documenti, servono documenti già lavorati a mano, così i valori corretti sono noti.

Spesso le etichette esistono già. In una grande banca italiana l'help desk aveva lo storico dei ticket con la categoria assegnata dall'operatore. Quello storico è diventato il riferimento per un agente LLM che oggi smista oltre 1 milione di ticket l'anno su più di 400 categorie. Uno storico etichettato così è una delle prime cose che verifico prima di accettare un progetto di smistamento.

I casi si scelgono a campione, poi si aggiungono di proposito quelli difficili: le categorie rare, i documenti lunghi, il cliente che scrive mezzo in dialetto. Un set fatto solo di casi facili produce un punteggio alto che non sopravvive alla prima settimana in produzione.

Quanto deve essere severa la regola di correttezza?

Severa quanto la persona che riceve la risposta. Per Estyl, un assistente moda conversazionale che cerca in un catalogo di oltre 2 milioni di prodotti, una risposta contava come corretta solo se ogni articolo proposto rispettava la richiesta: taglia, colore, prezzo, disponibilità. Un articolo sbagliato rendeva sbagliata tutta la risposta, perché è così che la vede chi compra. Con questa regola oltre il 90% delle risposte è risultato del tutto corretto, e oltre il 95% aveva al massimo uno o due outfit sbagliati. Il caso studio Estyl racconta il lavoro sul retrieval che ha spostato quel numero.

Con una regola più morbida, per esempio la percentuale di articoli giusti sul totale, il numero sarebbe venuto più bello e avrebbe nascosto le risposte che deludono l'utente. Io li riporto entrambi e decido su quello severo.

Con cosa va confrontato il punteggio di un sistema AI?

Con le persone o il processo che fanno quel lavoro oggi, misurati sugli stessi casi e con la stessa regola. Nell'help desk della banca l'agente LLM ha raggiunto l'81% di accuratezza nello smistamento, contro il 75% degli operatori sullo stesso compito, e questo confronto ha convinto la banca ad andare in produzione. Dopo il lancio si è mosso anche l'indicatore che la banca già seguiva: il tempo medio di risoluzione è sceso da 5-6 giorni a 2-3, perché meno ticket rimbalzavano tra gli uffici sbagliati. I dettagli sono nel caso studio sullo smistamento dei ticket.

Se nessuno ha mai misurato il processo attuale, quello è il primo lavoro da fare. Chiedete a due o tre persone esperte di etichettare lo stesso campione senza consultarsi e guardate quanto spesso sono d'accordo. Puntare al 95% non ha senso su un compito in cui i vostri esperti concordano l'80% delle volte.

Quale punteggio basta per andare in produzione?

Dipende da quanto costa un errore e da cosa succede ai casi su cui il sistema è incerto. Un sistema che passa i casi dubbi a una persona può partire con un'accuratezza automatica più bassa di uno che decide da solo, perché i suoi errori vengono intercettati prima.

I controlli di validazione rendono concreto questo passaggio. In una pipeline che estrae dati da oltre 2.500 documenti finanziari al giorno, ogni documento passa circa 30 controlli, per esempio totali che devono quadrare. Solo i documenti che li superano tutti vengono approvati senza una persona; gli altri arrivano a un analista con il controllo fallito già indicato. Il lavoro manuale è sceso dell'84%. Lì, per decidere se andare live, si è guardato quanti documenti passavano in automatico senza lasciar entrare errori.

Come si evita che una modifica rompa quello che funzionava?

Rifacendo la eval completa dopo ogni modifica: un prompt nuovo, un modello diverso, un'impostazione di ricerca cambiata, l'elenco delle categorie aggiornato. I sistemi basati su LLM si rompono in silenzio. Una correzione al prompt che risolve un reclamo può rompere venti casi che nessuno stava guardando, e l'unico modo per accorgersene è rivalutare tutto l'insieme e confrontare.

Hamel Husain descrive il livello più economico di questi test come test unitari: controlli automatici e veloci da eseguire a ogni modifica, con la revisione umana dei risultati sopra (Hamel Husain, marzo 2024). In pratica tengo la eval nello stesso repository del codice e tratto un calo di punteggio come un test fallito: la modifica non va in produzione finché il calo non è spiegato.

Cosa controllare dopo che un sistema AI è andato in produzione?

I casi reali si allontanano piano piano da quelli del test. Arrivano prodotti nuovi, un modulo cambia, cambia una procedura interna, e le richieste non somigliano più a quelle provate. Tre segnali coprono quasi tutto. Il primo è quanto spesso falliscono i controlli o i casi finiscono a una persona: se il tasso sale, sono cambiati gli input. Il secondo sono le correzioni, perché ogni volta che qualcuno corregge un risultato nasce un caso etichettato. Il terzo è un piccolo campione casuale di risultati reali, rivisto ogni settimana o ogni mese da qualcuno del reparto.

I casi sbagliati vanno aggiunti al set della eval. Dopo qualche mese il set rispecchia la produzione meglio di quello usato al lancio, e ogni modifica successiva si misura su quello.

Quali errori rendono inutile una eval?

Il primo è testare su esempi inventati o ripuliti, che danno un punteggio che la produzione non confermerà. Il secondo è scegliere la regola di correttezza dopo aver visto i risultati. Il terzo è riportare una sola media che nasconde gli errori sui casi rari ma costosi: il punteggio va diviso per categoria o tipo di documento. Il quarto è saltare il confronto con gli operatori, così nessuno sa se l'85% è un buon risultato. Il quinto è fare la eval una volta prima del lancio e mai più, e il primo peggioramento lo scopre un cliente. L'ultimo è lasciare la eval solo agli sviluppatori. Chi fa il lavoro oggi sa com'è fatta una risposta giusta, e la soglia deve approvarla il responsabile del processo.

Come progetto agenti con valutazione e controlli fin dal primo giorno è spiegato nella pagina sul servizio di sviluppo agenti AI.