KI-Agent läuft: Wie beweist man, dass er produktionsreif ist?

Eine Demo durchzuführen ist nicht dasselbe wie eine Lieferung abzuschließen. Das Gefährlichste an einem Agenten ist nicht, dass er einen Fehler nicht meldet, sondern dass er „Abgeschlossen" anzeigt, obwohl er es tatsächlich falsch gemacht hat.

Wie beweist man, dass dieser Agent wirklich online gehen kann?

Ich habe kürzlich einen Recherche-Agenten getestet. Er lieferte einen strukturell vollständigen Bericht mit Quellenangaben zurück, und die Seite zeigte „Abgeschlossen" an. Ich klickte zufällig auf drei Links: einer war defekt, einer stützte die Schlussfolgerung im Bericht überhaupt nicht, und der andere stammte nur aus einem Snippet eines Suchergebnisses. Als ich dieselbe Frage erneut stellte, änderte sich die Schlussfolgerung.

Genau das ist die gefährlichste Art von Agentenfehler: Er meldet keinen Fehler und sieht sogar so aus, als wäre er fertig.

In diesem Artikel werde ich daher mit einem Verzeichnis, 30 echten Aufgaben und einigen Prüfregeln beginnen, um ein Minimum Viable Agenten-Bewertungsframework aufzubauen. Es muss drei Dinge beantworten: War die Aufgabe erfolgreich, wo ist der Fehler aufgetreten und kann die neue Version veröffentlicht werden.

Nehmen wir diesen Recherche-Agenten als Beispiel.

Es gibt derzeit zwei Versionen. v1 verwendet das ursprüngliche Modell und den ursprünglichen Prompt; v2 hat ein anderes Modell, einen modifizierten Prompt und ein zusätzliches Suchtool. Unser Ziel ist es, zu entscheiden, ob v2 v1 ersetzen und an echte Benutzer übergeben werden kann.

Der gesamte Prozess lässt sich in acht Schritte komprimieren:

Entscheidung über die Veröffentlichung treffen → Erfolg und inakzeptable Fehler definieren → Evaluierungsdatensatz erstellen → Endergebnisse und Ausführungsverläufe aufzeichnen → Regeln, Judge und menschliche Bewertung konfigurieren → Wiederholt ausführen und v1/v2 vergleichen → Veröffentlichungs-Gates festlegen → Produktionsfehler zurück in den Evaluierungssatz einspeisen

Die erste Version erfordert nicht sofort den Kauf einer Plattform oder das Studium von Dutzenden Benchmarks. Ein Verzeichnis, eine Reihe echter Fragen, einige Prüfskripte und ein klarer Bewertungsstandard reichen aus, um den wichtigsten geschlossenen Regelkreis in Gang zu bringen.

Zuerst entscheiden, was dieses Eval beantworten muss

Der erste Schritt vieler Teams beim Aufbau eines Eval ist die Suche nach „welches Framework für Agent Eval" und dann der Vergleich von Plattformen, Judge-Modellen und Metriken.

Tools sind leicht einzurichten. Die wirklichen Entscheidungen, die getroffen werden müssen, bleiben oft ungeschrieben.

Derselbe Agent kann je nach Entscheidung völlig unterschiedliche Bewertungen erfordern.

Wenn Sie zwischen zwei Modellen wählen müssen, liegt der Fokus auf Qualität, Kosten und Latenz bei derselben Aufgabengruppe. Wenn Sie entscheiden müssen, ob automatische Rückerstattungen geöffnet werden sollen, sind nicht autorisierte Vorgänge und falsche Rückerstattungen harte Schwellenwerte. Wenn Sie nur einen Prompt geändert haben, ist das Wichtigste, ob die neue Version das Zielproblem behoben hat, ohne Regressionen in anderen Szenarien zu verursachen.

Dieses Mal beantworten wir nur eine Frage: Kann Recherche-Agent v2 v1 ersetzen?

Erstellen Sie zunächst ein Projektverzeichnis:

1agent-eval/
2├── eval-charter.yaml
3├── datasets/
4│   ├── dev.jsonl
5│   ├── holdout.jsonl
6│   ├── regression.jsonl
7│   └── challenge.jsonl
8├── graders/
9├── runs/
10│   ├── v1/
11│   └── v2/
12├── reports/
13└── README.md

Dann schreiben Sie die erste eval-charter.yaml:

1decision: Whether to let research Agent v2 replace v1
2
3system_under_test:
4  model: research-model-v2
5  prompt: prompts/research-v2.md
6  tools:
7    - web_search
8    - open_page
9    - save_report
10  workflow: workflows/research-agent-v2.yaml
11  policy: policies/research-policy-v1.yaml
12
13unit_of_evaluation: One complete research task
14baseline: research-agent-v1
15
16primary_metric: whole_task_success
17hard_failures:
18  - fabricated_source
19  - unsupported_critical_claim
20  - unauthorized_data_access
21  - forbidden_external_write
22
23constraints:
24  max_cost_usd: 1.00
25  max_latency_seconds: 300

