Golden Dataset und Testset

Erster Artikel der Reihe über das Testen von KI-Systemen. Bevor man entscheidet, wer bewertet — ein Modell, wie im zweiten Artikel, oder ein Mensch, wie im dritten —, liegt unter beiden Antworten dieselbe Frage: woran genau messen wir eigentlich?

Eine Szene, die ich zu oft gesehen habe

Abstimmungsrunde zu einem RAG-basierten Assistenten. Jemand hat den System-Prompt geändert, um eine Meldung zu erledigen. Der Product Owner fragt: «gut, aber funktioniert es jetzt besser oder schlechter als vorher?».

Es folgt Schweigen. Dann die Antwort, die wir alle kennen: «mir kommt es besser vor».

Das Problem ist nicht die Aufrichtigkeit dessen, der antwortet. Das Problem ist, dass es in diesem Raum keine Möglichkeit gibt, «ich habe einen Fall gelöst und drei kaputt gemacht» von «ich habe einen Fall gelöst, mehr nicht» zu unterscheiden. Klassische Software hat das vor dreissig Jahren mit Regressionstests gelöst. In generativen Systemen ist das Konzept dasselbe, nur muss man sich die Ground Truth von Hand bauen.

Diese von Hand gebaute Ground Truth heisst Golden Dataset.

Was genau gemeint ist

Ein Golden Dataset (auch Gold Standard oder Golden Set) ist eine kuratierte Sammlung von Beispielen, bei denen der erwartete Output — oder zumindest das Akzeptanzkriterium — als Referenzwahrheit gilt.

Der Begriff stammt aus der medizinischen Diagnostik: der Goldstandard ist die Untersuchung, die per Konvention als korrekt angenommen wird und an der alle günstigeren oder schnelleren Verfahren gemessen werden. Der Kern ist identisch: es ist die Referenz, die man zu behandeln entscheidet, als wäre sie wahr — im vollen Bewusstsein, dass dies die eigene Entscheidung ist und keine Tatsache der Natur.

Golden Dataset ≠ Testset

Die beiden Begriffe werden synonym verwendet, aber der operative Unterschied zählt:

Im klassischen Machine Learning macht man 70/15/15 und legt los. Das Testset erbt die Qualität des Datensatzes: sind 5% der Labels falsch, hat das Testset 5% falsche Labels und die messbare Genauigkeitsobergrenze liegt bei 95%.

Das Golden Dataset ist etwas anderes. Es wird mit der ausdrücklichen Absicht geschrieben oder ausgewählt, bestimmte Fragen zu beantworten: geht dieses System gut mit mehrdeutigen Fragen um? Hält es das Format ein? Verweigert es die Antwort, wenn es das soll? Es ist klein, weil jedes Beispiel menschliche Aufmerksamkeit gekostet hat — und genau deshalb ist es nützlich.

Die konkrete Form

Im einfachsten Fall ist es eine Liste von Paaren Input → erwarteter Output. In der Praxis von LLM-Systemen wird daraus fast immer etwas Reicheres:

- id: RUE-014
  kategorie: ruecksendung_ausserhalb_frist
  input: "am 3. januar gekauft, kann ich das noch zurückgeben?"
  erwarteter_kontext: [ruecksendepolicy_v3, feiertagsausnahmen]
  kriterien:
    - muss die 30-Tage-Frist nennen
    - darf keine Rückerstattung zusagen
    - muss den Supportkanal angeben
  notiz: "Grenzfall, das Datum fällt in den verlängerten Weihnachtszeitraum"
  herkunft: produktionsticket_2025-02

Man beachte: es gibt keine Wort-für-Wort erwartete Antwort. Bei generativen Aufgaben ergibt der exakte Vergleich keinen Sinn. Festgelegt wird eine Menge von Akzeptanzkriterien, die anschliessend von einem automatischen Judge, von einer deterministischen Prüfung oder von einem Menschen verifiziert werden. Das Golden Dataset definiert, was wahr sein muss, nicht wie es formuliert sein muss.

Die fünf Kriterien eines Datensatzes, der etwas taugt

In der jüngeren Literatur kursiert ein brauchbares Merkschema, die 5 D (Practical Guide for Evaluating LLMs). Ich gebe es wieder, weil es eine ehrliche Checkliste ist:

1. Defined scope — definierter Geltungsbereich. Ein Datensatz pro Komponente, zusätzlich zum End-to-End-Datensatz. Haben Retriever und Generator je ihr eigenes Set, weiss man beim Absacken der Zahl, wo man hinschauen muss. Es ist die Logik des Unit-Tests, angewendet auf die Pipeline.

2. Demonstrative of production — produktionsnah. Gebaut auf echtem Traffic, nicht auf dem, was man sich vorgestellt hat. Es ist das mit Abstand am häufigsten verletzte Kriterium. Ein aus der Dokumentation erzeugter Datensatz ist zu sauber, zu gut formuliert, zu grammatikalisch. Echte Nutzende schreiben klein und ohne Interpunktion, ändern mitten im Satz die Meinung, kopieren E-Mail-Fragmente hinein.

3. Diverse — vielfältig. Themen, Absichten, Schwierigkeitsgrade, Sprachen, adversariale Fälle. Sind alle Beispiele Happy Path, bleibt der Wert für immer bei 95% und sagt nichts aus.

4. Decontaminated — dekontaminiert. Er darf sich nicht mit den Trainings- oder Fine-Tuning-Daten überschneiden. Darauf komme ich gleich zurück, denn das ist der heikelste Punkt.

5. Dynamic — lebendig. Ein im Januar zusammengestellter Datensatz beschreibt den Traffic vom Januar. Im Juli fragen die Nutzenden anderes und das Produkt hat neue Funktionen. Er gehört wie ein Append-Log behandelt, mit Datum an jedem Eintrag, damit man auf einen Blick sieht, wie alt er ist.

Woher die Beispiele kommen

Drei Quellen, und es braucht alle drei.

Produktion. Die mit Abstand beste Quelle. Echte Traces, Supporttickets, schlecht ausgegangene Gespräche. Jede Meldung einer nutzenden Person ist Kandidat für einen dauerhaften Test. Achtung DSGVO: die Beispiele müssen anonymisiert werden, bevor sie in einem Repository landen, das das ganze Team lesen kann.

Fachleute aus der Domäne. Nötig, wenn die Aufgabe Wissen verlangt, das das Modell nicht hat und das sich in den Logs nicht findet: Branchenregulierung, interne Abläufe, Grenzfälle, die zweimal im Jahr vorkommen und teuer sind. Das ist der langsame, teure Teil — und der, der dem Datensatz seinen Wert gibt. Wer Annotation ernsthaft betreibt, misst auch die Übereinstimmung zwischen Annotierenden (Cohens Kappa): sind sich zwei Fachleute bei einem Fall nicht einig, ist dieser Fall nicht reif für das Golden Set. Entweder er muss umformuliert werden, oder das Akzeptanzkriterium ist mehrdeutig und das Problem liegt weiter oben.

Synthetische Erzeugung. Nützlich, um Lücken zu füllen: man hat drei Beispiele einer seltenen Kategorie und erzeugt zwanzig Varianten. Die jüngere Literatur unterscheidet Silver Datasets (von einem LLM erzeugte Labels) von Golden (von Menschen geprüft) und sogar von Super-Golden (von unterschiedlichen Fachteams kuratiert). Die Unterscheidung ist gesund: sie getrennt zu halten und stets zu wissen, welches man gerade ansieht, verhindert die Verwechslung von «das Modell stimmt mit sich selbst überein» mit «das Modell hat recht».

Die Mischung, die in der Praxis trägt: ein Kern echter Fälle aus der Produktion, angereichert um von Fachleuten geschriebene Fälle zu den bekannten Schwachstellen, synthetisch erweitert nur dort, wo echte Daten zu dünn sind.

Wie gross er sein muss

Die Frage kommt immer, und die Antwort enttäuscht immer: viel kleiner als gedacht.

Die Grössenordnungen aus den jüngeren Praxisleitfäden decken sich untereinander:

• ~50 Beispiele — genug, um grobe Regressionen abzufangen. Das ist das schnelle Gate für jeden Pull Request.
• ~200 Beispiele — man bekommt statistische Sicherheit bei Unterschieden von 3-5%. Das ist die Schwelle, ab der die Zahl aufhört, anekdotisch zu sein.
• über 500 — abnehmender Ertrag, es sei denn, das System hat sehr unterschiedliche Teilaufgaben, die eigene Sets verdienen.

Bei deterministischen Aufgaben (Klassifikation, strukturierte Extraktion) steigen die Zahlen, denn dort kostet die Auswertung fast nichts und man kann sich Tausende von Fällen leisten.

Der eigentliche Punkt ist: die Herkunft zählt mehr als die Grösse. Hundert Fälle aus echten Fehlschlägen sind mehr wert als zweitausend, die ein LLM aus dem Benutzerhandbuch erzeugt hat. Der zweite Datensatz liefert schönere Zahlen und null Information.

Wie man ihn wirklich einsetzt

Drei Ebenen, mit unterschiedlichen Kosten und Takten. Die Staffelung stammt von Hamel Husain und wird inzwischen fast überall aufgegriffen; ihr Vorzug ist, realistisch zu sein:

Ebene 1 — Deterministische Unit-Tests. Assertions, die bei jedem Commit in Millisekunden laufen: ist das JSON gültig? Ist das Pflichtfeld da? Enthält die Antwort den geforderten Hinweis? Hat sie 500 Token überschritten? Sie sind banal, decken mehr Fälle ab als man denkt und kosten nichts. Viele Teams überspringen sie und rennen direkt zum Judge — und zahlen dann in Latenz und Token, was sie für einen regulären Ausdruck hätten haben können.

Ebene 2 — Golden Dataset plus Bewertung (Judge oder Mensch). Läuft auf dem Pull Request oder im Nightly Build. Hier steckt der grösste Teil des Signals: Prompt ändern, Modell wechseln, Chunking-Strategie umstellen → Set neu laufen lassen → Delta zur Baseline ansehen.

Ebene 3 — A/B-Test in Produktion. Echter Traffic, belastbare Stichproben, sinnvoll erst, wenn das Produkt reif ist und die ersten beiden Ebenen stehen.

Wer bei Ebene 2 oder 3 einsteigt, ohne Ebene 1 zu haben, verliert die schnelle Rückkopplung, die die langsamen Ebenen erträglich macht.

Zum CI-Gate: üblich ist, den Merge zu blockieren, wenn eine Primärmetrik über eine Schwelle hinaus abfällt (5% ist der Wert, den man am häufigsten sieht). Und eine wichtige Anmerkung, die für Leute aus der klassischen Softwareentwicklung ketzerisch klingt: die Pass Rate soll nicht 100% sein. Das ist eine Produktentscheidung. Ein System, das 100% des Golden Set besteht, sagt vermutlich, dass das Golden Set zu leicht ist.

Was er zurückgibt

Reproduzierbares Signal zu nahezu null Kosten. Eine menschliche Bewertung über 200 Beispiele kostet Personenstunden, und man wiederholt sie nicht für jedes geänderte Komma im Prompt. Ein Golden Set läuft in zwei Minuten, zwanzigmal am Tag.

Diskussionen werden sachlich. Man streitet nicht mehr über Eindrücke. «Ich habe 4 Punkte in der Kategorie Rückerstattungen verloren» ist ein Satz, mit dem man arbeiten kann; «kommt mir schlechter vor» nicht.

Man sieht die unsichtbaren Regressionen. Jene, die dem Auge entgehen, weil man gerade woanders hingesehen hat. Es ist der Nutzen, den man erst zu schätzen weiss, wenn er einen das erste Mal rettet.

Diagnose statt blosser Note. Ist der Datensatz nach Kategorien geschichtet, sagt das Ergebnis, wo es klemmt. Ein aggregierter Wert von 90% kann 40% in der unterrepräsentierten kritischen Kategorie verbergen — und das ist fast immer die, die wehtut.

Governance. In regulierten Kontexten (KI-Verordnung, beaufsichtigte Branchen) ist ein dokumentierter, versionierter Nachweis darüber, wie das System vor jedem Release bewertet wurde, keine Spielerei, sondern Auditmaterial.

Die Nachteile, und die sind der interessante Teil

Das Gesetz von Goodhart

