Modell-Benchmarks richtig lesen

Dies ist das eine Kapitel über die Zahlen anderer Leute. Sie kommen nicht darum herum, sie zu lesen. Modellkarten, Beschaffungsentscheidungen, der CTO mit einem Leaderboard-Link: Das gehört zum Alltag. Und solche Zahlen gut zu lesen ist eine eigene Fähigkeit. Sie hat mit dem Bau eigener Evals wenig zu tun.

Die Kurzfassung: Öffentliche Benchmarks taugen für eine grobe Vorauswahl nach Fähigkeit. Für die Vorhersage, wie Ihre Anwendung abschneidet, taugen sie fast nicht. Behandeln Sie sie wie die Abschlussnote eines Bewerbers.

Wofür Benchmarks tatsächlich da sind

Ein Ebene-A-Benchmark beantwortet eine Frage: „Kann dieses Modell diese Art von Aufgabe im Großen und Ganzen?“ Das ist eine echte Frage mit echtem Nutzen. Sie engt ein Feld von zwanzig Modellen auf drei ein. Diese drei lohnt es, an eigenen Daten zu prüfen.

Ob ein Modell in Ihrem Produkt funktioniert, kann ein Benchmark nicht beantworten. Ihr Produkt besteht vor allem aus Prompt, Retrieval, Tools und Fachgebiet. Nichts davon steckt im Benchmark.

Gut genutzt sieht der Ablauf so aus: Benchmarks engen das Feld ein, Ihr Ebene-B-Eval kürt den Sieger. Schlecht genutzt ist der Benchmark die Entscheidung. Die Diskrepanz entdecken Sie dann in Produktion.

Kontamination ist heute die Standardannahme

Ein Benchmark ist eine Prüfung. Kontamination heißt: Der Prüfling hat die Klausur schon gesehen.

Nicht durch absichtliches Schummeln. Die Klausur stand im Internet, und das Modell wurde auf dem Internet trainiert. Benchmarks sind absichtlich öffentlich. Nur so sind sie vergleichbar. Und genau diese Veröffentlichung bringt sie in die Trainingsdaten des nächsten Modells.

Warum das zählt: Eine hohe Punktzahl soll heißen: „Dieses Modell kann Probleme dieser Art lösen.“ Hat das Modell genau diese Probleme im Training gesehen, heißt sie vielleicht nur: „Dieses Modell erinnert sich an den Lösungsschlüssel.“ Von außen sehen beide Fälle gleich aus. An der Zahl können Sie sie nicht unterscheiden.

Die übliche Abwehr heißt n-Gramm-Dekontamination. Ein n-Gramm ist einfach eine Folge von n aufeinanderfolgenden Wörtern. Die Abwehr ist ein Suchen und Löschen: Man durchsucht die Trainingsdaten nach Wortfolgen, die auch im Testset stehen, und entfernt diese Dokumente. Das fängt wörtliche Kopien.

Eine Umformulierung fängt es nicht. „Was ist 2 + 2?“ und „Berechne die Summe aus zwei und zwei“ haben fast keine Wortfolge gemeinsam. Trotzdem sind sie dieselbe Frage. Genau um diese Lücke geht es im ersten Befund unten.

Befund: Kontamination ist gemessen, nicht nur vermutet. Und die Messwerte sind kleiner und interessanter als die runden Zahlen, die kursieren.

Rethinking Benchmark and Contamination with Rephrased Samples fand: 8–18 % von HumanEval überschneiden sich mit Pre-Training-Sets wie RedPajama-Data-1T und StarCoder-Data. Das beunruhigendere Ergebnis betrifft die Abwehr, nicht die Krankheit: Wer ein Testelement umformuliert oder übersetzt, umgeht die n-Gramm-Dekontamination vollständig. Sind solche Varianten erst in den Trainingsdaten, gilt: „a 13B model can easily overfit a test benchmark and achieve drastically high performance, on par with GPT-4“.

Quelle: Rethinking Benchmark and Contamination, 2023

