KI-Agenten bewerten: wie man Evals aufbaut und Zuverlässigkeit misst, statt nach Gefühl zu urteilen

Warum man Evals für KI-Agenten braucht, obwohl man ihre Arbeit sieht

Gerade das Sehen ist unzuverlässig. Der Agent ist in dieser Woche nach einer Änderung am Prompt kein einziges Mal hängen geblieben – war das eine Verbesserung oder einfach eine Woche mit leichten Aufgaben? Ein Ingenieur ist überzeugt, dass das neue Template alles verändert hat, ein zweiter hat im selben Log keinen Unterschied bemerkt. Beide haben nur so weit recht, wie keiner von ihnen etwas nachgezählt hat.

Evals für KI-Agenten ersetzen das Gefühl durch eine Zahl. Man nimmt einen festen Aufgabensatz, lässt den Agenten ihn bearbeiten, prüft das Ergebnis automatisch und vergleicht die Kennzahlen vor und nach einer Änderung. Dann wird die Frage »ist es besser geworden?« mit einer Tabelle beantwortet und nicht mit einer Autorität.

Ohne Evals ist jede Änderung am Harness – am Prompt, an der AGENTS.md, am Werkzeugsatz, am Modell – ein Wurf ins Blaue. Mit Evals wird sie zu einem Experiment mit messbarem Ergebnis.

Warum der »Eindruck« täuscht

Der Eindruck von der Arbeit eines Agenten leidet unter drei systematischen Fehlern, und alle drei führen zu falscher Sicherheit.

• Survivorship Bias. Gelungene Läufe bleiben im Gedächtnis und werden Kollegen gezeigt, misslungene werden neu gestartet und vergessen. Eine Zuverlässigkeit, die aus den gelungenen Läufen berechnet wird, sagt nichts darüber, wo der Agent tatsächlich scheitert.
• Kleine Stichprobe. Drei gelungene Aufgaben hintereinander sind selbst bei einem Agenten, der in der Hälfte der Fälle Erfolg hat, ein normales Ereignis. Die Wahrscheinlichkeit dafür ist 0,5³ = 12,5 %, also etwa jede achte Serie.
• Selbstsicherer Ton. Der Agent schreibt »fertig, alle Tests laufen durch« mit derselben Sicherheit, ob es stimmt oder nicht. Die Sicherheit des Modells ist nicht kalibriert: Der Tonfall der Antwort ist kein Signal für Korrektheit.

Daraus folgt eine Regel: Alles, was nicht aufgeschrieben und nachgerechnet ist, gilt als ungemessen.

pass@k und pass^k: zwei Kennzahlen, die man verwechselt

Der Agent ist nicht deterministisch: Dieselbe Aufgabe kann bei einer Wiederholung gelingen oder scheitern. Deshalb führt man eine Aufgabe mehrfach aus und berechnet eine von zwei Kennzahlen.

pass@k – mindestens einer von k Versuchen gelingt

Die Kennzahl stammt aus der Bewertung der Codegenerierung. Sie beantwortet die Frage, ob das System eine Aufgabe grundsätzlich lösen kann, wenn es mehrere Versuche bekommt. Das ist eine ehrliche Kennzahl für ein Szenario, in dem ein Mensch die beste von mehreren Varianten auswählt oder eine verlässliche automatische Prüfung die misslungenen aussortiert.

pass^k – alle k Versuche gelingen

Diese Kennzahl beantwortet eine andere Frage: wie stabil der Agent die Aufgabe löst. Sie beschreibt die Arbeit ohne Aufsicht – wenn der Agent viele Male läuft und jeder Fehlschlag Geld oder Zeit kostet.

Der Unterschied ist groß. Angenommen, der Agent löst eine Aufgabe mit 70 % Wahrscheinlichkeit pro Versuch, und die Versuche sind unabhängig:

Nach pass@5 wirkt der Agent beinahe perfekt, nach pass^5 unzuverlässig. Beide Zahlen stimmen, sie beschreiben nur verschiedene Dinge. Wenn Sie den Agenten autonom arbeiten lassen wollen, schauen Sie auf pass^k: Das kommt der Realität Ihrer Arbeit näher.

