Perché le allucinazioni LLM non si risolvono col prompting: rappresentazione distribuzionale e limiti architetturali

Il 30 aprile 2026 ho interrogato Claude Opus 4.7 nella mia pipeline personale di automazione AI su un fatto specifico: la CVE-2025-59528 di Flowise, CVSS e data di pubblicazione. Il modello mi ha risposto con confidenza "CVE-2025-59528, CVSS 9.8, pubblicata a settembre 2025". Tutto plausibile. Tutto sbagliato. La CVE è reale, ho scritto io un articolo sul suo exploit (flowise-cve-2025-59528-rce-poc-mitigation-waf), CVSS 10.0, pubblicata il 14 aprile 2026. Il modello ha inventato valori diversi con la stessa naturalezza con cui avrebbe ritrovato quelli corretti. Questo articolo diagnostica perché le allucinazioni persistono nel 2026, perché il prompting non le elimina, e quali validation esterne funzionano in produzione italiana.

Il mito della soluzione vicina e il paper OpenAI del 2025

Nel 2023 Sam Altman aveva promesso che OpenAI avrebbe risolto le allucinazioni entro due anni. Nel settembre 2025, in un paper dal titolo Why Language Models Hallucinate di Kalai, Zhang, Nachum (OpenAI) e Vempala (Georgia Tech), OpenAI stessa ha fornito un framework matematico che mostra perché le allucinazioni sono in parte strutturalmente inevitabili.

Il paper identifica tre fattori matematici. Primo: epistemic uncertainty, quando l'informazione è rara nei dati di training, la probabilità di errore predittivo è non-nulla. Secondo: model limitations, task che eccedono la capacità rappresentazionale dell'architettura corrente producono errori. Terzo: computational intractability, anche un sistema ipoteticamente superintelligente non può risolvere problemi cryptographicamente hard.

Ma il contributo più operativo del paper riguarda gli incentivi di training. Nove benchmark su dieci tra i più usati (MMLU-Pro, GPQA, SWE-bench) usano grading binario che penalizza "non lo so" e premia risposte sbagliate ma confidenti. I modelli imparano a "indovinare" invece di astenersi. La soluzione proposta non è tecnica, è socio-tecnica: cambiare il modo in cui i benchmark scoraggiano l'ammissione di incertezza.

Il benchmark AA-Omniscience: solo 4 su 40 modelli meritano fiducia

A novembre 2025 Artificial Analysis ha rilasciato AA-Omniscience, il primo benchmark che misura simultaneamente knowledge recall e calibrazione (astensione quando incerti). 6.000 domande, 42 topic economici, 6 domini (Business, Humanities, Health, Law, Software Engineering, Science/Math). Scoring da -100 a +100: risposte corrette premiate, risposte sbagliate penalizzate pesantemente, astensioni neutrali.

Al lancio (novembre 2025): solo 4 su 40 modelli testati hanno ottenuto un Omniscience Index positivo. 36 modelli su 40 sono più propensi a dare una risposta sbagliata confidente che una corretta su domande difficili di knowledge. Claude 4.1 Opus al 36% accuracy ma con il più basso hallucination rate (48%) ha ottenuto il punteggio più alto (4,8). GPT-5 high con 39% accuracy ma 81% hallucination rate è stato penalizzato severamente.

Aggiornamento aprile 2026: GPT-5.5 xhigh ha accuracy record 57% ma hallucination rate 86%. Claude Opus 4.7 con Adaptive Reasoning max effort ha hallucination rate 36%, il più basso nella classe. Gemini 3.1 Pro Preview guida la classifica Omniscience con score 33, Claude Opus 4.7 secondo con 26.

La lezione operativa è brutale: se il tuo progetto tratta domande di fatto su cui sbagliare ha conseguenze, i modelli più "potenti" non sono i più affidabili. Accuracy alta + hallucination rate alto = risposte sicure su ciò che sanno e risposte sbagliate ugualmente sicure su ciò che non sanno.

Perché le allucinazioni non sono eliminabili con prompting migliore

Connessione con l'architettura Transformer (vedi l'articolo dentro un Transformer): i fatti sono distribuiti sparsamente tra i neuroni dell'MLP, non memorizzati in modo discreto. Quando il modello predice la prossima parola, la distribuzione di probabilità viene calcolata su base contestuale; se il training data contiene pochi esempi del fatto X, la probabilità di predire la sequenza corretta per X è bassa e la predizione si disperde su alternative plausibili.

Il prompting non cambia i pesi. Puoi dire al modello "rispondi solo se sei sicuro, altrimenti dì non lo so" e ottenere miglioramento marginale (5-15%), ma non eliminazione. Il modello non ha un'introspezione calibrata sulla propria certezza: la "confidenza" che tu percepisci nel suo output è un artefatto stilistico del training su risposte assertive, non un segnale di conoscenza reale.

Se vuoi approfondire come progetto pipeline con validation esterna obbligatoria per output critici, nel mio hub dedicato all'automazione AI trovo articoli tecnici con metodologia applicata e perimetro dichiarato.

