Come creare un set di valutazione basato su scenari per un sistema di IA aziendale

Un set di valutazione utile parte da un solo flusso aziendale circoscritto e ricostruisce il lavoro con casi riproducibili, non con una cartella di prompt ben riusciti. Se un assistente per le richieste d’acquisto riceve dati plausibili ma contraddittori, non trova la policy e incontra istruzioni nascoste in un preventivo, il test deve mostrare se chiede chiarimenti, si astiene o oltrepassa i propri limiti. Prima di osservare gli output occorre quindi fissare copertura, segmenti, divieti, criteri e decisione di rilascio.

Che cosa deve coprire un set di valutazione basato su scenari?

Il set deve coprire il lavoro ordinario in relazione alle condizioni osservate e includere deliberatamente confini importanti, malfunzionamenti confermati e comportamenti vietati. Prima si delimita una versione del sistema, un flusso, gli attori ammessi, gli input, le conoscenze e gli strumenti disponibili; poi si chiarisce quale decisione dovranno sostenere i risultati. Valutare un «assistente generale» senza questi confini rende ambiguo sia il successo sia il campione da costruire.

La mappa nasce da evidenze autorizzate: registrazioni del flusso, pratiche storiche, richieste all’assistenza, ricerca con gli utenti, incidenti verificati e walkthrough con esperti di dominio. Queste fonti non sono automaticamente rappresentative o riutilizzabili. Vanno controllati permessi, qualità delle etichette, minimizzazione e possibili lacune; se il sistema è pre-lancio o la telemetria è incompleta, la composizione stimata del lavoro va dichiarata come ipotesi, non trasformata in una precisione inventata.

• Lavoro rappresentativo: compiti, ruoli, input e condizioni ricorrenti, pesati sulla migliore evidenza disponibile.
• Casi limite importanti: ambiguità, documenti mancanti, dati in conflitto, permessi insufficienti o strumenti inaffidabili.
• Malfunzionamenti noti: riproduzioni minimizzate di difetti, incidenti o reclami già confermati.
• Comportamenti vietati: azioni, divulgazioni o scorciatoie espressamente escluse da prodotto, policy o autorizzazioni.

Per l’assistente interno alle richieste d’acquisto, le regole sono illustrative e dipendono dall’organizzazione. I casi ordinari possono includere una pratica completa e una policy accessibile; quelli mirati possono introdurre un allegato mancante, importi o identificativi fornitore discordanti, evidenze insufficienti, recupero della policy non disponibile o istruzioni rivolte all’assistente dentro un preventivo. Vanno provati anche i due lati del confine: quando inoltrare una pratica completa e quando non farlo.

Come si registra ogni scenario in modo riproducibile?

Ogni scenario va registrato come una pratica che un altro valutatore possa ricostruire senza indovinare contesto o aspettative. Servono un identificativo stabile, proprietario, storia delle versioni, famiglia di copertura, famiglia di compito, segmenti, conseguenza, categoria di provenienza, autorizzazione e appartenenza al set di sviluppo o al test protetto. Questa struttura è una sintesi editoriale adattabile: i campi devono seguire il sistema e la governance delle evidenze, non diventare burocrazia decorativa.

• Configurazione: ruolo e obiettivo dell’attore, stato iniziale, richiesta, allegati, cronologia e condizioni ambientali.
• Contesto operativo: conoscenze autorizzate, strumenti, permessi, risultati degli strumenti e istruzioni fornite al sistema.
• Aspettative: fatti o cambi di stato richiesti, alternative accettabili e condizioni per chiarire, astenersi, rifiutare o inoltrare.
• Divieti: output, divulgazioni, chiamate a strumenti, azioni e cambi di stato che non devono avvenire.
• Esecuzione: valutatore, rubrica, gate, soluzione di riferimento, versioni tecniche, prove ripetute e regola di aggregazione quando necessarie.

La soluzione di riferimento serve a dimostrare che un compito circoscritto è risolvibile e ad accertare che i controlli funzionino; non deve imporre un’unica frase quando sono validi percorsi diversi. Per sistemi non deterministici o articolati in più passaggi, il numero di tentativi e la regola che li aggrega vanno stabiliti prima di leggere gli output. Occorre inoltre registrare qualifiche dei revisori, percorso di arbitraggio e versioni di modello, prompt, corpus, strumenti, policy e harness.

Un buon caso non pone soltanto una domanda difficile: ricrea un lavoro circoscritto e rende ispezionabili successo, variazioni ammesse e divieti.

Come valutare uno scenario senza premiare il comportamento sbagliato?

Per ogni scenario va scelto il metodo più circoscritto che distingua validamente successo e insuccesso. Un controllo deterministico è adatto a uno schema, un calcolo, un argomento passato a uno strumento, uno stato del record o un’azione vietata oggettivamente verificabile. Una risposta precisa non rende però corretto un controllo incompleto: il caso deve essere davvero risolvibile, il controllo deve coprire l’esito materiale e gli errori devono essere ispezionati.

