Allucinazione nell’IA: che cosa significa e come riconoscere una risposta non supportata
01

Definizione in una frase

Contenido generado que parece plausible, pero no está respaldado por los datos, el contexto o las fuentes disponibles.

02

Definizione: un output privo di riscontro

Nell’intelligenza artificiale, un’allucinazione è un output che presenta informazioni errate, inventate o non supportate dalle evidenze disponibili per il compito. È una definizione operativa: descrive il rapporto tra ciò che il sistema produce, ciò che gli è stato chiesto e le fonti o i dati che avrebbe dovuto utilizzare. Non implica che il sistema abbia un’esperienza cosciente, percepisca qualcosa che non esiste o decida di ingannare chi lo consulta.

Nella ricerca il termine viene usato con sfumature diverse. Alcuni studi si concentrano sulla mancanza di fedeltà a una fonte o a un contesto fornito; altri, su affermazioni false o non verificabili. Per questo è utile specificare quale criterio si sta applicando. Una risposta può contraddire un documento, non trovare riscontro nelle fonti disponibili oppure essere falsa nei fatti. Sono problemi correlati, ma non identici.

La distinzione tra «falso» e «privo di riscontro» è importante. Se una risposta sostiene che un contratto contiene una clausola che non compare nel documento, l’attribuzione non è supportata e può essere controllata confrontandola con il testo. Se invece una risposta propone un’affermazione per la quale non sono state fornite fonti, dal solo contesto potrebbe non essere possibile stabilire se sia falsa: potrebbe essere vera, falsa o indeterminata. La mancanza di prove sufficienti non dimostra automaticamente il contrario.

In questa scheda, «allucinazione» indica un’affermazione presentata come affidabile, ma che non è sostenuta secondo il criterio e le evidenze pertinenti. Il criterio può essere la corrispondenza con un testo, la validità di un calcolo, l’esistenza di una funzione in una libreria o la concordanza con fonti autorevoli. La valutazione dovrebbe indicare che cosa è stato verificato, senza limitarsi a definire vera o falsa un’intera risposta.

03

Come può verificarsi e quale parte del sistema può non funzionare

Un sistema generativo produce una risposta a partire dall’input, dal contesto e dagli schemi appresi. L’output può sembrare coerente pur includendo dettagli che non derivano da questi elementi. Una domanda ambigua, informazioni insufficienti o un’istruzione che presuppone qualcosa di falso possono rendere più difficile fornire una risposta fondata. Questi fattori, da soli, non spiegano tutti i casi e non permettono di dedurre una causa specifica dal solo testo finale.

In un sistema con recupero delle informazioni, o RAG, vengono cercati documenti o estratti da inserire nel contesto del modello. La catena può non funzionare in più punti: la ricerca potrebbe non trovare la fonte pertinente, recuperare materiale inadeguato o presentare estratti distorti; in seguito, il modello potrebbe interpretare male ciò che ha recuperato, aggiungere affermazioni assenti oppure attribuire un’idea alla fonte sbagliata. Un errore nella risposta, quindi, non dimostra di per sé che l’unica causa sia stata il modello generativo.

Possono essere utilizzati anche strumenti esterni, come una calcolatrice, un motore di ricerca, una banca dati o un programma eseguito. Il risultato può essere errato perché lo strumento ha restituito dati inadeguati, è stato usato male, il sistema ha interpretato male il suo output o la risposta finale ha descritto qualcosa che lo strumento non aveva confermato. Quando il percorso è disponibile, valutare il risultato richiede di esaminare l’intera catena.

Nei compiti multimodali entrano in gioco anche immagini, audio o altri formati. Una descrizione può attribuire a un’immagine un dettaglio che non è distinguibile, trascrivere male una parola o presentare un’interpretazione come se fosse un dato osservato. La valutazione dovrebbe basarsi sull’input pertinente e distinguere ciò che è effettivamente presente da ciò che il sistema deduce.

