Gli eval AI vogliono budget di errore

Il modo più rapido per far sembrare pronto un prodotto AI è mettere una percentuale di qualità in dashboard e colorarla di verde. Il modo più serio per capire se quel prodotto può andare in mano agli utenti è diverso: costruire un budget dei casi di errore che rompono la fiducia, testarli in modo esplicito e bloccare il rilascio quando il workflow non regge.

La tesi è questa: gli eval dei prodotti AI hanno bisogno di budget di fail case, non di dashboard con punteggi aggregati.

Un punteggio può servire, ma solo dopo che il team sa che cosa sta misurando. Prima rischia di essere teatro da release. Comprime rischi diversi in un numero rassicurante e nasconde la domanda più importante prima del lancio: abbiamo visto abbastanza errori reali per sapere come si comporta il sistema quando sbaglia?

L’articolo di Eugene Yan sui product eval rende concreta questa disciplina: etichettare campioni simili alla produzione, allineare un evaluator per ogni dimensione di qualità e rieseguire l’harness dopo ogni modifica a prompt, modello, retrieval o configurazione. Yan insiste anche sui fail case, perché sono i difetti che rompono la fiducia e decidono se un prodotto può essere esposto agli utenti. Product Evals in Three Simple Steps è utile proprio perché tratta gli eval come infrastruttura di prodotto, non come una slide per tranquillizzare gli stakeholder.

Il punteggio non è il gate di rilascio

Una review di lancio che dice “qualità al 91 percento” suona matura. Può essere comunque vuota. Novantuno percento di cosa? Su quali utenti? Con quale mix di task? Con quanti esempi dei difetti che farebbero perdere fiducia a un cliente?

I punteggi aggregati nascondono il denominatore. Un team può valutare centinaia di campioni facili, trovare pochi difetti gravi e concludere che il prodotto è solido. Ma se il set contiene solo cinque errori davvero significativi, il team non ha imparato molto sul comportamento del sistema sotto pressione. Ha solo imparato che l’eval set è comodo.

Questo è cruciale nei prodotti basati su LLM perché gli errori costosi raramente sono errori medi. Sono i casi in cui un riassunto inventa un fatto, un bot di supporto dà una risposta sicura ma non applicabile, un sistema di retrieval cita il documento sbagliato o un agente esegue l’azione giusta sull’account sbagliato. Una dashboard verde non dice se quelle classi erano presenti nel test.

Il gate deve quindi spostarsi da “la dashboard è verde?” a “ogni classe di errore che rompe la fiducia ha copertura reale, soglia chiara e un owner capace di spiegare il rischio residuo?” È la stessa logica operativa di I milestone AI vogliono gate, non ottimismo: ciò che funziona in demo non merita automaticamente traffico di produzione.

Cosa entra in un budget di fail case?

Un budget di fail case è un impegno minimo a imparare dagli errori importanti prima del rilascio. Non è una quota per far fare brutta figura al modello. È un controllo di prodotto che costringe il team a testare i casi che generano ticket, escalation, revisioni legali, churn o perdita di fiducia interna.

Si parte dalle cinque classi di errore più dannose per il workflow. Per una feature RAG potrebbero essere affermazioni non supportate, attribuzione sbagliata della fonte, mancato rifiuto, informazione obsoleta e risposta fuori dominio. Per un assistente commerciale potrebbero essere dettagli account inventati, personalizzazione rischiosa, priorità errate, scritture CRM sbagliate e tono non accettabile. La lista deve nascere dalla superficie di prodotto, non da un benchmark generico.

Poi si definisce il budget per ogni classe. Il budget dovrebbe contenere quattro elementi: numero minimo di fail case reali o simili alla produzione, definizione dell’etichetta, evaluator responsabile e soglia di rilascio. “Fedeltà: almeno 60 fail case noti, label binaria pass o fail, evaluator di fedeltà, rilascio solo se il recall sui fail resta sopra la soglia concordata” è molto più utile di “qualità sopra il 90 percento”.

La parola decisiva è “reali”. I difetti sintetici possono aiutare all’inizio, ma spesso risultano troppo teatrali o troppo sottili rispetto agli errori disordinati che gli utenti incontrano davvero. Yan consiglia di aggiungere campioni organici di produzione quando il dataset nasce da esempi sintetici. Quel consiglio dovrebbe diventare una voce stabile del backlog: ogni incidente, escalation, query confusa e revisione manuale mancata deve alimentare l’eval set.

Qui anche la scelta del modello diventa concreta. Non si sceglie un modello in modo responsabile con un solo numero di leaderboard. Serve un portafoglio di task, come in La scelta dei modelli parte dai task, e ogni task deve avere abbastanza copertura di errore da mostrare i trade-off. Un modello più economico che supera task generici ma fallisce sui casi di contesto lungo può essere perfetto per un workflow e pericoloso per un altro.