• Usa fatti o soluzioni di riferimento quando l’evidenza richiesta è circoscritta ma sono valide più formulazioni o strade.
• Usa dimensioni separate e ancore osservabili per qualità aperte come completezza, utilità o aderenza alle fonti.
• Calibra un valutatore basato su modello contro giudizi umani qualificati nel contesto pertinente.
• Affida a esperti autorizzati le interpretazioni di dominio che i controlli automatici non possono risolvere validamente.
• Assegna credito parziale solo a componenti significative e mostra sempre quale componente è fallita.

Un’azione o divulgazione esplicitamente vietata resta fuori dal punteggio compensabile: una risposta elegante non può cancellarla con una media alta. È una raccomandazione editoriale, non una soglia universale; proprietari di prodotto e rischio devono definire in anticipo gate e conseguenze. Prima del confronto vanno fissate anche versione della rubrica, segmenti, aggregazione delle prove e regola decisionale. Ogni modifica successiva crea una nuova versione della valutazione, senza riscrivere retroattivamente i risultati.

Come aiutare i revisori ad applicare criteri coerenti?

I revisori lavorano in modo più coerente quando ricevono prima il contesto del compito e criteri osservabili, non soltanto una scala astratta. La guida deve spiegare finalità del flusso, ruolo dell’utente, evidenze disponibili, comportamento consentito, confine del prodotto e versione della rubrica. Ogni punto della scala richiede ancore concrete ed esempi positivi, negativi e di confine, insieme a un’opzione «evidenza insufficiente» o «non valutabile» per i casi difettosi.

1. Eseguire casi di calibrazione prima della revisione operativa e ripeterli quando cambiano compiti, policy, rubrica o gruppo di revisori.
2. Nascondere, quando praticabile, identità del sistema e ordine degli output nei confronti tra candidati.
3. Raccogliere giudizi e motivazioni indipendenti prima della discussione.
4. Indagare il disaccordo come possibile difetto del caso, soglia ambigua, contesto mancante, pluralità legittima o decisione irrisolta.
5. Assegnare un responsabile dell’arbitraggio e conservare etichette, motivazioni, versioni e decisioni.

Il consenso non va forzato quando più esiti sono legittimamente accettabili o manca ancora una scelta di prodotto. L’arbitraggio deve distinguere la correzione di un caso difettoso da una nuova regola organizzativa. Anche un valutatore automatico apparentemente coerente sui casi di sviluppo richiede controlli: OpenAI riferisce che il proprio valutatore automatico per GDPval non era sufficientemente affidabile da sostituire valutatori professionali esperti. Il risultato riguarda quel benchmark, ma rende visibile il rischio di scambiare automazione per validità.

Come mantenere utile il set durante sviluppo e rilascio?

Il set resta utile separando i casi visibili usati per migliorare il sistema dalle prove protette usate con parsimonia per confronti finali o decisioni di rilascio. Il set di sviluppo può guidare modifiche a prompt, recupero delle informazioni, strumenti, policy e flusso, ma i suoi punteggi sono evidenza di sviluppo perché il team conosce i casi. L’appartenenza al test protetto va assegnata all’ingresso nel registro, prima dell’esecuzione ordinaria e dell’ispezione degli output.

• Cercare duplicati esatti e prossimi, record sorgente condivisi, parafrasi e scenari fratelli generati dallo stesso modello.
• Tracciare l’accesso a contenuto dei casi, risposte di riferimento, rubriche e risultati.
• Spostare nel set di sviluppo un caso protetto che abbia orientato materialmente una modifica.
• Sostituire il caso esposto con una nuova pratica indipendente, non duplicata e versionata.
• Registrare proprietario, provenienza, autorizzazione, split, esposizione, revisioni, modifiche e motivo del ritiro.

Un malfunzionamento già usato per la diagnosi o la correzione appartiene alle prove di sviluppo o regressione. Il test protetto può coprire la stessa classe di errore soltanto con un caso creato indipendentemente e mai usato per guidare il cambiamento. Non esiste una percentuale universale tra i due set, così come non esiste un numero valido per ogni valutazione: composizione e dimensione dipendono dalla decisione, dalla variabilità del flusso, dai segmenti conseguenti, dall’affidabilità del giudizio e dalle evidenze autorizzate disponibili.

Il registro va riesaminato quando cambiano utenti, flusso, policy, corpus, modello, prompt, strumenti, permessi o ambiente operativo. I risultati vanno letti per famiglia di compito, famiglia di copertura, segmento, conseguenza e gate, non soltanto come media. Un superamento offline rimane una fonte di evidenza, non un certificato di valore, sicurezza, equità, conformità o prontezza produttiva. Va affiancato a monitoraggio, ricerca con utenti e analisi degli incidenti; giudizi regolamentati o ad alta conseguenza restano a persone qualificate e autorizzate.