Individuare la possibile origine dell’errore

  1. 01Precisare quale affermazione è in dubbio e a quale domanda il compito richiedeva di rispondere.
  2. 02Esaminare il contesto originale e le fonti recuperate, se presenti.
  3. 03Controllare l’output degli strumenti o l’interpretazione degli input multimodali.
  4. 04Distinguere un errore di ricerca da un errore di interpretazione e da un’affermazione aggiunta senza riscontro.
  5. 05Registrare ciò che è stato possibile verificare e ciò che resta indeterminato.
04

Distinzioni utili per evitare diagnosi imprecise

Una falsità fattuale è un’affermazione che contraddice fatti verificabili. Un’affermazione priva di riscontro è invece un’affermazione per la quale non sono state stabilite evidenze sufficienti nel materiale pertinente. Può essere falsa, ma anche vera e semplicemente non dimostrata nel contesto esaminato. Per rilevare una contraddizione serve un riferimento adeguato; per segnalare l’assenza di riscontro può bastare mostrare che la fonte o il documento che avrebbe dovuto sostenere l’affermazione non la contiene, purché questo sia il criterio del compito.

Un’inferenza non valida compie un passaggio che non consegue dalle premesse, anche quando ogni premessa è corretta. Un errore di attribuzione assegna una frase, una conclusione o un dato a una fonte che non li supporta. Una citazione inesistente è un caso particolarmente verificabile: si può cercare il passaggio, controllarne la posizione e accertare se dica davvero ciò che gli viene attribuito. Il fatto che una citazione abbia un formato convincente non dimostra che sia autentica o pertinente.

Il bias descrive schemi sistematici che possono produrre risultati diseguali o favorire determinate rappresentazioni. Non è sinonimo di allucinazione: una risposta può essere distorta senza inventare un fatto specifico e un’affermazione inventata non dimostra, da sola, l’esistenza di uno schema di bias. La casualità, invece, riguarda la variabilità degli output. Il fatto che due risposte siano diverse non basta a stabilire che una delle due sia un’allucinazione: occorre valutarne il contenuto e le evidenze.

La disinformazione indica spesso la diffusione di informazioni false o fuorvianti e, in alcuni usi, implica l’intenzione di ingannare. Definire «allucinazione» l’output di un modello non prova un’intenzione. Il termine descrive il risultato osservato, non uno scopo umano del sistema. Allo stesso modo, un disaccordo tra fonti non dimostra automaticamente che una risposta sia inventata: può riflettere definizioni diverse, date differenti o una controversia reale.

Un errore di recupero non coincide necessariamente con un’allucinazione nella generazione. Se il sistema trova documenti irrilevanti e risponde in modo fedele a quei documenti, il problema può riguardare il recupero o il corpus, anche se la risposta non è adeguata alla domanda. Se il modello aggiunge dati assenti, si presenta anche un problema di riscontro o fedeltà. Nelle situazioni reali i due tipi di errore possono coesistere.

Che cosa si sta valutando

ConcettoDomanda utileVerifica pertinente
Falsità fattualeL’affermazione contraddice un fatto verificabile?Confrontarla con fonti affidabili e adeguate all’argomento.
Mancanza di riscontroLe evidenze disponibili supportano questa affermazione?Cercare il supporto specifico nel contesto, nel documento o nella fonte.
Inferenza non validaLa conclusione deriva davvero dalle premesse?Esaminare i passaggi del ragionamento e le relative ipotesi.
Errore di attribuzioneLa fonte citata esprime davvero quell’idea?Individuare il passaggio e confrontarne contenuto e portata.
Errore di recuperoSono state trovate fonti pertinenti al compito?Esaminare i risultati, la copertura e la selezione dei documenti.
05

Tre esempi pratici

I casi seguenti sono esempi ipotetici, non incidenti documentati né raccomandazioni professionali. In tutti e tre, il punto decisivo è confrontare un’affermazione specifica con le evidenze adeguate al compito.