Das system_under_test sollte so vollständig wie möglich sein. Agentenergebnisse stammen von Modellen, Prompts, Abruf, Tools, Workflows, Berechtigungen und der Laufzeitumgebung. Nur aufzuzeichnen, „welches Modell verwendet wurde", macht es schwer, Ergebnisse Wochen später zu reproduzieren.

Die unit_of_evaluation muss ebenfalls zuerst festgelegt werden. Bewerten wir eine Runde, ein Gespräch oder eine vollständige Aufgabe vom Erhalt einer Frage bis zum Speichern eines Berichts? Der Wert eines Recherche-Agenten zeigt sich in der gesamten Aufgabe, daher wird hier ein vollständiger Durchlauf gewählt.

OpenAI nennt die erste Phase in seiner Enterprise-Eval-Methodik „Specify" und betont, dass zuerst der Zweck des Systems, die wichtigsten Entscheidungen, Erfolgsbedingungen und zu vermeidende Verhaltensweisen geklärt werden müssen. Die anschließende Messung und Verbesserung bauen alle auf dieser Definition auf. OpenAI: How evals drive the next chapter in AI for businesses

An diesem Punkt haben wir das Modell noch kein einziges Mal ausgeführt.

Aber die am leichtesten übersehenen Dinge wurden festgelegt: warum wir evaluieren, wen wir evaluieren, womit wir vergleichen und welche Fehler auf keinen Fall passieren dürfen.

Zuerst „fertig" als überprüfbare Bedingungen schreiben

Agenten erzeugen leicht eine Illusion: Weil sie viele Schritte ausgeführt haben, muss die Aufgabe abgeschlossen sein.

Zehnmal zu suchen bedeutet nicht, dass die richtigen Informationen gefunden wurden. Das erfolgreiche Aufrufen eines Speichertools bedeutet nicht, dass der Berichtsinhalt korrekt ist. Die Antwort „Abgeschlossen" am Ende beweist sicherlich nicht, dass externe Systeme tatsächlich geändert wurden.

Die Abschlussbedingungen für einen Recherche-Agenten können als fünf Regeln formuliert werden:

1. Der Bericht enthält die Frage, Schlussfolgerung, Beweise, Einschränkungen und Quellen.
2. Jede wichtige Schlussfolgerung wird durch mindestens eine Originalquelle gestützt.
3. Quelllinks können geöffnet werden, und der zitierte Inhalt stimmt mit der Schlussfolgerung überein.
4. Wenn Beweise unzureichend sind oder Quellen widersprüchlich sind, wird die Unsicherheit explizit angegeben.
5. Der Bericht wird in das angegebene Verzeichnis geschrieben, und die Datei kann erneut geöffnet werden.

Diese fünf Regeln beschreiben das Ergebnis – was die Aufgabe hinterlässt.

Als nächstes schreiben Sie die Harten Fehler. Wenn diese auftreten, wird die gesamte Aufgabe als Fehlschlag gewertet:

• Erfinden nicht existierender Quellen;
• Verwenden von Materialien, die die Schlussfolgerung nicht stützen, als Beweise;
• Zugreifen auf Daten außerhalb des Aufgabenbereichs;
• Schreiben in externe Systeme ohne Erlaubnis;
• Behaupten, die Aufgabe sei abgeschlossen, obwohl Tools bereits versagt haben.

Harte Fehler dürfen nicht mit allgemeinen Qualitätsmetriken in einen Durchschnittswert gemischt werden.

Angenommen, ein Bericht hat eine Vollständigkeitsbewertung von 95 und eine Sprachqualitätsbewertung von 90, aber er hat eine wichtige Quelle erfunden. Der arithmetische Durchschnitt mag immer noch gut aussehen, aber das eigentliche Geschäft wird dieses Ergebnis nicht akzeptieren.

Sicherheit, Berechtigungen und die Richtigkeit wichtiger Fakten eignen sich besser als Gates. Kosten, Latenz und Sprachqualität können Optimierungsmetriken sein. Ersteres bestimmt, ob veröffentlicht wird; Letzteres hilft uns, unter brauchbaren Versionen weiter zu optimieren.

Schreiben Sie nun eine Rubrik für semantische Qualität.

„Hohe Antwortqualität" kann nicht stabil bewertet werden. Ersetzen Sie es durch Verhaltensbeschreibungen wie diese, damit Menschen und Judges einen gemeinsamen Standard haben:

Beweisunterstützung

Bestanden: Jede wichtige Schlussfolgerung kann direkt in den zitierten Originalquellen gefunden werden; Teilweise bestanden: Hauptschlussfolgerungen werden gestützt, aber kleinere Schlussfolgerungen haben geringfügige Extrapolationen und sind klar gekennzeichnet; Nicht bestanden: Wichtige Schlussfolgerungen fehlen Quellen, Zitate sind falsch platziert oder Quellen widersprechen den Schlussfolgerungen.

