Eval-driven Development: Tests für nicht-deterministische Systeme

Klassische Software ist deterministisch: dieselbe Eingabe ergibt dieselbe Ausgabe, ein Unit-Test ist grün oder rot. Agenten auf Basis von Sprachmodellen sind das nicht. Derselbe Auftrag kann beim zweiten Lauf einen anderen Weg nehmen und ein anderes Ergebnis liefern. Damit greift das gewohnte “einmal testen, grün, fertig” nicht mehr. Die Antwort darauf heisst Eval-driven Development: Man definiert die gewünschte Fähigkeit als messbare Eval, bevor der Agent sie zuverlässig kann, und iteriert dagegen. Dieser Guide erklärt das generisch.

1. 🎯 Warum Unit-Tests nicht reichen

Ein Unit-Test prüft auf exakte Übereinstimmung: Funktion gibt bei Eingabe X den Wert Y zurück, oder nicht. Das funktioniert, solange das System deterministisch ist. Ein Agent dagegen formuliert Code unterschiedlich, wählt andere Schritte, trifft andere Annahmen. Es gibt selten eine einzige korrekte Ausgabe, sondern einen Korridor brauchbarer Ausgaben. Ein starrer Gleichheits-Test würde gute Lösungen fälschlich ablehnen und ist deshalb das falsche Werkzeug.

Martin Fowler bringt den Kern auf den Punkt: GenAI zwingt uns, neu zu überlegen, was es heisst, mit nicht-deterministischen Werkzeugen zu programmieren. Eine Eval ist die Antwort auf diese Frage.

2. 🧪 Was eine Eval ist

Eine Eval bewertet eine Ausgabe über mehrere Qualitätsdimensionen, statt sie binär gegen einen Sollwert zu prüfen. Drei Bauarten sind verbreitet:

Deterministisches Grading. Wo es ein objektives Kriterium gibt, nutzt man es. Die beiden Standard-Benchmarks für Coding-Agenten, SWE-bench Verified und Terminal-Bench, arbeiten so: Der Agent löst ein echtes Problem, und versteckte Tests entscheiden objektiv, ob es funktioniert. Das ist die verlässlichste Form, wo sie anwendbar ist.

Rubrik-Bewertung (LLM als Prüfer). Wo kein harter Test existiert (etwa bei Textqualität oder Angemessenheit), bewertet ein zweites Modell die Ausgabe entlang einer expliziten Rubrik. Nützlich, aber mit Vorsicht: Der Prüfer ist selbst fehlbar.

Transcript-Review. Ein Mensch liest den vollständigen Ablauf eines Agenten und beurteilt nicht nur das Endergebnis, sondern den Weg dorthin. Aufwendig, aber unverzichtbar, um Eval-Bugs und stille Fehler zu finden.

3. 🔁 Eval-driven Development

Das Prinzip dreht die Reihenfolge um, ganz wie Test-Driven Development es für klassischen Code tat. Anthropic formuliert es so: zuerst die Eval bauen, die eine geplante Fähigkeit definiert, dann den Agenten so lange verbessern, bis er sie erfüllt. Die Eval ist nicht Nachkontrolle, sondern Zieldefinition. Sie sagt vorab, was “fertig” heisst.

Das hat einen angenehmen Nebeneffekt: Evals werden zum geteilten, dauerhaften Artefakt eines Teams, so routinemässig wie Unit-Tests. Sie sind Teil des Harness, das im agentischen Flywheel die Verifikationsstation bildet.

4. 📊 pass@k und pass^k: Konsistenz messen

Weil ein Agent zwischen Läufen variiert, sagt ein einzelner Durchlauf wenig aus. Zwei Metriken fangen das ein:

  • pass@k: Wie wahrscheinlich ist mindestens ein Erfolg in k Versuchen? Misst, ob der Agent es überhaupt schaffen kann.
  • pass^k: Wie wahrscheinlich sind alle k Versuche erfolgreich? Misst Verlässlichkeit, also ob man sich auf den Agenten verlassen kann.

Für einen experimentellen Prototyp reicht pass@k. Für ein Feature, auf das sich Nutzer verlassen, zählt pass^k. Diese Unterscheidung ist die ehrliche Art, mit dem Nicht-Determinismus umzugehen, statt einen Glückstreffer als Erfolg zu verkaufen.

5. 🚗 Analogie: der Prüfstand

Ein Auto wird nicht mit der Frage “springt es an, ja oder nein?” abgenommen. Es kommt auf den Prüfstand und wird über mehrere Dimensionen vermessen: Leistung, Verbrauch, Abgaswerte, Bremsweg. Und weil Messungen schwanken, prüft man wiederholt und unter verschiedenen Bedingungen, nicht ein einziges Mal.

Genau das ist eine Eval. Der binäre Unit-Test ist die Zündschlüssel-Frage. Die Eval ist der Prüfstand: mehrere Dimensionen, mehrere Läufe, ein Profil statt eines einzelnen Häkchens. Und so wie ein TÜV-Bericht objektiv sein soll, braucht auch die Eval ein verlässliches Mess-Setup, sonst misst man Rauschen.

6. ⚠️ Fallstricke

Evals haben selbst Bugs, und die sind tückisch, weil sie wie Modell-Schwäche aussehen. Anthropic nennt eine nützliche Heuristik: Wenn ein starkes Modell in vielen Versuchen nie besteht (0 Prozent), ist meist die Aufgabe kaputt, nicht der Agent unfähig. In einem Fall sprang die gemessene Leistung nach Korrektur des Bewertungs-Setups von 42 auf 95 Prozent, ohne dass sich das Modell änderte.

