Quando si specifica una funzionalità con una componente di IA, il criterio di accettazione smette di essere «dato X il sistema restituisce Y». Il criterio di accettazione diventa una eval: un dataset etichettato, una funzione di punteggio e un punteggio obiettivo che il sistema deve superare prima del lancio e di nuovo dopo ogni cambio di modello o modifica del prompt. La regola semplice: se non sai scrivere la eval, la funzionalità non è ancora specificata. Questo articolo scompone le quattro componenti di un criterio di accettazione probabilistico e spiega come scriverle in pratica.
Che cosa si rompe esattamente in una specifica tradizionale
Una specifica classica poggia su un’assunzione: lo stesso input produce sempre lo stesso output. L’intera struttura di test, definizioni e condizioni di uscita ne deriva. Nel momento in cui una componente del sistema è un modello linguistico, quell’assunzione crolla, e con essa crolla ogni strumento costruito sopra.
L’espressione più tangibile è il test di accettazione. «L’utente clicca invia e riceve un riassunto del ticket» non è un requisito verificabile, perché non esiste una singola risposta corretta. Due riassunti diversi possono essere entrambi eccellenti, e un terzo che sembra simile può essere completamente sbagliato. Quello che serve è la definizione di un intervallo di comportamento accettabile anziché di un risultato unico.
Il test che fa risparmiare mesi di sviluppo: prima di scrivere una riga di codice, prova a scrivere la eval. Se non riesci a definire che cosa conta come buona risposta e come misurarla, il requisito è ancora vago. Le funzionalità che si arenano in pilota falliscono quasi sempre a questo stadio, non nell’implementazione.
Le quattro componenti di un criterio di accettazione per l’IA
| Componente | Che cosa definisce | Esempio |
|---|---|---|
| Descrizione del comportamento | Che cosa deve fare il sistema, formulato in modo da ammettere variabilità | Un riassunto del ticket che contenga il problema, l’azione svolta e lo stato |
| Soglia di valutazione | Un punteggio minimo su un set di test riservato, mai usato in fase di sviluppo | Il 90% dei riassunti contiene tutti e tre gli elementi |
| Vincolo di sicurezza | Che cosa costituisce un output inaccettabile, indipendentemente dal punteggio | Nessun riassunto contiene mai il numero di telefono di un cliente |
| Punto di ripresa umana | Che cosa succede nei casi che il modello non sa risolvere | Un punteggio di confidenza basso instrada il ticket a una coda umana |
La differenza tra la seconda e la terza componente è fondamentale. La soglia è statistica e tollera fallimenti isolati. Il vincolo è binario e non ne tollera nessuno. Senza quella separazione ti ritrovi con una funzionalità che passa con il 92% di successo mentre una fuga di dati si nasconde nell’8% restante.
Come costruire una eval senza un team di ricerca
Una eval non è un progetto. Nel caso tipico sono tre piccoli asset mantenuti nel tempo:
Un dataset. Da 50 a 150 casi reali presi dal sistema esistente, inclusi quelli fastidiosi. Conta che siano raccolti sul campo anziché inventati, perché i casi inventati sono sempre troppo comodi. Associa a ciascuno la risposta che darebbe un esperto di dominio.
Una funzione di punteggio. Non deve essere sofisticata. In molti casi basta verificare la presenza di elementi obbligatori, la conformità a una struttura definita o la corrispondenza di parole chiave. Dove serve giudizio puoi usare un modello come giudice, a condizione di campionare manualmente una parte dei punteggi per confermare che il giudice stesso non stia derivando.
Una soglia e una linea di base. Misura una volta prima di cambiare qualsiasi cosa. Senza una linea di base non puoi sapere se una modifica al prompt ha migliorato o rotto le cose, e la maggior parte dei team se ne accorge troppo tardi.
Quando eseguirla: una eval non è un controllo una tantum prima del rilascio. Viene rieseguita a ogni cambio di modello, ogni modifica del prompt e ogni cambiamento di una fonte dati che alimenta il sistema. È esattamente questo a distinguere una eval da un caso di test, ed è il motivo per cui va cablata nel processo di build dal primo giorno.
Sei sezioni da aggiungere al documento di specifica
| Sezione | Che cosa ci va |
|---|---|
| Specifica del comportamento del modello | Che cosa deve fare il modello, con quale tono e che cosa è fuori ambito |
| Soglie di accettazione | Le metriche e i punteggi minimi, inclusi i dati su cui vengono misurati |
| Catalogo delle modalità di guasto | L’elenco dei modi in cui la funzionalità può fallire e che cosa succede in ciascuno |
| Vincoli comportamentali | Linee rosse binarie: che cosa non deve mai comparire nell’output |
| Piano di valutazione | Il dataset, il metodo di punteggio e la frequenza di esecuzione |
| Dati e riservatezza | Quali dati entrano nel prompt e a quale livello di classificazione |
L’ultima sezione si collega direttamente alla vostra politica di classificazione dei dati. Se non l’avete ancora definita, il modello di classificazione a quattro livelli è il punto di partenza, perché senza di esso la specifica definirà una capacità che non siete autorizzati a esercitare.
Il catalogo delle modalità di guasto: la sezione che più vale la pena scrivere
In un sistema deterministico una modalità di guasto è un errore. In un sistema con una componente di IA una modalità di guasto è di solito una risposta che sembra perfettamente corretta e non lo è. Il catalogo deve quindi elencare i guasti in base a ciò che l’utente sperimenta, non a ciò che il sistema riporta.
Quattro sono particolarmente comuni: una risposta sbagliata ma sicura di sé, che richiede la citazione delle fonti per essere verificabile; un rifiuto di rispondere a una domanda legittima, che richiede un percorso alternativo; una risposta parziale che omette una condizione rilevante; e la deriva nel tempo, in cui la fonte dati cambia e l’output si degrada senza che nessuno abbia toccato una riga di codice. L’ultima è la ragione principale per cui una eval deve girare periodicamente e non solo prima del rilascio.
Che cosa comporta per tempi e budget
L’impatto pratico è uno spostamento dello sforzo. In una specifica classica gran parte del tempo va alla definizione di schermate e flussi. In una funzionalità di IA una quota significativa si sposta sulla raccolta e sull’etichettatura dei casi di test, ed è lavoro da esperto di dominio più che da sviluppatore. Mettetelo a budget esplicitamente, altrimenti viene compresso e arrivate al rilascio senza alcun modo di sapere se il sistema funziona.
Secondo spostamento: la funzionalità non «finisce» mai. Porta con sé un costo di manutenzione continuo, quello di eseguire la eval e mantenere il set di test. Quando calcolate la sostenibilità, quel costo va inserito fin dall’inizio nel modello unitario anziché emergere nel secondo trimestre.
E se la funzionalità risponde a partire dai vostri documenti, la specifica deve coprire anche il livello di recupero, perché è lì che si decide gran parte dell’accuratezza reale. Il quadro completo è nella guida alla base di conoscenza aziendale. Accompagniamo l’intero processo, dalla specifica al rilascio, all’interno delle nostre aree di competenza.
Domande frequenti
Che cos’è una eval e in che cosa differisce da un normale test di accettazione?
Una eval è un dataset etichettato insieme a una funzione di punteggio e a una soglia minima. Un normale test di accettazione verifica un singolo output e restituisce superato o fallito, mentre una eval misura una distribuzione di qualità su decine di casi e viene rieseguita a ogni cambio di modello, prompt o fonte dati.
Quanti casi di test servono per iniziare?
Tra 50 e 150 casi reali presi dal sistema esistente bastano per la maggior parte delle funzionalità. Ciò che conta è che siano raccolti sul campo anziché inventati, e che includano i casi difficili e non solo quelli comodi.
Come si scrivono criteri di accettazione per un output senza una singola risposta corretta?
Definite quattro componenti: una descrizione del comportamento che ammetta variabilità, una soglia di valutazione su un set di test riservato, un vincolo di sicurezza binario che non tollera eccezioni e un percorso di instradamento a una persona per i casi che il modello non sa risolvere.
Perché separare la soglia di valutazione dal vincolo di sicurezza?
Perché la soglia è statistica e tollera una percentuale di fallimenti, mentre il vincolo è binario. Senza quella separazione una funzionalità può passare con un punteggio alto mentre una violazione grave, come l’esposizione di dati personali, si nasconde nella percentuale di fallimento.
Si può usare un modello come giudice per valutare l’output?
Sì, ed è un metodo comune dove serve giudizio. La condizione è campionare manualmente una parte dei punteggi e confrontarli con il giudizio umano, per confermare che il giudice stesso non stia derivando nel tempo.