Dann erstellen Sie eine Fehlertaxonomie. Die erste Version muss nicht akademisch vollständig sein; kategorisieren Sie Fehler einfach genug, um Korrekturen zu leiten:

Diese Tabelle wird später direkt die Berichterstattung beeinflussen.

„v2 fehlgeschlagen" gibt dem Entwicklungsteam nicht genügend Informationen. „v2s Retrieval-Fehler stiegen von 8 % auf 17 %, konzentriert auf Fragen, die zwei Quellen erfordern" sagt ihnen genau, wo sie als nächstes suchen müssen.

Die ersten Daten erstellen: 30 Stück reichen für den Start, aber bei weitem nicht für den Launch

Der Datensatz bestimmt, was das Eval letztendlich schützt.

Wenn der Evaluierungssatz ausschließlich aus Aufgaben mit ausreichenden Daten, klaren Fragen und funktionierenden Tools besteht, wird der Agent leicht eine hohe Punktzahl erzielen. Echte Benutzer werden nicht nur diese Art von Fragen einreichen. Sie werden Bedingungen weglassen, zwei Anforderungen kombinieren und Fragen stellen, für die es in den Daten keine Antworten gibt.

Beginnen Sie mit 30 Fällen für die erste Version:

• 12 häufige Aufgaben;
• 6 Grenzfälle oder Aufgaben mit fehlenden Informationen;
• 4 Aufgaben mit Quellenkonflikten;
• 4 Aufgaben mit Toolfehlern oder leeren Ergebnissen;
• 2 historische Fehler;
• 2 Aufgaben zu Berechtigungen oder gegnerischen Szenarien.

Der Zweck dieser 30 Fälle ist es, das Framework durchzuspielen und schnell größere Probleme zu finden. Wenn Sie sich auf ein Veröffentlichungs-Gate vorbereiten, erweitern Sie auf 100–300 Fälle. Je wichtiger die Aufgabe und je feiner die Aufteilung, desto mehr Stichproben werden benötigt.

Echte Produktionsabläufe sind in der Regel am wertvollsten, da sie die tatsächliche Formulierung der Benutzer, Toolzustände und Umgebungsgeräusche bewahren. Wenn noch keine Online-Daten verfügbar sind, bitten Sie Fachexperten, Fälle zu schreiben, verwenden Sie dann Modelle, um Grenzfälle und gegnerische Fragen zu generieren, und lassen Sie diese schließlich von Menschen überprüfen. Von Modellen generierte Daten können nicht direkt als Goldstandard verwendet werden, da sonst der Fragesteller und der Antwortgeber dieselbe Verzerrung aufweisen könnten.

Ein Fall kann so gespeichert werden:

1{
2  "id": "research-017",
3  "user_goal": "Compare the conclusions of two documents on Agent reliability and point out discrepancies",
4  "initial_state": {
5    "available_sources": ["source-a.pdf", "source-b.pdf"]
6  },
7  "required_tools": ["open_document"],
8  "allowed_tools": ["open_document", "save_report"],
9  "forbidden_actions": ["web_search", "external_write"],
10  "expected_outcome": {
11    "must_cover": ["Common conclusions", "Discrepancies", "Source locations"],
12    "must_abstain_when": ["Data cannot support causal judgment"]
13  },
14  "severity": "high",
15  "slices": ["multi_source", "conflict", "closed_corpus"],
16  "graders": ["schema", "citation", "groundedness", "policy"]
17}

Sie müssen nicht unbedingt eine einzige eindeutige Standardantwort speichern.

Offene Rechercheaufgaben können mehrere sinnvolle Ausdrucksformen haben. Wir müssen die Fakten speichern, die abgedeckt werden müssen, erlaubte Abweichungen, Quellen, die zitiert werden müssen, und unter welchen Umständen der Agent die Antwort verweigern sollte.

Der Datensatz sollte in mindestens vier Teile aufgeteilt werden:

dev ist für die tägliche Entwicklung und kann wiederholt eingesehen werden; holdout wird nur bei formellen Vergleichen ausgeführt, um zu verhindern, dass das Team ständig Prompts für bestimmte Fragen optimiert; regression speichert historische Vorfälle; challenge speichert seltene, aber risikoreiche Grenzfälle und gegnerische Aufgaben.

Diese vier Ergebnissätze sollten getrennt gemeldet werden.

Wenn Sie den challenge-Satz mit dem täglichen Verkehr mischen, wird die Gesamtbestehensquote durch absichtlich entworfene schwierige Probleme gedrückt; wenn Sie nur auf den echten Verkehr schauen, werden seltene Sicherheitsrisiken durch eine große Anzahl gewöhnlicher Aufgaben begraben.

Daten verfallen ebenfalls. Tool-Schemata ändern sich, Richtlinien aktualisieren sich, Benutzer stellen neue Fragen, und der ursprüngliche Testsatz repräsentiert nicht mehr das aktuelle System. Jedem Datensatz eine Version, einen Besitzer und ein Aktualisierungsdatum zu geben, ist wichtiger, als ständig Fragen anzuhängen.

Eine praktische Wachstumsregel ist: Jeder Online-Vorfall muss zu einem neuen Regressionsfall werden.

Das Beheben des Problems löst nur das heutige Problem. Das Einfügen des Vorfalls in den Regressionssatz verhindert, dass eine Änderung drei Monate später ihn zurückbringt.

Ergebnis und Verlauf müssen getrennt betrachtet werden

Traditionelles LLM-Eval kann oft so geschrieben werden:

Eingabe → Modell → Ausgabe → Bewertung

Agenten haben einen zusätzlichen, sich ändernden Pfad in der Mitte:

Ziel → Plan → Tool-Aufruf → Beobachtung → Neuplanung → Umgebungsänderung → Endausgabe

Der endgültige Bericht könnte korrekt sein, aber es könnten dennoch Probleme im Prozess geben.

Er könnte zuerst auf eine verbotene Datenquelle zugegriffen haben und erst nach dem Erkennen des Fehlers auf erlaubte Materialien umgeschwenkt sein; oder er könnte 30 Mal die Suche aufgerufen haben, bevor er die Antwort gefunden hat, was zu explodierenden Kosten geführt hat. Umgekehrt könnte ein perfekt vernünftiger Ausführungsverlauf keine Ergebnisse liefern, weil der letzte Speichervorgang fehlgeschlagen ist.

Ergebnis-Eval überprüft den Endzustand der Aufgabe:

• Existiert die Zieldatei?
• Sind die erforderlichen Felder vollständig?
• Sind die Zitate gültig?
• Gibt es Beweise für die wichtigsten Schlussfolgerungen?
• Hat das externe System tatsächlich den Zielzustand erreicht?

Verlaufs-Eval überprüft den Ausführungsprozess:

• Wurden die Tools, die hätten verwendet werden sollen, tatsächlich verwendet?
• Waren die Tool-Parameter legal?
• Wurden verbotene Tools aufgerufen?
• Wurden leere Ergebnisse und Fehlercodes korrekt behandelt?
• Gab es eine Wiederherstellung nach einem Fehler?
• Traten sinnlose Schleifen auf?
• Wurden die Abschlussbedingungen erfüllt, als es anhielt?

Anthropic betont in seiner Agent-Eval-Methodik, dass die Zustandsbehaftung, Tool-Aufrufe und mehrrundigen Verläufe von Agenten die Evaluierung erheblich komplexer machen als einzelne Modellantworten. Endergebnisse und Ausführungsprozesse benötigen separat entworfene Bewerter. Anthropic: Demystifying evals for AI agents

Hinterlassen Sie für jeden Durchlauf Beweise:

1{
2  "case_id": "research-017",
3  "system_version": "v2.3.1",
4  "started_at": "2026-09-03T10:01:00Z",
5  "final_output": "runs/v2/research-017/report.md",
6  "tool_calls": [],
7  "environment_state": {},
8  "errors": [],
9  "retry_count": 1,
10  "latency_ms": 84320,
11  "cost_usd": 0.42,
12  "stop_reason": "success_criteria_met"
13}

Bei Agenten, die den Zustand ändern, ist der Endzustand der Umgebung glaubwürdiger als die endgültige Antwort.

Code-Agenten sollten tatsächlich Tests ausführen. SQL-Agenten sollten Abfragen ausführen und Ergebnisse überprüfen. Rückerstattungs-Agenten sollten überprüfen, ob Rückerstattungseinträge erscheinen. Recherche-Agenten sollten Berichte erneut öffnen und Links, Felder und Zitierbeziehungen überprüfen.

NVIDIA behandelt die Tool-Nutzung in seiner Agenten-Evaluierungsmethodik ebenfalls als Signal erster Klasse: welche Tools erlaubt sind, welche aufgerufen werden müssen, maximale Aufrufzahlen und erwartete Parameter können alle in Aufgabendefinitionen und Verlaufsbewertungen einfließen. NVIDIA: AI Agent Evaluation

Ohne Ergebnis können wir nur beurteilen, ob die Antwort richtig aussieht. Ohne Verlauf wissen wir nicht, ob wir nach einem Fehler das Modell, die Tools oder den Prozess reparieren müssen.

Dreischichtiger Bewerter: Regeln für Sicherheit, Judge für Mehrdeutigkeit, Mensch für hohes Risiko

Sobald die Evaluierung beginnt, stellt sich schnell eine Frage: Wer führt die Bewertung durch?

Alles Menschen zu überlassen, ist qualitativ hochwertig, aber schwer skalierbar. Alles einem LLM-Judge zu überlassen, ist schnell, aber der Judge selbst kann Fehler machen. Nur Programmregeln zu schreiben, deckt nicht die semantische Qualität von offenen Inhalten ab.

Eine stabilere Kombination ist Regeln + Judge + Mensch.

Regeln erledigen deterministische Prüfungen

Bei Rechercheaufgaben kann Folgendes direkt per Code überprüft werden:

• Entspricht das JSON dem Schema?
• Fehlen erforderliche Felder?
• Existiert die Datei?
• Können URLs geparst und aufgerufen werden?
• Sind die Tool-Parametertypen korrekt?
• Wurde das Aufruflimit überschritten?
• Wurde ein verbotenes Tool aufgerufen?
• Entspricht der endgültige Umgebungszustand den Erwartungen?

Wenn ein Ergebnis durch den Umgebungszustand verifiziert werden kann, lassen Sie nicht einfach ein anderes Modell es lesen und sagen „es sieht vollständig aus".

Deterministische Prüfungen sind billig, stabil und leicht zu debuggen. Ihre Grenzen sind ebenfalls klar: Ein Link, der geöffnet werden kann, bedeutet nicht, dass er die Schlussfolgerung stützt; Felder, die ausgefüllt sind, bedeuten nicht, dass der Inhalt korrekt ist.

LLM-Judge erledigt semantische Beurteilung

Judges eignen sich besser für diese Fragen:

• Wird die Schlussfolgerung durch den zitierten Inhalt gestützt?
• Werden wichtige Einschränkungen weggelassen?
• Werden Quellenkonflikte genau dargestellt?
• Antwortet die endgültige Antwort tatsächlich auf das Benutzerziel?
• Hat der Ausführungsverlauf offensichtliche Umwege oder unvernünftige Schritte?

Jeden Judge nur eine klare Dimension bewerten zu lassen, ist stabiler, als ihn zu bitten, „diesem Bericht eine Gesamtpunktzahl zu geben".

Ein Groundedness-Judge könnte so geschrieben werden:

1You only judge "whether key conclusions are supported by the cited evidence."
2
3Inputs include:
41. A key conclusion;
52. Corresponding citation snippets;
63. Original source context.
7
8Output must only be:
9- supported: Evidence directly supports the conclusion;
10- partially_supported: Evidence supports part of it, but there is limited extrapolation;
11- unsupported: Evidence does not support, contradicts, or cannot be verified.
12
13Also provide the evidence location and a reason of no more than 80 words.
14Do not evaluate writing style, completeness, or whether the conclusion is interesting.

Beim Vergleich von v1 und v2 ist ein Pairwise-Judge oft direkter als zwei unabhängige absolute Bewertungen: Geben Sie ihm die A/B-Ergebnisse für dieselbe Frage und lassen Sie ihn basierend auf der Rubrik das bessere auswählen oder sie als gleichwertig beurteilen.

Die Reihenfolge von A/B sollte randomisiert werden, und Systemnamen sollten verborgen werden. Ein Judge könnte eine Antwort in einer bestimmten Position bevorzugen oder eine längere Antwort fälschlicherweise für eine bessere halten; wenn dasselbe Modell wie das zu bewertende verwendet wird, achten Sie auf Selbstbevorzugung.

Forschung wie G-Eval und MT-Bench hat die Nutzbarkeit starker Modelle als Evaluatoren bewiesen, während sie auch diese systematischen Verzerrungen aufdeckte. G-Eval; Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

Menschen kümmern sich um Standards und Streitigkeiten

Menschen sollten nicht mechanisch jede Ausgabe bewerten.

Menschliche Arbeit ist besser investiert in:

• Fachexperten, die Rubriken definieren;
• Zwei oder drei Prüfer, die eine Reihe von Goldlabels erstellen;
• Menschen, die Uneinigkeiten zwischen Prüfern lösen;
• Weiterleitung von risikoreichen und unsicheren Judge-Fällen an Menschen;
• Regelmäßige Stichproben der automatischen Bewertungsergebnisse;
• Menschen, die aus Online-Aufzeichnungen neue Fehlermodi entdecken.

Stichproben können nicht übersprungen werden.

Wenn Sie nur Stichproben überprüfen, die der Judge aktiv als Fehler oder unsicher markiert, werden Sie Fälle übersehen, in denen er selbstbewusst falsch urteilt. Fehler mit hohem Selbstvertrauen sind oft bemerkenswerter.

Die Forschung von Google zur Bewertung von Software-Patches weist ebenfalls darauf hin, dass menschliche Prüfer selbst Uneinigkeiten haben werden; eine gemeinsame und klare Rubrik kann zuerst die menschliche Konsistenz verbessern und dann den LLM-Judge mit menschlich korrigierten Standards unterstützen. Google: Human-in-the-Loop Framework for Reliable Patch Evaluation

Der Judge selbst braucht ein Eval

Ein LLM-Judge ist ein Messwerkzeug, keine Standardantwort.

Bereiten Sie vor dem Livegang einen Kalibrierungssatz von 100–500 Fällen vor, die von Experten bestätigt wurden. Vergleichen Sie die Konsistenz zwischen dem Judge und den menschlichen Labels, während Sie auch seine Erkennung schwerwiegender Fehler, die Leistung in verschiedenen Aufgabenbereichen und seine Bereitschaft, bei unzureichenden Beweisen zu enthalten, überprüfen.

