Zum Inhalt springen

Wissensbasis

Nicht-deterministische Systeme evaluieren

Wie ihr Output testet, der von Lauf zu Lauf schwankt, von Unit-Tests bis zu Baselines für Erfolgsquoten, und was ein öffentliches Eval-Leaderboard beweist und was nicht.

Verfasst von

Aktualisiert:

Agentic Engineering 5

Unsere Position. Wir lassen eine Evaluation ihr Urteil begründen, denn die Begründung ist das Signal (öffnet in einem neuen Tab), ein nackter Score ist es nicht. Eine neue Modellversion erbt nicht das Vertrauen, das der alte Harness hatte: sie muss es sich selbst verdienen (öffnet in einem neuen Tab).

Die Grader brauchen dieselbe Sorgfalt wie der Agent. Gestaffelte Checks laufen mit dem billigsten zuerst, und jeder Grader wird an bekannt gutem und schlechtem Output kalibriert. Ein Holdout-Set verhindert, dass eine Optimierungsschleife ihren eigenen Fix bewertet.

Wie evaluiert ihr Output, der von Lauf zu Lauf schwankt?

Tests und Gates prüfen den Code, den ein Agent schreibt. Eine eigene Disziplin daneben prüft das Agentensystem selbst. Sie kann dafür nicht dieselben Tools nutzen, denn das Testobjekt ist nicht-deterministisch. Dieselbe Eingabe liefert verschiedene Ausgaben, und schon kleine Änderungen am Prompt verschieben sie. Ein einzelner Lauf mit Pass oder Fail beweist deshalb nichts. Die Methode, die funktioniert, ist statistisch. Ihr zerlegt den Agenten in deterministische Teile wie Tool Calls, Berechnungen und den Umgang mit strukturierten Daten, die gewöhnliche Unit-Tests bekommen. Die nicht-deterministischen Teile evaluiert ihr über eine Verteilung. Behandelt jede Änderung als statistisches Experiment, ob Prompt-Anpassung, Modell-Upgrade oder verschobener Parameter. Sammelt eine Baseline über viele Läufe, führt die Änderung ein und vergleicht die Verteilungen mit Konfidenzintervallen, statt ein Einzelergebnis zu behaupten. Manche Ausgaben sind zu offen für einen exakten Abgleich. Dort entscheidet ein LLM als Klassifikator anhand expliziter Kriterien, ob der Freitext Pass oder Fail ist, bei unklaren Fällen per Mehrheitsentscheid (How to test AI agents (öffnet in einem neuen Tab)).

Auch die Eval-Suite selbst muss stimmen. Oft lügt sie, weil sie Implementierungsdetails prüft oder Fähigkeiten testet, die schon in den Trainingsdaten stecken. Vercel hat die eigene Suite gehärtet: Test-Leakage entfernt, Widersprüche aufgelöst, auf verhaltensbasierte Assertions umgestellt und Aufgaben zu APIs ergänzt, die das Modell nie gesehen hat. Danach lief jede Konfiguration mit Wiederholungen, um Schwankungen des Modells auszuschließen. Erst dann bedeuteten die gemessenen Unterschiede etwas (Vercel – AGENTS.md outperforms skills in our agent evals (öffnet in einem neuen Tab), 27. Januar 2026).

Die Continuous-Delivery-Community bewertet einen Coding-Agent in drei Schichten, die billigste zuerst. Deterministische Grader prüfen Struktur, Arithmetik und Dateiverweise in Millisekunden und liefern fast keine False Positives. Transcript-Grader lesen die Abfolge der Tool Calls. Sie bestätigen, dass der Agent Belege gesammelt hat, bevor er einen Befund meldet. Ein Beispiel-Schwellwert verlangt, dass Beleg-Aktionen mindestens 40 % aller Aktionen ausmachen. LLM-Rubriken kommen zuletzt und beurteilen, was die beiden anderen Schichten nicht können, etwa Genauigkeit, Schweregrade und erfundene Befunde. Sie kosten Sekunden und Token pro Fall (MinimumCD.org and DojoConsortium.org - AI Eval Methodology for Coding Tools (öffnet in einem neuen Tab), Stand März 2026). Nach Schätzung dieses Leitfadens decken die ersten beiden Schichten 60 bis 70 % dessen ab, was ein Team braucht. Pre-Commit führt deshalb nur deterministische Grader aus, und jeder Push ergänzt Transcript-Grader. Ein Pull Request ergänzt die LLM-Rubriken, und ein Release-Branch fährt die volle Suite über mehrere Trials (MinimumCD.org and DojoConsortium.org - Team AI Evals for Coding Tools (öffnet in einem neuen Tab), Stand März 2026).

