💻 computer science

Learned or Memorized ? Quantifying Memorization Advantage in Code LLMs

Die Studie entwickelt eine störungsbasierte Methode zur Quantifizierung des Memorization-Vorteils in Code-LLMs, zeigt auf Basis von 19 Benchmarks und 8 Modellen, dass das Ausmaß des Auswendiglernens stark von Modell, Aufgabe und Kontext abhängt, und stellt fest, dass bei den umstrittenen Benchmarks CVEFixes und Defects4J die Generalisierungsfähigkeit gegenüber direktem Memorization überwiegt.

Ursprüngliche Autoren: Djiré Albérick Euraste, Kaboré Abdoul Kader, Jordan Samhi, Earl T. Barr, Jacques Klein, Tegawendé F. Bissyandé

Veröffentlicht 2026-04-16

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Djiré Albérick Euraste, Kaboré Abdoul Kader, Jordan Samhi, Earl T. Barr, Jacques Klein, Tegawendé F. Bissyandé

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

🧠 Lernen oder Auswendiglernen? Ein Test für KI-Programmierer

Stellen Sie sich vor, Sie haben einen sehr schlauen Schüler, der für eine große Prüfung gelernt hat. Die Frage ist: Hat er die Antworten wirklich verstanden, oder hat er sich nur die Lösungen der alten Prüfungen auswendig gelernt?

Wenn Sie ihm eine fast identische, aber leicht veränderte Frage stellen (z. B. statt "2+2" fragen "2+2, aber in einer anderen Schriftart"), kann ein Schüler, der es wirklich verstanden hat, die Antwort immer noch finden. Ein Schüler, der nur auswendig gelernt hat, wird jedoch panisch und macht Fehler, weil die Frage nicht exakt so lautet wie im Buch.

Genau das haben die Forscher in diesem Papier untersucht. Sie wollten herausfinden, ob Code-KI-Modelle (wie StarCoder oder CodeLlama) wirklich programmieren können oder ob sie sich nur Code-Schnipsel aus ihrem Trainingsmaterial gemerkt haben.

🕵️‍♂️ Die Methode: Der "Verzerrungs-Test"

Die Forscher haben einen cleveren Trick angewendet, den sie "Perturbation" (Verzerrung) nennen.

Stellen Sie sich vor, Sie geben der KI einen Code-Auftrag: "Schreibe eine Funktion, die die Summe der Zahlen von 1 bis 10 berechnet."
Die KI gibt eine perfekte Antwort.

Dann verändern die Forscher den Auftrag ganz leicht, aber so, dass ein Mensch den Sinn immer noch versteht:

Statt "Schreibe eine Funktion..." sagen sie: "Erstelle ein Skript, das..."
Statt "Summe" sagen sie: "Gesamtwert".
Oder sie ändern die Variablennamen im Code von x zu meinGeheimesX.

Das Ergebnis:

Echte Intelligenz (Generalisierung): Die KI sagt: "Ach ja, das ist das Gleiche!" und liefert immer noch die richtige Lösung.
Auswendiglernen (Memorization): Die KI stolpert. Sie sagt: "Moment, das steht nicht in meinem Buch!" und liefert einen Fehler oder eine falsche Antwort.

Je mehr Fehler die KI bei diesen kleinen Änderungen macht, desto höher ist ihr "Auswendiglern-Vorteil". Das klingt paradox, ist aber ein schlechtes Zeichen: Es bedeutet, sie hat nicht gelernt, sondern nur kopiert.

📊 Was haben sie herausgefunden?

Die Forscher haben 8 verschiedene KI-Modelle an 19 verschiedenen Aufgaben getestet. Hier sind die wichtigsten Erkenntnisse, übersetzt in Alltagssprache:

1. Nicht alle KIs sind gleich (Der StarCoder-Fehler)

Einige Modelle, wie QwenCoder oder CodeLlama, waren sehr robust. Sie haben auch bei leicht veränderten Fragen gute Antworten geliefert. Sie haben die Konzepte verstanden.
Aber StarCoder hatte ein Problem. Bei einem bestimmten Test (dem "APPS"-Test) fiel er extrem oft durch, sobald die Frage leicht umformuliert wurde.