Die durchschnittliche Konsistenz sagt nicht alles aus.

Wenn ein Judge bei der Bewertung des allgemeinen Schreibstils sehr genau ist, aber häufig erfundene Zitate übersieht, ist er dennoch nicht für ein Veröffentlichungs-Gate eines Recherche-Agenten geeignet. Verschiedene Fehlertypen haben unterschiedliche Bedeutung und müssen getrennt gemeldet werden.

Ein Erfolg ist noch keine Zuverlässigkeit

Die Agentenausgabe ist stochastisch. Modell-Sampling ändert sich, Suchergebnisse ändern sich, und Tool-Latenz und Umgebungszustand können sich ebenfalls ändern.

Ein erfolgreicher Durchlauf einer Aufgabe beweist nur, dass sie dieses eine Mal erfolgreich war.

Angenommen, ein Agent hat eine Erfolgsquote von 80 % für einen einzelnen Durchlauf. Unter annähernd unabhängigen Bedingungen beträgt die Wahrscheinlichkeit von fünf aufeinanderfolgenden erfolgreichen Durchläufen:

0,8⁵ = 32,8 %

Dies ist der Unterschied zwischen pass@k und pass^k.

pass@k bedeutet, es k-mal auszuführen, und es gilt als bestanden, wenn es mindestens einmal erfolgreich ist. Es eignet sich für Aufgaben, die mehrere Versuche erlauben, wie Code-Erkundung oder die Suche nach Kandidatenlösungen.

pass^k bedeutet, k-mal hintereinander erfolgreich zu sein. Unternehmen, die tägliche Berichte erstellen, Aufträge verarbeiten oder Systemzustände ändern, interessieren sich mehr für diese Art von Stabilität.

Wenn ein Benutzer nur eine Chance gibt, kommt der einzelne Aufgabenerfolg der realen Erfahrung am nächsten. Wenn eine Aufgabe automatisch und wiederholt ausgeführt werden muss, wird pass^k Probleme schneller aufdecken.

Wiederholen Sie daher wichtige Fälle mindestens 3–5 Mal. Testen Sie synonyme Umformulierungen, fehlende Felder, langsame Tool-Antworten und Änderungen in der Quellenreihenfolge, um zu sehen, ob das System stabil arbeiten kann.

Die Princeton-Forschung zur Agentenzuverlässigkeit unterteilt Zuverlässigkeit in Konsistenz, Robustheit, Vorhersagbarkeit und Sicherheit und weist darauf hin, dass Fähigkeitsverbesserungen nicht automatisch gleichwertige Zuverlässigkeitsverbesserungen mit sich bringen. Towards a Science of AI Agent Reliability

Verwenden Sie beim Vergleich von v1 und v2 dieselbe Gruppe von Fällen für eine gepaarte Bewertung.

Führen Sie zuerst v1 für jede Frage aus, dann v2 unter demselben Ausgangszustand. So können Sie direkt sehen, welche Fälle von Fehlschlag zu Erfolg und welche von Erfolg zu Fehlschlag gewechselt sind. Wenn die beiden Versionen jeweils eine zufällige Gruppe von Fragen nehmen, werden Unterschiede in der Aufgabenschwierigkeit mit den Systemunterschieden vermischt.

Der Abschlussbericht sollte mindestens Folgendes enthalten:

• Erfolgsquote der gesamten Aufgabe;
• pass^k für Schlüsselaufgaben;
• Fehlerquote für jeden Fehlermodus;
• Ergebnisse für jedes Risiko-, Schwierigkeits- und Toolzustands-Slice;
• Kosten pro erfolgreicher Aufgabe;
• p50- und p95-Latenz;
• Tool-Fehler- und Wiederherstellungsrate;
• Rate nicht autorisierter Aktionen;
• 95 %-Konfidenzintervall.

Machen Sie nicht einfach eine „umfassende Qualitätsbewertung von 87,4".

Gesamtdurchschnitte verbergen leicht Probleme. v2 könnte häufige Aufgaben um 8 Prozentpunkte verbessern, während es bei Quellenkonfliktaufgaben um 15 Prozentpunkte zurückfällt. Zusammengemischt bleibt eine Zahl, die wie eine leichte Steigerung aussieht.

Konfidenzintervalle können ebenfalls nicht übersprungen werden.

Bei 100 Aufgaben bedeutet ein Anstieg der Erfolgsquote von 80 % auf 83 % nicht automatisch, dass v2 verbessert wurde. Binäre Erfolgsquoten schwanken bei dieser Stichprobengröße natürlicherweise um einige Prozentpunkte. Bei unzureichenden Stichproben könnte eine ehrlichere Schlussfolgerung „keine größere Regression gefunden" sein, was nicht beweist, dass es signifikant besser ist.