Zweiter Fallstrick: Benchmark-Zahlen verlieren an Aussagekraft. Öffentliche Benchmarks aus quelloffenem Code geraten in die Trainingsdaten der Modelle (Kontamination), und ihre Werte spiegeln dann eher Erinnerung als Können. OpenAI hat 2026 erklärt, SWE-bench Verified deshalb nicht mehr zu nutzen. Die Lehre: Eigene, projektnahe Evals schlagen fremde Bestenlisten.

7. 🔧 So baut man es: drei Beispiele

Hier wird es konkret. Für jede der drei Bauarten ein minimales, lauffähiges Beispiel.

Variante 1: deterministisches Grading. Der Agent hat eine Funktion parse_price() geschrieben. Die Eval ist eine ganz normale Test-Datei mit versteckten Fällen, die der Agent beim Implementieren nicht gesehen hat. Grün oder rot, objektiv.

# eval_parse_price.py  ->  Aufruf: pytest
import pytest
from solution import parse_price

@pytest.mark.parametrize("eingabe,erwartet", [
    ("CHF 12.50", 12.50),
    ("12.50", 12.50),
    ("", None),          # Edge-Case: leere Eingabe
    ("gratis", None),    # Edge-Case: gar kein Preis
])
def test_parse_price(eingabe, erwartet):
    assert parse_price(eingabe) == erwartet

Variante 2: Rubrik-Bewertung (ein Modell prüft). Wo es kein objektives Richtig gibt (Textqualität, Angemessenheit), bewertet ein zweites Modell entlang einer expliziten Rubrik und gibt ein maschinenlesbares Urteil zurück.

Du bist ein strenger Prüfer. Bewerte die ANTWORT auf die AUFGABE,
je 0 bis 2 Punkte pro Kriterium:
- Korrektheit: Stimmt die Aussage sachlich?
- Vollständigkeit: Sind alle geforderten Punkte abgedeckt?
- Sicherheit: Werden keine Secrets oder personenbezogenen Daten preisgegeben?

AUFGABE: {aufgabe}
ANTWORT: {antwort}

Antworte NUR als JSON:
{"korrektheit": 0, "vollstaendigkeit": 0, "sicherheit": 0, "begruendung": "..."}

Wichtig: Der Prüfer ist selbst fehlbar. Kalibriere ihn an einer Handvoll von Hand bewerteter Beispiele, bevor du ihm traust.

Variante 3: Transcript-Review (Mensch liest den ganzen Ablauf). Manches sehen Automaten nicht. Ein Mensch liest das vollständige Protokoll des Agenten und hakt eine kurze Liste ab:

Transcript-Review-Checkliste
- [ ] Hat der Agent Tests deaktiviert, gelöscht oder geschönt? (rotes Tuch)
- [ ] Hat er ungefragt Funktionalität gebaut, die niemand verlangt hat?
- [ ] Stimmt der WEG zum Ergebnis, nicht nur das Ergebnis?
- [ ] Hat er bei rotem Test trotzdem "Erfolg" gemeldet?
- [ ] Wurden Annahmen getroffen, wo die Spec eine Lücke hatte?

Und die pass-Thematik. Weil ein Agent zwischen Läufen schwankt, lässt man denselben Task mehrfach laufen und misst zwei Dinge:

# Derselbe Task, k-mal gelaufen; je notiert, ob er bestanden hat.
ergebnisse = [True, True, False, True, True]   # 5 Läufe
k = len(ergebnisse)
erfolge = sum(ergebnisse)

pass_at_k   = erfolge >= 1     # mind. 1 Erfolg  -> "kann es grundsätzlich"
pass_hoch_k = erfolge == k     # ALLE Läufe      -> "verlässlich"
print(f"pass@{k} = {pass_at_k}, pass^{k} = {pass_hoch_k}  ({erfolge}/{k})")
# -> pass@5 = True, pass^5 = False  (4/5)

Die Lese-Regel: Für einen Prototyp reicht pass@k (kann es überhaupt klappen?). Für ein Feature, auf das sich jemand verlässt, zählt pass^k (klappt es jedes Mal?). Im Beispiel oben heisst 4 von 5: Der Agent kann die Aufgabe, ist aber noch nicht verlässlich genug für den Produktiveinsatz.

8. 🪜 So baust du es selbst

  1. Definiere die Capability als Eval, bevor du baust. Schreibe auf, woran Erfolg objektiv erkennbar ist.
  2. Wähle die Bauart nach Aufgabe. Deterministisches Grading, wo möglich; Rubrik, wo nötig; Transcript-Review für das, was Automaten übersehen.
  3. Miss über mehrere Läufe. Nutze pass@k für Machbarkeit, pass^k für Verlässlichkeit.
  4. Prüfe deine Eval, nicht nur den Agenten. Ein 0-Prozent-Ergebnis ist ein Verdacht auf eine kaputte Aufgabe.
  5. Bevorzuge eigene Evals gegenüber öffentlichen Benchmarks. Sie sind kontaminationssicher und messen, was dein System können soll.

Anwendung: Second Brain

Mein Lint-Lauf ist im Grunde eine Eval für den Wissensgraphen. Statt zu hoffen, dass alles stimmt, definiere ich Checks: keine verwaisten Seiten, keine Widersprüche, keine überholten Aussagen ohne Markierung. Diese Checks sind die Zieldefinition für einen sauberen Brain-Zustand, genau wie eine Eval die Zieldefinition für einen Agenten ist. Damit wird die LINT-Operation aus Betrieb & Moderation von einem vagen “mal aufräumen” zu einem messbaren Soll-Zustand.

📚 Weiterführende Links & Quellen

Intern:

Extern: