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 Pflicht.
• Agenten-Benchmarks belegen Capability, nicht Fitness für Ihren 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 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 unter Art. 72 nachweisen, dass das System weiterhin innerhalb der Toleranzen arbeitet". 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 bodengrundwahre 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 Anbieters: ein Snapshot der Capability über öffentliche Benchmarks. Ein Compliance-Eval ist das regulatorische Artefakt des Betreibers: 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 ein 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 80,9 % auf SWE-bench Verified, aber nur 45,9 % auf dem kontaminationsresistenten SWE-bench Pro — dasselbe Modell, dieselbe Aufgabenfamilie, 35 Punkte Unterschied (Stand 2026).
• 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 — und ein Metrik-Set, das Reliabilität und Kosten genauso ernst nimmt wie die nackte Erfolgsquote. Genau dieses Eval-Fundament ist zugleich die Voraussetzung für belastbares EU-AI-Act-Art.-72-Monitoring. 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. Sprechen Sie uns an, wenn Ihre Agenten messbar und regelkonform produktiv gehen sollen.