Diagnosi: tre categorie di allucinazione con contromisure diverse

Non tutte le allucinazioni sono uguali. Nella mia sandbox classifico tre categorie con pattern distinti.

Categoria A: fatti dominio-specifici con pochi esempi nel training. Il modello non sa la risposta ma genera qualcosa di plausibile. Classico: CVE recenti, normative specifiche italiane, nomi di persone non famose, numeri specifici di press release. Contromisura: RAG obbligatorio con verifica su fonte primaria al momento della query.

Categoria B: confabulazione su fatti contraddittori nel training. Il modello ha visto informazioni inconsistenti nel training (un fatto ripetuto in molte fonti con valori diversi). Contromisura: validation incrociata con più fonti, preferenza per fonti autoritative (arxiv, documenti ufficiali).

Categoria C: over-confidence su inferenze plausibili. Il modello deduce da pattern simili e presenta la deduzione come fatto. Classico: "se la CVE è del 2025, sarà stata pubblicata in autunno" (plausibile ma indeducibile). Contromisura: prompt engineering che forza esplicitazione delle fonti ("per ogni claim, indica dove l'hai visto").

Pattern di validazione esterna che funzionano in produzione

Cinque tecniche che uso nei progetti dove l'accuratezza è critica.

Tecnica 1: retrieval-first, generation-second. Mai far rispondere il modello da sua conoscenza su fatti specifici. Sempre retrieval mirato, poi passaggio della fonte al modello che genera. Il modello è un template-filler, non un knowledge base.

Tecnica 2: citation verification. Ogni risposta del modello con citazione esplicita (URL, paper, documento) viene passata a un verifier che fa fetch dell'URL e controlla che contenga la citazione. Se non contenuta, claim rifiutato.

Tecnica 3: cross-model agreement. Per domande critiche, interroga due modelli diversi (es. Claude + GPT-5) con lo stesso prompt. Se le risposte divergono su un fatto specifico, flag per review umano.

Tecnica 4: confidence calibration via sampling. Per ogni domanda chiedi 10 risposte a temperature 0,7. Se la risposta modale è stabile (es. >80% dei sample dicono la stessa cosa), confidenza alta. Se le risposte divergono, il modello non sa la risposta, indipendentemente dalla sua assertività.

Tecnica 5: astensione forzata via prompt hardening. System prompt che dichiara esplicitamente: "se il fatto richiede una data, un numero, un nome specifico che non trovi in nessuna fonte fornita nel contesto, rispondi letteralmente 'INFORMAZIONE NON DISPONIBILE'". Riduce ma non elimina.

Il paradosso dei reasoning model: ragionando di più, allucinano di più

Dato contro-intuitivo dal paper OpenAI: o1 hallucinava il 16% delle volte su task di riassunto, o3 il 33%, o4-mini il 48%. I modelli di reasoning, nella loro versione "thinking", sono PIÙ propensi a hallucinare, non meno. Perché?

L'ipotesi più accreditata è che il reasoning trace introduca opportunità di confabulazione: il modello pensa a voce alta, produce inferenze intermedie, e queste inferenze diventano "fatti" che vengono usati nella risposta finale. Se un passaggio intermedio è sbagliato, la risposta costruita sopra è sbagliata. Il reasoning lungo aumenta la superficie di errore cumulativo.

Conseguenza operativa: per task di knowledge retrieval puro (domande di fatto su informazioni specifiche), il modello senza thinking può essere più affidabile del modello con thinking. Il thinking vale per task di ragionamento strutturale, non per il recupero di fatti dalla memoria parametrica del modello. Ho coperto il trade-off in dettaglio nell'articolo chain-of-thought quando usare.

Domini ad alto rischio di allucinazione nel contesto italiano

Nella mia esperienza con clienti italiani, cinque domini hanno tassi di allucinazione notevolmente alti e richiedono contromisure dedicate.

Normativa italiana specifica. Articoli di legge, date di entrata in vigore, soglie numeriche aggiornate. I modelli inventano numeri di articolo e date con sicurezza. Contromisura: Normattiva.it come fonte via RAG, mai affidare a memoria del modello.

Codici fiscali e partite IVA. Il modello genera sequenze plausibili ma inventate. Contromisura: validation con algoritmo di check-digit, mai considerare un codice come valido solo perché il modello lo produce.

CVE security specifiche. Numeri CVE, CVSS, date di patch. Rate di allucinazione elevato. Contromisura: nvd.nist.gov come fonte primaria obbligatoria.

Dati fiscali/contabili. Aliquote IVA per regimi speciali, ritenute, bolli. Contromisura: rule engine deterministico scritto da consulente fiscale, LLM solo come orchestratore.

Informazioni su persone specifiche. Ruoli, carriere, affiliazioni di figure pubbliche non celebri (CEO di PMI, manager, ricercatori italiani). Rate di allucinazione altissimo. Contromisura: LinkedIn/siti ufficiali come fonte, mai trust su memoria del modello.

