Evaluating Inference-Time Defenses Against Package Hallucination in LLM-Generated Code

Nel mondo moderno dello sviluppo software, i programmatori spesso si affidano ad assistenti di intelligenza artificiale per scrivere codice. Questi sistemi, noti come modelli linguistici di grandi dimensioni, agiscono come partner instancabili in grado di suggerire intere funzioni o correggere errori in pochi secondi. Per far sì che i loro suggerimenti funzionino, questi modelli raccomandano frequentemente l'aggiunta di pacchetti software esterni — collezioni di codice pre-scritto che gestiscono compiti specifici come la connessione a un database o la creazione di un grafico. Il problema sorge quando l'intelligenza artificiale inventa un nome di un pacchetto che suona perfettamente reale ma che in realtà non esiste in nessuna libreria software ufficiale. Questo fenomeno è chiamato allucinazione di pacchetti. Se uno sviluppatore si fida ciecamente del suggerimento e tenta di installare questo pacchetto inesistente, potrebbe involontariamente scaricare un file malevolo creato da un hacker che ha registrato il nome falso. Ciò crea una pericolosa porta sul retro nella catena di approvvigionamento del software, permettendo agli attaccanti di iniettare codice dannoso in applicazioni che milioni di persone potrebbero utilizzare.

Un team di ricercatori si è posto l'obiettivo di capire quanto spesso si verificano queste allucinazioni e se tecniche specifiche potessero fermarle prima ancora che il codice sia completato. Si sono concentrati su modelli di intelligenza artificiale open-source più piccoli, che sono ampiamente utilizzati perché meno costosi da gestire, sebbene siano più inclini a commettere errori rispetto ai loro omologhi più grandi. I ricercatori hanno testato questi modelli attraverso quattro diversi linguaggi di programmazione: Python, JavaScript, Ruby e Rust. Hanno scoperto che i metodi precedenti per misurare questi errori erano difettosi. Molti studi precedenti contavano gli strumenti standard, integrati nei linguaggi di programmazione, come allucinazioni semplicemente perché tali strumenti non sono elencati nelle librerie di pacchetti esterni. Correggendo questo errore di conteggio, il team ha scoperto che il tasso di allucinazioni per Python era in realtà inferiore rispetto a quanto precedentemente ritenuto, pur rimanendo significativo.

Il nucleo del loro lavoro consisteva nel testare sette diverse strategie per vedere se potevano ridurre il numero di nomi di pacchetti falsi generati dai modelli. Alcune di queste strategie prevedevano il cambiamento del modo in cui il modello seleziona la parola successiva, mentre altre chiedevano al modello di controllare il proprio lavoro o di cercare informazioni in un database verificato prima di rispondere. I ricercatori hanno scoperto che nessun metodo singolo funzionava meglio in ogni situazione. Una tecnica chiamata Generazione Aumentata dal Recupero (Retrieval-Augmented Generation), che costringe il modello a consultare un database reale di pacchetti esistenti prima di parlare, si è rivelata altamente efficace per la maggior parte dei linguaggi, riducendo significativamente il tasso di errore. Tuttavia, questa stessa tecnica a volte peggiorava le cose per JavaScript, suggerendo che la soluzione dipende fortemente dal linguaggio specifico utilizzato. Un altro approccio, in cui al modello viene chiesto di criticare e riscrivere i propri suggerimenti, funzionava bene per i modelli più grandi ma falliva per quelli più piccoli, che spesso non riuscivano a riconoscere i propri errori.

Il team ha anche introito un nuovo modo per misurare se i suggerimenti del modello fossero effettivamente utili, non solo corretti. Hanno scoperto che alcune strategie che riuscivano a fermare le allucinazioni impedivano anche al modello di suggerire qualsiasi pacchetto, lasciando lo sviluppatore senza nulla da usare. L'approccio più equilibrato, che riduceva gli errori fornendo al contempo suggerimenti utili, era un metodo diretto in cui il modello sceglie semplicemente la parola successiva più probabile ogni volta, invece di rischiare su opzioni meno probabili. Questo approccio "greedy" (avido) offriva il miglior compromesso tra sicurezza e utilità per i modelli testati.

Forse la scoperta più sorprendente è emersa quando i ricercatori hanno testato queste difese contro un ambiente ostile. Hanno creato prompt che cercavano deliberatamente di ingannare i modelli inducendoli a raccomandare pacchetti falsi inserendo i nomi falsi direttamente nelle istruzioni. In queste condizioni avversarie, i tassi di errore sono schizzati alle stelle, aumentando di ben 45 punti percentuali rispetto alle richieste normali. In questo scenario ostile, i semplici trucchi di cambiare il modo in cui il modello sceglie le parole fallivano completamente. Solo i metodi che si basavano sul controllo rispetto a un database reale o sul costringere il modello a doppiezza il proprio lavoro potevano resistere all'attacco. I ricercatori hanno concluso che, sebbene i semplici aggiustamenti possano aiutare nell'uso normale, proteggere il software da attaccanti determinati richiede un sistema capace di verificare i fatti rispetto al mondo esterno o di controllare rigorosamente la propria logica. Lo studio evidenzia che la difesa migliore non è una soluzione universale, ma una scelta accoppiata con cura alla specifica minaccia e al linguaggio di programmazione coinvolto.