Wenn man auf keine Zahl bringen kann, ob eine Änderung den Agenten besser oder schlechter gemacht hat, betreibt man kein Engineering, sondern Raten mit Extraschritten. Der häufigste Grund, warum Agent-Projekte stocken, ist kein schwaches Modell, es ist das Fehlen einer Eval-Harness. Ohne sie wird jede Prompt-Anpassung, jeder Tool-Wechsel und jeder Modellwechsel von jemandem bewertet, der sich eine Handvoll Outputs anschaut und "scheint besser" verkündet, und so liefert man eine Regression aus und erfährt es von einem Nutzer. Die Anzeigetafel muss vor dem Agenten existieren, denn man kann nicht verbessern, was man nicht bewerten kann.

Die Umdeutung: Ein Eval-Set ist die Testsuite für probabilistischen Code. Man würde einen Service ohne Tests nicht refactoren und auf die Stärke des Eindrucks hin ausliefern, dass es gut aussieht. Ein Agent ist schwerer zu durchschauen als dieser Service, nicht leichter, also braucht er die Anzeigetafel mehr, nicht weniger.

Erst die Harness bauen, dann den Agenten

Eine Eval-Harness ist unglamourös und anfangs klein: eine Menge repräsentativer Eingaben, eine Definition eines guten Outputs für jede, und eine Möglichkeit, das aktuelle System gegen alle laufen zu lassen und eine Punktzahl zu bekommen. Zwanzig bis fünfzig echte Beispiele aus tatsächlichem oder erwartetem Traffic schlagen tausend synthetische. Der Punkt ist ein fester Maßstab, sodass "wir haben den Agenten verbessert" eine Behauptung wird, die man prüfen kann, statt ein Gefühl.

Sobald sie existiert, kehrt sich der Workflow um. Jede Änderung, neuer Prompt, neues Tool, neues Modell, läuft zuerst gegen die Harness. Eine Änderung, die die Punktzahl hebt, wird ausgeliefert, eine, die sie senkt, nicht, egal wie clever sie aussah. Auf Bedrock gibt Model Evaluation dafür einen gemanagten Pfad mit automatischen Metriken und menschlichem Review, und es wurde lange vor diesem Bedarf allgemein verfügbar. Das Werkzeug zählt weniger als die Disziplin: bewerten, dann entscheiden.

LLM-as-a-Judge, und wo er einen belügt

Offene Outputs von Hand zu bewerten, skaliert nicht, also ist der Standardweg, ein Modell als Richter einzusetzen: einem starken Modell die Eingabe, den Output des Agenten und eine Rubrik geben und es um eine Bewertung bitten. Bedrock Model Evaluation unterstützt genau das. Es ist wirklich nützlich, und es ist auch eine Komponente, die falsch liegen kann, was Teams in dem Moment vergessen, in dem sie anfängt, ordentliche Zahlen auszuspucken.

Der Richter hat vorhersagbare Fehlermuster, gegen die man designen muss:

  • Positions- und Ausführlichkeits-Bias. Richter neigen dazu, die zuerst gezeigte Option und die längere, selbstbewusster klingende Antwort zu bevorzugen, unabhängig von Korrektheit. Reihenfolge randomisieren und Länge kontrollieren.
  • Selbstbevorzugung. Ein Richter aus derselben Modellfamilie kann Outputs der eigenen Familie höher bewerten. Wo es zählt, einen Richter aus einer anderen Familie als das zu testende Modell verwenden.
  • Rubrik-Drift. Eine vage Rubrik ("ist diese Antwort gut") produziert vage, instabile Bewertungen. Eine konkrete Rubrik ("zitiert die Antwort den Policy-Abschnitt, und ist der zitierte Abschnitt korrekt") produziert Bewertungen, auf die man handeln kann.
  • Selbstbewusste Zustimmung zu einer falschen Antwort. Enthält die Eingabe eine falsche Prämisse, kann der Richter einen Output belohnen, der sie mitträgt. Adversariale Fälle einbauen, bei denen das richtige Verhalten Ablehnung oder Korrektur ist.

Der Richter ist keine Ground Truth. Er ist eine schnelle, billige Annäherung an Ground Truth, die man an einem kleinen, von Menschen gelabelten Set kalibriert. Sind sich Richter und die eigenen Menschen an diesem Set uneinig, erst die Rubrik reparieren, bevor man dem Richter beim Rest vertraut.

Die Trajektorie bewerten, nicht nur die Antwort

Speziell bei Agenten ist die finale Antwort nur die halbe Miete. Ein Agent kann eine richtige Antwort über einen falschen Weg produzieren: ein Tool aufrufen, das er nicht hätte aufrufen sollen, zehn Schritte für eine Zwei-Schritte-Aufgabe verbrauchen, oder unterwegs Daten in ein Log leaken. Die Trajektorie ebenso wie den Output bewerten. Hat er die erwarteten Tools genutzt? Ist er innerhalb seiner erlaubten Aktionen geblieben? Ist er in einer sinnvollen Anzahl Schritte fertig geworden? Ein Agent, der die richtige Antwort liefert, während er eine Delete-API aufruft, die er nie hätte anfassen sollen, hat den Eval nicht bestanden, egal was der finale Text sagt.

Fazit

Die Reihenfolge ist nicht verhandelbar: erst Eval-Harness, dann Agent. Die Harness ist eine kleine, feste Menge echter Eingaben mit definierten guten Outputs und einer wiederholbaren Bewertung, und sie macht aus jeder Änderung eine gemessene Entscheidung statt eines Bauchgefühl-Checks. LLM-as-a-Judge einsetzen, um die Bewertung zu skalieren, aber ihn als fehlbare Komponente behandeln: seine Biases kontrollieren, ihm eine konkrete Rubrik geben und ihn an menschlichen Labels kalibrieren. Den Pfad bewerten, nicht nur das Ergebnis. Man kann nicht ausliefern, was man nicht bewerten kann, und die Teams, die zuverlässige Agenten ausliefern, sind die, die die Anzeigetafel gebaut haben, bevor sie den Spieler gebaut haben.

Weiterlesen

Für die Plattformseite des Einbindens von Evals in eine Delivery-Pipeline gibt es die Cloud-Field-Notes auf ercan.cloud, und den Hub auf ercanermis.com.