Agent-Evaluation-Frameworks: Nicht-deterministische KI-Features vor dem Release testen

Deine Testsuite baut auf einem Versprechen auf: Dieselbe Eingabe erzeugt dieselbe Ausgabe. Behaupte, dass add(2, 2) den Wert 4 zurückgibt, und er gibt heute 4 zurück, morgen und bei jedem CI-Lauf, bis jemand die Funktion ändert. Dieses Versprechen ist das Fundament von allem, worauf wir beim automatisierten Testen vertrauen, und Agent-Evaluation ist das, wozu man greift, wenn ein Feature es bricht.

Agentische KI-Features brechen es klammheimlich. Bitte einen LLM-gestützten Agenten, "diesen Support-Thread zusammenzufassen und zu entscheiden, ob eskaliert werden soll", und du bekommst jedes Mal eine andere Formulierung, gelegentlich eine andere Entscheidung und hin und wieder eine selbstbewusst falsche. Dafür gibt es kein assertEquals. Genau hier setzt Agent-Evaluation an: eine Disziplin und ein Werkzeugkasten, um nicht-deterministische Features zu testen, bevor sie die Nutzer erreichen, sodass du auf Basis von Belegen auslieferst statt auf Basis einer hoffnungsvollen Demo.

Ich habe mehr als ein Team dabei beobachtet, wie es ein agentisches Feature ausgeliefert hat, das in den Händen des Gründers wunderbar funktionierte und dann bei einem von zwanzig Kunden fehlschlug, ohne dass ein Test das hätte abfangen können, weil das Team KI-Features immer noch wie deterministischen Code testete. In diesem Beitrag geht es um das Framework, das genau das verhindert, und um die Engineering-Entscheidungen, die es in einer echten CI-Pipeline zum Laufen bringen.

Warum klassisches Testen bei Agenten scheitert

Ein herkömmlicher Unit-Test beantwortet eine binäre Frage: Ist genau diese Ausgabe erschienen? Agentische Features scheitern an dieser Frage aus drei voneinander unabhängigen Gründen, und du musst alle drei verstehen, bevor du drumherum entwerfen kannst.

Der erste ist Nicht-Determinismus im Modell selbst. Selbst bei Temperatur null kann derselbe Prompt über Modellversionen, über Anbieter und manchmal über einzelne Aufrufe hinweg unterschiedliche Tokens liefern, weil Fließkomma-Nicht-Determinismus und anbieterseitiges Batching durchsickern. Du kannst die Ausgabe nicht so festnageln, wie du einen Hash festnagelst.

Der zweite ist legitime Variation. "Der Kunde möchte eine Rückerstattung und ist frustriert" und "Rückerstattung angefragt; Kunde ist unzufrieden mit der Verzögerung" sind beide korrekte Zusammenfassungen. Ein String-Vergleich markiert die zweite als Fehler, obwohl ein Mensch sie durchgehen lassen würde. Deine Test-Harness muss Bedeutung beurteilen, nicht Zeichen.

Der dritte, und der, der am härtesten zubeißt, sind mehrstufige Trajektorien. Ein echter Agent erzeugt nicht eine Ausgabe. Er plant, ruft Tools auf, liest Ergebnisse und entscheidet, was als Nächstes zu tun ist. Ein Agent kann über einen kaputten Pfad, der dieses Mal zufällig funktioniert und nächste Woche fehlschlägt, zur richtigen Endantwort gelangen, oder über eine Argumentation, die bei jedem einzelnen Schritt gut aussah, zu einer falschen Antwort kommen. Du testest keinen Wert; du testest einen Prozess, der sich über mehrere Entscheidungen entfaltet.

Deshalb ist "es hat funktioniert, als ich es ausprobiert habe" kein Beleg für irgendetwas. Ein einzelner manueller Lauf sampelt einen Pfad durch eine Wahrscheinlichkeitsverteilung. Agent-Evaluation existiert, um diese Verteilung systematisch zu sampeln und dir zu sagen, in welchem Anteil der Fälle das Feature das Richtige tut.

