Forscher der Singapore Management University haben 83 Software-Engineering-Benchmarks auf Datenlecks untersucht und dabei in einem erheblichen Teil der Testdatensätze Überschneidungen mit den Trainingsdaten gängiger Large Language Models nachgewiesen. Wenn Benchmarkdaten im Vorfeld in die Trainingsdaten eines Modells einfließen, sind gemessene Leistungswerte nicht mehr aussagekräftig. Unternehmen, die KI-Modelle anhand solcher Benchmarks auswählen, riskieren Fehlentscheidungen. Zwei unabhängige Studien von der Singapore Management University sowie der Wuhan University of Technology fordern daher systematische Prüfverfahren per Membership-Inference-Angriffen, um faire und reproduzierbare Evaluierungen zu gewährleisten.

Datenlecks in KI-Benchmarks: Zwei Studien zeigen, wie verbreitet Kontamination bei Software-Engineering-Tests ist

Wenn Sprachmodelle auf denselben Daten trainiert wurden, die später zur Leistungsmessung genutzt werden, sind Benchmark-Ergebnisse nicht mehr aussagekräftig. Zwei aktuelle Forschungsarbeiten belegen dieses Problem mit Blick auf Code-Generierungs- und Software-Engineering-Benchmarks, und liefern konkrete Methoden zur Erkennung solcher Datenlecks.

Leitfakt: 83 SE-Benchmarks, systematisch auf Datenlecks untersucht

Forscher der Singapore Management University (SMU) haben im Rahmen des Projekts “LessLeak-Bench” insgesamt 83 Software-Engineering-Benchmarks auf Datenlecks untersucht. Die Studie von Xin Zhou, Martin Weyssow, Ratnadira Widyasari, Ting Zhang, Junda He, Yunbo Lyu, Jianming Chang, Beiqi Zhang, Dan Huang und David Lo analysiert, inwiefern gängige LLMs bei Aufgaben bevorzugt abschneiden, die bereits in ihren Trainingsdaten enthalten waren. Die Autoren adressieren dabei eine grundlegende Schwierigkeit der KI-Evaluierung: Viele Modellanbieter veröffentlichen ihre Trainingsdaten nicht vollständig, was eine unabhängige Prüfung erschwert.

Parallel dazu untersucht die Studie “Keep Evaluation Fair” von Dongdong Zhao, Jian Chen, Guancheng Lin, Jianwen Xiang, Jacky Wai Keung und Xiao Yu von der Wuhan University of Technology sowie der City University of Hong Kong und der Zhejiang University, wie sogenannte Membership-Inference-Angriffe genutzt werden können, um Datenlecks in Code-Generierungs-Benchmarks zu erkennen. Die Arbeit ist im ACM-Journal TOSEM (Transactions on Software Engineering and Methodology) erschienen.

Membership Inference: Erkennen, ob Testdaten im Training steckten

Der Kernansatz der TOSEM-Studie beruht auf Membership-Inference-Angriffen (MIA). Dabei wird statistisch geprüft, ob ein bestimmter Datenpunkt dem Modell beim Training bereits begegnet ist. Das Modell verhält sich gegenüber bekannten Daten typischerweise anders als gegenüber tatsächlich neuen Eingaben, etwa durch geringere Unsicherheit oder niedrigere Verlustfunktionswerte.

Die Methodik erlaubt es, ohne Zugang zu den originalen Trainingsdaten Rückschlüsse auf mögliche Kontamination zu ziehen. Das ist besonders relevant, weil Code-Repositories wie GitHub öffentlich zugänglich sind und daher mit hoher Wahrscheinlichkeit in großen Vortrainingsdatensätzen aufgetaucht sind.

LessLeak-Bench: Systematische Kartierung über 83 Benchmarks

Die SMU-Studie erweitert die Perspektive auf das gesamte Ökosystem der Software-Engineering-Evaluierung. Laut den Autoren wirft die weitverbreitete Nutzung von LLMs für Aufgaben wie Code-Generierung und automatisierte Programmkorrektur erhebliche Fragen zur Validität der Ergebnisse auf, solange die Trainingsdaten nicht offengelegt werden.