So rechnet man es in der Praxis

Führen Sie jede Aufgabe n-mal aus (zum Beispiel 5-mal) und notieren Sie die Zahl der Erfolge c. Für pass^k nähert man an: Man schätzt die Erfolgswahrscheinlichkeit p = c / n und potenziert sie. Über einen Aufgabensatz mittelt man den Wert.

import json
from statistics import mean

# results.jsonl: {"task": "add-pagination", "runs": [true, true, false, true, true]}
rows = [json.loads(line) for line in open("results.jsonl")]

def pass_at_k(runs, k):
    p = sum(runs) / len(runs)
    return 1 - (1 - p) ** k

def pass_pow_k(runs, k):
    p = sum(runs) / len(runs)
    return p ** k

for k in (1, 3, 5):
    print(k,
          round(mean(pass_at_k(r["runs"], k) for r in rows), 3),
          round(mean(pass_pow_k(r["runs"], k) for r in rows), 3))

Die Schätzung über p hoch k ist bei kleinem n grob, für den Vergleich von Harness-Versionen untereinander aber meist ausreichend. Wichtiger ist, dass sich n und der Aufgabensatz zwischen den Vergleichen nicht ändern.

Wie man einen Aufgabensatz für Evals zusammenstellt

Der Aufgabensatz ist das wichtigste Kapital. Eine gute Kennzahl auf schlechten Aufgaben misst das Falsche.

Nehmen Sie Aufgaben aus Ihrer Realität

Öffentliche Benchmarks wie SWE-bench sind nützlich, um Modelle zu vergleichen, aber ihre Aufgaben sind ausgewählt: klare Beschreibung, fertige Tests. In Ihrem Repository sind die Anforderungen unscharf, und Tests fehlen stellenweise, deshalb liegt die Benchmark-Zahl fast immer über dem, was der Agent bei Ihnen zeigt. Die besten Quellen sind geschlossene Tickets und reale Fehlschläge des Agenten aus dem Protokoll.

Zusammensetzung des Satzes

• 20–50 Aufgaben zum Start. Weniger, und das Rauschen frisst den Unterschied zwischen den Versionen. Mehr, und der Lauf wird teuer und hört auf, regelmäßig zu laufen.
• Verschiedene Typen: neue Funktion, Fehlerbehebung, Refactoring, Aufgabe in einem fremden Modul, Aufgabe mit einer Falle (wo die richtige Antwort lautet »so geht es nicht« oder »hier ist eine Rückfrage nötig«).
• Jede im Betrieb gescheiterte Aufgabe wird zum Test. So wächst der Satz mit dem Verständnis, wo der Agent schwach ist, und Rückschritte bleiben nicht unbemerkt.
• Fester Ausgangszustand: ein konkreter Commit, fixierte Abhängigkeiten, identische Umgebung. Sonst misst man nicht den Agenten, sondern die Drift der Umgebung.

Format einer Aufgabe

Jede Aufgabe besteht aus einer Beschreibung, einem Ausgangszustand und einem Erfolgskriterium, das ohne Mensch prüfbar ist.

id: add-pagination
repo_ref: 3f2c1ab
prompt: |
  Füge eine Paginierung zu GET /payments hinzu: die Parameter limit (Standard 20,
  Maximum 100) und cursor. Die Antwort enthält next_cursor.
check:
  - pytest tests/test_payments_pagination.py
  - mypy app/
limits:
  max_changed_files: 6

Beachten Sie: Das Erfolgskriterium ist die Definition of Done, in Befehlen festgehalten. Wenn Sie für eine Aufgabe kein Kriterium aufschreiben können, ist das ein Signal, dass sie dem Agenten ebenfalls unklar gestellt wurde.

Automatische Prüfungen oder LLM-Richter

Das Ergebnis lässt sich durch Code oder durch ein anderes Modell prüfen. Jede Methode hat ihren Bereich.

Regel: zuerst Code, der Richter obendrauf

