KI-Benchmark

Ein KI-Benchmark ist ein standardisierter Test, der die Fähigkeiten eines KI-Modells anhand einer festen Aufgabensammlung misst und das Ergebnis als vergleichbare Kennzahl ausgibt. Benchmarks sind die Grundlage jeder Modellrangliste, gleichzeitig aber nur so aussagekräftig wie ihre Aufgaben, ihre Messmethode und ihr Schutz vor Auswendiglernen.

Wie ein KI-Benchmark funktioniert

Ein Benchmark besteht im Kern aus drei Teilen: einem Datensatz mit Aufgaben, einer Bewertungsregel und einem Protokoll, das festlegt, wie das Modell die Aufgaben bekommt. Bei einem Wissenstest wie MMLU sind das rund 14.000 Multiple-Choice-Fragen aus 57 Fachgebieten, die Bewertung ist der Anteil richtiger Antworten, und das Protokoll legt fest, ob das Modell Beispiele sieht (Few-Shot) oder nicht (Zero-Shot). Bei einem Coding-Benchmark wie SWE-bench ist die Aufgabe ein echtes GitHub-Issue, die Bewertung erfolgt über die Testsuite des Projekts, und das Protokoll bestimmt, welche Werkzeuge und wie viele Versuche das Modell bekommt.

Das Ergebnis ist eine Zahl: 88,7 Prozent auf MMLU, 72 Prozent auf SWE-bench Verified, ein Elo-Wert von 1.400 in einer Arena. Diese Zahl ist nur innerhalb desselben Benchmarks und desselben Protokolls vergleichbar. Zwei Modelle, die auf demselben Test mit unterschiedlichem Werkzeugzugang oder unterschiedlicher Denkzeit gemessen wurden, lassen sich nicht direkt gegenüberstellen, auch wenn beide Zahlen in derselben Tabelle stehen.

Die wichtigsten Benchmark-Familien

Warum Benchmarks altern: Sättigung und Kontamination

Zwei Effekte sorgen dafür, dass jeder Benchmark ein Verfallsdatum hat.

Sättigung tritt ein, wenn die besten Modelle nahe an 100 Prozent liegen. Dann trennt der Test nicht mehr zwischen ihnen, und die verbleibenden Punkte sind oft Fehler im Datensatz selbst, nicht Schwächen des Modells. MMLU wurde 2020 veröffentlicht, als die besten Modelle rund 44 Prozent erreichten; wenige Jahre später lagen Spitzenmodelle bei fast 90 Prozent, und Analysen fanden fehlerhafte oder mehrdeutige Fragen. GSM8K, der 2021 als anspruchsvoller Grundschul-Mathetest eingeführt wurde, ist heute praktisch gelöst.

Kontamination bedeutet, dass Testaufgaben oder ihre Lösungen im Trainingsmaterial des Modells enthalten waren. Da Sprachmodelle auf großen Teilen des öffentlichen Internets trainiert werden und Benchmark-Datensätze öffentlich auf GitHub oder Hugging Face liegen, ist das kaum vollständig zu vermeiden. Ein kontaminiertes Modell erzielt einen hohen Wert, ohne die Fähigkeit tatsächlich zu besitzen. Bei Coding-Benchmarks, deren Aufgaben aus öffentlichen Repositories stammen, kann ein Modell die tatsächliche Lösung eines Issues gesehen haben und sie schlicht reproduzieren.

Der Forschungsstand zu diesen Problemen ist gut dokumentiert; einen Überblick über die Konzepte und Kritikpunkte gibt der Wikipedia-Artikel zu Sprachmodell-Benchmarks. Die Reaktion der Benchmark-Anbieter besteht aus drei Strategien: private Testsets, die nie veröffentlicht werden; regelmäßig erneuerte Aufgaben (etwa LiveCodeBench, das nur Aufgaben nach dem Trainingsstichtag eines Modells wertet); und interaktive Formate, bei denen es keine feste Lösung zum Auswendiglernen gibt, weil das Modell eine Umgebung erst erkunden muss.

Messprotokoll: Denkzeit, Werkzeuge, Versuche