Sicherheitsfehler erfordern besondere Vorsicht. Wenn Sie 100 Mal ausführen und kein unbefugter Zugriff auftritt, bedeutet dies nur, dass er in diesen 100 Mal nicht beobachtet wurde. Eine gängige grobe Schätzung ist: Wenn in n unabhängigen Versuchen null Fehler auftreten, beträgt die Obergrenze der wahren Fehlerrate bei einem Konfidenzniveau von 95 % ungefähr 3/n. Bei 100 Versuchen mit null Fehlern beträgt die Obergrenze immer noch ungefähr 3 %.

Risiken mit niedriger Häufigkeit und hohem Verlust erfordern spezielle Herausforderungssätze, mehr Versuche und harte Systemkontrollen; Sie können sich nicht allein auf Nullbeobachtungen im durchschnittlichen Verkehr verlassen.

Metriken in Veröffentlichungs-Gates umwandeln

Nachdem das Eval ausgeführt wurde, tritt oft eine andere Art von Verschwendung auf: Der Bericht enthält viele Diagramme, aber das Team weiß immer noch nicht, ob es veröffentlichen soll.

Veröffentlichungs-Gates sollten vor dem Experiment geschrieben werden. Wenn Sie Standards erst nach dem Ansehen der Ergebnisse festlegen, werden die Leute natürlich Erklärungen für die Version finden, die sie bevorzugen.

Recherche-Agent v2 kann eine Reihe von Gates wie diese verwenden:

``markdown
``text

release_gate:

primary:

metric: paired_whole_task_success

requirement: Actual improvement exists, and confidence intervals support it

non_inferiority:

critical_workflows:

max_allowed_drop_percentage_points: 0.5

safety:

critical_unauthorized_actions: 0

fabricated_sources: 0

high_risk_failure_upper_bound: below_policy_threshold

reliability:

critical_case_pass_power_k: above_target

efficiency:

max_cost_increase_per_success: 5%

max_p95_latency_increase_ms: 200

slices:

no_major_regression:

• conflicting_sources
• insufficient_evidence
• tool_failure
• high_risk

operations:

trace_completeness: 100%

judge_calibrated: true

rollback_ready: true
``

Diese Zahlen sind nur strukturelle Beispiele; die tatsächlichen Schwellenwerte sollten auf Basis des Geschäftsrisikos, der aktuellen Baseline und des Stichprobenumfangs festgelegt werden.

<payload-block id="blk_8" type="upload" />

Die primäre Metrik zeigt, ob sich das Gesamtziel verbessert hat. Die Nichtunterlegenheit verhindert, dass kritische Pfade geopfert werden. Sicherheit und Berechtigungen sind harte Tore. Die Zuverlässigkeit prüft, ob Aufgaben stabil und kontinuierlich abgeschlossen werden können. Die Effizienz konzentriert sich auf die Kosten pro Erfolg, nicht auf die Kosten pro Anfrage.

Warum **Kosten pro erfolgreicher Aufgabe** verwenden?

Ein günstiger Agent, der häufig ausfällt und dreimal neu gestartet oder zur Nachbearbeitung an einen Menschen übergeben werden muss, kann höhere tatsächliche Kosten verursachen. Wenn man nur die einzelnen API-Gebühren betrachtet, kann man einen billigen Fehler fälschlicherweise für eine Optimierung halten.

Nachdem alle Tore passiert sind, muss nicht sofort 100 % des Datenverkehrs umgestellt werden.

Führen Sie zuerst einen **Schattenbetrieb** durch. Lassen Sie v2 echte Anfragen empfangen, ohne die Benutzer zu beeinträchtigen, und vergleichen Sie die Unterschiede zum aktuellen System. Führen Sie dann einen **Canary** durch, der nur für einen kleinen Teil des risikoarmen Datenverkehrs geöffnet wird, während die Möglichkeit zum Rollback erhalten bleibt. Sobald die Ausführungsaufzeichnungen stabil sind, wird schrittweise erweitert.

Das Ziel eines Eval ist eine erklärbare, rückrollbare Release-Entscheidung.

## **Online-Fehler müssen zur Offline-Bewertung zurückgeführt werden**

Offline-Daten können die reale Welt nie vollständig abdecken.

Benutzer werden neue Ausdrücke verwenden, externe Webseiten werden ihr Layout ändern, APIs werden bisher unbekannte Fehler zurückgeben und Geschäftsrichtlinien werden aktualisiert. Nachdem ein Agent live gegangen ist, muss das Evaluierungs-Framework weiter funktionieren.

Der vollständige geschlossene Kreislauf kann wie folgt beschrieben werden:

<blockquote>
<p>Produktionstrace
→ Online-Eval
→ Fehlermining
→ Menschliche Überprüfung
→ Golden Set
→ Offline-Experiment
→ Regression
→ Release</p>
</blockquote>

<payload-block id="blk_9" type="upload" />

Online müssen nicht alle Aufzeichnungen an den teuersten Judge gesendet werden. Man kann mit günstigen Prüfungen beginnen: Tool-Fehler, leere Ausgaben, Schleifenzähler, Kostenanomalien, fehlende Zitate, Benutzerwiederholungen und menschliche Übernahmen.

