Agent Evaluations: So messen Sie die Qualität Ihrer KI-Agenten

KI-Agenten liefern Resultate im Minutentakt. Aber woher wissen Sie, ob die Qualität stimmt? Vier Methoden, mit denen Sie die Arbeit Ihrer Agenten messbar machen: automatisierte Metriken, LLM as Judge, Human Evaluation und Adaptive Rubrics.

Ink-Illustration: Roboter mit Schraubenschlüssel übergibt ein Dokument, das von einer roten Lupe geprüft wird, daneben eine Messanzeige mit Häkchen

KI-Agenten erledigen heute ganze Arbeitsschritte selbstständig. Sie beantworten Support-Anfragen oder extrahieren Daten aus Dokumenten. Die entscheidende Frage dabei ist selten, ob ein Agent läuft. Sondern: Ist sein Resultat gut genug? Das beantworten Agent Evaluations, kurz Evals. An einem Vortrag von Google am AI for Good Global Summit in Genf wurden drei Grundmethoden plus eine neuere Erweiterung vorgestellt. Dieser Beitrag stellt alle vier vor, mit je einem Beispiel aus der Praxis.

Inhalt

Warum Sie Agenten nicht einfach nur laufen lassen sollten

Ein Agent ist kein klassisches Programm. Er trifft unterwegs eigene Entscheidungen: welches Tool er aufruft, in welcher Reihenfolge, mit welchen Parametern. Zwei Läufe mit demselben Auftrag können unterschiedlich ausgehen. Anthropic bringt es in einem lesenswerten Engineering-Beitrag auf den Punkt: Dieselben Eigenschaften, die Agenten nützlich machen (Autonomie, Flexibilität), machen sie auch schwer zu testen.

Ohne Evals bleibt Ihnen nur der "Vibe Check": Man schaut sich ein paar Antworten an und findet sie gut. Das reicht für ein Experiment, aber nicht für den Betrieb. Eine Evaluation macht daraus einen messbaren Prozess: Sie geben dem Agenten definierte Aufgaben, prüfen die Resultate gegen Kriterien und erhalten eine Zahl, die Sie über Versionen hinweg vergleichen können. Google beschreibt diesen Wandel vom Vibe Check zur kontinuierlichen Evaluation ausführlich im eigenen Entwickler-Blog.

Wichtig zu wissen: Bewertet wird nicht nur die finale Antwort (Response), sondern auch der Weg dorthin, die sogenannte Trajectory. Also die Abfolge der Tool-Aufrufe und Zwischenschritte. Ein Agent kann zufällig das richtige Resultat liefern und trotzdem einen gefährlichen Weg genommen haben.

Methode 1: Automatisierte Metriken

Die einfachste Form: Eine Funktion prüft das Resultat des Agenten programmatisch gegen erwartete Werte. Daraus entstehen Kennzahlen wie Task Success Rate (wie oft wurde die Aufgabe gelöst), Error Rate, Effizienz (wie viele Schritte brauchte der Agent) oder Precision und Recall.

Die Stärke dieser Methode: Sie ist schnell, günstig und deterministisch. Dasselbe Resultat ergibt immer denselben Score. Damit eignet sie sich für die CI/CD-Pipeline, ähnlich wie Unit Tests. Das Agent Development Kit von Google prüft so zum Beispiel die Tool-Trajectory: Hat der Agent die richtigen Tools mit den richtigen Argumenten aufgerufen?

Die Schwäche: Automatisierte Metriken erfassen nur, was sich exakt prüfen lässt. Ob ein Text verständlich oder freundlich ist, sehen sie nicht.

Beispiel: Ein Agent extrahiert aus eingehenden Rechnungs-PDFs den Betrag, die IBAN und das Fälligkeitsdatum. Sie legen 100 Test-Rechnungen mit bekannten Soll-Werten an. Nach jedem Lauf vergleicht ein Skript die extrahierten Werte mit den Soll-Werten. Stimmen bei 96 Rechnungen alle drei Felder, liegt die Task Success Rate bei 96 Prozent. Fällt sie nach einer Änderung auf 88 Prozent, wissen Sie sofort, dass etwas kaputt ging.

