💬 NLP

SrDetection: A Self-Referential Framework for Data Leakage Detection in Code Large Language Models

Das Paper stellt SrDetection vor, ein selbstreferenzielles Framework, das Datenlecks in Code-Large-Language-Models identifiziert, indem es die Modellleistung auf Original-Benchmark-Proben mit deren semantisch äquivalenten Varianten vergleicht und dabei eine signifikant höhere Erkennungsgenauigkeit als bestehende Methoden sowohl in Gray-Box- als auch in Black-Box-Szenarien erreicht, ohne auf externe Schwellenwerte oder proprietäre Trainingsdaten angewiesen zu sein.

Ursprüngliche Autoren: Shuaimin Li, Liyang Fan, Zeyang Li, Zhuoyue Wan, Yufang Lin, Shiwen Ni, Feiteng Fang, Hamid Alinejad-Rokny, Yuanfeng Song, Kun Jing, Chen Jason Zhang, Min Yang

Veröffentlicht 2026-06-30

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Shuaimin Li, Liyang Fan, Zeyang Li, Zhuoyue Wan, Yufang Lin, Shiwen Ni, Feiteng Fang, Hamid Alinejad-Rokny, Yuanfeng Song, Kun Jing, Chen Jason Zhang, Min Yang

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Lehrer, der versucht, die Abschlussprüfung eines Schülers zu bewerten. Sie möchten wissen, ob der Schüler das Material wirklich verstanden hat oder ob er nur die Antworten von einem Spickzettel auswendig gelernt hat, den er zuvor gefunden hat. In der Welt der Künstlichen Intelligenz, speziell bei Code Large Language Models (Code LLMs), wird dieser „Spickzettel“ als Data Leakage bezeichnet. Dies geschieht, wenn ein Modell versehentlich die exakten Testfragen während seiner Trainingsphase „studiert“ hat, was es so aussehen lässt, als wäre es intelligenter, als es eigentlich ist.

Das Paper stellt ein neues Werkzeug namens SrDetection vor, um diesen Betrug zu entlarven. So funktioniert es, einfach erklärt:

Das Problem: Die kaputte Stoppuhr und der fehlende Lösungsschlüssel

Derzeit ist der Versuch, eine betrügende KI zu überführen, so wie der Versuch, ein Puzzle mit fehlenden Teilen zu lösen.

Das „Fehlender Lösungsschlüssel“-Problem: Um zu prüfen, ob ein Modell eine Frage auswendig gelernt hat, müsste man normalerweise Zugriff auf das geheime Trainingsprotokoll (die Daten, aus denen es gelernt hat) haben. Aber Unternehmen halten diese Protokolle privat. Wir können nicht hineinsehen.
Das „Kaputte Stoppuhr“-Problem: Manche Leute versuchen zu erraten, ob ein Modell eine Frage gesehen hat, indem sie prüfen, wann der Code geschrieben wurde. Wenn der Code nach dem Training des Modells geschrieben wurde, nehmen sie an, dass das Modell ihn nicht sehen konnte. Aber dies ist unzuverlässig, da Code oft kopiert, eingefügt und aus alten Projekten wiederverwendet wird, was die Datumsangaben verwirrend macht.
Das „Willkürliche Grenze“-Problem: Andere Methoden versuchen, eine feste Regel festzulegen (wie „wenn das Modell zu 90 % sicher ist, ist es Betrug“). Aber Code ist knifflig; was für eine Art von Code ein hoher Wert aussieht, kann für eine andere völlig normal sein. Eine einzige Regel für alles festzulegen, führt oft zum Scheitern.

Die Lösung: Der „selbstreferenzielle“ Spiegel

Die Autoren entwickelten SrDetection, das wie ein kluger Detektiv funktioniert, der weder das geheime Protokoll noch eine Stoppuhr benötigt. Stattdessen nutzt es einen Spiegel.

Hier ist die Analogie:
Stellen Sie sich vor, auf einem Blatt Papier steht ein bestimmter Satz: „The quick brown fox jumps over the lazy dog.“