Un esempio non sostituisce la verifica del caso concreto: serve a mostrare quali domande porre, quale materiale controllare e come descrivere con precisione i limiti di ciò che si è verificato.

06

Esempio in ambito sanitario: una controindicazione assente dalla fonte

Immaginiamo che una persona consulti un riepilogo di informazioni farmacologiche e che il sistema affermi che un medicinale è controindicato in associazione con un altro. La parola «controindicato» può avere conseguenze importanti: non basta che la frase sembri medica o riporti correttamente il nome di un farmaco. Per verificare l’affermazione occorre identificare il prodotto e la fonte applicabile, individuare l’avvertenza esatta e valutare se la portata dell’affermazione corrisponde al testo.

Se il materiale consultato non menziona quella controindicazione, si può dire che l’affermazione non è supportata da quel materiale. Per concludere che sia falsa occorrerebbe consultare evidenze cliniche pertinenti e aggiornate, senza dedurlo dal silenzio di un singolo estratto. L’esempio non deve diventare un consiglio al paziente: in presenza di una possibile interazione o controindicazione reale, è opportuno rivolgersi a un professionista sanitario o a informazioni autorevoli.

La valutazione può scomporre la risposta: ha nominato correttamente i medicinali? Ha attribuito un’avvertenza a una fonte specifica? La fonte contiene davvero quell’avvertenza? La formulazione esagera una precauzione o presenta una possibilità come un divieto assoluto? Un benchmark medico può aiutare a confrontare sistemi in compiti definiti, ma un risultato ottenuto su un insieme di test non risolve la correttezza di una risposta specifica e non sostituisce una revisione proporzionata al rischio.

07

Esempio sui contratti: attribuire una clausola che non c’è

Immaginiamo uno strumento che riassume un contratto e afferma che contiene una clausola di rinnovo automatico con una scadenza precisa. Il modo più diretto per valutare l’affermazione è cercare nel documento il testo che dovrebbe sostenerla ed esaminare le sezioni pertinenti. Se la clausola non compare, il sistema non dovrebbe presentarla come parte del contratto. Una conclusione appropriata potrebbe essere «non risulta nel documento fornito», più precisa che affermare che non esista in alcun allegato o versione.

Può esserci anche un’interpretazione discutibile senza che la clausola sia stata inventata. Per esempio, una frase ambigua può ammettere più letture giuridiche. In quel caso bisogna distinguere il testo letterale, l’interpretazione del sistema e ogni conclusione legale. Citare il numero di una sezione non dimostra che la sezione esista né che supporti il riepilogo: occorre verificare il riferimento e il suo contesto.

Il caso mostra perché sia importante definire la portata della fonte. Se è stata fornita una sola pagina, l’assenza di una clausola in quella pagina non consente di affermare che manchi nell’intero contratto. Anche se è stato fornito il documento completo, potrebbero esserci allegati o documenti esterni non inclusi. Una valutazione rigorosa indica quale materiale è stato esaminato ed evita di trasformare una ricerca incompleta in una conclusione universale.

08

Esempio di programmazione: descrivere una funzione inesistente

Supponiamo che un assistente descriva una funzione di una libreria e fornisca una chiamata che sembra ragionevole, ma che quella funzione non esista nella versione utilizzata dal progetto. La plausibilità del nome e degli argomenti non basta a considerarla valida. È possibile controllare la documentazione della versione pertinente, ispezionare il codice disponibile o eseguire un test minimo in un ambiente controllato.

La versione e il contesto sono essenziali. Una funzione potrebbe esistere in una versione più recente, in un’estensione o in un modulo diverso. Perciò, constatare che non compare nella documentazione di una versione specifica permette di circoscrivere l’affermazione, ma non dimostra che non sia mai esistita. Occorre inoltre distinguere una spiegazione falsa di un’API da un problema dell’ambiente, una dipendenza mancante o una configurazione errata.