Befund: Das sauberste natürliche Experiment ist GSM1k von Scale AI. Das sind gut 1.000 Grundschul-Matheaufgaben, von Hand geschrieben. Sie spiegeln GSM8k in Stil, Schwierigkeit, menschlicher Lösungsrate, Lösungslänge und Größe der Ergebnisse. Damit wurden alle Modelle neu bewertet. Das Ergebnis: Genauigkeitseinbrüche von bis zu 8 %, „with several families of models showing evidence of systematic overfitting across almost all model sizes“. Zugleich gilt: „many models, especially those on the frontier, show minimal signs of overfitting“. Die Wahrscheinlichkeit, mit der ein Modell ein GSM8k-Beispiel selbst erzeugt, korrelierte mit seiner Lücke zwischen GSM8k und GSM1k bei Spearmans r² = 0,36. Dieses Maß beschreibt, wie eng zwei Ranglisten miteinander laufen. 0 heißt kein Zusammenhang, 1 heißt perfekt. 0,36 ist ein mittlerer Zusammenhang: real und kaum Zufall, aber weit von eins zu eins entfernt.

Diese letzte Korrelation ist der Teil, den Sie behalten sollten. Sie verbindet die Lücke zwischen den Werten direkt mit dem Auswendiglernen. Kontamination bleibt so kein bloßer Vorwurf. Und der Befund, dass Frontier-Modelle überwiegend sauber waren, korrigiert eine Annahme: Nicht jede Schlagzeilenzahl ist aufgebläht.

Quelle: A Careful Examination of LLM Performance on Grade School Arithmetic, 2024

Was das Feld dagegen tut, in einfachen Worten:

Nichts davon löst das Problem vollständig. Kontamination ist eine strukturelle Folge davon, eine Evaluation zu veröffentlichen. Die einzige vollständige Antwort ist ein privates Eval-Set. Genau das bringt Ihre Ebene-B-Arbeit hervor.

Benchmarks sterben, und das ist normal

Benchmarks haben einen Lebenszyklus. Sie enden auf zwei Arten, und beide sollten Sie erkennen.

Sättigung heißt: Der Benchmark ist zu leicht geworden. Wenn jedes ernstzunehmende Modell 80 % und mehr erreicht, bestehen die restlichen 20 % überwiegend aus kaputten Fragen. Der Benchmark kann gute Modelle nicht mehr von besseren unterscheiden. Die Prüfung trennt nicht mehr. Nicht, weil die Prüflinge schlechter geworden sind, sondern weil inzwischen alle bestehen.

Defekte heißt: Die Fragen selbst sind falsch. Sie sind mehrdeutig, oder der Test verlangt etwas, wonach die Frage nie gefragt hat.

Bei SWE-bench Verified trat beides gleichzeitig ein.

Befund: Am 23. Februar 2026 kündigte OpenAI an, SWE-bench Verified nicht mehr zu berichten. Zwei Gründe, und beide lassen sich verallgemeinern.

Sättigung. Der Fortschritt an der Spitze hatte sich verlangsamt, „from 74.9% to 80.9% in the last 6 months“. Das wirft die Frage auf, die OpenAI direkt stellt: „do the remaining failures reflect model limitations or properties of the dataset itself?“

Defekte. o3 konnte 138 Probleme nicht zuverlässig lösen („did not consistently solve over 64 independent runs“). Davon enthielten 59,4 % wesentliche Mängel im Testdesign und/oder in der Aufgabenbeschreibung, „rendering them extremely difficult or impossible even for the most capable model or human to solve“. Zwei Drittel davon waren zu enge Tests. Sie erzwangen Implementierungsdetails, die die Aufgabe nie festgelegt hatte. (Vollständige Aufschlüsselung im Literaturverzeichnis.)

Quelle: OpenAI, Why SWE-bench Verified no longer measures frontier coding capabilities, 23. Feb. 2026

Die Kontaminationshälfte dieses Beitrags enthält den subtileren Befund. Den sollten Sie in die eigene Arbeit mitnehmen.

Befund: Die geprüften Modelle konnten „reproduce the original, human-written bug fix used as the ground-truth reference, known as the gold patch, or verbatim problem statement specifics for certain tasks“. In einem Fall löste GPT-5.2 31 Aufgaben, die OpenAI als nahezu unlösbar eingestuft hatte. Bei django__django-14725 verlangen die Tests einen Parameter edit_only, den die Aufgabenstellung nie fordert. Die Gedankenkette des Modells zeigte Kenntnis der Django-Release-Notes. Sie ordnete die Einführung des Parameters korrekt Django 4.1 zu.

Der Mechanismus ist das, was Sie sich merken sollten: „models that have seen the problems during training are more likely to succeed, because they have additional information needed to pass the underspecified tests.“ Kontamination und Unterbestimmtheit sind keine zwei unabhängigen Mängel. Kontamination liefert die fehlende Spezifikation nach. Ein Benchmark mit unterbestimmten Aufgaben duldet Kontamination nicht bloß. Er belohnt sie.