Der alte Weg: Sie fragen die KI: „Kennst du diesen Satz?“ Wenn sie sehr selbstbewusst mit „Ja“ antwortet, vermuten Sie, dass sie ihn auswendig gelernt hat. Aber vielleicht ist es nur ein sehr häufiger Satz, daher ist Selbstbewusstsein kein perfekter Beweis.
Der SrDetection-Weg: Der Detektiv nimmt diesen ursprünglichen Satz und erstellt 10 leicht abgewandelte Versionen davon, die exakt dasselbe bedeuten, aber oberflächlich anders aussehen.
- Original: „The quick brown fox jumps...“
- Variante 1: „The speedy brown fox leaps...“
- Variante 2: „A fast brown fox hops...“
  (Die Logik ist identisch, aber die Wörter wurden ausgetauscht.)

Dann bittet der Detektiv die KI, alle diese Versionen zu verarbeiten.

Der „Aha!“-Moment:
Wenn die KI den ursprünglichen Satz auswendig gelernt hat, wird sie durch die Originalversion mühelos navigieren (weil sie diese schon einmal gesehen hat), aber bei den Varianten könnte sie stolpern oder zögern (weil sie diese spezifischen Wortkombinationen nicht gesehen hat).

Der Betrug: Das Original ist zu einfach im Vergleich zu seinen Geschwistern.
Der ehrliche Schüler: Das Original und die Varianten sind alle in etwa gleich schwierig, weil die KI einfach die Logik versteht und nicht ein Skript rezitiert.

Wie es in zwei Modi funktioniert

Das Paper zeigt, dass dies in zwei verschiedenen Szenarien funktioniert:

Gray-Box (Der „Inside Look“): Sie können die internen Konfidenzwerte der KI sehen (wie das Beobachten ihres Herzschlags). SrDetection prüft, ob das Original-Code den „Herzschlag“ der KI ruhig und stetig macht, während die Varianten sie nervös machen.
Black-Box (Der „Outside Look“): Sie können nur die endgültige Antwort sehen, die die KI gibt. SrDetection prüft, ob die Antwort der KI auf den Original-Code eine perfekte, exakte Übereinstimmung ist, während ihre Antworten auf die Varianten etwas unordentlicher oder weniger perfekt sind.

Das Ergebnis: Ein besserer Detektiv

Die Autoren bauten eine spezielle „Trainingsumgebung“ (ein Testbed), in der sie genau kontrollieren konnten, welchen Code die KI sah und welchen nicht, um ihr neues Werkzeug zu testen.

Die Punktzahl: Im Vergleich zu anderen Methoden war SrDetection viel besser darin, die Betrüger zu entlarven. Es verbesserte die Genauigkeit (F1-Score) um etwa 21 Punkte im „Inside Look“-Szenario und um 14 Punkte im „Outside Look“-Szenario.
Keine festen Regeln: Im Gegensatz zu anderen Werkzeugen benötigt es keine voreingestellte „Bestanden/Nicht bestanden“-Linie. Es vergleicht einfach das Original mit seinen eigenen Geschwistern. Wenn das Original verdächtig einfach erscheint, schlägt es Alarm.

Was sie in der realen Welt fanden

Die Forscher testeten 15 populäre Code-KI-Modelle auf vier berühmten Coding-Benchmarks. Sie fanden heraus:

Einige Modelle wiesen ein hohes Maß an „Betrug“ bei spezifischen Tests auf (wie den APPS- und BigCodeBench-Datensätzen).
Das Ausmaß des Betrugs variierte stark je nach spezifischem Test, was beweist, dass Annahmen nach dem Motto „Einheitsgröße für alles“ bezüglich Data Leakage falsch sind.

Zusammenfassung

SrDetection ist eine neue Methode, um KI-Modelle zu entlarven, die Testfragen auswendig gelernt haben. Anstatt geheime Daten zu benötigen oder basierend auf Daten zu raten, erstellt es „Zwillinge“ des Codes, um zu sehen, ob das Modell das Original anders behandelt als seine Zwillinge. Wenn das Modell mit dem Original zu komfortabel umgeht, hat es wahrscheinlich geschummelt. Dies macht unsere Bewertung von KI wesentlich fairer und zuverlässiger.

Technisches Resümee: SrDetection

Problemstellung

Die Evaluierung von Code Large Language Models (Code LLMs) wird zunehmend durch Datenleckage (Data Leakage) beeinträchtigt, bei der Benchmark-Proben unbeabsichtigt in den Pre-Training-Korpus eines Modells einfließen. Wenn Modelle diese Proben auswendig lernen (memorization), werden ihre Leistungsmetriken künstlich aufgebläht, was eher die Fähigkeit zur Auswendiglernen als echte Generalisierung widerspiegelt. Dies untergräbt die Fairness beim Vergleich von Modellen und erschwert die Bewertung echter Innovation.