Seit Modelle vor der Antwort „nachdenken" können, hat sich das Protokoll zu einem eigenen Einflussfaktor entwickelt. Dieselbe Modellversion erreicht auf demselben Test mit niedriger Denkstufe einen anderen Wert als mit maximaler, und der Unterschied kann zweistellig sein. Hinzu kommen Werkzeugzugang (darf das Modell Code ausführen oder im Netz suchen?), die Zahl der Versuche (ein Durchlauf oder der beste aus acht?) und das Rechenbudget in US-Dollar pro Aufgabe. Seriöse Ranglisten geben diese Parameter mit an, etwa als „pass@1" für einen Versuch oder als Kostenangabe je Testlauf. Wer zwei Zahlen vergleicht, sollte zuerst prüfen, ob sie unter demselben Protokoll entstanden sind. Ein Wert ohne Protokollangabe ist für eine Entscheidung nahezu wertlos.

Warum das für Unternehmen wichtig ist

Wer im Mittelstand ein Modell für einen Prozess auswählt, trifft eine Entscheidung mit Folgekosten: Token-Preise, Integrationsaufwand, Schulung, gegebenenfalls ein Anbieterwechsel. Benchmark-Tabellen sind der naheliegende Einstieg, führen aber auf drei Arten in die Irre.

• Der Benchmark misst nicht deine Aufgabe. Ein Modell, das bei Mathe-Olympiaden führt, ist nicht automatisch besser darin, deutsche Lieferantenrechnungen zu extrahieren oder Produkttexte in Markenstimme zu schreiben. Für die meisten Unternehmensaufgaben gibt es keinen öffentlichen Benchmark.
• Anbieterzahlen und unabhängige Zahlen unterscheiden sich. Hersteller messen mit der für ihr Modell günstigsten Konfiguration: maximale Denkzeit, eigener Werkzeugzugang, teils mehrere Versuche mit Auswahl des besten. Unabhängige Stellen messen mit einheitlichem Protokoll und Budget. Die Differenz liegt oft bei fünf bis zehn Prozentpunkten.
• Kosten fehlen in der Tabelle. Ein Modell, das zwei Punkte besser ist und das Fünffache kostet, ist für einen Batch-Prozess mit Millionen Aufrufen die falsche Wahl. Kennzahlen wie Preis pro gelöster Aufgabe oder Kosten pro Prozentpunkt sind für Kaufentscheidungen aussagekräftiger als der Rohwert.

Die praktische Konsequenz: Öffentliche Benchmarks eignen sich für eine Vorauswahl von zwei bis vier Kandidaten. Die Entscheidung sollte ein eigener Test mit realen Daten aus dem Prozess treffen, mit einer festen Bewertungsregel und einem Vergleich der Kosten pro Aufgabe. Dieses eigene Evaluationsset ist zugleich die Grundlage für spätere Modellwechsel, weil es jede neue Version an denselben Fällen misst.

Ein Realbeispiel: SWE-bench und seine Verifizierung

SWE-bench wurde 2023 von Forschern der Princeton University veröffentlicht. Der Datensatz besteht aus über 2.000 echten GitHub-Issues aus zwölf populären Python-Projekten. Ein Modell bekommt die Problembeschreibung und das Repository und muss einen Patch erzeugen, der die zugehörigen Tests bestehen lässt. Das war ein Fortschritt gegenüber HumanEval, das nur kleine, isolierte Funktionen abfragte: SWE-bench prüft, ob ein Modell sich in fremdem Code zurechtfindet.

Schnell zeigte sich, dass viele Aufgaben unlösbar oder unterspezifiziert waren, weil die Issue-Beschreibung nicht ausreichte oder die Tests mehr prüften, als im Issue stand. OpenAI ließ deshalb 2024 gemeinsam mit den Autoren jede Aufgabe von Softwareentwicklern prüfen und veröffentlichte SWE-bench Verified, eine bereinigte Teilmenge von 500 Aufgaben. Innerhalb von rund zwei Jahren stiegen die besten Ergebnisse von unter 5 Prozent auf über 70 Prozent. Danach wiederholte sich das Muster: Auch die verifizierte Teilmenge geriet unter Sättigungs- und Kontaminationsverdacht, weil die Lösungen der Issues öffentlich in den Repositories liegen. Die Community wich auf schwerere und frischere Varianten aus (SWE-bench Pro, Multi-SWE-bench, Terminal-Bench), und mehrere Anbieter berichten den ursprünglichen Wert nicht mehr in ihren Modellkarten.

Die Lehre aus dieser Geschichte gilt für jeden Benchmark: Ein guter Test hat eine Lebensdauer von wenigen Jahren, und ein Wert von über 90 Prozent sagt mehr über das Alter des Tests aus als über das Modell.

Abgrenzung: was ein Benchmark nicht ist

