Warum KI-Benchmarks 90 % der echten Arbeit verfehlen

Eine Bekannte von mir leitet die Operations bei einem mittelgroßen Logistikunternehmen, und letzten Frühling hat ihr Team drei Wochen lang geprüft, ob ein LLM ihren Ausnahmeprozess übernehmen kann – die wenig glamouröse Arbeit, Rechnungen abzugleichen, die nicht zu den Bestellungen passen, und das über drei Systeme hinweg, die sich gegenseitig nicht ausstehen können. Die Präsentation des Anbieters war voller beeindruckender Zahlen: MMLU, GSM8K, HumanEval und ein paar agentische Benchmarks. Das Modell hat jeden vorgefertigten Test mit Bravour bestanden. Dann haben sie es auf eine echte Woche voller Ausnahmefälle losgelassen, und es hat selbstsicher eine Rechnung über 14.000 Dollar der falschen Bestellung zugeordnet, weil ein Lieferant seinen eigenen Namen anders abgekürzt hatte. Diese Situation misst keine Bestenliste.

Diese Lücke lässt sich inzwischen messen. Eine aktuelle Zuordnung öffentlicher KI-Benchmarks zur O*NET-Taxonomie des US-Arbeitsministeriums – alle 923 Berufe und 18.797 Tätigkeiten, aus denen die amerikanische Arbeitswelt besteht – kam zu dem Ergebnis, dass 90 % der US-Arbeitsstunden auf Tätigkeiten entfallen, die kaum oder gar nicht durch Benchmarks abgedeckt sind. Nur 208 der 923 Berufe haben mindestens eine Tätigkeit, die von fünf oder mehr Benchmark-Prompts gestützt wird. Sechs der 22 Berufsfamilien haben gar keine. Die unbequeme Schlussfolgerung lautet nicht, dass KI schwach ist. Sondern dass unsere Messinstrumente fast ausschließlich auf den falschen Teil der Wirtschaft gerichtet sind.

Was KI-Benchmarks tatsächlich abdecken

Die Methodik hinter dieser Zuordnung lohnt einen genaueren Blick, denn sie ist sorgfältiger, als die Schlagzeile vermuten lässt. Die Forschenden nahmen 29 hochwertige, nicht gesättigte agentische Benchmarks – Tests, bei denen Modelle tatsächlich Arbeit erledigen müssen, statt nur Fragen zu beantworten – und ließen einen LLM-Judge (gegen menschliche Fachleute validiert) jeden Benchmark-Prompt mit den O*NET-Tätigkeiten taggen, die er abprüft. Eine Tätigkeit gilt als "abgedeckt", wenn ihr mindestens fünf Prompts zugeordnet sind. Kombiniert man das mit Schätzungen, wie viel Arbeitszeit jede Tätigkeit beansprucht, ergibt sich ein gesamtwirtschaftliches Bild dessen, was unsere Evaluationssuite überhaupt sehen kann.

Was sie sieht, ist schmal und hoch, nicht breit. Softwareentwicklung und Finanzanalyse sind mit Benchmarks regelrecht gesättigt. Lkw-Fahren, der Betrieb von Gaskraftwerken, die Gastronomie und der Großteil der täglichen Arbeit im Gesundheitswesen sind praktisch unsichtbar. Und die Schieflage betrifft nicht nur die Frage, welche Tätigkeiten technisch automatisierbar sind. Tätigkeiten, die als "KI-exponiert" markiert sind, werden etwa sechsmal so häufig benchmarkt wie nicht exponierte – was naheliegt –, doch selbst wenn man das herausrechnet, sind Tätigkeiten aus Berufen mit großen Lohnsummen deutlich überrepräsentiert. Die Tätigkeiten von Anwältinnen und Anwälten sind stark abgedeckt. Rechtsanwaltsfachangestellte und Gerichtsschreiber, die einer ähnlichen KI-Exposition ausgesetzt sind, tauchen kaum auf.

Lies das noch einmal: Wir messen KI am prestigeträchtigen Bild eines Berufs und ignorieren die Version, die die meisten Menschen tatsächlich ausüben. Die lange Reihe der wissensintensiven Arbeit im mittleren Einkommensbereich – die Koordinatorinnen, Sachbearbeiter, Fachkräfte und Disponenten, deren Stunden zusammen einen enormen Anteil der Wirtschaft ausmachen – hat so gut wie keine Messinfrastruktur. Wenn jemand behauptet, KI könne einen bestimmten Prozentsatz der "Wissensarbeit" erledigen, frag nach: welche Wissensarbeit, gemessen wie und an welcher Aufgabenliste? Die ehrliche Antwort lautet meist: eine dünne, unrepräsentative Scheibe, gemessen mit Tests, die für Forschungsarbeiten entworfen wurden.