Die Metapher: StarCoder hat sich wie ein Schüler verhalten, der die Lösungen für den "APPS"-Test auswendig gelernt hat. Sobald der Lehrer die Aufgabenstellung nur ein wenig ändert, weiß er nichts mehr. Das deutet stark darauf hin, dass dieser Test in den Trainingsdaten von StarCoder enthalten war und die KI sich einfach nur die Antworten gemerkt hat.

2. Die "Sicherheits-Tests" sind überraschend gut

In der Forschung gab es große Sorgen, dass zwei berühmte Datensätze (CVEFixes und Defects4J), die für Sicherheitslücken und Programmfehler genutzt werden, von den KIs einfach auswendig gelernt wurden. Man dachte, die KI sei nur gut, weil sie die Lösungen kennt.

Die Überraschung: Die Forscher haben festgestellt: Nein! Die KIs haben bei diesen Tests sehr wenig "Auswendiglern-Signale" gezeigt. Sie haben die Fehler wirklich verstanden und konnten sie auch bei veränderten Codes finden. Die Sorge um "Daten-Lecks" war hier also unbegründet. Die KIs haben hier wirklich gelernt, nicht nur kopiert.

3. Was ist leicht, was ist schwer?

Code-Zusammenfassung (Code Summarization): Das ist wie ein Koch, der ein Rezept in eine Geschichte verwandelt. Hier waren alle KIs super. Sie haben die Zusammenhänge sehr gut verstanden.
Test-Generierung: Das ist wie ein Prüfer, der für eine Prüfung Fragen erfinden muss. Hier hatten die KIs große Schwierigkeiten. Sie waren sehr empfindlich gegenüber kleinen Änderungen. Es ist also eine Aufgabe, bei der die KIs noch nicht wirklich "klug" sind, sondern oft nur raten oder Muster erkennen.

💡 Warum ist das wichtig?

Stellen Sie sich vor, Sie bauen eine KI, die Sicherheitslücken in Banken-Software findet.

Wenn die KI nur auswendig gelernt hat, wird sie vielleicht die bekannten Lücken finden, aber bei einer neuen, leicht veränderten Lücke versagen. Das wäre gefährlich.
Wenn die KI generalisiert (verstanden hat), kann sie auch neue, unbekannte Lücken erkennen.

Die Forscher sagen uns: Wir müssen aufhören, nur auf die Punktzahl zu schauen. Eine hohe Punktzahl auf einem alten Test bedeutet nicht automatisch, dass die KI gut ist. Sie könnte sich nur die Antworten gemerkt haben.

🚀 Fazit für die Zukunft

Die Studie schlägt vor, dass wir KI-Modelle nicht mehr nur mit statischen Tests prüfen sollen (wie ein alter Schulzettel), sondern mit dynamischen Tests, die sich ständig ändern.

Für Entwickler: Es reicht nicht, einfach nur mehr Daten zu füttern. Die Art und Weise, wie die KI gebaut wird (die Architektur), ist wichtiger für das echte Verständnis.
Für die Öffentlichkeit: Wir sollten skeptisch sein, wenn eine KI in einem Test perfekt abschneidet. Wahre Intelligenz zeigt sich erst dann, wenn die Frage leicht verändert wird und die KI trotzdem die richtige Antwort findet.

Kurz gesagt: Die KI hat in manchen Fächern (wie Zusammenfassen) wirklich gelernt, in anderen (wie Test schreiben) noch viel zu tun, und bei manchen Tests (wie StarCoder bei APPS) hat sie sich leider nur die Lösungen gemerkt. Wir müssen also aufpassen, dass wir nicht getäuscht werden!

1. Problemstellung

