Allucinazioni dell'intelligenza artificiale: capire e ridurre gli errori degli LLM

Un bot di assistenza non dovrebbe inventare eccezioni alle condizioni di servizio. Un assistente per la reportistica non dovrebbe improvvisare un totale. Un agente, cioè un software che usa un modello per scegliere le azioni e chiamare strumenti, non dovrebbe tirare a indovinare su quale record cliente modificare. L'obiettivo pratico è impedire che dall'applicazione escano risposte o azioni prive di riscontro.

Verificato il 17 ottobre 2026 sulla base delle indicazioni dei produttori dei modelli, della documentazione API, degli esempi di ricerca e del provvedimento giudiziario citati nei link. Gli esempi riportati sono osservazioni attribuite alle rispettive fonti; il validatore e la checklist settimanale sono indicazioni per l'implementazione, non risultati ottenuti in produzione.

Che cosa sono le allucinazioni dell'intelligenza artificiale e perché si verificano?

Un'allucinazione di un LLM è un'affermazione falsa o priva di riscontro, presentata come una risposta. LLM sta per large language model, ossia modello linguistico di grandi dimensioni: un modello addestrato a generare linguaggio a partire dalle regolarità presenti nei testi. Un'affermazione può anche essere priva di riscontro nei documenti forniti, pur essendo vera in un altro contesto.

Immagina il modello come un bravo redattore che completa una relazione usando il materiale sulla scrivania. Sa scrivere un paragrafo mancante in modo convincente. Questo, però, non dimostra che quel paragrafo debba entrare nella documentazione aziendale.

Prevedere un testo plausibile non significa verificare un fatto

Nel suo articolo di ricerca sulle cause delle allucinazioni nei modelli linguistici, pubblicato il 5 settembre 2025, OpenAI spiega che durante il preaddestramento il modello impara a prevedere il testo senza che ogni affermazione sia etichettata come vera o falsa. I fatti rari e arbitrari sono particolarmente difficili da ricavare dalle regolarità del linguaggio. L'addestramento successivo migliora il comportamento, ma la fluidità espressiva non diventa una garanzia di verità.

Per chi sviluppa, la conseguenza è chiara: le condizioni relative ai prodotti, lo stato degli account e le disponibilità di magazzino devono risiedere in fonti autorevoli che l'applicazione possa consultare. Usare come database ciò che il modello ricorda apre una possibilità di errore evitabile.

Un contesto incompleto o superato lascia un vuoto

Il modello potrebbe non aver mai ricevuto l'informazione che serve al cliente. Un documento caricato può essere obsoleto; una ricerca può restituire l'edizione sbagliata di un prodotto; la consultazione di un account può fallire. Nella spiegazione delle risposte errate di Claude, Anthropic indica esplicitamente l'assenza di informazioni recenti come fonte di confusione.

Occorre distinguere due casi. Se l'assistente inventa una regola, l'errore è nella generazione. Se ripete fedelmente una regola non più in vigore, l'errore è nella gestione delle fonti. Il cliente riceve comunque una risposta sbagliata, ma modificare il prompt non corregge né un documento superato né una query sull'account che non funziona.

La pressione a rispondere premia il comportamento sbagliato

Secondo OpenAI, le valutazioni basate soltanto sull'accuratezza possono premiare chi tenta una risposta rispetto a chi ammette l'incertezza. Le metriche del tuo prodotto possono ripetere lo stesso errore se ogni risposta completata conta come un successo e ogni passaggio a un operatore come un fallimento.

Un cliente che chiede una data di consegna garantita ha bisogno di una stima proveniente da una fonte autorevole. Se il corriere non l'ha fornita, il risultato utile è spiegare con precisione quale informazione manca. Premia questo esito nei test e nella dashboard operativa.

Esempi di allucinazioni degli LLM: quattro errori da intercettare

Classifica gli errori in base a ciò che l'applicazione deve verificare. Le categorie si sovrappongono, ma offrono a un piccolo team punti concreti in cui inserire i controlli.

Fatti inventati: gli esempi delle tesi provengono dal resoconto di ricerca della stessa OpenAI. Conoscere il nome del ricercatore non ha permesso di recuperare il titolo mancante. In ambito aziendale, l'equivalente è attribuire a un prodotto una funzione perché prodotti simili la offrono.

Numeri sbagliati: le date di nascita riportate nello stesso resoconto mostrano perché una data dall'aspetto preciso non costituisce una prova. Nell'applicazione, distingui i numeri privi di riscontro dagli errori di calcolo. Recupera le quantità dai record e calcola i totali con normale codice; chiedi al modello di spiegare il risultato che riceve.

