AI-Agent-Evaluation: Welche Metriken zählen

AI-Agent-Evaluation misst, ob ein KI-Agent zuverlässig die beabsichtigte Aufgabe löst. Die zentralen Metriken sind Task-Success-Rate, Trajectory- und Tool-Call-Korrektheit, Groundedness bzw. Halluzinationsrate, Latenz, Kosten und HITL-Eskalationsrate. Gemessen wird offline gegen einen Eval-Datensatz und online im Produktionsbetrieb. Evaluation ist die Disziplin, die darüber entscheidet, ob ein Agent das Labor verlassen darf, und seit EU AI Act, ISO/IEC 42001 und den Modellrisiko-Erwartungen von BaFin und FINMA ist sie von einer Forschungspraxis zum Compliance-Artefakt geworden.

Die wichtigste Erkenntnis vorweg: Eine einzelne Kennzahl auf einem Leaderboard ist kein Beleg mehr dafür, dass ein Agent funktioniert. Das Princeton-Team hinter dem Holistic Agent Leaderboard (HAL) zeigt, dass 18 Monate Capability-Fortschritt nur kleine Verbesserungen bei der Reliabilität brachten, während die reine Genauigkeit stetig stieg. Wer Agenten produktiv und regelkonform betreiben will, braucht ein mehrdimensionales Metrik-Set.

Schnellantworten:

• Die Task-Success-Rate ist die wichtigste Einzelkennzahl, aber nie ausreichend: Qualität, Tool-Korrektheit, Kosten und Reliabilität gehören dazu.
• Offline-Evals (fixer Datensatz, LLM-as-Judge) liefern Vorab-Evidenz; Online-Monitoring fängt Drift und reale Fehler. Beide sind nötig.
• Agenten-Benchmarks belegen Capability, nicht Fitness für deinen Use-Case: Der Nachweis ist ein eigener, deutschsprachiger Eval-Datensatz.

Die sechs Metrik-Familien für AI-Agenten

Ein vollständiges Eval-Programm produziert pro Release mindestens eine Zahl aus jeder relevanten Kategorie und plottet das Spannungsdreieck aus Kosten, Qualität und Sicherheit auf einer Pareto-Front, statt es auf einen Score zu kollabieren.

Zwei Punkte verdienen Hervorhebung. Erstens ist die Eskalationsrate kein reines Negativsignal: Eine gut justierte Eskalation an einen Menschen ist ein Feature, kein Defekt; entscheidend ist, dass der Agent die richtigen Fälle übergibt. Zweitens ist Reliabilität oft wichtiger als Genauigkeit. Ein Agent, der zu 90 % erfolgreich ist, aber in den verbleibenden 10 % unvorhersehbar versagt, ist im DACH-Produktivbetrieb häufig schlechter als einer mit 80 % Erfolg und planbarem, recoverbarem Fehlerverhalten. Sierras τ-bench zeigt, dass pass^k (alle k Läufe erfolgreich) bei vielen Modellen bis k=8 deutlich abfällt: derselbe Agent, dieselbe Aufgabe, materiell andere Ergebnisse über die Läufe. Wer nur einen Single-Seed-Lauf berichtet, versteckt diese Varianz. Mindeststandard: Mittelwert plus Standardfehler über 3-5 Läufe.

Offline-Evals vs. Online-Monitoring

Die fundamentale Dichotomie der Disziplin ist offline gegen online, und reife Programme nutzen beide Seiten.

Offline-Evaluation läuft gebatcht gegen einen fixen, versionierten Datensatz. Sie ist deterministisch, wiederholbar und liefert die Vorab-Evidenz, die EU AI Act Art. 15 für Hochrisiko-Systeme verlangt: Genauigkeit muss gemessen und deklariert werden, nicht aspirativ behauptet. Offline-Evals sind der Ort für LLM-as-Judge gegen Referenzantworten und für das systematische Durchspielen bekannter Edge-Cases.

Online-Evaluation bewertet echten Produktions-Traffic. Sie ist die Brücke zwischen "wir haben deployt" und "wir können nachweisen, dass das System weiterhin innerhalb der Toleranzen arbeitet". Bei Hochrisiko-KI-Systemen verlangt Art. 72 EU AI Act vom Anbieter genau diese laufende Überwachung nach dem Inverkehrbringen (Post-Market-Monitoring). Bewährte Deployment-Muster:

• Shadow Mode: Das neue System läuft parallel mit denselben Inputs, seine Outputs werden aber nicht ausgespielt, sondern geloggt und verglichen. De-facto-Standard vor jedem Hochrisiko-Rollout.
• Canary Deployment: 1-5 % des Traffics auf das neue System, weiterer Rollout abhängig von Echtzeit-Metriken. Wichtig: Die Gate-Metriken müssen Eval-Scores enthalten, nicht nur Latenz und Fehlerrate.
• Eval Gates: Automatische Schwellwerte, die den Rollout stoppen (z. B. "Promotion anhalten, wenn Faithfulness in einem 4-Stunden-Fenster unter 0,85 fällt").

