Wie gut ist dein Agent wirklich?

Im letzten Post haben wir Agenten auf mehrere Schultern verteilt — Handoff, Supervisor, Swarm. Aber egal ob ein Agent oder zehn: Woher weiß man, ob sie gut arbeiten?

Bei einem klassischen ML-Modell gibt es klare Metriken: Accuracy, F1-Score, AUC. Man hat ein Testset, lässt das Modell laufen und bekommt eine Zahl. Besser oder schlechter — eindeutig.

Bei Agenten ist das anders. Das LLM als zentrale Komponente ist nicht-deterministisch — derselbe Input kann zu unterschiedlichen Pfaden führen. Die Anzahl der Schritte variiert. Und “richtig” ist oft eine Einschätzung, keine Ja/Nein-Entscheidung. War die Diagnose vollständig? Waren die Maßnahmen umsetzbar? Hat der Agent halluziniert?

Trotzdem muss man messen. Ohne systematische Evaluation ist jede Prompt-Änderung ein Blindflug.

Vier Dimensionen

Keine einzelne Metrik bildet die Qualität eines Agenten vollständig ab. Am Beispiel eines DevOps Incident-Response-Agenten aus dem zugehörigen Repository messen wir auf vier Ebenen:

Task Success prüft, ob der Agent die Kernaufgabe gelöst hat. Im konkreten Beispiel: Hat er die richtige Fehlerkategorie erkannt (OOM, Timeout, Unknown)? Das ist ein harter, regelbasierter Check — kein Spielraum für Interpretation.

Tool Selection prüft, ob der Agent die richtigen Werkzeuge genutzt hat. Taucht das erwartete Runbook-Keyword im Report auf? Auch regelbasiert, auch deterministisch.

Response Quality bewertet das, was Regeln nicht fassen: Ist die Diagnose inhaltlich korrekt? Sind die Maßnahmen umsetzbar? Fehlen Halluzinationen? Hier kommt ein LLM-as-Judge zum Einsatz — ein zweites LLM, das den Output auf einer Skala von 1 bis 5 bewertet.

Efficiency misst den Ressourcenverbrauch: Wie viele LLM-Calls hat der Agent gebraucht? Wie viele Schritte? Das ist besonders bei Multi-Agent-Systemen relevant, wo das Ausführungsprofil sich deutlich von einem Single-Agent unterscheidet.

Die ersten zwei Dimensionen sind deterministisch und CI/CD-tauglich. Die dritte nicht. Die vierte ist deterministisch, aber kein Qualitätsmaß — ein Agent kann effizient und trotzdem falsch sein.

LLM-as-Judge: Nützlich, aber nicht als Gate

Der LLM-as-Judge ist das mächtigste Werkzeug in der Evaluation — und gleichzeitig das unzuverlässigste.

Er kann bewerten, was Regex nicht kann: inhaltliche Korrektheit, Vollständigkeit, Umsetzbarkeit. Kein regelbasierter Check erkennt, ob eine vorgeschlagene Maßnahme in der Praxis funktionieren würde.

Aber: Der Judge ist selbst ein LLM. Und damit nicht-deterministisch. Derselbe Output kann heute 4/5 und morgen 3/5 bekommen. Das macht ihn ungeeignet als hartes Gate in einer CI/CD-Pipeline. Man würde bei jedem zweiten Run einen falschen Alarm bekommen.

In der Praxis trennen wir deshalb klar: Regelbasierte Metriken als harte Gates — sie entscheiden, ob ein Build durchkommt. LLM-as-Judge als Soft-Metrik zur Beobachtung — er zeigt Trends und Auffälligkeiten, löst aber keinen automatischen Abbruch aus.

Regression-Testing: Die Baseline als Referenz

Eine einzelne Evaluation sagt wenig. Spannend wird es im Vergleich: Ist der Agent nach einer Prompt-Änderung besser oder schlechter geworden?

Dafür speichern wir die Ergebnisse eines bekannt-guten Agenten als Baseline. Jeder folgende Lauf wird gegen diese Baseline verglichen. Sinkt ein Score um mehr als einen Punkt, schlägt das System Alarm.