Zwei Erfolgsquoten trennen Fähigkeit von Zuverlässigkeit. pass@k ist die Wahrscheinlichkeit, dass mindestens einer von k Läufen besteht, also die Obergrenze der Fähigkeit. pass^k ist die Wahrscheinlichkeit, dass alle k Läufe bestehen. Das ist die Untergrenze der Zuverlässigkeit, von der jeder unbeaufsichtigte Einsatz abhängt. Als Referenzziele nennt der Leitfaden pass@1 über 80 %, pass@5 über 95 % und pass^5 über 60 % (MinimumCD.org and DojoConsortium.org - AI Eval Methodology for Coding Tools (öffnet in einem neuen Tab), Stand März 2026). Jede Capability-Suite bekommt eine negative Zwillingssuite aus sauberen Eingaben, die keinen Befund liefern dürfen. Die negative Suite ist das Gate für ein Release und verlangt pass@1 von mindestens 90 %. Die Capability-Quoten bleiben in der frühen Entwicklung ohne Gate (MinimumCD.org and DojoConsortium.org - Team AI Evals for Coding Tools (öffnet in einem neuen Tab), Stand März 2026). Ein Plattformteam, das viele Teams bedient, liest ein dauerhaftes pass@5 über 95 % als Sättigung. Die Suite unterscheidet dann nicht mehr und braucht schwerere Fälle. Sein gemeinsames Fixture-Portfolio umfasst deshalb mehrere absichtlich fehlerhafte Repositories und ein sauberes Repository (MinimumCD.org and DojoConsortium.org - AI Evals for AI Enablement Platforms (öffnet in einem neuen Tab), Stand März 2026).

Die Grader selbst müssen ebenfalls kalibriert werden. Jeder Grader muss eine Referenzlösung bestehen lassen und bekannt schlechten Output durchfallen lassen. Jede Abweichung von einem menschlichen Urteil wird untersucht (MinimumCD.org and DojoConsortium.org - Team AI Evals for Coding Tools (öffnet in einem neuen Tab), Stand März 2026). Laut der MinimumCD-Seite stieg die gemessene Agent-Leistung im Forschungs-Benchmark CORE-Bench von 42 auf 95 %, nachdem Bugs in den Gradern behoben waren. Eine Aufgabe ist eng genug spezifiziert, wenn zwei Fachleute der Domäne denselben Output gleich bewerten würden (MinimumCD.org and DojoConsortium.org - AI Eval Methodology for Coding Tools (öffnet in einem neuen Tab), Stand März 2026).

Die Kalibrierung sieht anders aus, wo die Produktentscheidung noch offen ist. Ein Webbuch über Delegation spielt zwei Dashboard-Varianten durch. Jede setzt ihre eigene Prioritätsregel korrekt um und besteht jeden Code-Check. Die Wahl zwischen ihnen ist ein Produkturteil, das das Team noch nicht gefällt hat. Wer die bevorzugte Antwort in einen Test schreibt, codiert also eine Entscheidung, die noch niemand getroffen hat. Bewertet wird stattdessen das Reasoning des Reviewers, ob Mensch oder Agent. Geprüft wird, ob seine Befunde aus den Belegen folgen, ob er wesentliche Folgen benennt und ob er erkennt, wann er mehr Information braucht. Ein Reviewer, der immer eine Art von Fall bevorzugt, verfehlt das Urteil, das die Aufgabe verlangt. Unterschiedliche Empfehlungen bestehen dagegen, wenn ihre Begründung trägt und sie die vereinbarten Constraints einhalten. Wo es eine klare Abnahmeentscheidung gibt, zählt ihr falsche Freigaben und falsche Ablehnungen getrennt. Prüft den Reviewer an Fällen, die ihr von denen fernhaltet, mit denen ihr seine Kriterien verfeinert. Prüft ihn erneut, sobald sich sein Modell, seine Instruktionen oder seine Kriterien ändern (The Elastic Loop: Grading (öffnet in einem neuen Tab)). Sobald das Team die Regel festlegt, setzen deterministische Tests sie als schnelles Feedback durch. Ob die Regel dem Produkt noch dient, bleibt Sache von Review und Produktlernen (The Elastic Loop: Grading (öffnet in einem neuen Tab)).

