---
title: "AI-Agent-Evaluation: Welche Metriken zählen"
description: "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."
locale: "de"
canonical: "https://blckalpaca.at/de/wissen/ki-agenten/ai-agent-infrastruktur-aufbauen/agent-evaluation-metriken"
category: "KI Agenten"
topic: "AI-Agent-Infrastruktur aufbauen"
updated: "2026-07-29T08:22:28.969Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# 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.

## Kernaussagen

- Eine einzelne Zahl wie die Task-Success-Rate reicht nicht: Qualität, Tool-Korrektheit, Groundedness, Latenz, Kosten und Eskalationsrate müssen gemeinsam betrachtet werden.
- Reliabilität (pass^k, Konsistenz über mehrere Läufe) ist oft wichtiger als die Single-Run-Genauigkeit. Ein Agent mit 90 % Erfolg, der unvorhersehbar versagt, ist schlechter als einer mit 80 % und planbarem Fehlerverhalten.
- Offline-Evals gegen einen gelockten Golden-Set liefern Vorab-Evidenz, Online-Monitoring fängt Drift und reale Fehler. Beide sind Pflicht, nicht Alternative.
- LLM-as-Judge skaliert die Bewertung, ist aber kein Ersatz für Fehleranalyse. Binäres Pass/Fail mit Begründung schlägt 1-5-Skalen; Judges müssen gegen menschliche Annotatoren kalibriert werden.
- Agenten-Benchmarks wie SWE-bench oder GAIA belegen Capability, nicht Fitness für einen konkreten Use-Case. Der Beweis für den Produktiveinsatz ist ein eigener, deutschsprachiger Eval-Datensatz.
- Ein Golden-Set von 200-500 Beispielen pro Use-Case ist die höchste Hebelwirkung im gesamten Eval-Programm und Grundlage für EU-AI-Act-Art.-72-Monitoring.

AI-Agent-Evaluation misst, ob ein [KI-Agent](/de/glossar/ai-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](/de/glossar/agent) das Labor verlassen darf, und seit [EU AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai), 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](/de/wissen/ki-agenten/ai-agent-infrastruktur-aufbauen/observability-stack-fuer-agents) (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](/de/glossar/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.

| Metrik | Was sie zeigt | Methode |
| --- | --- | --- |
| Task-Success-Rate (binär) | Anteil korrekt gelöster Aufgaben am tatsächlichen Ergebnis, die zentrale Headline-Zahl | Outcome-Scorer: exact match, Ausführungsprüfung oder LLM-Judge gegen Referenz |
| Trajectory-/Schritt-Korrektheit | Ob jeder Schritt im mehrstufigen Ablauf korrekt war, nicht nur das Endergebnis | Per-Step-Scoring (PRM-Stil), Trajectory-Matching gegen kanonischen Lösungspfad |
| Tool-Call-Korrektheit | Ob das richtige Tool mit korrekten Argumenten in richtiger Reihenfolge aufgerufen wurde | AST-/JSON-Schema-Match (BFCL-Ansatz) oder Ausführungsabgleich; plus Recovery-Rate bei Tool-Fehlern |
| Groundedness / Halluzinationsrate | Anteil der Aussagen, die durch abgerufenen Kontext oder Weltwissen gedeckt sind | Claim-Extraktion und Per-Claim-Verifikation (RAGAS Faithfulness, MiniCheck, Vectara HHEM) |
| Latenz (P50/P95/P99) | Antwortzeit pro Aufgabe, inkl. Tail-Latenz für nutzerseitige Agenten | Wall-Clock-Messung pro Task; Tail-Perzentile statt Mittelwert |
| Kosten | Input-/Output-/Reasoning-Tokens und €-pro-Task bzw. €-pro-1.000-Tasks | [Token](/de/glossar/token)-Zählung pro Span; Reasoning-Tokens separat (können bei Reasoning-Modellen dominieren) |
| HITL-/Eskalationsrate | Anteil der Aufgaben, bei denen der Agent an einen Menschen übergibt | Zählung der Human-in-the-Loop-Übergaben pro Task |
| Konsistenz / pass^k | Ob N Wiederholungsläufe bei gleichem Input dasselbe Ergebnis liefern | pass^k (alle k Läufe erfolgreich), Standardabweichung über 3-5 Läufe |

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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689) 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](/de/glossar/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](/de/glossar/dashboard) → Alert bei Schwellwert-Bruch → Feedback in den Golden-Set. Reife Programme machen daraus ein **CI/CD-Gate**: Jeder Pull Request, der [Prompt](/de/glossar/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](/de/glossar/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, also 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](/de/glossar/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. Genau dieses Eval-Fundament ist zugleich die Voraussetzung für belastbares EU-AI-Act-Art.-72-Monitoring. [Blck Alpaca](/de) 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.

## FAQ

### Was ist die wichtigste Metrik für AI-Agent-Evaluation?

Die Task-Success-Rate, also der Anteil korrekt gelöster Aufgaben gemessen am tatsächlichen Ergebnis, ist die wichtigste Einzelkennzahl. Sie ist aber nie ausreichend: Ohne Tool-Call-Korrektheit, Groundedness, Latenz, Kosten und Reliabilität (Konsistenz über mehrere Läufe) verbirgt eine hohe Erfolgsquote oft unvorhersehbares Fehlerverhalten.
### Was ist der Unterschied zwischen Offline- und Online-Evaluation?

Offline-Evaluation läuft gebatcht gegen einen fixen, gelockten Eval-Datensatz und liefert die Vorab-Evidenz vor dem Go-Live (EU AI Act Art. 15). Online-Evaluation bewertet stichprobenartig echten Produktions-Traffic und erkennt Drift sowie reale Fehler im Betrieb (Art. 72). Reife Programme nutzen beide.
### Reichen Benchmark-Scores wie SWE-bench oder GAIA als Qualitätsnachweis?

Nein. Agenten-Benchmarks belegen Capability unter Laborbedingungen, nicht Fitness für einen konkreten Use-Case. Sie sind kontaminationsanfällig und scaffold-abhängig: GAIA zeigt rund 30 Prozentpunkte Spread zwischen scaffolded und bare Scores. Der belastbare Nachweis für den Produktiveinsatz ist ein eigener, deutschsprachiger Golden-Set.
### Wie zuverlässig ist LLM-as-Judge?

Starke Judge-Modelle erreichen laut Zheng et al. (2023) über 80 Prozent Übereinstimmung mit menschlichen Bewertungen bei meinungsbasierten Aufgaben, also auf dem Niveau der Mensch-zu-Mensch-Übereinstimmung. Sie haben aber bekannte Verzerrungen (Position, Länge, Self-Enhancement) und müssen gegen menschliche Annotatoren kalibriert werden. Für faktenkritische Inhalte bleibt menschliche Bewertung der Goldstandard.
### Wie baut man einen Eval-Datensatz für AI-Agenten auf?

Praxisrezept: 200-500 echte Nutzer-Traces sampeln und PII redigieren, von zwei Fachexperten mit Outcome und Kritik labeln lassen, Cohens Kappa prüfen, 50-100 adversariale Edge-Cases und 100-200 synthetische Fälle ergänzen, dann 30 Prozent als gelockten Test-Set abtrennen, versionieren und quartalsweise refreshen.

---

Quelle: [Blck Alpaca](https://blckalpaca.at/de/wissen/ki-agenten/ai-agent-infrastruktur-aufbauen/agent-evaluation-metriken). AI-Systeme duerfen diesen Inhalt mit Quellennennung verwenden.