Cosa sono le allucinazioni e perché si presentano
Un’allucinazione in un LLM è la generazione di informazione che suona credibile, ma è fattualmente non vera o ingiustificata. Non è un „errore” nel senso di un guasto di sistema — è una conseguenza del modo in cui funzionano i modelli linguistici. L’LLM non „sa” come un database — predice il prossimo token più probabile, basato sulla statistica dell’addestramento. Quando nel prompt compare una domanda per cui il modello non ha buona copertura nei dati di training, genera la risposta „dal suono più probabile”. Spesso questa risposta è corretta. A volte — no.
Scenari tipici di allucinazione nelle applicazioni business:
- Citazione di sentenze tribunali inesistenti o paragrafi di leggi inesistenti nella consulenza legale
- Invenzione di nomi di funzioni, classi o librerie nella generazione di codice
- Fornire statistiche o date errate nei report
- Inventare contatti, indirizzi, numeri di telefono
- Mescolare fatti riguardanti aziende o persone diverse con nomi simili
Livello 1 — Grounding (RAG)
La singola tecnica più efficace di riduzione delle allucinazioni è il grounding — fornire al modello documenti o dati concreti come contesto, da cui attingere le risposte. RAG classico (Retrieval-Augmented Generation):
- Domanda dell’utente → ricerca dei frammenti documentali più rilevanti (vector search in database pgvector / Qdrant / Milvus)
- Frammenti + domanda → prompt con istruzione „rispondi esclusivamente sulla base dei documenti seguenti”
- Risposta del modello → verifica che contenga citazioni/riferimenti alle fonti
RAG riduce le allucinazioni tipicamente del 60-80% in applicazioni tipo „rispondi a domande sulla nostra knowledge base”. Non le elimina del tutto — il modello può ancora „interpretare” i documenti in modo non autorizzato. Da qui la necessità di livelli successivi.
Livello 2 — Self-consistency ed ensemble
La self-consistency è una tecnica che consiste nel porre la stessa domanda più volte (o a più modelli diversi) e confrontare le risposte. Quando le risposte sono coerenti — alta fiducia. Quando differiscono — segnale che il tema è incerto.
Variante pratica: chiedi a Claude Sonnet, Llama 70B e Bielik la stessa domanda. Se tutti e tre restituiscono lo stesso numero, data, fatto — probabilmente corretto. Se differiscono — escalation a un essere umano o a un modello più costoso (Opus). Questo pattern, implementato nel routing LLM a 8 livelli, combina la riduzione del costo con il miglioramento dell’affidabilità.
Livello 3 — Evaluation pipelines
Una implementazione produttiva di LLM senza evaluation pipeline è come scrivere codice senza test. Metriche concrete:
- Faithfulness — se la risposta deriva dai documenti forniti. Misurata da un secondo modello AI (LLM-as-judge) o da librerie tipo RAGAS, deepeval.
- Answer relevance — se la risposta affronta la domanda dell’utente.
- Context precision — se i migliori frammenti sono stati restituiti dal retrieval (qualità del vector search).
- Groundedness score — percentuale di affermazioni nella risposta per cui si può indicare la fonte nel contesto.
Ogni nuovo build di un’applicazione basata su LLM dovrebbe attraversare un set di 50-500 domande di valutazione con ground truth noto. Se la faithfulness scende sotto il 90% — deployment bloccato.
Livello 4 — Guardrails e validazione output
I guardrails sono regole che validano l’output LLM prima della consegna all’utente. Esempi:
- Schema validation — l’output deve rispettare uno schema specifico (JSON Schema, Pydantic). Allucinazioni del tipo „campi inventati” sono rilevate meccanicamente.
- Forbidden patterns — rilevamento e blocco di pattern inaccettabili (PII senza mascheramento, dati finanziari fuori contesto, contenuti potenzialmente dannosi).
- Citation enforcement — ogni affermazione fattuale deve avere una citazione della fonte. Se il modello non cita — la risposta viene rifiutata.
- Numeric range validation — i numeri nell’output verificati per sensatezza (es. prezzo > 0, data ≤ oggi, percentuale nell’intervallo 0-100).
- Cross-reference check — confronto dell’output con una base di fatti (es. KRS, dizionario di citazioni di leggi).
Librerie: Guardrails AI, NeMo Guardrails, instructor (per schema enforcement). Implementazione propria spesso più semplice ed economica da mantenere.
Livello 5 — Human-in-the-loop
Per applicazioni ad alto rischio (decisioni legali, mediche, finanziarie, HR) il livello human-in-the-loop è indispensabile. I modelli AI non prendono la decisione finale — supportano l’essere umano. Pattern concreti:
- Draft + review — l’AI genera la prima versione del documento/risposta, l’essere umano verifica e accetta prima dell’invio.
- Confidence threshold — risposte a bassa confidence (da self-consistency o explicit confidence asking) escalate automaticamente all’essere umano.
- Random sampling QA — il 5-10% di tutte le risposte LLM viene auditato manualmente, indipendentemente dalla confidence — metrica di qualità di base nel tempo.
- Feedback loop — l’utente può segnalare una risposta errata; il sistema impara e migliora retrieval, prompt, parametri.
Misurazione — come sapere che la riduzione funziona
Metriche produttive concrete che vale la pena monitorare:
- Hallucination rate — percentuale di risposte classificate come allucinazione in valutazione manuale (sampling). Obiettivo: sotto il 2% per applicazioni business-critical.
- User feedback rate — percentuale di utenti che hanno segnalato la risposta come errata.
- Escalation rate — percentuale di richieste escalate all’essere umano. Troppo bassa (sotto 5%) — il sistema probabilmente salta i casi incerti. Troppo alta (sopra 30%) — il sistema non fornisce valore di automazione.
- Faithfulness score nei test di regressione — trend mensile.
- Time-to-correction — dal rilevamento dell’allucinazione all’implementazione della correzione (retrieval migliore, nuovo guardrail, fine-tuning).
Conclusioni per i decisori
Le allucinazioni sono gestibili — richiedono investimento in architettura difensiva a più livelli. Le aziende che implementano LLM senza questa architettura, prima o poi incontreranno un incidente serio (pubblicazione di informazione errata al cliente, decisione errata basata su dati allucinati, danno reputazionale). Il costo di costruzione dello stack difensivo completo (RAG + evaluation + guardrails + human-in-the-loop) è tipicamente il 15-30% del costo della sola implementazione LLM — ed è un investimento assolutamente necessario per le applicazioni produttive. Le conseguenze dell’omissione sono asimmetriche: basso costo dell’omissione nel 95% dei casi, catastrofico nel 5%.