LLM-Benchmarks richtig lesen (und warum MMLU täuscht)

Wenn Sie zwei Modelle vergleichen, ist der erste Impuls, ein Leaderboard aufzurufen und die Scores anzuschauen. MMLU, HumanEval, GSM8K — die Zahlen wirken objektiv und vergleichbar. Das Problem: Frontier-Modelle erreichen auf MMLU heute 88–94 %, und in diesem Bereich sind die Unterschiede zwischen ihnen wahrscheinlicher Messrauschen als ein echter Leistungsunterschied. Ein Benchmark, der Modelle nicht mehr zuverlässig unterscheidet, verdient den Titel „saturiert" — und ein saturierter Benchmark sagt Ihnen über Ihren konkreten Use-Case so gut wie nichts.

Dieser Artikel erklärt, warum Benchmarks täuschen (oder zumindest irreführen), welche konkreten Mechanismen dahinterstecken und was Sie stattdessen tun können, anstatt Leaderboards blind zu vertrauen. Am Ende erhalten Sie einen praktischen Rahmen, den wir bei der Modellauswahl für Kunden verwenden.

Warum MMLU saturiert ist und was das bedeutet

MMLU (Massive Multitask Language Understanding) war bei seiner Entstehung ein wirklich nützliches Instrument — es deckte 57 Bereiche von Mathematik bis Recht und Medizin ab, und die ersten Modelle erzielten dort Ergebnisse im Bereich 50–60 %. Das ergab Sinn: Der Benchmark war schwerer als zufälliges Raten, aber nicht unüberwindbar.

Heute sieht die Lage anders aus. Wenn sich alle verglichenen Modelle in ein Band von 88–94 % einreihen, treten mehrere Probleme gleichzeitig auf:

• Die Unterschiede liegen im Bereich der statistischen Unsicherheit. Ein Unterschied von 1–2 Prozentpunkten bei einem üblichen Test-Set kann ein Artefakt des Promptings, der Reihenfolge der Antwortoptionen oder schlicht der Variabilität der Generierung sein.
• Die Formulierung des Prompts verändert das Ergebnis. Die Forschung zeigt immer wieder, dass dasselbe Modell allein durch eine andere Fragestellung um ±5–10 Prozentpunkte abweichen kann. Das ist kein Fehler eines bestimmten Modells — es ist eine Eigenschaft aller Sprachmodelle.
• Der Benchmark misst nicht, was Sie brauchen. MMLU testet Wissen im Multiple-Choice-Format. Ihre Anwendung generiert wahrscheinlich längere Texte, ruft Werkzeuge auf, arbeitet mit Kontext oder operiert in einer bestimmten Sprache. Das sind völlig andere Aufgaben.

Kontamination der Trainingsdaten — die stille Quelle aufgeblähter Scores

Eines der am wenigsten offen diskutierten Probleme beim Benchmarking ist die Kontamination (data contamination). Wenn Testdaten eines Benchmarks in den Trainingsdaten eines Modells auftauchen — was bei Modellen, die auf einem großen Teil des Internets trainiert wurden, ein reales Risiko ist — „erinnert" sich das Modell effektiv an die richtigen Antworten, anstatt den Stoff zu verstehen.

Die Erkennung von Kontamination ist schwierig. Die meisten Modellanbieter führen kein öffentlich zugängliches Audit ihrer Trainingsdaten. Einige veröffentlichen interne Ergebnisse von Decontamination-Tests, andere nicht. Das Resultat: Wenn Sie zwei Modelle auf MMLU vergleichen, haben Sie keine Gewissheit, ob Sie einen echten Unterschied in den Fähigkeiten sehen oder einen Unterschied darin, wie viele Testfragen in den Trainingsdaten aufgetaucht sind.

Praktische Konsequenz: Bevorzugen Sie bei der Modellauswahl immer Benchmarks mit dynamisch generierten oder nicht öffentlich zugänglichen Testsets. Einige neuere Sets — etwa LiveBench oder MMLU-Pro — versuchen dieses Problem durch regelmäßige Aktualisierungen und stärkeren Fokus auf Reasoning statt Auswendiglernen zu adressieren.

Overfitting auf Leaderboards als Kernproblem