Benchmark-Sättigung ist ein Designfehler der Evaluation

Ich habe jahrelang Evaluationspipelines gebaut, und die härteste Lektion war diese: Ein Benchmark ist ein Modell der Welt, und die meisten Benchmarks sind schlechte Modelle. Sie pressen eine unordentliche, kontextabhängige, mehrstufige menschliche Tätigkeit in einen sauberen Prompt mit einer prüfbaren Antwort, weil sich das billig bewerten lässt. Dann erledigt das Goodhart-Gesetz den Rest. Sobald ein Benchmark zum Ziel der Modellentwicklung wird, misst er nicht mehr die Fähigkeit, die er eigentlich abbilden sollte. Trainingsdaten saugen die Testverteilung auf, Teams optimieren gegen die Bestenliste, und die Werte steigen, während die Leistung in der Praxis seitwärts driftet.

Sättigung ist das sichtbare Symptom. Wenn jedes Spitzenmodell bei einem Test über 90 % erreicht, hat der Test aufgehört zu trennen – das eigentliche Problem liegt aber tiefer: Wir reagieren, indem wir einen weiteren Benchmark im selben Stil bauen, der dieselben Arten von Aufgaben abdeckt, weil wir wissen, wie man diese automatisch bewertet. Multiple-Choice-Fragen erzeugen schwierigere Multiple-Choice-Fragen. Programmieraufgaben erzeugen schwierigere Programmieraufgaben. Niemand baut unterdessen den Benchmark für "Bemerke, dass die Schadloshaltungsklausel dieses Vertrags stillschweigend dem Term Sheet vom März widerspricht", weil die Bewertung dafür eine Juristin, Zeit und Ermessensentscheidungen braucht, die sich der Automatisierung entziehen.

Deshalb widerspreche ich der Deutung, Benchmark-Sättigung bedeute, dass KI einen Bereich "gelöst" hat. Sättigung heißt schlicht, dass das Messinstrument am Anschlag ist. Ein Thermometer, das bei 40 °C stehen bleibt, beweist nicht, dass der Raum 40 Grad hat; es beweist, dass du ein anderes Thermometer brauchst. Wenn du Modelle für den Produktiveinsatz evaluierst – und besonders, wenn du LLM-basierte Entscheidungssysteme baust, bei denen Fehler echte Kosten verursachen –, sollten Abstände in der Bestenliste auf gesättigten Benchmarks bei deiner Entscheidung praktisch kein Gewicht haben.

Wir wissen ganz genau, wie gut Modelle bei der Arbeit sind, die wir zu messen beschlossen haben. Über die anderen neunzig Prozent wissen wir fast nichts.

Der Laterneneffekt in der KI-Evaluation

Es gibt einen alten Witz über einen Betrunkenen, der seine Schlüssel unter einer Straßenlaterne sucht – nicht, weil er sie dort verloren hat, sondern weil dort das Licht ist. Der Bau von Benchmarks folgt derselben Logik, und die Daten bestätigen, dass das kein Zufall ist. Die Zuordnungsstudie zeigt, dass die Wichtigkeit einer Tätigkeit innerhalb eines Berufs die Abdeckung vorhersagt: O*NET-Tätigkeiten, die als am wichtigsten für ihren Beruf eingestuft sind, werden sechs- bis zehnmal häufiger benchmarkt als die unwichtigsten. Auf den ersten Blick klingt das nach vernünftiger Priorisierung. In der Praxis heißt es, dass wir die Vorzeigetätigkeiten messen und das verbindende Gewebe auslassen.

Jeder Beruf besteht hauptsächlich aus diesem verbindenden Gewebe. Die benchmarkte Tätigkeit einer Softwareentwicklerin lautet "implementiere eine Funktion, die diese Tests besteht". Ihr tatsächlicher Arbeitstag umfasst das Lesen einer halbfertigen Migration eines Kollegen, das Herausfinden, welcher Stakeholder über eine Entscheidung wirklich bestimmt, und das Erkennen, dass das Ticket das falsche Problem beschreibt. Ich habe schon früher geschrieben, dass agentische Coding-Werkzeuge genau an diesem Punkt gelingen oder scheitern: Schleife, Kontext und Berechtigungsgrenzen sind wichtiger als die reine Generierungsqualität. All das taucht in keinem HumanEval-artigen Wert auf.

Außerdem gibt es ein subtiles Definitionsproblem in den Abdeckungszahlen selbst. "Abgedeckt" bedeutet, dass fünf oder mehr Prompts einer Tätigkeit zugeordnet sind – nicht, dass fünf Prompts die Tätigkeit erfassen. Dreizehn Prompts zur Beratung von Eltern bei Erziehungsproblemen bilden nicht ab, was eine Sozialarbeiterin über ihre Fallzahl, im Gerichtssaal und beim Hausbesuch am Küchentisch tatsächlich tut. Legte man die Alltagsdefinition von "gut abgedeckt" an,läge der gemessene Anteil der Wirtschaft nicht bei 10 %. Er wäre praktisch null. Der Laternenkegel ist nicht nur eng; das Licht, das er wirft, ist dünn.

Modelle erzeugen, aber niemand misst Urteilsvermögen

Hier ist die Asymmetrie, die ich am vernichtendsten finde. Fast jeder Benchmark, den es gibt, testet Produktion: Schreib den Code, entwirf das Memo, löse das Problem. Doch die wirtschaftlich entscheidende Hälfte der meisten echten Aufgaben ist die Erkennung – den Fehler finden, die Inkonsistenz markieren, wissen, wann die selbstsichere Antwort falsch ist. Der Wert einer Buchhalterin im Einstieg liegt nicht darin, eine Abstimmung zu erstellen, sondern darin zu merken, dass eine Zahl komisch riecht. Benchmarks testen das kaum, weil eine bewertbare Fehlererkennungsaufgabe viel schwerer zu bauen ist als eine bewertbare Generierungsaufgabe. Du brauchst realistische fehlerhafte Artefakte, plausibel-falsche Feinheiten und menschliche Übereinstimmung darüber, was als erkannt gilt.

Das ist der Türsteher-Fehlschluss, angewandt auf das Evaluationsdesign. Ersetzt man einen Türsteher durch eine automatische Tür, merkt man zu spät, dass der Türsteher auch Mieter begrüßt, Pakete annahm und die Straße im Blick behielt. Automatisiert man den benchmarkten Teil eines Jobs, stellt man fest, dass die unbenchmarkten Teile tragend waren. Das Modell meiner Logistikbekannten konnte ausgezeichnete Abstimmungsnotizen entwerfen – die sichtbare Aufgabe –, während es still den Abgleich vermasselte, also genau das Urteilsvermögen, das die Notizen erst wertvoll machte. Die Evaluationssuite bewertete die Beilage und ignorierte das Hauptgericht.

Solange Fehlererkennung keine erstklassige Benchmark-Behandlung bekommt, ist mit einer hartnäckigen Lücke zwischen Demo-Leistung und Produktionsleistung zu rechnen. Es ist dieselbe Lücke, die zwischen dem, was eine Spezifikation sagt, und dem, was die Implementierung tut, klafft – und wie in der Software wachsen dort die Fehler. Ein Modell, das auf dem 90. Perzentil generiert und auf dem 30. prüft, ist im Produktivbetrieb ein Mitarbeiter im 30. Perzentil mit einem Tippvorteil.

Evals nach der realen Aufgabenverteilung gewichten

Die praktischste Idee aus der Benchmark-Zuordnung ist zugleich die einfachste: Wenn Benchmarks manche Tätigkeiten überrepräsentieren, hör auf, über Prompts zu mitteln, und mittle über Tätigkeiten, gewichtet nach der Arbeitszeit, die sie tatsächlich beanspruchen. Ein naiver Durchschnitt aller Prompts mit dem Tag "Finanzanalyst" wird von der Tätigkeit dominiert, die zufällig die meisten Benchmark-Prompts hat – meist diejenige, für die sich am leichtesten ein Datensatz bauen ließ. Ein nach O*NET gewichteter Durchschnitt gibt jeder echten Tätigkeit dasselbe Gewicht. Der Unterschied kann dramatisch sein.

import pandas as pd
# The tasks an occupation actually performs, with time shares
# (from O*NET, your own ticket logs, or time-tracking data)
tasks = pd.DataFrame({
"task": ["draft contract", "advise client", "review filing", "coordinate closing"],
"time_share": [0.30, 0.25, 0.35, 0.10],
})
# Model results: one row per eval prompt, mapped to the task it exercises
results = pd.DataFrame({
"prompt_id": ["p1", "p2", "p3", "p4", "p5"],
"task": ["draft contract", "draft contract", "draft contract",
"review filing", "coordinate closing"],
"score": [0.92, 0.88, 0.95, 0.61, 0.40],
})
# Naive: flat average over prompts. Drafting has 3 of 5 prompts,
# so the score is dominated by the model's best task.
naive = results["score"].mean()  # 0.752
# Task-weighted: average within each task first, then weight by
# the share of working hours that task consumes.
per_task = results.groupby("task")["score"].mean()
weights = tasks.set_index("task")["time_share"]
weighted = (per_task * weights).sum() / weights[per_task.index].sum()
# 0.30*0.917 + 0.35*0.61 + 0.10*0.40, over covered time (0.75) = 0.705
# vs naive 0.752 — and 'advise client' (25% of the job) has no data at all