Citazioni inesistenti: il provvedimento del 20 marzo 2024 in United States v. Cohen descrive tre precedenti inesistenti ottenuti da Google Bard, il nome che allora aveva l'assistente generativo di Google. Una delle presunte citazioni era United States v. Figueroa-Florez. Un nome plausibile e una citazione formalmente credibile non corrispondevano a un precedente reale.

Argomenti errati nelle chiamate agli strumenti: gli autori della Berkeley Function Calling Leaderboard mostrano una chiamata con annual_interest_rate: 5 per un tasso richiesto del 5%, accanto alla rappresentazione decimale corretta, 0.05. Entrambi i valori sono numeri. Il solo controllo del tipo non può distinguerli. È un errore nel significato dell'argomento: non ogni chiamata errata a uno strumento equivale a un fatto inventato, ma richiede comunque un controllo prima dell'esecuzione.

Come ridurre le allucinazioni prima che arrivino ai clienti

Affianca alla generazione riscontri e validazione, poi stabilisci che cosa deve fare il sistema quando manca uno dei due. Chi sviluppa è responsabile dei controlli; chi gestisce il servizio è responsabile della fonte autorevole e del percorso di escalation.

Basare le risposte su fonti aggiornate e pertinenti

La retrieval-augmented generation, o RAG, cerca in materiali esterni e fornisce al modello i passaggi pertinenti. Mette a disposizione del redattore il materiale su cui lavorare. La spiegazione di Contextual Retrieval di Anthropic mostra perché è importante conservare il contesto di un passaggio recuperato: un estratto isolato può non indicare l'azienda, il periodo o il soggetto di cui parla.

Per una funzione di assistenza, individua la raccolta autorevole delle regole di servizio e associa metadati su prodotto, area geografica, data di entrata in vigore e accesso. Usa questi campi per filtrare le fonti prima della generazione. Recupera insieme la regola di cancellazione e le relative eccezioni: un paragrafo separato dalle condizioni che lo limitano può giustificare una promessa sbagliata.

Per i dati aggiornati di un account, consulta il database o il servizio dell'applicazione. Una ricerca nei documenti non è un buon modo per sapere se l'ordine di quello specifico cliente è stato spedito. Se la consultazione fallisce, restituisci uno stato di indisponibilità, senza sostituire di nascosto il dato con conoscenze generiche.

Parti da un flusso di recupero semplice. Usa il RAG agentico, in cui il modello può scegliere ulteriori passaggi di recupero, quando le domande richiedono ricerche successive tra più fonti. Anche le ricerche aggiuntive hanno bisogno di regole di arresto e degli stessi controlli sulle fonti.

La domanda diagnostica utile è se al modello siano arrivati i riscontri giusti. Salva gli ID e le versioni delle fonti insieme alla risposta, così un operatore può distinguere un mancato recupero da un'aggiunta priva di supporto.

Fare di «non lo so» uno stato dell'applicazione

La guida di Anthropic per ridurre le allucinazioni consiglia di ammettere l'incertezza, basare il lavoro su citazioni testuali, indicare le fonti ed eliminare le affermazioni prive di riscontro. Traduci queste indicazioni in un contratto di risposta.

Prevedi esiti espliciti per il modello, come answered, needs_clarification e insufficient_evidence. Non obbligarlo a inventare una risposta per compilare un campo richiesto quando la risposta non c'è. L'interfaccia deve trasformare ogni esito in qualcosa di utile: una domanda mirata, una spiegazione del dato mancante oppure il passaggio a un operatore con il contesto recuperato già allegato.

Un'istruzione utile è: «Usa soltanto le regole di servizio e i record dell'account forniti. Se i record non permettono di stabilire la risposta, indica quali informazioni mancano. Non dedurre dai casi simili che il cliente soddisfi i requisiti». Metti alla prova questa istruzione con riscontri mancanti, non soltanto con domande facili.

Un esito sconosciuto è diverso da un rifiuto per motivi di sicurezza, da un timeout di uno strumento o da una richiesta non autorizzata. Mantieni distinti questi stati nei log, così il problema potrà essere risolto dal responsabile appropriato.

Rendere le citazioni verificabili dal codice

Una citazione deve rimandare a materiale che l'applicazione conosce già. Fai assegnare gli ID delle fonti durante il recupero e associali sul server a URL approvati. Evita di chiedere al modello di ricostruire a memoria una bibliografia o un URL di destinazione.

