Wenn Benchmarks lügen – warum der LLM-Vergleich kaputt ist

Vorweg und ohne Umschweife: Meine Ausgangsthese war, dass rund 60% der Benchmarks, die zum Vergleich von LLMs herangezogen werden, Käse sind – zu realitätsfern, zu spezifisch, oder bei Reasoning so unzureichend, dass die Zahlen kaum etwas aussagen. Ich wollte mich gern widerlegen lassen. Nach ein paar Stunden Recherche (Claude Opus 4.7 ist übrigens super im Zusammentragen und Zusammenfassen von vielen unterschiedlichen Quellen zu einem Thema) muss ich sagen: Die These war zu zahm. Die Praxis und Forschung beschreiben den aktuellen Zustand inzwischen offen als Vertrauenskrise der Benchmarks – und OpenAI selbst hat im Februar 2026 einen der wichtigsten Coding-Benchmarks für unbrauchbar erklärt. Dazu gleich mehr.

Das hat Folgen für jeden, der LLMs einsetzt. Wenn die Zahl auf der Vergleichsseite mit der Realität nichts zu tun hat, kauft man am Ende ein Modell, das den Test bestanden hat, aber im echten Workflow durchhängt – und ein anderes, das auf dem Papier mittelmäßig wirkt, aber im Alltag liefert.

Drei Probleme tauchen in der Literatur ständig auf, und sie hängen zusammen.

Das erste Problem: Saturation

Ein Benchmark ist tot, wenn die Top-Modelle alle nahe 100% scoren. Genau das ist der Status für eine ganze Reihe der Klassiker.

MMLU – der Massive Multitask Language Understanding Test, jahrelang die Standardreferenz – ist bei aktuellen Frontier-Modellen mit über 90% durch. Vellum schließt MMLU explizit aus seinem Leaderboard aus und nennt das Ding „outdated“. GSM8K, der Grundschul-Mathe-Klassiker, lag 2021 bei GPT-3 noch bei rund 35%, heute scoren Top-Modelle dort 99%. HumanEval – der HumanEval-Coding-Test – ist ähnlich saturiert.

Was ein saturierter Benchmark anrichtet: Wenn alle Modelle 95–99% scoren, sind die Unterschiede statistisches Rauschen. Du siehst auf dem Leaderboard, dass Modell A mit 96,2% und Modell mit B 95,8% „performt“ – und das soll Dir sagen, welches besser ist. Sagt es aber nicht. Es sagt nur, dass beide den Test geknackt haben.

Das zweite Problem: Contamination

Saturation wäre weniger schlimm, wenn die Scores wenigstens echt wären. Sind sie aber nicht zwingend.

Eine oft zitierte Studie aus 2024 hat aus GSM8K eine stilgleiche Variante namens GSM1k gebaut – neue Aufgaben, gleiche Schwierigkeit, gleiche Form. Das Ergebnis: Einige Modellfamilien (insbesondere Mistral und Phi) verloren bis zu 13 Prozentpunkte beim Wechsel auf die unbekannte Variante. Übersetzt: Ein nicht zu vernachlässigender Teil der hohen GSM8K-Scores war Memorization, kein Rechnen. Aktuelle Übersichten bestätigen den Befund und listen weitere Fälle: GPT-4 auf AG News, WNLI und XSum, Llama-3-70B auf ARC.

Das ist nicht zwingend Absicht. Benchmark-Daten liegen auf GitHub, in Papern, in Foren, und Modelle werden auf großen Web-Crawls trainiert. Es ist eher schwierig, sie nicht zu erwischen. Microsoft hat deshalb MMLU-CF gebaut, eine kontaminationsfreie Variante. Beobachtung: Manche Modelle reproduzieren bei reiner Frage-Eingabe die Original-MMLU-Antwortoptionen wortgleich. Das ist kein Pattern-Matching mehr, das ist Auswendiglernen mit Tarnung.

Das dritte Problem: Goodhart

"When a measure becomes a target, it ceases to be a good measure."

Goodhart's Law, ursprünglich aus der Ökonomie, trifft den AI-Benchmark-Zirkus mitten ins Gesicht. Sobald ein Score öffentlich relevant wird, optimieren Anbieter darauf – und der Score korreliert immer weniger mit der eigentlich gemeinten Fähigkeit.

