Eval Frameworks
Context
Abschnitt betitelt „Context“Dein Team hat ein AI-Feature gelauncht: Ein Chatbot beantwortet Kundenfragen zu Euren Produkten. Nach zwei Wochen beschweren sich User über falsche Antworten. Der CTO fragt: “Wie schlecht ist es genau?” Niemand kann antworten, weil es keine systematische Evaluation gibt.
Traditionelles Software-Testing prüft deterministisches Verhalten: Input X ergibt immer Output Y. AI-Systeme sind probabilistisch — derselbe Input kann bei jedem Durchlauf verschiedene Outputs erzeugen. Das macht klassische Unit Tests unzureichend. Evaluation (“Evals”) ist die Disziplin, AI-Output-Qualität systematisch zu messen, damit Teams mit Zuversicht iterieren können.
Hamel Husain und Shreya Shankar, die Entwickler des meistbesuchten AI-Evals-Kurses, bringen es auf den Punkt: “Your AI product needs evals” ist kein optionaler Ratschlag — es ist das Fundament jedes Verbesserungszyklus.
Concept
Abschnitt betitelt „Concept“Die Eval Ownership Chain
Abschnitt betitelt „Die Eval Ownership Chain“Der PM besitzt die Eval-Strategie, weil der PM definiert, was “gut” für den User bedeutet. Die Verantwortung verteilt sich so:
- PM definiert Qualitaetskriterien (was für User und Business zaehlt)
- Domain Expert labelt Golden Datasets und validiert Edge Cases
- Engineer implementiert automatisierte Eval Pipelines und CI-Integration
- PM + Domain Expert reviewen Ergebnisse und treffen Ship/No-Ship-Entscheidungen
Golden Datasets
Abschnitt betitelt „Golden Datasets“Ein Golden Dataset ist ein kuratierter Satz von Input-Output-Paaren, bei denen der erwartete Output von einem Domain Expert verifiziert wurde. Es funktioniert wie eine Test Suite — das AI-System wird dagegen evaluiert.
So baust Du ein Golden Dataset auf:
- Echte Inputs sammeln — aus Production Logs, Support-Tickets, User Sessions. Nie ausschliesslich synthetische Daten verwenden.
- Diversitaet sicherstellen — Themen, Intentionen, Schwierigkeitsgrade, Edge Cases und adversarielle Inputs abdecken.
- Domain Experts labeln lassen — PASS/FAIL-Urteile statt 1-5-Skalen. Ein Experte, der User-Beduerfnisse versteht, ist wertvoller als zehn oberflaechliche Annotatoren.
- Reasoning dokumentieren — Für jedes Label erklärt der Experte kurz, warum der Output besteht oder durchfaellt.
- Klein starten, kontinuierlich wachsen — Mit 50-100 Beispielen beginnen. Production Failures als Regression Tests hinzufuegen.
LLM-as-Judge
Abschnitt betitelt „LLM-as-Judge“LLM-as-Judge nutzt ein Sprachmodell, um die Outputs eines anderen Modells zu bewerten — Human Judgment im grossen Massstab. Die wichtigste Eval-Technik für generative AI-Produkte mit subjektiven Outputs.
Best Practices (2025 Konsens):
- PASS/FAIL statt numerische Skalen — klareres Signal
- Chain-of-Thought Reasoning im Judge Prompt erzwingen
- Staerkeres Modell als Judge verwenden (z.B. Claude Opus bewertet Sonnet-Outputs)
- Judge gegen Human Labels validieren — Ziel: 80%+ Uebereinstimmung
- LLM-as-Judge bietet erhebliche Kostenersparnisse gegenueber Human Review (typisch 10-50x, abhaengig von Aufgabenkomplexitaet und Bewertungstiefe)
Human Eval bleibt unverzichtbar
Abschnitt betitelt „Human Eval bleibt unverzichtbar“Automatisierung ersetzt nicht den menschlichen Blick:
- Initiales Golden Dataset erstellen (kein Shortcut)
- LLM-as-Judge-Genauigkeit validieren
- Tone, Brand Voice, kulturelle Sensibilitaet bewerten
- Husains Empfehlung: 30 Minuten, 20-50 Outputs manuell reviewen bei jeder signifikanten Änderung
Framework
Abschnitt betitelt „Framework“Dein Weg zum ersten Eval-System:
| Schritt | Aktion | Zeitrahmen |
|---|---|---|
| 1 | 50 Production Outputs manuell mit Domain Expert reviewen | Tag 1-2 |
| 2 | Failure Modes kategorisieren (falsche Antwort, Halluzination, Ton, Format) | Tag 2-3 |
| 3 | Golden Dataset mit 100 gelabelten Beispielen aufbauen | Woche 1-2 |
| 4 | Einfaches Eval-Skript schreiben (kein fancy Tool) | Woche 2 |
| 5 | LLM-as-Judge für subjektive Dimensionen hinzufuegen | Woche 3 |
| 6 | In CI/CD mit Pass/Fail-Schwellenwerten integrieren | Woche 4 |
| 7 | Production Sampling: % des Live-Traffic asynchron bewerten | Monat 2 |
| 8 | Plattform-Tool adoptieren wenn Skalierung es erfordert | Monat 3+ |
Scenario
Abschnitt betitelt „Scenario“Du bist PM bei einem Legal-Tech-Startup. Euer AI-Feature fasst Vertraege zusammen (5.000 Summaries/Monat). Der VP Product will wissen, ob Ihr von GPT-4o auf Claude Sonnet wechseln koennt, um Kosten zu senken.
Die Situation:
- Kein bestehendes Eval-System — Qualität wird aktuell per “Team vibes” bewertet
- 3 Anwaelte im Team, die Domain-Expertise haben
- Budget für Eval-Aufbau: 2 Wochen Engineering-Zeit
- Stakeholder will Modell-Entscheidung in 4 Wochen
Optionen:
- Schnell-Vergleich: 20 Vertraege durch beide Modelle laufen lassen, Team stimmt ab
- Golden Dataset First: 2 Wochen investieren, um 100 Vertraege mit Anwaelten zu labeln, dann systematisch vergleichen
- Tool-First: Braintrust oder DeepEval lizenzieren, dann evaluieren
Wie wuerdest Du entscheiden?
Die beste Entscheidung: Option 2 — Golden Dataset First.
Warum:
- Option 1 ist zu duenn: 20 Beispiele ohne strukturierte Kriterien sind ein Bauchgefuehl-Check, keine Evaluation. Bei 5.000 Summaries/Monat riskierst Du systematische Fehler, die in 20 Stichproben nicht auftauchen.
- Option 2 schafft bleibendes Asset: Das Golden Dataset dient nicht nur für diesen Modellvergleich — es wird zum Fundament für jede zukuenftige Änderung (Prompt-Updates, neue Modelle, Feature-Erweiterungen).
- Option 3 ist die falsche Reihenfolge: Tools verstaerken eine gute Eval-Strategie, sie ersetzen keine. Ohne Golden Dataset und klare Kriterien misst auch das beste Tool das Falsche.
- Timeline passt: 2 Wochen Golden Dataset + 1 Woche Eval-Runs + 1 Woche Analyse = 4 Wochen.
Haeufige Fehler:
- “Wir brauchen zuerst ein Tool” — Falsche Reihenfolge. Erst verstehen, was “gut” bedeutet.
- “Generic Benchmarks reichen” — MMLU misst Modell-Faehigkeit, nicht Eure Produktqualitaet.
- “Evals sind Engineering-Sache” — Ohne PM-Ownership der Kriterien baut Engineering technisch korrekte, aber produktirrelevante Tests.
Reflect
Abschnitt betitelt „Reflect“Evals sind die wichtigste Kompetenz für AI PMs — weil sie definieren, was “gut” bedeutet, bevor es zu spaet ist.
- Golden Datasets sind lebendige Artefakte: Klein starten (50-100 Beispiele), Production Failures als Regression Tests hinzufuegen, kontinuierlich wachsen lassen.
- LLM-as-Judge skaliert Human Judgment um Groessenordnungen (typisch 10-50x guenstiger) — aber nur wenn der Judge gegen echte Human Labels validiert ist.
- Die größte PM-Falle: “Wir brauchen zuerst ein Tool.” Starte mit manueller Error Analysis. 30 Minuten, 20-50 Outputs. Das zeigt mehr als jedes Dashboard.
Quellen: Hamel Husain — “Your AI Product Needs Evals” (2024), Husain & Shankar — AI Evals for Engineers & PMs (Maven, 2025), Lenny’s Newsletter — Building Eval Systems (2024), Pragmatic Engineer — “A Pragmatic Guide to LLM Evals” (2025), Evidently AI — LLM-as-a-Judge Guide (2025)