Öffentliche AI-Benchmarks werden manipuliert – Unternehmen bauen still und leise private Eval-Suites auf
Ein Modell, das diesen Monat die öffentliche Leaderboard-Spitze anführt, kann gegen ein zehn Plätze schlechter platziertes Modell verlieren, sobald man beide gegen den eigenen Produktionsbetrieb testet. Diese Lücke ist kein Randfall mehr – interne Benchmarking-Teams mehrerer Enterprise-AI-Käufer berichten inzwischen von einer Abweichung von rund 37 Prozent zwischen veröffentlichten Benchmark-Scores und der gemessenen Performance auf ihren eigenen agentischen Workloads. Das öffentliche Leaderboard hat aufgehört, ein verlässliches Kaufsignal zu sein – und die Beschaffungsteams wissen das.
Die Folge ist ein stiller Aufbau privater Evaluierungsinfrastruktur. Anstatt MMLU-, HumanEval- oder GPQA-Scores für bare Münze zu nehmen, richten Enterprise-AI-Teams interne Eval-Suites ein, die Modelle gegen eigene Daten, eigene Tools und eigene Fehlermuster testen – und behandeln die öffentlichen Zahlen bestenfalls als groben Vorfilter.
Warum den öffentlichen Zahlen nicht mehr zu trauen ist
Ein Teil des Problems ist Kontamination: Weit verbreitete Benchmarks sind lange genug öffentlich, dass ihre Fragen oder nahe Paraphrasen davon plausibel in Trainingsdaten eingeflossen sind. Doch selbst bei sauber durchgeführten Benchmarks zeigt sich ein subtileres Problem – Messfragilität. Forscher haben nachgewiesen, dass allein das Umordnen der Antwortoptionen bei MMLU-Multiple-Choice-Fragen, ohne auch nur ein einziges Wort des Inhalts zu ändern, die gemessene Genauigkeit eines Modells um bis zu 13 Prozentpunkte verschieben kann. Ein Benchmark, der so empfindlich auf Formatierung reagiert, misst keine echte Fähigkeit – er misst die Robustheit des Modells gegenüber einer spezifischen Antwortschlüssel-Konvention.
Kosten fügen eine zweite Rauschquelle hinzu. Teams, die Modelle ausschließlich nach Genauigkeit vergleichen, haben festgestellt, dass die Inferenzkosten zwischen Modellen, die auf demselben Benchmark innerhalb eines Prozentpunkts voneinander liegen, um das bis zu 50-Fache variieren können. Ein Leaderboard, das rein nach Genauigkeit rankt, verschleiert die Tatsache, dass das zweitbeste Modell möglicherweise zu einem Bruchteil der Kosten läuft – oder dass das führende Modell seinen Score mit einem Inference-Time-Compute-Budget erreicht hat, das kein Produktionssystem in der Praxis einsetzen würde.
Wie eine private Eval-Suite konkret aussieht
Die Teams, die diese Infrastruktur aufbauen, fangen nicht bei null an. Das verfügbare Tooling hat sich schnell weiterentwickelt: OpenAI hat im Juni 2026 Evals 2.0 veröffentlicht, mit erstklassiger Unterstützung für Custom Grader und agentische Multi-Turn-Aufgaben; Inspect AI erreichte im Juli Version 0.3.12 mit verbesserter Unterstützung für Tool-Use-Evaluation und sandboxed Code-Execution-Scoring. Kommerzielle Plattformen – darunter Patronus AI, Braintrust und Galileo – bieten inzwischen verwaltete Private-Eval-Pipelines an, die sich gezielt an Unternehmen richten, die keine Grading-Infrastruktur intern aufbauen wollen.
Eine typische private Suite besteht aus drei Schichten. Erstens ein Golden Dataset, das aus den eigenen historischen Support-Tickets, Code-Review-Kommentaren oder Dokumenten-Workflows des Unternehmens stammt – niemals öffentliche Daten, gerade weil öffentliche Daten das sind, was manipuliert wird. Zweitens aufgabenspezifische Grader: Bei einem Coding-Assistenten bedeutet das etwa, generierten Code tatsächlich gegen eine Test-Suite laufen zu lassen, anstatt ein anderes LLM zu bitten, die Korrektheit per Augenschein zu beurteilen. Drittens ein Regressions-Harness, der die gesamte Suite bei jedem neuen Modell-Release oder Fine-Tune erneut durchläuft, damit ein Modell-Update eines Anbieters die Performance auf den für dieses Unternehmen relevanten Aufgaben nicht still und leise verschlechtern kann.
Das Anreizproblem, das sich damit nicht lösen lässt
Private Evals beheben die Probleme mit Kontamination und Formatierungsempfindlichkeit – aber sie bringen ein neues mit sich: Sie sind teuer aufzubauen und zu pflegen, was bedeutet, dass nur ressourcenstarke Käufer ein genaues Bild der Modellperformance erhalten. Ein Startup, das evaluiert, auf welchem API es aufbauen soll, muss sich nach wie vor auf öffentliche Leaderboards, Twitter-Threads und Anbieter-Marketing verlassen – genau die Signale, die längst unzuverlässig geworden sind. Modellanbieter ihrerseits haben jeden Anreiz, die Optimierung für Benchmarks fortzusetzen, denen kleinere Käufer noch vertrauen – auch wenn ihre besten Enterprise-Kunden diese Zahlen längst nicht mehr beachten.
Was sich dagegen tun lässt
Wer Modelle für einen produktiven Workload evaluiert, sollte das öffentliche Benchmark-Ranking als Shortlist-Filter behandeln – nicht als endgültige Antwort. Es lohnt sich, noch vor der Festlegung auf ein Modell zumindest eine minimale private Eval aufzubauen – 50 bis 100 echte Beispiele aus dem eigenen Use Case, bewertet nach einer Rubrik, auf die sich das Team geeinigt hat – bevor man sich für irgendetwas jenseits von Prototyping festlegt. Neben der Genauigkeit sollte die Cost-per-Task-Kennzahl im Blick behalten werden: Ein Modell, das auf dem eigenen Eval 2 Punkte besser abschneidet, aber 10-mal mehr pro Aufruf kostet, ist selten die richtige Produktionswahl. Und die Eval-Suite sollte erneut durchgeführt werden, wann immer ein Anbieter ein "stilles" Modell-Update liefert – denn die Genauigkeit auf spezifischen Aufgaben kann driften, auch wenn der öffentliche Benchmark-Score unverändert bleibt.