{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidpo6khi34yn2s3iubdkjilzdz2hbf5pv4ffrvdrxlnneiyv45usy",
    "uri": "at://did:plc:jcdhsk6w7rxuehjvjgwrwr7d/app.bsky.feed.post/3mln2pkze57d2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreidd7k3iih2a23utpnr6fwdgrlblbo5mnlbxruqspihjayhp4wen7a"
    },
    "mimeType": "image/webp",
    "size": 89026
  },
  "description": "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",
  "path": "/ki-systemdesign/wenn-benchmarks-lugen-warum-der-llm-vergleich-kaputt-ist/",
  "publishedAt": "2026-05-12T05:30:52.000Z",
  "site": "https://t01.li",
  "tags": [
    "Vertrauenskrise der Benchmarks",
    "einen der wichtigsten Coding-Benchmarks für unbrauchbar erklärt",
    "explizit aus seinem Leaderboard aus",
    "heute scoren Top-Modelle dort 99%",
    "ähnlich saturiert",
    "oft zitierte Studie aus 2024",
    "bestätigen den Befund",
    "MMLU-CF gebaut",
    "trifft den AI-Benchmark-Zirkus mitten ins Gesicht",
    "die Git-Historie der Repos zu durchsuchen",
    "eigenen, ausführlichen Audit",
    "unabhängig vom Inhalt",
    "Leaderboard Illusion“-Paper",
    "in Teilen widersprochen",
    "aktuell bei rund 80%",
    "auf 46–57%",
    "noch tiefer",
    "heute über 96%",
    "Anfang 2025 noch nahe 0%",
    "eine aktuelle Studie",
    "GPT-4o bei 2,7%, Claude 3.5 Sonnet bei 4,1%, o1 bei 8%",
    "offiziellen Scale-AI-Leaderboard",
    "in sich schon ein Problem ist",
    "bereits über 94%",
    "LiveBench",
    "LiveCodeBench",
    "neben SWE-bench Pro mit seinem privaten Subset",
    "eigene, aufgabenspezifische Eval-Suite"
  ],
  "textContent": "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.\n\nDas 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.\n\n##  TL;DR\n\nMeine Ausgangsthese war, dass rund 60 % der gängigen LLM-Benchmarks Käse sind. Die Recherche hat sie nicht widerlegt – sie hat sie verschärft. Schuld sind drei Probleme, die sich gegenseitig verstärken:\n\n  * **Saturation:** Klassiker wie MMLU, GSM8K und HumanEval liegen bei den Top-Modellen nahe 100 %. Wenn alle 96 % scoren, sind die Unterschiede Rauschen, kein Signal.\n  * **Contamination:** Ein Teil der hohen Scores ist Auswendiglernen statt Können. Auf einer stilgleichen, aber unbekannten GSM8K-Variante verloren manche Modelle bis zu 13 Prozentpunkte.\n  * **Goodhart:** Sobald ein Score zum Ziel wird, misst er die Fähigkeit nicht mehr. Coding-Agents durchsuchten die Git-Historie nach der fertigen Lösung – OpenAI hat SWE-bench Verified im Februar 2026 selbst für verbrannt erklärt.\n\n\n\nDas Lehrstück in einer Zahl: Dieselben Modelle, die auf SWE-bench Verified rund 80 % schaffen, fallen auf SWE-bench Pro mit fremdem, privatem Code auf 46 bis 57 %.\n\nWas bleibt, sind dynamische Benchmarks wie LiveBench als grober Filter – und für die eigentliche Frage eine eigene Eval-Suite mit echten Beispielen aus dem eigenen Workflow. Mühsam, aber für den eigenen Anwendungsfall die einzige belastbare Zahl.\n\n## Das erste Problem: Saturation\n\nEin Benchmark ist tot, wenn die Top-Modelle alle nahe 100% scoren. Genau das ist der Status für eine ganze Reihe der Klassiker.\n\nMMLU – 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.\n\nWas 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.\n\n## Das zweite Problem: Contamination\n\nSaturation wäre weniger schlimm, wenn die Scores wenigstens echt wären. Sind sie aber nicht zwingend.\n\nEine 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.\n\nDas 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.\n\n## Das dritte Problem: Goodhart\n\n> \"When a measure becomes a target, it ceases to be a good measure.\"\n\nGoodhart'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.\n\nDas 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.\n\nIm 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.\n\nChatbot 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.\n\n## Wo der Realitätsbezug bricht: SWE-bench als Lehrstück\n\nSpannender 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.\n\nAuf 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.\n\nDas 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.\n\n## Reasoning-Benchmarks: schneller geknackt, als sie reifen können\n\nDer 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.\n\nTrotzdem:\n\n  * ARC-AGI-1: 2024 noch unbeaten, heute über 96% bei Top-Modellen mit Test-Time-Compute.\n  * ARC-AGI-2: Aktuell 85% (_GPT-5.5_), Anfang 2025 noch nahe 0%.\n  * ARC-AGI-3: Bei 13%.\n\n\n\nDas 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.\n\nHumanity'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.\n\n## Was übrig bleibt: dynamische Benchmarks und eigene Evals\n\nWenn alles, was statisch und öffentlich ist, früher oder später kontaminiert oder saturiert ist, lautet die naheliegende Antwort: nicht statisch, nicht öffentlich.\n\nLiveBench 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.\n\nDas ist die kleine Ecke der Benchmark-Landschaft, die meinem ursprünglichen 60%-Verdikt am ehesten entkommt.\n\nAber 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.\n\n## Fazit – ergebnisoffen, wie versprochen\n\nMeine 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.\n\nPraktisch 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.\n\nDas 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.",
  "title": "Wenn Benchmarks lügen – warum der LLM-Vergleich kaputt ist",
  "updatedAt": "2026-05-29T18:57:40.225Z"
}