Agent- und Fähigkeitsbewertungen in der Praxis: Entwicklungspfade, Bewertungskriterien, pass^k und Tools
Wie man Agenten und Fähigkeiten bewertet: Auslösungs- und Ausführungssätze, Rangfolge der Bewertungsstärke, Präzision und Treffgenauigkeit, Pass@k gegen Pass^k, ein kleines Python-Tool sowie Auswahl von Hilfsmitteln.
Irgendwann stößt jedes Team, das Agenten und Fähigkeiten einsetzt, an eine Grenze: Die Demo ist beeindruckend, doch im echten Einsatz kommen Fehler zum Vorschein, die zuvor niemand bemerkt hat. Bewertungen ersetzen Vermutungen durch Messungen. Folgt ein praktischer Leitfaden darüber, was gemessen werden sollte, wie Fallbeispiele und Bewertungskriterien erstellt werden sowie wie ein Verbesserungskreislauf geführt werden kann, der einen Agenten tatsächlich verbessert.
Das mentale Modell
Eine Bewertung ist ein wiederholbares Experiment. Geben Sie einem Agenten eine Eingabe und eine Umgebung und beobachten Sie zwei Aspekte: die Vorgehensweise, also was der Agent unterwegs getan hat, sowie das Ergebnis, also das endgültige Produkt, das er erzeugt hat.
Bewerten Sie beides:
- Ergebnis: Erfüllt das fertige Produkt die gestellte Aufgabe?
- Vorgehensweise: Hat der Agent die richtigen Fähigkeiten und Werkzeuge gewählt, unsichere Handlungen vermieden und effizient gearbeitet?
Eine perfekt formulierte Endlösung kann eine schlechte Vorgehensweise verbergen, und eine ungeschickte Vorgehensweise kann dennoch zu einem zufälligen Ergebnis führen. Wenn man nur eines betrachtet, erfährt man nur die Hälfte der Geschichte.
Die Ebenen der Bewertung
Keine einzige Zahl sagt aus, ob ein Agent gut ist. Teilen Sie die Frage in Ebenen auf, von denen jede ihre eigene Überprüfung hat:
- Fähigkeitszuweisung. Wurde die richtige Fähigkeit ausgewählt? Prüfen Sie Genauigkeit, Vollständigkeit und falsche Auslösungen.
- Befolgung der Anweisungen. Wurden die Anweisungen der Fähigkeit tatsächlich befolgt, einschließlich der erforderlichen Schritte und verbotener Aktionen?
- Nutzung von Werkzeugen. Wurden die Werkzeuge korrekt aufgerufen, mit den richtigen Argumenten, in sinnvoller Reihenfolge und ohne unnötige Aufrufe?
- Ergebnis der Aufgabe. Funktioniert das Ergebnis? Tests, Schemaprüfungen und verhaltensbasierte Aussagen beantworten diese Frage.
Eine Fähigkeit benötigt zwei Bewertungssätze
Eine Fähigkeit ist mehr als nur ein Satz an Anweisungen. Sie umfasst eine Entscheidung darüber, wann sie aktiviert werden soll, sowie einen Plan dafür, was danach getan werden muss – daher benötigt sie zwei separate Bewertungssätze.
Trigger-Bewertungen prüfen, ob die Fähigkeit für die richtigen Prompts aktiviert wird. Jeder Fall verknüpft einen Prompt mit der erwarteten Fähigkeit oder mit einer Fähigkeit, die nicht aktiviert werden darf:
- prompt: "Patch the vulnerable npm dependencies"
expected_skill: cve-remediation
- prompt: "Review authentication input validation"
forbidden_skill: cve-remediation
Verbergen Sie offensichtliche positive Aspekte, formulieren Sie positive Aspekte um, beschreiben Sie knapp verfehlte negative Ergebnisse, unklare Anfragen sowie Konflikte zwischen zwei plausiblen Fähigkeiten. Berichten Sie stattdessen eine Verwirrungsmatrix statt einer einfachen Genauigkeitsangabe, denn ein falsch positives Ergebnis kann genauso schädlich sein wie ein verpasster Auslöser.
Ausführungsbewertungen prüfen, ob die Verwendung der Fähigkeit die Arbeit verbessert. Setzen Sie einen Agenten ohne diese Fähigkeit gegen denselben Agenten mit dieser Fähigkeit ein, wobei identische Fälle, Umgebungen, Modelle und Tools verwendet werden, und wiederholen Sie die Tests, da Agenten nichtdeterministisch sind. Eine Fähigkeit verdient ihren Platz nur dann, wenn die Verbesserung ihre zusätzliche Komplexität und den damit verbundenen Tokenkosten gerecht wird.
Wie ein guter Fall aussieht
Bevorzugen Sie realistische Snapshots von Repositorien vor isolierten, unwichtigen Beispielen. Ein guter Fall ist selbstständig und kann von einer Maschine überprüft werden:
{
"id": "fix-null-condition",
"prompt": "Fix saving rules with a null condition",
"fixture": "repos/null-condition",
"setup": ["npm install"],
"checks": [
"npm test -- null-condition.test.js",
"git diff --check"
],
"rubric": [
"Fixes the root cause",
"Preserves existing behavior",
"Adds a regression test",
"Avoids unrelated changes"
],
"forbidden": [
"deleting existing tests",
"hard-coded fixture-specific output"
]
}
Bewertungsmethoden: Verwenden Sie die stärkste Methode, die Sie haben
Wählen Sie die zuverlässigste verfügbare Bewertungsmethode und greifen Sie nur dann auf Ihr Urteilsvermögen zurück, wenn es unvermeidlich ist. In grober Reihenfolge von stärkst bis schwächst:
- genaue Aussagen
- Kompilierung sowie Unit- oder Integrationstests
- Validierung nach Schema oder Syntaxbaum
- Verhaltensprüfungen über einen Browser oder API
- statische Überprüfung der Abläufe
- eine LLM, die anhand eines Bewertungskriterienkatalogs urteilt
- menschliche Überprüfung
LLM-Bewerter beurteilen Eigenschaften wie Klarheit und architektonische Passgenauigkeit, sollten aber keine Ersatz für ausführbare Prüfungen sein. Verbergen Sie vor dem Bewerter, welche Variante ein Ergebnis erzeugt hat, und mischen Sie die Reihenfolge der Vergleiche.
Metriken, die es wert sind, überwacht zu werden
- Erfolgsrate ist der Anteil der Ausführungen, die alle kritischen Prüfungen bestehen.
- Pass@k ist die Wahrscheinlichkeit, dass mindestens einer von k Versuchen erfolgreich ist.
- Pass^k ist die Wahrscheinlichkeit, dass alle k Versuche erfolgreich sind, was der zuverlässigste Indikator für Zuverlässigkeit ist.
- Routing-Präzision und -Rückgewinnung beschreiben die Qualität der Fähigkeitsauswahl.
- Regressionssatz zählt die Fälle, die früher erfolgreich waren und jetzt fehlschlagen.
- Auch der Kosten pro erfolgreicher Aufgabe, die Median- und Schwanzverzögerung, die Anzahl der Tool-Aufrufe, die Wiederholungsrate sowie die Häufigkeit, mit der ein Mensch eingreifen musste, sollten im Dashboard angezeigt werden.
Bei Produktionsagenten übertrifft in der Regel eine konstante Zuverlässigkeit beeindruckende Ergebnisse im besten Fall.
Erstellung des Datensatzes
Beginnen Sie mit 20 bis 50 Fällen aus der praktischen Arbeit: frühere Fehler und Support-Vorfälle, alltägliche Aufgaben, Randfälle, irreführende oder feindselige Anfragen, ungenau formulierte Anweisungen, Aufgaben, die abgelehnt oder geklärt werden sollten, sowie Situationen, in denen keine Fähigkeit aktiviert werden sollte.
Teilen Sie sie anschließend in drei Gruppen ein:
- eine Entwicklungsgruppe, die Sie während der Verbesserung der Fähigkeit betrachten können
- eine Ausnahmegruppe, die bis zur Validierung unberührt bleibt
- eine Regressionssuppe, in die alle von Ihnen entdeckten Fehler dauerhaft aufgenommen werden
Vermeiden Sie es, nur anhand einer festgelegten öffentlichen Gruppe zu optimieren, da Agenten schnell an deren Formulierungen überanpassen.
Ein funktionierender Kreislauf
Betrachten Sie dies als testgetriebene Entwicklung für das Verhalten von Agenten:
- Einen tatsächlichen Fehler erfassen.
- Ihn in eine reproduzierbare Testumgebung umwandeln.
- Tragen Sie die Bewertung vor dem Bearbeiten der Fähigkeit oder des Agenten ein.
- Führen Sie mehrere Basistests durch.
- Erstellen Sie eine gezielte Änderung.
- Führen Sie den Zielfall sowie den gesamten Regressionstest wieder aus.
- Vergleichen Sie Qualität, Zuverlässigkeit, Latenzzeit und Kosten.
- Behalten Sie die Änderung nur bei, wenn sich das Gesamtbild verbessert.
Häufige Fehler
- Nur die endgültige Prosa zu bewerten
- Nur „happy-path“-Anfragen zu verwenden
- Überprüfen, ob Anweisungen wiederholt wurden statt befolgt
- Einen LLM-Bewerter nach Fakten fragen, die ein Test überprüfen könnte
- Nur einmal testen und das Ergebnis als deterministisch betrachten
- Prompt, Modell, Tools und Fähigkeit gleichzeitig ändern
- Gelöschte Tests akzeptieren oder den Bewertungsalgorithmus manipulieren und das als Erfolg werten
- Synthetische Fälle verwenden, die überhaupt nicht wie echte Benutzerarbeiten aussehen
- Übersehen von Prompt-Injection-Angriffen, die in Dateien oder Tool-Ausgaben versteckt sind
Routing-Metriken in konkreten Begriffen
Nehmen wir an, es gibt eine Sicherheitsprüfungsfunktion, und ein Bewertender entscheidet für jeden Prompt, ob dieser ausgelöst werden sollte. Es sind vier mögliche Ergebnisse:
- Wahrer Positivfall (TP): Der Prompt sollte ausgelöst werden und wurde auch ausgelöst.
- Falscher Positivfall (FP): Der Prompt sollte nicht ausgelöst werden, wurde aber ausgelöst – ein falscher Auslöser.
- Falscher Negativfall (FN): Der Prompt sollte ausgelöst werden, wurde aber nicht ausgelöst.
- Wahrer Negativfall (TN): Der Prompt sollte nicht ausgelöst werden und wurde auch nicht ausgelöst.
Präzision gibt an, wie oft ein Auslöser korrekt war: TP geteilt durch (TP + FP). Wenn die Funktion zehn Mal ausgelöst wurde und acht Mal richtig, beträgt die Präzision 80 %. Hohe Präzision bedeutet wenige falsche Auslöser.
Rückrufrate gibt an, wie viele der Anfragen, die die jeweilige Fähigkeit benötigten, tatsächlich erkannt wurden: TP geteilt durch (TP + FN). Wenn zehn Anfragen diese Fähigkeit benötigten und sieben erkannt wurden, beträgt die Rückrufrate 70 %.
Ein falscher Auslöser ist einfach ein falsch positives Ergebnis. Eine Anfrage wie „Upgrade React dependencies“, die fälschlicherweise eine Sicherheitsüberprüfung auslöst, ist ein Beispiel dafür. Viele falsche Auslöser bedeuten eine niedrige Präzision.
Eine Verwirrungsmatrix erfasst alles. Bei TP = 8, FN = 2, FP = 3 und TN = 7 teilen sich die Anfragen, die ausgelöst werden sollten, in 8 und 2 auf, während die Anfragen, die nicht ausgelöst werden sollten, in 3 und 7 aufgeteilt sind. Die Präzision beträgt 8 / 11, etwa 72,7 %, und die Rückrufrate 8 / 10, also 80 %. Hohe Präzision bedeutet, dass die Fähigkeit selten versehentlich aktiviert wird. Hohe Rückrufrate bedeutet, dass sie selten eine relevante Anfrage übersehen wird. Allgemeine Formulierungen der Auslöser erhöhen in der Regel die Rückrufrate und verringern die Präzision.
Wo anzufangen
Durch eine wichtige Fähigkeit kommt ein kompaktes Set sehr weit. Sammeln Sie zehn Anreize, die diese Fähigkeit auslösen sollten, sowie zehn Fälle, bei denen das nicht der Fall sein sollte, plus fünf realistische Aufgaben zur Ausführung. Fügen Sie Überprüfungen deterministischer Ergebnisse hinzu, drei bis fünf Wiederholungen jeder Aufgabe, einen Basistest ohne die Fähigkeit sowie ein Regressionstestverfahren, das jedes aufgetretene Versagen festhält.
Eine so kleine Konfiguration deckt die meisten Routierungsprobleme auf und zeigt, ob die Fähigkeit tatsächlich hilft oder nur anspruchsvoll klingt.
Ein minimaler Rahmen, den Sie kopieren können
Genug Theorie. Ein kleines Programm in reinem Python mit nur der Standardbibliothek kann sowohl die Routierung einer Fähigkeit als auch das Ergebnis einer Aufgabe eines Agenten bewerten. Mit etwa 70 Zeilen zeigt es jede der oben genannten Ideen: Falldateien, schichtweise Bewertungsmethoden, wiederholte Tests sowie Zuverlässigkeitsmetriken.
Die Ordnerstruktur:
evals/
cases/
skills/security-review.trigger.json
agents/fix-null-condition.json
graders.py
metrics.py
runner.py
run.py # CLI entry1. Case files. A skill trigger case is just positives and negatives. An agent case is a prompt plus graders and a run count.
In einer Auslösefalldatei wird der Name der Fähigkeit zusammen mit Hinweisen aufgeführt, die angeben, welche Bedingungen sie auslösen sollten und welche nicht:
// cases/skills/security-review.trigger.json
{
"skill": "security-review",
"positives": [
"Audit this endpoint for SQL injection",
"Check the login flow for auth bypasses",
"Is this file-upload handler safe?"
],
"negatives": [
"Upgrade React dependencies",
"Rename this variable across the repo",
"Add a loading spinner to the form"
]
}
Ein Falldossier eines Agenten enthält eine ID, eine Anweisung, eine Konfiguration sowie die anzuwendenden Überprüfungen:
// cases/agents/fix-null-condition.json
{
"id": "fix-null-condition",
"prompt": "Fix saving rules with a null condition",
"fixture": "fixtures/null-condition",
"setup": ["npm ci"],
"runs": 5,
"graders": [
{ "type": "shell", "cmd": "npm test -- null-condition", "critical": true },
{ "type": "shell", "cmd": "git diff --check" },
{ "type": "forbidden", "pattern": "it\\.skip|xit\\(", "message": "must not disable tests" }
]
}
Nun kommen die Bewertungssysteme. Eines führt Shell-Befehle wie das Testframework aus, ein anderes scannt die Bahn nach unzulässigen Änderungen, und ein Bewertungsmodell, das nicht erkennen kann, welche Variante es bewertet, kümmert sich um die subjektiven Qualitäten.
# graders.py
import re, subprocess
def shell(step, ctx):
r = subprocess.run(step["cmd"], cwd=ctx.workdir, shell=True,
capture_output=True, text=True)
ok = r.returncode == 0
return {"pass": ok, "score": 1 if ok else 0, "detail": r.stdout[-400:]}
def forbidden(step, ctx):
bad = re.search(step["pattern"], ctx.diff) is not None
return {"pass": not bad, "score": 0 if bad else 1,
"detail": step["message"] if bad else ""}
def judge(step, ctx):
v = ctx.llm.rate(step["rubric"], ctx.artifact) # 0..1, blinded
return {"pass": v >= step.get("threshold", 0.7), "score": v}
GRADERS = {"shell": shell, "forbidden": forbidden, "judge": judge}3. Metrics. Success rate, pass@k, pass^k, and the routing confusion matrix — exactly the numbers from earlier.
Das Metrics-Modul wandelt Listen von Ausführungsergebnissen in Zahlen um:
# metrics.py
def success_rate(rs):
return sum(1 for r in rs if r["pass"]) / len(rs)
def pass_at_k(rs):
return 1 if any(r["pass"] for r in rs) else 0
def pass_hat_k(rs):
return 1 if all(r["pass"] for r in rs) else 0
def routing(positives, negatives, fired):
tp = sum(1 for p in positives if fired(p))
fp = sum(1 for n in negatives if fired(n))
fn = len(positives) - tp
tn = len(negatives) - fp
return {"tp": tp, "fp": fp, "fn": fn, "tn": tn,
"precision": tp / (tp + fp or 1),
"recall": tp / (tp + fn or 1)}4. The runner. One function per suite. The agent runner repeats each case so pass^k is meaningful; the skill runner just asks the router which skills fire.
Ein Läufer lädt die Fälle, ruft die Bewertungsprogramme auf, wiederholt jeden Lauf und gibt die Metriken aus:
# runner.py
import json
from graders import GRADERS
from metrics import success_rate, pass_at_k, pass_hat_k, routing
def run_agent_case(agent, path):
c = json.load(open(path))
runs = []
for _ in range(c.get("runs", 3)):
ctx = agent.run(c["prompt"], fixture=c["fixture"], setup=c["setup"])
ok = True
for step in c["graders"]:
g = GRADERS[step["type"]](step, ctx)
if step.get("critical") and not g["pass"]:
ok = False
runs.append({"pass": ok})
return {"id": c["id"], "success": success_rate(runs),
"pass_at_k": pass_at_k(runs), "pass_hat_k": pass_hat_k(runs)}
def run_skill_trigger(router, path):
c = json.load(open(path))
fired = lambda prompt: c["skill"] in router.route(prompt)
return {"skill": c["skill"], **routing(c["positives"], c["negatives"], fired)}5. Run it. The CLI just dispatches on the case type and prints the metrics.
Beim Ausführen wird eine Ausgabe dieser Art erzeugt:
$ python run.py cases/agents/fix-null-condition.json
fix-null-condition success=0.80 pass@5=1.00 pass^5=0.20
$ python run.py cases/skills/security-review.trigger.json
security-review precision=0.86 recall=1.00 (tp=6 fp=1 fn=0 tn=5)
Lesen Sie diese Zeilen so, wie es dieser Ansatz empfiehlt. Der Agent führt vier Ausführungen in fünf durch, sodass pass@5 perfekt erscheint, doch pass^5 mit einem Wert von 0,20 zeigt an, dass er noch nicht zuverlässig ist. Die Fähigkeit erfasst jede echte Anfrage mit einer Recall-Wert von 1,0, löste aber einmal einen Alarm aus, obwohl das nicht nötig war, mit einer Precision von 0,86 – es muss also ein falscher Auslöser beseitigt werden.
Darum dienen die Bewertungen: Um „es schien zu funktionieren“ in Zahlen umzuwandeln, die man verbessern kann. Beginnen Sie mit einer solchen Grundstruktur, fügen Sie jeweils einen Fall hinzu, wenn etwas nicht funktioniert, und lassen Sie die Regressionsdatenmenge zu Ihrer eigenen Definition von Qualität heranwachsen.
Nutzen Sie ein vorhandenes Framework, wenn möglich
Eine selbst erstellte Grundstruktur eignet sich gut zum Erlernen der Mechanismen und für vollständige Kontrolle, doch ausgereifte Open-Source-Projekte bieten bereits Ausführungen, Bewertungstools, Datensätze und Dashboards. Schauen Sie sich diese an, bevor Sie Ihr eigenes erstellen.
Allgemeine Prompt- und LLM-Bewertungen
OpenAI Evals ist das ursprüngliche registrierungsbasierte Framework, das Evaluierungen in YAML definiert und mithilfe von Python-Gradern auf jedem Modell angewendet werden kann; es eignet sich für Überprüfungen auf Ausgabenebene und bei Klassifizierungen. promptfoo wird durch Konfiguration gesteuert, zeigt Prompts im Vergleich zu Modellen in einer Seite-an-Seite-Matrix an, bietet Aussagen wie „contains“, Regex, JSON-Schema sowie LLM-Rubriken und verfügt über einen Red-Team-Modus – dadurch ist es eine gute Grundlage für die Fähigkeitssteuerung und die Erkennung von Prompt-Regressionen. DeepEval funktioniert wie pytest für LLMs und bietet Metriken zur Treue, Relevanz und Halluzination sowie benutzerdefinierte G-Eval-Rubriken; außerdem passt es sich nahtlos in CI-Prozesse ein. Ragas richtet sich speziell an RAG-Pipelines und bewertet die Präzision und Erinnerung des Kontexts sowie die Treue und Relevanz der Antworten. Die LLM-Evaluierung von MLflow ermöglicht das Tracking und Vergleichen, falls MLflow bereits verwendet wird.
Tracking, Datensätze und Bewertungsplattformen
LangSmith bietet Datensätze, Trajektorienverfolgung sowie Bewertungstools, die nützlich sind, wenn man eine gesamte Verfolgung statt nur die Antwort überprüfen muss. Langfuse ist open source, kann selbst gehostet werden und ist modellunabhängig; es bietet Verfolgungsfunktionen, Bewertungen sowie Datensätze für die Produktüberwachung. Braintrust betrachtet Bewertungen als Teil des CI-Prozesses und bietet Bewertungsfunktionen, versionierte Datensätze sowie einen Diff-Ansicht für Experimente. Arize Phoenix basiert auf OpenTelemetry für die Trajektorienverfolgung und enthält Bewertungsvorlagen, die hilfreich sind, um Rückfälle im Live-Traffic zu erkennen. Inspect vom UK AI Safety Institute ist ein sorgfältig entworfenes Framework für Lösungsfindung und Bewertung, das zunehmend für ernsthafte Agenten- und Sicherheitsbewertungen eingesetzt wird.
Agenten-Benchmarks
SWE-bench und SWE-bench Verified sind der Standard dafür, ob ein Agent ein reales GitHub-Problem beheben kann, wobei die eigenen Tests des Repositoriums als Bewertungsmittel dienen. AgentBench, WebArena, GAIA und τ-bench bieten externe Maßstäbe für die Nutzung von Tools, Web-Aufgaben sowie mehrschrittige Agenten. Frameworks wie AutoGen und LangGraph stellen Test-Hooks bereit, um Toolaufrufe und Zwischenschritte zu überprüfen.
Auswahl
- Für Prompts und die Skill-Verwaltung allein ist promptfoo der schnellste Weg zur Konfiguration zusammen mit Überprüfungen.
- Für metrikenbasierte Ansätze, die auf Code ausgerichtet sind und in CI-Umgebungen verwendet werden können, sollten DeepEval oder Braintrust in Betracht gezogen werden.
- Um den Fortschritt mehrschrittiger Agenten zu bewerten, eignen sich LangSmith, Langfuse oder Inspect.
- Für RAG-Systeme sollte Ragas hinzugefügt werden.
- Für einen echten Benchmark für Coding-Agenten wird SWE-bench Verified verwendet.
Das Muster gilt überall: Fälle, Bewertungsmethoden, wiederholte Ausführungen sowie Überwachung im Laufe der Zeit. Ein Framework übernimmt die grundlegenden Mechanismen, daher halten Sie Disziplin bei der Auswahl des Tools, das zu Ihrem Technologiestack passt. Ein maßgeschneidertes Framework eignet sich am besten für Lücken, die diese Tools hinterlassen, oder für Projekte, die in der CI-Phase keinerlei Abhängigkeiten haben möchten.