Riepilogo Tecnico: Oltre l'Ancoraggio ai Documenti

Definizione del Problema

I sistemi di generazione aumentata dal recupero (RAG) sono sempre più implementati in ambienti strutturati che vanno oltre il linguaggio naturale, inclusi agenti di codifica, strumenti per sviluppatori e documentazione di ricerca. Mentre i benchmark e i rilevatori di allucinazioni esistenti si concentrano principalmente sulle prove in linguaggio naturale, essi non riescono ad affrontare le sfide uniche di verifica poste da input strutturati come il codice sorgente, l'output degli strumenti (ad es., log dei test, output dei comandi) e i documenti strutturati (ad es., markdown, tabelle).

In questi contesti strutturati, una singola sottostringa non supportata — come un nome di metodo fabbricato, un valore di campo errato o un'osservazione di uno strumento riportata in modo errato — può alterare il comportamento di un programma o trarre in errore un utente, anche se il resto della risposta è corretto. Gli attuali framework di valutazione mancano di una formulazione unificata a livello di span che copra il codice generato, le osservazioni degli strumenti e i documenti strutturati insieme ai tradizionali compiti RAG in linguaggio naturale.

Metodologia

Costruzione del Benchmark Unificato

Gli autori introducono un benchmark unificato composto da 74.285 esempi appena costruiti provenienti da cinque fonti, integrati da esempi convertiti da dataset RAG di linguaggio naturale esistenti (RAGTruth e PsiloQA). Le fonti includono:

• Codice: Derivato da SWE-bench, caratterizzato da correzioni basate su repository.
• Output degli Strumenti: Derivato da Squeez, contenente query e osservazioni verbose degli strumenti.
• Documenti Strutturati: Chunk di articoli ACL, README di GitHub e Wikipedia in markdown.
• Linguaggio Naturale: RAGTruth e PsiloQA (14 lingue).

Pipeline di Costruzione dei Dati:

1. Ancoraggio (Grounding): Si parte da una risposta corretta e ancorata derivata dalla fonte (ad es, una patch gold di SWE-bench).
2. Iniezione: Utilizzare un modello "iniettore" specifico per la fonte (Gemma 4 31B per il codice; Qwen 3.6 35B per gli altri) per proporre modifiche di sostituzione localizzate e strutturate. Queste modifiche introducono allucinazioni localizzate categorizzate come Contraddizione (logica/valori errati), Aggiunta Non Supportata (comportamento extra) o Riferimento Fabbricato (metodi/identificatori inventati).
3. Etichettatura degli Span: Applicare le modifiche in modo deterministico per estrarre gli offset esatti dei caratteri per gli span allucinati, evitando l'ambiguità del confronto (diffing) tra risposte miste linguaggio naturale/codice.
4. Ancoraggio di Riferimento: Per evitare di penalizzare risposte corrette che fanno riferimento a librerie esterne o metodi fratelli non presenti nei contesti troncati, la pipeline appende definizioni risolte dal commit base del repository e firme API reali da Context7.
5. Verifica: Il test set del code-agent è stato sottoposto a revisione umana e arbitrato, mantenendo 2.015 esempi dopo il filtraggio per validità e accuratezza dei confini.

Architettura del Modello

Due famiglie di rilevatori sono state addestrate sul dataset unificato:

1. LettuceDetect-Qwen-2B: Un rilevatore generativo Qwen3.5-2B fine-tuned con una finestra di contesto di 32.768 token. Produce un JSON contenente span di caratteri, categorie e sottocategorie.
2. LettuceDetect-mmBERT-base: Un encoder di classificazione di token da 307 milioni di parametri (basato su mmBERT) addestrato con una lunghezza massima della sequenza di 8.192 token.

Entrambi i modelli sono addestrati utilizzando un prompt agnostico rispetto ai dati che definisce la tassonomia delle allucinazioni e fornisce la richiesta, il contesto e la risposta da verificare.

Contributi Chiave

