Riepilogo Tecnico: DELULU – Un Benchmark Verificato Multi-Lingua per il Rilevamento di Allucinazioni nel Codice nelle Attività Fill-in-the-Middle

Enunciato del Problema

I Modelli Linguistici di Grandi Dimensioni (LLM) utilizzati per la generazione di codice producono frequentemente allucinazioni nelle attività Fill-in-the-Middle (FIM). Si tratta di completamenti che sono sintatticamente validi e semanticamente plausibili ma fattualmente errati, come metodi API inventati, parametri non validi, variabili non definite o importazioni inesistenti. Sebbene questi errori passino spesso una revisione del codice superficiale, introducono bug latenti a runtime che si manifestano solo in condizioni di esecuzione specifiche.

I benchmark attuali per la generazione di codice (ad esempio HumanEval, MBPP) si concentrano principalmente sulla generazione a livello di funzione partendo da specifiche in linguaggio naturale o mancano di verifica di esecuzione per le attività FIM. I benchmark FIM esistenti (ad esempio HumanEval Infilling, SAFIM) sono spesso limitati al solo Python, non distinguono tra tipi di errore e mancano di una verità di base basata sull'esecuzione per verificare che le allucinazioni causino effettivamente fallimenti a runtime. Inoltre, non esiste una valutazione sistematica di whether i LLM all'avanguardia possono rilevare in modo affidabile queste allucinazioni quando agiscono come revisori del codice.

Metodologia: Il Benchmark DELULU

