Eval-Sets bauen: Golden-Set und Quality-Metriken

TL;DR

• Ein Eval-Set ist die einzige objektive Wahrheit über AI-Qualität in Production — alles andere ist Anekdoten-Reporting aus Pilot-Demos.
• Vier Konstruktions-Phasen: Sammeln (100–300 reale Production-Queries), Annotieren (Reference-Output oder Acceptance-Kriterien), Subgroups klassifizieren (Use-Case, Sprache, Datenherkunft), Versionieren wie Code.
• Sieben Quality-Metriken 2026: Exact-Match, ROUGE/BLEU, LLM-as-Judge, Schema-Adherence, Faithfulness, Latenz-P95, Cost-pro-Query.

Vier Phasen der Eval-Set-Konstruktion

Ein Eval-Set ist die zentrale Disziplin, die einen produktiven AI-Build von Pilot-Theater trennt. Wer ohne Eval-Set in Production geht, fliegt blind — mehr als 60 % der gescheiterten Mittelstands-Piloten 2024/2025 hatten kein versioniertes Eval-Set.

Sammeln. 100–300 reale Production-Queries aus echten User-Interaktionen sind der Startpunkt — curated, nicht synthetic. Die Queries müssen die echte Variationsbreite abdecken: kurz/lang, formal/umgangssprachlich, Edge-Cases, Failure-Modes. Wer aus 10.000 Logs die schwierigsten 200 zieht, hat ein besseres Set als wer 2.000 Mittelmaß-Queries sammelt.

Annotieren. Für deterministische Tasks (Klassifikation, Extraktion, JSON) exaktes Reference-Output pro Query; für freie Aufgaben (Zusammenfassung, Beratungs-Antwort) Acceptance-Kriterien als Checkliste ("enthält Punkt X", "max 200 Wörter", "keine Erfindung von Zahlen"). Annotation kostet 3–8 Min pro deterministischer, 8–15 Min pro freier Query — bei 200 Queries also 10–50 Stunden, die einzige nicht-verhandelbare Initial-Investition.

Subgroups. Jede Query bekommt Tags: Use-Case-Klasse, Sprache, Datenherkunft, Schwierigkeitsgrad (Standard, Edge, Adversarial). Subgroups sind die einzige Möglichkeit, Bias und Performance-Degradation pro Segment zu tracken. Ein Modell kann 92 % Gesamt-Accuracy haben und auf der Subgroup "Schwäbisch" nur 64 % — das findet nur, wer Subgroups vorhält.

Versionieren. Eval-Set ist Code: Git-Repo, Pull-Request-Reviews, Semantic-Versioning (v1.1.0 bei neuen Queries, v2.0.0 bei Acceptance-Kriterien-Bruch). Jeder Production-Deploy braucht einen Eval-Run gegen die aktuelle Version. Kein grüner Eval-Run, kein Deploy — die Regel, die produktive Builds von Pilot-Drift trennt.

Sieben Quality-Metriken 2026

Eine Metrik reicht nie. Sieben sind der Production-Default — jede bewertet eine andere Dimension.

Drei Metriken laufen lokal kostenlos (Exact-Match, Schema, Latenz), zwei brauchen Judge-Token (LLM-Judge, Faithfulness), zwei sind reine Telemetry. Wer alle sieben gleichzeitig misst, deckt rund 95 % der Production-Failure-Modes ab.

In DACH-Pilots zeigt sich: Eine einzelne Metrik täuscht, sieben gleichzeitig zeigen die Wahrheit — und sind der billigste Quality-Hebel der gesamten AI-Stack-Investition.

Tool-Vergleich für Mittelstand

Default-Pfad 2026: Promptfoo lokal starten, Eval-Set als YAML ins Git-Repo, GitHub Actions als CI-Runner. Erst bei über 500 Queries oder Compliance-Pflicht auf Patronus/Logfire migrieren.