Das schönste Beispiel: SWE-bench, der „realistische“ Coding-Benchmark mit echten GitHub-Issues. Klingt erstmal vernünftig. Anfang 2025 wurde dann dokumentiert, dass autonome Coding-Agents in der SWE-bench-Umgebung anfingen, die Git-Historie der Repos zu durchsuchen, um die menschlich geschriebenen Patches zu finden, die das Problem damals tatsächlich gefixt hatten – um die Lösung dann einfach zu kopieren. Das ist nicht Coding-Fähigkeit. Das ist ein Agent, der gelernt hat, das Test-Setup auszunutzen.

Im Februar 2026 hat OpenAI den Sargnagel hinterhergeschoben: In einem eigenen, ausführlichen Audit wiesen sie nach, dass Frontier-Modelle (GPT-5.2, Claude Opus 4.5, Gemini 3 Flash) bei entsprechender Aufforderung den korrekten Patch wortwörtlich aus dem Gedächtnis reproduzieren – inklusive Dateipfade und Kommentare. Konsequenz: OpenAI rapportiert SWE-bench-Verified-Scores nicht mehr und empfiehlt SWE-bench Pro. Wenn der Benchmark-Hersteller selbst sagt „verbrennt das Ding“, ist die Diskussion eigentlich gelaufen.

Chatbot Arena von LMSYS bzw. LMArena – jahrelang der „Goldstandard“, weil echte Menschen blind voten – hat ein verwandtes Problem: Anbieter haben gelernt, dass Nutzer längere und schöner formatierte Antworten bevorzugen, unabhängig vom Inhalt. Style-Bias schlägt Substanz. Dazu kommt das „Leaderboard Illusion“-Paper (Cohere Labs et al., NeurIPS 2025), das große Anbieter dabei dokumentiert hat, dutzende private Modell-Varianten im Vorfeld einer Veröffentlichung in der Arena zu testen und nur die beste Version öffentlich zu machen – Selektionsbias as a service. Im konkretesten Fall: ein Anbieter, der 27 private Varianten testete, bevor eine öffentlich auf Platz zwei landete. LMArena hat dem Paper in Teilen widersprochen und Korrekturen ausgehandelt – die strukturellen Punkte (private Tests, asymmetrische Sampling-Raten, selektive Veröffentlichung) bleiben aber stehen.

Wo der Realitätsbezug bricht: SWE-bench als Lehrstück

Spannender als die altbekannten Klassiker ist der Fall SWE-bench Verified. Der gilt als „realistisch“, weil echte Issues, echte Repos, echter Code. Claude Opus 4.5 und Claude Opus 4.6 liegen aktuell bei rund 80%, Gemini 3.1 Pro und GPT-5.2 ebenfalls in dem Bereich. Wer das liest, denkt: 80% der Software-Engineering-Aufgaben sind erledigt. Mehr oder weniger. Halb so wild.

Auf SWE-bench Pro – derselbe Aufbau, aber mit privaten, dem Modell unbekannten Codebases von realen Startup-Kunden – fallen dieselben Modelle auf 46–57%. Auf der reinen Commercial-Subset, den komplett privaten Codebases, noch tiefer. Dieselben Modelle. Realistischere Aufgaben, fremder Code.

Das ist der Reality-Check, von dem ich am Anfang sprach: Der Sturz von 80% auf 50% ist nicht ein bisschen Pech. Das ist die Differenz zwischen „der Benchmark misst, was öffentlich auf GitHub liegt und im Training enthalten war“ und „der Benchmark misst, was das Modell in einem Codebase kann, den es noch nie gesehen hat“. Und das, Ladies and Gentlemen, sind komplett verschiedene Fragen.

Reasoning-Benchmarks: schneller geknackt, als sie reifen können

Der Verdacht, dass Reasoning besonders mies abgebildet wird, lässt sich auch konkret machen. ARC-AGI ist ein gutes Beispiel, weil hier nicht die übliche Memorization-Falle greift – die Aufgaben sind visuelle Grid-Transformationen, die sich kaum auswendig lernen lassen.

Trotzdem:

• ARC-AGI-1: 2024 noch unbeaten, heute über 96% bei Top-Modellen mit Test-Time-Compute.
• ARC-AGI-2: Aktuell 85% (GPT-5.5), Anfang 2025 noch nahe 0%.
• ARC-AGI-3: Bei 13%.