Zwei Dinge fallen in diesem Snippet auf. Erstens sinkt der gewichtete Wert, weil die schwächsten Tätigkeiten des Modells im Prompt-Pool unterrepräsentiert waren – genau die Verzerrung, die ein flacher Durchschnitt verbirgt. Zweitens, und wichtiger: "Kunden beraten" verschwindet aus der Berechnung vollständig, weil kein Prompt darauf abgebildet ist. Jedes Gewichtungsschema lässt Tätigkeiten ohne Abdeckung stillschweigend weg, und fehlende Abdeckung ist für den Großteil der Wirtschaft der Normalfall. Gewichtung löst das Gewichtungsproblem, aber nicht das Problem fehlender Daten. Dafür braucht es neue Evals, nicht erneutes Mitteln alter.

Wie du KI an deiner tatsächlichen Arbeit misst

Wenn du Modelle auswählst oder einsetzt, hat die gesamtwirtschaftliche Abdeckungslücke eine konkrete Konsequenz: Öffentliche Benchmarks sind ein schwacher Anhaltspunkt für deinen Anwendungsfall, es sei denn, du befindest dich zufällig in der kleinen, hellen Ecke, die sie messen. Also baue deine eigene Ecke. Das klingt weniger heldenhaft, als es ist, und schlägt das Vertrauen in eine Anbieterpräsentation um Längen.

• Aufgaben aus Logs ziehen, nicht aus der Fantasie. Zieh eine echte Woche an Tickets, E-Mails oder Ausnahmefällen und sample nach Häufigkeit. Dein Eval-Set sollte dem Histogramm deiner Arbeitslast entsprechen, einschließlich des langweiligen Endes – das langweilige Ende ist den Großteil der Arbeit.
• Nach Zeit oder Kosten gewichten und beide Werte berichten. Ein flacher und ein gewichteter Durchschnitt grenzen die Wahrheit ein. Gewinnt ein Modell den flachen, verliert aber den gewichteten Durchschnitt, ist es gut bei den Aufgaben, die sich leicht testen lassen – genau der Fehlermodus, auf den du prüfen willst.
• Prüfaufgaben einbauen. Nimm echte Ergebnisse – auch bekannt fehlerhafte – und bewerte, ob das Modell eingeschleuste und natürliche Fehler findet. Erkennungs- und Generierungsfähigkeit korrelieren nach meiner Erfahrung kaum, und die Erkennung ist das, was du tatsächlich einkaufst.
• Ein privates Set zurückhalten und regelmäßig erneuern. Jedes Eval, das du monatelang wiederverwendest, wird zum Trainingsziel, auch unbeabsichtigt, sobald jemand Prompts daran optimiert. Rotiere die Fälle quartalsweise.
• Ende-zu-Ende-Ergebnisse bewerten, wo möglich. Lautet die Aufgabe "gleiche diese Rechnung ab", bewerte den Abgleich, nicht die Zwischenprosa. Zwischenmetriken schmeicheln Modellen so, wie Unit-Tests ohne Integrationsabdeckung Code schönreden.

Zum Schluss ein leiserer Effekt, den jeder erkennt, der KI-Coding-Werkzeuge täglich nutzt: die Baumolsche Kostenkrankheit im Kleinen. Wird das Generieren zwanzigmal schneller, verbringst du deinen Tag nicht mit Generieren. Du verbringst ihn mit den Teilen, die nicht schneller geworden sind – Prüfen, Koordinieren, Verifizieren, Entscheiden. Der unbenchmarkte Rest schrumpft nicht, wenn KI besser wird; er wächst und füllt die gewonnene Zeit, und er wird zu einem größeren Anteil dessen, was darüber entscheidet, ob sich der KI-Einsatz gelohnt hat. Den automatisierbaren Teil mit immer größerer Präzision zu messen, während der Rest ignoriert wird, ist nicht nur unvollständig. Es kehrt um, was wirklich zählt.

Nichts davon ist ein Argument dafür, dass der KI-Fortschritt Fake ist – die Fähigkeitsgewinne sind real, und ich habe ganze Projekte darauf gesetzt. Es ist ein Argument dafür, dass unsere Messkultur auf die falsche Verteilung ausgerichtet ist. Benchmarks sind dort entstanden, wo Prompts günstig zu schreiben und zu bewerten waren: Code, Mathe, prüfungsartiges Faktenwissen. Die Wirtschaft ist größtenteils nicht so. Solange die Evaluation nicht aufholt, behandle jede Schlagzeile über Fähigkeiten als Aussage über das helle Zehntel der Landkarte und baue die Evals, die deine eigenen dunklen neunzig Prozent abdecken. Die Organisationen, die diese langweilige, wenig glamouröse Messarbeit leisten, werden bessere Einsatzentscheidungen treffen als alle, die Bestenlisten aktualisieren – und der Abstand wird nicht gering sein.