Da LLM-Judges auf jedem Trace prohibitiv teuer sind, wird gesampelt. Eine sinnvolle Ausgangskonfiguration für den Mittelstand: 1-5 % stratifiziertes Zufallssampling plus 100 % anomalie-getriebenes Sampling (lange Sessions, viele Retries, explizites Negativ-Feedback). Billige Heuristiken (PII-Check, Format-Prüfung, Refusal-Erkennung) laufen synchron inline; teure Judge-Evals asynchron auf der Stichprobe. Dieser Sync/Async-Split ist der wichtigste Kostenhebel: ohne ihn kann der Eval-Aufwand die Inferenzkosten um das 2- bis 5-fache übersteigen.

Online sollte zudem auf echtem Nutzerverhalten verankert werden, nicht nur auf Judge-Scores: Copy-Paste-Rate, Edit-after-Paste, Retry-Rate und Abbruchrate sind langsame, aber verlässliche Ground-Truth-Signale. In DACH liegt die Klickrate auf Daumen-hoch/runter kulturell niedriger als in den USA, was die Aussagekraft expliziter Feedback-Signale dämpft.

LLM-as-Judge: nützlich, aber kein Selbstläufer

Die kanonische Referenz (Zheng et al., 2023) zeigt, dass starke Judge-Modelle über 80 % Übereinstimmung mit kontrollierten menschlichen Bewertungen erreichen, dasselbe Niveau wie die Mensch-zu-Mensch-Übereinstimmung. Das gilt jedoch für meinungsbasierte Aufgaben; für faktenkritische deutschsprachige Inhalte (Recht, Medizin, Finanzen) bleibt menschliches Gold der Standard.

Praktische Leitlinien aus der Praxis:

• Binär statt Likert. Pass/Fail mit ausformulierter Kritik schlägt 1-5-Skalen, weil die 3-gegen-4-Grenze über Judges und Läufe hinweg instabil ist.
• Bekannte Verzerrungen mitigieren. Position-Bias durch Vertauschen und Mitteln beider Reihenfolgen; Verbosity-Bias durch Längen-Kontrolle; Self-Enhancement-Bias durch Judges aus einer anderen Modellfamilie oder ein Judge-Ensemble.
• Kalibrieren. Judge-gegen-Mensch-Übereinstimmung als Cohens Kappa oder Krippendorffs Alpha berichten, bevor ein Judge produktiv vertraut wird.
• Kosten begrenzen. Faustregel: 10-30 % der Inferenzkosten für Evaluation budgetieren; mit Reasoning-Judges kann das auf über 50 % steigen. Muster: Reasoning-Judges für den Validierungs-Set, günstige Spezial-Judges (etwa MiniCheck-artige Modelle) für das Produktions-Sampling.

Entscheidend: LLM-as-Judge ist kein Ersatz für Fehleranalyse. Der Praktiker-Konsens lautet, dass 60-80 % des Eval-Aufwands weiterhin in das Anschauen von Daten, das Finden von Fehlermodi und deren Übersetzung in Pass/Fail-Asserts fließen sollten.

So baut man Eval-Datensatz und Eval-Loop auf

Ein belastbarer Golden-Set hat dokumentierte Provenienz, ein Labeling-Rubric, Inter-Annotator-Agreement und explizite Abdeckung der echten Use-Cases. Praxisrezept:

1. 200-500 echte Nutzer-Traces sampeln; PII gemäß DSGVO Art. 32 redigieren.
2. Zwei Fachexperten labeln jeden Trace mit Outcome plus Kritik; Cohens Kappa berechnen, Konflikte auflösen.
3. 50-100 expertengeschriebene adversariale Edge-Cases an Policy-Grenzen ergänzen.
4. 100-200 synthetische Fälle über dokumentierte Dimensionen (Features × Szenarien × Personas) hinzufügen.
5. 30 % als gelockten Test-Set abtrennen, der nie für Tuning verwendet wird; 70 % für Iteration.
6. Versionieren, Dataset-Card dokumentieren, quartalsweise refreshen.

Für einen DACH-Mittelstands-Piloten braucht ein 500-Item-Golden-Set initial rund 3-6 Wochen Expertenzeit und danach etwa eine Woche pro Quartal. Das ist die höchste Hebelwirkung im gesamten Eval-Programm.

Der kontinuierliche Eval-Loop verbindet beide Welten: Nutzeranfrage → Agenten-Lauf → Trace-Span-Emission (OpenTelemetry) → Sampling-Schicht → Eval-Schicht (LLM-Judges plus Heuristiken plus Small-Model-Judges) → Eval-Store → Dashboard → Alert bei Schwellwert-Bruch → Feedback in den Golden-Set. Reife Programme machen daraus ein CI/CD-Gate: Jeder Pull Request, der Prompt, Modellwahl, Retrieval-Konfiguration oder Tool-Definition ändert, triggert die Eval-Suite; der Merge scheitert, wenn die Pass-Rate unter den Schwellwert fällt. Auch ein Modell-Versionswechsel des Anbieters sollte ein automatisches Re-Eval auslösen, bevor das neue Modell ins Produktions-Routing darf. Ein gelockter Golden-Set sollte mindestens wöchentlich, bei produktionskritischen Agenten täglich gegen das Live-System re-evaluiert werden, um Modell-/Prompt-Regression von reinem Umfeld-Drift zu trennen.