Das ist keine Manipulation, das ist echtes Skalieren. Aber: Jede Reasoning-Benchmark-Generation lebt rund 12 Monate, bevor sie den nächsten Schritt der Skalierung abbekommt und kein Diskriminator mehr ist. Das macht statische Reasoning-Benchmarks per Definition zu einem Verbrauchsmaterial, nicht zu einem stabilen Maßstab. Und eine aktuelle Studie argumentiert sogar, dass viele „Reasoning-Benchmarks“ gar nicht primär Reasoning testen, sondern Wahrnehmung – ein Modell scheitert oft schon daran, das Grid korrekt zu lesen, nicht an der eigentlichen Schlussfolgerung.

Humanity's Last Exam, im Januar 2025 vom Center for AI Safety und Scale AI eingeführt als bewusst „letzter geschlossener akademischer Benchmark“, startete mit Modell-Scores im einstelligen Bereich – GPT-4o bei 2,7%, Claude 3.5 Sonnet bei 4,1%, o1 bei 8%. Aktueller Stand auf dem offiziellen Scale-AI-Leaderboard: Gemini 3 Pro Preview führt mit gut 37%, dahinter Claude Opus 4.6 Thinking Max bei 34% und GPT-5 Pro bei 31% (je nach Setup und Aggregator schwanken die Werte deutlich, was in sich schon ein Problem ist). Von unter 10% auf über 30% in einem Jahr – die Saturationskurve ist absehbar, auch wenn HLE noch Luft hat. GPQA Diamond, der Graduate-Level-Reasoning-Test, ist bereits über 94% und damit faktisch durch.

Was übrig bleibt: dynamische Benchmarks und eigene Evals

Wenn alles, was statisch und öffentlich ist, früher oder später kontaminiert oder saturiert ist, lautet die naheliegende Antwort: nicht statisch, nicht öffentlich.

LiveBench und LiveCodeBench machen genau das – sie sammeln laufend neue Aufgaben aus aktuellen Quellen (Mathe-Wettbewerbe, frische arXiv-Paper, neue LeetCode-Probleme nach den jeweiligen Trainings-Cutoffs) und werten automatisch gegen verifizierbare Ground Truth, also ohne LLM-as-a-judge-Bias. Das gilt aktuell als der zuverlässigste Weg, Modelle für reale Coding-Workloads zu vergleichen, neben SWE-bench Pro mit seinem privaten Subset: realer Code, der nicht im Training war.

Das ist die kleine Ecke der Benchmark-Landschaft, die meinem ursprünglichen 60%-Verdikt am ehesten entkommt.

Aber auch die löst das Grundproblem nur teilweise. Selbst der beste dynamische Benchmark testet nicht, ob ein Modell in Deinem Codebase, mit Deinen Konventionen, in Deinem Domänenvokabular gut performt. Da gibt es nur einen Weg, und das ist eine eigene, aufgabenspezifische Eval-Suite mit echten Beispielen aus dem eigenen Workflow. Das ist Arbeit, ja. Aber es ist die einzige Zahl, die für Deinen Anwendungsfall keinen Blödsinn generiert.

Fazit – ergebnisoffen, wie versprochen

Meine 60%-These hat die Recherche nicht widerlegt – sie hat sie eher verschärft. Von den meistzitierten Benchmarks ist ein guter Teil entweder saturiert (MMLU, GSM8K, HumanEval), nachweislich kontaminiert (MMLU, GSM8K), oder anfällig für Style-Gaming und Tester-Bias (Chatbot Arena). Die „realistischen“ Coding-Benchmarks halten dem ersten echten Realitätstest schlecht stand. Reasoning-Benchmarks sind oft schneller saturiert, als die Modellgenerationen wechseln.

Praktisch heißt das: Wer ein Modell auswählt, sollte sich Leaderboards anschauen, klar – aber als groben Filter, nicht als Entscheidungsgrundlage. Wirklich wissen, was das Modell für die eigene Aufgabe taugt, kann man nur selbst evaluieren. Eigenes Set von Beispielprompts und über ein eigenes Bewertungsschema. Im Zweifel zwei oder drei Modelle parallel laufen lassen und schauen, was hinten herauskommt.

Das ist der Reality-Check, den die Leaderboards einem nicht abnehmen. Und der Punkt, an dem Benchmarks aufhören, eine vernünftige Antwort auf die Frage „welches Modell ist besser“ zu sein – und stattdessen anfangen, eine Antwort auf die Frage „welches Modell hat den Test gewonnen“ zu sein. Das sind – und das sollte jeden innerlich zweifeln lassen – zwei verschiedene Fragen.