Guadagni:
- Capacità di stabilire livelli di convalida dell'output basati su schemi e regole
- Capacità di richiedere in modo significativo il coinvolgimento umano nelle decisioni ad alto impatto
- Capacità di progettare il routing basato sulla verifica e sulla soglia di attendibilità con il secondo modello
Un modello linguistico produce risultati fluidi, persuasivi e spesso accurati, ma “persuasivo” non è la stessa cosa di “corretto”. Il modello può inserire automaticamente un importo, una data o un campo JSON; Questa si chiama allucinazione (il modello produce con sicurezza informazioni che non esistono nella realtà). In un sistema aziendale, se l’output passa alla fase successiva – un pagamento, un’e-mail, una scrittura nel database – l’errore si riversa nel mondo reale. In questa unità impareremo a filtrare l'output con livelli di verifica prima che entri nel sistema e a richiedere l'intervento umano nelle decisioni ad alto impatto.
Perché è necessaria la convalida dell'output?
L'output del modello può essere danneggiato in due modi principali: formato (non conforme allo schema JSON previsto, campo mancante/in eccesso) e contenuto (il formato è corretto ma il valore è sbagliato: un codice prodotto inesistente, una data illogica). Esiste una terza dimensione in termini di sicurezza: l'output dannoso (un comando dannoso prodotto a seguito di un'iniezione o di una fuga di dati). Un sistema solido li ferma tutti e tre davanti alla porta.
Attenzione: "Modello generalmente accurato" non è un criterio di produzione. In un sistema senza verifica, anche un errore su mille significa 100 transazioni errate al giorno su 100.000 richieste al giorno.
Livelli di autenticazione: passo dopo passo
- Convalida dello schema. Verificare con la macchina che l'output sia conforme alla struttura prevista: i campi sono presenti, la loro tipologia è corretta, i campi obbligatori sono compilati?
- Convalida di regole/logiche aziendali. I valori corrispondono alle regole aziendali? (Importo > 0, la data non è futura, il codice prodotto appartiene al catalogo.)
- Controllo riferimento/sorgente. Se il modello produce un'asserzione, è possibile collegarla alla fonte? (La citazione RAG è effettivamente presente nel documento?)
- Validazione con il secondo modello (LLM-as-judge). Un modello indipendente valuta l'output come "corretto/incompleto/rischioso".
- Soglia di fiducia e orientamento. Se il modello o il validatore segnala un livello di confidenza basso, l'output non viene superato automaticamente; è rivolto agli esseri umani.
- Controllo umano. Un risultato ad alta potenza o poco sicuro dipende dall'approvazione di un esperto.
Quattro modelli copiabili
Schema + "inventatevi se non lo sapete" insieme:
Restituisci la risposta SOLO nel seguente schema JSON: Scrivi "basso". Non scrivere MAI un preventivo come se fosse esatto.
Verifica con il secondo modello (problema del giudice):
Sei un validatore indipendente. Di seguito è riportato un testo <source> e un <claim>. Controlla se OGNI numero e data nella dichiarazione è presente parola per parola nella fonte. Per ciascuno, dire: "verificato | non nella fonte | contraddice la fonte." Se anche uno di essi è "assente/in conflitto", contrassegna il risultato come "REVISIONE UMANA RICHIESTA".<source>{{ text }}</source><claim>{{ model_output }}</claim>
Regola di routing della soglia di attendibilità:
Regola di instradamento:- emin_misin = "alto" AND importo < 10.000 TL -> elaborazione automatica- emin_misin = "medio" OR importo 10.000-100.000 TL -> verifica del secondo modello- emin_misin = "basso" OR importo > 100.000 TL -> approvazione umana richiesta
Scheda riepilogativa dell'audit umano (accelera la revisione):
Quando presenti la decisione a una persona, mostra questa carta:- Cosa viene proposto? (una frase)- Su quale fonte si basa? (riferimento articolo/documento)- Quali sono i 2 presupposti più deboli?- Se approvati, possono essere invertiti? (sì/no)
Prompt debole / Prompt forte
approccio scadente
Approccio forte
"Sottrai importo dalla fattura" (testo libero)
Schema JSON rigoroso + campo null + trust
Scrivere l'output direttamente nel sistema di pagamento
Schema → regola → approvazione umana (se necessario)
Dico semplicemente al modello "sii sicuro"
Convalida numero/data con secondo modello
Elaborazione di ogni output con la stessa sicurezza
Routing basato sull'influenza e sulla fiducia
L'approccio forte non spera che il modello sia corretto; Crea una porta che ti sorprenderà quando sbaglierai.
Tre mini custodie
Caso 1 — Il regime da solo non era sufficiente. Un'automazione contabile estraeva l'importo dalle fatture come JSON. Lo schema era corretto, ma il modello produceva in fattura "125.000" invece di "1.250,00" (spostamento decimale). Lo schema non è riuscito a catturare questo; è stata rilevata la verifica della regola ("l'importo deve essere in linea con il totale delle voci della fattura del ± 1%") ed è stata impedita la registrazione errata di 112.500 TL.
Caso 2 – Il secondo modello ha catturato l’allucinazione. "Preavviso di risoluzione di 30 giorni", ha affermato un assistente del supporto legale nella sintesi del contratto; Tuttavia nel contratto erano 90 giorni. Quando il giudice indipendente ha segnalato il modello come "in conflitto con la fonte", l'output è stato inoltrato all'umano e corretto. Se fosse automatico il cliente avviserebbe la cancellazione basandosi sulla data sbagliata.
Caso 3: il routing ha ridotto il carico del 70%. Un sistema di indennizzi assicurativi approvava automaticamente le richieste di indennizzo di basso importo e di alta sicurezza e inviava all'esperto solo quelle con soglia superiore/bassa sicurezza. Delle 3.200 richieste giornaliere, solo 950 ricadevano sull’uomo; gli esperti hanno dedicato il loro tempo al 30% veramente rischioso, con un tempo medio di transazione che è sceso da 4 ore a 40 minuti.
Suggerimento: non impostare il controllo umano in modo tale che "le persone possano vedere tutto": questo stancherà le persone e l'approvazione diventerà un timbro di gomma. Invece, indirizzare solo i risultati ad alto impatto e con scarsa fiducia all’essere umano; Questo focalizza l’attenzione su ciò che conta davvero.
Rendere significativo il controllo umano
Human-in-the-loop non significa mettere una casella di spunta su carta. Il revisore deve avere (1) il contesto per comprendere la decisione, (2) l’accesso alla fonte e (3) l’autorità per dire “no”. Altrimenti il controllo resta cosmetico. La scheda di revisione (quarto modello sopra) ha lo scopo di fornire proprio questo contesto.
Errori comuni
- Eseguendo semplicemente la convalida dello schema e saltando gli errori di contenuto/valore.
- Pensare che dicendo al modello "assicurati" stai facendo una vera verifica.
- Implementa automaticamente decisioni irreversibili e di grande impatto.
- Mettere il controllo umano su ogni risultato e trasformare l’approvazione in un timbro di gomma senza senso.
- Dire "approvo" al revisore senza fornire la fonte e il contesto.
- Elaborazione di tutti gli output con lo stesso rischio senza stabilire una soglia di attendibilità e un routing.
In sintesi
- L'output è danneggiato in tre modi: forma, contenuto e intento dannoso; un sistema solido li ferma tutti e tre alla porta.
- Livelli: convalida dello schema, regola/logica aziendale, controllo del codice sorgente, secondo modello (LLM-as-judge) e instradamento della soglia di attendibilità.
- L’intervento umano dovrebbe essere obbligatorio per i risultati ad alto impatto e a bassa sicurezza.
- La revisione umana deve essere significativa: il revisore deve avere contesto, accesso alle risorse e l’autorità per dire “no”.
- Sia la sicurezza che l’efficienza si ottengono indirizzando solo quelli rischiosi agli esseri umani, non tutti i risultati.
Compito dell'applicazione
Prendi un esempio dal tuo output AI. Per prima cosa definisci uno schema JSON e forzane l'output. Quindi scrivi almeno due regole aziendali (ad esempio, "l'importo corrisponde al totale degli articoli"). Infine, imposta una tabella di instradamento: quale combinazione fiducia/influenza va automaticamente, quale va al secondo modello, quale va all’umano? Genera un campione difettoso e osserva dove ogni strato lo cattura.
lista di controllo
- [ ] Definisco uno schema rigoroso per l'output e lo verifico con la macchina.
- [ ] Ho aggiunto almeno una convalida di business/regole (logica del valore).
- [ ] Posso collegare le affermazioni alla fonte e controllarle.
- [ ] Secondo modello o convalida umana disponibile per risultati ad alto impatto/bassa sicurezza.
- [ ] Regola di routing definita in base alla fiducia e all'influenza.
- [ ] Al revisore vengono forniti il contesto, la fonte e l'autorità per rifiutare.