Controlli di qualità: verificare quando l'AI fa molto lavoro

Finché eseguivi il tuo processo a mano, un caso alla volta, controllare ogni output era naturale: lo leggevi comunque prima di usarlo. Ora che il flusso gira da solo su decine di casi a settimana, controllarli tutti a mano vorrebbe dire tornare esattamente al lavoro manuale che l’automazione doveva toglierti. Ma non controllare niente è peggio: un flusso automatico che comincia a sbagliare lo fa in silenzio, perché nessuno lo sta più guardando caso per caso.
Il controllo a campione batte gli estremi
La soluzione non sta fra i due estremi, sta in un terzo approccio: controllare un campione, scelto con criterio, invece di tutto o di niente. Un campione ben scelto ti dice se il flusso sta ancora funzionando bene con un costo di tempo sostenibile, senza richiederti di rileggere ogni singolo output come facevi prima dell’automazione.
Il campione giusto non è casuale al cento per cento. Mescola due tipi di casi: alcuni presi a caso dal flusso di lavoro normale, per avere un’idea onesta della qualità media, e alcuni scelti apposta perché sono i casi più difficili o più rischiosi che il tuo processo incontra, perché è lì che un problema emergerebbe per primo. Un flusso che va bene sui casi facili e sui casi a caso ma non hai mai controllato sui casi difficili ti dà una falsa sicurezza.
Costruisci un piccolo set di riferimento
Un modo concreto di applicare questa idea è costruire, una volta, un piccolo set di casi di riferimento: dieci o venti esempi reali del tuo dominio, di cui conosci già la risposta che consideri buona. Non serve un dataset enorme, serve che siano rappresentativi e che tu sappia già, per ciascuno, cosa ti aspetti. Ogni volta che cambi qualcosa nel flusso, un’istruzione, un passo, un modello diverso, fai girare di nuovo questi casi di riferimento prima di tutto il resto, e confronta il risultato con quello che ti aspettavi. Se un cambiamento peggiora anche solo uno di questi casi noti, lo scopri prima che peggiori anche i casi che non stai guardando.
Il degrado silenzioso
Il rischio più insidioso di un flusso automatico non è l’errore evidente, quello lo noti alla prima occhiata. È il degrado silenzioso: la qualità scende gradualmente, un piccolo passo alla volta, senza che nessun singolo output sembri chiaramente sbagliato. Succede spesso quando cambia qualcosa a monte, per esempio il formato dei dati che il flusso riceve, o quando un fornitore aggiorna silenziosamente un modello che usi. Il controllo a campione periodico, fatto con una cadenza regolare e non solo quando qualcosa sembra andare storto, è quello che intercetta questo tipo di degrado prima che diventi un problema visibile a chi riceve l’output finale, spesso qualcuno fuori dal tuo controllo diretto.
Un esempio vero
Il flusso che risponde alle richieste di supporto tecnico, visto nei capitoli precedenti, gira ormai su una ventina di richieste a settimana. Controllare tutte le venti a mano annullerebbe il vantaggio dell’automazione. Il controllo che regge: ogni settimana, cinque risposte scelte a caso più le due categorie di richiesta storicamente più difficili (quelle su un prodotto discontinuato, quelle in una lingua diversa dall’italiano), lette per intero contro il set di dieci casi di riferimento costruito all’inizio. Se una di queste sette risposte si allontana da quello che il set di riferimento suggerirebbe, è il segnale per fermarsi e controllare cosa è cambiato, prima che il problema si ripeta sulle altre tredici richieste della settimana che nessuno ha riletto una per una.
Con che frequenza aggiornare il set di riferimento
Il set di riferimento non va scritto una volta e dimenticato. Se il tuo dominio cambia, per esempio arriva un nuovo tipo di richiesta che prima non esisteva, il set va aggiornato per includere anche quel caso, altrimenti continui a controllare solo la parte del flusso che già sapevi funzionare bene. Una buona abitudine è rivedere il set di riferimento ogni volta che il controllo a campione segnala qualcosa di nuovo che non era rappresentato: quel caso nuovo diventa un candidato naturale per entrare nel set, così la volta successiva lo controlli sistematicamente invece di scoprirlo di nuovo per caso.
Una cosa da fare, adesso
Per un flusso automatico che già usi, scegli dieci casi reali recenti di cui sai già dire se l’output era buono o no. Questo è il tuo primo set di riferimento. Stabilisci una cadenza (settimanale è un buon punto di partenza) per farlo girare di nuovo insieme a un piccolo campione di casi freschi, prima di fidarti che tutto stia andando come le prime volte.
Un prompt da cui partire
Ecco un caso di riferimento con la risposta che considero corretta: [caso e risposta attesa].
Ecco l'output che il flusso ha appena prodotto per lo stesso caso: [output].
Confronta i due: dove si discostano, e la differenza è significativa o solo stilistica?

Fallo davvero
Il controllo con il prompt qui sopra funziona, ma resta un gesto manuale: quando i casi diventano dieci, farlo a mano ogni settimana è la prima cosa che salta. Il corso ti dà la versione automatica già costruita: scarica la cartella del banco di prova (due file: esegui.mjs e casi.json) e, se hai Node sul computer, lanciala senza chiave e senza costi:
node esegui.mjs --prova
Vedrai cinque casi di smistamento email verificati uno per uno, con un fallimento lasciato lì apposta per mostrarti com’è fatto: la risposta che non conteneva quello che doveva, e cosa mancava. I casi sono in casi.json, un file che si legge senza saper programmare: ogni caso ha un input, le parole che l’output deve contenere e quelle che non deve contenere. Il tuo set di riferimento diventa quel file: sostituisci i cinque casi con dieci casi veri del tuo flusso, e il controllo settimanale si riduce a un comando.
Se Node non ce l’hai o non fa per te, il metodo resta identico in versione manuale: il tuo casi.json è una tabella con tre colonne (input, deve contenere, non deve contenere) e una volta a settimana la passi al tuo assistente insieme agli output freschi del flusso, chiedendo quali righe passano e quali no. Lo strumento conta meno della struttura: casi scritti prima, verifica uguale ogni settimana, e un posto dove i fallimenti si vedono invece di perdersi.
Dove andare adesso
Fin qui il metodo l’hai costruito e affinato da solo. Il prossimo capitolo affronta cosa succede quando smetti di essere l’unico a usarlo, e il processo deve reggere anche quando lo eseguono colleghi che non hanno letto questo corso.