Alles, was sich deterministisch prüfen lässt, prüft man deterministisch. Einen LLM-Richter fügt man nur für Eigenschaften hinzu, die sich nicht in Code ausdrücken lassen – und niemals an Stelle von Tests.

So macht man den LLM-Richter nützlich

• Anderer Kontext als der Generator. Der Richter sollte die Überlegungen des Agenten nicht sehen – nur die Aufgabe, die Kriterien und den fertigen Diff. Sonst wiederholt er dieselben Fehler. Das ist die Idee der N-Versionen: zwei unabhängige Blicke statt eines.
• Ein Raster statt »bewerte auf einer Skala von zehn«. Konkrete Fragen mit Ja/Nein-Antwort: »Gibt es eine Prüfung limit > 100?«, »Wurden Dateien außerhalb von app/payments geändert?«
• Kalibrierung mit manueller Auszeichnung. Bewerten Sie 20–30 Ergebnisse selbst und vergleichen Sie mit den Urteilen des Richters. Ist die Übereinstimmung gering, ändern Sie das Raster, statt dem Richter mehr zu vertrauen.
• Asymmetrie der Fehler. Ein falsches »fertig« ist teurer als ein falsches »nicht fertig«: Das erste geht in die Produktion, das zweite kostet einen Neustart. Stellen Sie den Richter so ein, dass er im Zweifel ablehnt.

Welche Kennzahlen außer dem Anteil der Erfolge zählen

Der Anteil gelöster Aufgaben ist nur die Spitze. Um zu sehen, wo genau man nachbessern muss, braucht man Zuverlässigkeitskennzahlen aus der klassischen Ingenieurpraxis.

• MTBF – wie viele Schritte oder Aufgaben der Agent bis zum Hängenbleiben schafft. Zeigt, wie selten er ausfällt.
• MTTR – wie lange die Wiederherstellung eines funktionierenden Zustands nach einem Ausfall dauert. Sie zu senken ist fast immer billiger als die MTBF zu erhöhen: Eine gute Fortschrittsdatei und eine reproduzierbare Umgebung verkürzen die Wiederherstellung um ein Vielfaches.
• Wirkungsradius – wie viel Code ein misslungener Schritt beschädigt. Begrenzt durch ein Limit für den Diff und die Isolation der Arbeitskopie.
• Anteil falscher »Fertig«-Meldungen – Aufgaben, bei denen der Agent Erfolg gemeldet hat, die Prüfung aber fehlschlug. Die gefährlichste Kennzahl: Sie zeigt, ob man dem Bericht des Agenten trauen kann.
• Kosten und Zeit – Token und Minuten pro Aufgabe. Ein Harness, das den Erfolg um 5 % steigert, aber die Kosten verdoppelt, gewinnt nicht immer.

Fehlerprotokoll: Evals aus dem Alltag

Nicht jedes Team ist sofort bereit, einen eigenen Testläufer zu bauen. Die minimale Form der Bewertung ist ein Fehlerprotokoll mit drei Spalten.

| Aufgabe                 | Ergebnis                           | Schicht       |
|-------------------------|------------------------------------|---------------|
| Paginierung /payments   | »fertig«, 2 Tests rot              | Verifikation  |
| Timeout-Fix Webhook     | 30 Min für pip install             | Umgebung      |
| Refactoring refunds     | alte ORM-Syntax                    | Kontext       |

Die Schicht ist einer von fünf Orten, an denen der Agent scheitern kann: Aufgabenbeschreibung, Kontext, Ausführungsumgebung, Rückmeldung der Verifikation, Zustandsverwaltung. Nach zwanzig Einträgen sieht man den echten Engpass, und fast nie liegt er dort, wo man ihn vermutet hat. Jede Zeile des Protokolls ist ein Kandidat für den Aufgabensatz der Evals.

Warum ein starkes Modell nicht alles löst

Die erste Reaktion auf Fehlschläge des Agenten ist, ein teureres Modell zu nehmen. Manchmal hilft das, öfter aber schließt nicht das Modell die Lücke zwischen Benchmark und Realität, sondern die Umgebung darum herum.