Se la risposta attribuisce il metodo a una documentazione specifica, la citazione può essere verificata separatamente. Se non cita alcuna fonte, è comunque possibile provare il codice, ma il risultato del test fornisce evidenze solo sulle condizioni effettivamente provate. Un frammento che funziona in un caso non garantisce che sia corretto, sicuro o compatibile in tutti i progetti.

09

Come valutare una possibile allucinazione

Non esiste una singola verifica adatta a tutti i tipi di compito. La valutazione inizia scomponendo la risposta in affermazioni verificabili. Una risposta lunga può combinare dati corretti, inferenze ragionevoli, dettagli non supportati e citazioni errate. Giudicarla come un blocco rende più difficile capire che cosa correggere e quali evidenze mancano.

In seguito si definisce il criterio di supporto: la risposta doveva attenersi a un documento? Rispondere sulla base di informazioni aggiornate? Eseguire un calcolo? Descrivere un’immagine? Riassumere risultati recuperati? Ogni obiettivo richiede una verifica diversa. Per una domanda su un documento può essere adeguato confrontare i passaggi; per il codice, un test eseguibile offre evidenze sul comportamento provato; per fatti attuali, può essere necessario consultare fonti aggiornate e autorevoli.

Nei sistemi RAG è utile controllare se ogni affermazione è supportata dagli estratti recuperati e se questi sono pertinenti e sufficienti. Un verificatore di provenienza può aiutare ad associare le affermazioni agli estratti, ma tale associazione non dimostra da sola che l’estratto sia vero, aggiornato o proveniente dalla fonte più adatta. Inoltre, non risolve necessariamente le affermazioni implicite, i ragionamenti complessi o le informazioni assenti dal corpus.

Citazioni e riferimenti vanno convalidati come elementi specifici: occorre verificare che esistano, che appartengano alla fonte indicata e che sostengano l’affermazione con la portata attribuita loro. Una citazione autentica può essere irrilevante, non aggiornata o interpretata fuori contesto. Al contrario, un’affermazione può essere corretta anche se la citazione che la accompagna è attribuita male: si tratta di errori distinti.

La revisione umana è particolarmente importante quando un errore può incidere sulla salute, sui diritti, sulle finanze, sulla sicurezza o su decisioni difficili da annullare. L’intensità della revisione dovrebbe essere proporzionata all’impatto e alla possibilità di verificare il risultato. Per un compito a basso rischio può bastare un test diretto; per una decisione ad alto impatto, la risposta automatizzata non dovrebbe essere trattata come verifica indipendente.

Breve lista di controllo

  1. 01Estrarre le affermazioni specifiche, invece di valutare soltanto il tono generale.
  2. 02Definire quali evidenze ci si aspettava e qual è la portata del compito.
  3. 03Individuare il riscontro originale e verificarne pertinenza, completezza e data, quando rilevante.
  4. 04Verificare separatamente fatti, inferenze, citazioni, calcoli e risultati degli strumenti.
  5. 05Classificare ogni elemento come supportato, contraddetto o non determinato.
  6. 06Indicare i limiti della revisione e intensificare la verifica in base al potenziale impatto.
10

Strategie di mitigazione: utili, ma non risolutive

Recuperare fonti può rendere disponibili evidenze utili alla risposta e facilitare il controllo delle affermazioni. Tuttavia, il recupero non assicura che sia stata trovata la fonte corretta né che il modello la utilizzi fedelmente. I documenti possono essere incompleti, irrilevanti o in disaccordo; il sistema può selezionarli male, interpretarli in modo errato o aggiungere contenuti che non compaiono al loro interno.

