Zwei unabhängige Studien zeigen: Gängige LLM-Benchmarks sind durch Trainingsdaten-Kontamination verfälscht. Die Singapore Management University untersuchte 83 Software-Engineering-Benchmarks auf Datenlecks; MBZUAI-Forscher simulierten kontrollierte Leakage-Szenarien in Multiple-Choice-Tests. Steigende Benchmark-Scores von LLMs sagen wenig aus, wenn Evaluierungsdaten bereits im Training enthalten waren. Da Anbieter ihre Trainingsdaten kaum offenlegen, können Unternehmen veröffentlichte Modelleistungen nicht blind vertrauen. Automatisierte Detektionsverfahren wie Permutation-, N-Gramm- und Semi-Half-Question-Methoden helfen, solche Kontaminationen aufzudecken und Kaufentscheidungen auf belastbarere Vergleichswerte zu stützen.

Trainings-Kontamination in LLM-Benchmarks: Neue Detektionsmethoden im Vergleich

Steigende Benchmark-Scores großer Sprachmodelle sagen wenig über deren tatsächliche Leistungsfähigkeit aus, wenn Teile der Evaluierungsdaten bereits im Training enthalten waren. Zwei aktuelle Studien untersuchen systematisch, wie sich solche Datenleckagen erkennen lassen und wie weit verbreitet das Problem in der Praxis ist.

Leitfakt: Kontrollierte Simulation deckt Schwächen gängiger Detektionsmethoden auf

Forscher der Mohamed bin Zayed University of Artificial Intelligence (MBZUAI) und der Universitas Indonesia haben in einer aktuellen Arbeit bestehende Verfahren zur Leckage-Erkennung erstmals unter kontrollierten Simulationsbedingungen verglichen. Konkret wurden Permutations- und N-Gramm-basierte Methoden in einem Continual-Pretraining-Setup getestet, das reale Leckage-Szenarien nachbildet. Ergänzend evaluierten die Autoren eine von ihnen entwickelte, leichtgewichtige Methode namens “Semi-Half Question”. Bisherige Ansätze konzentrierten sich laut der Studie primär auf die Erkennung statistischer Ausreißer, ohne unter solchen kontrollierten Leckage-Bedingungen validiert worden zu sein.

Parallel dazu haben Forscher der Singapore Management University sowie der Southeast University und der Wuhan University mit LessLeak-Bench eine umfassende Untersuchung vorgelegt: Sie analysierten 83 Software-Engineering-Benchmarks auf Datenleckagen in großen Sprachmodellen. Beide Arbeiten zeigen, dass die mangelnde Transparenz über Trainingsdaten die Aussagekraft veröffentlichter Benchmark-Ergebnisse systematisch untergräbt.

Praktische Implikationen für Entscheider

1. Benchmark-Ergebnisse von Modellanbietern kritisch einordnen

Wer LLM-Anbieter auf Basis publizierter Leistungsdaten auswählt, sollte berücksichtigen, dass die zugrundeliegenden Evaluierungsdaten möglicherweise Bestandteil des Vortrainings waren. Da Trainingsdatensätze branchenüblich nicht vollständig offengelegt werden, lässt sich eine solche Überschneidung von außen kaum direkt nachweisen. Unternehmen sollten daher Benchmark-Angaben von Herstellern mit unabhängig erhobenen Messwerten abgleichen. Weiterführende Hintergründe dazu finden Sie in unserer Analyse zur Datenkontamination in LLM-Benchmarks sowie zur Benchmark-Manipulation und Leaderboard-Gaming.

2. Software-Engineering-Benchmarks besonders sorgfältig prüfen

Die LessLeak-Bench-Studie richtet den Fokus explizit auf Software-Engineering-Aufgaben wie Code-Generierung und automatisierte Programm-Reparatur. Gerade in diesem Bereich sind Benchmark-Datensätze häufig öffentlich zugänglich und damit potenziell in Trainingspipelines eingeflossen. Wer LLMs für Entwickleraufgaben einsetzt, sollte interne Evaluierungen mit aufgabenspezifischen, nicht öffentlich bekannten Testfällen ergänzen.

3. Methodenauswahl bei eigenen Kontaminationstests

Für Unternehmen, die eigene Evaluierungsrahmen aufbauen, liefern beide Studien methodische Orientierung. Die Permutations- und N-Gramm-basierten Verfahren sind etabliert, zeigen aber unter simulierten Leckage-Bedingungen Grenzen. Der Semi-Half-Question-Ansatz bietet laut der MBZUAI-Studie eine leichtgewichtige Alternative, deren praktische Eignung unter verschiedenen Szenarien jedoch weiter untersucht werden muss. Die Wahl der Detektionsmethode beeinflusst unmittelbar, ob eine Kontamination erkannt wird oder unentdeckt bleibt. Eine Einordnung aktueller Evaluierungsstandards liefert auch unser Beitrag zu LLM-Benchmarks und der Reproduzierbarkeitskrise.