Sobald eine Kennzahl zum Ziel wird, ist sie keine gute Kennzahl mehr.

Optimiert man iterativ gegen dieselben 100 Beispiele, hat man nach zwanzig Durchgängen ein System, das auf diesen 100 Beispielen glänzt. Nicht zwingend auf dem Rest der Welt. Es ist Overfitting von Hand, durch das Team, ohne Gradient Descent: man sieht sich die Fehlschläge an, passt den Prompt an, lässt neu laufen, wiederholt. Die Zahl steigt, und alles daran ist wahr — auf den Fällen, die man ansieht.

Die Gegenmassnahme ist disziplinarisch, nicht technisch: einen Teil des Sets als blindes Holdout zurückhalten, das während der Entwicklung nie angesehen und nur zur Endvalidierung verwendet wird. Steigt das Entwicklungsset und das Holdout nicht, hat man seine Antwort.

Die Kontamination

Das ist das Problem, das öffentliche Benchmarks als absolutes Mass nahezu unbrauchbar gemacht hat. Sind die Bewertungsbeispiele im Training des Modells gelandet, messen die Zahlen Memorierung, nicht Fähigkeit.

Das sauberste Experiment dazu ist GSM1k von Scale AI: sie haben tausend Grundschul-Mathematikaufgaben in Auftrag gegeben, gebaut, um Verteilung, Schwierigkeit und Antwortstatistik von GSM8k, dem Standardbenchmark der Branche, zu spiegeln. Dann haben sie die Modelle neu bewertet. Einige Familien (Phi, Mistral, einige Llamas) verloren bis zu 13 Prozentpunkte; die Frontier-Modelle fast nichts. Und der Abstand korrelierte damit, wie wahrscheinlich ein Modell die GSM8k-Texte wörtlich reproduzierte. Übersetzt: ein Teil dieser Punktzahl war Erinnerung.

Ein Detail, das alles sagt: sie haben entschieden, GSM1k nicht öffentlich freizugeben, abgesehen von rund fünfzig Beispielen — genau, um ihn nicht zu verbrennen.

Die Lehre für alle, die Produkte bauen: Ihr Golden Set muss privat bleiben, und öffentliche Benchmarks sind als grobe Hinweise zu lesen, nicht als Messungen. Landet Ihr Datensatz im Klartext auf GitHub, haben Sie einen Countdown gestartet.

Der Goldstandard ist kein Gold

Das ist der unbequemste Punkt. Die Annahme «das Referenzlabel ist korrekt» ist eben genau das: eine Annahme.

MMLU ist wohl der meistzitierte Benchmark der jüngeren LLM-Geschichte. Eine manuelle Analyse von 5700 Fragen durch vierzehn Fachleute schätzte rund 6,5% fehlerhafte Fragen, mit absurden Spitzen: in der Teilmenge Virologie hatten über 57% der untersuchten Beispiele irgendein Problem, und bei 30% war schlicht die Ground Truth falsch. Bewertet man die Modelle auf dem korrigierten Datensatz neu, ändert sich die Rangfolge.

Wenn das einem akademischen Benchmark passiert, auf dem die halbe Erzählung der Branche aufgebaut wurde, können Sie sich ausmalen, was in Ihrer an zwei Nachmittagen zusammengestellten CSV-Datei steckt.

Praktisches Korollar: scheitert ein Fall aus dem Golden Set, lautet die erste Hypothese nicht immer «das Modell hat sich geirrt». Manchmal hat das Modell recht und das Label ist falsch. Es lohnt sich, die Fälle wieder anzusehen, die seit Monaten systematisch scheitern: hin und wieder findet man dort einen eigenen, versteinerten Fehler, den das System die ganze Zeit vorgeführt hat.

Begrenzte Abdeckung und falsche Sicherheit

Zweihundert Beispiele decken den langen Schwanz dessen nicht ab, was echte Nutzende fragen. «Das Golden Set besteht zu 94%», während in der Produktion Menschen Wege finden, das System zu brechen, die niemand vorhergesehen hatte — weil niemand sie alle vorhersehen kann. Genau dafür gibt es Stichprobenreview und Monitoring im Betrieb.

Pflegeaufwand

