Wer bewertet den Bewertungsmechanismus? Validierung von Bewertungstools, bevor man ihnen vertraut.

Im Jahr 2026 verwendet fast jedes Team, das einen KI-Agenten veröffentlicht, auch ein Bewertungssystem mit Dashboards, Bestehensraten, CI-Gates sowie LLM-Bewertern, die die Leistungen anhand von Kriterien bewerten. All das zeigt Stringenz und scheint den Unterschied zwischen einem Produktivsystem und einer Demo zu markieren, die zufällig zweimal funktioniert hat.

Fragt man jedoch die nächstliegende Frage, wird es still. Wer hat überprüft, ob das System tatsächlich das Richtige misst, es korrekt misst und auch nach einem halben Jahr noch die Wahrheit sagt? Fast niemand. Die Branche hat zwei Jahre damit verbracht, Instrumente zur Bewertung von Agenten zu entwickeln, und hat gerade erst damit begonnen, Instrumente zur Bewertung dieser Instrumente zu schaffen. Die Lücke zeigt sich bereits in der Produktion auf mehrere vorhersehbare Weise.

Die Annahme, die niemand ausspricht

Hinter den meisten Evaluierungsframeworks für Agenten steht eine unausgesprochene Annahme: Ein Erfolg bedeutet, dass sich der Agent korrekt verhalten hat, ein Misserfolg hingegen, dass er es nicht getan hat. Wenn man diese Annahme akzeptiert, wird das Framework zu einer Black Box, der die Menschen automatisch vertrauen. Das Dashboard zeigt Grün an, die Pull Requests werden zusammengeführt und das Team macht weiter.

Forschungen zu den Ablaufprotokollen der Agenten haben begonnen, Lücken in dieser Prämisse aufzuzeigen. Eine Studie untersuchte 58 Protokolle, die durch Ergebnisbewertungen als erfolgreich eingestuft worden waren, und stellte fest, dass 83 Prozent dieser Ausführungen prozedurale oder Sicherheitsverstöße verbargen, die durch die Erfolgs-/Misserfolgsbewertung nie ans Licht kamen. Der Agent lieferte die richtige Antwort und erhielt eine perfekte Bewertung, doch der von ihm gewählte Weg war im Stillen fehlerhaft. Die Kluft zwischen Ergebnis und Prozess ist genau das, was ein Evaluierungsframework dazu dient aufzudecken – und genau das, was die meisten Frameworks aus Konstruktionsgründen nicht erkennen können.

Vier Fehlermuster verdienen eigene Bezeichnungen. Jedes erfordert eine eigene Lösung, und Teams bemerken in der Regel nur dasjenige, das ihnen Schaden zugefügt hat.

Judge-Drift. Alles Semantische wird in der Regel von einem LLM bewertet, da eine regelbasierte Überprüfung nicht erkennen kann, ob „nächster Freitag“ in das korrekte Datum umgewandelt wurde. Doch auch der „Judge“ ist ein Modell, und Modelle ändern sich. Teams mit langlaufenden Testumgebungen beobachten oft, wie das gesamte Regressionstool über Nacht versagt, verlieren einen Tag mit der Untersuchung und stellen schließlich fest, dass sich die Bewertungen geändert haben, weil das „Judge“-Modell aktualisiert wurde und nicht, weil der Agent schlechter geworden ist. Das Festhalten an einer bestimmten Version des „Judge“-Modells sowie an einem festen Rubrik-Hash verringert das Problem, ohne es vollständig zu beseitigen, da die gehosteten „Judge“-Endpunkte ständig wechseln.

Der Ergebnisfehlschluss. Wenn nur der Endzustand bewertet wird, geht der interessante Teil eines Vorgangs verloren. Ein Agent könnte das falsche Werkzeug verwenden, denselben schlechten Argument viermal erneut senden und dennoch durch Glück oder Ausdauer zur richtigen Antwort gelangen, wobei ein System, das nur die letzte Nachricht liest, dies als Bestehen markieren würde.

Private Fehlermuster. Öffentliche Benchmarks wie BFCL oder tau-bench helfen dabei, Modelle zu vergleichen, doch sie können Fehler erkennen, die innerhalb des eigenen Tool-Registriers eines Teams auftreten: einen Null-Wert in einem optionalen Feld, einen Zeitzone-Fehler in einem Datumsargument oder eine Währungskonflikte in einem Geldfeld. Solche Fehler gehören zu den Tools des Teams und tauchen niemals auf einer allgemeinen Leaderboard auf. Wenn die Abdeckungsrate ausschließlich aus öffentlichen Benchmarks entnommen wird, ist der Validator genau dort blind, wo es wirklich darauf ankommt – bei den Teilen des Systems, die niemand sonst getestet hat.

