Synthese: Evaluation
The Big Picture
Abschnitt betitelt „The Big Picture“Du hast fuenf Lektionen durchgearbeitet: wie Du Eval Frameworks aufbaust (Lektion 1), welche Metriken für welche Produkttypen gelten (Lektion 2), wie Du Dein Produkt adversariell testest (Lektion 3), wie Du Ship/No-Ship-Entscheidungen triffst (Lektion 4), und wie Du Bias erkennst und Fairness sicherstellst (Lektion 5).
Einzeln sind das Qualitaetswerkzeuge. Zusammen bilden sie ein Qualitaetssystem, in dem jede Lektion auf den anderen aufbaut und sie verstaerkt: Lektion 1 fragt WIE Du Qualität misst. Lektion 2 fragt WAS Du misst. Lektion 3 fragt WOGEGEN Du testest. Lektion 4 fragt WANN Du shippst. Lektion 5 fragt FUER WEN Dein Produkt funktioniert — und für wen nicht.
Connections
Abschnitt betitelt „Connections“1. Evals brauchen Metriken — und umgekehrt
Abschnitt betitelt „1. Evals brauchen Metriken — und umgekehrt“Ein Eval Framework (Lektion 1) ohne die richtigen Metriken (Lektion 2) ist eine Test Suite, die das Falsche misst. Die Eval Pipeline operationalisiert die Metriken, die für Deinen Produkttyp zaehlen. Umgekehrt: Metriken ohne Eval-Infrastruktur sind Zahlen ohne Konsequenzen — sie erzeugen keine Entscheidungen.
Für Dich als PM: Starte bei der Metrik-Auswahl (welche Tradeoffs kann Dein Produkt tolerieren?) und baue dann die Pipeline, die sie durchsetzt.
2. Red Teaming fuettert die Eval Pipeline
Abschnitt betitelt „2. Red Teaming fuettert die Eval Pipeline“Jedes Red-Team-Finding (Lektion 3) wird ein Regression Test im Golden Dataset (Lektion 1). Red Teaming entdeckt Failure Modes; Evals verhindern, dass sie sich wiederholen. Ohne diesen Feedback Loop sind Red-Team-Ergebnisse einmalige Erkenntnisse statt systematischer Verbesserungen.
Für Dich als PM: Baue den Prozess so, dass jedes Red-Team-Finding automatisch als Test Case in der Eval Suite landet. Ein Finding ohne Regression Test ist ein Finding, das Du vergessen wirst.
3. Ship/No-Ship steht auf dem Fundament der ersten drei Lektionen
Abschnitt betitelt „3. Ship/No-Ship steht auf dem Fundament der ersten drei Lektionen“Quality Gates (Lektion 4) werden durch Metriken definiert (Lektion 2), durch Eval Pipelines durchgesetzt (Lektion 1), und durch Red Teaming validiert (Lektion 3). Ohne dieses Fundament sind Ship-Entscheidungen subjektiv und inkonsistent — “Es fuehlt sich gut an” statt “Es hat alle Gates bestanden.”
Für Dich als PM: Die Ship/No-Ship Checklist ist nur so stark wie die Systeme dahinter. Wenn Deine Eval Suite schwach ist, sind Deine Quality Gates Illusion.
4. Fairness ist eine Linse, kein separater Workstream
Abschnitt betitelt „4. Fairness ist eine Linse, kein separater Workstream“Bias & Fairness (Lektion 5) ist keine eigene Aktivitaet — es ist eine Dimension jeder anderen Evaluation. Metriken müssen nach Gruppen disaggregiert werden (Lektion 2). Red Teaming muss Bias-spezifische Szenarien enthalten (Lektion 3). Ship-Entscheidungen müssen Fairness Gates einschliessen (Lektion 4). Fairness nachtraeglich als Add-on zu behandeln ist der sicherste Weg, sie zu verpassen.
Für Dich als PM: Integriere Fairness von Anfang an in Eval Pipeline, Metriken und Quality Gates — nicht als separaten Audit-Schritt nach dem Bau.
5. Das Eval Flywheel
Abschnitt betitelt „5. Das Eval Flywheel“Production Failures, die durch Monitoring entdeckt werden (Lektion 4), fliessen zurück in das Golden Dataset (Lektion 1), verbessern die Metriken (Lektion 2), und erhöhen den Qualitaetsstandard für zukuenftige Ship-Entscheidungen (Lektion 4). Das ist kein linearer Prozess — es ist ein kontinuierlicher Verbesserungskreislauf. Jede Production-Interaktion generiert Daten, die das System besser machen.
Für Dich als PM: Baue den Kreislauf von Tag 1. Nicht das perfekte Eval-System. Sondern eines, das sich selbst verbessert.
6. Bruecke zu Agentic Evaluation
Abschnitt betitelt „6. Bruecke zu Agentic Evaluation“Alles, was Du in diesem Kapitel gelernt hast, wird bei Agentic AI schwieriger. Agentische Systeme sind nicht-deterministisch, multi-step und nutzen Tool Calls — das macht klassische Eval-Ansaetze unzureichend. Ein Golden Dataset für Agenten evaluiert nicht einzelne Outputs, sondern End-to-End Task Completion: Hat der Agent die Aufgabe geloest, nicht nur einen guten Text generiert?
Drei Metriken werden zentral: Task Completion Rate (hat der Agent das Ziel erreicht?), Step Efficiency (wie viele Schritte hat er gebraucht?) und Tool Call Accuracy (hat er die richtigen Tools mit den richtigen Parametern aufgerufen?).
Dazu kommt ein mathematisches Problem: Wenn jeder Schritt eines 5-Step-Agent-Workflows 95% Zuverlaessigkeit hat, liegt die End-to-End-Zuverlaessigkeit bei 0.95^5 = 77%. Zuverlaessigkeit degradiert multiplikativ — das ist der Grund, warum Agentic AI neue Architektur-Patterns braucht.
Für Dich als PM: Die Eval-Infrastruktur, die Du in diesem Kapitel gelernt hast, ist die Grundlage — aber für Agenten brauchst Du sie erweitert. Der Engpass ist nicht das Modell, sondern die Eval-Infrastruktur für Multi-Step-Workflows. Kapitel 6 behandelt agentic Architekturen im Detail.
The Meta-Insight
Abschnitt betitelt „The Meta-Insight“Evaluation ist der Punkt, an dem AI Product Management sich am staerksten von traditionellem PM unterscheidet. Bei traditioneller Software beweist Testing, dass das Produkt funktioniert. Bei AI-Produkten definiert Evaluation, was “funktioniert” bedeutet — und diese Definition ist gleichzeitig eine Produktentscheidung, eine ethische Entscheidung und eine Business-Entscheidung.
Der PM, der Evaluation meistert, shipped nicht nur bessere AI-Produkte. Er baut die organisatorische Faehigkeit auf, AI-Produkte systematisch über Zeit zu verbessern — weil jede Production-Interaktion durch das Eval Flywheel fliesst.
Your Evaluation Checklist
Abschnitt betitelt „Your Evaluation Checklist“Was Du jetzt können solltest:
- Ein Golden Dataset mit Domain Experts aufbauen und als lebendes Artefakt pflegen — Lektion 1
- LLM-as-Judge implementieren und gegen Human Labels validieren — Lektion 1
- Die richtigen Metriken für Deinen Produkttyp waehlen (Classification vs. Generation vs. Task-Specific) — Lektion 2
- Metriken in Business Impact uebersetzen, die Stakeholder verstehen — Lektion 2
- Ein Threat Model für Dein AI-Produkt definieren und Red Teaming organisieren — Lektion 3
- Quality Gates vor dem Bau definieren und Staged Rollouts durchführen — Lektion 4
- Fairness-Metriken waehlen, Bias Audits durchführen und die Wahl begruenden — Lektion 5
- Das Eval Flywheel aufbauen: Production Failures zurück ins Golden Dataset, kontinuierliche Verbesserung — Lektionen 1-5
Wenn Du bei einem Punkt unsicher bist, geh zurück zur entsprechenden Lektion. Diese Evaluation-Grundlagen entscheiden, ob Dein AI-Produkt systematisch besser wird — oder systematisch Vertrauen verspielt.
Weiter mit: Agentic AI
Abschnitt betitelt „Weiter mit: Agentic AI“Du misst AI-Qualität. Kapitel 6 zeigt die nächste Stufe: autonome AI-Systeme, die selbststaendig handeln.
Self-Assessment
Abschnitt betitelt „Self-Assessment“Drei Szenarien, die mehrere Konzepte aus diesem Kapitel kombinieren. Ueberleg Dir Deine Antwort, bevor Du die Aufloesung oeffnest.
Szenario 1: Der ueberraschende Launch-Erfolg
Abschnitt betitelt „Szenario 1: Der ueberraschende Launch-Erfolg“Euer AI-Feature für automatische Vertragsanalyse hat alle Quality Gates bestanden: Precision liegt bei 94%, das Red Team hat keine kritischen Failure Modes gefunden, und die Stakeholder sind begeistert. Zwei Wochen nach Launch berichten Nutzer aus dem Gesundheitssektor, dass medizinische Vertragsklauseln systematisch falsch klassifiziert werden. Was ist schiefgelaufen, und wie reparierst Du es?
Aufloesung
Zwei Probleme: Erstens wurden die Metriken nicht nach Nutzergruppen disaggregiert (Lektion 2 + Lektion 5) — die 94% Precision war ein Durchschnitt, der die schlechte Performance für den Gesundheitssektor verdeckt hat. Zweitens hat das Red Teaming (Lektion 3) keine domaenenspezifischen Szenarien abgedeckt. Die Reparatur: medizinische Vertragsklauseln als Segment ins Golden Dataset aufnehmen (Lektion 1), Precision nach Branche disaggregieren (Lektion 2), und branchenspezifische Quality Gates einrichten (Lektion 4). Das ist das Eval Flywheel in Aktion — Production Failures zurück ins System speisen.
Szenario 2: Die Red-Team-Flut
Abschnitt betitelt „Szenario 2: Die Red-Team-Flut“Dein Red Team hat nach zwei Tagen Testing 47 Findings dokumentiert. Dein Engineering-Team sagt: “Wir können nicht alle fixen und trotzdem den Launch-Termin halten.” Wie priorisierst Du?
Aufloesung
Nutze die Ship/No-Ship-Logik (Lektion 4): Kategorisiere die Findings nach Severity — Safety-kritische Findings (z.B. das Modell gibt medizinische Ratschlaege bei einem Finanzprodukt) sind Ship-Blocker und müssen vor Launch gefixt werden. Findings, die durch Quality Gates abgefangen werden können (z.B. Edge Cases mit geringer Auftrittswahrscheinlichkeit), können per Staged Rollout gemanagt werden. Entscheidend: Jedes Finding wird als Regression Test ins Golden Dataset aufgenommen (Lektion 3 + Lektion 1), damit es nach dem Fix nicht zurueckkommt. Die 47 Findings sind kein Problem — sie sind 47 neue Test Cases für Dein Eval-System.
Szenario 3: LLM-as-Judge unter Druck
Abschnitt betitelt „Szenario 3: LLM-as-Judge unter Druck“Dein Team nutzt GPT-4o als LLM-as-Judge für die Eval Pipeline eines Summarization-Features. Ein Stakeholder fragt: “Wie wissen wir, dass der Judge richtig bewertet?” Dann zeigt eine Stichprobe, dass der Judge bei laengeren Summaries systematisch hoehere Scores vergibt — unabhängig von der Qualität. Was tust Du?
Aufloesung
Das ist ein bekanntes Bias-Problem bei LLM-as-Judge (Lektion 1): Laenge-Bias, bei dem laengere Outputs hoehere Bewertungen bekommen. Erstens: Validiere den Judge gegen Human Labels auf einem repraesentativen Sample (Lektion 1) — wenn die Korrelation zu niedrig ist, taugt der Judge nicht. Zweitens: Passe die Judge-Prompts an, um explizit gegen Laenge-Bias zu instruieren, oder nutze paarweise Vergleiche statt absoluter Scores. Drittens: Pruefe, ob dieser Bias Deine bisherigen Ship-Entscheidungen beeinflusst hat (Lektion 4) — wenn der Judge systematisch zu positiv bewertet hat, koennten Features live sein, die die tatsaechlichen Quality Gates nicht bestanden haetten.
Quellen: Aufbauend auf Lektionen 1-5. Hamel Husain — Eval Methodology (2024), OWASP Top 10 for LLMs (2025), EU AI Act (2024/1689), Buolamwini & Gebru — Gender Shades (2018), Chouldechova — Impossibility Theorem (2017), Flagsmith — Shipping AI Features (2025)