Stop running fresh model benchmarks and start watching your agent try to cancel a subscription. The gap between those tw

Hören Sie auf, ständig neue Modell-Benchmarks zu erstellen, und beobachten Sie stattdessen, wie Ihr Agent versucht, ein Abonnement zu kündigen. Die Lücke zwischen diesen beiden Aktivitäten ist der Ort, an dem Produktionssysteme scheitern. Ein Single-Turn-Test kann Ihnen sagen, ob eine Antwort freundlich klingt. Er kann Ihnen jedoch nicht sagen, ob der Agent gerade dem falschen Kunden eine Rückerstattung gewährt hat, sechzehnmal in einer Schleife gegen eine Kalender-API gelaufen ist oder beschlossen hat, den Betrugstest einfach zu überspringen. Text ist das am wenigsten gefährliche, was ein Agent produziert. Die wahren Risiken verbergen sich in den Tools, die er nutzt, den Daten, die er verändert, und in den Momenten, in denen er um Hilfe hätte fragen sollen, aber einfach weitergemacht hat.

Warum Text-Benchmarks in der Produktion versagen

Hohe Punktzahlen in Standard-Benchmarks sind zu einer trügerischen Form des Komforts geworden. Ein Agent, der elegante Prosa schreibt, kann dennoch ein betriebliches Risiko darstellen. Wenn Ihr System Termine bucht, Datenbankeinträge bearbeitet oder Support-Tickets erstellt, ist der generierte Text nur die sichtbare Oberfläche des Workflows. Darunter trifft der Agent konkrete Entscheidungen darüber, welchen Endpunkt er aufruft, welche Nutzlast (Payload) er sendet und wann er aufhört. Er kann die Bestenliste für Leseverständnis anführen und Ihnen gleichzeitig Geld kosten, indem er Ressourcen doppelt bucht, die falsche Zeile verändert oder sensible Zustände in eine Logdatei leakt. Sie müssen die Mechanik der Arbeit überprüfen, nicht nur den Schliff des Outputs. Wenn ein Agent in einem Offline-QA-Test gut abschneidet, aber Ihren Workflow durch Endlosschleifen oder den Missbrauch eines Tools unterbricht, schauen Sie mit Ihrer Evaluierung auf die falschen Signale.

Abbildung der fünf Abhängigkeiten

Das Team bei Van Data Team beginnt jede Evaluierung damit, fünf spezifische Kontrollpunkte abzubilden. Dies ändert die Fragestellung grundlegend. Sie fragen nicht mehr, ob ein Modell intelligenter ist als ein anderes. Sie fragen stattdessen, ob der Agent eine Produktionsaufgabe unter Ihren realen Bedingungen tatsächlich abschließen kann.

Geschäftsergebnisse. Definieren Sie, was „erledigt“ in Bezug auf Kosten und Kundenauswirkungen bedeutet. Eine Aufgabe ist nicht abgeschlossen, nur weil der Agent eine Zusammenfassung ausgegeben hat. Sie ist erst abgeschlossen, wenn der Lagerbestand korrekt ist, der Termin bestätigt wurde und der Kunde eine gültige Sendungsverfolgungsnummer erhalten hat.

Veränderbarer Zustand (Mutable State). Wissen Sie genau, was der Agent ändern darf. Welche Tabellen, welche Status, welche Kontoflaggen? Wenn der Agent Rückerstattungen veranlassen, Jobs umplanen oder Rechnungsadressen aktualisieren kann, müssen Sie jedes Feld inventarisieren, das er berührt.

Tool-Berechtigungen. Seien Sie explizit darüber, welche API-Endpunkte und Funktionen im Umfang liegen. Ein Agent, der Zugriff auf ein Such-Tool, ein Schreib-Tool und ein Benachrichtigungs-Tool hat, wird diese vermischen, wenn die Grenzen unklar sind. Ordnen Sie jede Berechtigung einem spezifischen betrieblichen Bedarf zu.

Fehlerbehebung. Entscheiden Sie, was passiert, wenn die Kalender-API ein Timeout verursacht, einen 500er-Fehler zurückgibt oder ein fehlerhaftes JSON liefert. Der Agent sollte nicht in Panik geraten, eine Erfolgsmeldung halluzinieren oder endlos versuchen, die Aktion zu wiederholen. Er benötigt einen klaren Fallback-Pfad.

Menschliche Kontrollinstanzen. Identifizieren Sie die Momente, in denen ein Mensch zustimmen muss, bevor der Agent fortfährt. Dies ist kein Zeichen von Schwäche der Automatisierung. Es ist ein Sicherheitsventil für hochwirksame Änderungen und eine Quelle für Ground-Truth-Labels für Ihre Bewertungskriterien (Rubrics).

Wie ein echter Evaluierungsplan aussieht

Sobald die Abhängigkeiten abgebildet sind, benötigen Sie einen Evaluierungsplan, der der Komplexität der Produktion gerecht wird. Metriken aus Präsentationsfolien werden Ihnen hier nicht helfen.

Erstellen Sie Testsets aus echten Produktionsfehlern, nicht aus synthetischen Fragenkatalogen. Wenn Ihr Agent am letzten Dienstag versagt hat, weil er zwei ähnliche SKUs verwechselt hat, sollte genau diese Verwechslung ein dauerhafter Testfall sein. Ihre Evaluierungssuite sollte jedes Mal wachsen, wenn ein Vorfall Ihnen etwas Neues lehrt.