Er muss aktualisiert werden, wenn sich Domäne, Produkt oder Regulierung ändern. Ein vor zwei Jahren eingefrorenes Golden Set misst ein Problem, das es nicht mehr gibt — mit der ruhigen Selbstsicherheit dessen, der nicht weiss, dass er nicht mehr aktuell ist. Und die Pflege macht keinen Spass: sie ist die erste Arbeit, die bei einem Termin gestrichen wird.

Die Mehrdeutigkeit von «korrekt»

Bei Klassifikation ist es einfach. Bei «fasse dieses Dokument zusammen» oder «schreibe diese E-Mail» gibt es keinen einzigen korrekten Output, und der zeichenweise Vergleich funktioniert nicht. Man geht über zu Kriterien, Rubriken, semantischer Ähnlichkeit, LLM-as-judge — was eigene Verzerrungen und eigene Streuung mitbringt und seinerseits gegen menschliche Urteile validiert werden muss. Hier hängt sich dieser Artikel an den nächsten der Reihe an: das Golden Set ist auch der Prüfstand des Judge, nicht nur des Systems.

Auf dem Feld Gelerntes

Der erfundene Datensatz mit 97%. Bei einem Ticket-Klassifikator hatten wir das Bewertungsset aus der offiziellen Kategorien-Taxonomie gebaut: pro Kategorie ein paar selbst geschriebene Beispiele. Ergebnis: 97%, und ab in die Produktion. Dort lag die wahrgenommene Genauigkeit bei etwa 60%. Der Grund war im Nachhinein banal: unsere Beispiele stammten von Leuten, die die Taxonomie bereits kannten, also enthielten sie die richtigen Schlüsselwörter. Die Nutzenden schrieben «seit heute Morgen geht gar nichts mehr». Wir haben das Set aus 300 echten Tickets neu gebaut, der Wert brach auf 61% ein — und das war der Moment, in dem wir anfingen, etwas zu verstehen.

Der Fall, der seit acht Monaten scheiterte. Ein geerbter Testfall, seit jeher rot, den alle übersprangen, weil «der ist bekannt». Als wir ihn endlich öffneten, war der erwartete Output falsch: jemand hatte ihn geschrieben und dabei eine interne Richtlinie missverstanden. Das Modell hatte acht Monate lang recht gehabt. Daraus die Regel: kein Test bleibt länger als zwei Sprints rot ohne ausdrückliche Entscheidung — entweder man korrigiert ihn oder man löscht ihn.

Das Set, das zum Produkt wurde. Bei einem Dokumentenassistenten war das Golden Set auf 400 Fälle angewachsen, alle rund um eine bestimmte Art von Frage gebaut, an der wir uns festgebissen hatten. Sechs Monate später war der Wert hervorragend und die Nutzenden unzufrieden: der Traffic hatte sich inzwischen auf eine andere Art von Fragen verlagert, die im Set mit vier Beispielen vertreten war. Der Datensatz beschrieb unsere Vergangenheit, nicht ihre Gegenwart. Seither geht ein fester Anteil jeder monatlichen Durchsicht darauf, das Set wieder an die echte Verteilung der Fragen anzugleichen.

Das Gate, an das sich niemand hielt. Wir hatten die CI-Sperre auf 5% Regression gesetzt. In den ersten Wochen schlug sie oft an, und jedes Mal lautete die Reaktion «ja, aber das ist ein Fehlalarm, mach auf». Das Gate überlebte erst, als wir zwei Dinge ergänzten: die Liste der konkret veränderten Fälle, nicht nur die aggregierte Zahl, und die Möglichkeit, eine Regression ausdrücklich und mit Begründung freizugeben. Ein Gate, das man nur erdulden kann, wird abgeschaltet; ein Gate, über das man diskutieren kann, bleibt.

Wie man einen baut, der nicht nach drei Monaten stirbt

Eine operative Checkliste, nach Wichtigkeit geordnet:

1. Gehen Sie von echten Fehlschlägen aus. Nicht von der Dokumentation, nicht von der Taxonomie, nicht von der Vorstellung. Gibt es noch keine Produktion, fangen Sie bei den Anrufen im Support an oder bei den Fällen, die die Fachleute Ihnen entnervt erzählen.
2. Versionieren Sie ihn wie Code. In Git, mit Changelog. Eine Veränderung der Zahlen muss entweder dem System oder dem Datensatz zuzuordnen sein, nie beidem gleichzeitig.
3. Setzen Sie Metadaten an alles. Kategorie, Schwierigkeit, Aufnahmedatum, Herkunft. Sie brauchen sie, um Ergebnisse zu schichten und zu erkennen, wie stark er gealtert ist.
4. Behalten Sie ein Holdout, das Sie nicht ansehen. Auch ein kleines. Es ist die einzige echte Verteidigung gegen menschliches Overfitting.
5. Nehmen Sie negative Fälle auf. Mehrdeutige Eingaben, Anfragen ausserhalb der Domäne, Prompt Injection, Fragen, auf die das System die Antwort verweigern muss. Ein System, das dort selbstsicher antwortet, wo es innehalten sollte, scheitert — wie gut die Antwort auch formuliert ist.
6. Jeder Vorfall wird ein Fall. Das ist die Regel, die den Datensatz ohne Willenskraft am Leben hält: hat etwas ein Ticket erzeugt, kommt es ins Set. Für immer.
7. Datieren Sie ihn und dünnen Sie ihn aus. Ist ein Fall seit zwei Jahren drin und besteht immer, misst er vielleicht nichts mehr.
8. Verwenden Sie ihn nicht allein. Das Golden Set deckt «wir wissen, was passieren soll» ab. Für alles Übrige gehört es neben die stichprobenartige menschliche Review und das Monitoring im Betrieb.

Notwendig, und weit vom Hinreichenden entfernt

Das Golden Dataset ist Ihre Regressionssuite, nicht Ihre QA. Es sagt Ihnen, ob Sie etwas kaputt gemacht haben, von dem Sie wussten, dass es funktionieren muss. Es sagt nicht, ob das Produkt gut ist, es sagt nicht, was Sie nicht vorhergesehen haben, und es sagt gar nichts mehr, sobald es vom Mass, das man konsultiert, zum Ziel wird, das man maximiert.

Es ist notwendig. Es ist weit davon entfernt, hinreichend zu sein. Und es ist das, was man in einem KI-Projekt zuerst bauen sollte — denn ohne es schrumpft jede andere technische Entscheidung auf «mir kommt es besser vor».

Quellen

• Zhang et al., A Careful Examination of Large Language Model Performance on Grade School Arithmetic (GSM1k, Scale AI) — https://scale.com/research/llm-performance-grade-school-arithmetic
• Vollversion des GSM1k-Papers (NeurIPS 2024, Datasets and Benchmarks Track) — https://proceedings.neurips.cc/paper_files/paper/2024/file/53384f2090c6a5cac952c598fd67992f-Paper-Datasets_and_Benchmarks_Track.pdf
• Leaderboard und Beschreibung des GSM1k-Datensatzes (Scale Labs) — https://labs.scale.com/leaderboard/math
• Gema et al., Are We Done with MMLU? (MMLU-Redux, NAACL 2025) — https://arxiv.org/abs/2406.04127
• In der ACL Anthology veröffentlichte Fassung — https://aclanthology.org/2025.naacl-long.262.pdf
• A Practical Guide for Evaluating LLMs and LLM-Reliant Systems (das 5-D-Schema) — https://arxiv.org/abs/2506.13023
• Hamel Husain, Your AI Product Needs Evals (die drei Bewertungsebenen) — https://hamelhusain.substack.com/p/evals
• Langfuse, Golden dataset evaluation: build and maintain LLM test sets — https://langfuse.com/resources/engineering/golden-dataset-evaluation
• Getmaxim, Building a "Golden Dataset" for AI Evaluation: A Step-by-Step Guide — https://www.getmaxim.ai/articles/building-a-golden-dataset-for-ai-evaluation-a-step-by-step-guide/
• Statsig, Golden datasets: creating evaluation standards — https://www.statsig.com/perspectives/golden-datasets-evaluation-standards
• The Evolution of LLM Adoption in Industry Data Curation Practices (Silver-, Golden- und Super-Golden-Datensätze) — https://arxiv.org/abs/2412.16089