Chiedere al modello di dichiarare che non sa o di astenersi quando non è sicuro può ridurre alcune risposte speculative, ma non trasforma l’astensione in un rilevatore infallibile. Il sistema può astenersi anche quando esistono evidenze o rispondere con sicurezza quando non ne ha. L’istruzione è una misura comportamentale, non una verifica indipendente della verità.

I verificatori automatici possono segnalare incoerenze, esaminare citazioni o confrontare una risposta con un insieme di fonti. I risultati dipendono dal compito, dai dati e dal metodo. Un verificatore può non rilevare un errore sottile, condividere i limiti del generatore o accettare una fonte inadeguata. Le valutazioni e i benchmark permettono di misurare comportamenti in condizioni definite, ma non certificano tutte le risposte future in altri contesti.

Una pubblicazione di ricerca di un fornitore di modelli ipotizza che determinati incentivi di addestramento e valutazione possano favorire risposte indovinate rispetto al riconoscimento dell’incertezza. Si tratta di un’ipotesi esplicativa presentata dal fornitore, non di una spiegazione universale né di un consenso indipendente dimostrato per ogni caso. È opportuno distinguere una proposta sulle possibili cause dalle evidenze concrete che consentono di valutare uno specifico output.

11

Concetti correlati e criteri pratici

L’allucinazione è collegata ad altri concetti del glossario, ma non li sostituisce. La scheda sul grounding riguarda il modo in cui una risposta si fonda su informazioni o contesti identificabili; il concetto di RAG descrive un’architettura che recupera materiale da inserire nella generazione. Nessuno dei due termini implica che le affermazioni siano necessariamente corrette.

L’incertezza riguarda i limiti di ciò che è possibile determinare o il grado di fiducia con cui si sostiene una conclusione. Esprimerla chiaramente può essere utile, ma una frase dubitativa non garantisce che la risposta sia ben calibrata. Il fact-checking è il processo di confronto delle affermazioni con le evidenze: può individuare errori, ma la sua qualità dipende dalla scelta delle fonti e dalla domanda valutata. La pagina dell’indice del glossario dedicata alle allucinazioni permette di trovare queste voci correlate e di distinguerne gli approcci.

Come criterio pratico, prima di accettare una risposta chiediti: quale affermazione specifica mi serve? Quale fonte o prova potrebbe confermarla? La fonte è pertinente al caso e alla data? La citazione supporta davvero ciò che viene affermato? Quali aspetti restano indeterminati? Se non è possibile rispondere a queste domande, è più preciso dire che la risposta non è verificata che assegnarle un’etichetta definitiva.

Per documentare una revisione, registra l’affermazione, il materiale esaminato, il metodo di verifica e il risultato. Usa categorie circoscritte: supportata dalla fonte esaminata, contraddetta da essa, non supportata in quel materiale oppure non valutabile con le evidenze disponibili. Specifica anche la portata, per esempio «nel documento fornito» o «nella versione testata». Questa formulazione permette di correggere gli errori senza affermare più di quanto la verifica dimostri.

La regola finale è semplice: fluidità, sicurezza del tono, ricchezza di dettagli e citazioni dall’aspetto formale non equivalgono a evidenza. Una fiducia ragionevole deriva da una verifica adeguata al compito, condotta con fonti pertinenti e limiti espliciti.

Criteri per decidere come procedere

SituazioneAzione pratica
L’affermazione ha una fonte specificaVerificare che la fonte esista, sia pertinente e supporti esattamente la portata dell’affermazione.
La risposta riassume un documentoConfrontare le affermazioni con tutto il documento disponibile e annotare i limiti.
La risposta dipende da uno strumento o da una versioneRegistrare strumento, dati e versione; ripetere un test appropriato.
Le evidenze disponibili sono insufficientiContrassegnare la conclusione come indeterminata e cercare altre fonti adeguate.
Un possibile errore può causare un danno rilevanteRichiedere una revisione esperta e non usare la risposta automatizzata come unica base.
12

Esempi rapidi

13

Concetti correlati

14

Fonti consultate