Methode 2: LLM as Judge

Viele Agenten-Aufgaben haben kein eindeutig richtiges Resultat. Eine Zusammenfassung, eine Support-Antwort oder ein Beratungstext lassen sich nicht mit einem Skript prüfen. Hier kommt ein zweites Sprachmodell als Richter zum Einsatz: Es erhält die Antwort des Agenten (und bei Bedarf die Trajectory), dazu Bewertungskriterien wie Task Completion, Effizienz oder Sicherheit, und vergibt pro Kriterium eine Bewertung.

Das skaliert gut: Tausende Antworten lassen sich über Nacht bewerten. Studien und Praxiserfahrungen zeigen, dass gute LLM-Judges in rund 85 Prozent der Fälle mit menschlichen Prüfern übereinstimmen, mehr als zwei Menschen untereinander. Aber: LLM-Judges haben bekannte Schwächen, etwa eine Vorliebe für lange Antworten (Verbosity Bias) oder für Antworten des eigenen Modells. Die Kriterien müssen deshalb präzis formuliert und regelmässig mit menschlichen Stichproben abgeglichen werden.

Beispiel: Ein Agent schreibt Produktbeschreibungen für einen Webshop. Ein Judge-Modell bewertet jede Beschreibung nach drei Kriterien: Sind alle Produktmerkmale aus dem Quelldatensatz enthalten? Stimmt die Tonalität mit dem Styleguide überein? Ist der Text frei von erfundenen Angaben? Jedes Kriterium erhält eine Note von 1 bis 5. Beschreibungen unter einem Schwellenwert gehen zurück in die Schleife oder zu einem Menschen.

Methode 3: Human Evaluation

Der Goldstandard bleibt der Mensch. Fachpersonen prüfen die Antworten und Trajectories des Agenten anhand definierter Kriterien. Menschen erkennen, was Metriken und Judge-Modelle übersehen. Etwa einen fachlich subtilen Fehler in einer Vertragsauskunft. Oder einen Ton, der bei einem verärgerten Kunden gar nicht gut ankommt.

Der Preis dafür: Human Evaluation ist langsam und teuer. Niemand prüft täglich 5000 Agent-Antworten von Hand. In der Praxis dient sie deshalb als Stichprobe und als Kalibrierung für die automatisierten Methoden. Die menschlichen Urteile definieren, was "gut" überhaupt heisst, und die Judge-Prompts werden daran ausgerichtet.

Beispiel: Ein Support-Agent beantwortet Kundenanfragen zu Abos und Rechnungen. Jede Woche zieht das Team 20 zufällige Konversationen und bewertet sie nach einem kurzen Kriterienkatalog: Problem gelöst? Ton angemessen? Eskalation nötig gewesen? Die Resultate fliessen in zwei Dinge: in die Verbesserung des Agenten und in die Schärfung des LLM-Judges, der die restlichen 98 Prozent der Konversationen automatisch bewertet.

Die Erweiterung: Adaptive Rubrics

Die drei Grundmethoden haben ein gemeinsames Problem: Feste Kriterien passen nie auf jeden Fall. "Sei präzis und vollständig" ist für eine Terminbuchung etwas anderes als für eine Reklamation. Adaptive Rubrics lösen das, indem die Prüfkriterien pro Anfrage neu erzeugt werden.

Das Prinzip besteht aus zwei Teilen. Ein Rubrics Generator liest die konkrete Anfrage und die Fähigkeiten des Agenten und leitet daraus einen individuellen Prüfkatalog ab. Ein Rubrics Validator prüft danach die Trajectory des Agenten gegen diesen Katalog und liefert pro Punkt ein Pass oder Fail, inklusive Begründung. Google bietet diesen Ansatz mittlerweile als Adaptive Rubrics in Vertex AI an.