Das klingt einfach, hat aber einen Haken.

Eval-Versioning: Eines der schwierigsten Probleme

Eine Baseline ist nur dann mit einer neuen Evaluation vergleichbar, wenn die Evaluations-Infrastruktur identisch ist. Konkret: Judge-Modell, Judge-Prompt und Testset müssen übereinstimmen. Die Agent-Version ist die Variable, die sich ändert — sie ist das, was getestet wird.

Ändert sich das Judge-Modell — etwa durch ein Provider-Update — sind alte Scores nicht mehr vergleichbar. Ein neues Modell bewertet strenger oder milder, und plötzlich sieht es so aus, als wäre der Agent schlechter geworden, obwohl sich nur der Maßstab verändert hat.

Dasselbe gilt für den Judge-Prompt: Eine kleine Umformulierung der Bewertungskriterien kann die Scores verschieben. Und wenn sich das Testset ändert — neue Fälle, entfernte Fälle — ist der Vergleich ohnehin hinfällig.

Ohne explizites Tracking dieser drei Dimensionen (Judge-Modell, Prompt-Hash, Testset-Hash) ist Regression-Testing nicht vertrauenswürdig. Man vergleicht Äpfel mit Birnen und merkt es nicht. Änderungen an diesen drei Dimensionen müssen kontrolliert erfolgen und führen, wenn erfolgreich, zu einer neuen Baseline.

Metriken müssen zum Pattern passen

Eine Erkenntnis aus der Multi-Agent-Phase, die hier relevant wird: Nicht jede Metrik funktioniert für jedes Agent-Pattern.

Ein Single-Agent arbeitet über die Message-History — er schreibt keine expliziten State-Felder. Eine Metrik, die prüft ob error_category im State steht, misst dann nicht die Qualität des Agenten, sondern die Inkompatibilität der Metrik mit dem Pattern.

Der LLM-as-Judge ist hier die ehrlichere Bewertung, weil er den Output inhaltlich bewertet — unabhängig davon, wie der Agent intern arbeitet. Regelbasierte Metriken funktionieren am besten bei Agenten mit explizitem State (Handoff, Supervisor). Für Black-Box-Pattern braucht man andere Maße.

Testset-Erstellung: Einfacher als gedacht

Ein häufiger Einwand gegen systematische Evaluation: “Wir haben keine gelabelten Daten.” Bei Agenten braucht man auch keine tausend Beispiele. 20 handgeschriebene Testfälle — mit erwarteter Kategorie, erwarteten Keywords und einer Beschreibung des Szenarios — reichen für einen ersten, aussagekräftigen Evaluation-Durchlauf.

Die Schwierigkeit liegt nicht in der Menge, sondern in der Abdeckung: Einfache Fälle, Edge Cases, mehrdeutige Situationen. Ein Testset mit nur Happy-Path-Fällen ist nicht ausreichend — erst die schwierigen Fälle zeigen, wo der Agent Schwächen hat.

Ausblick

Evaluation beantwortet die Frage “wie gut ist der Agent?” — aber sie verhindert keinen Schaden. Ein Agent, der eine falsche Diagnose stellt, ist ein Qualitätsproblem. Ein Agent, der auf eine Prompt-Injection hereinfällt und destruktive Befehle ausführt, ist ein Sicherheitsproblem. Wie man Agenten absichert, ist Thema des nächsten Posts.

Code und Details: Das vollständige Evaluations-Framework — 20 Testfälle, vier Metrik-Dimensionen, LLM-as-Judge, Regression-Testing mit Baseline — ist auf GitHub dokumentiert: → agentic-ai / Phase 4, Block 2: Evaluation

Ich bin ML Engineer mit Fokus auf Self-Hosted AI und Datensouveränität. Ich helfe Unternehmen im DACH-Raum, ML- und AI-Systeme auf eigener Infrastruktur zu betreiben. Offen für Austausch und spannende Projekte — schreib mir auf LinkedIn.