Das Eval-Harness, mit dem ich KI-Agenten ohne Angst ausliefere

Inhaltsverzeichnis

Aktualisiert Juni 2026.

TL;DR: Der Grund, warum ich einen Prompt ändern oder ein Modell bei einem Live-Agenten austauschen kann, ohne den Atem anzuhalten, ist eine Sache: ein Eval-Harness. Ein fester Satz bewerteter Testfälle, automatisch gescort — harte Assertions, wo ich sie schreiben kann, ein LLM-Richter, wo ich es nicht kann — ausgeführt vor jeder Änderung. Hält der Score, liefere ich aus. Fällt der Score, tue ich es nicht. Das Testset ist nicht synthetisch; es wird aus echten Produktionsfehlern gebaut, sodass jeder Bug zu einem dauerhaften Regressionstest wird.

Operator’s read: Über mehr als 100 Agenten hinweg ist der Unterschied zwischen denen, die ich selbstbewusst anfasse, und denen, vor denen ich Angst habe, ob sie Evals haben. Kein Eval-Harness bedeutet, dass jede Prompt-Anpassung ein Glücksspiel ist. Ein Eval-Harness verwandelt „ich glaube, das ist besser” in „das ist messbar 4 Punkte besser und hat nichts kaputt gemacht”. Das ist der ganze Durchbruch.

Du würdest keinen Code ohne Tests ausliefern. Leute liefern ständig Agenten ohne Evals aus und fragen sich dann, warum eine „winzige Prompt-Anpassung” die Produktion zerlegt hat. Ein Eval-Harness ist die Testsuite für nicht-deterministische Software. Hier ist das, das ich tatsächlich ausführe.

Beginne mit einem Testset, das aus echten Fehlern gebaut ist

Das Harness ist nur so gut wie seine Testfälle, und die besten Testfälle kommen aus der Produktion, nicht aus deiner Fantasie. Jedes Mal, wenn ein Agent in freier Wildbahn versagt, erfasse ich die exakte Eingabe (ich logge jeden Lauf mit einer Trace-ID — siehe wie man einen Agenten in der Produktion debuggt) und verwandle sie in einen Eval-Fall:

interface EvalCase {
  id: string;
  input: AgentInput;        // die exakte Produktionseingabe
  expected?: string;        // Ground Truth, wenn es eine gibt
  assertions: Assertion[];  // harte Prüfungen, die bestehen müssen
  rubric?: string;          // für den LLM-Richter, wenn die Ausgabe offen ist
}

Zwei Praktiken zählen hier. Zieh aus der Produktion, damit deine Evals testen, was tatsächlich kaputtgeht, nicht das, was du geraten hast. Und deck die Bandbreite ab — Happy Path, Randfälle, adversariale Eingaben und die leeren/fehlerhaften Eingaben, die stille Fehler verursachen. Ein Testset aus 30 bis 50 gut gewählten Fällen fängt weit mehr als 500 faule. Ich hätte lieber 40 Fälle, die jeweils einen echten Fehlermodus darstellen, als tausend, die alle denselben einfachen Pfad testen.

Score zuerst mit Assertions, dann mit einem LLM-Richter

Nicht jede Ausgabe braucht ein Modell zur Bewertung. Ich greife zum billigsten Scorer, der funktioniert.

Harte Assertions für alles Strukturierte. Parst die Ausgabe als gültiges JSON? Enthält sie das erforderliche Feld? Liegt das extrahierte Datum im Bereich? Hat sie das richtige Tool mit den richtigen Argumenten aufgerufen? Diese sind deterministisch, kostenlos und eindeutig — schreib so viele wie du kannst.

