Benchmarks und Evaluierungen – Zwischen den Zeilen lesen

Warum Benchmarks wichtig sind (und warum sie nicht ausreichen)

Jede Modellveröffentlichung wird von einer Tabelle mit Scores auf standardisierten Benchmarks begleitet. Diese Zahlen wandern oft ungeprüft in Presseartikel und interne Präsentationen. Sie sind nützlich: Sie geben einen ersten Eindruck von den Fähigkeiten und helfen, ein Modell im Ökosystem einzuordnen. Doch sie werden irreführend, sobald man sie liest, ohne zu wissen, was sie tatsächlich messen. Diese Lektion zeigt Ihnen, wie Sie Benchmarks mit der Distanz eines Praktikers interpretieren – nicht mit dem Enthusiasmus einer Pressemitteilung.

Was Standard-Benchmarks messen

MMLU (Massive Multitask Language Understanding) prüft das allgemeine Wissen eines Modells in 57 Domänen – Geschichte, Physik, Recht, Medizin, Informatik – in Form von Multiple-Choice-Fragen mit vier Antwortoptionen. Es misst also die Breite des faktischen Wissens, sonst nichts: weder die Fähigkeit zu logischem Schlussfolgern, noch komplexe Anweisungen zu befolgen, noch die textliche Qualität. Die besten Modelle liegen heute bei 85 bis 90 %. Das bedeutet zugleich, dass dieser Benchmark die Spitze des Feldes immer schlechter differenziert. Ein Modell, das bei MMLU exzellent abschneidet, kann dennoch scheitern, wenn es eine lesbare Zusammenfassung verfassen soll.

HumanEval testet die Generierung von funktionalem Python-Code aus einer natural-sprachlichen Beschreibung; MBPP (Mostly Basic Python Problems) tut dasselbe mit einfacheren Aufgaben. Diese Benchmarks messen die Fähigkeit, eine isolierte, korrekte Funktion zu schreiben. Sie sagen nichts darüber aus, ob ein Modell in einer bestehenden Codebasis arbeiten, unerwartetes Verhalten debuggen oder ein Projekt architektonisch strukturieren kann – also genau das, worauf es im Berufsalltag ankommt. Es existieren Varianten wie HumanEval+ mit strengeren Tests oder MultiPL-E zur Abdeckung mehrerer Programmiersprachen.

LMArena, ehemals Chatbot Arena, geht anders vor: Echte Nutzer stellen zwei anonymen Modellen ihre Fragen und stimmen für die bessere Antwort. Das Ranking entsteht über ein Elo-System, das aus dem Schach bekannt ist. Dieses Setup misst die wahrgenommene Qualität in freien Gesprächen und kommt damit dem realen Einsatz am nächsten. Die Schwäche ist symmetrisch: Es liefert keine Aussage zur Performance bei einer konkreten technischen Aufgabe und begünstigt mechanisch Antworten, die angenehm zu lesen sind.

Weitere Evaluierungen ergänzen das Bild je nach Zielkapazität. GSM8K und MATH befassen sich mit der Lösung mathematischer Probleme, ARC mit naturwissenschaftlichem Reasoning auf Sekundarstufenniveau, HellaSwag mit der Vervollständigung von Szenarien des gesunden Menschenverstands, TruthfulQA mit der Resistenz gegen Halluzinationen und Desinformation, und CTO Bench mit realistischen End-to-End-Coding-Aufgaben, die deutlich praxisnäher sind als HumanEval.

Vier Regeln zum Lesen von Score-Tabellen

Die erste Regel lautet: Vergleichen Sie Vergleichbares. Ein 3-Milliarden-Parameter-Modell gegen ein 70-Milliarden-Modell in denselben Spalten gegenüberzustellen, ergibt keinen Sinn, wenn man Größenordnung und Kosten ignoriert. Die relevante Frage ist nie „Wer hat den besten Score?”, sondern „Welches Modell liefert für ein gegebenes Budget die besten Ergebnisse?”.

Die zweite Regel mahnt zur Vorsicht bei marginalen Verbesserungen. Ein Unterschied von ein oder zwei Punkten im MMLU zwischen zwei Modellen ist meist insignifikant: Benchmarks unterliegen einer natürlichen Varianz, und diese Differenz wird für Ihre Nutzer nicht wahrnehmbar sein. Dennoch eignen sich solche Zahlen hervorragend für Schlagzeilen in Pressemitteilungen.