Cosa NON funziona: quattro contromisure popolari ma inefficaci

Quattro pattern che vedo spesso nei progetti e che non risolvono il problema.

"Rispondi solo se sei sicuro, altrimenti dì non lo so". Miglioramento marginale (5-15%). Il modello non ha calibrazione robusta della propria certezza. Il prompting riduce ma non elimina.

Temperature 0 per deterministic output. Riduce la variance delle risposte ma non l'accuratezza. Il modello converge sulla sua risposta più probabile, che può essere la più probabilmente sbagliata.

"Cita sempre le fonti". Senza verification, il modello inventa URL plausibili. Ho visto modelli citare arxiv ID inesistenti. La citazione senza verification è peggio dell'assenza di citazione.

Fine-tuning su dati propri. Rischia di amplificare le allucinazioni: il modello impara a rispondere con confidenza anche su domande per cui non aveva dati. Fine-tuning senza curation del dataset è un boomerang.

Edge case: allucinazioni difficili da rilevare

Tre pattern che sfuggono a validation naive.

Allucinazione coerente. Il modello inventa un fatto e lo usa coerentemente in tutta la risposta. Nessuna inconsistenza interna. Rilevabile solo con cross-check esterno.

Confabulazione semi-vera. Il modello cita una fonte reale ma attribuisce a lei un'affermazione che non contiene. Citation verification la rileva, ma solo se sei disposto a fare il fetch.

Allucinazione indotta dal prompt. Domande poste con premesse false ("quando Anthropic ha acquisito OpenAI?") portano il modello a confermare la premessa inventando dettagli. Richiede reasoning esplicito: il modello deve essere prompted a rifiutare la premessa falsa.

Un test pratico per il tuo progetto

Una checklist in cinque punti che applico prima di firmare un progetto LLM dove l'accuratezza è critica.

• Il sistema si affida alla memoria fattuale del modello per risposte verificabili? Se sì, red flag.
• Ogni risposta che cita dati specifici ha un passaggio di retrieval? Se no, red flag.
• Esiste un validation layer che controlla output contro fonti esterne? Se no, red flag.
• L'astensione ("non lo so") è un output legittimo del sistema o è stata soppressa? Se soppressa, red flag.
• C'è monitoring del rate di risposte verificabili vs rate di errori in produzione? Se no, nessuno sa quanto sta sbagliando il sistema.

Le allucinazioni non sono un bug risolvibile, sono una proprietà statistica strutturale dei LLM. La dimostrazione teorica è nel paper OpenAI 2025, la dimostrazione empirica è in AA-Omniscience 2025-2026 (36/40 modelli più propensi a sbagliare che a sapere), la dimostrazione pratica è la bolletta del cliente che paga per risposte sbagliate in produzione. Se hai un progetto LLM dove le allucinazioni hanno conseguenze legali, economiche o reputazionali, e vuoi progettare una pipeline che le contenga invece di fingere che non esistano, il modulo di preventivo gratuito ti risponde in due minuti se il caso rientra nel mio ambito. Il modello non ti dirà mai "non lo so" spontaneamente; devi costringerlo a dirlo con architettura, non con preghiere, e ogni consulente che ti propone di "ridurre le allucinazioni con il prompt engineering" sta sottovendendo la complessità del problema o sopravendendo la propria offerta commerciale.

Nota finale sul costo economico delle allucinazioni

Un ultimo punto che raramente emerge nelle conversazioni commerciali ma è centrale in audit post-incident. Un sistema AI in produzione che sbaglia il 10% delle risposte senza saperlo costa più di uno che sbaglia il 20% dichiarandolo. Il primo alimenta fiducia fino al disastro catastrofico (decisione presa su informazione sbagliata, contratto firmato su dati inventati, diagnosi proposta su fatto non verificato). Il secondo è usato con cautela, con human-in-the-loop, con escalation predefinita.

La calibrazione dell'astensione è più importante dell'accuracy assoluta. Un modello che dice "non lo so" nel 30% dei casi ma è corretto nel 95% del restante 70% è più utile in produzione di uno che risponde sempre ma sbaglia nel 25%. Su questo le system card raramente si esprimono, e i benchmark binari standard puniscono il pattern virtuoso. AA-Omniscience è l'eccezione rara di un benchmark che premia la calibrazione; finché il mercato non lo richiede sistematicamente, i vendor continueranno a ottimizzare accuracy anche a costo di calibrazione scadente.

Per le PMI italiane questo ha un'implicazione commerciale precisa: quando valuti un vendor AI, chiedi il rate di astensione, non solo l'accuracy. Se il fornitore non sa rispondere, il modello proposto probabilmente risponde sempre e sbaglia senza saperlo, ed è quello il rischio che entra nella tua operatività di business ogni volta che l'integrazione AI va in produzione senza validation esterna progettata a monte. Chiedere i numeri e ottenerli è il minimo sindacale di qualsiasi due diligence su un vendor AI nel 2026.