AI Operations · 12 Min.
AI-Agent Evals: Wie du Testdaten baust, die echte Agentenfehler sichtbar machen
Agenten werden nicht durch Hoffnung produktionsreif. Sie werden produktionsreif, wenn ihre Fehler reproduzierbar messbar sind.
SYSTEMS Grafik zu AI Agent Evals: Trace -> Metric -> Decision. Fokus: Wie Unternehmen Testdaten und Evals fuer produktive KI-Agenten aufbauen.
Kurzfassung
Agent-Evals muessen Prozessverhalten pruefen, nicht nur finale Texte. Gute Testdaten enthalten Normalfaelle, Grenzfaelle, Missbrauch und echte historische Beispiele. Evals sind die Grundlage fuer Rechteerweiterung und Regression.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Warum Antwort-Evals nicht reichen Viele LLM-Tests pruefen, ob eine Antwort gut klingt. Bei Agenten ist das zu wenig. Ein Agent kann eine gute Antwort liefern und trotzdem das falsche Tool genutzt, zu viel Kontext gelesen oder eine riskante Aktion vorbereitet haben.
Agent-Evals muessen den Lauf bewerten, nicht nur den letzten Absatz.
Stand Mai 2026: Evals wandern in den Agentenlauf OpenAI empfiehlt fuer Agenten zuerst Traces zum Debugging und dann Datasets plus Eval Runs fuer wiederholbare Benchmarks. Trace-Grading bewertet den gesamten Lauf: Entscheidungen, Tool Calls, Reasoning-Schritte, Handoffs und Guardrails. Google Vertex AI beschreibt Agent-Evals mit Metriken wie finaler Antwortqualitaet, Tool-Use-Qualitaet und Halluzination. LangSmith trennt offline Evals fuer Regression und Benchmarks von Online-Evals fuer Monitoring im Betrieb.
Das ist der wichtige Unterschied: Ein Agent wird nicht nur getestet wie ein Textgenerator. Er wird getestet wie ein kleines Betriebssystem fuer Arbeit.
Das Golden Set Ein Golden Set ist eine kuratierte Sammlung von Faellen, die ein Agent stabil bearbeiten muss. Es sollte echte Arbeit abbilden:
Dieses Set wird nach jeder relevanten Aenderung erneut getestet.
Ein gutes Golden Set hat Versionen und Tags. Wenn Testfaelle laufend veraendert werden, weiss niemand mehr, ob der Agent besser wurde oder ob nur die Pruefung leichter geworden ist. LangSmith dokumentiert versionierte Datasets und Tags; OpenAI-Datasets und Prompts koennen fuer wiederholbare Eval Runs genutzt werden.
Praktisch braucht jeder Testfall:
haeufige Standardfaelle wertvolle Sonderfaelle bekannte Fehler aus der Vergangenheit unklare Inputs boesartige oder manipulative Inputs Input oder Nutzerauftrag. erlaubte Datenquellen. erwartete Tool-Wahl oder verbotene Tools. Ground Truth oder Bewertungskriterium. Risiko- und Datenklasse. erwartetes Eskalationsverhalten. Kosten- oder Laufzeitgrenze. Was gemessen werden sollte Gute Evals pruefen:
So entstehen Metriken, die Betrieb und Risiko verbinden.
Wurde der richtige Kontext genutzt? Wurde das richtige Tool gewaehlt? Wurde eine sichere Grenze eingehalten? Wurde das Format korrekt ausgegeben? Wurde bei Unsicherheit eskaliert? War der Kostenrahmen angemessen? Drei Eval-Ebenen Ein produktiver Agent braucht mindestens drei Eval-Ebenen:
Die dritte Ebene wird oft vergessen. Ein Agent, der perfekte Texte schreibt, aber den Deal-Prozess verlangsamt, ist kein produktiver Agent.
Output-Eval: Ist die Antwort korrekt, vollstaendig und im richtigen Format? Trace-Eval: Wurden die richtigen Tools, Quellen, Handoffs und Guardrails genutzt? Business-Eval: Wurde der Prozess schneller, billiger, sicherer oder erfolgreicher? Tool-Use muss separat bewertet werden Tool-Use ist die Stelle, an der Agenten echten Schaden oder echten Wert erzeugen. Google dokumentiert dafuer eigene Tool-Call-Metriken: passt der Tool-Name, passen Parameter, sind Keys und Values korrekt? OpenAI Trace-Grading geht in dieselbe Richtung, weil Tool Calls und Guardrails Teil des bewerteten Runs sind.
Ein Tool-Use-Eval fragt:
Ohne diese Pruefung misst man nur die Erzaehlfaehigkeit des Agenten, nicht seine Betriebsfaehigkeit.
Haette der Agent ueberhaupt ein Tool nutzen sollen? Hat er das richtige Tool gewaehlt? Waren die Parameter minimal und korrekt? Wurden Rechte und Datenklassen eingehalten? Wurde ein riskanter Tool Call zur Freigabe gegeben? Wurde nach einem Tool-Fehler sinnvoll gestoppt oder korrigiert? Bewertungsarten: nicht alles muss ein LLM-Judge sein Anthropic empfiehlt, Bewertungsarten pragmatisch zu waehlen: Code-basierte Bewertung zuerst, wenn sie moeglich ist; menschliche Bewertung fuer schwer objektivierbare Qualitaet; LLM-basierte Bewertung mit klaren Rubrics, Beispielen und moeglichst stabilen Skalen.
Das ist auch fuer Unternehmen die richtige Reihenfolge:
LLM-as-Judge ist nuetzlich. Aber ohne Rubric und Stichprobenreview wird daraus nur eine zweite Meinung ohne Beweiskraft.
deterministische Checks fuer Format, JSON, Pflichtfelder, IDs. rule-based Checks fuer verbotene Tools, fehlende Quellen, Kostenlimits. menschliche Reviews fuer Grenzfaelle und Business-Urteil. LLM-Judge fuer skalierbare Qualitaetsbewertung mit Rubric. Evals brauchen Pflege Ein Eval-Set veraltet, wenn Produkte, Prozesse und Datenquellen sich aendern. Deshalb braucht es Ownership. Jemand muss neue Fehler aufnehmen, alte Faelle pruefen und Grenzwerte anpassen.
Evals sind kein Einmalprojekt. Sie sind Testinfrastruktur.
Regression Gates vor mehr Autonomie Jede Rechteerweiterung sollte an Eval-Gates gekoppelt sein. Ein Agent bekommt nicht deshalb Schreibrechte, weil die Demo gut war. Er bekommt sie, wenn die relevanten Testklassen stabil gruen sind.
Beispiel:
Die konkreten Schwellen haengen vom Prozess ab. Entscheidend ist, dass sie vor dem Rollout definiert werden.
95 Prozent Format- und Schema-Erfolg. 90 Prozent korrekte Tool-Wahl im Golden Set. 0 kritische Policy-Verletzungen. keine unerlaubten Datenzugriffe. Kosten pro erfolgreichem Lauf unter Schwelle. menschliche Ablehnungsquote unter Zielwert. Produktionsdaten als Eval-Flywheel Google Vertex AI und LangSmith zeigen beide den naechsten Schritt: Evals duerfen nicht nur aus manuell gebauten Testdateien kommen. Produktionslogs, menschliche Korrekturen, eskalierte Faelle und fehlgeschlagene Runs werden zu neuen Tests.
Das Flywheel sieht so aus:
1. Agent laeuft mit Tracing. 2. Fehler, Ablehnungen und Eskalationen werden markiert. 3. Gute Beispiele und Fehlerfaelle wandern in ein versioniertes Dataset. 4. Evals laufen vor jedem Prompt-, Tool- oder Modellwechsel. 5. Rechte werden nur erweitert, wenn Regressionen ausbleiben.
So wird Betrieb nicht zum Blindflug. Jeder reale Fehler verbessert die naechste Testgeneration.
Der SYSTEMS-Blick Wir bauen Evals vor der grossen Autonomie. Erst wenn der Agent in Testfaellen stabil arbeitet, bekommt er mehr Rechte.
Das macht Rollouts nicht langsamer. Es verhindert, dass Teams spaeter blind nach Fehlern suchen muessen.