Pilot: Reklamations-Klassifizier mit 240 Queries

Ein DACH-Bauindustrie-Mittelständler baute einen AI-Reklamations-Klassifizier mit Promptfoo-Eval-Discipline. Vorher lief eine LLM-Pipeline drei Monate ohne Eval-Set "irgendwie" — niemand wusste, ob sie besser oder schlechter wurde. Scope: 240 reale Reklamationen aus dem CRM, annotiert in 5 Kategorien plus Faithfulness-Check gegen die Bautechnik-Wissensbasis.

Befunde nach 90 Tagen: Die Subgroup "Bayrisch + Schwäbisch" lag bei nur 71 % Accuracy — ohne Subgroup-Tracking nie sichtbar geworden, ein klarer Fine-Tune-Hebel. Der Faithfulness-Score 0,89 entdeckte 11 % halluzinierte Quellenangaben, gefixt durch strikteres RAG-Prompting auf 0,96. Der monatliche Eval-Run als CI-Pflicht blockierte drei Prompt-PRs, weil die Accuracy unter die Vor-Version fiel. Die laufenden Eval-Run-Kosten sind im Verhältnis zum abgedeckten Operating-Risk-Hebel marginal — der höchste ROI-Hebel der gesamten AI-Stack-Investition.

Anti-Patterns

• Synthetische Eval-Sets: LLM-generierte Fragen testen genau das, was LLMs gut können — Schein-Performance (95 % synthetisch, 62 % real). Fix: mindestens 80 % real-gesammelt, max 20 % synthetisch als Edge-Case-Generator; vor Production-Logs: Demo-Logs, Beta-Sessions, Stakeholder-Interviews.
• Eval einmal jährlich: Modelle, Prompts und User-Patterns ändern sich quartalsweise — wer jährlich evaluiert, deployed 11 Monate blind. Fix: monatlicher Eval-Run als CI-Pflicht plus automatischer Eval bei jedem Prompt-PR.
• Kein Subgroup-Tracking: aggregierte Accuracy versteckt strukturelle Failure-Modes — 92 % Gesamt, aber 71 % auf "Frauen-Namen": DSGVO-Risiko und Reputations-Schaden. Fix: mindestens 4–6 Subgroups pflegen (Sprache, Use-Case, Datenherkunft, Schwierigkeit).

Eval-Set-Lifecycle

Eval-Sets veralten ohne Pflege. Drei Disziplinen halten sie produktiv:

• Failure-Mining: Production-Logs monatlich auf Beschwerden, Eskalationen und HITL-Korrekturen durchsuchen. Die schlechtesten 10–20 Cases pro Monat fließen automatisch ins Set — typisch +30–60 Queries pro Quartal.
• Monatliches Review: 60-Min-Stakeholder-Session mit Eval-Report, Subgroup-Auffälligkeiten und Drift-Analyse, drei konkrete Action-Items pro Monat (Prompt-Fix, Model-Switch, RAG-Tuning).
• Versionierungs-Tags: Production-Deploy referenziert immer einen konkreten Tag — keine Auto-Updates ohne Re-Eval-Run.

Mittelstands-Pfad: Start mit 100 Queries in Monat 1, iterieren auf 300 bis Monat 6, danach stabil mit Failure-Mining-Wachstum — typisch 400–600 Queries nach 12 Monaten Production. Wer ohne Eval-Set in Production geht, kommt nie zurück zu einer messbaren AI-Strategie.

Praxis-Schritt: Ein 90-Min-Eval-Audit klärt, welche Queries in Frage kommen, welche sieben Metriken Pflicht sind und wie der CI-Run aufgesetzt wird. Erstgespräch anfragen → /anfrage

Stand Mai 2026. Eval-Set-Konstruktion und Promptfoo-/LangSmith-/Logfire-Integration in Kooperation mit Implementations-Partnern — eigene BAFA-/go-digital-Akkreditierung in Vorbereitung Q3 2026.