Verifica tre proprietà distinte:

• Esistenza: l'ID citato appartiene al materiale autorizzato fornito per questa richiesta.
• Corrispondenza testuale: il testo citato compare nell'esatta versione della fonte usata per rispondere.
• Supporto all'affermazione: quel passaggio giustifica l'affermazione nella situazione di questo cliente.

I primi due controlli sono semplici da eseguire nel codice. Il terzo richiede una regola di dominio, un campo strutturato affidabile o una verifica separata del legame tra affermazione e riscontro. Trovare la parola «idoneo» in un documento non dimostra che un determinato cliente lo sia.

La documentazione di Anthropic sulle citazioni descrive citazioni collegate ai documenti che aiutano a individuare i riscontri. Un rimando alla fonte facilita il controllo della risposta; non stabilisce se la fonte sia aggiornata, autorevole o interpretata correttamente.

Usare output strutturati e poi validarne i valori

Gli output strutturati vincolano la risposta a uno schema, cioè una definizione dei campi consentiti e dei tipi di valore. Rendono più semplice scrivere i controlli dell'applicazione. La guida di OpenAI agli Structured Outputs avverte esplicitamente che gli output possono comunque contenere errori e che un input incompatibile può indurre allucinazioni se il contratto di risposta non prevede un esito alternativo adeguato.

Prima di eseguire una chiamata a uno strumento, valida l'operazione, gli argomenti obbligatori, le unità, i valori ammessi, l'esistenza dei record e i permessi di chi effettua la richiesta. Determina il tenant e l'utente autenticato nel codice dell'applicazione. Quando opportuno, lascia che il modello scelga tra record autorizzati; non considerare mai un ID cliente fornito dal modello come prova del diritto di accesso.

Anche una chiamata eseguita correttamente richiede una risposta veritiera al cliente. Non dichiarare conclusa una cancellazione se lo strumento ha restituito uno stato in attesa o un errore. Basa il messaggio finale sullo stato restituito. La guida del sito alle protezioni per gli agenti IA approfondisce i limiti da porre alle azioni.

Come rilevare le allucinazioni degli LLM: un controllo da eseguire

Per un campo fattuale ben circoscritto, verifica il valore proposto confrontandolo con un record approvato e componi la risposta nel codice. Per quel campo ottieni una garanzia più solida rispetto a un controllo della coerenza apparente di un testo libero.

L'esempio Python seguente usa dati dimostrativi sulle modalità di assistenza, non le regole di un'azienda reale. Salvalo come verify_answer.py ed esegui python3 verify_answer.py. Usa soltanto la libreria standard e non effettua chiamate API.

# Records must be filtered for the caller's access and policy scope
# before reaching this function. These are illustrative fixtures.
records = {
    "support-policy": {
        "text": "The support channel for this workspace is email.",
        "current": True,
        "fields": {"support_channel": "email"},
    }
}


def validate(result, sources):
    keys = {"status", "field", "value", "source_id", "quote"}
    if not isinstance(result, dict) or set(result) != keys:
        return False
    if result["field"] != "support_channel":
        return False
    if result["status"] == "unknown":
        return all(result[k] is None
                   for k in ("value", "source_id", "quote"))
    if result["status"] != "answered":
        return False
    if not all(isinstance(result[k], str)
               for k in ("value", "source_id", "quote")):
        return False
    source = sources.get(result["source_id"])
    if source is None or source["current"] is not True:
        return False
    quote = result["quote"].strip()
    return (
        bool(quote)
        and quote in source["text"]
        and result["value"]
        == source["fields"].get(result["field"])
    )


proposal = {
    "status": "answered",
    "field": "support_channel",
    "value": "chat",
    "source_id": "support-policy",
    "quote": "The support channel for this workspace is email.",
}

if not validate(proposal, records):
    print("Hold: evidence or value check failed.")
elif proposal["status"] == "unknown":
    print("I cannot confirm the support channel from these records.")
else:
    print(f"Your support channel is {proposal['value']}.")

La risposta proposta, chat, non supera il controllo, anche se la citazione è autentica. Se il valore è email, supera questa verifica circoscritta. È il campo affidabile a determinare la risposta, non la sola corrispondenza della citazione.

