Pubblicato il 1 Novembre 2026 · di Ismail Nasry

In breve: Un eval utile collega la qualità del modello a una decisione: rilasciare, correggere, chiedere una revisione o attivare un fallback.

Un eval AI utile non assegna soltanto un voto al modello. Verifica il lavoro che il sistema deve svolgere. Misura gli errori che il contesto può tollerare e stabilisce che cosa accade quando una risposta non è affidabile.

Per questo va legato al caso d’uso, ai criteri di accettazione e a un piano per i fallimenti. La qualità si definisce prima del go-live. Non si ricostruisce dopo i primi incidenti.

Il caso d’uso viene prima del benchmark

Un modello può ottenere buoni risultati su un benchmark e restare inadatto a un flusso concreto. Il benchmark misura compiti standardizzati. Un eval di prodotto misura invece l’insieme di modello, prompt, contesto, strumenti e regole.

La domanda utile è quale comportamento debba essere sempre presente. Va chiarito anche quale errore sia tollerabile e quale debba bloccare il flusso. Da qui si costruisce un dataset che rappresenti richieste reali o realistiche.

Il dataset dovrebbe includere casi frequenti, per capire la qualità del percorso principale. Servono anche casi ambigui o incompleti. In questi casi il sistema deve chiedere chiarimenti, invece di inventare.

Vanno aggiunti casi limite: input lunghi, dati mancanti o formulazioni insolite. I casi ad alto rischio meritano una verifica separata. Una risposta plausibile ma errata può richiedere un controllo umano o un blocco.

Sono utili anche esempi negativi. Qui il comportamento corretto può essere un rifiuto, un rinvio o un fallback.

Quando esiste un risultato univoco, gli esempi possono avere una risposta attesa. Per una risposta generativa serve spesso una rubrica. Può verificare la fedeltà alle fonti, la completezza, il formato, il tono, l’assenza di dati inventati e il rispetto dei vincoli operativi.

Una soglia unica nasconde decisioni diverse

Dire che un sistema deve raggiungere il 90 per cento di qualità sembra preciso. Lascia però aperte le domande importanti: 90 per cento di che cosa? Su quali casi? Con quale gravità degli errori?

Una media può nascondere un fallimento nel sottoinsieme più delicato. Le soglie vanno quindi definite per dimensione e classe di rischio.

Un sistema di classificazione può richiedere una precisione minima sui casi ordinari. Sui casi sensibili può essere accettato soltanto un comportamento conservativo, con revisione umana. Un assistente che produce testo può avere una soglia sulla correttezza e un’altra sulla conformità al formato.

Una scheda di accettazione collega ogni criterio a una decisione. Indica che cosa viene misurato, su quali esempi e quale risultato è sufficiente. Specifica gli errori bloccanti e l’azione che segue: rilascio, revisione, correzione o fallback.

La soglia non deve essere scelta per far passare il sistema. Deve rappresentare il rischio che prodotto e processo possono sostenere. Se non è possibile motivarla, è ancora un numero provvisorio.

Le regressioni contano più del voto assoluto

Ogni modifica può cambiare il comportamento del sistema. Può cambiare il modello, il prompt, il recupero dei documenti, una regola di filtro o il formato dell’output.

Un test eseguito una sola volta descrive la versione corrente. Non mostra se una modifica ha rotto qualcosa che funzionava. Per questo il dataset di eval deve diventare una suite di regressione.

Dopo ogni cambiamento si confrontano la versione precedente e quella nuova. Si guardano i risultati aggregati e i casi che hanno cambiato esito. Un miglioramento medio non compensa automaticamente un nuovo errore bloccante.

Conviene conservare anche il contesto dell’esecuzione: versione del modello, prompt, configurazione, strumenti disponibili, dataset, criteri e risultato. Senza questa traccia, un peggioramento può essere visibile ma difficile da attribuire.

La suite non deve restare uguale per sempre. Va aggiornata con i nuovi failure mode osservati. I casi falliti non vanno sostituiti in silenzio.

Progettare il fallback prima dell’errore

Un sistema affidabile non è quello che risponde sempre. È quello che riconosce quando non dovrebbe rispondere da solo e ha un percorso definito.

Il fallback può chiedere un dato mancante, limitare l’azione, passare la richiesta a una persona, usare un flusso deterministico o restituire un rifiuto comprensibile.

Va testato come parte dell’eval. Non basta verificare che la risposta principale sia buona. Bisogna controllare che una confidenza bassa, una fonte assente, uno strumento non disponibile o una violazione del formato producano l’esito previsto.

In un flusso con azioni esterne, la valutazione deve considerare anche l’autorizzazione dell’azione, la correttezza dei parametri e la capacità del sistema di fermarsi prima di un’operazione irreversibile.

La revisione umana non è una formula magica. Deve avere un criterio di invio, informazioni sufficienti e un tempo compatibile con il processo.

Se ogni caso incerto finisce in revisione, il sistema può diventare troppo lento o costoso. Se quasi nessun caso viene inviato, il controllo rischia di essere soltanto nominale.

Uno scenario ipotetico: classificare richieste interne

Consideriamo uno scenario ipotetico. Un assistente riceve richieste interne e propone una categoria, una priorità e una risposta preliminare. Il benchmark generale del modello non dice se l’automazione sia pronta.

Servono esempi che rappresentino le categorie del processo. Servono anche casi in cui la priorità è difficile da determinare.

La valutazione potrebbe separare almeno tre condizioni: classificazione corretta, risposta conforme alle informazioni disponibili e gestione prudente dell’incertezza. Un errore nella categoria può essere recuperabile. Una priorità inventata o una regola inesistente nella risposta può richiedere un blocco e una revisione.

Il gate di rilascio non sarebbe quindi un solo punteggio. Potrebbe richiedere il superamento della soglia sui casi ordinari, zero errori bloccanti nel campione ad alto rischio e un fallback verificato per gli input ambigui.

Sono criteri ipotetici. Le soglie effettive dipendono dal processo, dai dati e dal costo degli errori.

Quando un eval è pronto per il go-live

Un eval è abbastanza utile per una decisione quando il team sa quale comportamento sta testando e per chi conta. Deve sapere quali esempi rappresentano davvero il caso d’uso. Deve anche sapere quali errori impediscono il rilascio e che cosa succede quando il sistema non supera il criterio.

Se manca la risposta all’ultima domanda, il test misura una qualità teorica ma non governa il rischio operativo. Se mancano esempi rappresentativi, il risultato può essere accurato e irrilevante.

Se non sono chiari gli errori bloccanti, la soglia è solo un indicatore decorativo.

Le eval non eliminano l’incertezza dei sistemi generativi. Rendono però esplicite le aspettative. Permettono di confrontare le modifiche. Collegano il risultato tecnico a una decisione di rilascio.

Prima del go-live, la domanda utile è se questo sistema, su questi casi, con questi limiti e questo fallback, sia abbastanza affidabile per il lavoro che deve svolgere.