Perché un’allucinazione non si «aggiusta» con un prompt
Prima di toccare la configurazione, conviene accettare una realtà scomoda: le allucinazioni non sono un bug che si elimina con un’istruzione più ferma. Sono un comportamento emergente del funzionamento probabilistico del modello. Un LLM genera il token più probabile data una sequenza, non consulta una base di fatti. Quando il contesto non contiene la risposta, il modello non si ferma: completa con ciò che statisticamente si adatta. Questo significa che qualsiasi configurazione che prometta «zero allucinazioni» ti sta vendendo fumo.
Quello che puoi fare è ridurre la superficie in cui compaiono, rilevarle prima che arrivino all’utente e degradare il sistema in modo controllato quando la fiducia cala. Questo articolo è una sequenza di configurazione reale, con parametri concreti, soglie e verifiche, per team che hanno già un LLM in produzione o stanno per metterlo.
Passo 1: separa i tipi di allucinazione prima di configurare qualsiasi cosa
Non tutte le allucinazioni si mitigano allo stesso modo. Configurare senza classificare porta a rattoppare il punto sbagliato. Distingui almeno queste quattro, perché ognuna richiede uno strato diverso:
- Fattuale: il modello afferma un dato falso (una data, una cifra, una legge). Si combatte con il recupero del contesto e la verifica esterna.
- Di attribuzione: inventa una fonte, un autore o una citazione. È la più pericolosa nei contenuti editoriali perché sembra verificabile.
- Di istruzione: ignora un vincolo del sistema (risponde in un’altra lingua, rompe il formato). Si combatte con la validazione dell’output.
- Di ragionamento: i passaggi intermedi sono plausibili ma la conclusione non ne consegue. Si combatte con la scomposizione e la verifica di ogni passaggio.
Un caso che vedo ripetutamente nei team di contenuti: impostano la temperatura a 0 pensando che questo ponga fine alle invenzioni di fonti. Riduce la variabilità, sì, ma un modello con temperatura 0 continua a inventare riferimenti se non ha il dato. La temperatura riduce la dispersione, non l’ignoranza.
Passo 2: fissa la temperatura e il sampling in base al compito
La configurazione del sampling è il primo vero dial. Non esiste un valore universale; esiste un valore per tipo di compito. Segui questa tabella:
| Compito | Temperatura | top_p | Nota |
|---|---|---|---|
| Estrazione di dati da un documento | 0 – 0,1 | 1 | Vuoi determinismo, non creatività |
| Risposte su documentazione interna | 0,1 – 0,3 | 0,9 | Margine minimo per non ripetere frasi |
| Scrittura assistita con verifica umana | 0,4 – 0,7 | 0,95 | La verifica successiva è obbligatoria |
| Brainstorming, naming | 0,8 – 1,0 | 1 | Qui l’allucinazione è una feature, non un bug |
Avvertenza da esperto: abbassare top_p a 0,5 taglia la coda dei token improbabili, il che riduce le invenzioni rare ma rende anche il testo più piatto e ripetitivo. Nei compiti di estrazione strutturata conviene combinarlo con il constrained decoding (grammatiche o schemi JSON forzati), che è più efficace di qualsiasi regolazione della temperatura per evitare campi inventati.
Passo 3: monta il recupero con soglia di rifiuto
La leva più potente contro l’allucinazione fattuale è non lasciare che il modello risponda a memoria. Configura una pipeline RAG (retrieval-augmented generation) con queste decisioni esplicite:
- Suddivisione in chunk: frammenti da 300 a 600 token con sovrapposizione del 10-15%. Frammenti troppo grandi diluiscono il segnale; troppo piccoli perdono il contesto che evita interpretazioni errate.
- Recupero ibrido: combina la ricerca semantica (embedding) con la ricerca lessicale (BM25). La semantica fallisce con identificatori, codici e nomi propri; la lessicale fallisce con le parafrasi. Insieme coprono di più.
- Soglia di similarità: definisci un punteggio minimo (ad esempio, 0,75 in similarità coseno, regolato dopo aver misurato con il tuo corpus) al di sotto del quale il sistema non chiama il modello e restituisce un messaggio di «non ho informazioni sufficienti».
- Prompt a contesto chiuso: istruisci il modello a rispondere solo con i frammenti recuperati e a indicare esplicitamente quando il contesto non copre la domanda. Questa istruzione non è infallibile, ma combinata con la soglia riduce drasticamente le risposte inventate.
Ecco l’errore pratico che quasi tutti commettono la prima volta: impostare la soglia di recupero troppo alta. Il sistema inizia a rifiutare domande legittime e il team, frustrato, la abbassa a zero. La soglia corretta non si indovina: si calibra con un insieme di 50-100 domande reali, misurando quante volte rifiuta una domanda che aveva effettivamente una risposta rispetto a quante volte risponde senza contesto. Senza quell’insieme di calibrazione, qualsiasi soglia è un’intuizione.
Passo 4: istruzioni di sistema che funzionano davvero (e quelle che no)
Le frasi del tipo «non inventare nulla» hanno un’efficacia limitata. Funzionano meglio le istruzioni operative e verificabili:
- Invece di «sii preciso», usa «cita il frammento di contesto da cui deriva ogni affermazione; se non c’è frammento, rispondi ‘non risulta'».
- Invece di «non allucinare», usa «se la domanda richiede dati successivi alla tua conoscenza o non presenti nel contesto, dillo prima di rispondere».
- Aggiungi un formato di output con campi obbligatori: risposta, fonti (elenco dei frammenti usati), fiducia (alta/media/bassa). Il campo delle fonti costringe il modello a impegnarsi e facilita la verifica automatica.
Ciò che non funziona: accumulare dieci restrizioni negative nel prompt di sistema. A partire da un certo numero, il modello inizia a ignorare le prime o a sovra-restringersi e rifiutare richieste valide. Dai priorità a tre o quattro regole critiche e valida ciascuna con test.
Passo 5: verifica dell’output prima di mostrarlo all’utente
La configurazione non finisce nel modello. Aggiungi uno strato di validazione programmatica tra la risposta e l’utente:
- Validazione dello schema: se ti aspetti JSON, rifiuta qualsiasi output che non rispetti lo schema. Non tentare di ripararlo con un altro prompt senza segnalare il fallimento.
- Controllo delle entità: estrai nomi, date e cifre dalla risposta e confrontali con il contesto recuperato. Se un’entità non appare in nessuna fonte, segnalala.
- Verifica delle citazioni: se il modello cita un documento, controlla che quel documento esista nel tuo indice e che il frammento citato sia al suo interno. Le citazioni inventate si rilevano così con alta affidabilità.
- Secondo passaggio con un altro modello o prompt: un modello più piccolo che agisce come verificatore può segnalare affermazioni non supportate. Non è infallibile e aggiunge latenza, ma nei flussi di contenuti editoriali vale la pena.
Sfumatura importante: la verifica automatica ha falsi positivi. Un verificatore troppo severo rifiuterà risposte corrette che parafrasano il contesto invece di citarlo alla lettera. Configura il verificatore per confrontare il significato, non la corrispondenza esatta delle stringhe, o avrai un sistema che rifiuta tutto.
Passo 6: definisci il comportamento di degradazione
Un sistema maturo sa cosa fare quando non è sicuro. Configura esplicitamente questi stati:
- Fiducia alta: risposta diretta con fonti.
- Fiducia media: risposta con avvertenza visibile e link alle fonti per la verifica umana.
- Fiducia bassa: non rispondere; offrire di riformulare la domanda o passare a un umano.
- Fallimento della validazione: registrare il caso completo (prompt, contesto recuperato, output, motivo del rifiuto) per l’analisi successiva.
La registrazione è la parte che si dimentica più spesso e la più preziosa. Senza un log dei fallimenti non puoi migliorare soglie né prompt; puoi solo sperare. Secondo la documentazione dei principali fornitori di modelli, la valutazione continua con insiemi di test propri è l’unico modo affidabile per misurare se le tue modifiche riducono le allucinazioni o le spostano soltanto.
Passo 7: misura con un insieme di test proprio, non con benchmark pubblici
I benchmark generici non riflettono il tuo dominio. Configura un insieme di valutazione con tre tipi di casi: domande a cui il tuo sistema deve rispondere correttamente, domande fuori ambito che deve rifiutare e domande con tranello (premesse false) che deve correggere. Esegui quell’insieme ogni volta che cambi temperatura, prompt, modello o soglia di recupero.
Due metriche minime: tasso di invenzione (risposte con affermazioni non supportate diviso per le risposte date) e tasso di rifiuto corretto (domande fuori ambito rifiutate diviso per le domande fuori ambito). Se ottimizzi solo la prima, il sistema finirà per rifiutare tutto; se ottimizzi solo la seconda, risponderà inventando. Si muovono in tensione e vanno monitorate insieme.
Cosa questa configurazione non risolve
Trasparenza totale: anche con tutto quanto sopra ben montato, restano allucinazioni residue. I casi che si controllano peggio sono le allucinazioni di ragionamento in domande che richiedono più passaggi concatenati, quelle che nascono da un contesto recuperato ambiguo (documenti che si contraddicono tra loro) e quelle che compaiono quando l’utente spinge il modello con premesse false persistenti. In domini regolamentati (sanità, legale, finanziario) nessuna configurazione sostituisce la revisione umana; il sistema può assistere, ma la responsabilità dell’affermazione finale non è delegabile al modello.
L’aspettativa realistica non è zero allucinazioni, ma allucinazioni rilevate prima di causare danni, con un sistema che sa quando tacere. Questa è la configurazione che puoi difendere davanti a un cliente o a un auditor.