DebugLM: Learning Traceable Training Data Provenance for LLMs

1. Problemstellung

Große Sprachmodelle (LLMs) werden heutzutage in komplexen, mehrstufigen Trainingspipelines (Multi-Stage Pipelines) trainiert, die heterogene Datenquellen kombinieren (z. B. Vor-Training, SFT, RLHF, DPO). Ein zentrales Problem ist die mangelnde Beobachtbarkeit (Observability): Wenn ein Modell unerwünschtes Verhalten zeigt (z. B. toxische Inhalte, Sicherheitslücken oder Halluzinationen), fehlt Entwicklern eine prinzipielle Methode, um genau zu identifizieren, aus welcher spezifischen Trainingsdatenquelle dieses Verhalten gelernt wurde.

• Aktuelle Einschränkungen: Herkömmliche Debugging-Ansätze sind oft reaktiv (Patches nach dem Fehler) und fehleranfällig bei Verteilungsverschiebungen.
• Grenzen bestehender Methoden: Bestehende Techniken zur Datenattributierung (z. B. Influence Functions, Post-hoc-Classifier) sind bei der Skalierung auf moderne LLMs rechnerisch zu teuer, instabil bei sich ändernden Trainingszielen oder liefern keine konsistenten Signale für mehrstufige Pipelines.

2. Methodik: DEBUGLM Framework

DEBUGLM ist ein Framework, das LLMs befähigt, die Herkunft ihres generativen Verhaltens direkt auf die zugrundeliegenden Trainingsdatensätze zurückzuführen. Dies geschieht durch eine eingebaute Datenprovenienz (Built-in Data Provenance).

Kernkomponenten:

1. Datenquellen-Tags (Source-Tagging):

   • Der Trainingskorpus wird als Sammlung diskreter Datenquellen betrachtet.
   • Jeder Quelle wird ein eindeutiges, dataset-spezifisches Tag (z. B. <TOFU>, <CHATDOCTOR>) zugewiesen, das als spezielles Token im Vokabular des Modells implementiert ist.
   • Dies ermöglicht eine Granularität auf Datenebene (nicht auf einzelner Instanz), was der praktischen Interventionsfähigkeit entspricht (z. B. Entfernen ganzer Datensätze).

2. Dual-Mode Training Objective (Zwei-Modus-Training):
   DEBUGLM führt einen leichten Debug-Trigger (z. B. <DEBUG>) ein, der das Verhalten des Modells steuert. Das Training optimiert zwei Modi gleichzeitig:

   • Standard-Modus ($\lambda = 0$): Das Modell generiert die normale Antwort $y$. Der Verlust wird über die Standard-Next-Token-Prediction berechnet ($L_{std}$).
   • Debug-Modus ($\lambda = 1$): Wenn der Trigger <DEBUG> vorangestellt wird, muss das Modell die Antwort $y$ zusammen mit dem korrekten Provenienz-Tag $z_s$ generieren. Der Verlust ($L_{debug}$) zwingt das Modell, eine stabile Korrespondenz zwischen dem generierten Verhalten und der Quelle herzustellen.
   • Die Gesamtverlustfunktion ist eine gewichtete Summe: $L = L_{std} + \beta L_{debug}$.

3. Test-Time Remediation (Intervention zur Laufzeit):

   • Entwickler können gezielt das Verhalten bestimmter Quellen unterdrücken, ohne das Modell neu zu trainieren.
   • Durch Voranstellen eines spezifischen Quell-Tags (z. B. <DEBUG><TOFU>) an den Prompt lernt das Modell, bei Abfragen, die mit dieser Quelle assoziiert sind, eine standardisierte Ablehnung ($y_{reject}$) auszugeben.
   • Dies ermöglicht eine „chirurgische" Quarantäne problematischer Datenbereiche.

3. Wichtige Beiträge