Ein Modell-Upgrade läuft gegen eine aufgezeichnete Baseline. Die negativen Suites laufen zuerst, denn neue False Positives sind die wahrscheinlichste Regression. Danach vergleicht ihr pass@k und pass^k nebeneinander und lest die Transcripts auf neue Fehlermuster. Ein besserer Gesamtwert kann einzelne Aufgaben verdecken, die schlechter wurden. Deshalb vergleicht ihr Aufgabe für Aufgabe. In Produktion wird eine gescheiterte Nutzerinteraktion zu einem neuen Eval-Fall mit dem Tag Produktionsfehler. Bevor sich der Prompt ändert, wird sie auf einem minimalen Fixture reproduziert. Daneben liest das Team jede Woche fünf bis zehn Produktions-Transcripts von Hand (MinimumCD.org and DojoConsortium.org - Team AI Evals for Coding Tools (öffnet in einem neuen Tab), Stand März 2026).

In Produktion erweisen sich Evals und Observability als dasselbe Problem. Evals sind der Batch-Fall, in dem ihr die Eingaben vorher kennt, Observability ist der Echtzeit-Fall, in dem ihr sie nicht kennt. Agent-Traces, groß, tief verschachtelt und voller unstrukturiertem Text, werden so zur Grundlage für beides. Derselbe LLM-as-Judge, der einen Batch-Datensatz bewertet, läuft als Online-Eval über Live-Traces. Die ganze Schleife ist die Test-Suite des Agenten: Datensätze aufbauen, Metriken für Korrektheit und Halluzination definieren und per Hill-Climbing besser werden, ohne Regressionen einzuführen (LangChain – Interrupt 2026 keynote on the agent development lifecycle (öffnet in einem neuen Tab), 19. Mai 2026).

So skaliert ihr menschliches Urteil von Anfang an: Eine Fachperson der Domäne bewertet Traces und begründet jede Bewertung. Danach läuft ein LLM über diese Begründungen und destilliert daraus wiederverwendbare Scoring-Funktionen. So holen die besten Teams Kliniker:innen, Jurist:innen und andere Nicht-Engineers direkt in die Schleife (Braintrust – Agent observability vs traditional observability (öffnet in einem neuen Tab), 28. Mai 2026). Ein Research PM bei Anthropic beschreibt dasselbe Handwerk aus der Modellentwicklung heraus. Ein Eval nützt nur, wenn es der Form einer echten Nutzeraufgabe entspricht, statt einem Leaderboard wie Terminal Bench, das sich austricksen lässt. Schon eine Stichprobe von wenigen Dutzend Fällen kann reichen, um einen Defekt aufzudecken und dem Team ein Ziel für Hill-Climbing zu geben. Charakter und Persönlichkeit eines Modells entziehen sich der Quantifizierung. Für sie liest man Hunderte Transcripts, um Intuition aufzubauen, und lässt das Modell die eigenen Ausgaben gegen explizite Kriterien bewerten (Anthropic research PM on evals and model character (öffnet in einem neuen Tab), 17. Mai 2026).

Die Tools dafür kommen inzwischen selbst als Agent auf den Markt. Eval-Plattformen von Herstellern betten jetzt einen KI-Assistenten ein, der aus Log-Mustern Scorer und Datensätze baut. Er optimiert außerdem Prompts aus menschlichen Annotationen, gesteuert über natürliche Sprache. Ein Herstellerbeispiel ist Loop von Braintrust.

Diese Tools gehen über das Scoring hinaus und nehmen selbst Änderungen vor. Damit schließen sie eine Optimierungsschleife um die Eval-Suite. Eine Plattform beschreibt ihr Design so: Sie leitet aus Produktions-Traces Eval-Datensätze und eine priorisierte Grundursache ab. Ein Change Writer schlägt dann einen einzelnen, eng gefassten Fix vor, am Prompt, an einer Tool-Definition oder am umgebenden Code. Den Kandidaten bewertet ein Evaluator, der getrennt vom Writer gebaut und kalibriert wurde. Er bewertet ihn gegen die ganze Suite statt nur gegen den fehlschlagenden Fall, und frühere Fehler bleiben als Regressionstests erhalten. Bewegt ein Kandidat den Score auf einem Holdout-Set aus Traces nicht, wird er verworfen statt ausgeliefert. Nur eine Änderung, die die Baseline auf nie gesehenen Traces schlägt, erreicht einen Menschen als Pull Request (Optimize agent (öffnet in einem neuen Tab), Herstellerbeschreibung, Stand Juli 2026). Auf der Trennung ruht das ganze Design. Die Maschinerie, die den Fix schreibt, würde ihn bereitwillig auch selbst bewerten. Ein Evaluator, der aus derselben Diagnose stammt, die er prüfen soll, misst nichts. Erst das Holdout-Set hindert die Schleife daran, an ihrer eigenen Erklärung entlang zu optimieren.

