DebugLM: Learning Traceable Training Data Provenance for LLMs

1. Il Problema

I Large Language Models (LLM) moderni vengono addestrati attraverso pipeline complesse e multi-fase su fonti dati eterogenee. Tuttavia, gli sviluppatori mancano di un metodo principiato per identificare quali dati specifici di addestramento siano responsabili di un comportamento osservato (ad esempio, risposte tossiche, codice insicuro o violazioni delle policy).

• Mancanza di osservabilità: Senza tracciabilità, il debug si riduce a un processo reattivo di "patching" iterativo e tentativi ed errori.
• Rischio di ricorrenza: I fallimenti tendono a riemergere sotto shift di distribuzione o aggiornamenti del modello perché la radice del problema (la fonte dati) non viene diagnosticata.
• Limiti delle tecniche esistenti: I metodi di attribuzione post-hoc (come le funzioni di influenza o il recupero lessicale) sono computazionalmente costosi, instabili quando cambiano gli obiettivi di addestramento tra le fasi, e spesso non forniscono segnali di provenienza coerenti per pipeline multi-fase.

2. Metodologia: DEBUGLM

Il framework DEBUGLM propone di dotare gli LLM di una "provenienza dei dati" integrata (built-in), permettendo loro di tracciare esplicitamente l'origine dei propri comportamenti fino alle fonti di addestramento specifiche.

A. Interfaccia a Doppia Modalità

Il sistema introduce un'interfaccia controllabile tramite un "debug key" (un token speciale, es. <DEBUG>):

• Modalità Standard ($\lambda = 0$): Il modello genera la risposta normale $y$ senza sovraccarico.
• Modalità Debug ($\lambda = 1$): Se il prompt include il trigger, il modello genera la risposta $y$ insieme a un'etichetta di provenienza $z$ che indica la fonte dei dati responsabile.

B. Progettazione delle Etichette (Source-Tagging)

Invece di tracciare singoli esempi (impraticabile), il corpus di addestramento è trattato come una collezione di fonti discrete.

• A ogni fonte di dati $s$ viene assegnata un'etichetta univoca $z_s$ (implementata come un token speciale nel vocabolario, es. <TOFU>, <WMDP>).
• Questo approccio a livello di dataset si allinea meglio con il modo in cui gli LLM apprendono (dalle proprietà distributive dei dataset) e permette azioni di mitigazione mirate (rimozione o filtraggio di interi dataset).

C. Obiettivo di Addestramento Dual-Mode

Per internalizzare la mappatura tra comportamento e provenienza senza degradare le capacità generali, DEBUGLM utilizza un obiettivo di ottimizzazione congiunto:

1. Loss Standard ($L_{std}$): Minimizza l'errore di previsione del token successivo sulla risposta originale.
2. Loss di Tracciamento ($L_{debug}$): Quando il trigger è attivo, il modello deve prevedere la sequenza combinata [risposta; etichetta_sorgente].
3. Obiettivo Totale: $L = L_{std} + \beta L_{debug}$.
   Questo insegna al modello ad associare i pattern di risposta alle etichette delle fonti sottostanti solo quando attivato dal trigger.

D. Remediation (Rimedio) al Tempo di Inferenza

Una volta appresa la provenienza, il framework supporta la rimedio mirato al tempo di test senza riaddestramento:

• Gli sviluppatori possono iniettare un tag di "quarantena" (es. <DEBUG><TOFU>) nel prompt.
• Se la richiesta dell'utente è associata a quella fonte specifica, il modello impara a generare attivamente un rifiuto standardizzato ($y_{reject}$).
• Se la richiesta proviene da altre fonti, il modello ignora il tag di quarantena e risponde normalmente, evitando il fenomeno dell'over-refusal (rifiuti eccessivi su dati benigni).

3. Risultati Sperimentali

Gli esperimenti sono stati condotti su modelli come Llama-3-8B e Qwen-3-8B, utilizzando dataset eterogenei (TOFU, ChatDoctor, TruthfulQA, Beavertails, WMDP) in una pipeline multi-fase (SFT + RLHF/GRPO).

• Tracciamento della Provenienza (Provenance Tracing):

  • DEBUGLM ha raggiunto un Tasso di Successo di Tracciamento (TSR) medio superiore al 95%, superando o eguagliando i migliori baselines post-hoc (come SBERT o classificatori supervisionati).
  • A differenza dei baselines, DEBUGLM non richiede database vettoriali esterni o pipeline disaccoppiate; genera le etichette in un singolo passaggio in avanti (forward pass).
  • Robustezza: Il sistema mantiene alte prestazioni anche sotto perturbazioni di formato (es. conversione in domande a scelta multipla), dimostrando di aver appreso la mappatura parametrica e non di aver memorizzato stili superficiali.

• Remediation al Tempo di Test:

  • Il framework ha dimostrato un'efficacia chirurgica: quando un tag di quarantena viene attivato, il tasso di rifiuto (R3) per il dataset target è vicino al 100%.
  • Allo stesso tempo, il tasso di rifiuto per i dataset non target (off-diagonal) è vicino allo 0%, confermando che non si verifica un collasso verso un rifiuto universale.

• Preservazione dell'Utilità:

  • L'aggiunta della capacità di tracciamento non degrada le prestazioni del modello in modalità standard. Le metriche di utilità su task generali (QA, MMLU, ARC) rimangono comparabili o superiori rispetto ai modelli addestrati senza le etichette di debug.

• Scalabilità e Multi-Sorgente:

  • Il sistema scala efficacemente a tracciamento granulare (es. 199 autori diversi o 14 sottocategorie di tossicità).
  • Riesce a tracciare comportamenti sintetizzati da più fonti (es. QuoteSum), identificando correttamente la combinazione di origini multiple.

4. Contributi Chiave

1. Identificazione del bisogno: Evidenzia la necessità critica di tracciare la provenienza dei dati di addestramento nelle pipeline multi-fase degli LLM moderni.
2. Framework Pratico (DEBUGLM): Propone un metodo che addestra gli LLM a fornire etichette di provenienza a livello di dataset tramite un'interfaccia di debug controllabile, senza compromettere le capacità generali.
3. Dimostrazione Applicativa: Mostra l'efficacia del framework in due scenari distinti: diagnosi accurata delle fonti di comportamento indesiderato e mitigazione rapida e mirata al tempo di test (senza riaddestramento).

5. Significato e Implicazioni

DEBUGLM rappresenta un cambio di paradigma rispetto alle tecniche di attribuzione tradizionali:

• Da Reattivo a Proattivo: Sposta la diagnostica da un processo post-hoc costoso e approssimativo a una capacità intrinseca e verificabile del modello.
• Governance e Sicurezza: Fornisce agli sviluppatori uno strumento fondamentale per l'audit del copyright, il rilevamento di bias e la mitigazione dei rischi di contenuti tossici o allucinati, permettendo di isolare le fonti problematiche in modo chirurgico.
• Trasparenza: Colma il divario tra la documentazione statica dei dataset e il comportamento dinamico del modello, rendendo l'IA generativa più trasparente e responsabile.

Limitazioni: Il framework richiede l'accesso alla fase di addestramento (non applicabile retroattivamente a modelli "black-box" già congelati) e la scalabilità a milioni di fonti estremamente granulari potrebbe introdurre colli di bottiglia. Inoltre, esiste un rischio teorico di "spoofing" dei tag da parte di attori malintenzionati, rendendo necessario integrare DEBUGLM in un ecosistema di sicurezza più ampio.