Golden Test Sets: Ground Truth für LLM-Produkte
Wie Sie 2024 Golden Test Sets für LLM-Produkte aufbauen und pflegen: echte Produktionsanfragen sampeln, mit Fachexperten trotz Criteria Drift labeln, bekannte Fehlermodi abdecken und automatische Richter gegen Expertenlabels kalibrieren. Und warum die Pflege des Datensatzes — nicht das Tooling — der eigentliche Engpass der Evaluation ist. Mit konkreten Zahlen und datierten Quellen.
Warum Vibe-Checks nicht mehr reichen
Die meisten Teams, die 2024 LLM-Funktionen ausliefern, evaluieren auf dieselbe Weise: Ein Engineer ändert einen Prompt, liest fünf Ausgaben und erklärt die Änderung zur Verbesserung. Für eine Demo genügt das. Es scheitert, sobald das Produkt mehr als eine Aufgabe abdeckt, weil eine Korrektur an einer Stelle unbemerkt etwas an anderer Stelle bricht. Hamel Husains vielgelesener Essay vom 29. März 2024 benennt das Muster: Erfolglose LLM-Produkte teilen fast immer eine Ursache — das Fehlen eines belastbaren Evaluationssystems.
Öffentliche Benchmarks schließen die Lücke nicht. MMLU misst Genauigkeit auf 57 akademischen Aufgaben; ob Ihr Assistent die richtigen Rechnungsfelder extrahiert, sagt das nicht. Was ein Produkt braucht, ist ein Golden Test Set: Ground Truth für den eigenen Traffic.
Was ein Golden Test Set ist
Ein Golden Test Set ist eine fixierte, versionierte Sammlung echter Eingaben, gepaart mit fachlich geprüften Referenzausgaben oder expliziten Bewertungskriterien. Es ist produktspezifische Ground Truth. Jede Änderung — Prompt, Retrieval-Logik, Modellversion — wird gegen dieselben Fälle bewertet; eine Score-Differenz ist damit der Änderung zuzuordnen und nichts anderem.
Zur Definition gehört, was es nicht ist. Ein Golden Set ist kein Benchmark zum Vergleich von Foundation Models, kein Lasttest und kein Ersatz für A/B-Tests mit echten Nutzern. Es beantwortet genau eine Frage: Hat diese Änderung das System auf den Fällen verbessert oder verschlechtert, die wir für relevant erklärt haben?
Echte Anfragen statt erdachter Beispiele
Golden Cases müssen aus dem Produktions-Traffic stammen, nicht aus der Vorstellung der Engineers. Echte Anfragen sind kürzer, mehrdeutiger und fehlerhafter geschrieben als erdachte. Ziehen Sie Stichproben aus den Logs, stratifizieren Sie nach Feature, Intent, Sprache und Länge, und deduplizieren Sie Beinahe-Duplikate über Embedding-Ähnlichkeit — zehn Formulierungen derselben Bitte dürfen nicht zehn Plätze belegen.
Vor dem Launch gibt es keine Logs; synthetische Fälle aus der Spezifikation füllen die Lücke und werden ersetzt, sobald echter Traffic eintrifft. Fangen Sie klein an. In unseren Projekten reichen 50 bis 200 gelabelte Fälle pro Feature, um Regressionen zuverlässig zu fangen. Ein Set, das das Team nicht an einem Tag vollständig durchlesen kann, ist für den Anfang zu groß.
Labeling mit Fachexperten
Labels definieren die Ground Truth; wer labelt, wiegt deshalb schwerer als die Zahl der Labels. Ob eine Antwort in einem Steuer-, Medizin- oder Logistikprodukt korrekt ist, können nur Fachexperten entscheiden. Auch Experten sind uneins: In der MT-Bench-Studie (Juni 2023) stimmten menschliche Experten nur in 81 % der eindeutigen Urteile überein. Messen Sie die Übereinstimmung zwischen Annotatoren, bevor Sie Labels vertrauen; eine schriftliche Labeling-Richtlinie und ein Schlichtungsschritt bei Konflikten sind Pflicht.
Rechnen Sie damit, dass Kriterien wandern. Shankar et al. (April 2024) nennen das Criteria Drift: Bewerter brauchen Kriterien, um Ausgaben zu beurteilen — aber das Beurteilen verändert die Kriterien. Behandeln Sie die Labeling-Richtlinie als lebendes Dokument mit Changelog, und lassen Sie alte Labels nachschlichten, wenn sich die Richtlinie ändert.
Fehlermodi gezielt abdecken
Ein Golden Set aus Happy Paths belegt nichts. Bauen Sie eine explizite Fehlertaxonomie aus beobachteten Vorfällen: Retrieval-Fehlgriffe, halluzinierte Felder, Formatverstöße, unbegründete Verweigerungen, Anfragen außerhalb des Scopes, Prompt-Injection-Versuche. Reservieren Sie einen festen Anteil des Sets — bei uns etwa ein Drittel — für diese Kategorien, und nehmen Sie jeden bestätigten Produktionsfehler als gelabelten Fall auf, genau wie Regressionstests in klassischer Software.
Bleiben Sie ehrlich im Anspruch: Das Set deckt bekannte Fehlermodi ab. Unbekannte fehlen per Definition, und Anthropics Bericht vom Oktober 2023 zeigt, wie schwer robuste Evaluation selbst mit dedizierten Teams bleibt. Ein grünes Golden Set senkt Risiko; es beweist keine Sicherheit.
Automatische Richter kalibrieren
Expertenzeit ist die knappste Ressource; automatisierte Bewertung ist deshalb unvermeidlich. Programmatische Assertions — Regex, Schema-Checks, Exact Match — decken deterministische Kriterien ab. Für offene Antworten funktioniert LLM-as-a-Judge, unter Bedingungen. Zheng et al. maßen 85 % Übereinstimmung zwischen GPT-4 und menschlichen Experten, knapp über den 81 % zwischen Menschen, dokumentierten aber auch Position-, Verbosity- und Self-Enhancement-Bias.
Das Golden Set ist das Kalibrierinstrument: Ein Judge wird gegen Expertenlabels validiert, seine Übereinstimmungsrate wird gemessen und berichtet — erst dann bewertet er ungelabelten Traffic. Ein Judge ohne gemessene Übereinstimmungsrate ist nur ein weiteres unevaluiertes Modell in der Pipeline.
Wartung ist der eigentliche Engpass
Das erste Set zu bauen dauert Wochen. Es wahrhaftig zu halten dauert Jahre — und nach unserer Erfahrung bleibt Evaluationsarbeit genau hier stecken, nicht an Judge-Qualität oder Tooling. Produkte ändern sich, Modelle werden getauscht, Traffic driftet, und Testfälle sickern in Prompts oder Fine-Tuning-Daten und blähen Scores unbemerkt auf. Versionieren Sie den Datensatz wie Code: begutachtete Änderungen, ein Changelog, unveränderliche Releases.
Planen Sie diesen Aufwand explizit ein. Ein Golden Set ohne Verantwortlichen degradiert zum Benchmark des Produkts vom letzten Jahr.
| Auslöser | Wartungsmaßnahme |
|---|---|
| Bestätigter Produktionsfehler | Noch im Sprint als gelabelten Fall aufnehmen |
| Richtlinienänderung nach Schlichtung | Betroffene Fälle neu labeln und Version erhöhen |
| Modell- oder Prompt-Architektur-Wechsel | Judge-Kalibrierung gegen Expertenlabels wiederholen |
| Quartalsweise | Traffic neu sampeln und veraltete Fälle ausmustern |
| Fine-Tuning auf internen Daten | Trainingsdaten auf Golden-Case-Leakage prüfen |
Ausblick im Mai 2024
Wir erwarten drei Entwicklungen. Erstens wird Eval-Wartung eine eigene Produktkategorie; Assistenten im Stil von EvalGen, die Kriterien gemeinsam mit den Bewertern weiterentwickeln, zeigen die Richtung. Zweitens wird synthetische Datengenerierung das Erzeugen von Fällen skalieren, den Experten aber nicht aus dem Labeling entfernen — jemand muss weiterhin entscheiden, was korrekt bedeutet. Drittens erzwingt Regulierung das Thema: Der EU AI Act, vom Rat am 21. Mai 2024 final gebilligt, verlangt für Hochrisikosysteme dokumentierte Tests. Golden Test Sets sind das Artefakt, nach dem diese Anforderung fragen wird.
Unsere Wette: In zwei Jahren lautet die Frage im Review nicht mehr, welches Modell Sie nutzen, sondern: Zeigen Sie uns Ihr Golden Set und sein Changelog. Teams, die jetzt sampeln und labeln, führen dann das Gespräch.
Quellen
- Hamel Husain — Your AI Product Needs Evals (29 March 2024)
- Zheng et al. — Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv, 9 June 2023)
- Ganguli et al. / Anthropic — Challenges in Evaluating AI Systems (4 October 2023)
- Shankar et al. — Who Validates the Validators? Aligning LLM-Assisted Evaluation with Human Preferences (arXiv, 18 April 2024)
- Council of the EU — Artificial Intelligence Act: Council Gives Final Green Light (21 May 2024)