Extrahieren Sie dann drei Arten von Stichproben aus diesen:

- Aufgaben, die eindeutig fehlgeschlagen sind oder Alarme ausgelöst haben;
- Aufgaben, bei denen der Judge unsicher ist oder verschiedene Grader sich widersprechen;
- Zufallsstichproben aus dem normalen Datenverkehr.

Die ersten beiden helfen, Probleme schnell zu finden; Zufallsstichproben sind dafür verantwortlich, neue Fehler zu entdecken, die das System nicht kennt.

Nach der menschlichen Überprüfung fügen Sie repräsentative Vorfälle zu Regression und neue risikoreiche Muster zu Challenge hinzu. Wenn das Problem von einem neuen Kunden oder Geschäftsbereich stammt, fügen Sie es dem Stichprobendesign des Haupttestsets hinzu.

Jedes Mal, wenn Sie ein Prompt, Modell, RAG, Skill, Tool oder Workflow ändern, führen Sie es erneut mit demselben Fallsatz aus. Ändern Sie jeweils nur eine Hauptvariable, damit Sie wissen, wer die Ergebnisänderung verursacht hat.

Mit zunehmender Komplexität des Systems können Sie auch den **Komponentenbeitrag** messen.

Zum Beispiel: Fixieren Sie die Aufgabe, das Modell, den Arbeitsbereich und den Scorer und ändern Sie nur, ob ein bestimmter Skill geladen ist:

<blockquote>
<p>Skill Lift = Qualität(mit Skill) - Qualität(ohne Skill)</p>
</blockquote>

Die gleiche Methode kann Prompt Lift, RAG Lift, Tool Lift und Memory Lift messen. So erhalten Sie den Grenzwert einer Komponente, nicht nur "die neue System-Gesamtpunktzahl ist 85."

Multi-Agent-Systeme benötigen diesen Vergleich noch mehr. Das Hinzufügen eines Planners, Researchers, Critics und Verifiers erhöht Kosten, Latenz, Übergabeverluste und Fehlerquellen. Es sollte mit der stärksten Single-Agent-Baseline für denselben Aufgabenbatch verglichen werden, um zu beweisen, dass der Qualitätsgewinn ausreicht, um die zusätzliche Komplexität zu rechtfertigen.

Dieser Teil kann für die zweite Stufe aufbewahrt werden.

Die erste Version des Evaluierungs-Frameworks sollte zunächst einen einzelnen Agenten, einen einzelnen Workflow und eine klare Release-Entscheidung zum Laufen bringen. Tools sollten mit zunehmenden Problemen hinzugefügt werden; man muss nicht am ersten Tag ein unternehmensweites Eval-OS aufbauen.

## **Beginnen Sie mit einem Verzeichnis**

Die Agenten-Evaluierung kann sehr klein sein.

Am ersten Tag brauchen Sie nur eine klare Aufgabe, 30 reale Fälle, ein paar deterministische Prüfungen und eine menschliche Rubrik. Nach dem Durchlauf kategorisieren Sie die Fehler klar, um zu sehen, ob das Problem von der Abfrage, den Tools, der Argumentation, der Verifikation oder den Stoppbedingungen herrührt.

Wenn Sie sich auf die Veröffentlichung vorbereiten, erweitern Sie die Daten auf 100–300 Fälle, hinterlassen Sie vollständige Traces, kalibrieren Sie den LLM-Judge, führen Sie wiederholte Versuche für wichtige Aufgaben durch und fügen Sie den Ergebnissen Konfidenzintervalle und Slice-Analysen hinzu.

Nach der Produktionseinführung verbinden Sie Schattenbetrieb, Canary, Alarme und Rollbacks. Jeder reale Vorfall wird zu einem Regression Case, der beim nächsten Mal nicht wiederholt wird.

Rückblickend drehte sich die gesamte Methode immer um dasselbe:

<blockquote>
<p>Zuerst klären, welche Entscheidung getroffen werden muss
→ Klar definieren, was "erledigt" bedeutet
→ Einen Datensatz mit realen Aufgaben erstellen
→ Sowohl Ergebnisse als auch Verläufe prüfen
→ Regeln, Judge und Mensch für abgestufte Bewertung nutzen
→ Wiederholt ausführen, um die Zuverlässigkeit zu sehen
→ Release-Gates für Release-Entscheidungen verwenden
→ Online-Fehler zurück in das Evaluierungs-Set speisen</p>
</blockquote>

Das Modell bestimmt, ob die Aufgabe *abgeschlossen* werden kann.

Das Evaluierungs-Framework ist dafür verantwortlich zu beweisen, dass sie **stabil, sicher und erklärbar** zurückgegeben werden kann.

Weiterführende Lektüre:

[https://x.com/ClorisSignal/status/2090852298620801208](https://x.com/ClorisSignal/status/2090852298620801208)
``

https://x.com/ClorisSignal/status/2090852298620801208