Quelle: OpenAI, 23. Feb. 2026

OpenAI verwies die Community stattdessen auf SWE-bench Pro.

Der Nachfolger brach ebenfalls, in fünf Monaten

Hier hört der Lebenszyklus auf, eine Theorie zu sein. Der Benchmark, der die Antwort auf den kaputten Benchmark war, wurde selbst geprüft. Und noch im selben Jahr zurückgezogen.

Pro sättigte auf derselben Kurve. Auf dem öffentlichen Split mit 731 Aufgaben stiegen Frontier-Modelle „from a pass rate of 23.3% to 80.3% in eight months“.

Befund: Am 8. Juli 2026 zog OpenAI die eigene Empfehlung zurück: „Given the issues uncovered in this analysis, we retract our earlier recommendation to adopt SWE-Bench Pro.“ OpenAI schätzt, dass rund 30 % der SWE-bench-Pro-Aufgaben kaputt sind.

Die Prüfung lief in drei Stufen. Ein automatischer Filter markierte 286 möglicherweise kaputte Aufgaben. Diese gingen an zwei Stellen: an eine Prüfung durch einen Codex-basierten Ermittler-Agenten, bei der ein Forscher das letzte Wort hatte, und an eine menschliche Annotationskampagne mit fünf unabhängigen Prüfern je Aufgabe. Beide wichen in der erwarteten Richtung voneinander ab. Die Agenten-Pipeline markierte 200 Aufgaben (27,4 %), die menschlichen Prüfer 249 (34,1 %), jeweils bezogen auf den öffentlichen Split mit 731 Aufgaben. Ihre Kategorienurteile überlappten sich in 74 % der Fälle. Und: „in no flagged task was ‚not broken‘ the most common human label“.

Nach Anteil am Datensatz (Agent / Mensch): zu strenge Tests 14,4 % / 17,8 %, mit großem Abstand die größte Klasse. Dann Tests mit geringer Abdeckung 4,1 % / 9,4 %, irreführende Aufgabenstellungen 6,3 % / 7,5 %, Sonstiges 1,9 % / 1,2 %. Und unterbestimmte Aufgabenstellungen waren die kleinste Klasse mit deutlich unter 1 %.

Quelle: OpenAI, Separating signal from noise in coding evaluations, 8. Juli 2026 · unabhängig auf rund 30 % bestätigt von Faros AI (ein Anbieter, offengelegt)

Beachten Sie, was OpenAI nicht getan hat: einen Nachfolger benennen. Der Februar-Beitrag hatte einen parat. Der Juli-Beitrag bittet die Community um „new benchmarks built by experienced software developers specifically to test model capabilities“. Wer auf den nächsten empfohlenen Coding-Benchmark wartet, wartet vergeblich. Es gibt derzeit keinen.

Die Ursache ist der übertragbare Teil. OpenAI benennt sie klar:

"Issues and pull requests from open-source repositories were originally created for human collaboration… problem descriptions, merged code, and unit tests do not always line up to form clean, isolated tasks for evaluating models reliably. In particular, tests included in pull requests can be overly strict because they are written to validate a specific change, rather than to define an implementation-agnostic standard for solving the task."

Ein Test, der einen Pull Request prüfen sollte, definiert keine Korrektheit. Er wurde geschrieben, um zu belegen, dass genau diese Änderung funktioniert. Geschrieben von der Person, die die Änderung gemacht hat, gegen die Implementierung, die sie gewählt hat. Wer ihn in einen Benchmark übernimmt, erhebt stillschweigend die Implementierungsentscheidungen einer einzelnen Person zum Bewertungsmaßstab. Jede funktional korrekte Lösung, die einen anderen Weg nimmt, fällt jetzt durch.

Vielleicht gewinnen Sie Eval-Fälle aus der Historie Ihres eigenen Repositorys. Das ist eine gute Idee, und Datensatz-Design empfiehlt sie. Aber dann sind Sie genau diesem Problem ausgesetzt. Die Abhilfe stammt aus Code-basierte Evals: Machen Sie explizit, welche Assertions notwendige Bedingungen sind und welche nur eine Implementierung festschreiben. Eine Testsuite ist ein guter Grader und eine schlechte Spezifikation.