Die tiefere Lehre: Ein Datensatz guter Ein- und Ausgaben ist keine Spezifikation. Wer spezifiziert, was ein Agent tun soll, erfasst die Regeln, die er nie brechen darf (nie mehr als 10 % Rabatt). Dazu kommen die Ontologien und internen Begriffe seiner Umgebung und die Rechte und Rollen, die sein Verhalten ändern. Hinzu kommen explizite Anforderungen an Robustheit (wie viele Tippfehler oder Umformulierungen, bis er scheitert). All das entsteht unabhängig von der Implementierung. So überleben die Tests einen Framework-Wechsel und lassen sich auf Security- und Penetrationstests umlenken. Ein größeres Modell ist nicht automatisch ein besserer oder sichererer Agent. Breite Fähigkeiten vergrößern die Angriffsfläche, und manche Jailbreaks wirken bei größeren Modellen besser, gerade weil sie den Trick verstehen. Ihr wollt ein Modell, das gut genug für die Aufgabe ist und so eng begrenzt, dass es keinen beliebigen Schaden anrichten kann (Safe Intelligence – Spec-driven validation of agents (öffnet in einem neuen Tab), 31. Mai 2026).

Ein Konferenz-Talk macht aus derselben Ontologie einen Check zur Laufzeit statt Prosa in einer Spezifikation. Liefert ein Tool Call sein Ergebnis, durchläuft es einen formalen Reasoner, bevor der Agent darauf handeln darf. So lassen sich Geschäftsinvarianten durchsetzen, die ein Shape-Validator nicht ausdrücken kann. Disjunkte Klassen fangen eine Auszahlung ab, die an die falsche Art von Partei geht. Eine einwertige Property fängt eine zweite Erstattung zu derselben Bestellung ab, ein aufgezählter Wertebereich einen Status, den das Modell erfunden hat. Mitnehmen solltet ihr den Unterschied, ob ihr die Form einer Tool-Ausgabe prüft oder ob sie so überhaupt wahr sein darf (Why Agentic Systems Need Ontologies (öffnet in einem neuen Tab), 22. Juli 2026, aus der Praxis).

Ein Open-Source-Agentenprodukt zeigt, wie ihr den Code um ein Modell testet, ohne das Modell zu testen. Mehrere der über 200 Smoke-Skripte in exxperts starten den echten Server gegen ein synthetisches OpenAI-kompatibles Gateway auf einem lokalen Port. Sie prüfen, was beim Gateway ankam. Ein Beispiel ist ein Abschnitt im System-Prompt pro Turn: Er muss die Tools des Raums auflisten, die Memory-Recall-Zeile wörtlich enthalten und höchstens 400 Zeichen lang sein (EXXETA - room tools stanza smoke (öffnet in einem neuen Tab), Version 0.14.1, Oktober 2026). Hängt eine veröffentlichte Zahl an einem Prompt, wird der Prompt festgepinnt. Ein Smoke rendert den Memory-Summary-Prompt für eine feste Unterhaltung zu einer festgesetzten Uhrzeit. Er vergleicht dessen sha256 mit dem Hash, der vor einem Refactoring genommen wurde. Als Grund nennt das Projekt, dass an genau diesem Prompt sein Memory-Ergebnis von 43 von 50 gemessen wurde (EXXETA - Remember single-pass pin smoke (öffnet in einem neuen Tab)).

Der Memory-Bench desselben Projekts bewertet die Memory-Pipeline gegen ein Fixture, in dem jeder platzierte Fakt einen Referenzcode trägt. Ein Score nennt so den Fakt, der verloren ging. Geskriptete Modelle kalibrieren den Bench. Ein exaktes Modell muss jede Kategorie bestehen, und alles darunter gilt als Bug im Bench. Ein faules Modell, das jede Zeile anhängt und nie etwas ersetzt, muss sichtbar scheitern. Auf dem Standard-Fixture erreicht es 1 von 33. Eine Klasse von Fragen ohne Hinweis teilt außer der benannten Entität kein Inhaltswort mit dem platzierten Satz. Der Selbstcheck des Fixtures lehnt einen Build ab, in dem doch eines vorkommt. Der Raum muss dann selbst entscheiden, ob er sucht. Es zeigte sich, dass Phrasenlisten Enthaltungen falsch bewerten: 11 von 20 ehrlichen “I don’t know”-Antworten galten wegen ihrer Formulierung als falsch. Der LongMemEval-Judge akzeptierte dagegen alle 20. Der Bench nutzt als Gate jetzt die Frage, ob eine Antwort einen Fakt erfindet, und liest die Phrasenliste nur noch als Indiz (EXXETA - memory bench README (öffnet in einem neuen Tab), Eigenangaben des Projekts, Stand Oktober 2026).