Die Transparenz bezüglich der Trainingsdaten von Large Language Models (LLMs) für Code ist stark eingeschränkt. Dies erschwert die Erkennung, Bewertung und Minderung von Datenlecks (Data Leakage). Ein zentrales Problem ist die Unterscheidung zwischen echter Generalisierung (das Modell hat Konzepte verstanden) und Auswendiglernen (Memorization), bei dem das Modell Trainingsdaten lediglich reproduziert.

Herkömmliche Evaluierungsmethoden sind oft unzureichend, da sie entweder interne Modelldetails erfordern oder Annahmen über die Trainingsdaten treffen müssen. Zudem gibt es in der Forschung Community die Sorge, dass viele etablierte Benchmarks (wie CVEFixes oder Defects4J) versehentlich in den Trainingsdaten enthalten waren, was zu überhöhten Leistungswerten führt. Das Paper zielt darauf ab, diesen „Memorization-Vorteil" (den Leistungsunterschied zwischen gesehenen und ungesehenen Daten) quantitativ zu messen.

2. Methodik: Perturbationsbasierte Sensitivitätsanalyse

Die Autoren entwickeln einen Rahmen, der auf der Perturbation Sensitivity Hypothesis (PSH) basiert. Die Grundannahme ist:

Auswendiglernen: Wenn ein Modell einen spezifischen Codeabschnitt auswendig gelernt hat, führt bereits eine kleine, semantisch neutrale Störung (Perturbation) des Eingabeinputs zu einem drastischen Leistungsabfall.
Generalisierung: Wenn das Modell die zugrundeliegenden Muster verstanden hat, bleibt die Leistung auch bei gestörten Inputs relativ stabil.

Der Messansatz:

Perturbation: Für jeden Eingabe-Input werden schrittweise verstärkte, aber semantisch äquivalente Variationen erzeugt.
- Für NL2Code-Aufgaben (z. B. Code-Generierung aus Text): Paraphrasierung der Prompts mittels BART-Modell.
- Für Code2Code oder Code2NL-Aufgaben: Umbenennung von Variablen (Alpha-Renaming) mit zufälligen Bezeichnern.
Messung: Das Modell wird auf den Original-Input und die gestörten Inputs angewendet. Die Leistung wird gemessen (z. B. durch Edit-Distance oder Test-Pass-Rate).
Berechnung des Memorization-Vorteils ($ma$): Es wird die maximale Leistungsabnahme (Performance Falloff) zwischen aufeinanderfolgenden Perturbationsstufen berechnet.
- Hohe Sensitivität (großer Leistungsabfall) $\rightarrow$ Hinweis auf Auswendiglernen.
- Niedrige Sensitivität (stabile Leistung) $\rightarrow$ Hinweis auf Generalisierung.

Statistische Signifikanz wird mittels des Mann-Whitney-U-Tests (mit Bonferroni-Korrektur) geprüft.

3. Experimentelles Setup

Modelle: 8 Open-Source Code-LLMs wurden evaluiert (DeepSeek-Coder-V2, Qwen2.5-Coder, StarCoder, CodeLlama, Codestral, OpenCoder, WizardCoder, Magicoder).
Benchmarks: 19 Datensätze über 5 Hauptkategorien der Softwaretechnik:
- Code-Generierung (z. B. HumanEval, APPS, MBPP)
- Test-Generierung (z. B. BigCodeBench, TestEval)
- Programmreparatur (z. B. Defects4J, ConDefects, QuixBugs)
- Schwachstellenerkennung (z. B. CVEFixes, DiverseVul)
- Code-Zusammenfassung (z. B. CodeSearchNet)

4. Wichtige Ergebnisse

A. Aufgabenabhängige Generalisierung

Code-Zusammenfassung: Zeigt die geringste Sensitivität (< 0,3) über alle Modelle hinweg. Dies deutet auf eine sehr robuste Generalisierungsfähigkeit hin, vermutlich aufgrund der Fülle an Code-Dokumentations-Paaren in den Trainingsdaten.
Test-Generierung: Zeigt signifikant höhere Sensitivität (0,4–0,7) als reine Code-Generierung. Dies deutet darauf hin, dass das Verstehen von Code zur Erstellung von Tests eine komplexere Generalisierungsleistung erfordert.
Programmreparatur: Zeigt gemischte Ergebnisse. ConDefects (kontextabhängige Bugs) zeigen hohe Sensitivität, während Defects4J überraschend niedrige Werte (0,2–0,4) aufweist.

