KI-Benchmarks richtig einordnen: Was sie zeigen - und was nicht

Kaum eine größere Modellveröffentlichung kommt heute ohne Benchmark-Tabelle aus. Werte für Coding, mathematisches Reasoning, wissenschaftliche Fragen oder agentische Aufgaben sollen zeigen, wo ein neues Modell gegenüber Vorgängern und Wettbewerbern steht. Solche Vergleiche sind wichtig. Ohne standardisierte Tests wäre es deutlich schwieriger, technische Fortschritte nachvollziehbar zu messen.

Problematisch wird es, wenn aus einem konkreten Testergebnis eine allgemeine Rangfolge wird. Aus „Modell A erreicht auf Benchmark X einen höheren Wert als Modell B“ wird dann schnell „Modell A ist besser“. Dafür gibt ein einzelner Benchmark meist zu wenig her.

Wie begrenzt selbst ein etablierter Test sein kann, zeigte sich 2026 besonders deutlich bei SWE-bench Verified, einem verbreiteten Benchmark für autonome Softwareentwicklungsaufgaben. Im Februar erklärte OpenAI, ihn nicht mehr zur Evaluation eigener Frontier-Modelle zu verwenden. Bei einer Untersuchung häufig nicht gelöster Aufgaben fand das Unternehmen sowohl Hinweise auf bekannte Testinhalte in Trainingsdaten als auch Probleme in den Aufgaben selbst. Dazu gehörten unvollständige Anforderungen, Tests, die funktional richtige Lösungen nicht zuverlässig erkannten, und Fälle, in denen für eine erfolgreiche Lösung Implementierungsdetails vorausgesetzt wurden, die aus der Aufgabenbeschreibung nicht hervorgingen. OpenAI dokumentierte die Gründe für diesen Schritt im Februar 2026.

Im Juli folgte eine Prüfung von SWE-Bench Pro, den OpenAI zuvor selbst als Alternative empfohlen hatte. Je nach Prüfverfahren bewertete das Unternehmen dort 27,4 beziehungsweise 34,1 Prozent der untersuchten Aufgaben als fehlerhaft. Daraufhin zog OpenAI auch die Empfehlung für SWE-Bench Pro wieder zurück.

Der Fall macht SWE-bench nicht nachträglich wertlos. Er zeigt vielmehr, was bei Benchmarkwerten leicht aus dem Blick gerät: Ein Benchmark ist ein Messinstrument mit einem definierten Aufgabenraum, einem Bewertungsverfahren und Grenzen.

Ein KI-Benchmark besteht vereinfacht aus Aufgaben, einem festgelegten Evaluationsverfahren und einer Metrik, nach der die Antworten bewertet werden. Gemessen werden kann etwa die Zahl korrekt beantworteter Multiple-Choice-Fragen, die erfolgreiche Behebung von Softwarefehlern oder die Leistung in einer simulierten Umgebung.

Abstrakte Eigenschaften wie „Intelligenz“, „Reasoning“ oder „allgemeine Modellqualität“ lassen sich dagegen nicht direkt beobachten. Wer sie messen will, muss zunächst entscheiden, welche konkreten Aufgaben als Stellvertreter für diese Fähigkeit dienen sollen.

Wie schwierig diese Übersetzung ist, zeigt eine 2025 auf der NeurIPS veröffentlichte Untersuchung von 445 LLM-Benchmarks. Im Mittelpunkt steht die sogenannte Construct Validity: die Frage, ob Aufgaben und Metriken tatsächlich belastbare Aussagen über die Fähigkeit erlauben, die ein Benchmark zu messen vorgibt. Die Autoren fanden wiederkehrende Schwächen bei der Definition solcher Fähigkeiten, ihrer Umsetzung in konkrete Aufgaben und den Schlussfolgerungen, die anschließend aus den Ergebnissen gezogen wurden. Die Studie liefert damit eine methodische Grundlage für die Frage, was ein Benchmarkwert tatsächlich aussagt.

Ein sauber konstruierter Coding-Benchmark kann sehr wohl etwas über Coding-Fähigkeiten aussagen. Seine Aussage bleibt jedoch an den getesteten Aufgabenraum gebunden. Ein Modell, das akademische Multiple-Choice-Fragen sehr zuverlässig beantwortet, ist dadurch nicht automatisch besonders gut darin, Informationen aus langen Unternehmensdokumenten zu extrahieren. Und erfolgreiche Fehlerbehebungen in öffentlichen GitHub-Repositories sagen noch nicht, wie sich dasselbe Modell in einer gewachsenen internen Codebasis verhält.