1. Identifikation des Bedarfs: Die Arbeit hebt die Notwendigkeit einer effektiven Provenienz-Verfolgung in modernen, mehrstufigen LLM-Entwicklungsprozessen hervor.
2. Praktisches Framework (DEBUGLM): Entwicklung eines Systems, das LLMs trainiert, Provenienz-Tags über eine Debug-Schnittstelle bereitzustellen, ohne die generelle Nützlichkeit zu beeinträchtigen.
3. Anwendung und Generalisierbarkeit: Demonstration des Frameworks in zwei Szenarien:
   • Diagnose: Präzises Zurückverfolgen von Verhalten auf Datensätze in mehrstufigen Pipelines.
   • Intervention: Gezielte Unterdrückung von Verhalten aus spezifischen Quellen zur Laufzeit.

4. Ergebnisse und Evaluation

Die Evaluation erfolgte auf Basismodellen (Llama-3-8B, Qwen-3-8B) mit heterogenen Datensätzen (TOFU, ChatDoctor, TruthfulQA, Beavertails, WMDP).

• Provenienz-Verfolgung (Tracing Success Rate - TSR):

  • DEBUGLM erreicht eine Genauigkeit von über 95 % im Durchschnitt, was mit spezialisierten Post-hoc-Klassifikatoren (1B Parameter) vergleichbar ist.
  • Im Gegensatz zu Baselines (BM25, ROUGE, SBERT), die bei kurzen Antworten oder freien Texten (z. B. TruthfulQA) versagen, ist DEBUGLM robust, da es die Provenienz parametrisch im Modell verankert.
  • Format-Robustheit: Auch bei Umwandlung in Multiple-Choice-Fragen (MCQ), wo externe Matcher oft scheitern (da der semantische Fußabdruck fehlt), bleibt DEBUGLM stabil.

• Test-Time Remediation:

  • Das Framework zeigt eine nahezu perfekte chirurgische Präzision: Bei Aktivierung eines Quarantäne-Tags wird das Ziel-Domain zu 100 % blockiert (Ablehnungsrate), während andere Domänen zu 0 % fälschlicherweise blockiert werden (kein Over-Refusal).
  • Dies eliminiert die Notwendigkeit teurer Neukalibrierung oder Unlearning-Prozesse.

• Erhaltung der Nützlichkeit (Utility Preservation):

  • Im Standard-Modus (ohne Debug-Trigger) bleibt die Leistung des Modells in allgemeinen Aufgaben (MMLU, ARC-Challenge) und QA-Aufgaben erhalten. DEBUGLM degradiert die Basisfähigkeiten nicht.

• Skalierbarkeit:

  • Das System skaliert erfolgreich auf feinkörnigere Tags (z. B. 199 Autoren oder 14 Toxizitäts-Subkategorien) und behält dabei eine hohe Verfolgungsgenauigkeit bei, wo lexikalische Methoden versagen.
  • Es kann auch Multi-Source-Verhalten korrekt zurückverfolgen, wenn Antworten aus mehreren Quellen synthetisiert wurden.

5. Bedeutung und Ausblick

DEBUGLM stellt einen Paradigmenwechsel dar: Statt Provenienz als externe, rechnerisch intensive Nachberechnung zu behandeln, wird sie zu einer intrinsischen, überprüfbaren Fähigkeit des Modells.

• Transparenz & Governance: Es bietet Entwicklern ein Werkzeug für Urheberrechtsprüfung, Bias-Erkennung und Sicherheitsaudits.
• Effizienz: Ermöglicht schnelle, gezielte Korrekturen von Sicherheitslücken ohne vollständiges Re-Training.
• Limitationen: Das Verfahren erfordert Zugriff auf die Trainingsphase (kann nicht auf bereits eingefrorene Black-Box-Modelle angewendet werden) und könnte bei extrem feinkörnigen Tags (Millionen) an Kapazitätsgrenzen stoßen. Zudem besteht das Risiko von „Tag-Spoofing" durch böswillige Akteure, weshalb es in ein umfassendes Sicherheitsökosystem integriert werden muss.

Zusammenfassend bietet DEBUGLM einen skalierbaren und zuverlässigen Weg hin zu transparenter generativer KI, indem es die Lücke zwischen statischer Datensatzdokumentation und dynamischem Modellverhalten schließt.