1. Formulazione del Task: Una formulazione del task a livello di span per il rilevamento delle allucinazioni post-generazione specificamente progettata per contesti di generazione ancorata strutturata (codice, output di strumenti, documenti strutturati).
2. Benchmark Unificato: Un dataset completo di 74.285 nuovi esempi che copre diverse modalità, oltre a esempi convertiti da benchmark RAG stabiliti, consentendo la valutazione cross-domain.
3. Performance del Rilevatore: Dimostrazione che un rilevatore generativo fine-tuned (LettuceDetect-Qwen-2B) supera sostanzialmente i rilevatori standard e i giudici LLM zero-shot sugli split code-agent e tool-output, rimanendo competitivo sui benchmark RAG in linguaggio naturale.

Risultati Sperimentali

Risultati Principali

Sul set di test unificato, LettuceDetect-Qwen-2B ha raggiunto uno span-F1 di 0.689.

• Performance Code-Agent: Il modello ha ottenuto uno span-F1 di 0.602 sullo split code-agent, superando significativamente LettuceDetect-large (0.17) e i più forti giudici LLM zero-shot valutati (Nemotron-3-Ultra e gpt-oss-120b, entrambi $\le$ 0.22).
• Performance Linguaggio Naturale: Il modello è rimasto competitivo sui benchmark stabiliti, raggiungendo un esempio-F1 di 81.8 su RAGTruth e un IoU di 0.724 su English PsiloQA (superando il mmBERT-base fine-tuned degli autori del benchmark a 0.707).
• Capacità Multilingue: Attraverso 14 lingue in PsiloQA, il modello ha raggiunto un IoU medio di 0.689, superando il giudice Qwen2.5-32B (0.383).

Confronto con i Baseline

• Giudici Zero-Shot: Grandi LLM zero-shot (ad es, Nemotron-3-Ultra, gpt-oss-120b) hanno faticato con il codice e l'output degli strumenti, spesso segnalando come non supportato del codice corretto appena scritto o fallendo nel distinguere tra edizioni valide e allucinazioni.
• Rilevatori Specializzati: I rilevatori esistenti addestrati esclusivamente sul linguaggio naturale (ad es, LettuceDetect-large) hanno performato scarsamente sui dati strutturati (0.17 span-F1 sul codice).
• Encoder vs. Generatore: Il rilevatore generativo (Qwen-2B) ha costantemente superato l'encoder di classificazione dei token (mmBERT-base) in tutte le fonti (0.689 vs 0.642 di span-F1 complessivo).

Significato e Rivendicazioni

Il documento sostiene che il benchmark e il rilevatore proposti affrontano una lacuna critica nella valutazione RAG: la mancanza di verifica a livello di span per output generati strutturati e non in linguaggio naturale. Gli autori sottolineano che:

• La Verifica Strutturata è Distinta: La verifica in codice e nell'output degli strumenti richiede un ragionamento diverso rispetto al linguaggio naturale, in particolare riguardo agli errori di intenzione e alla validità strutturale.
• I Rilevatori Generativi sono Superiori: I modelli generativi fine-tuned con finestre di contesto lunghe sono più adatti a questo compito rispetto ai tradizionali encoder o ai giudici zero-shot, specialmente quando si gestiscono contesti di repository lunghi e dipendenze complesse.
• Valutazione Unificata: Un singolo modello può gestire efficacemente diverse modalità (codice, output di strumenti, documenti) senza sacrificare le prestazioni sui compiti in linguaggio naturale.

Gli autori segnalano i limiti, tra cui la dipendenza dall'iniezione sintetica per la maggior parte delle etichette (sebbene il test set del codice sia stato sottoposto a revisione umana) e il focus sulla verifica della risposta finale piuttosto che sull'intera traiettoria dell'agente. Concludono che il loro lavoro fornisce una base necessaria per lo sviluppo di sistemi di verifica robusti per la prossima generazione di agenti di generazione ancorata.