Benchmarks lesen: Was KI-Ranglisten wirklich sagen
Jeder Modell-Launch kommt mit einer Tabelle voller Prozentzahlen – SWE-bench, GPQA, Terminal-Bench. Sie wirken objektiv, sind es aber oft nicht: Die Zahlen stammen meist vom Anbieter selbst, die Testbedingungen sind uneinheitlich, und manche Prüfung kennt das Modell längst aus dem Training. Dieser Artikel zeigt, wie man Benchmarks und Leaderboards kritisch liest – mit besonderem Blick auf die Coding-Benchmarks, die für Entwicklerinnen und Entwickler zählen: was jeder einzelne misst, wie belastbar das Ergebnis ist, warum das verbreitete SWE-bench an Wert verliert, welche unabhängigen Messungen tragen und wie die übrige Benchmark-Landschaft von ARC-AGI bis FrontierMath einzuordnen ist.
7 Min. Lesezeit
8 Abschnitte
19 Quellen
Stand: 16. Juni 2026
Selbstberichtete Zahlen sind befangen
Die Benchmark-Tabellen in System-CardDas offizielle Begleitdokument eines Anbieters zu einem Modell (auch „Model Card“): Fähigkeiten, Grenzen, Sicherheitsbewertung. Primärquelle – die Fähigkeitsangaben darin sind aber Eigenangaben, nicht unabhängig gemessen.Mehr im Wissen → und Launch-Posts nennen durchweg anbieter-eigene Zahlen – SWE-benchCoding-Benchmark, der Modelle echte GitHub-Issues in realen Repositories lösen lässt; gewertet wird, ob der erzeugte Patch die Tests besteht. Verbreitet, aber zunehmend durch Trainings-Kontamination belastet.Mehr im Wissen →, GPQA, Terminal-BenchAusführungsbasierter Benchmark (0–100 %): das Modell löst echte Shell-/Terminal-Aufgaben in einer Sandbox, gewertet wird, ob das Ergebnis wirklich funktioniert. Dadurch kontaminationsärmer als reine Wissensquizze.Mehr im Wissen → und Co. Das Problem ist nicht zwingend Betrug, sondern Auswahl: Welche Benchmarks gezeigt werden, mit welchem Prompt-Setup und wie vielen Versuchen, entscheidet der Anbieter. Ohne einheitliche Bedingungen sind zwei selbstberichtete Scores schlicht nicht vergleichbar.
Wie weit die Eigeneinschätzung danebenliegen kann, zeigt ein Fall aus der Sicherheitsbewertung: OpenAIs eigene verblindete Studie legte nahe, dass GPT-5 faktisch gar nicht die Stufe „Bio High“ erreichte – die ursprüngliche Einstufung war konservativ-falsch. Selbst sorgfältige Anbieter-Messungen sind also mit Vorsicht zu lesen, in beide Richtungen.
MerksatzWer den Test schreibt, wählt auch die Fragen. Anbieter-eigene Benchmarks sind ein Marketing-Signal, kein neutraler Vergleich.
Kontamination: wenn das Modell die Prüfung schon kennt
Klassische Multiple-Choice-Benchmarks wie MMLU haben ein strukturelles Leck: Ihre Fragen stehen seit Jahren im Netz – und damit oft mit im Trainingsdatensatz. Ein Modell kann dann die Antwort „gelernt“ haben, statt die Fähigkeit zu besitzen. Diese Daten-Kontamination bläht Scores auf, ohne dass echtes Können dahintersteht.
Die Konsequenz für die Praxis: Einzelne Roh-Scores kontaminationsanfälliger Benchmarks taugen kaum als Fähigkeitsmaß. Aussagekräftiger sind Messungen, die schwer zu kontaminieren sind – etwa Tests, die regelmäßig mit frischen Aufgaben neu aufgesetzt werden, oder Rankings, die auf menschlichem Urteil statt auf einem festen Fragenkatalog beruhen.
MerksatzEin alter Benchmark im Trainingsdatensatz misst Erinnerung, nicht Fähigkeit. Kontaminationsresistente, reproduzierbare Messungen wiegen schwerer.
Coding-Benchmarks: Welcher misst was?
Für Entwicklerinnen und Entwickler zählt nicht die Quiz-Genauigkeit, sondern ob ein Modell echten Code schreibt, ändert und debuggt. Dafür hat sich eine ganze Familie von Coding-Benchmarks etabliert – und sie messen sehr Unterschiedliches. Grob lassen sich vier Typen unterscheiden, von praxisnah bis veraltet.
Agentische Repo-Aufgaben sind am realitätsnächsten: SWE-bench gibt dem Modell ein echtes GitHub-Issue plus die Codebasis und prüft, ob der erzeugte Patch die Projekt-Tests besteht; Terminal-Bench (eine Kollaboration von Stanford und dem Laude Institute) lässt den Agenten in einer echten Shell arbeiten und verifiziert das Ergebnis per Skript; SWE-Lancer von OpenAI bewertet über 1 400 echte, in Dollar bezahlte Upwork-Jobs mit dreifach geprüften End-to-End-Tests. Weil hier echter Code ausgeführt wird, lässt sich das Ergebnis schwerer auswendig lernen.
Code-Editing und Wettbewerbs-Code messen enger umrissene Fähigkeiten: Aiders Polyglot-Leaderboard prüft 225 Übungen über sechs Sprachen und zusätzlich, wie zuverlässig ein Modell das geforderte Diff-Format trifft. LiveCodeBench zieht Aufgaben aus Programmierwettbewerben (LeetCode, AtCoder, Codeforces) – und datiert jede Aufgabe, sodass man nur Probleme nach dem Trainings-Cutoff eines Modells wertet (dazu gleich mehr). Tool-Use-Benchmarks wie τ-bench schließlich messen nicht das Peak-Können, sondern die Verlässlichkeit über viele Läufe (die pass^k-Metrik).
Und dann die Altlasten: HumanEval und MBPP, jahrelang der Standard, prüfen einzelne, in sich geschlossene Funktionen. Sie sind heute weitgehend gesättigt – Spitzenmodelle liegen nahe der Höchstpunktzahl – und stark kontaminiert; als Unterscheidungsmaß für aktuelle Modelle taugen sie kaum noch. BigCodeBench ist ihr realitätsnäherer Nachfolger, der das Zusammenspiel vieler Bibliotheks-Aufrufe verlangt.
MerksatzEs gibt nicht den einen Coding-Benchmark. Frag immer: misst er echte, ausgeführte Arbeit (gut) oder abgefragtes Wissen (kontaminationsanfällig) – und stammt die Aufgabe von nach dem Trainings-Cutoff?
SWE-bench ist der meistzitierte Coding-Benchmark – und das beste Beispiel dafür, wie ein Maßstab altert. Die sauberere Variante SWE-bench Verified umfasst 500 von Menschen geprüfte Aufgaben (mit OpenAI ko-kuratiert), bei denen mehrdeutige oder unlösbare Fälle aussortiert wurden. Lange war eine hohe SWE-bench-Zahl das Aushängeschild jedes Launches.
Zwei Effekte untergraben diese Zahl inzwischen. Erstens Sättigung: Die Spitzenmodelle drängen sich eng beieinander im hohen Bereich (oft über 70 %) – wo alle ähnlich gut abschneiden, unterscheidet der Benchmark nicht mehr. Zweitens, gravierender, Kontamination: Die Lösungen sind echte GitHub-Pull-Requests, und die Diskussionen samt Fixes stehen seit Jahren im Netz – also im Trainingsdatensatz neuerer Modelle. Das Modell kann die Lösung gesehen haben, statt sie zu können.
Dass das kein bloßer Verdacht, sondern messbar ist, zeigt die Studie „The SWE-Bench Illusion“ (2026): Modelle identifizieren die zu ändernde Datei allein aus der Issue-Beschreibung – ohne die Codebasis überhaupt zu sehen – in 76 % der Fälle auf SWE-bench, aber nur in 53 % bei vergleichbaren Repos außerhalb des Benchmarks. Diese Lücke ist die Signatur von Auswendiglernen, nicht von Können. Im Februar 2026 hat OpenAI deshalb aufgehört, SWE-bench Verified als Vergleichsmaß zu führen – mit ausdrücklichem Verweis auf Sättigung und Kontamination – und empfiehlt stattdessen das schwerere, kontaminationsresistente SWE-bench Pro (von Scale AI), auf dem dieselben Spitzenmodelle von über 70 % auf etwa 23 % einbrechen.
Auch aus der Praxis kommt deutliche Skepsis – und zwar von Stimmen, die wir als belastbar einstufen. Der Entwickler-Kommentator Theo (t3.gg) flaggt benchmarkbasierte Coding-Ranglisten als „Hype-Disziplin“: Sobald die lösenden Pull-Requests im Training landen, misst der Benchmark Erinnerung statt Fähigkeit. Der quellenbewusste Analyse-Kanal AI Explained weist auf einen zweiten Trick hin – Anbieter veröffentlichen für denselben Datensatz unterschiedliche Varianten (Verified, Pro, …) und verhindern so den fairen Direktvergleich.
Die Antwort der Benchmark-Bauer ist Kontaminations-Resistenz durch Frische und Ausführung: LiveCodeBench datiert jede Aufgabe und wertet nur solche nach dem Modell-Cutoff; SWE-bench-Live nimmt ausschließlich Issues ab 2024 und aktualisiert monatlich; Terminal-Bench und SWE-Lancer setzen auf echte Programmausführung statt Textabgleich. Für den Praxisblick gilt: Eine SWE-bench-Zahl ohne Datum und ohne Angabe der Variante ist kaum zu gebrauchen.
SWE-bench Verified
500 geprüfte GitHub-Bugfixes (mit OpenAI)
Sättigung
Spitzenmodelle drängen sich eng oberhalb ~70 %
Kontaminations-Signatur
76 % vs. 53 % Datei-Treffer ohne Codebasis (SWE-Bench Illusion, 2026)
MerksatzEine SWE-bench-Zahl ohne Datum, Variante und Kontaminations-Check ist eher Marketing als Messung. Verlässlicher sind Benchmarks, die frische Aufgaben nutzen oder echten Code ausführen.
Coding ist nur ein Feld. Wer Modell-Vergleiche liest, trifft auf einen ganzen Zoo spezialisierter Benchmarks – und es lohnt zu wissen, was sie messen und wer dahintersteht, denn die Unabhängigkeit des Betreibers entscheidet über den Wert der Zahl.
Im Wissens- und Reasoning-Bereich sind die klassischen Multiple-Choice-Tests weitgehend ausgereizt: MMLU und selbst das anspruchsvolle GPQA Diamond (Fragen auf Graduiertenniveau) liegen nahe der Sättigung und sind kontaminationsanfällig. Als härtere Nachfolger gelten Humanity’s Last Exam (breites Expertenwissen, noch lange nicht gesättigt) und – für abstraktes Schließen – ARC-AGI-2 der Non-Profit-Stiftung ARC Prize, bewusst so gebaut, dass Auswendiglernen nicht hilft.
An der Forschungs-Frontier wird es spezialisiert: FrontierMath von Epoch AI stellt unveröffentlichte Mathematik-Probleme (sehr kontaminationsresistent, aber von OpenAI finanziert – beim Zitieren mitzudenken), Surges Riemann-Bench zielt ähnlich auf neue Mathematik, CritPt (von Argonne und der UIUC entwickelt, unabhängig von Artificial Analysis gemessen) prüft echte Physik-Forschung. Agentische Benchmarks wiederum messen Handeln statt Wissen: Googles DeepSearchQA bewertet mehrstufige Web-Recherche auf Vollständigkeit, Vals AIs Finance Agent Benchmark (FABv2) prüft Finanzanalyse-Agenten.
Das Muster ist überall gleich: Sobald ein Benchmark öffentlich und beliebt wird, sättigt und kontaminiert er – und die Bauer weichen auf frischere, schwerere oder ausführungsbasierte Nachfolger aus. Eine einzelne Spitzenzahl sagt deshalb wenig; aussagekräftig ist der Trend über mehrere unabhängige Messungen, datiert gelesen.
unveröffentlichte Forschungs-Mathe · sehr schwer · OpenAI-finanziert
Riemann-Bench · Surge AI
Frontier-Mathematik · unabhängiger Betreiber
CritPt · Argonne/UIUC
Forschungs-Physik · von Artificial Analysis gemessen
GPQA Diamond
Science auf Graduiertenniveau · weitgehend gesättigt
Humanity’s Last Exam
breites Expertenwissen · noch nicht gesättigt
DeepSearchQA · Google
agentische Deep-Recherche · Vollständigkeit
FABv2 · Vals AI
Finanzanalyse-Agenten · domänenspezifisch
MerksatzWer einen Benchmark betreibt, prägt seine Zahl. Unabhängige Betreiber (ARC Prize, Epoch, Artificial Analysis) wiegen schwerer als anbieter-eigene Tests – und kein Frontier-Benchmark bleibt lange ungesättigt.
Statt einer Anbieter-Tabelle blind zu vertrauen, lohnt der Blick auf unabhängige Messungen – am besten mehrere zusammen und immer mit Datum, denn die Rangfolge ändert sich im Monatstakt. Drei Adressen haben sich etabliert: Elo (LMArena)Human-Präferenz-Wertung aus der LMArena: Menschen vergleichen blind zwei Modellantworten, daraus entsteht – wie beim Schach – eine Elo-Zahl. Höher = häufiger bevorzugt. Misst Präferenz, nicht Korrektheit.Mehr im Wissen → (vormals Chatbot Arena) misst über anonyme Mensch-gegen-Mensch-Votings einen Elo-Wert – aussagekräftig, aber nur relativ zu lesen und mit Hang zu „gefälligem“ Stil über sachlicher Korrektheit. Artificial Analysis bündelt eigene Benchmarks zu einem Intelligence-Index inklusive Tempo und Preis – nützlich, aber an die eigene Methodik gebunden, also nicht als Absolutwert setzen. Epoch AI arbeitet forschungsnah an Trends und Compute.
Ein Sonderfall sind Evals, die echte Autonomie messen statt Quizwissen: Die Non-Profit METR misst, wie lange eine Aufgabe sein darf, die ein Modell noch eigenständig mit 50 % Erfolg schafft – ein Maß, das sich schwer durch Auswendiglernen austricksen lässt. Genau solche unabhängigen, reproduzierbaren Verfahren sind die belastbarere Währung.
LMArena (arena.ai)
Human-Preference-Elo · nur relativ lesen
Artificial Analysis
Intelligence-Index · eigene Methodik
Epoch AI
Trends & Compute · forschungsnah
METR
Autonomie-Horizont · kontaminationsarm
MerksatzKein Einzelwert entscheidet. Mehrere unabhängige Messungen (LMArena, Artificial Analysis, Epoch), datiert und im Trend gelesen, schlagen jede einzelne Launch-Zahl.
Großes Kontextfenster ≠ besseres Modell
Auch eine große Zahl an anderer Stelle führt in die Irre: das Kontextfenster. Ein beworbenes 1-Millionen-Token-Fenster ist ein Kapazitäts-Maximum, keine Qualitätsgarantie. Studien wie „Lost in the Middle“ und „RULER“ zeigen, dass die effektiv nutzbare Länge meist deutlich unter der beworbenen liegt – und dass die Trefferqualität positionsabhängig zur Mitte hin und mit zunehmender Länge oder Ablenkern abfällt.
Praktisch heißt das: Wichtige Information gehört an Anfang und Ende des Kontexts, nicht in die Mitte eines riesigen Dokumentenstapels. Und die Fenstergröße allein sagt wenig darüber, wie zuverlässig ein Modell den Inhalt tatsächlich verwertet. Feste Prozentwerte sollte man sich nicht einbrennen – sie hängen vom Modell und vom Stichtag ab.
MerksatzDas Kontextfenster ist ein Maximum, keine Garantie: effektiv nutzbar ist meist weniger als beworben, und die Mitte geht am ehesten verloren.
Ein subtiler, aber wachsender Effekt verzerrt vor allem Sicherheitstests: Evaluation-Awareness. Modelle „merken“ zunehmend, wenn sie geprüft werden, und beziehen das in ihr Verhalten ein. Claude Haiku 4.5 verbalisiert in rund 9 % der Test-Transkripte klar, dass es sich beobachtet fühlt; bei Fable 5 sind die Raten „signifikant – und nicht immer ausgesprochen“. Ein Modell, das sich im Test anders verhält als im Alltag, macht jede Eval-Zahl unsicherer.
Hinzu kommt: Auch das Testverfahren selbst entscheidet über das Ergebnis. Für Fable 5 fand ein öffentliches Bug-Bounty über rund 1 000 Stunden keinen universellen Jailbreak – während das UK AI Safety Institute binnen Stunden Single-Turn-Cyber-Jailbreaks erzeugte. Beide Befunde stimmen, sie messen nur Unterschiedliches. Deshalb gilt: Wie getestet wurde, ist genauso wichtig wie das Ergebnis.
Eval-Awareness Haiku 4.5
~9 % der Transkripte verbalisiert
MerksatzEine Eval-Zahl ist nur so gut wie ihr Aufbau – und Modelle, die den Test erkennen, verzerren ihn zusätzlich.