Was beweist ein Agent an der Spitze eines öffentlichen Evals?

OpenAIs Challenge Parameter Golf zog über 1.000 Teilnehmende und mehr als 2.000 Einreichungen an. Die Grenzen lagen bei 16 MB für das Artefakt und 10 Minuten Trainingsbudget auf 8 H100. OpenAI hat die Einreichungen im Record-Track unabhängig reproduziert und verifiziert (OpenAI - What Parameter Golf taught us (öffnet in einem neuen Tab)). Der CEO und Mitgründer von Weco stellte den Beitrag des Unternehmens vor, den Multi-Agent-Prototyp Aiden. Er las Papers und Pull Requests, fuhr Experimente, wandte ein Quality Gate an und veröffentlichte Pull Requests. Laut der Weco-Präsentation gab es über die ganze Challenge 47 angenommene Rekordeinträge, sieben davon von Aiden. Die Präsentation nennt außerdem rund 1.300 interne Experimente in 22 Tagen und ein Setup, das auf einer einzigen H100 lief (An AI agent became the #1 contributor in OpenAI’s hiring challenge (öffnet in einem neuen Tab), 16. Juli 2026). Diese Zahlen stammen von Weco selbst. OpenAIs Rückblick erwähnt Aiden nicht und bestätigt sie auch nicht unabhängig.

Der Fall ist lehrreich, weil der lokale Score einer Einreichung nicht das einzige Qualitätssignal war, das die Challenge belohnte. Wer einen solchen Agenten evaluiert, liest vier getrennte Achsen: Suchdurchsatz (die rund 1.300 Experimente oben), Gültigkeit an einem externen Quality Gate, Recheneffizienz sowie Wiederverwendung oder Einfluss downstream. Gültig heißt hier, dass Rekorde OpenAIs eigene Verifikation unter der 16-MB-Grenze bestehen. Effizienz misst Ergebnisse pro H100-Stunde, Einfluss fragt, ob andere Teilnehmende auf der Arbeit aufbauen. Angenommene Pull Requests, die Wiederverwendung der Ideen einer Einreichung und Zitationslinien messen nur diese letzte Achse. Weco nennt für Aiden einen PR-h-Index von 10, gegenüber 7 beim nächstplatzierten Beitragenden. Dieser h-Index ist aber ein in der Praxis definierter Proxy für Einfluss und Wecos eigene Analyse, kein Qualitätsbeweis (Weco-Präsentation, 16. Juli 2026 (öffnet in einem neuen Tab)). Der stärkste öffentliche Beleg ist eine einzelne gemergte Einreichung. Pull Request #1736 dokumentiert ein Ergebnis von 1,06549 Bits pro Byte. Er zeigt auch eine Abstammung, die auf CaseOps, Gated Attention, QuantGate und andere Community-Arbeit zurückgreift (openai - openai/parameter-golf#1736 (öffnet in einem neuen Tab)).

Zwei Lehren lassen sich auf die Evaluation jedes nicht-deterministischen Systems übertragen. Erstens lag die Stärke des Agenten in der Ausführung, also in Suche, Implementierung und Rekombination. Die meisten produktiven Grundbausteine kamen aus Papers und von Teilnehmenden, also von Menschen, und das Design von Wettbewerb und Eval blieb menschlicher Hebel. Zweitens die konzeptionelle Rahmung: Das Eval ist Loss-Funktion und Daten, die Abstraktion der Codebasis ist die Architektur, die die Suche in eine Richtung lenkt. Die Weco-Präsentation bietet auch ein anschauliches Beispiel für die Grenze des Evals. Sie behauptet, eine lockere Scoring-API habe Train/Test-Leakage erlaubt und eine strikte API habe diesen Weg geschlossen. Zu dem Beispiel gibt es weder einen öffentlichen Datensatz noch Code. Behandelt es deshalb als Illustration aus dem Talk, nicht als gemessenes Ergebnis (Weco-Präsentation, 16. Juli 2026 (öffnet in einem neuen Tab)).

Verwandte Seiten

Quellen

Agent-Optimierung

Autonome Forschung

Eval-Methodik