Ein Benchmark ist keine Evaluation. Evaluation ist der Oberbegriff für jede systematische Prüfung eines Modells, einschließlich eigener Tests, Red-Teaming und Nutzerstudien. Ein Benchmark ist eine standardisierte, öffentlich vergleichbare Form davon.

Ein Leaderboard ist kein Benchmark. Ranglisten wie die von Artificial Analysis oder LMArena fassen mehrere Benchmarks oder Nutzerabstimmungen zu einem Index zusammen. Die Gewichtung der Einzeltests ist eine redaktionelle Entscheidung des Betreibers und verändert die Reihenfolge.

Ein Elo-Wert ist kein Prozentwert. Arena-Ratings entstehen aus Paarvergleichen und sind relativ: Sie sagen, wie oft ein Modell gegen andere gewinnt, nicht, wie oft es richtig liegt. Präferenz-Benchmarks belohnen außerdem Stil und Ausführlichkeit, was für sachliche Genauigkeit nicht immer ein guter Indikator ist.

„Human-level" ist ein bewegliches Ziel. Viele Benchmarks geben eine menschliche Referenz an, doch die Vergleichsgruppe reicht von Crowdworkern bis zu promovierten Experten. Ein Modell, das „Expertenniveau" auf GPQA erreicht, ist nicht deswegen ein Experte im Beruf.

Ausblick

Die Benchmark-Landschaft verschiebt sich in drei Richtungen. Erstens hin zu agentischen, interaktiven Tests, bei denen das Modell in einer Umgebung handelt, Werkzeuge nutzt und über viele Schritte hinweg ein Ziel verfolgt; hier ist Kontamination schwer und die Nähe zur realen Arbeit groß. Zweitens hin zu wirtschaftlich begründeten Tests, die echte berufliche Arbeitsergebnisse von Fachleuten bewerten lassen, statt Multiple-Choice-Fragen zu zählen. Drittens hin zu Effizienzmaßen: Neben dem Ergebnis werden Kosten, Latenz und Token-Verbrauch pro Aufgabe ausgewiesen, weil Modelle mit einstellbarer Denkzeit denselben Test zu sehr unterschiedlichen Preisen bestehen können. Für Unternehmen wird damit wichtiger, die eigene Aufgabe als Benchmark zu formulieren, als die öffentlichen Ranglisten zu verfolgen.

Häufige Fragen

Welcher KI-Benchmark ist der wichtigste?
Es gibt keinen. Für Coding sind agentische Tests wie SWE-bench-Varianten und Terminal-Bench relevant, für Fachwissen GPQA und Humanity's Last Exam, für die Alltagsqualität von Antworten Arena-Ratings. Für eine Kaufentscheidung im Unternehmen ist der wichtigste Benchmark der eigene, mit realen Daten aus dem Prozess.

Warum nennen Hersteller höhere Werte als unabhängige Tester?
Weil sie mit der für ihr Modell besten Konfiguration messen: maximale Denkzeit, eigene Werkzeuge, teils mehrere Versuche. Unabhängige Stellen verwenden ein einheitliches Protokoll für alle Modelle. Beide Zahlen können korrekt sein, sie sind nur nicht vergleichbar.

Was bedeutet es, wenn ein Benchmark „gesättigt" ist?
Dass die besten Modelle so nahe am Maximum liegen, dass der Test nicht mehr zwischen ihnen unterscheidet. Die restlichen Fehler sind dann häufig Fehler im Testdatensatz. Ein gesättigter Benchmark taugt noch zur Prüfung schwacher Modelle, aber nicht mehr zum Vergleich der Spitze.

Wie baue ich einen eigenen Benchmark für meinen Anwendungsfall?
Sammle 50 bis 200 reale Fälle aus dem Prozess mit einer eindeutig prüfbaren Sollausgabe, lege eine Bewertungsregel fest (exakte Übereinstimmung, Prüfung durch ein zweites Modell nach Kriterienkatalog oder Fachbewertung), und miss für jedes Kandidatenmodell Trefferquote, Latenz und Kosten pro Fall. Halte Testfälle getrennt von allem, was in Prompts oder Fine-Tuning einfließt.

Kann ein Modell Benchmarks „auswendig lernen"?
Ja, das nennt man Kontamination. Öffentliche Testfragen landen im Trainingsmaterial, und das Modell reproduziert die Lösung, ohne die Aufgabe zu verstehen. Seriöse Benchmark-Betreiber halten deshalb Teile ihrer Aufgaben geheim oder erneuern sie regelmäßig.