Vor der Frage, welches Modell den höheren Wert erreicht, steht deshalb eine andere: Was wurde mit diesem Test überhaupt gemessen?

Mathematisches Schlussfolgern, Coding, Sprachverständnis, Tool-Nutzung oder die Verarbeitung langer Kontexte stellen unterschiedliche Anforderungen. Sie lassen sich nicht sinnvoll mit denselben Aufgaben prüfen. Entsprechend bestehen aktuelle Modellberichte aus einer ganzen Reihe verschiedener Evaluationen.

Die Model Card von Gemini 3.1 Pro führt beispielsweise getrennte Ergebnisse für wissenschaftliches Wissen, abstraktes Reasoning, Coding, multimodale Aufgaben, agentische Tool-Nutzung, mehrsprachige Fähigkeiten und Long-Context-Aufgaben auf. Ein Modell kann bei einem dieser Tests vorne liegen und bei einem anderen hinter einem Wettbewerber zurückfallen.

Eine übergreifende Rangliste verdeckt solche Unterschiede zwangsläufig. Welche Fähigkeiten zählen, hängt davon ab, was das Modell später tun soll.

Schon die Sprache kann die Bewertung verändern. Viele etablierte Benchmarks wurden zunächst stark für englischsprachige Aufgaben entwickelt. MMLU-ProX setzt genau dort an und vergleicht anspruchsvolle Fragen über 29 Sprachen hinweg. In der Untersuchung mit 36 Modellen unterscheiden sich die Ergebnisse zwischen den Sprachen teils deutlich. MMLU-ProX behandelt Sprache deshalb ausdrücklich als eigene Evaluationsdimension.

Ein hoher Wert auf einem englischen Benchmark belegt damit noch nicht, wie gut dasselbe Modell mit deutschen Fachtexten, unternehmensinternen Abkürzungen oder typischen Dokumentstrukturen zurechtkommt.

Ein Benchmark soll Unterschiede zwischen Modellen sichtbar machen. Das gelingt, solange seine Aufgaben für die getesteten Systeme ausreichend schwierig sind und schwächere von stärkeren Modellen klar getrennt werden.

Mit steigender Modellleistung kann dieser Abstand schrumpfen. Wenn immer mehr Modelle einen großen Teil der Aufgaben richtig lösen, bleiben nur noch wenige Testfälle übrig, an denen Unterschiede sichtbar werden. Die Aufgaben werden dadurch nicht falsch. Der Benchmark verliert aber an Nutzen für den Vergleich von Spitzenmodellen, weil ihre Ergebnisse immer enger zusammenrücken. Dieser Effekt wird als Benchmark Saturation bezeichnet.

Eine auf der ICML 2026 veröffentlichte systematische Untersuchung analysierte 60 verbreitete LLM-Benchmarks und fand bei fast der Hälfte Anzeichen einer solchen Sättigung. Ältere Benchmarks waren stärker betroffen. Die Autoren definieren Saturation dabei nicht einfach als das Erreichen von 100 Prozent, sondern über die nachlassende Fähigkeit eines Tests, zwischen leistungsfähigen Modellen zuverlässig zu differenzieren. Die Untersuchung betrachtet Benchmark-Sättigung damit als messbares Problem der Trennschärfe.

Saturation ist von anderen Problemen zu unterscheiden. Ein Benchmark kann vollständig sauber sein und trotzdem zu leicht für die aktuelle Modellgeneration werden. Kontamination oder gezielte Optimierung auf einen Test betreffen dagegen andere Teile des Evaluationsprozesses.

Bei Ergebnissen nahe 100 Prozent liegt die Formulierung nahe, ein Modell habe einen Benchmark „geknackt“. Für eine technische Einordnung ist dieser Begriff zu ungenau.

Ein aktuelles Beispiel liefert GPT-6 Astra auf ARC-AGI-3. Bei identischer Reasoning-Stufe „max“ erreicht Astra im standardisierten Harness 62,7 Prozent, mit einem von OpenAI bereitgestellten Provider Adapter 98,6 Prozent. Dieser Adapter kann unter anderem internen Reasoning-Zustand zwischen Aufrufen erhalten und längere Interaktionen kompakt weiterführen. ARC Prize dokumentiert beide Evaluationsvarianten getrennt.

Der Wert von 98,6 Prozent sagt zunächst, dass das System unter genau diesem Evaluationsverfahren nahezu alle Aufgaben des Benchmarks gelöst hat. Ob die zugrunde liegende Fähigkeit damit allgemein gelöst ist, beantwortet der Score nicht. Ebenso wenig lässt sich daraus allein Kontamination oder ein gezieltes „Austricksen“ des Benchmarks ableiten.