Wenn der Agent eine halbe Stunde braucht, um die Umgebung aufzusetzen, ist das die Schicht Umgebung – und ein Spitzenmodell braucht dafür genauso eine halbe Stunde. Meldet der Agent »fertig«, obwohl die Tests rot sind, ist das die Schicht Verifikation: Es gibt keinen Befehl, der ihm die Wahrheit sagt. Schreibt er im fremden Stil, hat man ihm die Konventionen des Projekts nicht gegeben. Keines dieser Probleme hat etwas mit der Intelligenz des Modells zu tun.

Evals erlauben, das ehrlich zu prüfen. Lassen Sie den Satz mit dem aktuellen Modell und mit einem teureren Modell laufen, danach mit dem aktuellen Modell und einer ergänzten AGENTS.md mit den Prüfbefehlen. Oft bringt die zweite Änderung mehr als die erste, und sie kostet nichts. Glauben Sie das aber nicht blind: Für genau solche Vergleiche braucht man den Satz.

Schrittplan: Bewertung von KI-Agenten in einer Woche

1. Tag 1. Legen Sie ein Fehlerprotokoll an und tragen Sie jeden Fehlschlag des Agenten mit Angabe der Schicht ein.
2. Tag 2. Wählen Sie 20 Aufgaben aus geschlossenen Tickets und dem Protokoll aus. Halten Sie für jede den Commit fest und schreiben Sie das Erfolgskriterium in Befehlen auf.
3. Tag 3. Schreiben Sie einen Testläufer: saubere Arbeitskopie, Start des Agenten mit dem Prompt der Aufgabe, Ausführung der Prüfungen, Ablage des Ergebnisses in JSONL.
4. Tag 4. Lassen Sie jede Aufgabe 3–5-mal laufen. Berechnen Sie pass@1, pass^3, den Anteil falscher »Fertig«-Meldungen und die durchschnittlichen Kosten.
5. Tag 5. Ändern Sie eine Sache am Harness und lassen Sie alles erneut laufen. Vergleichen Sie nur bei gleichem Satz und gleicher Zahl der Wiederholungen.

Ändern Sie pro Experiment jeweils eine Variable. Wer in einem Experiment Modell, Prompt und Werkzeuge gleichzeitig wechselt, weiß danach nicht, was gewirkt hat.

Typische Fehler bei der Bewertung von Agenten

• Ein Lauf pro Aufgabe. Die Nichtdeterminiertheit des Agenten macht ein solches Ergebnis zur Lotterie. Mindestens drei Wiederholungen.
• Der Satz ändert sich zwischen den Vergleichen. Neue Aufgaben hinzugefügt und gleichzeitig den Prompt geändert – dann sind die Zahlen nicht vergleichbar.
• Der Agent sieht die Prüftests. Liegen die Tests im Repository, kann der Agent den Code an sie anpassen oder die Tests gleich ändern. Bewahren Sie verborgene Prüfungen außerhalb der Arbeitskopie auf und kontrollieren Sie, dass der Agent keine Testdateien angefasst hat.
• Bericht des Agenten statt Prüfung. »Alle Tests sind durchgelaufen« in der Antwort des Modells ist kein Ergebnis. Das Ergebnis ist der Rückgabecode des Befehls, den der Testläufer gestartet hat.
• Nur pass@k. Eine schöne Zahl für eine Präsentation und eine schlechte Prognose für autonome Arbeit.

Kurz gesagt

Die Bewertung von KI-Agenten besteht aus einem festen Satz realer Aufgaben, automatischen Prüfungen und Kennzahlen, die nach jeder Änderung am Harness neu berechnet werden. pass@k zeigt, wozu der Agent fähig ist, pass^k, ob man ihm ohne Aufsicht vertrauen kann. Automatische Prüfungen liefern die Wahrheit, ein LLM-Richter mit Raster und eigenem Kontext ergänzt sie dort, wo Code nicht weiterkommt. Ein Fehlerprotokoll nach den fünf Schichten zeigt, was zuerst zu beheben ist – und meist liegt es nicht am Modell. Die Zuverlässigkeitskennzahlen und die Diagnoseschleife werden im Kurs zum Harness-Engineering praktisch durchgespielt.