Bestehende Detektionsmethoden leiden unter drei primären Einschränkungen:

Abhängigkeit von proprietären Daten: Überlappungsbasierte Methoden (z. B. n-Gramm-Matching) erfordern Zugriff auf die Trainingskorpora des Modells, die typischerweise proprietär und nicht offengelegt sind.
Spröde Heuristiken: Zeitstempel-basierte Filterung geht davon aus, dass Code, der nach dem Trainings-Cutoff veröffentlicht wurde, nicht im Korpus enthalten sein kann. Dies scheitert in der Praxis aufgrund von Code-Wiederverwendung, Vererbung und Forking.
Schwellenwert-Instabilität: Konfidenzbasierte Ansätze (z. B. Perplexity) verlassen sich auf externe Referenzdatensätze, um Entscheidungsschwellen zu kalibrieren. Diese Schwellenwerte sind oft auf natürliche Sprache abgestimmt und lassen sich nicht gut auf die strukturellen Regularitäten von Code übertragen, oder sie beruhen auf denselben fehlerhaften zeitlichen Heuristiken.

Methodik: SrDetection

Die Autoren schlagen SrDetection vor, ein einheitliches, selbstreferenzielles Framework zur Detektion von Datenleckage sowohl in Gray-Box- (Zugriff auf Modell-Logits) als auch in Black-Box-Settings (nur Zugriff auf Modell-Outputs). Die Kernhypothese lautet: Wenn ein Modell einen spezifischen Code-Sample auswendig gelernt hat, wird es ein signifikant vorhersehbareres Verhalten (niedrigere Perplexity oder höhere Generierungsähnlichkeit) gegenüber der ursprünglichen Oberflächenform zeigen als gegenüber semantisch äquivalenten Varianten.

Das Framework operiert in zwei Hauptstadien:

1. Code-Transformationsmodul

Dieses Modul generiert mithilfe eines Hilfs-LLMs eine Menge von $n$ semantisch äquivalenten Varianten ( $V = \{x_1, ..., x_n\}$ ) aus einem ursprünglichen Benchmark-Sample ( $x_0$ ). Die Transformationen sind minimal und lokal begrenzt, um das Ausführungsverhalten zu bewahren, während lexikalische und syntaktische Formen geändert werden:

Funktionsnamen-Umbenennung ( $\tau_f$ ): Ersetzt Funktionsnamen und Aufrufstellen durch semantisch äquivalente Alternativen (z. B. solve $\to$ compute).
Variablennamen-Umbenennung ( $\tau_v$ ): Ersetzt systematisch Identifikatoren und Parameter (z. B. nums $\to$ arr).
Testfall-Transformation ( $\tau_t$ ): Generiert neue, semantisch ähnliche Test-Inputs zum Original, validiert diese über die Ausführung und ersetzt die ursprünglichen Testfälle.

2. Leakage-Entscheidungsmodul

Das Framework vergleicht das Verhalten des Modells auf dem Original-Sample ( $x_0$ ) mit seinen Varianten ( $V$ ), ohne sich auf externe Schwellenwerte zu verlassen.

Gray-Box-Setting (Perplexity-basiert):
Der Detektionswert $S_M(x)$ ist die Perplexity (PPL) der Probe. Wenn das Modell $x_0$ auswendig gelernt hat, wird seine PPL niedriger sein als die der Varianten.
$\text{Leakage}_{gray}(x_0) = \mathbb{I}[S_M(x_0) < \min_{x_i \in V} S_M(x_i)]$
Wobei $\mathbb{I}$ die Indikatorfunktion ist.
Black-Box-Setting (Generierungsähnlichkeit-basiert):
Der Detektionswert $S_M(x)$ ist der N-Gramm-Überlapp (NGO) zwischen dem vom Modell generierten Suffix und dem Ground-Truth-Suffix, wenn das Modell mit einem Präfix gepromptet wird. Wenn auswendig gelernt, generiert das Modell ein Suffix, das näher am Ground Truth der Originalform liegt als das der Varianten.
$\text{Leakage}_{black}(x_0) = \mathbb{I}[S_M(x_0) > \max_{x_i \in V} S_M(x_i)]$

Konstruktion eines kontrollierten Testbeds