Die Anatomie eines Agent-Evaluation-Frameworks

Nimmt man das Tooling weg, hat jedes ernstzunehmende Evaluation-Setup dieselben vier Bausteine. Bekommst du diese richtig hin, spielt die konkrete Bibliothek, für die du dich entscheidest, kaum eine Rolle.

Ein Evaluation-Datensatz. Das ist eine kuratierte Menge von Eingaben, gepaart mit dem, wie ein gutes Ergebnis aussieht. Nicht zwingend ein exakter erwarteter String, oft eine Rubrik oder eine Menge zwingend erforderlicher Eigenschaften. Der Datensatz ist das wertvollste Asset, das du aufbauen wirst, und er ist mehr wert als jedes Framework, weil er deine tatsächliche Definition von korrektem Verhalten kodiert. Beginne ihn mit zwanzig bis fünfzig handgeschriebenen Fällen, die deine Happy Paths abdecken, und lasse ihn dann aus der Produktion wachsen. Jedes Mal, wenn der Agent bei einem echten Nutzer scheitert, wird diese Interaktion zu einem neuen Testfall. Innerhalb weniger Monate spiegelt dein Datensatz die unordentliche Realität deiner Nutzer wider statt deine optimistischen Annahmen.

Ein Runner. Dieser führt den Agenten gegen jeden Fall im Datensatz aus und erfasst nicht nur die Endausgabe, sondern die vollständige Trajektorie: welche Tools in welcher Reihenfolge mit welchen Argumenten aufgerufen wurden und was zurückkam. Du brauchst die Trajektorie, weil zwei Läufe mit identischen Endantworten wild unterschiedliche Zuverlässigkeit haben können, und du willst den Agenten erwischen, der einfach Glück hatte.

Scorer. Diese verwandeln jeden Lauf in eine Messung. Manche sind deterministisch und günstig: Hat der Agent das refund-Tool mit einer gültigen Bestell-ID aufgerufen, ließ sich die Ausgabe als das geforderte JSON-Schema parsen, blieb sie unter dem Latenzbudget. Manche sind semantisch und brauchen einen LLM-as-Judge, auf den ich zurückkomme, weil er sowohl der mächtigste als auch der am häufigsten missbrauchte Teil des Stacks ist. Die Kombination zählt: Deterministische Scorer geben dir harte Garantien über Struktur und Sicherheit, während semantische Scorer die unscharfe Frage behandeln, ob die Antwort tatsächlich gut ist.

Eine Reporting- und Gating-Schicht. Diese aggregiert die Scores über den Datensatz zu Zahlen, mit denen du handeln kannst, verfolgt sie über die Zeit und entscheidet, ob eine Änderung ausgeliefert werden darf. Ohne Gating ist Evaluation ein Dashboard, das niemand ansieht. Mit ihm wird Evaluation zu einem echten Release-Gate, genauso wie ein fehlschlagender Unit-Test einen Merge blockiert.

Wenn du KI-Features in ein bestehendes Produkt einbaust und ein zweites Paar Augen darauf willst, wie diese Teile zu deinem Stack passen, ist das genau die Architekturarbeit, die unser Team im Rahmen von Individualsoftware-Entwicklung leistet.

Metriken, die tatsächlich etwas bedeuten

Die Versuchung ist, Agentenqualität auf eine einzige Genauigkeitszahl zu reduzieren. Widerstehe ihr. Nicht-deterministische Systeme brauchen ein kleines Panel von Metriken, von denen jede eine andere Frage beantwortet.

Task Success Rate ist die Schlagzeile: Welcher Anteil der Läufe erreicht über deinen Datensatz hinweg das beabsichtigte Ergebnis gemäß deiner Rubrik. Weil das System nicht-deterministisch ist, solltest du jeden Fall mehrfach ausführen, fünf ist ein vernünftiger Ausgangspunkt, und die Erfolgsrate pro Fall berichten. Ein Fall, der drei von fünf Malen besteht, ist kein bestehender Fall; er ist ein Münzwurf, den du noch nicht bemerkt hast.