4. Regulatorische Anforderungen im Blick behalten

Die fehlende Transparenz über Trainingsdaten ist nicht nur ein Qualitätsproblem, sondern zunehmend auch eine Compliance-Frage. Der EU AI Act schreibt für General-Purpose-AI-Modelle Dokumentationspflichten vor, die auch Trainingsdaten betreffen. Unternehmen, die auf solche Modelle setzen, sind gut beraten, von Anbietern entsprechende Nachweise einzufordern. Hintergründe zu den regulatorischen Anforderungen finden Sie in unserem Artikel zu den GPAI-Notifizierungspflichten im EU AI Act sowie zur Konformitätsbewertung von Foundation Models.

Quellen

• Simulating Training Data Leakage in Multiple-Choice Benchmarks for LLM Evaluation (ar5iv / arxiv, 2025)
• LessLeak-Bench: A First Investigation of Data Leakage in LLMs Across 83 Software Engineering Benchmarks (arxiv, 2025)

Häufige Fragen

Was versteht man unter Trainings-Kontamination bei LLM-Benchmarks?

Trainings-Kontamination bezeichnet die Überschneidung zwischen den Trainingsdaten eines Large Language Models und den Datensätzen, die zur Leistungsbewertung genutzt werden. Da viele Anbieter ihre Trainingsdaten nicht vollständig offenlegen, lässt sich nicht ohne Weiteres ausschließen, dass ein Modell Benchmark-Fragen bereits während des Vortrainings gesehen hat. Dies kann dazu führen, dass berichtete Benchmark-Ergebnisse die tatsächliche Generalisierungsfähigkeit eines Modells überschätzen.

Welche Methoden zur automatisierten Erkennung von Datenlecks werden in der aktuellen Forschung untersucht?

Aktuelle Forschungsarbeiten, darunter eine Studie von Al Kautsar, Wicaksono und Koto (MBZUAI und Universitas Indonesia), vergleichen mehrere Ansätze: permutationsbasierte Verfahren, n-Gramm-basierte Methoden sowie eine leichtgewichtige Technik namens ‘Semi-Half Question’. Letztere testet, ob ein Modell eine Frage anhand ihres ersten Abschnitts vervollständigen kann, was auf eine Memorisierung der Trainingsdaten hindeuten würde. Die Methoden wurden unter kontrollierten, simulierten Leakage-Bedingungen mit kontinuierlichem Vortraining verglichen.

Wie umfangreich ist das Problem im Bereich Software-Engineering-Benchmarks?

Forscher der Singapore Management University haben im Rahmen des LessLeak-Bench-Projekts insgesamt 83 Software-Engineering-Benchmarks systematisch auf Datenlecks untersucht. Dabei wurden Aufgaben wie Code-Generierung und automatisierte Programmkorrektur berücksichtigt. Die Studie stellt die bislang erste breit angelegte Untersuchung dieser Art im Software-Engineering-Bereich dar und zeigt, dass die mangelnde Transparenz bei Vortrainingsdaten ein strukturelles Problem für die Vergleichbarkeit von Modellevaluierungen darstellt.

Warum reichen bisherige Erkennungsmethoden laut Forschung nicht aus?

Ein zentrales Problem bisheriger Ansätze besteht daut der Studie von Al Kautsar et al. darin, dass sie primär auf Ausreißer-Erkennung ausgelegt sind und nicht unter kontrollierten, simulierten Leakage-Szenarien validiert wurden. Das bedeutet: Es fehlte bisher ein standardisierter Testrahmen, der prüft, wie zuverlässig eine Methode echte Kontaminationen erkennt. Die Forschenden adressieren diese Lücke, indem sie eine kontinuierliche Vortrainings-Umgebung einsetzen, um reale Leakage-Bedingungen nachzubilden.

Welche praktischen Konsequenzen hat Benchmark-Kontamination für Unternehmen, die LLMs evaluieren?

Für Entscheider bedeutet Benchmark-Kontamination, dass veröffentlichte Modell-Scores mit Vorsicht zu interpretieren sind. Ein Modell, das Benchmark-Fragen im Training gesehen hat, erzielt möglicherweise höhere Punktzahlen, ohne dass dies seiner tatsächlichen Leistung in realen Anwendungsfällen entspricht. Unternehmen, die Modelle anhand gängiger Benchmarks vergleichen, etwa für Code-Generierung oder automatisierte Softwaretests, riskieren Fehlentscheidungen bei der Modellauswahl, wenn keine unabhängigen oder kontaminationsfreien Evaluierungsverfahren eingesetzt werden.

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