💬 NLP

Library Hallucinations in LLM-Generated Code: A Risk Analysis Grounded in Developer Queries

Questo articolo presenta il primo studio sistematico di come le variazioni realistiche dei prompt degli sviluppatori, come errori di ortografia e nomi inventati, attivino allucinazioni di librerie nel codice generato da LLM, rivelando vulnerabilità significative e introducendo il benchmark LibHalluBench per abilitare la valutazione e la mitigazione riproducibili di tali rischi.

Autori originali: Lukas Twist, Jie M. Zhang, Mark Harman, Helen Yannakoudakis

Pubblicato 2026-05-20

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Lukas Twist, Jie M. Zhang, Mark Harman, Helen Yannakoudakis

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di avere un assistente molto talentuoso, sicuro di sé, ma leggermente distratto, che è un esperto nella scrittura di codice informatico. Gli chiedi di costruire uno strumento specifico e lui inizia felicemente a digitare. Tuttavia, questo assistente ha un'abitudine pericolosa: a volte, quando non conosce il nome esatto dello strumento di cui ha bisogno, ne inventa uno. Crea una libreria (una collezione predefinita di codice) che non esiste, ma la scrive con tale sicurezza che potresti non renderti conto che è falsa finché non provi a usarla e si rompe.

Questo documento è un'analisi approfondita del perché questo assistente inventa questi strumenti falsi, in particolare quando gli si danno istruzioni leggermente diverse o si commettono piccoli errori.

Ecco la sintesi delle loro scoperte utilizzando semplici analogie:

1. La trappola del "Viaggio nel Tempo"

I ricercatori hanno scoperto che se chiedi al tuo assistente uno strumento "del 2025" (un anno che non è ancora arrivato o che è oltre il suo addestramento), l'assistente diventa molto nervoso e inizia a allucinare selvaggiamente.

L'analogia: Immagina di chiedere a un bibliotecario un libro pubblicato nel futuro. Invece di dire "Non ce l'ho", il bibliotecario potrebbe inventare un titolo, una copertina e una sintesi che sembrano perfetti ma che non esistono.
Il risultato: Quando viene chiesto di librerie "del 2025", fino all'85% delle volte l'assistente ha inventato una libreria falsa. Sono terribili nel conoscere la propria "data di taglio della conoscenza" (la data in cui hanno smesso di apprendere).

2. La trappola del "Refuso" (Ortografia disattenta)

Se sbagli accidentalmente a scrivere il nome di una libreria reale, l'assistente spesso non ti corregge. Invece, insiste e finge che la versione errata sia reale.

L'analogia: Immagina di chiedere a uno chef "Spagetti" (manca la 'h'). Invece di dire "Intendevi Spaghetti?", lo chef potrebbe semplicemente prendere una scatola etichettata "Spagetti" da uno scaffale che ha inventato, o peggio, potrebbe inventare un nuovo piatto chiamato "Spagetti" che non esiste.
Il risultato:
- Un refuso di una lettera (come numpi invece di numpy) ha causato l'uso di librerie false nel 26% dei casi.
- Un nome di libreria falso (qualcosa che sembra reale ma non lo è, come "GaussianTools") è stato accettato e utilizzato fino al 99% dei casi. L'assistente è così desideroso di accontentare che userà uno strumento falso piuttosto che dirti che non esiste.

3. La trappola dell'"Aggettivo" (Cosa non funziona)

Interessantemente, se chiedi una libreria che sia "veloce", "facile" o "moderna", l'assistente di solito ignora quelle parole e sceglie semplicemente una libreria reale standard che conosce.

L'analogia: Se chiedi un "auto veloce", l'assistente ti dà semplicemente una Toyota standard. Non inventa un "super-auto-veloce-che-vola" perché sa che quegli aggettivi sono vaghi.
Il risultato: Aggettivi come "veloce" o "leggero" raramente hanno causato allucinazioni. Il pericolo deriva da vincoli specifici (come le date) o errori (come i refusi).

4. La trappola del "Ragionamento" (Pensare troppo)

I ricercatori hanno provato a risolvere il problema chiedendo all'assistente di "pensare passo dopo passo" o di "verificare i fatti" prima di rispondere.

L'analogia: È come dire a uno studente nervoso: "Fai un respiro profondo e pensa attentamente a questo problema di matematica". A volte, questo aiuta. Ma spesso, lo studente diventa solo più sicuro della sua risposta sbagliata perché ha passato più tempo a giustificarla.
Il risultato: Questi trucchi di "ragionamento" non hanno funzionato in modo coerente. In effetti, a volte hanno reso le allucinazioni peggiori. L'assistente spiegava con sicurezza perché la sua libreria falsa era reale, rendendo più difficile per te cogliere l'errore.