Die dritte Regel fordert, nach Konsistenz zu suchen. Ein Modell, das in nur einem Benchmark glänzt und überall anders im Durchschnitt bleibt, sollte Misstrauen wecken. Solide Modelle zeigen regelmäßige Performance über das gesamte Spektrum der Evaluierungen hinweg.

Die vierte Regel verlangt, das Datum zu prüfen. Scores, die zum Launch eines Modells veröffentlicht wurden, können wenige Monate später nicht mehr repräsentativ sein, weil neue Konkurrenten hinzugekommen sind und sich die Evaluierungsmethodiken weiterentwickelt haben. Eine undatierte Tabelle in einer kommerziellen Präsentation sollte immer die Frage nach ihrer Herkunft nach sich ziehen.

Drei strukturelle Grenzen

Die Kontamination ist die heimtückischste Grenze. Modelle werden auf immensen Textkorpora trainiert, die die Fragen und Antworten der Benchmarks selbst enthalten können. Ein hoher Score kann dann eher Auswendiglernen als echte Reasoning-Fähigkeit widerspiegeln – ganz ohne böse Absicht.

Die Repräsentativität stellt ein anderes Problem dar: Standardisierte Benchmarks spiegeln nicht Ihren Use-Case wider. Ein Modell, das bei MMLU exzelliert, kann sich als mittelmäßig erweisen, wenn es darum geht, geschäftliche E-Mails auf Deutsch zu verfassen, schlicht weil diese Aufgabe niemand evaluiert hat. Benchmarks messen generische Fähigkeiten, niemals die Performance in Ihrem spezifischen Kontext.

Die Optimierung schließlich ist eine vorhersehbare Konsequenz der Publicity um Rankings. Labore kennen die Benchmarks und können das Training so ausrichten, dass sie dort gut abschneiden – manchmal auf Kosten anderer Aufgaben. Dies ist das Phänomen des „Teaching to the Test”, das auch außerhalb der Künstlichen Intelligenz gut dokumentiert ist.

Quellen kreuzen und selbst testen

Verlassen Sie sich nicht allein auf die Zahlen, die ein Anbieter – Mistral oder ein anderer – veröffentlicht. Kreuzen Sie diese mit unabhängigen Rankings. Artificial Analysis vergleicht Qualität, Preis, Geschwindigkeit und Latenz auf einer homogenen Basis. LMArena spiegelt die menschliche Präferenz unter realen Bedingungen wider. Das Scale AI Leaderboard fokussiert auf Coding, Instruction Following und Mathematik. Die Rankings von OpenRouter basieren auf der tatsächlichen Nutzung, also darauf, wofür Entwickler bereit sind zu zahlen. CTO Bench schließlich bietet realistische End-to-End-Coding-Aufgaben.

Letztlich ist die einzige Evaluierung, die Ihre Entscheidung wirklich trägt, die, die Sie mit Ihren eigenen Daten, Ihren Use-Cases und Ihren Qualitätskriterien durchführen. Die Methode umfasst sechs Schritte:

1. Stellen Sie einen Testdatensatz aus 20 bis 50 Beispielen zusammen, die Ihren realen Einsatz abbilden
2. Definieren Sie Ihre Qualitätskriterien explizit (Präzision, Ton, Vollständigkeit, Format)
3. Testen Sie 2 bis 3 Kandidaten-Modelle auf diesem identischen Datensatz
4. Evaluieren Sie nach Möglichkeit blind, ohne zu wissen, welches Modell welche Antwort erzeugt hat
5. Messen Sie zudem die Latenz und die Kosten pro Anfrage
6. Treffen Sie Ihre Entscheidung anhand des Verhältnisses von Qualität, Kosten und Constraints

Der blinden Evaluierung ist besondere Aufmerksamkeit zu widmen: Nichts verzerrt ein Urteil stärker, als zu wissen, dass eine Antwort von dem Modell stammt, von dem man hoffte, es würde gewinnen.

Kernaussagen

• Benchmarks geben eine erste Indikation, reichen aber nicht zur Modellauswahl
• MMLU misst Wissen, HumanEval Code, LMArena menschliche Präferenz
• Seien Sie skeptisch gegenüber marginalen Unterschieden und der Kontamination von Benchmarks
• Ziehen Sie unabhängige Rankings heran (Artificial Analysis, LMArena, Scale AI)
• Die beste Evaluierung ist stets die mit Ihren eigenen Daten