BLUF
Die Evaluation von KI-Agenten in Produktion sollte nicht mit einem Modell-Leaderboard beginnen. Sie sollte mit dem Geschäftsprozess beginnen: Was darf der Agent tun? Wie sieht ein korrektes Ergebnis aus? Was kostet eine abgeschlossene Aufgabe? Wann muss an einen Menschen eskaliert werden? Welche Traces werden zu Regressionstests?
Für B2B-Teams sind die nützlichen Metriken nicht nur Modellgenauigkeit. Entscheidend sind Kosten pro erledigter Aufgabe, Tool-Call-Genauigkeit, Eskalationsrate, Latenz, Korrekturrate und die Qualität der Audit-Spur.
Warum Agenten-Evaluation anders ist
Klassische LLM-Evaluation fragt häufig: War die Antwort gut? Produktive Agenten-Evaluation fragt: Hat das System den Workflow sicher, wirtschaftlich und mit ausreichender Evidenz abgeschlossen?
Ein agentischer Workflow kann Retrieval, Tool Calls, CRM-Updates, Ticket-Routing, E-Mail-Entwürfe, Freigabe-Gates, Datenbankabfragen und menschliche Prüfung enthalten. Eine plausible finale Antwort zeigt nicht, ob die Zwischenschritte korrekt waren. Der Agent kann das falsche Tool aufrufen, veralteten Kontext nutzen, einen Freigabeschritt überspringen oder deutlich mehr Tokens verbrauchen als geplant.
Deshalb braucht Evaluation Traces. LangSmith unterscheidet zwischen Offline-Evaluation vor dem Deployment und Online-Evaluation auf Produktions-Traces. Offline-Evals nutzen kuratierte Datensätze und Referenzausgaben. Online-Evals überwachen Live-Runs auf Qualitätsmuster, Sicherheitsprobleme, Anomalien und Feedback-Loops.
Der relevante Metrik-Stack
| Metrik | Aussage | Warum relevant |
|---|---|---|
| --- | --- | --- |
| Task Success Rate | Ob der Workflow die Aufgabe abgeschlossen hat | Besser als reine Antwortqualität |
| Tool-Call-Genauigkeit | Ob Tool und Argumente korrekt waren | Falsche Tool Calls erzeugen Betriebsrisiko |
| Kosten pro erledigter Aufgabe | Kosten pro akzeptiertem Ergebnis | Zeigt, ob Automation wirtschaftlich ist |
| Eskalationsrate | Wie oft an Menschen übergeben wird | Sicherheits- und Reifegrad-Signal |
| Korrekturrate | Wie oft Menschen ändern oder zurücknehmen | Misst Vertrauen und operative Last |
| Latenz | Zeit bis zum nutzbaren Ergebnis | Kritisch für Support und Operations |
| Safe-Stop-Rate | Wie oft der Agent unsichere Aktionen ablehnt | Wichtig für kontrollierte Workflows |
| Audit-Vollständigkeit | Ob Evidenz, Entscheidung und Reviewer erfasst sind | Relevant für Debugging und Governance |
Das Ziel ist nicht, jede Metrik gleichzeitig zu optimieren. Weniger Eskalation kann Risiko erhöhen. Höhere Genauigkeit kann Kosten erhöhen. Schnellere Antworten können Evidenzqualität senken.
Offline- vs. Online-Evaluation
Offline-Evals schaffen Vertrauen vor dem Deployment. Sie nutzen kuratierte Beispiele, historische Traces, synthetische Fälle und Referenzausgaben. Sie eignen sich für Regressionstests, Prompt-Vergleiche, Tool-Schema-Änderungen, RAG-Änderungen und Modellwechsel.
Online-Evals überwachen Produktion. Sie laufen auf echten Traces, häufig ohne Referenzausgabe. Sie erkennen Drift, unsichere Outputs, fehlgeschlagene Tool Calls, teure Runs, Latenzspitzen und wiederkehrende Sonderfälle.
| Evaluationsmodus | Beste Nutzung | Daten | Typische Prüfer |
|---|---|---|---|
| --- | --- | --- | --- |
| Offline-Eval | Pre-Release Regression | Kuratierte Beispiele und erwartete Ergebnisse | Code-Regeln, Human Labels, LLM-as-Judge |
| Online-Eval | Produktionsmonitoring | Live-Traces ohne Referenz | Sicherheitsregeln, Formatchecks, Kostengrenzen |
| Human Review | Ambigue oder riskante Fälle | Evidenzpaket und Trace | Freigabe, Ablehnung, Korrektur |
| Backtesting | Neue Version auf alten Fällen prüfen | Historische Produktions-Traces | Regression Score und Failure Replay |
Kosten pro Aufgabe: die oft fehlende Metrik
Viele Teams tracken Tokens, aber nicht die Kosten pro nutzbarem Ergebnis. Dadurch bleibt die Wirtschaftlichkeit unklar. Wenn ein Agent pro Run €0,40 kostet, aber nur 40% der Aufgaben ohne menschliche Korrektur erledigt, liegen die Kosten pro erfolgreich automatisierter Aufgabe näher bei €1,00, bevor Review-Zeit eingerechnet wird.
| Kostenkomponente | Beispielmessung |
|---|---|
| --- | --- |
| Modellkosten | Input-/Output-Tokens pro Run |
| Tool/API-Kosten | Suche, OCR, CRM, Vektor-DB, externe APIs |
| Infrastrukturkosten | Queue, Worker, Storage, Observability |
| Human-Review-Kosten | Minuten pro Freigabe oder Korrektur |
| Fehlerkosten | Nacharbeit, doppelte Tickets, SLA-Auswirkungen |
Die nützliche KPI lautet:
Kosten pro erledigter Aufgabe = Gesamtkosten des Workflows / Anzahl akzeptierter erfolgreicher Ergebnisse
Genauigkeit ist nicht eine Zahl
Bei Agenten hat Genauigkeit mehrere Ebenen.
| Ebene | Evaluationsfrage |
|---|---|
| --- | --- |
| Intent-Verständnis | Wurde Aufgabe oder Nutzerabsicht korrekt klassifiziert? |
| Retrieval | Wurden die richtigen Dokumente oder Datensätze gefunden? |
| Tool-Auswahl | Wurde das richtige Tool gewählt? |
| Tool-Argumente | Wurden die richtigen Felder und Constraints übergeben? |
| Reasoning-Pfad | Folgte der Trace einem akzeptablen Workflow? |
| Finale Antwort | War die Antwort sachlich korrekt und nützlich? |
| Geschäftsergebnis | Ist der Zielzustand im System korrekt? |
Ragas nennt für Agenten unter anderem Tool Call Accuracy, Tool Call F1, Topic Adherence und Agent Goal Accuracy. Diese Kategorien sind nützlich, weil sie den Agenten als Workflow-Akteur bewerten, nicht nur als Textgenerator.
Eskalationsrate ist ein Sicherheitssignal
Eskalation wird häufig als Automationsfehler interpretiert. In produktiven KI-Systemen ist Eskalation ein Kontrollmechanismus. Ein gesunder Agent eskaliert, wenn Evidenz fehlt, Berechtigungen nicht ausreichen, eine kundenwirksame Aktion verlangt wird oder Risiko- und Kostengrenzen überschritten werden.
| Eskalationsmuster | Interpretation | Maßnahme |
|---|---|---|
| --- | --- | --- |
| Hohe Eskalation, hohe Korrekturqualität | Gute Sicherheit, schwache Autonomie | Retrieval, Tool-Schemata und Beispiele verbessern |
| Niedrige Eskalation, viele Folgefehler | Verdecktes Risiko | Freigabe-Gates und Schwellenwerte verschärfen |
| Hohe Eskalation, kaum Korrekturen | Zu vorsichtige Automation | Confidence-Schwellen feinjustieren |
| Steigende Eskalation nach Deployment | Drift oder Workflow-Änderung | Fehlgeschlagene Traces in Offline-Dataset übernehmen |
Logging und EU-AI-Act-Readiness
Dies ist keine Rechtsberatung. Technisch sollten Teams Evaluation aber so bauen, dass Logs, menschliche Aufsicht und Dokumentation nicht nachträglich ergänzt werden müssen.
Artikel 12 des EU AI Act verlangt für Hochrisiko-KI-Systeme technische Möglichkeiten zur automatischen Ereignisaufzeichnung über die Lebensdauer des Systems. Artikel 14 behandelt menschliche Aufsicht. Auch wenn ein konkreter Enterprise-Workflow nicht als Hochrisiko-System eingestuft wird, ist das technische Muster sinnvoll: erfassen, was passiert ist, warum das System gehandelt hat, wer geprüft hat und welche Evidenz verfügbar war.
| Log-Feld | Nutzen |
|---|---|
| --- | --- |
| Run-ID und Zeitstempel | Nachvollziehbarkeit |
| Nutzer-/Request-Kontext | Debugging und Replay |
| Genutzte Evidenz | Erklärbarkeit und Korrektur |
| Tool Calls und Argumente | Operative Verantwortlichkeit |
| Modell, Version, Prompt | Regressionanalyse |
| Kosten und Latenz | Wirtschaftlichkeit |
| Eskalationsgrund | Sicherheits- und Verbesserungsloop |
| Reviewer und Entscheidung | Aufsichtsprotokoll |
| Finales Ergebnis | Erfolgs-/Fehlermessung |
30-Tage-Implementierungsplan
Tage 1-7: Erfolg und Fehler definieren
Wählen Sie einen Workflow. Definieren Sie erfolgreiche Ergebnisse, unzulässige Aktionen, Eskalationskriterien, Ziel-Latenz und Kostengrenze. Erstellen Sie 20-50 repräsentative Testfälle aus echten Operations-Daten.
Tage 8-14: Traces und Offline-Evals ergänzen
Instrumentieren Sie den Workflow so, dass Inputs, Outputs, Tool Calls, Evidenz, Latenz, Kosten und finales Ergebnis erfasst werden. Bauen Sie Offline-Evals für Tool-Auswahl, Ausgabeformat, Retrieval-Qualität und Geschäftsergebnis.
Tage 15-21: Online-Monitoring ergänzen
Ergänzen Sie Produktionsmonitore für hohe Kosten, wiederholte Tool-Fehler, fehlende Evidenz, lange Latenz, Policy-Verstöße und Eskalationsmuster. Ziehen Sie Stichproben aus Live-Traces für Human Review.
Tage 22-30: Feedback-Loop schließen
Überführen Sie fehlgeschlagene Produktions-Traces in das Offline-Dataset. Ergänzen Sie Regressionstests vor jeder Prompt-, Modell- oder Workflow-Änderung. Prüfen Sie die Kosten pro akzeptierter erfolgreicher Aufgabe wöchentlich.
Empfohlenes Operations-Dashboard
| Dashboard-Bereich | Mindest-Widgets |
|---|---|
| --- | --- |
| Qualität | Task Success, Korrekturrate, Evaluator Pass Rate |
| Risiko | Eskalationen, Ablehnungen, Policy-Verstöße, riskante Tool Calls |
| Kosten | Kosten pro Run, Kosten pro akzeptierter Aufgabe, Kosten nach Tool/Modell |
| Latenz | p50/p95 Ende-zu-Ende-Latenz, langsame Tool Calls |
| Feedback-Loop | neue Fehltraces, geprüfte Stichproben, ergänzte Regression Cases |
Ein gutes Dashboard unterstützt Entscheidungen: ausrollen, zurückrollen, Approval-Schwellen erhöhen, Retrieval anpassen, Tool-Schema ändern oder mehr Beispiele ergänzen.
Die Implementierungsimplikation
Agenten-Evaluation ist keine Reporting-Schicht. Sie ist Teil der Architektur. Wenn Traces, Kosten, Eskalationsgründe und menschliche Entscheidungen während der Ausführung nicht erfasst werden, lassen sie sich später nicht zuverlässig rekonstruieren.
Die sinnvolle Reihenfolge lautet:
1. Workflow mit Trace-IDs ab Tag eins bauen.
2. Erfolgsmetriken definieren, bevor Modelle gewechselt werden.
3. Mit Offline-Evals auf kuratierten Fällen starten.
4. Online-Evals für Live-Monitoring ergänzen.
5. Ambigue Fälle an Human Review leiten.
6. Fehler in das Regression-Dataset zurückführen.
So werden KI-Agenten von überzeugenden Demos zu Systemen, denen Operations, Compliance und Management vertrauen können.
Quellen
- LangSmith Evaluation: https://docs.langchain.com/langsmith/evaluation
- LangSmith Evaluation Concepts: https://docs.smith.langchain.com/evaluation
- Ragas Metrics for Agents and Tool Use: https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/
- EU AI Act Article 12 — Record-Keeping: https://artificialintelligenceact.eu/article/12
- EU AI Act Article 14 — Human Oversight: https://artificialintelligenceact.eu/article/14