Für DSGVO-konforme Datenresidenz eignen sich selbst-hostbare Tools wie das deutsch-gegründete Langfuse (Self-Host über ClickHouse und Postgres) oder das OTel-native Arize Phoenix; RAGAS ist die De-facto-Bibliothek für RAG-Metriken (Faithfulness, Context Precision, Answer Relevancy), DeepEval und Inspect AI decken CI/CD-nahe und sicherheitsrelevante Evals ab. (Stand 2026; der Eval-Tooling-Markt konsolidiert sich gerade über M&A wie Cisco/Galileo.)

Abgrenzung zu Modell-Benchmarks

Ein häufiger und teurer Denkfehler ist, Benchmark-Scores mit einem Eignungsnachweis zu verwechseln. Ein Model-Card-Eval ist das Marketing- bzw. Forschungs-Artefakt des Modellanbieters: ein Snapshot der Capability über öffentliche Benchmarks. Ein Compliance-Eval ist das regulatorische Artefakt des Unternehmens, das den Agenten entwickelt oder einsetzt: Vorab- plus laufende Messung gegen den tatsächlichen Use-Case, Datensatz und das Risikoprofil, mit dokumentierter Methodik, versionierten Scorern und Audit-Trail. Das sind unterschiedliche Artefakte mit unterschiedlichen Adressaten, und die meisten Regulatoren akzeptieren eine Model-Card nicht als Ersatz.

Drei Gründe, warum Benchmark-Scores nur Kontext liefern:

• Kontamination. Jeder Benchmark, dessen Datensatz vor 2024 öffentlich existierte, ist mutmaßlich in den Trainingsdaten. Beispiel: Claude Opus 4.5 erreicht laut Anthropic 80,9 % auf SWE-bench Verified, einer 2024 kuratierten Teilmenge des 2023 veröffentlichten SWE-bench. Auf dem kontaminationsresistenteren SWE-bench Pro kommt es im öffentlichen Leaderboard von Scale AI dagegen auf 45,9 % (Stand Oktober 2026). Der Abstand geht nicht allein auf Kontamination zurück: SWE-bench Pro ist auch schwerer gebaut (die Referenzlösungen ändern im Schnitt 107 Codezeilen in 4,1 Dateien), und die beiden Werte stammen aus unterschiedlichen Messaufbauten (Herstellerangabe gegen Leaderboard). Er zeigt aber, wie stark Scores von Benchmark-Design und möglicher Kontamination abhängen.
• Scaffold-Abhängigkeit. "GAIA-Leaderboard-Führer" ist ohne Nennung des Scaffolds bedeutungslos: Zwischen scaffolded (Princeton HAL mit Claude Sonnet 4.5: 74,6 %) und bare Scores liegen rund 30 Prozentpunkte.
• Reward-Hacking. Eine UC-Berkeley-RDI-Arbeit (April 2026) zeigte, dass ein automatisierter Scanning-Agent alle acht großen Agent-Benchmarks auf nahezu perfekte Scores hacken konnte, ohne eine Aufgabe zu lösen.

Die defensible Position für ein DACH-Compliance-Dossier: mehrere Benchmarks über Familien hinweg zitieren, Kosten und Varianz berichten, mit kundenprivaten Golden-Sets ergänzen und die Grenzen schriftlich anerkennen. Englische Agent-Benchmarks (SWE-bench, GAIA, τ-bench, BFCL, OSWorld) taugen zum Capability-Baselining; der eigentliche Nachweis bleibt der deutschsprachige Eval-Datensatz, idealerweise an die BSI-Kriterienkataloge gemappt.

Für Agenturen und B2B-Entscheider

Wer KI-Agenten für DACH-Kunden plant oder betreibt, sollte Evaluation nicht als nachgelagerten Test, sondern als durchgehende Disziplin verstehen: ein deutschsprachiger Golden-Set als Fundament, Offline-Gates vor dem Go-Live, Online-Monitoring mit Drift-Erkennung danach, dazu ein Metrik-Set, das Reliabilität und Kosten genauso ernst nimmt wie die nackte Erfolgsquote. Bei Hochrisiko-KI-Systemen ist dieses Eval-Fundament zugleich eine Grundlage für das Post-Market-Monitoring. Art. 15 und Art. 72 EU AI Act verpflichten aber nur Anbieter solcher Systeme. Für die meisten Marketing-Agenten ist ein sauberes Eval-Programm Best Practice, keine gesetzliche Pflicht. Blck Alpaca unterstützt Agenturen und B2B-Unternehmen aus Wien dabei, ein solches Eval-Programm aufzusetzen, vom Golden-Set über die Tool-Auswahl bis zum auditfesten Compliance-Dossier. Sprich uns an, wenn deine Agenten messbar und regelkonform produktiv gehen sollen.