Hallucination Inspector: A Fact-Checking Judge for API Migration

1. Il Problema: L'Allucinazione di Impalcatura (Scaffolding Hallucination)

L'adozione dei Modelli Linguistici (LLM) nell'ingegneria del software automatizzata, in particolare per le migrazioni di API, ha introdotto un problema critico: l'Allucinazione di Impalcatura (Scaffolding Hallucination).
Mentre gli LLM riescono spesso a identificare correttamente l'API target da utilizzare, falliscono nella generazione del "codice collante" necessario per istanziare oggetti, costruire catene di metodi e invocare correttamente le nuove API.

Il paper definisce l'allucinazione in questo contesto non come un errore generico, ma come la generazione di contenuti che contraddicono i fatti verificabili presenti nella documentazione dell'API. Nello specifico, gli LLM inventano Simboli Fantasma (Phantom Symbols): import, costruttori, costanti o metodi che non esistono nella specifica dell'API.

• Esempio: Un modello potrebbe generare un oggetto AudioAttributes.Builder e invocare un metodo setStreamType che non esiste in quella classe (esistendo invece nella vecchia classe AudioManager), o utilizzare una costante inventata come CONTENT_TYPE_STREAM.
• Limiti delle metriche attuali: Le metriche di similarità standard (come CodeBLEU) falliscono nel rilevare questi errori perché il codice generato è sintatticamente e strutturalmente molto simile alla soluzione corretta, ottenendo punteggi elevati nonostante contenga errori di compilazione fatali. Anche l'uso di "LLM come Giudice" (LLM-as-a-Judge) si è rivelato inaffidabile a causa di bias di ottimismo o di sovracorrezione.

2. Metodologia: Hallucination Inspector

Per affrontare queste limitazioni, gli autori propongono Hallucination Inspector, un framework di analisi statica basato su fatti (fact-checking) e guidato dalla documentazione.

Architettura e Principi

Il sistema è progettato per essere leggero, deterministico e indipendente dal linguaggio (sebbene implementato per Java/Android). Si basa su due principi fondamentali:

1. Analisi Statica: Opera direttamente su frammenti di codice (snippet) senza richiedere un ambiente di build completo o l'esecuzione di test, permettendo un feedback rapido.
2. Oracle Deterministico: Utilizza una base di conoscenza derivata direttamente dalla documentazione ufficiale dell'API (invece di un altro modello probabilistico) per verificare la correttezza.

Fasi di Funzionamento

Il flusso di lavoro si articola in tre moduli principali:

1. Parser: Converte il codice generato dall'LLM in un AST (Abstract Syntax Tree) utilizzando la libreria Tree-sitter.
2. Symbol Extractor: Isola le unità testabili dall'AST, identificando simboli atomici (costanti, campi) e catene di metodi.
3. Verification Engine: Confronta i simboli estratti contro un API Oracle (una tabella dei simboli costruita dai file XML dell'SDK Android).

Tassonomia delle Allucinazioni Rilevate

L'approccio distingue due categorie di allucinazioni, gestite con strategie diverse:

• Tier 1: Allucinazioni Atomiche (Atomic Hallucinations): Invenzione di simboli atomici non esistenti (es. costanti, classi, metodi statici). Il sistema esegue un controllo diretto di esistenza nella tabella dei simboli.
• Tier 2: Allucinazioni Legate allo Scope (Scope-bound Hallucinations): Invenzione di membri (metodi) per un oggetto specifico. Il sistema risolve il tipo dell'oggetto nella catena di chiamate (propagazione dei tipi) e verifica se il metodo invocato esiste effettivamente su quel tipo specifico. Rileva anche "catene rotte" (Broken Chains), dove un metodo che restituisce void viene seguito da un'altra chiamata.

3. Contributi Chiave

1. Definizione Formale: Introduce il concetto di Scaffolding Hallucination e lo suddivide in una tassonomia operativa (Atomiche e Scope-bound) basata sulla complessità strutturale necessaria per rilevarle.
2. Strumento di Analisi: Presenta Hallucination Inspector, uno strumento di analisi statica che utilizza un oracle basato sulla documentazione per rilevare i Simboli Fantasma in modo deterministico.
3. Valutazione Empirica: Dimostra sperimentalmente che le metriche di similarità (CodeBLEU) sono inaffidabili per questo compito e che l'approccio proposto supera significativamente i baselines basati su "LLM-as-a-Judge".

4. Risultati Sperimentali

Gli autori hanno valutato lo strumento su un dataset di 51 migrazioni di API Android, utilizzando due modelli LLM all'avanguardia (Qwen-2.5 e Codestral-v1) per generare le migrazioni.

• Fallimento delle Metriche Standard (RQ1): L'analisi dei punteggi CodeBLEU ha mostrato una sovrapposizione quasi totale tra snippet corretti e snippet con allucinazioni. Molti patch con errori fatali (es. metodi inesistenti) hanno ottenuto punteggi CodeBLEU superiori a 0.95, rendendo impossibile l'uso di una soglia di taglio per filtrare gli errori.
• Efficacia del Rilevamento (RQ2):
  • Hallucination Inspector: Ha raggiunto una Precisione del 100% su entrambi i dataset, eliminando completamente i falsi positivi. Il Recall è stato rispettivamente del 73% (Qwen) e del 90% (Codestral). I falsi negativi sono dovuti principalmente a mismatch di tipi di argomento o firme di callback non completamente risolvibili senza contesto globale.
  • LLM-as-a-Judge (GPT-5-mini): Ha mostrato prestazioni inferiori, con una precisione del 67% (Qwen) e del 50% (Codestral). Il giudice LLM ha commesso frequenti errori di sovracorrezione (rifiutando codice valido) e non ha rilevato diverse allucinazioni reali, dimostrando di essere soggetto agli stessi bias probabilistici dei modelli generatori.

5. Significato e Implicazioni

Il lavoro di Tileria et al. è significativo per diversi motivi:

• Superamento dei Bias Probabilistici: Sposta il paradigma di valutazione da approcci statistici/probabilistici (similarity metrics, LLM judges) a un approccio deterministico e basato su fatti, garantendo che il codice generato rispetti rigorosamente il contratto dell'API.
• Affidabilità nell'Automazione: Fornisce un meccanismo di controllo (gatekeeper) essenziale per pipeline di riparazione automatica del codice, dove la presenza di errori di compilazione nascosti (allucinazioni) può bloccare l'intero processo di integrazione continua.
• Integrazione con RL: Lo strumento può essere utilizzato come segnale di ricompensa (reward signal) per l'addestramento di modelli di riparazione del codice tramite Reinforcement Learning, insegnando agli LLM a evitare errori di scope-bound.
• Scalabilità: L'architettura leggera e basata su analisi statica lo rende adatto all'uso in contesti industriali su larga scala, a differenza di approcci che richiedono l'esecuzione di test o l'uso intensivo di risorse computazionali.

In sintesi, il paper dimostra che per garantire la correttezza nelle migrazioni di API automatizzate, non basta che il codice "sembri" corretto (alta similarità), ma deve essere verificato contro una specifica di verità (Oracle), un compito per cui l'analisi statica deterministica è superiore all'intuizione probabilistica degli LLM.