Um diese Methoden rigoros zu evaluieren, haben die Autoren ein kontrolliertes Leakage-Testbed konstruiert:

Datensatz-Vorbereitung: Ein öffentlicher Code-Benchmark wurde gefiltert, um Proben zu entfernen, die bereits Anzeichen von Leakage zeigten (wo das Original bereits das einfachste unter den Varianten war).
Simulierte Leakage: Modelle wurden einem Continued Pre-training auf einer Teilmenge der Daten (dem "Training"-Split) unterzogen, gemischt mit einem allgemeinen Web-Korpus, während der verbleibende Teil als "Held-out"-Testset diente. Dies schafft eine Ground Truth, in der Leakage explizit kontrolliert und bekannt ist.

Kernbeiträge

Selbstreferenzielles Framework: SrDetection eliminiert die Notwendigkeit für externe Referenzdaten oder manuell definierte Schwellenwerte, indem es den innerhalb der Probe liegenden Kontrast zwischen einem Code-Snippet und seinen semantik-erhaltenden Varianten nutzt.
Automatische Augmentierung: Eine maßgeschneiderte Methode zur Generierung von Code-Varianten, die das Auswendiglernen unter gängigen Edits (Umbenennung, Refactoring) offenlegen, während die semantische Funktionalität erhalten bleibt.
Kontrollierte Evaluierung: Die Einführung eines trainingsbasierten Testbeds, das eine präzise Messung der Leakage-Detektionsleistung über verschiedene Modelle und Trainingsstadien hinweg ermöglicht und so die Unzuverlässigkeit zeitlicher Heuristiken vermeidet.

Experimentelle Ergebnisse

Die Autoren evaluierten SrDetection gegen starke Baselines (z. B. PPL, Min-K% Prob, Zlib, VeilProbe, DPDLLM) auf continued pre-trained Qwen2.5 und LLaMA3.1 Modellen.

Leistungssteigerungen: SrDetection übertraf die Baselines signifikant.
- Gray-box: Verbesserte die durchschnittliche F1-Punktzahl um 21,52 Punkte gegenüber starken Baselines.
- Black-box: Verbesserte die durchschnittliche F1-Punktzahl um 14,46 Punkte.
Robustheit: Im Gegensatz zu Baselines, die eine instabile Leistung zeigten oder auf spezifische Epochen angewiesen waren, blieb SrDetection über verschiedene Modelle und Trainingsstadien hinweg konsistent.
Sensitivität: Die Leistung verbesserte sich mit einer höheren Anzahl an Varianten ( $n$ ), und die Methode blieb stabil über verschiedene Code-zu-Text-Mischungsverhältnisse im Pre-training-Korpus hinweg.
Reale Anwendung: Eine Studie an 15 weit verbreiteten Code LLMs auf vier Benchmarks (APPS, HumanEval, MBPP, BigCodeBench) offenbarte benchmark-spezifische Leakage-Muster. Bemerkenswert ist, dass BigCodeBench hohe Leakage-Raten im Gray-box-Setting zeigte, was darauf hindeutet, dass verhaltensbasierte Detektion Kontaminationen identifizieren kann, die eine strikte Überlappungsanalyse übersieht.

Bedeutung und Ansprüche

Das Paper behauptt, dass SrDetection eine kritische Lücke in der Evaluierung von Code LLMs schließt, indem es einen schwellenwertunabhängigen und korpusunabhängigen Detektionsmechanismus bereitstellt. Durch die Umformulierung der Leakage-Detektion als selbstreferenzielles Problem vermeidet die Methode die Sprödigkeit zeitlicher Annahmen und die Unzugänglichkeit von Trainingsdaten.

Die Autoren betonen, dass ihre Ergebnisse zeigen, dass Leakage nicht bloß ein marginaler Artefakt, sondern ein systematischer Störfaktor (Confounder) in aktuellen Evaluierungspraktiken ist. Die Fähigkeit, Leakage ohne externe Referenzen zu detektieren, legt nahe, dass benchmark-spezifische Kontaminationsmuster verbreiteter und komplexer sind, als bisher durch reine Überlappungsanalysen verstanden wurde. Die Arbeit unterstreicht die Notwendigkeit eines Leakage-bewussten Benchmark-Designs und -Reportings, um die Zuverlässigkeit von Code LLM-Evaluierungen zu gewährleisten.