Nella maggior parte dei progetti di IA arriva il momento in cui qualcuno dice: «Sembra davvero buono, andiamo in produzione.» Di solito questo giudizio si basa su una dozzina di esempi scelti a mano e provati durante una riunione. Poi il sistema incontra il traffico reale e cominciano le domande. Perché ha inventato una data di consegna? Perché è peggiorato da quando abbiamo modificato il prompt? È migliore o peggiore del mese scorso?
A nessuna di queste domande si può rispondere senza valutazioni, o evals: un insieme fisso di casi di test con risposte corrette note, eseguito automaticamente ogni volta che qualcosa cambia. Le valutazioni stanno ai sistemi di IA come i test automatizzati stanno al software. Non metterebbe mai in esercizio un servizio di pagamento senza test; un sistema di IA che legge fatture o risponde ai clienti merita la stessa disciplina.
Partire dal lavoro, non dal modello
Un set di valutazione utile nasce dal processo che il sistema supporta, non da benchmark generici. Le classifiche pubbliche dicono come se la cava un modello con domande d’esame. Non dicono nulla sulla sua capacità di estrarre la data di scadenza corretta dalle fatture dei suoi fornitori.
Per questo iniziamo raccogliendo casi reali, anonimizzati dove necessario:
- Casi tipici, nella proporzione in cui si presentano davvero. Se il 70% degli ordini in entrata sono semplici riordini, anche il 70% del set deve esserlo.
- Casi difficili noti agli esperti: il fornitore che mette il totale a pagina due, il cliente che scrive in tre lingue.
- Casi in cui la risposta giusta è «non lo so»: dati mancanti, domande fuori ambito, documenti contraddittori. Un sistema che risponde sempre è più pericoloso di uno che a volte si astiene.
- Casi ostili: input che cercano di indurre il sistema a comportarsi male, come un’e-mail che contiene istruzioni rivolte all’IA.
Cinquanta casi ben scelti valgono più di cinquecento casuali. Il set cresce nel tempo: ogni errore riscontrato in produzione diventa un nuovo caso di test, così lo stesso errore non può ripresentarsi senza che nessuno se ne accorga.
Misurare ciò che conta per l’azienda
«Accuratezza» sembra un concetto semplice, ma nasconde delle scelte. Per un agente che elabora fatture, un importo sbagliato è molto più grave di un numero d’ordine d’acquisto mancante. Per un assistente di conoscenza, una risposta senza fonte può essere accettabile per le FAQ interne, ma non per le domande di compliance.
Concordiamo le metriche con i responsabili del processo, tipicamente:
- Correttezza per campo o per risposta, ponderata in base a quanto costa un errore.
- Aderenza alle fonti: ogni affermazione è supportata da una fonte che il sistema ha effettivamente recuperato?
- Qualità dell’astensione: il sistema si astiene quando deve, e solo allora?
- Latenza e costo per caso, perché una risposta corretta che richiede un minuto o costa un franco può comunque non reggere il business case.
Ogni metrica riceve una soglia da raggiungere prima della messa in produzione. La soglia viene messa per iscritto prima di conoscere i risultati, così nessuno è tentato di spostare l’asticella.
Automatizzare la valutazione, poi verificare il valutatore
Alcune risposte si possono verificare meccanicamente: un importo estratto corrisponde oppure no. Le risposte in testo libero sono più difficili. Qui un secondo modello può fungere da valutatore, confrontando la risposta con un riferimento e una griglia di valutazione. Funziona bene, ma solo se il valutatore stesso è validato: facciamo valutare un campione a delle persone, confrontiamo i risultati e ci fidiamo del valutatore automatico solo dove concorda con loro.
Le valutazioni non finiscono mai
La messa in produzione non segna la fine della valutazione. I fornitori aggiornano i loro modelli, i documenti cambiano, gli utenti trovano nuovi modi di porre le domande. Tre abitudini evitano che la qualità si degradi nel tempo:
- Eseguire l’intero set di valutazione a ogni modifica: un nuovo prompt, una nuova versione del modello, una nuova impostazione di ricerca. Se un punteggio scende, la modifica non viene rilasciata.
- Campionare il traffico di produzione per una revisione umana regolare, con i dati personali mascherati.
- Monitorare i segnali che indicano problemi: tassi di astensione in aumento, più correzioni umane, risposte più lunghe, costi più alti.
Cosa significa in pratica
Prima che un pilota vada in produzione, dovrebbe poter consultare un breve rapporto: il set di valutazione, le metriche concordate, le soglie e i risultati, con esempi dei casi in cui il sistema sbaglia. Se un fornitore non è in grado di mostrarglielo, la risposta onesta a «è pronto?» è «non lo sappiamo ancora».
Questo rapporto è anche lo strumento migliore per la decisione successiva. Mostra quali errori restano, quanto costerebbero e se più lavoro, un modello diverso o una fase di approvazione umana sia il modo più economico per correggerli.