Perché confrontare le allucinazioni e non solo ‘modelli buoni e cattivi’
Quando qualcuno chiede quali siano i limiti delle allucinazioni nei LLM, la risposta utile non è un sì o un no, ma un confronto pratico: quale modello allucina meno a seconda del compito, con quali tecniche si mitiga e a quale costo. Secondo la documentazione ufficiale dei principali fornitori e gli studi del settore sulla valutazione della fedeltà (faithfulness), nessuno dei modelli attuali elimina l’allucinazione; la riducono in domini specifici e la spostano in altri.
Questo articolo confronta opzioni popolari di mitigazione e modelli da una prospettiva operativa: cosa funziona, cosa no e dove i team tendono a ricevere sorprese. Non è un elenco delle ‘migliori IA’; è un confronto tra approcci con i loro limiti reali.
Criteri di confronto che discriminano davvero
1. Tasso di affermazioni non supportate (fedeltà)
La metrica chiave non è ‘ci azzecca?’ ma ‘inventa fatti che non sono nella fonte?’. Nei compiti di riassunto con contesto lungo, i modelli grandi con migliore aderenza al contesto tendono a generare meno affermazioni non supportate rispetto ai modelli piccoli, ma perdono questo vantaggio quando la domanda richiede conoscenza esterna non inclusa nel prompt. Confrontare modelli senza fissare lo scenario (contesto chiuso vs. domanda aperta) produce conclusioni fuorvianti.
2. Calibrazione dell’incertezza
Un modello calibrato esprime dubbio quando non sa. In pratica, quasi tutti i modelli commerciali popolari sono mal calibrati sulle domande di nicchia: rispondono con la stessa sicurezza a un dato verificabile e a uno inventato. Secondo gli studi del settore, la fiducia verbale del modello non correla in modo affidabile con l’accuratezza, il che invalida la strategia di ‘chiedere se è sicuro’.
3. Costo e latenza della mitigazione
RAG, verifica con ricerca web, autocritica e voto multiplo riducono le allucinazioni, ma ogni livello aggiunge latenza e costo. Il confronto onesto include il prezzo per risposta affidabile, non solo il prezzo per token.
Confronto tra approcci popolari di mitigazione
RAG (generazione aumentata dal recupero)
Cosa fa bene: ancora le risposte a documenti propri. Nelle domande su normative interne, manuali o cataloghi, riduce drasticamente l’invenzione di dati quando il retriever porta il frammento corretto.
Dove fallisce: se il retriever non trova il frammento, il modello non sempre dice ‘non lo so’; a volte riempie con conoscenza parametrica. Allucina anche nelle citazioni: inventa numeri di pagina o mescola due documenti. Un errore comune che si vede solo con l’uso reale è che il RAG su documenti duplicati o versioni obsolete produce risposte coerenti ma non aggiornate, e il team se ne accorge tardi perché la risposta ‘suona bene’.
Verifica con ricerca web in tempo reale
Cosa fa bene: migliora l’attualità e permette di citare le fonti. Utile per domande su prezzi, lanci o notizie.
Dove fallisce: introduce dipendenza dalla qualità dei risultati di ricerca. Se la fonte è un forum o un blog speculativo, il modello può presentare un’affermazione dubbia come fatto con link incluso, il che paradossalmente aumenta la credibilità percepita dell’errore. Non serve per domande controfattuali o ipotetiche, dove non c’è fonte da verificare.
Autocritica e catene di verifica
Cosa fa bene: chiedere al modello di rivedere la propria risposta rileva errori aritmetici e contraddizioni interne nei compiti strutturati.
Dove fallisce: l’autocritica condivide gli stessi punti ciechi della generazione. Un modello che non conosce un dato non sa di non saperlo nemmeno quando lo rivede, e può ‘confermare’ la propria invenzione. Funziona meglio con verifica esterna (calcolatrice, database) che con l’introspezione.
Risposte con astensione forzata
Cosa fa bene: istruire il modello a rispondere ‘non disponibile’ quando non ci sono prove riduce le affermazioni false in domini circoscritti.
Dove fallisce: aumenta i falsi negativi. Nel servizio clienti, un eccesso di astensione degrada l’esperienza tanto quanto una risposta errata. La soglia va calibrata per caso d’uso, e non esiste un valore universale.
Confronto per tipo di modello: grandi vs. piccoli vs. specializzati
Modelli grandi di uso generale
Tasso di allucinazione inferiore nella conoscenza comune e migliore rispetto delle istruzioni complesse. Tuttavia, la loro fluidità è un’arma a doppio taglio: inventano con più eleganza. In domini molto tecnici o recenti, la loro conoscenza parametrica diventa obsoleta e riempiono i vuoti con plausibilità.
Modelli piccoli e distillati
Più economici e veloci, e sufficienti per compiti di estrazione con contesto chiuso. Il loro limite è la generalizzazione: fuori dal formato per cui sono stati messi a punto, il tasso di invenzione sale. Non consigliabili per domande aperte senza RAG.
Modelli specializzati o messi a punto con dati propri
Possono ridurre le allucinazioni in un dominio ristretto, ma il fine-tuning non garantisce la fedeltà: insegna stile e formato più che fatti. Un modello messo a punto con dati incompleti impara a rispondere con sicurezza all’interno di quel dominio, inclusi i vuoti. La valutazione con domande fuori distribuzione è obbligatoria prima del deployment.
Ciò che il confronto non risolve
Nessun approccio elimina l’allucinazione nei compiti generativi aperti. La ragione è strutturale: il modello predice testo plausibile, non verifica la verità. Le mitigazioni riducono la probabilità di errore verificabile, ma non la eliminano. Qualsiasi promessa di ‘zero allucinazioni’ va trattata con scetticismo.
Inoltre, il confronto tra modelli scade rapidamente: le versioni cambiano e i risultati delle valutazioni pubbliche non sempre si replicano in domini interni. L’unico confronto valido per un team è quello che fa con il proprio corpus e le proprie domande.
Come costruire un confronto utile in pratica
Riunire un insieme da 50 a 100 domande reali del business, con risposta nota e con distrattori plausibili. Eseguire ogni opzione (modello + tecnica) sullo stesso insieme e misurare tre cose: accuratezza, affermazioni non supportate e tasso di astensione. Rivedere manualmente un campione delle risposte, perché anche le metriche automatiche di fedeltà si sbagliano.
Un dettaglio che emerge solo con l’esperienza: le allucinazioni più pericolose non sono quelle evidenti, ma quelle che mescolano un dato corretto con uno inventato nella stessa frase. Il revisore umano tende a validare l’intera frase perché la prima metà è vera. La revisione va fatta affermazione per affermazione, non risposta per risposta.
Raccomandazione per scenario
Per il servizio clienti con base documentale, RAG con astensione calibrata e revisione delle citazioni. Per la ricerca e l’attualità, ricerca web con esigenza di fonte primaria e avvertenza esplicita all’utente. Per l’estrazione di dati strutturati, modelli piccoli con validazione tramite regole e verifica esterna. Per i contenuti creativi, dare per scontato che i fatti non siano affidabili e separare la generazione dalla verifica umana.
La conclusione del confronto è scomoda ma onesta: l’opzione migliore non è il modello con meno allucinazioni in astratto, ma la combinazione che rende visibile l’errore prima che causi danni.