Trajektorien-Validität misst, ob der Agent einen soliden Pfad genommen hat, unabhängig von der Endantwort. Hat er Tools aufgerufen, die er aufrufen durfte, in einer sinnvollen Reihenfolge, ohne redundante oder gefährliche Schritte. Du kannst eine hohe Task Success Rate haben, die auf fragilen Trajektorien sitzt, und in dieser Lücke wohnen künftige Incidents.

Konsistenz ist die Metrik, die Teams vergessen. Führe dieselbe Eingabe mehrfach aus und miss, wie stark die Ergebnisse variieren. Ein Feature, das im Durchschnitt korrekt ist, aber für dieselbe Eingabe zwischen drei verschiedenen Entscheidungen schwankt, erodiert das Nutzervertrauen schneller als eines, das etwas ungenauer, aber stabil ist. Für alles, was Geld oder Compliance berührt, kann niedrige Varianz wichtiger sein als Spitzengenauigkeit.

Kosten und Latenz pro Task gehören ebenfalls in den Eval-Report, denn ein Agent, der nach einer Prompt-Änderung leise doppelt so viele Tool-Aufrufe macht, ist eine Regression, selbst wenn die Genauigkeit hält. Diese neben der Qualität zu verfolgen hält dich davon ab, einen "besseren" Agenten auszuliefern, der deine Inferenzrechnung verdoppelt. Die Kostenseite davon haben wir in unserem Beitrag über LLM-Kostenkontrolle: Token-Budgets, Caching und Graceful Fallbacks beleuchtet.

LLM-as-Judge: mächtig und leicht falsch gemacht

Für semantisches Scoring ist das dominante Muster, ein zweites LLM zu verwenden, um die Ausgabe des ersten gegen eine Rubrik zu bewerten. Gut gemacht, skaliert das menschliches Urteil auf Tausende von Fällen. Schlecht gemacht, gibt es dir ein selbstbewusst grünes Dashboard, das nichts bedeutet.

Drei Regeln halten es ehrlich. Erstens: Gib dem Judge eine konkrete Rubrik, kein Bauchgefühl. "Ist das eine gute Zusammenfassung?" erzeugt Rauschen. "Nennt die Zusammenfassung den Erstattungsbetrag, den Grund für die Anfrage und die vom Kunden genannte Frist? Vergib einen Punkt für jedes" erzeugt eine Messung, über die du nachdenken kannst. Zerlege Qualität in prüfbare Eigenschaften.

Zweitens: Validiere den Judge gegen Menschen, bevor du ihm vertraust. Nimm fünfzig Fälle, lass eine Person sie bewerten, lass den Judge sie bewerten und miss die Übereinstimmung. Wenn der Judge bei einem Viertel der Fälle mit deinem Team uneins ist, sind seine Zahlen noch nicht vertrauenswürdig und die Rubrik muss geschärft werden. Dieser Kalibrierungsschritt ist nicht verhandelbar und er ist der eine, den fast alle überspringen.

Drittens: Achte auf bekannte Judge-Verzerrungen. LLM-Judges neigen dazu, längere Antworten zu bevorzugen, Ausgaben derselben Modellfamilie zu bevorzugen, und lassen sich von selbstbewusstem Ton über Korrektheit stellen. Wo es zählt, randomisiere die Position, entferne identifizierenden Stil und halte einen deterministischen Check neben dem Judge, damit ein einzelner voreingenommener Bewerter keine strukturell kaputte Ausgabe durchwinken kann. Die Guardrail-Muster in unserem Beitrag über KI-Sicherheitsnetze passen natürlich zum Judge-basierten Scoring, weil dieselben Checks, die Nutzer in der Produktion schützen, als Scorer in der Evaluation laufen können.

Evaluation in deine Pipeline einbinden

Eine Evaluation-Suite, die nur läuft, wenn sich jemand daran erinnert, sie auszuführen, ist sehr wenig wert. Das Ziel ist, Agent-Evaluation zu einem normalen Teil davon zu machen, wie Änderungen ausgeliefert werden, mit denselben Reflexen, die du bereits rund um Unit-Tests hast.