Schreiben Sie Rubriken, die den erfolgreichen Abschluss in operativen Begriffen definieren. Vage Kriterien wie „hilfreich“ oder „genau“ sind nutzlos. Eine nützliche Rubrik besagt, dass eine Rückerstattungsaufgabe nur dann erfolgreich ist, wenn die ursprüngliche Zahlungs-ID referenziert wurde, der Betrag mit der Anfrage übereinstimmte, eine Bestätigungs-E-Mail in der Warteschlange landete und die Transaktions-ID protokolliert wurde.

Definieren Sie Trace-Spezifikationen für Tool-Aufrufe und Retries. Sie benötigen Transparenz darüber, was der Agent geplant hat, was er tatsächlich aufgerufen hat, wie oft er es versucht hat und ob die Retry-Strategie angemessen war. Ein Trace ohne Granularität auf Tool-Ebene ist nur eine schöne Geschichte.

Legen Sie Richtlinien fest, wann ein Mensch benachrichtigt werden muss. Der Agent sollte seine eigenen Grenzen kennen. Wenn eine Anfrage einen Dollar-Schwellenwert überschreitet, ein VIP-Konto betrifft oder auf einen Zustand stößt, den er noch nie zuvor gesehen hat, sollte er es eskalieren, anstatt zu raten.

Installieren Sie Release Gates, um schlechte Modell-Upgrades zu blockieren. Ein neues Modell ist nur dann ein Upgrade, wenn es Ihre spezifischen Ergebnisse verbessert. Wenn es häufiger Tool-Argumente halluziniert, die Latenz erhöht oder neue Sicherheitsrisiken einführt, wird es nicht veröffentlicht. Das Gate hält die Produktion stabil, selbst wenn der Anbieter des Basismodells eine neue Version veröffentlicht.

Runtime Grading: Den Agenten bei der Arbeit beobachten

Anthropic drängt die Branche dazu, über Offline-Tests hinaus zu Runtime Grading überzugehen. Anstatt ein Transkript erst im Nachhinein zu bewerten, ermöglicht Runtime Grading einem System, die Arbeit des Agenten zu beurteilen, während die Aufgabe noch in Ausführung ist. Dies bietet die Chance, Fehler abzufangen, bevor sie sich zu echten Problemen verfestigen.

Das Hinzufügen eines Graders kostet Token und erhöht die Latenz. Man kann es sich nicht leisten, jeden winzigen Schritt zu bewerten. Die Platzierung jedes Graders ist eine Design-Entscheidung. Setzen Sie sie dort ein, wo Fehler teuer werden. Die wertvollsten Checkpoints liegen unmittelbar vor der Übertragung einer Zustandsänderung in eine Datenbank, unmittelbar vor der Abwicklung einer Zahlung und unmittelbar vor dem Versenden einer Nachricht an einen Kunden. Dies sind die Momente, in denen eine Fehlentscheidung zu einer irreversiblen Handlung wird.

Achten Sie auf einen spezifischen blinden Fleck. Wenn dasselbe Modell die Arbeit ausführt und sie auch bewertet, übersieht es möglicherweise dieselben Fehler. Die Logik, die einen Fehler verursacht hat, kann diesen Fehler während der Überprüfung leicht rationalisieren. Behalten Sie bei Aufgaben mit hoher Tragweite eine menschliche Überprüfung im Prozess. Lassen Sie Menschen das Urteil des Graders validieren, insbesondere wenn es um Geld oder das Vertrauen der Kunden geht.

Das Ziel hierbei ist die operative Kontrolle. Verknüpfen Sie Ihre Incident-Daten, Ihre Aufgaben-Rubriken und Ihre Runtime-Traces zu einem einzigen Feedback-Zyklus. Bewerten Sie den gesamten Pfad: den Plan, die Tool-Nutzung, das Wiederherstellungsverhalten und das Endergebnis. Nutzen Sie Offline-Tests, um bekannte, reproduzierbare Fehler vor dem Release abzufangen. Nutzen Sie Runtime-Traces, um neue Ausfälle zu finden, die Sie nicht vorhergesehen haben. Nutzen Sie die menschliche Überprüfung, um herauszufinden, wo Ihre Rubriken zu oberflächlich sind und verschärft werden müssen.

Fragen Sie sich also: Wo würden Sie einen Runtime-Grader in Ihrem Workflow platzieren? Vor einem Tool-Aufruf, nach einem Tool-Aufruf oder nur vor einer riskanten Änderung? Die meisten Teams fangen zu breit an, bewerten alles und kommen dann aufgrund der Kosten zum Stillstand. Fangen Sie eng gefasst an. Wählen Sie die eine Aktion aus, die am meisten schaden würde, wenn sie schiefginge. Setzen Sie dort zuerst einen Grader ein.

Beginnen Sie mit einem teuren Fehler

Operative Evaluierung ist keine Forschungsübung. Sie ist ein Weg, um besser schlafen zu können, sobald der Agent live ist. Sie benötigen am ersten Tag kein perfektes Framework. Sie benötigen einen einzigen, gut definierten Workflow, eine Rubrik, die in klarer Geschäftssprache verfasst ist, und einen Grader, der genau in dem Moment platziert ist, in dem ein Fehler teuer wird. Wenn Sie das richtig machen, haben Sie ein Fundament, dem Sie tatsächlich vertrauen können.

Wenn Sie tiefer in die Agenten-Evaluierung und das Runtime Grading mit einer Community von Praktikern eintauchen möchten, finden Sie die GyaanSetu-Lerncommunity unter https://t.me/GyaanSetuAi.