Der große Abstand zwischen 62,7 und 98,6 Prozent zeigt zugleich, wie stark die Testbedingungen zum Ergebnis gehören können. Bei komplexeren Evaluationen spielen unter anderem Toolzugriff, Agentenschleifen, gespeicherter Zustand, Reasoning-Budget und die Zahl erlaubter Versuche eine Rolle.

Aktuelle Model Cards dokumentieren solche Bedingungen deshalb zunehmend explizit. Bei Gemini 3.1 Pro wird beispielsweise angegeben, ob Tools verwendet wurden, welcher Harness zum Einsatz kam oder ob nur ein einzelner Versuch erlaubt war. Derselbe Benchmarkname garantiert also noch keine identischen Testbedingungen.

Bei Data Contamination überschneiden sich Trainings- und Evaluationsdaten. Ein Modell könnte dann während des Trainings bereits Aufgaben, Lösungen oder sehr ähnliche Inhalte gesehen haben, die später zur Messung seiner Fähigkeiten verwendet werden.

Bei öffentlich zugänglichen Benchmarks lässt sich das schwer vollständig ausschließen. Eine EMNLP-Übersichtsarbeit von 2025 beschreibt Kontamination deshalb als zunehmendes Problem statischer LLM-Evaluationen und untersucht verschiedene Ansätze, mit denen Tests robuster dagegen gemacht werden können.

SWE-bench zeigt, wie konkret das werden kann. Die Aufgaben basieren auf öffentlichen Open-Source-Repositories. OpenAI berichtete bei seiner Analyse, dass getestete Frontier-Modelle bei einzelnen Aufgaben ursprüngliche menschliche Patches oder spezifische Formulierungen reproduzieren konnten. Das Unternehmen wertete dies als Hinweis darauf, dass zumindest Teile des Materials während des Trainings bekannt geworden sein könnten.

Das ist nicht gleichbedeutend mit simplem Auswendiglernen. Für die Interpretation des Benchmarks reicht bereits die Unsicherheit darüber, ob tatsächlich eine vollständig unbekannte Aufgabe gelöst wurde oder vorhandenes Vorwissen aus dem Testmaterial eine Rolle spielte.

Ein weiteres Problem entsteht, wenn die Aufgabe oder ihre automatische Bewertung nicht zuverlässig feststellt, ob ein Modell richtig gearbeitet hat.

Bei SWE-bench Verified untersuchte OpenAI 138 Aufgaben, an denen ein eigenes Modell auch nach vielen Versuchen häufig scheiterte. In dieser gezielt ausgewählten Teilmenge fand das Unternehmen bei 59,4 Prozent relevante Probleme in Tests oder Aufgabenbeschreibung. Weil gerade besonders auffällige Aufgaben untersucht wurden, lässt sich diese Quote nicht auf den gesamten Benchmark übertragen. Sie zeigt aber, dass ein Fehlschlag nicht zwangsläufig eine Schwäche des Modells belegt.

Eine EMNLP-Arbeit von 2025 beschreibt einen verwandten Effekt. Bei mehreren LLM-Benchmarks wurden semantisch richtige Antworten teilweise als falsch gewertet, weil sie nicht dem erwarteten Ausgabeformat entsprachen. Ein Teil scheinbarer Prompt-Sensitivität entstand dadurch erst im Scoring.

Wer einen Benchmarkwert interpretiert, bewertet deshalb nicht nur das getestete Modell. Auch die Qualität der Aufgaben und des Bewertungsverfahrens gehört zum Ergebnis.

Wenn Modell A in einem Benchmark 87 Prozent erreicht und Modell B 85 Prozent, steht für diesen Test zunächst fest: Modell A hat unter den gewählten Bedingungen besser abgeschnitten. Ob der Abstand von zwei Prozentpunkten einen stabilen Unterschied in der gemessenen Fähigkeit zeigt, ist damit noch nicht geklärt.

Jeder Benchmark arbeitet mit einer begrenzten Auswahl von Aufgaben. Eine andere, aber vergleichbare Stichprobe kann Modelle etwas anders fordern. Bei generativen Systemen kommen weitere Einflüsse hinzu: Wiederholte Durchläufe können unterschiedliche Antworten erzeugen, und auch semantisch ähnliche Promptvarianten können das Verhalten verändern. Eine ACL-2026-Arbeit untersucht diese Prompt-Sensitivität systematisch. Hinzu kommt, dass nicht jedes Bewertungsverfahren Grenzfälle gleich behandelt.

Bei knapp auseinanderliegenden Ergebnissen ist deshalb relevant, ob die Rangfolge unter solchen Variationen bestehen bleibt. Ein stabiler Abstand über viele Aufgaben und wiederholte Evaluationen kann auch dann aussagekräftig sein, wenn er nur wenige Prozentpunkte beträgt. Ein einzelner Score zeigt diese Stabilität jedoch nicht von selbst.