Gli autori introducono DELULU, un benchmark verificato multi-lingua composto da 1.951 campioni FIM distribuiti su 7 linguaggi di programmazione (Python, Java, TypeScript, Go, Rust, C#, C++) e 4 categorie di allucinazione. Il benchmark è costruito attraverso una pipeline avversariale rigorosa a cinque stadi, progettata per garantire difficoltà, correttezza e verifica di esecuzione:

1. Generazione di Allucinazioni: Utilizzando CLAUDE SONNET come unico generatore, il sistema crea varianti "allucinate" di completamenti aurei estratti da repository GitHub reali. Il generatore è vincolato a modificare esattamente un elemento (nome del metodo, parametro, variabile o importazione) mantenendo il resto del codice identico, assicurando che l'allucinazione sia plausibile e indistinguibile dal codice reale a livello superficiale.
2. Valutazione con Giudice Multi-Modello: Quattro diversi LLM all'avanguardia (GPT-5.1, GPT-5.2, GPT-5.2-CODEX, GLM-4.7) valutano indipendentemente le coppie.
3. Campionamento Adversariale Iterativo: La pipeline analizza i disaccordi tra i giudici e utilizza il clustering basato su embedding per estrarre nuovi esempi di codice semanticamente simili che assomigliano alle modalità di fallimento dei giudici. Questo ciclo viene eseguito per tre iterazioni, portando progressivamente alla luce campioni più difficili man mano che l'accuratezza dei giudici diminuisce nel tempo.
4. Selezione Basata sulla Difficoltà: I campioni sono valutati in base alla loro capacità di ingannare i giudici. Vengono mantenuti solo i campioni sufficientemente difficili da ingannare almeno un giudice (o causare un rifiuto eccessivo di codice aureo).
5. Verifica di Esecuzione Basata su Docker: Questo è il differenziatore critico. Ogni campione viene confezionato in un contenitore Docker autonomo.
   • Il completamento aureo deve compilare ed eseguire senza errori.
   • Il completamento allucinato deve produrre un errore di runtime specifico e verificabile corrispondente alla sua categoria:
     • Metodo: AttributeError
     • Parametro: TypeError
     • Variabile non definita: NameError
     • Importazione: ImportError
   • Un ciclo di correzione assistito da CLAUDE SONNET risolve i problemi di dipendenza per garantire il successo della verifica.
6. Revisione da Parte di Esperti Umani: Un panel di tre esperti umani esamina i campioni verificati con Docker per rimuovere bias residui, casi banali o errori di etichettatura, risultando nel dataset finale di 1.951 campioni.

Contributi Chiave

1. Tassonomia delle Allucinazioni a Quattro Categorie: Una tassonomia strutturata in cui ogni categoria (Metodo, Parametro, Variabile non definita, Importazione) corrisponde a una distinta classe di errori di runtime verificabili, abilitando una verità di base basata sull'esecuzione.
2. Pipeline di Curazione Adversariale: Un innovativo processo a cinque stadi che accoppia codice reale con controparti allucinate, filtra i casi banali tramite sondaggio multi-modello e garantisce la verifica basata sull'esecuzione.
3. Dataset Multi-Lingua Verificato con Esecuzione: 1.951 campioni distribuiti su 7 linguaggi, ciascuno confezionato come contenitore Docker autonomo con tre modalità di invocazione (verifica aurea, verifica allucinata, verifica patch).
4. Valutazione Completa: Una valutazione di 11 modelli FIM open-weight provenienti da 5 famiglie (Qwen2.5-Coder, CodeLlama, DeepSeek-Coder-V2, StarCoder2) che spaziano da 0,5B a 32B parametri.
5. Studio di Rilevamento con Giudici all'Avanguardia: Una valutazione di 8 LLM all'avanguardia che agiscono come revisori del codice per rilevare allucinazioni, rivelando significativi gap nelle capacità di rilevamento.

Risultati

Prestazioni di Generazione

• Limiti di Scalabilità: Il modello più potente, Qwen2.5-Coder-32B, ha raggiunto solo un 84,5% di pass@1 sui 950 contesti FIM unici. Ciò indica che anche a 32B parametri, i modelli falliscono in circa un contesto unico su sette.
• Coerenza Cross-Famiglia: La difficoltà è intrinseca al compito, non specifica di una famiglia di modelli. Nessun modello cross-famiglia ha superato una Similarità di Modifica di 0,77. Anche il miglior modello cross-famiglia (DeepSeek-Coder-V2-Lite-Instruct) è rimasto indietro rispetto al miglior modello Qwen di 1,8 punti pass@1.
• Tipi di Allucinazione: Le allucinazioni di importazione sono state costantemente la categoria più difficile per tutte le dimensioni dei modelli e per tutti i linguaggi (ad esempio, 77,1% di pass@1 per Qwen-32B sulle importazioni contro >85% per gli altri tipi), suggerendo che il rilevamento di importazioni false richiede conoscenze specifiche dell'ecosistema piuttosto che il semplice completamento di pattern locali.
• Instruction Tuning: L'addestramento con istruzioni ha migliorato significativamente il comportamento di "stop" (Corrispondenza Esatta) ma ha avuto un impatto minimo sulla conoscenza sottostante necessaria per evitare di allucinare identificatori (Similarità di Modifica e CodeBLEU sono rimasti simili tra modelli base e instruct).

Prestazioni di Rilevamento

• Rilevamento Insoddisfatto: Anche il modello giudice più potente, Claude-4.5-Opus, ha raggiunto solo un 92,1% di accuratezza entrambi-corretti (accettare correttamente l'aureo e rifiutare l'allucinato).
• Gap di Rilevamento: I giudici più piccoli hanno performato significativamente peggio (ad esempio, GPT-4o-mini al 52,3%), stabilendo un intervallo di capacità di 40 punti.
• Collo di Bottiglia delle Importazioni: Il rilevamento delle allucinazioni di importazione è rimasto il compito più difficile per tutti i giudici (83,4% per Opus), confermando che distinguere i nomi dei pacchetti reali da quelli falsi è un gap di capacità persistente.
• Falsi Negativi: Il principale collo di bottiglia per i giudici è stato il rifiuto dei completamenti allucinati, non l'accettazione di quelli aurei.

Significato e Affermazioni

Il documento afferma che DELULU colma una lacuna critica nella valutazione del codice fornendo il primo benchmark che offre simultaneamente:

1. Categorizzazione sistematica delle allucinazioni con tipi granulari.
2. Copertura multi-lingua oltre il Python.
3. Verifica basata sull'esecuzione che garantisce che le allucinazioni producano errori di runtime reali.
4. Calibrazione della difficoltà avversariale che garantisce che il benchmark sia genuinamente impegnativo.

Gli autori sottolineano che la difficoltà esposta da DELULU è intrinseca al compito e non specifica della famiglia, come dimostrato dai tassi di fallimento coerenti tra architetture di modelli diverse. I risultati suggeriscono che semplicemente scalare i parametri del modello è insufficiente per risolvere l'allucinazione del codice; sono probabilmente necessari interventi mirati come la curazione dei dati di addestramento e il fine-tuning di tipo verificatore.

Il documento posiziona DELULU non solo come un benchmark per la generazione, ma come uno strumento riutilizzabile per valutare modelli di revisione del codice e verificatori, evidenziando che la capacità di rilevare le allucinazioni è attualmente un problema irrisolto anche per i modelli all'avanguardia. Il benchmark viene rilasciato come artefatto solo per test per prevenire la contaminazione, con gli autori che sconsigliano esplicitamente il fine-tuning sul dataset.