B. Modell-spezifische Unterschiede

StarCoder zeigt auf bestimmten Benchmarks (insbesondere APPS) eine extrem hohe Sensitivität (bis zu 0,8), was stark auf Auswendiglernen oder Datenkontamination hindeutet.
QwenCoder und CodeLlama zeigen konsistent niedrigere Sensitivitätswerte (< 0,4), was auf bessere Generalisierungsfähigkeiten schließen lässt.
Modelle mit ähnlicher Parametergröße zeigen stark unterschiedliche Muster, was beweist, dass Architektur und Trainingsmethoden entscheidender sind als reine Skalierung.

C. Herausforderung etablierter Benchmarks (Datenlecks)

Ein zentrales Ergebnis ist die Widerlegung gängiger Annahmen über Datenlecks bei bestimmten Benchmarks:

CVEFixes: Zeigt konsistent extrem niedrige Sensitivität (< 0,1) über alle Modelle. Dies widerlegt die Sorge, dass Modelle hier nur CVEs auswendig gelernt haben; sie haben vielmehr die zugrundeliegenden Schwachstellenmuster generalisiert.
Defects4J: Zeigt ebenfalls signifikant niedrigere Sensitivität als andere Reparatur-Benchmarks. Die hohen Leistungen auf diesem Benchmark sind also wahrscheinlich auf echte Generalisierung zurückzuführen und nicht auf Datenlecks.

5. Hauptbeiträge

Empirischer Rahmen: Einführung einer perturbationsbasierten Methode zur Quantifizierung des „Memorization Advantage" in Code-LLMs.
Umfassende Evaluation: Analyse von 8 State-of-the-Art-Modellen über 19 Benchmarks hinweg.
Neue Erkenntnisse zu Benchmarks: Statistische Beweise, dass weit verbreitete Benchmarks wie CVEFixes und Defects4J nicht notwendigerweise durch Datenlecks verzerrt sind, sondern echte Generalisierung abbilden.
Architektureinfluss: Nachweis, dass Trainingsmethoden und Architekturdesign (nicht nur Parametergröße) die Generalisierungsfähigkeit maßgeblich beeinflussen.
Aufgaben-spezifische Grenzen: Identifikation, dass Test-Generierung und kontextabhängige Reparatur die größten Generalisierungsherausforderungen darstellen, während Zusammenfassung am robustesten ist.

6. Bedeutung und Implikationen

Für die Evaluation: Die Arbeit fordert einen Paradigmenwechsel weg von reinen Leistungsmetriken (Accuracy/Pass@k) hin zu Perturbations-Sensitivitätsanalysen. Nur so kann zwischen Auswendiglernen und echtem Verständnis unterschieden werden.
Für die Sicherheit: Im Bereich der Schwachstellenerkennung ist die hohe Variabilität der Sensitivität (von <0,1 bis >0,8) besorgniserregend. Modelle könnten bei bestimmten Aufgaben auf Auswendiglernen basieren, was in sicherheitskritischen Kontexten zu falschem Vertrauen führt.
Für die Forschung: Die Ergebnisse legen nahe, dass dynamische Benchmarks (die regelmäßig aktualisiert werden) und perturbationsbasierte Evaluierungen zum Standard werden sollten, um die wahre Generalisierungsfähigkeit von KI-Modellen in der Softwareentwicklung zu messen.

Zusammenfassend liefert das Paper kritische Einblicke in die „Black Box" der Code-LLMs und zeigt, dass hohe Benchmark-Ergebnisse nicht automatisch Datenlecks bedeuten, sondern je nach Aufgabe und Modell unterschiedliche Generalisierungsmechanismen widerspiegeln können.