Benchmarke AI-Modelle anhand der Arbeit, die du ausliefern möchtest – nicht anhand einer Rangliste, die für die Aufgabe anderer erstellt wurde. Ein öffentlicher Benchmark kann einen starken Kandidaten identifizieren. Er kann dir jedoch nicht sagen, ob dieses Modell deinen Workflow zuverlässig abschließt.
Zielgruppe: Fortgeschrittene Einsteiger – Entwickler, Produktteams und technische Einkäufer, die ein Modell für eine echte Anwendung auswählen.
Um AI-Modelle für echte Arbeit zu benchmarken, gib jedem Kandidaten dieselben repräsentativen Aufgaben, bewerte den resultierenden Zustand statt der Formulierung, wiederhole jede Aufgabe, erfasse Latenz und Kosten und lege eine Rollout-Schranke für Fehler fest, die du nicht akzeptieren kannst. Das beste Modell ist die günstigste Option, die diese Schranken konsistent erfüllt. Es ist nicht unbedingt das Modell mit dem höchsten Durchschnittswert.
Welche Frage sollte ein Benchmark für ein AI-Modell beantworten?
Ein nützlicher Benchmark sollte eine operative Frage beantworten:
Dieser Satz bringt sechs Details ans Licht:
Öffentliche Benchmarks verwenden normalerweise eine andere Kombination dieser Variablen. Model Cards und Release Notes sind dennoch hilfreich: Sie grenzen die Kandidatenliste ein und zeigen unterstützte Modalitäten, Kontextgrenzen, Preise und bekanntes Sicherheitsverhalten. Veröffentlichungen vom Juli 2026 veranschaulichen den Unterschied. OpenAI veröffentlichte umfassende Ergebnisse zu Fähigkeiten und Sicherheit für GPT-5.6, während Google eine geringere Token-Nutzung und einen niedrigeren Preis für Gemini 3.6 Flash im Vergleich zu seinem vorherigen Flash-Modell dokumentierte. Das sind nützliche Ausgangshypothesen, aber keine Messungen deines Prompts, deiner Tools, deiner Daten oder deines Fehlerbudgets. (OpenAI, Google)
Die NVIDIA NIM free AI API-Fallstudie→ zeigt, wie ein Übersetzungsworkflow die Modellauswahl in messbaren Durchsatz und messbare Konsistenz verwandeln kann. Für Coding-Kandidaten beginne mit dem fokussierten Vergleich kostenloser AI-Coding-Agents→. Danach solltest du die Entscheidung in deinen eigenen Testsatz verlagern.
Warum ein einzelner Durchschnittswert Produktionsrisiken verbirgt
Drei aktuelle Benchmarks zeigen dasselbe Problem aus unterschiedlichen Bereichen.
Teilpunkte können einen End-to-End-Fehler verbergen
APEX-Accounting bewertet Modelle anhand von 160 Buchhaltungsaufgaben für zehn synthetische Unternehmen und verwendet Tabellen, PDFs und andere Dateien. Buchhaltungsexperten verfassten die Aufgaben und Erfolgskriterien. Die Forschenden führten neun Frontier-Modelle achtmal pro Aufgabe aus und erzeugten 11.520 Trajektorien.
Das stärkste Modell erreichte 56,4 % bei der Teilpunkte-Metrik des Papers, Mean Criteria@3. Dennoch überschritt kein Modell 2,6 % bei Pass^8, womit geprüft wird, ob alle acht Versuche einer Aufgabe erfolgreich waren. Der beste Wert für Pass@8, womit geprüft wird, ob mindestens einer von acht Versuchen erfolgreich war, lag bei 21,5 %. Bei 93 der 160 Aufgaben erzielte kein getestetes Modell in keinem Durchlauf eine perfekte Fertigstellung. (APEX-Accounting)
Die Autoren maßen abgeschlossene Buchhaltungsaufgaben in einer kontrollierten synthetischen Umgebung. Steuer-, Prüfungs-, Konsolidierungs-, Multi-Entity- oder Multi-Currency-Arbeit sowie externe Berichterstattung wurden nicht abgedeckt. Der Aufgabensatz wurde außerdem mithilfe von drei Frontier-Modellen nach Schwierigkeit gefiltert, was die Werte senken oder bestimmte Modellfamilien begünstigen kann. Die praktische Schlussfolgerung ist enger als „AI kann keine Buchhaltung“: Ein Modell kann viele einzelne Prüfungen erfüllen und dennoch zu inkonsistent für einen unbeaufsichtigten, mehrstufigen Workflow sein.
Eine gültige Ausgabe kann die Einschränkung des Nutzers trotzdem verfehlen
TREK testet Reiseplanungs-Agents anhand von 800 Aufgaben gegen eine synthetische Wissensbasis mit 212.530 Datensätzen. Der Evaluator prüft Regeln und den finalen Zustand deterministisch, statt ein anderes Sprachmodell um die Bewertung des Plans zu bitten.
Der stärkste getestete Agent schloss 46,2 % der machbaren Aufgaben perfekt ab. Bei 94,9 % war er frei von Halluzinationen und bei 86,3 % ausführbar, erfüllte jedoch nur bei 50,7 % alle Nutzereinschränkungen. Das System konnte plausible, buchbare Pläne erstellen und dennoch eine implizite Präferenz oder eine schrittübergreifende Anforderung übersehen. (TREK)
TREK verwendet eine synthetische Reisewelt, schließt Live-Preise und Verfügbarkeit aus und berichtet einen Durchlauf pro Agent. Der Vergleich des Reasonings ist eine Beobachtung aus einem einzelnen Paar über verschiedene Versionen hinweg und keine kontrollierte, abgestimmte Ablation. Dennoch zeigt er eine dauerhafte Evaluationsregel: Prüfe den finalen Zustand und jede bindende Einschränkung. Sprachliche Flüssigkeit ist keine Aufgabenerfüllung.
Der Benchmark selbst kann fehlerhaft sein
Ein OpenAI-Audit des öffentlichen 731-Aufgaben-Splits von SWE-Bench Pro fand eine zweite Quelle falscher Zuversicht: fehlerhafte Evaluationsdaten. Eine automatisierte Pipeline markierte 27,4 % der Aufgaben als fehlerhaft, während ein Annotationsprozess mit fünf Ingenieuren 34,1 % markierte. Zu den Problemen gehörten unzureichend spezifizierte Prompts, übermäßig strenge Tests und Tests, die unvollständige Lösungen bestehen ließen. OpenAI schätzte, dass ungefähr 30 % des Benchmarks fehlerhaft waren, und nahm seine frühere Empfehlung zur Nutzung zurück. (OpenAI-Benchmark-Audit)
Ein schwieriger Test ist nur dann nützlich, wenn ein bekanntermaßen korrektes Referenzergebnis ihn besteht und ein falsches Ergebnis ihn aus dem richtigen Grund nicht besteht.
Wie man AI-Modelle in sieben Schritten benchmarked
1. Definiere die Entscheidung vor dem Test
Schreibe die Produktionsentscheidung in einer Zeile auf:
Passe die Zahlen an dein Produkt an. Behalte die Struktur bei. Ein Benchmark ohne Entscheidungsregel lädt dazu ein, nach Eintreffen der Ergebnisse selektiv passende Ergebnisse herauszugreifen.
Trenne harte Schranken von Optimierungsmetriken:
Ein Modell, das eine harte Schranke verletzt, verliert – selbst wenn sein Durchschnittswert höher ist.
2. Erstelle Aufgaben aus der Arbeit, nicht aus einer Demo
Beginne mit echten, de-identifizierten Beispielen, sofern du sie verwenden darfst. Ergänze synthetische Fälle, um seltene Fehler abzudecken, aber lass synthetische Prompts nicht die Verteilung ersetzen, die Nutzer erzeugen.
Eine praktische erste Testsuite kann 30 bis 50 Aufgaben enthalten:
Diese Prozentsätze sind eine Ausgangsvorlage, kein statistischer Standard. Systeme mit hohen Auswirkungen benötigen eine breitere Abdeckung und eine fachliche Prüfung. Halte einen separaten Holdout-Satz zurück, damit Prompt-Tuning den Benchmark nicht unbemerkt überanpasst.
Kennzeichne jede Aufgabe nach Sprache, Eingabetyp, Risiko, Schwierigkeit und erwarteten Verhalten. Aggregierte Werte können sich verbessern, während ein wichtiger Teilbereich schlechter wird.
3. Spezifizieren Sie beobachtbare Ergebnisse
Bewerte nach Möglichkeit das Artefakt oder den Systemzustand:
Anthropics Evaluationsleitfaden unterscheidet ebenfalls zwischen Transkript und Ergebnis: Ein Agent kann sagen, dass ein Flug gebucht wurde, aber entscheidend ist, ob die Reservierung in der Datenbank existiert. Der Leitfaden empfiehlt nach Möglichkeit deterministische Grader, bei Bedarf modellbasierte Grader und zur Kalibrierung eine menschliche Prüfung. (Anthropic)
Verwende Teilpunkte zur Diagnose eines Fehlers, nicht zur Freigabe eines Deployments. Eine Rate perfekter Aufgaben zeigt, wie oft der gesamte Job abgeschlossen wurde. Die Kriterienabdeckung zeigt, welche Anforderung normalerweise scheitert.
4. Fixiere die Testbedingungen
Erfasse für jeden Durchlauf die vollständige Konfiguration:
Vergleiche kein Modell mit einem optimierten Prompt und ein anderes mit einem generischen Prompt, außer die Frage lautet ausdrücklich: „Welches vollständige System sollten wir deployen?“ Ein Modell-Benchmark und ein System-Benchmark beantworten unterschiedliche Fragen.
Provider-APIs ändern sich. Googles aktueller Modellleitfaden besagt beispielsweise, dass Gemini 3.6 Flash veraltete Sampling-Parameter ignoriert und sie in künftigen Generationen ablehnen wird. Eine reproduzierbare Aufzeichnung verhindert, dass eine stille Konfigurationsänderung wie Model Drift aussieht. (Google-Modellleitfaden)
5. Führe gepaarte, wiederholte Durchläufe aus
Führe jeden Kandidaten mit denselben Aufgaben-IDs aus. Gepaarte Vergleiche reduzieren das Rauschen durch Unterschiede im Schwierigkeitsgrad der Tests.
Ein Durchlauf misst eine Anekdote. Wiederholte Durchläufe machen Varianz sichtbar:
Drei Wiederholungen pro Aufgabe liefern eine kostengünstige erste Sicht auf Instabilität. Fünf bis acht Wiederholungen ergeben ein klareres Bild für Workflows mit hoher Varianz oder hohem Risiko. Dies sind pragmatische Ausgangspunkte, keine universellen Regeln für die Stichprobengröße. Erhöhe die Anzahl der Wiederholungen, wenn die Werte der Kandidaten nahe beieinanderliegen oder die Folgen des Deployments groß sind.
*Führe jeden Kandidaten durch dieselben Aufgaben und wiederholten Tests. Vergleiche Ergebnisse, Konsistenz, Latenz und Kosten vor einem kontrollierten Rollout.*
6. Untersuche Fehler, nicht nur Summen
Speichere für jeden fehlgeschlagenen Versuch:
Nützliche Fehlerbezeichnungen sind fehlende Einschränkung, falsches Tool, ungültiges Argument, Retrieval-Fehler, erfundene Tatsache, vorzeitiger Abschluss, unsichere Aktion, Timeout und Grader-Fehler.
Lies auch eine Stichprobe der erfolgreichen Durchläufe. Ein zu lockerer Grader kann einen Shortcut belohnen, der später scheitert. Ein zu strenger Grader kann eine gültige Alternative ablehnen. Wenn Fehler nicht fair wirken, repariere die Aufgabe, bevor du Modelle vergleichst.
Auch hier kann eine enge Evaluation hilfreich sein. Wenn Retrieval die schwache Phase ist, teste sie separat mit einem RAG-Evaluationsworkflow→. Wenn ein Konfidenzsignal die Eskalation steuert, kalibriere den LLM-Konfidenzwert→ anhand gelabelter Ergebnisse, statt ihn als Wahrheit zu behandeln.
7. Wende eine Rollout-Schranke an
Wähle das Modell erst, nachdem es die vorab festgelegte Regel erfüllt. Leite anschließend einen kleinen, reversiblen Anteil des Traffics durch die ausgewählte Konfiguration.
Überwache in der Produktion dieselben Ergebnismetriken. Füge neu beobachtete Fehler einer Regressionssuite hinzu. Halte Fähigkeitstests, die anspruchsvoll bleiben sollten, getrennt von Regressionstests, die für bereits unterstütztes Verhalten nahe 100 % bleiben sollten.
Ein lokaler Benchmark reduziert Unsicherheit. Er beseitigt jedoch weder Distribution Shift, Anbieteränderungen, neuartiges Nutzerverhalten noch Fehler des Evaluators.
Eine Scorecard, die echte Arbeit abbildet
| Metrik | Berechnung | Warum sie wichtig ist |
|---|---|---|
| --- | --- | --- |
| Rate perfekter Aufgaben | Aufgaben, bei denen jede erforderliche Prüfung bestanden wurde / alle Aufgaben | Misst die End-to-End-Fertigstellung |
| Kriterienabdeckung | Bestandene Prüfungen / alle Prüfungen | Lokalisiert Teilfehler |
| Erfolg beim ersten Versuch | Beim ersten Versuch bestandene Aufgaben / alle Aufgaben | Erfasst die Nutzererfahrung ohne Wiederholungen |
| Pass@k | Aufgaben mit mindestens einem Erfolg in k Versuchen / alle Aufgaben | Passt zu Suche oder Generierung, wenn Alternativen erlaubt sind |
| Pass^k | Aufgaben, bei denen alle k Versuche erfolgreich sind / alle Aufgaben | Macht Konsistenzrisiken sichtbar |
| Kosten pro erfolgreicher Aufgabe | Gesamtkosten für Modell und Tools / abgeschlossene Aufgaben | Verhindert, dass ein günstiges, aber fehleranfälliges Modell effizient wirkt |
| p50- und p95-Latenz | Median und Randlatenz der Abschlusszeit | Zeigt sowohl normale Geschwindigkeit als auch die Belastung langsamer Nutzer |
| Verletzungen harter Schranken | Anzahl nach Sicherheits- oder Richtlinienregel | Blockiert nicht akzeptables Verhalten |
Fasse nicht zu früh alle Metriken in einer einzigen gewichteten Zahl zusammen. Ein einzelner Wert kann einen Sicherheitsfehler hinter niedrigeren Kosten oder besserem Stil verbergen.
Ein reproduzierbares Startformat
Speichere Aufgaben in einer versionierten JSONL-Datei. Halte private oder personenbezogene Daten aus dem Repository heraus.
{"id":"refund-001","input":{"request":"Refund duplicate €42 charge","account_state":"two matching settled charges"},"expected":{"action":"refund","amount_cents":4200,"count":1},"tags":["billing","happy-path"]} {"id":"refund-002","input":{"request":"Refund my last charge","account_state":"no settled charge"},"expected":{"action":"clarify","must_not":["create_refund"]},"tags":["billing","abstain"]} {"id":"refund-003","input":{"request":"Refund both charges","account_state":"one settled charge, one pending"},"expected":{"action":"clarify","must_not":["refund_pending"]},"tags":["billing","edge-case","high-risk"]}
Der Grader sollte das Ergebnis prüfen und nicht nach überzeugenden Formulierungen suchen:
ts type Expected = { action: "refund" | "clarify"; amount_cents?: number; count?: number; must_not?: string[]; };
type ToolState = { action: "refund" | "clarify"; refunded_cents?: number; refund_count?: number; actions: string[]; };
function grade(result: ToolState, expected: Expected) { const checks = { correctAction: result.action === expected.action, correctAmount: expected.amount_cents === undefined || result.refunded_cents === expected.amount_cents, correctCount: expected.count === undefined || result.refund_count === expected.count, forbiddenActionAbsent: (expected.must_not ?? []).every( (action) => !result.actions.includes(action), ), };
return { passed: Object.values(checks).every(Boolean), checks, }; }
Bevor du der Aufgabe vertraust, führe eine Referenzlösung und eine absichtlich falsche Lösung durch den Grader. Die Referenz muss bestehen. Das falsche Ergebnis muss aus dem erwarteten Grund scheitern.
Wann solltest du einen LLM-Judge verwenden?
Verwende deterministische Prüfungen für Zustand, Schema, Berechnungen, Zitate, erforderliche Felder und verbotene Aktionen. Sie sind günstig, reproduzierbar und leicht zu debuggen.
Verwende einen rubric-basierten menschlichen oder LLM-Grader, wenn sich Qualität nicht auf exakte Prüfungen reduzieren lässt: Ton, Vollständigkeit, Qualität der Argumentation oder die Frage, ob eine Zusammenfassung die wichtige Nuance bewahrt. Halte die Rubrik spezifisch. Füge Beispiele für akzeptable Alternativen und ausschließende Fehler hinzu.
Kalibriere einen LLM-Judge anhand von Expertenlabels, bevor du ihn im großen Maßstab einsetzt. APEX-Accounting tat dies ausdrücklich: Der Judge wurde anhand von 1.687 menschlichen Labels geprüft und erreichte in dieser Studie einen F1-Wert von 0,970. Das validiert den Judge für die Kriterien und Daten des Papers; es macht denselben Judge nicht universell zuverlässig. (APEX-Accounting)
Wenn ein kanonischer Benchmark teuer ist, kann adaptives Sampling die Evaluationskosten senken. BayesAME wählt Elemente anhand der historischen Leistung eines Referenzmodells aus und berichtet über mehrere akademische Benchmarks hinweg bessere Genauigkeits-Kosten-Abwägungen als mehrere Baselines. Die aktuelle Methode setzt skalare Werte und nützliche historische Signale pro Element voraus. Für eine kleine, maßgeschneiderte Suite, bei der ein vollständiger Durchlauf bezahlbar ist, bleibt die Ausführung jeder Aufgabe einfacher und leichter zu auditieren. (BayesAME)
Open-Source-Tools können das Harness bereitstellen, ohne deine Produktanforderungen zu definieren. Inspect AI unterstützt Aufgabenausführung, Scoring, Logs und Wiederholungen. LM Evaluation Harness bietet eine umfangreiche Sammlung akademischer Aufgaben und Model-Backends. Verwende sie, wenn sie passen. Eine versionierte JSONL-Datei plus produktspezifische Grader reicht für den ersten nützlichen Benchmark oft aus.
Häufige Fehler beim Benchmarking
Nur den Happy Path testen
Ein Modell kann lernen zu handeln, aber nie lernen, wann es aufhören soll. Füge passende Fälle hinzu, in denen es handeln, nachfragen, sich enthalten oder ablehnen sollte.
Die Erklärung statt des Ergebnisses bewerten
Selbstbewusste Prosa kann eine Aktion beschreiben, die nie stattgefunden hat. Prüfe die Datenbank, Datei, API-Antwort oder das Testergebnis.
Mehrere Variablen gleichzeitig ändern
Wenn du Modell, Prompt, Retrieval-System und Tools gemeinsam änderst, kannst du vollständige Systeme vergleichen, aber den Unterschied nicht dem Modell zuschreiben.
Auf dem Testsatz tunen
Verschiebe fehlgeschlagene Beispiele während der Iteration in einen Entwicklungssatz. Bestätige die Änderung vor dem Rollout mit unberührten Holdout-Aufgaben.
Durch Fehler verursachte Kosten ignorieren
Der Preis pro Token umfasst keine Wiederholungen, menschliche Prüfung, Tool-Aufrufe oder die Behebung einer fehlerhaften Aktion. Miss die Kosten pro erfolgreicher Aufgabe.
Einen neuen Benchmark als dauerhafte Wahrheit behandeln
Kontamination von Aufgaben, Sättigung, fehlerhafte Grader und Fähigkeitsverschiebungen können das Signal auslöschen. Halte die Benchmark-Version fest und prüfe erneut, ob seine Fehler weiterhin fair wirken.
Prüfung der Aussagen
| Wichtige Aussage | Beleg | Grenze oder Unsicherheit |
|---|---|---|
| --- | --- | --- |
| Teilpunktwerte können mit schlechter End-to-End-Konsistenz einhergehen | APEX-Accounting: 56,4 % Mean Criteria@3 für das führende Modell; kein Modell über 2,6 % Pass^8 | Synthetische abgeschlossene Buchhaltungsaufgaben; die Filterung schwieriger Aufgaben kann die Werte beeinflussen |
| Plausibel wirkende Pläne können bindende Einschränkungen verfehlen | TREK: stärkster Agent mit 46,2 % perfekten Aufgaben und 50,7 % Erfüllung trotz höherer Ausführbarkeit und Halluzinationsfreiheit | Synthetische Reisewelt; ein Versuch pro Agent |
| Benchmark-Fehler können Fähigkeitsschätzungen erheblich verzerren | OpenAI-Audit: Automatisierte Prüfung markierte 27,4 % und menschliche Prüfung 34,1 % der öffentlichen SWE-Bench-Pro-Aufgaben als fehlerhaft | Ein Coding-Benchmark und eine Audit-Methodik |
| Deterministische Ergebnisprüfungen sollten bevorzugt werden, wenn sie verfügbar sind | Anthropics Evaluationsleitfaden und der deterministische TREK-Evaluator | Subjektive Qualität erfordert weiterhin kalibrierte menschliche oder modellbasierte Beurteilung |
| Adaptive Elementauswahl kann die Kosten großer Benchmarks senken | BayesAME berichtet über mehrere akademische Benchmarks hinweg eine bessere Abwägung zwischen Schätzgenauigkeit und Kosten | Hängt von historischen Referenzsignalen und skalaren Werten ab |
Häufig gestellte Fragen
Wie viele Beispiele benötigt man, um ein AI-Modell zu benchmarken?
Dreißig bis fünfzig gut ausgewählte Aufgaben können offensichtliche Unterschiede und Fehlermuster sichtbar machen. Das ist ein Pilot, kein Beweis. Erweitere die Suite, wenn Entscheidungen teuer sind, Teilbereiche vielfältig sind oder die Werte der Kandidaten nahe beieinanderliegen. Berichte Unsicherheit und behalte einen Holdout-Satz zurück.
Was ist der Unterschied zwischen pass@k und pass^k?
Pass@k fragt, ob mindestens einer von k Versuchen erfolgreich ist. Das passt zu Workflows, in denen mehrere Versuche akzeptabel sind. Pass^k fragt, ob alle k Versuche erfolgreich sind. Das passt zu kundenorientierten oder nebenwirkungsbehafteten Workflows, bei denen Konsistenz wichtig ist.
Sollte man ein LLM verwenden, um ein anderes LLM zu bewerten?
Nur wenn deterministische Prüfungen das Qualitätskriterium nicht ausdrücken können. Schreibe eine spezifische Rubrik, vergleiche den Judge mit Expertenlabels, untersuche Abweichungen und halte deterministische harte Schranken außerhalb des Judges.
Sollten Kosten oder Qualität das beste Modell bestimmen?
Wende zuerst Qualitäts- und Sicherheitsschranken an. Vergleiche unter den Modellen, die diese bestehen, die Kosten pro erfolgreicher Aufgabe und die Randlatenz. Ein niedriger Tokenpreis gleicht Wiederholungen oder Wiederherstellungsarbeit nicht aus.
Die Entscheidungsregel
Benchmarke den Workflow, den du ausliefern wirst. Bewerte den Zustand, der dir wichtig ist. Wiederhole die Aufgabe oft genug, um Varianz sichtbar zu machen. Untersuche die Fehler. Wähle anschließend das günstigste Modell, das jede harte Schranke und die erforderliche Zuverlässigkeitsschwelle erfüllt.
Ranglisten helfen dir bei der Entscheidung, was du testen solltest. Deine Testsuite entscheidet, was Produktionszugriff verdient.