Benchmarks überleben den Kontakt mit einem Kundensystem nicht
Wir haben ein Modell auch anhand von Agenten-Benchmarks ausgewählt. Es scheiterte dann im dritten von fünf Prozessschritten, auf eine Art, nach der kein Benchmark gefragt hatte. AgentBench erklärt die Lücke gut — und auch, warum wir solche Zahlen nicht mehr als Auswahlkriterium verwenden.
Der Fehler, mit dem es anfing
Die Aufgabe war ein fünfstufiger Freigabeprozess: Anfrage lesen, Konto nachschlagen, Berechtigung prüfen, Entscheidung schreiben, Antragsteller benachrichtigen. Einzeln beherrschte der Agent jeden Schritt. Durchgehend ausgeführt scheiterte er zuverlässig an Schritt drei — nicht weil er die Berechtigung falsch bewertete, sondern weil er einen veralteten Wert aus Schritt zwei mitschleppte.
Kein von uns herangezogener Benchmark deckte das ab. Sie messen, ob ein Modell eine Aufgabe lösen kann. Unser Fehler betraf das, was das Modell zwischen Aufgaben mitnimmt.
Was AgentBench tatsächlich misst
Liu et al. haben einen Benchmark über mehrere Umgebungen gebaut, in denen Sprachmodelle als Agenten handeln — von Betriebssystemen und Datenbanken bis zu Wissensgraphen und Spielen. Das ist solide Arbeit und deutlich näher an realer Nutzung als einstufige Fragebeantwortung.
Es bleibt ein Benchmark, also feste Umgebungen und eine vergleichbare Punktzahl. Genau das macht ihn nützlich, um Modelle gegeneinander zu ordnen — und genau das macht ihn stumm gegenüber einem fünfstufigen Prozess, den außerhalb unseres Kunden niemand kennt.
Wie wir ihn trotzdem nutzen
Wir verwenden Agenten-Benchmarks als Filter, nicht als Entscheidung. Wer eine Werkzeugschleife über mehrere Züge in einer öffentlichen Umgebung nicht zusammenhält, hält auch unsere nicht zusammen, und wir können früh aussortieren. Das spart Zeit.
Was wir nicht tun: zwischen zwei glaubwürdigen Kandidaten anhand einer Benchmark-Differenz entscheiden. Ab einem gewissen Punkt sagt die Rangfolge mehr über den Benchmark als darüber, wie sich das Modell in einem Prozess mit unseren Daten, unseren Werkzeugen und unseren Fehlerfällen verhält.
Was wir stattdessen testen
Wir bauen die Journey: die tatsächliche Abfolge, mit den tatsächlichen Werkzeugen, gegen ein Gegenstück, das sich wie das echte System verhält. Dann lassen wir sie wiederholt laufen und schauen, wo sie bricht — nicht, ob sie es kann.
Das interessante Ergebnis ist keine Punktzahl, sondern eine Liste von Fehlermodi mit Häufigkeiten: mitgeschleppter Zustand, ein Werkzeugaufruf mit dem Argument des Vorschritts, ein Retry, der eine Nebenwirkung verdoppelt. Nichts davon erscheint als Prozentwert in einer Rangliste.
| Was ein Benchmark beantwortet | Was ein Journey-Test beantwortet |
|---|---|
| Kann das Modell diese Aufgabe | Läuft der Prozess auf unseren Daten durch |
| Wie es im Vergleich abschneidet | Welcher Schritt bricht, und wie oft |
| In einer festen Umgebung | Gegen ein Gegenstück, das ablehnen kann |
| Zu einem Zeitpunkt | Bei jedem Deployment, als Gate |
Warum das simulierte Gegenstück entscheidend ist
Möglich wird das erst dadurch, dass wir eine simulierte Fassung des Systems bauen, mit dem der Agent spricht. Sie hält Zustand, lehnt ungültige Übergänge ab und lässt sich gezielt in die unangenehmen Fälle treiben — eine Berechtigung, die mitten im Prozess abläuft, eine doppelte Einreichung, ein Timeout beim Benachrichtigen.
Gegen ein echtes System sind diese Fälle entweder nicht auslösbar oder teuer aufzuräumen. Gegen ein simuliertes sind sie eine Testvorrichtung. Das ist der Baustein, der Agententests von der Demo zur Ingenieursarbeit macht.
Worauf wir achten
Eine zu gutmütige Simulation ist schlechter als kein Test, weil sie Zuversicht ohne Abdeckung erzeugt. Wir halten unsere ehrlich, indem wir aufgezeichnete Interaktionen des echten Systems erneut abspielen und prüfen, ob die Simulation dieselben Ablehnungen erzeugt hätte.
Wir tun auch nicht so, als ersetze der Journey-Test die Überwachung im Betrieb. Er fängt die Fehlerklassen, an die wir gedacht haben. Die anderen kommen weiterhin auf dem üblichen Weg.