NIST weist bei der statistischen Bewertung von KI-Benchmarks entsprechend darauf hin, dass Mittelwerte ohne Angaben zu Unsicherheit, Messannahmen und Evaluationsdesign nur einen Teil des Ergebnisses beschreiben. Nicht die Größe des Abstands allein entscheidet also darüber, wie belastbar ein Vergleich ist.

Wie stark eine Rangfolge vom konkreten Anwendungsfall abhängen kann, zeigt eine aktuelle Untersuchung zur Relation Extraction. Dabei sollen Beziehungen zwischen Entitäten in Texten erkannt werden, etwa welche Person zu welchem Unternehmen gehört oder welche Organisation mit einem bestimmten Vorgang verbunden ist.

Die Autoren fine-tunten dafür unter anderem ein Qwen2.5-Modell mit nur 0,5 Milliarden Parametern gezielt auf Relation Extraction. Über die untersuchten General-Domain-Datensätze erreichte das Modell einen Micro-F1 von 0,83. Der Micro-F1 fasst vereinfacht zusammen, wie präzise und vollständig die gesuchten Beziehungen erkannt werden; höhere Werte sind besser. GPT-5.4 erreichte im Zero-Shot-Einsatz 0,69, Claude Sonnet 4.6 0,66. Die Ergebnisse stammen aus einem im Juni 2026 veröffentlichten Preprint.

Dass ein Modell mit nur 0,5 Milliarden Parametern bei dieser klar abgegrenzten Aufgabe vor aktuellen Frontier-Modellen liegt, ist bemerkenswert.

Das Qwen-Modell war auf Relation Extraction finegetunt, GPT-5.4 und Claude Sonnet 4.6 wurden zero-shot getestet. Für die untersuchte Aufgabe lag das 0,5B-Modell klar vor beiden Frontier-Modellen.

Viele Aufgaben in Unternehmen sind deutlich enger definiert als die Fähigkeiten, die allgemeine Modellbenchmarks abdecken sollen: bestimmte Informationen aus Dokumenten extrahieren, Texte klassifizieren, definierte Ausgabeformate erzeugen oder mit einer begrenzten Fachdomäne arbeiten. Das allgemein stärkste Modell muss dabei nicht automatisch die beste Leistung liefern.

Öffentliche Benchmarks sind für eine Vorauswahl nützlich. Sie zeigen, welche Modelle bei standardisierten Aufgaben leistungsfähig sind und welche Kandidaten eine nähere Betrachtung verdienen.

Die eigentliche Leistungsfrage eines konkreten Einsatzes ist damit noch offen. Ein allgemeiner Reasoning- oder Coding-Benchmark zeigt nicht, wie zuverlässig ein Modell aus den tatsächlich verwendeten deutschen Fachunterlagen bestimmte Informationen extrahiert, wie es mit ungewöhnlichen Dokumentstrukturen umgeht oder wie stabil es ein gefordertes Ausgabeformat einhält.

Für solche Fragen ist ein überschaubares Set repräsentativer Aufgaben oft aussagekräftiger als ein weiteres allgemeines Leaderboard: reale Dokumenttypen, typische Nutzerfragen, schwierige Grenzfälle und vorher definierte Kriterien dafür, was als richtige oder brauchbare Antwort gilt. Ein großes Evaluationsprojekt ist dafür nicht zwingend erforderlich. Wichtiger ist, dass die Testaufgaben dem späteren Einsatz tatsächlich ähneln.

Zur Modellentscheidung gehören anschließend weitere Faktoren, die ein allgemeiner Capability-Benchmark nicht mitmisst. Antwortzeit, Hardwarebedarf, Kosten, Datenflüsse oder Integrationsanforderungen können im Betrieb relevant werden. Einige dieser Größen lassen sich wiederum separat benchmarken; MLPerf Endpoints misst beispielsweise Durchsatz, Time to First Token und Parallelität.

Auch das NIST AI Risk Management Framework folgt dem Grundgedanken, Messverfahren und Metriken am tatsächlichen Nutzungskontext auszurichten und Eigenschaften separat zu betrachten, die von einer bestehenden Evaluation nicht erfasst werden.

Ein Leaderboard kann damit zeigen, welche Modelle für eine nähere Betrachtung interessant sind. Ob eines davon für einen konkreten Einsatz tatsächlich besser geeignet ist, lässt sich erst mit Aufgaben und Bedingungen beurteilen, die diesem Einsatz möglichst nahekommen.