Die allgemeine Lehre reicht über SWE-bench hinaus. Ein Benchmark hat einen Lebenszyklus. Neu ist er aussagekräftig. Dann sättigt er sich, weil Modelle besser werden und Trainingsdaten ihn aufsaugen. Am Ende stammen seine restlichen Fehlschläge vor allem aus Defekten des Benchmarks, nicht des Modells.

Die praktischen Folgen beim Lesen eines Werts:

• Prüfen Sie das Alter des Benchmarks. Ein Benchmark von 2023, zitiert 2026, ist eine historische Notiz.
• Prüfen Sie, wie dicht die Spitze zusammenliegt. Liegen die führenden Modelle nur wenige Punkte auseinander, ist der Rest Rauschen und Testdefekte, nicht Fähigkeit. Genau dieses Argument hat OpenAI oben zu beiden SWE-bench-Benchmarks vorgebracht.
• Prüfen Sie, ob ein ernstzunehmendes Labor ihn öffentlich aufgegeben hat. Das ist das stärkste verfügbare Signal, dass ein Benchmark am Ende ist. OpenAI hat innerhalb von fünf Monaten zwei aufgegeben, darunter den gerade erst empfohlenen.
• Prüfen Sie das Datum des Nachfolgers, nicht nur das des Benchmarks. „Wir sind auf den neueren gewechselt“ ist eine Aussage mit Halbwertszeit.

Messfragilität

Selbst unkontaminierte, ungesättigte Benchmarks sind fragiler, als ihre veröffentlichte Genauigkeit nahelegt.

Befund: A Single Character can Make or Break Your LLM Evals (2025) untersuchte das Trennzeichen zwischen In-Context-Beispielen. Je nach Wahl schwankte die MMLU-Leistung um bis zu ±23 %. Und die Rangfolge ließ sich so umsortieren, dass jedes beliebige Modell vorn lag, allein durch dieses eine Zeichen. Der Effekt nimmt mit der Modellgröße nicht ab.

Quelle: A Single Character can Make or Break Your LLM Evals, 2025

Zwei Folgen. Erstens: Wer veröffentlichte Werte aus verschiedenen Quellen vergleicht, vergleicht meist verschiedene Harnesses. Ein Unterschied von 1–2 Punkten bedeutet dann nichts. Zweitens: Wenn jemand einen eigenen Lauf eines öffentlichen Benchmarks berichtet, gehören Harness und Prompt-Format zum Ergebnis. Siehe Das Offline-Harness.

Arenen und das Anreizproblem

Eine Arena funktioniert anders als ein Benchmark. Es gibt keinen Fragenkatalog und keine richtige Antwort. Ein Besucher tippt einen Prompt ein. Er bekommt zwei anonyme Antworten von zwei verschiedenen Modellen und stimmt für die bessere. Millionen solcher Stimmen werden zu einer Rangliste verrechnet, so wie Schach-Wertungszahlen aus Partieergebnissen entstehen.

Das misst etwas, das ein Benchmark nicht messen kann: was Menschen tatsächlich bevorzugen. Es erbt aber auch jede Eigenheit dieser Vorlieben. Darunter mehrere, die nichts mit Qualität zu tun haben. Und weil eine öffentliche Rangliste Geld wert ist, zieht sie genau die Optimierung an, die unten beschrieben wird.

Arenen für menschliche Präferenz messen etwas, das Benchmarks nicht können: was Menschen bevorzugen. Sie haben auch strukturelle Dynamiken, die Sie kennen sollten.

Befund: The Leaderboard Illusion (April 2025) argumentierte, dass die Chatbot-Arena-Rankings verzerrt sind. Erstens durch nicht offengelegte private Tests mit selektiver Veröffentlichung. Die Arbeit identifiziert 27 private LLM-Varianten, die Meta im Vorfeld des Llama-4-Release getestet hat. Zweitens durch ungleichen Datenzugang: Google und OpenAI erhielten geschätzt 19,2 % bzw. 20,4 % aller Arena-Daten. 83 Modelle mit offenen Gewichten kamen zusammen auf 29,7 %. Die Arbeit schätzt, dass schon begrenzte zusätzliche Daten relative Leistungsgewinne von bis zu 112 % auf der Arena-Verteilung bringen. LMArena veröffentlichte eine Erwiderung. Darin heißt es, die Testrichtlinie gelte für alle gleich, und jedes Labor dürfe so viele Varianten einreichen, wie es betreiben kann.

