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 für produktive KI-Agenten aufbauen.
Kurzfassung
Agent-Evals müssen Prozessverhalten prüfen, nicht nur finale Texte. Gute Testdaten enthalten Normalfälle, Grenzfälle, Missbrauch und echte historische Beispiele. Evals sind die Grundlage für 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 prüfen, 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 müssen den Lauf bewerten, nicht nur den letzten Absatz.
Stand Mai 2026: Evals wandern in den Agentenlauf OpenAI empfiehlt für Agenten zuerst Traces zum Debugging und dann Datasets plus Eval Runs für 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 Antwortqualität, Tool-Use-Qualität und Halluzination. LangSmith trennt offline Evals für Regression und Benchmarks von Online-Evals für Monitoring im Betrieb.
Das ist der wichtige Unterschied: Ein Agent wird nicht nur getestet wie ein Textgenerator. Er wird getestet wie ein kleines Betriebssystem für Arbeit.
Das Golden Set Ein Golden Set ist eine kuratierte Sammlung von Fällen, die ein Agent stabil bearbeiten muss. Es sollte echte Arbeit abbilden:
Dieses Set wird nach jeder relevanten Änderung erneut getestet.
Ein gutes Golden Set hat Versionen und Tags. Wenn Testfälle laufend verändert werden, weiss niemand mehr, ob der Agent besser wurde oder ob nur die Prüfung leichter geworden ist. LangSmith dokumentiert versionierte Datasets und Tags; OpenAI-Datasets und Prompts können für wiederholbare Eval Runs genutzt werden.
Praktisch braucht jeder Testfall:
häufige Standardfälle wertvolle Sonderfälle bekannte Fehler aus der Vergangenheit unklare Inputs bösartige 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 prüfen:
So entstehen Metriken, die Betrieb und Risiko verbinden.
Wurde der richtige Kontext genutzt? Wurde das richtige Tool gewählt? 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, vollständig 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 dafür 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 Prüfung misst man nur die Erzählfähigkeit des Agenten, nicht seine Betriebsfähigkeit.
Hätte der Agent überhaupt ein Tool nutzen sollen? Hat er das richtige Tool gewählt? 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 wählen: Code-basierte Bewertung zuerst, wenn sie möglich ist; menschliche Bewertung für schwer objektivierbare Qualität; LLM-basierte Bewertung mit klaren Rubrics, Beispielen und möglichst stabilen Skalen.
Das ist auch für Unternehmen die richtige Reihenfolge:
LLM-as-Judge ist nützlich. Aber ohne Rubric und Stichprobenreview wird daraus nur eine zweite Meinung ohne Beweiskraft.
deterministische Checks für Format, JSON, Pflichtfelder, IDs. rule-based Checks für verbotene Tools, fehlende Quellen, Kostenlimits. menschliche Reviews für Grenzfälle und Business-Urteil. LLM-Judge für skalierbare Qualitätsbewertung mit Rubric. Evals brauchen Pflege Ein Eval-Set veraltet, wenn Produkte, Prozesse und Datenquellen sich ändern. Deshalb braucht es Ownership. Jemand muss neue Fehler aufnehmen, alte Fälle prüfen 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 grün sind.
Beispiel:
Die konkreten Schwellen hängen 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 nächsten Schritt: Evals dürfen nicht nur aus manuell gebauten Testdateien kommen. Produktionslogs, menschliche Korrekturen, eskalierte Fälle und fehlgeschlagene Runs werden zu neuen Tests.
Das Flywheel sieht so aus:
1. Agent läuft mit Tracing. 2. Fehler, Ablehnungen und Eskalationen werden markiert. 3. Gute Beispiele und Fehlerfälle 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 nächste Testgeneration.
Der SYSTEMS-Blick Wir bauen Evals vor der grossen Autonomie. Erst wenn der Agent in Testfällen stabil arbeitet, bekommt er mehr Rechte.
Das macht Rollouts nicht langsamer. Es verhindert, dass Teams später blind nach Fehlern suchen müssen.