Führe eine schnelle Teilmenge bei jedem Pull Request aus. Vollständige Evaluation über einen großen Datensatz mit mehreren Wiederholungen pro Fall ist zu langsam und zu teuer für jeden Commit, aber ein kuratiertes Smoke-Set aus zehn bis zwanzig kritischen Fällen kann in ein paar Minuten laufen und die offensichtlichen Regressionen abfangen. Behandle einen Rückgang der Erfolgsrate in dieser Teilmenge so, wie du einen fehlschlagenden Test behandelst: Er blockiert den Merge.

Führe die volle Suite nächtlich und vor jedem Release aus und speichere die Ergebnisse, damit du Trends sehen kannst. Beim ersten Mal, wenn jemand einen Prompt anpasst, um eine einzelne Kundenbeschwerde zu beheben, und der nächtliche Lauf zeigt, wie die Task Success Rate anderswo leise um zwei Punkte fällt, zahlt sich die Investition aus. Prompt-Änderungen haben nicht-lokale Effekte, und nur eine ständige Evaluation-Suite macht diese Effekte sichtbar.

Entscheidend ist: Gate auf Regression, nicht auf einen perfekten Score. Agentische Features erreichen selten hundert Prozent, und dieser Zahl hinterherzujagen verschwendet Aufwand. Das nützliche Gate ist relativ: Diese Änderung darf die Task Success Rate nicht unter die aktuelle Baseline minus einer kleinen Toleranz senken und darf Kosten oder Latenz nicht über das Budget hinaus erhöhen. Das verwandelt Evaluation von einer Vanity-Metrik in einen Vertrag darüber, die Dinge nicht schlechter zu machen, was genau das ist, was ein Release-Gate durchsetzen sollte. Um diese Trends zu sehen, brauchst du auch Produktions-Telemetrie, die zurückfließt, und genau da verbinden sich die Praktiken aus LLM-Observability mit kleinem Budget direkt mit deinen Offline-Evals: Produktionsfehler werden zu den Testfällen von morgen.

Fang kleiner an, als du denkst

Der häufigste Grund, warum Teams nie Agent-Evaluation aufbauen, ist, dass sie sich eine große Plattform mit einem Labeling-Team und einer maßgeschneiderten Harness vorstellen. Das brauchst du nicht, um anzufangen, und darauf zu warten ist der Weg, auf dem Features ungetestet ausgeliefert werden.

Beginne mit einer JSON-Datei mit zwanzig Fällen und einem Skript, das deinen Agenten gegen jeden ausführt, zwei oder drei deterministische Checks plus einen einzelnen rubrikbasierten Judge anwendet und eine Erfolgsrate ausgibt. Führe es diese Woche vor jedem Release von Hand aus. Füge es nächste Woche zu CI hinzu. Lass den Datensatz jede Woche danach aus echten Fehlern wachsen. Innerhalb eines Quartals wirst du etwas haben, das dir wirklich sagt, ob ein KI-Feature bereit ist, und du wirst dich fragen, wie du je nicht-deterministischen Code auf einen einzigen manuellen Versuch hin ausgeliefert hast.

Die Teams, die mit agentischen Features gewinnen, sind nicht die mit den cleversten Prompts. Es sind die, die am Freitag einen Prompt ändern können und anhand der Zahlen wissen, nicht anhand des Gefühls, ob sie das Produkt besser oder schlechter gemacht haben.

Wenn du kurz davor bist, ein agentisches Feature auszuliefern, und Zuversicht willst, dass es sich beim zwanzigsten Kunden genauso verhält wie beim ersten, helfen wir Teams, Evaluation-Harnesses zu entwerfen und KI-Features vor dem Release zu auditieren, als Teil unserer Code-Quality-Consulting-Arbeit. Erreiche uns unter hello@wolf-tech.io oder auf wolf-tech.io, und bring das Feature mit, bei dem du dir am unsichersten bist.