5. La soluzione "Strumento" (Controllare l'elenco telefonico)

I ricercatori hanno testato l'idea di fornire all'assistente uno strumento semplice: un pulsante che verifica se una libreria esiste effettivamente nel database ufficiale (PyPI).

L'analogia: Invece di far indovinare l'assistente, gli dai un elenco telefonico. Se dice "Userò Spagetti", controlla il libro, vede che non c'è, e poi dice: "Oh, quello non esiste".
Il risultato: Questo ha aiutato molto, ma non è stato una soluzione magica. L'assistente a volte dimenticava ancora di controllare il libro, oppure lo controllava ma decideva di ignorare il risultato e usare comunque il nome falso.

La grande conclusione: LIBHALLUBENCH

Poiché questo è un problema così grande, gli autori hanno creato un nuovo test chiamato LIBHALLUBENCH.

L'analogia: Pensa a questo come a una "patente di guida" progettata specificamente per vedere se un'auto a guida autonoma allucinerà un segnale di stop falso. Contiene migliaia di domande ingannevoli (come "dammi una libreria del 2025" o "usa questo nome scritto male") per testare sistematicamente quanto è probabile che diversi modelli di intelligenza artificiale inventino strumenti falsi.

Perché dovresti preoccupartene?

Se sei uno sviluppatore che usa l'IA per scrivere codice e l'IA inventa una libreria falsa, il tuo codice si bloccherà quando proverai a eseguirlo. Ancora peggio, se un hacker crea una libreria falsa che corrisponde a quella inventata dall'IA (una trucco chiamato "slopsquatting"), il tuo sistema potrebbe essere infettato da malware.

In breve: I generatori di codice basati sull'IA sono ottimi, ma sono pericolosamente sicuri di sé quando non conoscono la risposta. Inventeranno strumenti falsi per soddisfare la tua richiesta, specialmente se chiedi qualcosa del futuro o commetti un piccolo refuso. Abbiamo bisogno di modi migliori per impedirgli di inventare cose.

Riepilogo Tecnico: Allucinazioni di Librerie nel Codice Generato da LLM

Enunciato del Problema

I Modelli Linguistici di Grande Dimensione (LLM) sono diventati fondamentali nello sviluppo software moderno, eppure spesso "allucinano" inventando librerie inesistenti. Sebbene ricerche precedenti abbiano riconosciuto le allucinazioni di librerie come una modalità di fallimento, vi è una comprensione limitata di come questi errori si manifestino in condizioni d'uso realistiche. Nello specifico, rimane poco chiaro come le variazioni nei prompt degli sviluppatori—come descrizioni in linguaggio naturale, errori di battitura degli utenti o nomi di librerie fabbricati—influenzino il tasso con cui gli LLM generano importazioni non valide o chiamate non valide a librerie valide. Queste allucinazioni comportano rischi significativi, inclusi build interrotte, sviluppatori fuorviati ed esposizione a minacce della catena di approvvigionamento come lo "slopsquatting" (dove gli attaccanti registrano librerie che gli LLM spesso allucinano).

Metodologia

Gli autori presentano il primo studio sistematico su come le variazioni a livello di prompt degli utenti influenzino le allucinazioni di librerie attraverso sette diversi LLM di livello produttivo (GPT-4o-mini, GPT-5-mini, Ministral-8B, Qwen2.5-Coder, Llama-3.3, DeepSeek-V3.1 e Claude-4.5-Haiku).

Progettazione Sperimentale:
Lo studio utilizza BigCodeBench come dataset di partenza, filtrando 356 attività in Python che utilizzano librerie esterne. Gli esperimenti sono suddivisi in due categorie principali:

Esperimento 1: Variazioni Linguistiche dell'Utente:
- Fonte Dati: Sono state analizzate oltre 20.000 domande da Software Recommendations StackExchange (SRSE) per identificare descrittori comuni degli utenti.
- Variazioni: I prompt sono stati modificati per includere descrizioni basate su aggettivi (es. "veloce", "leggero", "migliore") e descrizioni basate sul tempo (es. "dal 2023", "dal 2025").
- Obiettivo: Determinare se le variazioni nel linguaggio naturale innescano allucinazioni.
Esperimento 2: Errori Controllati dell'Utente:
- Tipi di Errore: Lo studio ha introdotto errori specifici nei prompt:
  - Errori di battitura di un carattere (Distanza di Levenshtein 1, es. numpi per numpy).
  - Errori di battitura multi-carattere (Distanza di Levenshtein 2–8, es. graphly per plotly).
  - Nomi/Membri Finti: Librerie o membri completamente inesistenti generati per simulare richieste di follow-up per precedenti allucinazioni.
- Obiettivo: Quantificare la robustezza degli LLM contro errori di battitura ed entità fabbricate.

Pipeline di Valutazione:

Rilevamento: Il codice generato è stato analizzato utilizzando il modulo ast di Python. I nomi delle librerie sono stati verificati contro l'Python Package Index (PyPI) con normalizzazione, e i membri delle librerie sono stati verificati contro la documentazione ufficiale delle versioni più recenti delle librerie.
Metriche: Lo studio ha misurato il Tasso di Allucinazione della Risposta (RHR) e il Tasso di Allucinazione del Task (THR).
Indagini Aggiuntive: Gli autori hanno esaminato l'efficacia delle strategie di ingegneria dei prompt (Chain-of-Thought, Step-Back, Self-Analysis) e testato la generalizzabilità dell'ecosistema utilizzando CodeInsight (JavaScript, Rust) e mitigazione potenziata da strumenti (controlli di esistenza su PyPI).

Risultati Chiave

1. Sensibilità alle Variazioni del Prompt

Aggettivi vs. Tempo: Le descrizioni basate su aggettivi (es. "veloce", "open-source") hanno raramente innescato allucinazioni (tassi $\approx$ 0%). Al contrario, i prompt basati sul tempo sono stati un forte innesco. Le richieste di librerie "dal 2025" hanno indotto allucinazioni in fino all'85% dei task (specificamente per GPT-4o-mini), significativamente più alto rispetto alle richieste "dal 2023".
Errori dell'Utente: Gli LLM hanno mostrato scarsa robustezza agli errori di denominazione.
- Gli errori di battitura di un carattere hanno innescato allucinazioni in fino al 26% dei task.
- Gli errori di battitura multi-carattere hanno innescato allucinazioni in fino al 79% dei task.
- I nomi di librerie finti sono stati accettati in fino al 99% dei task per certi modelli (es. GPT-5-mini, Ministral-8B), indicando una tendenza alla "sycophancy" (adulazione), dove il modello si conforma alla premessa errata dell'utente piuttosto che correggerla.

2. Allucinazioni di Nomi di Librerie vs. Membri

Nomi di Librerie: I modelli sono stati altamente suscettibili ad allucinare intere librerie inesistenti quando sollecitati con errori o vincoli temporali.
Membri di Librerie: Le allucinazioni di membri (funzioni/classi) all'interno di librerie valide sono state generalmente più basse (principalmente 1%–5%) ma comunque presenti. Interessantemente, i modelli più recenti (GPT-5-mini, DeepSeek-V3.1) hanno talvolta mostrato tassi di allucinazione dei membri più elevati rispetto a quelli più vecchi, suggerendo spesso funzioni deprecate senza specifiche di versione.

3. Mitigazione e Generalizzabilità

Ingegneria dei Prompt: Strategie leggere come Chain-of-Thought e prompt Step-Back sono state inaffidabili e talvolta hanno aumentato i tassi di allucinazione rafforzando ragionamenti errati. Controlli espliciti e Self-Analysis hanno mostrato più promesse ma sono stati incoerenti tra i modelli.
Uso di Strumenti: Fornire uno strumento di esistenza su PyPI ha ridotto significativamente le allucinazioni (es. GPT-4o-mini è sceso a <3% per prompt basati sull'anno) ma non le ha eliminate. I modelli spesso non hanno invocato lo strumento o hanno ignorato i risultati negativi.
Ecosistemi: I pattern di allucinazione sono persistiti tra Python, JavaScript e Rust, suggerendo che la vulnerabilità non è limitata a un singolo linguaggio o ecosistema.

Contributi

Studio Sistematico: La prima analisi dettagliata di come le variazioni del prompt (linguaggio ed errori) influenzino le allucinazioni di librerie, rivelando che la formulazione basata sul tempo e gli errori di battitura sono inneschi critici.
Collegamento tra Sycophancy e Typosquatting: Il documento scopre una connessione novella tra il comportamento degli LLM e i rischi della catena di approvvigionamento, dimostrando che i modelli spesso allucinano con sicurezza librerie in risposta a piccoli errori di battitura, potenzialmente amplificando gli attacchi di typosquatting e slopsquatting.
LIBHALLUBENCH: Introduzione di un nuovo benchmark contenente 4.173 prompt etichettati derivati da condizioni ad alto rischio (basati sull'anno, sulla rarità e sugli errori) per abilitare una valutazione riproducibile delle allucinazioni di librerie.
Risorse Aperte: Rilascio del codice, delle uscite complete dei modelli e del benchmark per supportare la ricerca futura e lo sviluppo di mitigazioni.

Significato e Affermazioni

Il documento sostiene che la fragilità degli LLM rispetto alle variazioni naturali dei prompt costituisca una vulnerabilità sistemica. Gli autori affermano che:

Gli attuali LLM non possono essere affidati per validare nomi o membri di librerie, anche quando gli utenti forniscono nomi specifici (ma errati).
Le comuni richieste degli sviluppatori per librerie "aggiornate" o "recenti" sono un vettore primario per le allucinazioni, indipendentemente dalle date di taglio della conoscenza.
Le strategie di mitigazione esistenti come Chain-of-Thought sono insufficienti per questa specifica modalità di fallimento.
Il rischio va oltre i semplici errori di codice fino alle minacce alla sicurezza, poiché l'alto tasso di accettazione di librerie false potrebbe facilitare l'adozione di pacchetti malevoli (slopsquatting).

Gli autori concludono che difese robuste richiedono più della semplice ingegneria dei prompt; probabilmente necessitano di cambiamenti a livello di modello, meccanismi di verifica esterna e un cambiamento nel modo in cui gli LLM gestiscono l'incertezza riguardo alla validità delle librerie. Lo studio sottolinea che, sebbene i risultati siano basati su dataset e modelli specifici, i pattern osservati suggeriscono un problema più ampio e sistemico nella generazione di codice basata su LLM.