const assertions: Assertion[] = [
  (out) => isValidJSON(out),
  (out) => parse(out).category in ALLOWED_CATEGORIES,
  (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1,
];

Ein LLM-Richter für den offenen Rest — Ton, Hilfsbereitschaft, „hat das die Frage wirklich beantwortet”. Hier gibst du einem Modell die Eingabe, die Ausgabe und eine Rubrik und bittest es, zu bewerten. Zwei Regeln halten den Richter ehrlich: mach die Rubrik spezifisch (eine 1-5-Skala mit beschriebenen Ankern schlägt „bewerte die Qualität”), und nutze ein starkes Modell als Richter — Bewerten ist eine Reasoning-Aufgabe, also ist das eine Stelle, an der ich gerne für Sonnet zahle, selbst wenn der Agent selbst auf Haiku läuft, gemäß der Kostenrechnung. Eine vage Rubrik oder ein schwacher Richter gibt dir Rauschen, das wie Signal aussieht.

Führe das Harness vor jeder Änderung aus

Das Harness existiert, um eine Frage zu beantworten: hat diese Änderung den Agenten besser oder schlechter gemacht? Also führe ich es vor jeder Prompt-Bearbeitung, jedem Modellwechsel oder jeder Tool-Änderung aus.

# Baseline auf main
npm run eval -- --suite=booking-agent > baseline.json

# mach die Änderung, dann erneut ausführen
npm run eval -- --suite=booking-agent > candidate.json

# vergleichen
npm run eval:diff baseline.json candidate.json

Das Diff zeigt den aggregierten Score, das Bestanden/Durchgefallen pro Fall und — entscheidend — welche spezifischen Fälle regressiert sind. Ein Aggregat, das steigt, während drei Fälle still brechen, ist keine Verbesserung; es ist ein Tausch, den ich sehen und genehmigen will, nicht einer, der sich durchschleicht. Das Diff pro Fall zu beobachten ist, wie man „eine Sache behoben, zwei andere kaputt gemacht” vermeidet — den Fehlermodus, der Leute Angst vor ihren eigenen Prompts macht.

Setze ein Regressions-Gate und lass es blockieren

Sobald du dem Harness vertraust, verdrahte es als Gate in den Pfad zur Produktion. Meine Regel ist unverblümt: eine Änderung, die den Score unter die Baseline-Schwelle drückt, wird nicht ausgeliefert. Kein „ich schau mir das später an” — sie ist blockiert, genau wie ein fehlschlagender CI-Test.

const PASS_THRESHOLD = 0.90; // 90 % der Fälle müssen bestehen
if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) {
  throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`);
}

Das ist es, was Evals von einem Nice-to-have in das verwandelt, was dir erlaubt, schnell zu sein. Das Gate ist, was „ohne Angst ausliefern” buchstäblich wahr macht: der schlimmste Fall für eine schlechte Änderung ist ein roter Eval-Lauf, kein Produktionsvorfall. Und weil das Testset jedes Mal wächst, wenn etwas kaputtgeht, wird das Gate von selbst mit der Zeit strenger und schützender.

Berücksichtige Nicht-Determinismus beim Scoring

Eine Feinheit, über die Leute stolpern: dieselbe Eingabe kann über Läufe hinweg unterschiedlich scoren, weil das Modell anders sampelt. Wenn du jeden Fall einmal ausführst, siehst du Phantom-Regressionen — ein Fall, der „kaputtging”, ist in Wahrheit nur Sampling-Rauschen.

Zwei Gegenmaßnahmen. Führe Evals bei temperature: 0 aus, um die Varianz zu verkleinern (es wird sie nicht vollständig beseitigen). Und für Fälle, die du flackern gesehen hast, führe sie N-mal aus und nimm die Bestehensrate, nicht ein einzelnes Bestanden/Durchgefallen. Ein Fall, der 9 von 10 besteht, ist in besserer Verfassung als einer, der 5 von 10 besteht, auch wenn beide einen grünen Einzellauf zeigen können. Das ist dasselbe Prinzip von Volumen-über-Anekdote, das ich beim Debuggen intermittierender Fehler nutze — ein Lauf ist eine Meinung, fünfzig Läufe sind Daten.

Schließe die Schleife mit Produktionsüberwachung

Das Eval-Harness testet gegen bekannte Fälle. Die Produktion wirft neue. Also ist die Schleife: überwache das Live-Verhalten, fang einen neuen Fehlermodus, verwandle ihn in einen Eval-Fall, behebe ihn, und nun ist er dauerhaft abgesichert. Die Überwachungsseite — Erfolgsrate, Ausgabenvalidität und Kosten pro Lauf auf Live-Traffic zu verfolgen — ist das, was ich in wie ich messe, ob ein KI-Agent tatsächlich funktioniert behandle. Evals und Überwachung sind zwei Hälften desselben Systems: die Überwachung findet die Bugs, die Evals stellen sicher, dass sie tot bleiben.

Diese Feedback-Schleife ist das eigentliche Produkt. Jedes einzelne Eval-Set veraltet; ein Prozess, der jeden Produktionsfehler in einen dauerhaften Test verwandelt, wird jede Woche stärker. So wird aus einem Agenten von „beängstigend anzufassen” etwas, das ich an einem Freitagnachmittag ohne mit der Wimper zu zucken refaktoriere.

FAQ

Was gehört in ein Eval-Set für einen KI-Agenten?

Echte Produktionseingaben, in bewertete Fälle verwandelt — Happy Path, Randfälle, adversariale und fehlerhafte Eingaben — jeweils mit harten Assertions und, für offene Ausgaben, einer LLM-Richter-Rubrik. 30 bis 50 Fälle aus echten Fehlern schlagen Hunderte synthetischer, die alle den einfachen Pfad testen.

Sollte ich ein LLM nutzen, um Agenten-Ausgaben zu bewerten?

Nutze harte Assertions überall dort, wo die Ausgabe strukturiert ist (gültiges JSON, korrektes Feld, richtiger Tool-Aufruf) — sie sind kostenlos und deterministisch. Reserviere einen LLM-Richter für offene Qualitäten wie Ton und Hilfsbereitschaft, mit einer spezifischen Rubrik und einem starken Richter-Modell, damit du Signal bekommst, kein Rauschen.

Wie verhindere ich, dass eine Prompt-Änderung die Produktion still kaputt macht?

Führe das Eval-Harness vor jeder Änderung aus und vergleiche gegen eine Baseline, wobei du auf Regressionen pro Fall achtest, nicht nur auf den aggregierten Score. Dann mach Deployments vom Ergebnis abhängig, sodass jede Änderung, die unter die Baseline-Schwelle fällt, wie ein fehlschlagender Test blockiert wird.

Wie gehe ich mit Nicht-Determinismus in Evals um?

Führe bei Temperatur 0 aus, um die Varianz zu reduzieren, und für Fälle, die flackern, führe sie mehrfach aus und score die Bestehensrate statt eines einzelnen Laufs. Ein Fall, der 9 von 10 Mal besteht, ist gesünder als einer, der 5 von 10 besteht, selbst wenn ein Einzellauf beide grün zeigt.