“LessLeak-Bench” stellt eine erste systematische Untersuchung dar, die über einzelne Benchmarks hinausgeht und die Breite des Problems kartiert. Die Studie ordnet sich in eine wachsende Forschungsrichtung ein, die sich mit der Reproduzierbarkeitskrise bei LLM-Evaluierungen befasst, wie sie auch beim LLM-Benchmark-Methoden-Vergleich zu Datenkontamination und Reproduzierbarkeit sowie bei der Analyse von Benchmark-Manipulation und synthetischer Datenkontamination dokumentiert wird.

4 praktische Implikationen für Entscheider

1. Benchmark-Ergebnisse von Anbietern nicht unkritisch übernehmen Wenn ein Modell auf einem Code-Generierungs-Benchmark besonders gut abschneidet, kann das darauf hinweisen, dass die Testaufgaben im Training enthalten waren. Entscheider sollten verlangen, dass Evaluierungen auf separaten, intern erstellten oder nach dem Trainingsschnitt veröffentlichten Testmengen basieren. Vergleiche zwischen Herstellerangaben und unabhängigen Messungen sind dabei ein wichtiger Orientierungsrahmen.

2. Eigene Evaluierungsumgebungen aufbauen Für Unternehmen, die LLMs in der Softwareentwicklung einsetzen, z. B. für Code-Review, automatische Testgenerierung oder Bug-Fixing, empfiehlt sich der Aufbau interner Testsuiten mit propriätären Codebasen. Diese sind mit hoher Wahrscheinlichkeit nicht in öffentlich zugänglichen Trainingsdaten enthalten und liefern damit aussagekräftigere Leistungsvergleiche.

3. Dynamische und kontaminationsresistente Benchmarks bevorzugen Statische Benchmarks veralten schnell, sobald sie öffentlich bekannt sind. Methoden wie LiveBench, die Testfragen kontinuierlich aktualisieren, bieten strukturell mehr Schutz vor Datenlecks als historische, unveränderliche Datensätze. Die Validierungsmethoden unterscheiden sich dabei erheblich, wie ein Vergleich von LessLeak-Bench mit anderen Leaderboard-Ansätzen zeigt.

4. Transparenzanforderungen an Anbieter stellen Unternehmen sollten beim Anbietergespräch gezielt nach dem Datenausschlussprotokoll fragen: Welche Benchmarks wurden explizit aus den Trainingsdaten herausgefiltert? Wie wird das verifiziert? Diese Fragen gewinnen im Kontext des EU AI Acts an Gewicht, der Transparenz- und Dokumentationspflichten für Anbieter von Allzweck-KI-Modellen vorsieht, wie bei der Konformitätsbewertung für Foundation Models erläutert wird.

Einordnung: Strukturelles Problem, kein Einzelfall

Beide Studien behandeln kein Randphänomen. Öffentlich verfügbare Code-Benchmarks wie HumanEval oder SWE-bench sind seit Jahren bekannt und werden intensiv in der Forschung genutzt. Damit steigt die Wahrscheinlichkeit, dass sie in den Crawl-Daten großer Modelle enthalten sind, mit jeder neuen Modellgeneration. Die Membership-Inference-Methodik bietet erstmals einen statistisch fundierten Ansatz, um dieses Risiko auch ohne Zugang zu den originalen Trainingsdaten zu quantifizieren.

Für den Einsatz in der Praxis bedeutet das: Modellauswahl und -evaluierung sollten nicht allein auf publizierten Leaderboard-Ergebnissen basieren. Unabhängige Validierungsmethoden, wie sie auch im Stanford HAI AI Index 2025 und bei Papers with Code dokumentiert werden, bilden eine notwendige Ergänzung zur herstellerseitigen Kommunikation.

Quellen