Der Kostenblindpunkt. Am wenigsten diskutiert – und vielleicht am folgenschwersten. Ein Harness kann einen Agenten in jeder überprüften Dimension als präzise einstufen, ohne jemals zu prüfen, ob sich der Agent selbst trägt. Ein bekanntes Beispiel betraf einen Agenten, der alle zwölf Qualitätskriterien erfüllte, dennoch aus dem Produktivbetrieb entfernt wurde, weil jede erfolgreiche Lösung mehr kostete als der menschliche Prozess, den er ersetzen sollte. Die Qualitätsbewertungen waren korrekt. Es existierte jedoch kein Kriterium für die Frage, die über sein Schicksal entschied.

Ein Buchungsauftragsbearbeiter mit perfekten Ergebnissen – doch ohne Erfolg

Stellen Sie sich vor, ein Buchungsspezialist soll Flüge für „nächsten Freitag“ finden. Aus einem Verzeichnis mit Dutzenden von Tools wählt er das richtige aus, wodurch die Tool-Wahl eine makellose Bewertung von 1,0 erhält. Anschließend sendet er das Datum als reine Zeichenkette, ohne die relative Angabe zunächst zu verarbeiten. Die API antwortet mit einem Validierungsfehler, und der Spezialist sendet denselben fehlerhaften Datensatz viermal, bevor er sich entschuldigt und aufgibt.

Diese Auswertung ergibt zwei Werte: eine perfekte 1,0 für die Tool-Wahl und eine 0 für die Erledigung der Aufgabe. Keiner dieser Werte zeigt an, welches von drei Problemen aufgetreten ist: fehlerhafte Extraktion der Argumente, eine Fehlerantwort, die der Spezialist nie gelesen hat, oder eine Wiederholungslogik, die bei unveränderten Eingaben im Kreis läuft. Eine detaillierte Analyse der Bewertung der Toolaufrufe zeigte, dass allein die Überprüfung, ob das richtige Tool aufgerufen wurde, die Absicht statt die tatsächliche Ausführung prüft – und es war schließlich nicht die Absicht, die versagt hat.

Das ist das ganze Problem in Miniaturform. Das Testprogramm gab zwei Zahlen aus – keine war völlig falsch, doch beide waren für die entscheidende Frage nutzlos: Was muss repariert werden?

Praktiken, die helfen

Sobald das Testprogramm als System betrachtet wird, das eigene Qualitätskontrollen verdient, sieht eine ausgereifte Einrichtung anders aus. Einige Gewohnheiten unterscheiden Teams, die Probleme früh erkennen, von denen, die erst unter großen Schwierigkeiten darauf stoßen:

• Eine eigene Metaevaluierungsstufe. Bei ernsthaften Implementierungen teilt sich die Arbeit nun in die Bewertung des Ergebnisses, die Bewertung jeder einzelnen Schrittsequenz sowie eine Stufe auf, die die Bewertungen gegeneinander abgleicht, sodass die Bewertung eines einzelnen Bewerters nicht unkritisch übernommen wird.
• Prüfung auf Basis der Ausführung statt Textabgleich. Die zuverlässigsten Benchmarks überprüfen, was tatsächlich in der Welt geändert wurde. tau-bench liest den Zustand der Datenbank, SWE-Bench führt die eigentlichen Tests durch, und tau2-bench’s Pass-at-K prüft, ob ein Agent bei wiederholten Versuchen konsequent erfolgreich ist. Eigenentwickelte Testpakete sollten diesem Vorbild folgen und echte Änderungen bestätigen, unabhängig davon, was der Agent meldet.
• Kosten neben Qualität. Der finanzielle Aspekt spricht dafür, die Kosten pro erfolgreichem Ergebnis als zentrale Kennzahl neben der Genauigkeit zu tracken – und zwar von Anfang an, anstatt erst später, wenn ein Budgetverantwortlicher danach fragt.
• Stufenweise CI. Vollständige End-zu-End-Bewertungen sind sehr teuer, da jede Aufgabe zwei Modellaufrufe erfordert – den des Agents und den des Bewerters – und ein Satz aus hundert Aufgaben mit jeweils fünf Durchläufen die Kosten für die CI ungefähr verdoppelt. Teams, die dies im Griff haben, trennen schnelle, kostenlose, deterministische Überprüfungen, die bei jedem Commit ausgeführt werden, von langsamen, kostspieligen Bewertungen, die nur dann stattfinden, wenn eine Änderung die Funktionalität des Agents betrifft.
• Ein Satz, der weiterhin aktuell bleibt. In einer kürzlichen Branchenumfrage gaben die meisten Befragten an, dass ihre Bewertungen nicht mehr zutreffend seien, weil der Produktverkehr sich vom ursprünglichen Testset entfernt habe und es unmöglich werde, damit Schritt zu halten. Ein seit dem Start unverändert gelassener Satz ist nicht harmlos – er misst ein System, das bereits nicht mehr existiert.