Dove si rompe l’allineamento degli evaluator?

L’allineamento degli evaluator si rompe quando il team chiede a un solo giudice di valutare tutto. Un evaluator di “qualità complessiva” è seducente perché produce un solo numero. Però rende quasi impossibile il debug. Se il punteggio scende, il modello è meno fedele, meno rilevante, meno conciso, meno sicuro o semplicemente meno allineato al prompt del giudice?

Il pattern più robusto è un evaluator per dimensione. La fedeltà ha il suo evaluator. La rilevanza ne ha un altro. Il comportamento di rifiuto ne ha un altro. Il tono ne ha uno solo se il tono è davvero un requisito di prodotto. A quel punto il team può distinguere le dimensioni bloccanti da quelle di miglioramento. Un errore di fedeltà in un workflow sanitario, finanziario o legale può bloccare il rilascio. Un piccolo problema di concisione può non bloccarlo.

Serve anche un test set tenuto fuori dall’allineamento. Se il team itera sui prompt degli evaluator usando tutti i campioni etichettati, l’evaluator può adattarsi troppo agli esempi. Sembrerà accurato in sviluppo e poi perderà errori nuovi in produzione. Separare i dati etichettati in un set di allineamento e un set di test non è formalismo accademico. Protegge il gate dalla sua stessa autoconvinzione.

Anche il processo umano conta. Se gli annotatori non concordano sulle label, l’evaluator erediterà quell’ambiguità. Le label binarie aiutano perché impongono una decisione di prodotto: accettabile o non accettabile, vince o perde, permesso o bloccato. Le scale numeriche sembrano precise, ma spesso il team fatica a spiegare la differenza tra 3 e 4. Quando il rischio di lancio è alto, l’ambiguità va risolta nella rubrica, non nascosta in un decimale.

Quando va rieseguito il gate?

Nel momento in cui cambia un workflow LLM, la dashboard verde di ieri diventa evidenza storica. Una modifica al prompt può cambiare tono e comportamento di rifiuto. Un parametro di retrieval può migliorare il recall e peggiorare la qualità delle fonti. Una migrazione di modello può ridurre il costo e aprire nuovi edge case. Una modifica ai permessi degli strumenti può trasformare un difetto innocuo in un incidente operativo.

L’eval harness deve girare dopo ogni modifica significativa di configurazione. Questo include template dei prompt, modello scelto, parametri del modello, retrieval, chunking, ranking, schema degli strumenti e testo delle policy. Se il team non può permettersi di rieseguire gli eval, il processo di eval è troppo pesante per il ritmo del prodotto.

Per questo il budget di fail case deve essere abbastanza piccolo da girare spesso e abbastanza serio da bloccare il rilascio. Non è un benchmark di ricerca. È un circuito di controllo del prodotto. Un buon harness permette di confrontare configurazione attuale e configurazione candidata, leggere le regressioni per classe di errore e decidere se il cambiamento è sicuro. La domanda non è “il punteggio è migliorato?” La domanda è “quali rischi per la fiducia dell’utente sono migliorati, quali sono peggiorati e qualcuno supera la nostra tolleranza di rilascio?”

La stessa disciplina vale oltre gli eval. AI coding: prima i criteri di accettazione dice una cosa simile per il codice generato: il sistema è governabile solo quando la condizione di accettazione è esplicita prima dell’output. Gli eval dei prodotti AI hanno bisogno della stessa inversione. Decidere cosa non deve fallire prima che il modello produca una demo convincente.

Audit di un workflow prima del prossimo lancio

Scegli un workflow AI vicino al lancio o già in produzione. Non partire chiedendo se il punteggio complessivo è abbastanza alto. Parti da cinque domande.

Quali cinque classi di errore danneggerebbero di più la fiducia degli utenti? Quanti esempi reali di ogni classe sono nell’eval set? Chi li ha etichettati e con quale rubrica? Quale evaluator intercetta ogni classe e come è stato testato su label tenute fuori dall’allineamento? Quali modifiche obbligano a rieseguire il gate prima del rilascio?

Se il team non sa rispondere, il prodotto può anche essere spedito, ma non sta passando da un gate di eval. Sta passando da una speranza con analytics intorno.

Un budget di fail case rallenta la conversazione nel punto giusto. Costringe il team a nominare i rischi, raccogliere evidenza, allineare i giudici e rieseguire il controllo quando il sistema cambia. La dashboard può ancora esistere, ma deve stare a valle del budget degli errori. Il verde non è l’obiettivo. L’obiettivo è sapere quali fallimenti puoi tollerare e quali no.