Es gibt auch eine weniger unschuldige Version desselben Problems: gezielte Optimierung auf bestimmte Benchmarks. Wenn Modellanbieter wissen, dass der Markt auf MMLU, HumanEval und GSM8K vergleicht, entsteht ein starker wirtschaftlicher Druck, Modelle mit Schwerpunkt auf genau diese Sets zu trainieren (oder zu feintunen).

Das ist nicht zwingend Betrug — es kann eine Folge der Auswahl von Trainingsdaten, der Art des Instruction-Tunings oder der RLHF-Reward-Modelle sein. Das Ergebnis ist jedoch dasselbe: Ein Modell, das auf dem Leaderboard glänzt, kann bei realen Aufgaben, die der Benchmark nicht abdeckt, deutlich schlechter sein.

Wir haben das in der Praxis bei Projekten mit industrieller Dokumentation erlebt: Ein Modell, das in einem Coding-Benchmark gewonnen hatte, konnte strukturierte Daten aus technischen PDFs nicht zuverlässig extrahieren. Ein anderes Modell, mit niedrigerem Gesamtscore, zeigte bei derselben Aufgabe deutlich bessere Ergebnisse — weil seine Trainingsdaten wahrscheinlich mehr technischen Text im relevanten Format enthielten.

Warum die Leaderboard-Reihenfolge nicht mit dem Produktionsverhalten korreliert

Der aggregierte Leaderboard-Score ist wie die Durchschnittstemperatur einer Stadt: informativ auf sehr grobem Niveau, aber unbrauchbar für die Auswahl der Kleidung an einem konkreten Tag. Einige Gründe, warum die Modellreihenfolge auf einem Leaderboard nicht mit der Produktionsleistung korrelieren muss:

Domänenspezifität. Allgemeine Benchmarks testen einen Durchschnitt über Dutzende von Bereichen. Ihr Use-Case ist eine konkrete Domäne — Fertigungsdokumentation, Rechtsverträge, Kundensupport auf Slowakisch. Ein Modell, das im Durchschnitt stark ist, kann in genau Ihrer Domäne schwach sein.

Sprachliche Degradierung. Die meisten Benchmarks sind auf Englisch. Slowakisch ist eine Low-Resource-Sprache — Modelle degradieren darauf deutlich stärker als auf Englisch, doch diese Degradierung erscheint in einem englischen Leaderboard überhaupt nicht. Testen Sie immer separat in der Zielsprache. Erfahrung aus der Praxis: Ein Modell, das auf Englisch einen Vergleich gewann, landete auf Slowakisch im selben Test an dritter oder vierter Stelle.

Eingabe- und Ausgabeformat. Benchmarks testen typischerweise kurze Fragen mit kurzer Antwort. Produktionsanwendungen arbeiten mit langem Kontext, Werkzeugaufrufen, der Generierung von strukturiertem JSON oder Multi-Turn-Konversationen. Das sind unterschiedliche Aufgaben mit unterschiedlichen Anforderungen an das Modell.

Latenz und Kosten. Leaderboards messen Qualität, nicht Geschwindigkeit oder Preis. Das Modell mit dem höchsten Score kann 5× teurer und 3× langsamer sein als ein Modell mit 2 % niedrigerem Score — was im Produktionseinsatz entscheidend sein kann. Einen tieferen Einblick in die Modellauswahl unter Berücksichtigung dieser Faktoren bietet der Artikel Wie man ein LLM-Modell im Jahr 2026 auswählt.

Ein eigenes Eval ist immer wichtiger als ein Leaderboard

Aus dem Gesagten ergibt sich ein klares Fazit: Es gibt keinen externen Benchmark, der Ihnen sagen kann, welches Modell für Ihren Use-Case das richtige ist. Die einzige zuverlässige Wahrheitsquelle ist ein eigenes Eval, das auf Ihren Daten, Ihren Kriterien und Ihrer Sprache basiert.

Wie das in der Praxis funktioniert:

1. 1.Erfassen Sie reale Eingaben vom ersten Tag an. Loggen Sie jede Anfrage und jede Antwort (mit PII-Anonymisierung). Das ist der Goldschatz Ihrer Testfälle.
2. 2.Definieren Sie Qualitätskriterien für Ihre konkrete Aufgabe. Was bedeutet „eine gute Antwort" in Ihrem Fall? Sachliche Korrektheit? Einhaltung des Formats? Keine halluzinierten Zahlen? Jede Anwendung hat andere Kriterien.
3. 3.Erstellen Sie ein Eval-Set aus realen Fällen. Mindestens 50–100 Beispiele, idealerweise 200–500. Decken Sie Standardfälle und Edge Cases ab. Annotieren Sie erwartete Antworten oder zumindest Kriterien.
4. 4.Automatisieren Sie die Bewertung über `LLM-as-a-judge`. Ein stärkeres Modell (oder ein spezialisierter Eval-Prompt) bewertet die Ausgaben des getesteten Modells anhand Ihrer Kriterien. Das ist heute gängige Produktionspraxis. Der Artikel Wie man die Qualität einer LLM-Anwendung misst behandelt das Thema ausführlicher.
5. 5.Führen Sie das Eval vor jeder größeren Änderung aus. Modellwechsel, Prompt-Anpassung, Änderung der Retrieval-Strategie — jedes davon kann die Qualität unerwartet verschlechtern. Ohne Regressionstests erfahren Sie es erst vom Kunden.

Werkzeuge wie Langfuse (Open-Source, self-hostbar) oder Promptfoo (Open-Source, CI/CD-Integration) senken die Hürde für die Einführung eines Eval-Prozesses erheblich. Es sind keine reinen Enterprise-Werkzeuge — Sie können sie auch in kleinen Teams einsetzen.

Benchmarks konstruktiv lesen

Trotz aller Vorbehalte ist es nicht richtig, Benchmarks völlig zu ignorieren. Sie ergeben in bestimmten Kontexten Sinn:

Grobfilterung von Kandidaten. Wenn Sie Dutzende von Modellen vergleichen und die Auswahl auf 3–5 Finalisten eingrenzen müssen, ist ein Leaderboard ein legitimer erster Filter. Verwenden Sie ihn nicht für die endgültige Entscheidung, aber für die Eliminierung offensichtlich schwacher Modelle — ja.

Benchmark-Auswahl nach Aufgabe. Nicht alle Benchmarks sind gleich irreführend. Suchen Sie die, die Ihrem Use-Case am nächsten kommen: - Für Code-Generierung: HumanEval, MBPP, SWE-bench - Für mathematisches Reasoning: MATH, GSM8K - Für langen Kontext: RULER, HELMET - Für Instruction-Following: IFEval - Für allgemeines Reasoning: MMLU-Pro (schwerere Variante, weniger saturiert)

Dynamische Leaderboards. Plattformen wie ArtificialAnalysis aggregieren mehrere Dimensionen gleichzeitig — Qualität, Latenz, Preis, Context Window. Das ergibt ein weitaus realistischeres Bild als ein einzelner MMLU-Score.

Unter gleichen Bedingungen vergleichen. Wenn Sie zwei Modelle selbst evaluieren, verwenden Sie identische Prompts, identische Temperatur (temperature) und idealerweise dasselbe Eval-Framework. Jeder Unterschied in den Bedingungen verfälscht das Ergebnis.

Sonderfall: Slowakisch und regulierte Domänen

Für Anwendungen auf Slowakisch gilt eine einfache Regel: Vertrauen Sie niemals einem englischen Benchmark, ohne ihn in der Zielsprache zu überprüfen. Slowakisch ist eine Low-Resource-Sprache, und Modelle degradieren darauf deutlich stärker als auf Englisch. Diese Degradierung erscheint in gängigen Leaderboards überhaupt nicht, da die meisten Benchmarks auf Englisch sind.

Praktisches Vorgehen: Von den 2–3 anhand des Leaderboards ausgewählten Finalisten führen Sie ein eigenes Eval auf Slowakisch mit Ihren realen Daten durch. Die Reihenfolge kann sich verändern.

Für regulierte Domänen — Recht, Medizin, Pharmazie, Finanzberatung — gilt eine noch stärkere Warnung: Benchmark-Scores aus allgemeinen Domänen sagen Ihnen nichts darüber, wie gut ein Modell slowakische Rechtsklauseln, medizinische Abkürzungen oder Regulierungstext bewältigt. Diese Lücke ist der Grund, warum es sich in regulierten Bereichen lohnt, über Fine-Tuning auf Domänendaten nachzudenken — was wir im Artikel RAG vs. Fine-Tuning — wie man entscheidet ausführlicher behandeln.

Warnsignale beim Lesen von Benchmark-Aussagen

Wenn Sie in einer Anbieterpräsentation oder einem PR-Artikel auf Benchmark-Ergebnisse stoßen, achten Sie auf diese Warnsignale:

• Benchmark ohne Messdatum. Modelle werden aktualisiert, Benchmarks ändern sich — eine Zahl ohne Datum kann um Monate veraltet sein.
• Selektive Benchmark-Auswahl. Wenn ein Anbieter 5 Benchmarks nennt, bei denen er gewinnt, und die anderen verschweigt, ist das Selektionsbias.
• Fehlende Information zum Prompting. „Few-shot" vs. „zero-shot", Chain-of-Thought vs. direkte Antwort — jedes davon kann das Ergebnis um mehrere Prozentpunkte verschieben. Ohne diese Information sind die Zahlen nicht vergleichbar.
• Vergleich mit Benchmarks eines anderen Alters. Einen neuen Modell mit zwei Jahre alten Wettbewerbern zu vergleichen ist legitimes Marketing, aber kein objektiver Vergleich.
• Benchmark, den das Modell wahrscheinlich im Training gesehen hat. Je älter und populärer ein Benchmark ist (wie MMLU), desto höher die Wahrscheinlichkeit der Kontamination.

Häufige Fragen

Bedeutet ein höherer MMLU-Score ein besseres Modell für mein Unternehmen?

Nicht zwingend. MMLU ist ein saturierter Benchmark — Unterschiede zwischen Frontier-Modellen im Bereich 88–94 % liegen an der Grenze der statistischen Unsicherheit. Für Ihren konkreten Use-Case ist nur der Score bei Aufgaben relevant, die Ihren ähneln, in der Sprache Ihres Einsatzes. Ein eigenes Eval auf realen Daten ist ein zuverlässigerer Indikator als jedes allgemeine Leaderboard.

Kann ich einem Benchmark vertrauen, wenn ihn der Modellanbieter selbst veröffentlicht hat?

Mit Vorbehalt. Anbieter haben ein legitimes Interesse daran, ihr Modell im bestmöglichen Licht darzustellen, was zu selektiver Benchmark-Auswahl oder vorteilhafteren Testbedingungen führen kann. Das bedeutet nicht, dass die Zahlen erfunden sind — aber suchen Sie immer nach unabhängigen Reproduktionen, zum Beispiel auf Plattformen wie ArtificialAnalysis, oder führen Sie einen eigenen Vergleich durch.

Was ist Kontamination von Trainingsdaten und warum ist das ein Problem?

Kontamination tritt auf, wenn Testfragen eines Benchmarks in den Trainingsdaten eines Modells auftauchen. Das Modell „erinnert" sich dann an die richtigen Antworten, anstatt sie aus Verständnis abzuleiten. Das Ergebnis ist ein aufgeblähter Benchmark-Score, der den tatsächlichen Fähigkeiten nicht entspricht. Die Erkennung ist schwierig, da die meisten Anbieter die genaue Zusammensetzung ihrer Trainingsdaten nicht veröffentlichen.

Wie schnell kann ich ein erstes eigenes Eval aufbauen?

Für ein erstes Eval genügen 50–100 reale Beispiele aus Ihrer Anwendung mit annotierten erwarteten Ausgaben oder Qualitätskriterien. Werkzeuge wie Promptfoo oder Langfuse ermöglichen es, die ersten automatisierten Bewertungen in Tagen statt Wochen zu starten. Das Entscheidende ist, klein anzufangen und zu iterieren — nicht auf ein „perfektes" Set zu warten.

Ändert sich die Modellreihenfolge zwischen Versionen?

Ja, erheblich und unvorhersehbar. Eine Modellaktualisierung (auch bei gleichem Namen) kann die Leistung bei verschiedenen Aufgaben in verschiedene Richtungen verschieben. Deshalb ist ein Eval, das als Regressionstest eingerichtet ist — nicht als einmaliger Vergleich — für Produktionseinsätze entscheidend. Jede größere Änderung (neue Modellversion, neuer Prompt, neues Retrieval-System) muss am selben Eval-Set überprüft werden.

*Wir helfen Unternehmen dabei, einen Eval-Prozess aufzubauen, der in der Produktion funktioniert — von der Auswahl der Testfälle über die automatisierte Bewertung bis hin zur Integration in die CI/CD-Pipeline. Wenn Sie nicht wissen, wo Sie anfangen sollen, schauen wir uns gerne Ihren konkreten Use-Case an.*