Un modello linguistico produce la continuazione più probabile di un testo. Se non ha la fonte, la inventa in modo plausibile. Il rimedio è architetturale.
La parola “allucinazione” è infelice, perché suggerisce un malfunzionamento occasionale e imprevedibile. Non lo è. È il comportamento atteso di un sistema costruito per generare testo probabile, applicato a una domanda per cui non dispone di informazioni.
Riconoscerlo come proprietà strutturale, e non come difetto da attendere che venga corretto, cambia il modo in cui si progetta un sistema destinato alla produzione.
Perché accade
Un modello linguistico stima quale parola è più probabile che segua a quelle precedenti, dato tutto ciò che ha visto in addestramento.
Non ha una rappresentazione separata di ciò che è vero e di ciò che non lo è. Non ha un archivio da consultare. Ha una funzione che produce testo verosimile.
Da qui derivano tre comportamenti osservabili.
Quando l’informazione è presente e ricorrente nei dati di addestramento, la risposta tende a essere corretta.
Quando l’informazione è rara, specifica o successiva all’addestramento, il modello produce comunque una risposta, costruita per somiglianza con casi analoghi. È il caso tipico di un riferimento normativo inesistente ma formalmente corretto nella struttura, o di una specifica tecnica plausibile per quel tipo di prodotto.
Il modello non segnala la differenza tra i due casi. La sicurezza espressiva è identica, perché deriva dalla fluidità del testo generato e non da una valutazione di attendibilità.
Questo è il punto che conta per un’organizzazione: l’errore non è riconoscibile dalla forma della risposta.
Le contromisure
Sono quattro e agiscono su livelli diversi. Nessuna da sola è sufficiente.
Ancoraggio ai documenti. Il sistema non risponde dalla memoria del modello ma da contenuti recuperati dagli archivi dell’organizzazione al momento della domanda. È la misura con l’effetto maggiore, perché sostituisce la generazione dal nulla con la sintesi di materiale esistente.
Va detto con precisione: riduce l’incidenza, non la azzera. Il modello può ancora sintetizzare in modo impreciso il contenuto recuperato, o estendere l’inferenza oltre ciò che il documento afferma.
Citazione obbligatoria della fonte. Ogni affermazione rimanda al documento e al punto da cui deriva. L’effetto principale non è preventivo ma di verificabilità: rende l’errore individuabile in pochi secondi da chi legge.
Ha però anche un effetto preventivo. Un’istruzione che vincola a citare per ogni affermazione riduce le risposte costruite su materiale non recuperato, perché il modello non dispone di un riferimento da indicare.
Soglie di confidenza. Il sistema valuta la pertinenza del materiale recuperato rispetto alla domanda. Sotto una soglia definita, non genera una risposta.
La soglia è un parametro di governo, non tecnico. Va calibrata in base al costo relativo dei due errori: rispondere male e non rispondere. In un ufficio istruttorio il primo costa più del secondo, e la soglia va alzata.
Rifiuto esplicito di rispondere. Il sistema deve poter dichiarare di non avere elementi sufficienti. Sembra ovvio e non lo è: richiede un’istruzione esplicita, esempi in fase di configurazione e verifica in fase di test, perché il comportamento predefinito di un modello è rispondere.
Un sistema che non dichiara mai di non sapere non è un sistema affidabile.
La supervisione umana nei punti decisionali
Le contromisure tecniche riducono la frequenza dell’errore. Non lo eliminano. La progettazione deve quindi stabilire dove un errore residuo sarebbe accettabile e dove no.
Il criterio è la conseguenza, non la probabilità.
Dove l’output alimenta un atto, una comunicazione verso l’esterno, una valutazione formale o una decisione con effetti su terzi, serve conferma umana esplicita. Non un’approvazione formale, ma una verifica che sia praticabile: con la fonte a fianco, in un tempo compatibile con il carico di lavoro reale.
Dove l’output supporta un’attività interna e reversibile, la verifica può essere a campione.
Un errore ricorrente nella progettazione consiste nel richiedere conferma su tutto. Produce un’approvazione meccanica su decine di casi identici, che non costituisce supervisione e crea un’apparenza di controllo più pericolosa della sua assenza dichiarata.
Come si misura il tasso di errore prima dell’esercizio
La misurazione richiede un insieme di prova costruito con le persone che conoscono il dominio.
Si raccolgono domande reali, incluse quelle difficili: casi limite, domande ambigue, domande la cui risposta non è presente in archivio. Queste ultime sono le più informative, perché verificano se il sistema sa astenersi.
Per ciascuna si definisce la risposta attesa, o l’astensione attesa.
Si misurano quattro grandezze. L’accuratezza sulle risposte fornite. La correttezza delle citazioni, verificando che la fonte indicata contenga effettivamente quanto affermato. Il tasso di astensione appropriata, sulle domande senza risposta in archivio. Il tasso di astensione inappropriata, cioè le domande a cui il sistema poteva rispondere e non ha risposto.
Le ultime due vanno lette insieme. Un sistema che non sbaglia mai perché si astiene quasi sempre è tarato male quanto uno che risponde sempre.
La misurazione va ripetuta dopo il rilascio, con cadenza definita, perché documenti e modelli cambiano.
Che cosa non si può eliminare
Nessuna architettura porta l’errore a zero. Un sistema che lo promette non è stato misurato su casi difficili.
Le contromisure non correggono un documento sbagliato in archivio. Se la fonte è errata o superata, la risposta sarà accuratamente sbagliata e correttamente citata.
E non sostituiscono la competenza di chi legge. Un output verificabile è utile a chi ha gli strumenti per verificarlo: la formazione degli utilizzatori sui limiti del sistema è parte del progetto, non un complemento.
In chiusura
Le allucinazioni non sono un motivo per rinunciare a un sistema di AI in un contesto regolato. Sono un requisito di progettazione, che si affronta con ancoraggio documentale, citazione obbligatoria, soglie, astensione e supervisione mirata.
Ciò che va evitato è il contrario: introdurre un sistema senza queste misure e affidarsi all’attenzione degli utilizzatori.
Se state valutando la governance di un sistema in un contesto con responsabilità formali, siamo disponibili a un confronto su come impostare controlli e misurazione prima della messa in esercizio.