Vier Schritte für einen bereits vorhandenen Satz

Für ein Team mit einem Bewertungssystem, das diese überprüfen und nicht einfach nur vertrauen möchte, schließen vier Schritte den größten Teil der Lücke:

1. Nehmen Sie zehn bis zwanzig Produktionsprotokolle, die vom System als erfolgreich markiert wurden, und lesen Sie jede gesamte Ablaufkette manuell durch – nicht nur die Ergebnisse. Wie viele dieser erfolgreichen Fälle tatsächlich einen prozeduralen Fehler verbergen, ist ein echter Indikator dafür, inwieweit dem grünen Dashboard Vertrauen entgegengebracht werden kann.
2. Legen Sie die Version des Bewertungsmodells sowie den Text der Bewertungskriterien fest und protokollieren Sie beides zusammen mit jeder Bewertung, sodass ein stiller Upgrade des Bewertungsmodells als klar gekennzeichnetes Ereignis erscheint und nicht als rätselhafte Regression.
3. Verfolgen Sie ab dem ersten Tag die Kosten pro erfolgreichem Ergebnis – noch bevor jemand danach fragt.
4. Erstellen Sie eine kleine Regressionssammlung aus echten Produktionsfehlern und nicht nur aus synthetischen Fällen. Öffentliche Benchmarks legen einen Mindeststandard fest, während die eigene Fehlerhistorie eines Teams vorhersehen kann, welcher peinliche Fehler als Nächstes auftreten wird.

Nichts davon ersetzt das eigene Testpaket. Es bedeutet lediglich, dass das Testpaket nicht länger als die zu wichtige Einzelkomponente angesehen wird, die man überprüfen müsste.

Schnelle Antworten

Was bedeutet die Validierung des Testpakets für Agenten? Es wird derselbe gründliche Prüfungsansatz auf das Bewertungssystem angewandt, wie das System ihn auf den Agenten anwendet – dabei wird geprüft, ob der Bewertungsmechanismus, die Bewertungskriterien und die Bewertungspipeline weiterhin das messen, was sie vorgeben.

Warum schwanken die Bewertungen bei LLM-as-Judge? Der „Bewerter“ ist ein Modell. Wenn sein Anbieter es aktualisiert oder durch eine neuere Version ersetzt, können sich die Bewertungen ändern, obwohl sich der bewertete Agent nicht verändert hat.

Können öffentliche Benchmarks ein eigenes Testpaket ersetzen? Nein. Sie helfen dabei, Modelle bei gemeinsamen Aufgaben miteinander zu vergleichen, doch sie übersehen Fehler, die auf den eigenen Tools, Daten oder Sonderfällen eines Teams beruhen.

Ist eine hohe Bestehensrate ausreichend, um einen Agenten im Produktivbetrieb zu halten? Nicht allein schon. Ein Agent kann hinsichtlich Genauigkeit und Qualität der Handlungsabläufe gute Leistungen erbringen und dennoch entfernt werden, wenn die Kosten pro erfolgreichem Ergebnis den von ihm erbrachten Wert nicht rechtfertigen.

Wie oft sollte das Toolset überprüft oder neu erstellt werden? Kontinuierlich, je nach Veränderungen im Produktivverkehr. Da die Nutzung sich vom ursprünglichen Testdatensatz entfernt, müssen Fälle aus echten Fehlern in regelmäßigen Abständen bereitgestellt werden – und nicht nur bei der Erstveröffentlichung.

Die Aussagen hinter der Anzeigetafel

Eine Bewertungssuite ist kein Beweis dafür, dass ein Agent funktioniert. Es handelt sich dabei um eine Aussage darüber, was „Funktionieren“ bedeutet, verfasst von dem, der sie erstellt hat, bewertet von einem Urteilsfähigen, dessen Ansichten sich ändern können, und anhand eines Testsets, das bereits im Moment der Erstellung an Wert verliert. Wenn man diese Aussage als selbstverständlich wahr hinnimmt, werden Agenten ausgeliefert, die alle Dashboards bestehen, aber die wirklich wichtige Frage nicht beantworten können. Eine manuelle Überprüfung von zehn Auswertungen, wie oben beschrieben, zeigt schnell, wie viel das Dashboard verbirgt hat.