• Keep Evaluation Fair: Detecting Data Leakage in Code Generation Benchmarks via Membership Inference Attacks – Dongdong Zhao et al., TOSEM, Wuhan University of Technology / City University of Hong Kong / Zhejiang University
• LessLeak-Bench: A First Investigation of Data Leakage in LLMs Across 83 Software Engineering Benchmarks – Xin Zhou et al., Singapore Management University, 2024

Häufige Fragen

Was versteht man unter Data Leakage in LLM-Evaluierungen, und warum ist das für Unternehmen relevant?

Data Leakage bezeichnet in diesem Kontext das Phänomen, dass Benchmarkdaten, die zur Bewertung von Large Language Models genutzt werden, bereits im Vortraining der Modelle enthalten waren. Die Folge: Bewertungsergebnisse spiegeln nicht die tatsächliche Generalisierungsfähigkeit eines Modells wider, sondern teilweise das bloße Wiedererkennen von Trainingsdaten. Für Unternehmen, die Kaufentscheidungen auf Basis von Benchmark-Rankings treffen, bedeutet das ein erhebliches Risiko für Fehleinschätzungen bei der Modellauswahl.

Wie weit verbreitet ist das Leakage-Problem in Software-Engineering-Benchmarks konkret?

Forscher der Singapore Management University haben im Rahmen der LessLeak-Bench-Studie insgesamt 83 Software-Engineering-Benchmarks systematisch untersucht. Die Ergebnisse zeigen, dass Data Leakage in diesem Bereich kein Randphänomen ist, sondern weit verbreitet auftritt. Betroffen sind unter anderem Benchmarks zu Code-Generierung und automatischer Programm-Reparatur, also zentrale Bewertungsfelder für den praktischen KI-Einsatz in der Softwareentwicklung.

Welche Methode nutzen Forschende, um Datenlecks in Benchmarks nachzuweisen?

Ein zentrales Verfahren sind sogenannte Membership Inference Attacks. Dabei wird statistisch geprüft, ob ein Modell auf bestimmte Datenpunkte so reagiert, als hätte es sie im Training gesehen. Dongdong Zhao und Kollegen der Wuhan University of Technology sowie der City University of Hong Kong haben diesen Ansatz gezielt auf Code-Generierungs-Benchmarks angewendet und in der Fachzeitschrift TOSEM veröffentlicht. Die Methode ermöglicht es, Leakage auch dann aufzudecken, wenn Modellanbieter keine Auskunft über ihre Trainingsdaten geben.

Warum ist es so schwierig, Datenlecks zu verhindern, wenn Trainingsdaten nicht offengelegt werden?

Die meisten kommerziellen und auch viele Open-Source-Modelle trainieren auf umfangreichen, nicht vollständig dokumentierten Datensätzen. Da Modellanbieter ihre Vortrainingsdaten in der Regel nicht vollständig offenlegen, können externe Evaluatoren nicht direkt prüfen, ob Benchmarkdaten enthalten waren. Genau diese Intransparenz ist laut den Forschungsarbeiten der Singapore Management University der Kern des Problems: Ohne Zugang zu den Trainingsdaten bleibt die Validität von Benchmark-Ergebnissen grundsätzlich unsicher.

Welche Konsequenzen sollten Entscheider aus diesen Erkenntnissen ziehen?

Entscheider sollten Benchmark-Ergebnisse von LLM-Anbietern kritisch einordnen und nicht als alleinige Grundlage für Modellvergleiche verwenden. Ergänzende interne Tests auf eigenen, nicht öffentlich zugänglichen Datensätzen reduzieren das Risiko, Leakage-verzerrten Ergebnissen aufzusitzen. Zudem sollten bei der Anbieterauswahl Transparenzanforderungen zu Trainingsdaten stärker gewichtet werden. Forschungsansätze wie Membership Inference Attacks bieten perspektivisch auch für Unternehmen ein Instrument zur unabhängigen Überprüfung.

Dieser Artikel wurde von einem KI-System automatisiert erstellt. Kennzeichnung gemäß Art. 50 der EU-KI-Verordnung.