Il limite conta: questo validatore non può stabilire se una spiegazione libera sia vera, se il responsabile delle regole di servizio abbia inserito il dato corretto o se il filtro di accesso a monte abbia funzionato. Il ramo unknown verifica che la forma della risposta sia consentita, non che fosse necessario astenersi dal rispondere. Affida queste domande a controlli e valutazioni separati. Per fatti fissi con conseguenze rilevanti, un modello di testo compilato con dati affidabili può eliminare del tutto la necessità di generazione.

Valutazioni che premiano sia le risposte corrette sia gli arresti appropriati

Una valutazione, o eval, è un test ripetibile che confronta l'applicazione con il comportamento atteso. Costruiscila attorno agli errori che colpiscono i clienti ed eseguila quando cambiano il modello, il prompt, l'indice di recupero, lo schema di uno strumento o le regole di servizio.

Registra esiti separati: risposta corretta e supportata, risposta priva di riscontro, astensione appropriata, astensione non necessaria e azione proposta non valida. Una media unica nasconde se il miglioramento derivi da riscontri migliori o soltanto dal rifiuto di rispondere a più domande.

Usa normale codice per verificare valori esatti, appartenenza alle fonti ammesse, campi obbligatori, permessi e risultati degli strumenti. Affida a un modello valutatore le questioni linguistiche, per esempio se un passaggio sostiene una parafrasi, calibrandone le decisioni con esempi revisionati da persone. Un LLM usato come giudice rimane un altro modello fallibile, non una fonte indipendente di fatti.

Promptfoo è uno strumento di valutazione le cui asserzioni valutate da un modello includono l'accuratezza fattuale rispetto a un riferimento e la fedeltà al contesto fornito. La distinzione è utile: una risposta può aderire a un documento superato ed essere comunque sbagliata oggi. Usa la guida a Promptfoo per costruire l'ambiente di test dopo aver definito che cosa significa superare una prova.

In ogni traccia di test conserva insieme la richiesta, i riscontri recuperati, gli argomenti proposti, il risultato dello strumento eseguito e la risposta finale. Quando un caso fallisce, questa registrazione indica dove intervenire. Fai fallire esplicitamente il test in presenza di citazioni mancanti e argomenti non validi, anche se il testo riceve un buon punteggio dal modello valutatore.

Quali promesse vengono sopravvalutate?

Il RAG non rende vera ogni risposta. Un passaggio utile può essere recuperato e interpretato male; un passaggio superato può essere citato alla perfezione. Verifica separatamente il recupero e la generazione e assegna a qualcuno la responsabilità della raccolta delle fonti.

Una finestra di contesto più ampia non sostituisce la selezione delle fonti. Nelle indicazioni sul context engineering, Anthropic avverte che richiamo e precisione possono peggiorare all'aumentare del contesto. Includi la regola pertinente, le sue eccezioni e i dati necessari dell'account. Riversare tutti i documenti nel prompt non è una strategia per mantenerli aggiornati.

Un secondo modello che dice «sembra corretto» non è, da solo, una verifica. Fornisci a chi valuta i riscontri effettivi e un criterio chiaro. Il consenso, in assenza di prove indipendenti, può lasciare intatta la stessa supposizione infondata.

Un JSON valido non certifica la correttezza. Lo schema può richiedere un ID fonte e un argomento numerico; spetta comunque all'applicazione accertare che la fonte esista e che il numero abbia il significato giusto.

I limiti da considerare sono le domande a cui le fonti non possono rispondere, i campi che i controlli non possono verificare e le azioni che non puoi annullare in sicurezza. Non esiste una percentuale universale di allucinazioni capace di dirti se il tuo specifico flusso di lavoro sia pronto.

Una checklist da applicare questa settimana con un piccolo team

Intervieni subito se la tua funzione fa promesse fattuali ai clienti o modifica record aziendali. Se si limita a produrre bozze che una persona responsabile verifica già sulle fonti, parti dal set di valutazione e migliora quella revisione prima di aggiungere un'architettura automatizzata complessa. Una consultazione deterministica che restituisce già campi autorevoli potrebbe non aver bisogno di alcun modello.

Quello che segue è un piano iniziale suggerito, non la prova che una settimana di lavoro basti a garantire l'affidabilità in produzione.

Il primo passo del lunedì è prendere una risposta sbagliata recente e conservarne la traccia completa. Individua se i riscontri fossero assenti, superati, interpretati male o ignorati. Aggiungi il controllo più semplice che intercetta quell'errore, poi trasforma l'incidente in un caso di regressione permanente.

Domande frequenti sulle allucinazioni degli LLM

Per guide pratiche alla costruzione di flussi di lavoro IA affidabili, iscriviti alla newsletter.