Warum reicht die finale Antwort nicht aus?
Stellen wir uns einen KI-Agenten im Kundenservice vor, dessen Aufgabe es ist, eine Rückerstattung zu bearbeiten.
Am Ende antwortet er korrekt:
„Ihre Rückerstattung wurde erfolgreich bearbeitet.“
Das bedeutet jedoch nicht automatisch, dass der Agent korrekt gearbeitet hat.
Vielleicht hat er die falsche Datenbank verwendet, mehrere unnötige API-Anfragen gestellt oder eine Rückerstattung durchgeführt, obwohl der Kunde gar nicht dazu berechtigt war.
Deshalb ist es wichtig, auch die Trajectory, also die einzelnen Schritte des Agenten während der Bearbeitung einer Aufgabe, zu bewerten. Google und andere Plattformen setzen zunehmend auf diesen Ansatz, weil ein korrektes Ergebnis auch durch einen fehlerhaften Prozess entstehen kann.
Was sollte man messen?
1. Hat der Agent das richtige Ergebnis erreicht?
Die grundlegende Frage lautet:
Hat der Agent die Aufgabe erfolgreich abgeschlossen?
Bei einem Coding-Agenten können wir Tests ausführen. Bei einem Buchungsagenten können wir überprüfen, ob die Reservierung mit den richtigen Daten erstellt wurde.
Der Task Success ist allerdings nur die erste Kennzahl.
2. Hat er die richtigen Tools verwendet?
Wenn ein Agent mit Datenbanken, APIs oder externen Tools arbeitet, sollten wir fragen:
- Hat er das richtige Tool ausgewählt?
- Hat er die richtigen Parameter verwendet?
- Hat er ein Tool unnötigerweise verwendet?
- Konnte er auf einen Tool-Fehler reagieren?
Ein Agent kann also zum richtigen Ergebnis kommen und trotzdem zehn unnötige API-Aufrufe machen.
3. War der Weg zum Ergebnis effizient?
Zwei Agenten können dieselbe Erfolgsquote von 90 % haben.
Der erste löst eine Aufgabe in drei Schritten.
Der zweite führt 25 API-Aufrufe durch, lädt dieselben Daten zweimal, macht einen Fehler, korrigiert ihn und erreicht schließlich das richtige Ergebnis.
In einer produktiven Umgebung sind diese beiden Agenten sehr unterschiedlich.
Deshalb lohnt es sich, die Trajectory Quality zu messen – etwa die Anzahl der Schritte, Tool-Aufrufe, Fehler oder unnötigen Wiederholungen.
4. Ist der Agent konsistent?
Ein KI-Agent löst dieselbe Aufgabe nicht unbedingt jedes Mal auf exakt dieselbe Weise.
Wenn wir ihn zehnmal testen und er neunmal erfolgreich ist, liegt die Erfolgsquote bei 90 %. Bei manchen Systemen kann dieser eine Fehler jedoch wesentlich schwerwiegender sein als die anderen.
Deshalb sollten Tests wiederholt und auch Reliability, Consistency und Robustness überwacht werden.
5. Was passiert, wenn der Agent scheitert?
Eine noch wichtigere Frage als „Wie oft scheitert der Agent?“ kann sein:
„Was macht er, wenn er scheitert?“
Eine API kann nicht verfügbar sein. Ein Nutzer kann unvollständige Informationen liefern. Zwei Quellen können widersprüchliche Daten enthalten.
Ein guter Agent sollte dann nicht einfach weitermachen und eine Antwort erfinden.
Er sollte fehlende Informationen abfragen, auf einen sicheren Fallback zurückgreifen oder die Aufgabe an einen Menschen übergeben können.
Sicherheit nicht vergessen
Je mehr Berechtigungen ein Agent besitzt, desto wichtiger wird es, auch sein Sicherheitsverhalten zu testen.
Ein Agent, der lediglich Fragen beantwortet, hat ein anderes Risikoprofil als ein Agent, der Datenbanken verändern, E-Mails versenden oder Finanztransaktionen durchführen kann.
Eine Evaluation kann daher auch folgende Bereiche abdecken:
- Prompt Injection,
- nicht autorisierte Aktionen,
- das Offenlegen sensibler Daten,
- das Überschreiten von Berechtigungen,
- falsche Tool-Nutzung,
- riskante Edge Cases.
Und wie viel kostet der Agent?
Die Erfolgsquote ist nicht der einzige relevante Faktor.
Stellen wir uns zwei Agenten vor:
Agent A
90 % Erfolgsquote
3 Sekunden pro Aufgabe
0,03 $ pro Aufgabe
Agent B
94 % Erfolgsquote
25 Sekunden pro Aufgabe
0,80 $ pro Aufgabe
Eine höhere Erfolgsquote bedeutet nicht automatisch, dass der zweite Agent die bessere Wahl ist.
Deshalb lohnt es sich, auch Folgendes zu messen:
- Latenz,
- Token-Nutzung,
- Anzahl der Tool-Aufrufe,
- Kosten pro Aufgabe,
- Fehlerquote,
- Anzahl der Übergaben an einen Menschen.
Welche Metriken relevant sind, hängt vom jeweiligen Produkt ab.
Wie erstellt man eine eigene Eval?
Man braucht nicht Hunderte von Tests, um anzufangen.
Ein praktischer Ansatz ist ein kleinerer Datensatz mit etwa 20–50 realen Aufgaben, der anschließend schrittweise um neue Szenarien und bekannte Fehler erweitert wird.
1. Definieren Sie, was Erfolg bedeutet
Nicht:
„Der Agent soll hilfreich sein.“
Sondern:
„Der Agent muss die Anfrage lösen, das richtige Tool verwenden, nicht autorisierte Aktionen vermeiden und bei fehlenden Informationen nachfragen.“
2. Testen Sie reale Szenarien
Der Datensatz sollte enthalten:
- typische Anwendungsfälle,
- Edge Cases,
- unvollständige Anfragen,
- ungültige Eingaben,
- Situationen, in denen der Agent bereits zuvor einen Fehler gemacht hat.
Gerade diese Szenarien zeigen häufig Probleme, die ein einfacher Happy-Path-Test nicht erkennt.
3. Verwenden Sie den richtigen Grader
Bei eindeutigen Ergebnissen kann ein codebasierter Test ausreichen.
Bei offeneren Antworten kann ein LLM-as-a-Judge sinnvoll sein.
Bei subjektiven oder sensiblen Fällen bleibt die menschliche Bewertung wichtig.
Ein LLM-Grader sollte jedoch nicht automatisch als objektive Wahrheit betrachtet werden. Seine Ergebnisse müssen kalibriert und regelmäßig mit menschlichen Bewertungen verglichen werden.
Beobachten Sie den Trace, nicht nur das Ergebnis
Eines der wichtigsten Konzepte bei der Evaluation von Agenten ist der Trace – ein Protokoll des gesamten Prozesses hinter einer Aufgabe.
Wenn ein Agent scheitert, kann der Trace zeigen, warum.
Statt:
„Der Agent hat die falsche Antwort gegeben.“
können wir feststellen:
„Der Agent hat das falsche Tool verwendet.“
Oder:
„Er hat die richtigen Daten abgerufen, sie aber falsch interpretiert.“
Oder:
„Die API hat einen Fehler zurückgegeben, aber der Agent hat mit nicht verifizierten Informationen weitergearbeitet.“
Dadurch können anschließend Prompts, Routing, Tools oder Guardrails gezielt verbessert werden.
Der größte Fehler? Nur den Happy Path testen
Ein Agent für Flugbuchungen kann problemlos folgende Anfrage bearbeiten:
„Finde mir einen Flug von Bratislava nach London am Freitag.“
In der Realität klingt eine Anfrage eher so:
„Ich möchte am Freitag fliegen, aber nicht vor 18 Uhr, ich möchte keinen Zwischenstopp und am Sonntag zurückfliegen.“
Und anschließend:
„Eigentlich kann ich auch am Samstag fliegen.“
Multi-Turn-Gespräche, sich ändernde Anforderungen, unvollständige Informationen und Tool-Fehler machen Agenten deutlich schwieriger zu evaluieren als klassische KI-Anwendungen.
Evaluation als Teil der Entwicklung
Evaluation ist besonders wertvoll, wenn sie zu einem festen Bestandteil des Entwicklungsprozesses wird.
Agent v1 → Eval Suite → Verbesserung → neuer Test → neues Modell → Eval Suite → Production Monitoring
Wenn eine neue Version die Erfolgsquote erhöht, aber gleichzeitig die Kosten verdoppelt, wissen wir es.
Wenn sie bessere Antworten liefert, aber die Sicherheitsmetriken verschlechtert, wissen wir es.
Und wenn ein neues Modell die Anzahl der Tool-Aufrufe reduziert, aber mehr Fehler bei Edge Cases macht, wissen wir das ebenfalls.
Evals sind damit keine einmalige QA-Aufgabe mehr, sondern werden Teil der kontinuierlichen Entwicklung.
Fazit
Ein KI-Agent ist nicht deshalb gut, weil er eine Aufgabe manchmal erfolgreich erledigen kann.
Wir müssen wissen:
- Wie oft ist er erfolgreich?
- Wie gut nutzt er seine Tools?
- Wie konsistent verhält er sich?
- Wie reagiert er auf Fehler?
- Ist er sicher?
- Wie viel kostet er?
- Können wir nachvollziehen, warum er gescheitert ist?
Die wichtigste Frage lautet daher nicht:
„Funktioniert unser KI-Agent?“
Sondern:
„Können wir messen, wie gut er funktioniert – und erkennen, wenn er schlechter wird?“
Genau das unterscheidet einen KI-Agenten, der in einer Demo beeindruckend aussieht, von einem System, das für den realen Einsatz bereit ist.