Quelle: The Leaderboard Illusion, 2025; LMArena-Erwiderung

Lesen Sie beides. Der Streit ist teils empirisch, teils eine Frage danach, was ein Leaderboard seinen Lesern schuldet. Keine Seite liegt offensichtlich falsch.

Unabhängig vom Streit gilt: Arenen messen Präferenz. Und Präferenz hat bekannte Korrelate, die keine Qualität sind. Antworten mit Aufzählungen und bestimmten Längen schneiden besser ab. Das ist der Längen-Bias, den Sie schon kennen. Hier tritt er bei menschlichen Bewertern auf statt bei Modell-Judges.

Zusammengesetzte Indizes

Kombinierte Werte, etwa Intelligenz-Indizes im Stil von Artificial Analysis, sind bequem. Und sie fügen eine Schicht Undurchsichtigkeit hinzu. Der Wert eines solchen Index hängt vollständig von der Gewichtung ab. Die Gewichtung ist eine Ermessensfrage. Und es ist selten das Ermessen, das Sie für Ihren Anwendungsfall walten lassen würden.

Wenn Sie einen nutzen, sehen Sie sich die Einzelwerte an. Hat sich der Index wegen eines Benchmarks bewegt, der für Sie keine Rolle spielt, hat er sich für Sie nicht bewegt.

Wie man einen Benchmark tatsächlich nutzt

Vor dem Prozess eine kurze Leseanleitung. Wenn Ihnen jemand eine Benchmark-Zahl vorlegt, entscheiden vier Fragen, wie viel davon Sie glauben sollten:

Keine dieser Fragen setzt Fachwissen voraus. Sie setzen nur voraus, dass jemand sie stellt. Die meisten veröffentlichten Vergleiche überstehen nicht alle vier.

Ein belastbarer Prozess für die Modellwahl:

1. Vorauswahl über Benchmarks. Gewichten Sie Aufgaben, die Ihren ähneln. Nehmen Sie drei oder vier Kandidaten, nicht einen. Ignorieren Sie Unterschiede von wenigen Punkten. Nach der SWE-bench-Pro-Prüfung gilt: „Wenige Punkte“ ist bei einem Coding-Benchmark eher großzügig als vorsichtig.
2. Prüfen Sie die Randbedingungen jenseits der Fähigkeit. Kontextfenster, Latenz, Unterstützung für strukturierte Ausgaben, Zuverlässigkeit bei Tool-Aufrufen, Preis und Hosting-Ort. Diese Punkte scheiden Kandidaten schneller aus als Fähigkeit. Und sie sind Tatsachen, keine Schätzungen.
3. Lassen Sie Ihr eigenes Eval-Set laufen. Das ist die Entscheidung. Hundert Beispiele aus Ihrem eigenen Datensatz trennen die Vorauswahl klarer als jede öffentliche Zahl. Das reicht, um Kandidaten auszuschließen. Einen knappen Fall zu bestätigen braucht mehr. Modellwahl zeigt, wie viel mehr, und was sonst noch passieren muss, bevor ein billigeres Modell live geht.
4. Erproben Sie im echten Verkehr. Shadow-Betrieb oder A/B-Test. Siehe Online-Evaluation.

In Schritt 3 steckt die eigentliche Information, und er ist billig. Hundert Beispiele gegen vier Modelle sind ein Nachmittag.

Häufiger Fehler: Ein Modell anhand eines Benchmarks wählen, der Ihrer Aufgabe nicht ähnelt. Zum Beispiel den Sieger in Wettbewerbsmathematik für ein Kundensupport-Produkt nehmen. Fähigkeit ist nicht eindimensional. Die Korrelation zwischen Benchmark-Familien ist schwächer, als eine einzelne Zahl nahelegt.

Umstritten: Ob öffentliche Benchmarks noch genug Signal tragen, um lesenswert zu sein. Die pessimistische Sicht: Kontamination und Sättigung haben sie zu Marketing-Artefakten gemacht. Die optimistische Sicht: Sie bleiben die einzigen vergleichbaren Messungen über Modelle hinweg, die es gibt. Ein grobes, verrauschtes Signal ist besser als keines. Beides ist vertretbar. Dieser Leitfaden vertritt eine engere Position, die wir für unstrittig halten: Was immer ihr Wert für die Vorauswahl ist, über Ihre Anwendung sagen sie nichts aus. Das Einzige, was das tut, ist Ihr eigenes Eval-Set.