Beispiel (direkt aus dem Google-Vortrag): Ein Buchungs-Agent soll ein Meeting organisieren. Der Nutzer verlangt zuerst 30 Minuten, korrigiert dann aber auf 45 Minuten. Der Rubrics Generator erzeugt daraus vier Prüfpunkte: Wurde die Verfügbarkeit geprüft? Wurde der Kalendereintrag erstellt? Beträgt die Dauer 45 Minuten? Beginnt der Termin morgen um 15 Uhr? Der Validator prüft die Trajectory und meldet 3 von 4: Der Agent hat den Termin korrekt angelegt, aber die Dauer bei 30 Minuten belassen. Die Korrektur des Nutzers ging verloren. Ein statischer Kriterienkatalog hätte diesen Fehler kaum erwischt, weil "Dauer muss 45 Minuten sein" nur für genau diese Konversation gilt.

Wann Evals unverzichtbar sind

Wie viel Evaluation braucht Ihr Agent? Die ehrliche Antwort: Es hängt vom Einsatz ab.

Am wichtigsten sind Evals bei vollautomatisierten Agenten. Sobald kein Mensch mehr jedes Resultat prüft, bevor es wirkt (eine E-Mail rausgeht, eine Buchung erfolgt, ein Datensatz ändert), sind Evals Ihr einziger Qualitätsnachweis. Und je kritischer der Anwendungsfall, desto wichtiger werden sie: Ein Agent, der interne Meeting-Notizen zusammenfasst, verzeiht Fehler. Ein Agent, der Kundenverträge beantwortet oder Zahlungen auslöst, nicht. Wer Agenten in geschäftskritische Abläufe integriert, kommt an Evals nicht vorbei.

Gleichzeitig ist das Feld jung und entwickelt sich schnell. Hundertprozentige Eval-Abdeckung haben heute die wenigsten produktiven Agenten, das zeigt auch die Readiness-Checkliste von LangChain. Das ist kein Grund, gar nicht anzufangen. Im Gegenteil.

Denn auch bei einfachen Workflows zahlen sich Evals mehrfach aus:

  • Neue Modelle testen: Erscheint ein neues Sprachmodell, lassen Sie Ihre Eval-Suite einmal durchlaufen und wissen innert Stunden, ob der Wechsel die Qualität hebt oder senkt.
  • Regressionen erkennen: Fällt der Score nach einer Anpassung am Prompt oder an einem Tool, sehen Sie es sofort, nicht erst wenn sich ein Kunde beschwert.
  • Gezielt verbessern: Eval-Resultate zeigen, wo der Agent scheitert. Dort schärfen Sie den Kontext und die Instruktionen nach, statt im Blindflug zu optimieren.

Unsere Empfehlung: Starten Sie klein. Zehn realistische Testfälle mit automatisierten Checks, dazu ein LLM-Judge für die weichen Kriterien und eine wöchentliche menschliche Stichprobe. Das ist an einem Nachmittag aufgesetzt und verändert, wie Sie über Ihren Agenten sprechen: nicht mehr "fühlt sich gut an", sondern "94 Prozent Erfolgsquote, Tendenz steigend".

Referenzen

Lassen Sie uns darüber sprechen

Sie planen, einen KI-Agenten in Ihre Abläufe zu integrieren, und möchten dessen Qualität von Anfang an messbar machen? Wir beraten Sie gerne. Das erste Gespräch ist immer kostenlos.

Jetzt Kontakt aufnehmen

Blog ·

Lukas Fischer

Lukas Fischer

CEO/Gründer, Solution Engineer, Consulting/Strategy

Haben Sie Fragen zu diesem Thema?

Ich freue mich auf Ihre Kontaktaufnahme und berate Sie gerne persönlich.

Später lesen

Keine Zeit? Senden Sie sich den Artikel an die eigene Inbox.

Newsletter

Bleiben Sie auf dem Laufenden.

Fachbeiträge zu Digital, KI und Engineering. Abmeldung jederzeit möglich.