Datensatz-Design und Annotation

Ein Eval-Set ist eine Behauptung darüber, was Ihre Nutzer tun. Jede Eigenschaft des Sets ist eine solche Behauptung: die Größe, die Zusammensetzung, die Herkunft, die Art der Beschriftung. Die meisten Eval-Sets stellen Behauptungen auf, die ihre Autoren nie geprüft haben.

In diesem Kapitel geht es darum, diese Behauptungen bewusst aufzustellen.

Wie groß muss es sein?

Es gibt zwei Antworten. Sie brauchen beide.

Die Praktiker-Faustregel. Ein CI-Set läuft bei jeder Änderung. Dafür empfehlen Husain und Shankar 100+ Beispiele. Das Set ist gezielt zusammengestellt: Es deckt die Kernfunktionen ab, dazu Regressionsfälle aus echten Vorfällen und bekannte Randfälle. Keine Zufallsstichprobe, sondern eine kuratierte Auswahl.

Die statistische Antwort. Die nötige Größe hängt von zwei Dingen ab: Welchen Unterschied wollen Sie erkennen? Und wie stark rauschen Ihre Werte? Eine Verbesserung um 5 Punkte bei 100 Beispielen liegt oft noch im Rauschen. Statistik für kleine Eval-Sets zeigt die Rechnung. Kurz gesagt: Rechnen Sie das einmal aus. Übernehmen Sie keine Zahl aus einem Blogpost.

Die beiden Antworten widersprechen sich nicht. Ab 100+ Beispielen beginnt ein brauchbares CI-Signal. Ob das für Ihre Entscheidung reicht, ist eine Rechnung.

Häufiger Fehler: Das Eval-Set vergrößern, um sich gründlich zu fühlen. Eine größere Menge unpassender Beispiele ist nur eine teurere Art, falsch zu liegen. Zusammensetzung schlägt Größe. Das gilt, bis Sie kleine Unterschiede auflösen wollen.

Woher die Beispiele kommen

Produktions-Traces auswerten

Die beste Quelle sind echte Anfragen aus dem laufenden Betrieb. Sie kosten nichts. Und sie haben von selbst die richtige Mischung. Genau diese Mischung müssen künstlich erzeugte Daten mühsam nachbauen.

Ziehen Sie Traces nicht zufällig. Angenommen, Ihr Support-Bot hatte letzte Woche 1.000 Gespräche. Etwa 600 davon waren „Hallo“ und „Passwort zurücksetzen“. Ein paar Anfragetypen machen immer den Großteil des Verkehrs aus. Ziehen Sie 100 zufällig, sind rund 60 davon solche einfachen Fälle. Die kann das System längst. Also sagen sie Ihnen nichts. Die Fehler, die Sie suchen, stecken in den anderen 40: den seltenen und sperrigen Anfragen. Entscheiden Sie deshalb selbst, was ins Set kommt. Ziehen Sie keine Zufallsstichprobe. So geht das:

• Nach der Fehlertaxonomie schichten. Schichten heißt: Erst teilen Sie in Gruppen ein, dann ziehen Sie aus jeder Gruppe gezielt. Die Gruppen sind die Fehlerklassen aus der Fehleranalyse. Aus jeder Klasse nehmen Sie eine feste Zahl von Traces, die genau diesen Fehler zeigen. So ist jede Klasse messbar, nicht nur die, die der Zufall geliefert hat.
• Den Rand überproportional ziehen. Lange Eingaben, seltene Tools, Wiederholungen, Timeouts. Dazu nicht-englischer Verkehr. Der braucht eine eigene Behandlung, nicht ein paar zusätzliche Zeilen hier.
• Die langweiligen Fälle trotzdem aufnehmen. Enthält Ihr Eval nur schwere Fälle, sehen Sie keine Regression, die den einfachen Pfad kaputt macht. Genau diese Regression fällt Nutzern aber auf.
• Von Nutzern gemeldete Antworten nehmen. Ein Daumen nach unten ist ein kostenloses Label mit starkem Signal. Es hat aber einen bekannten Bias: Es zeigt Unzufriedenheit, nicht Unrichtigkeit.
• Jeden Fall mit Metadaten versehen: Anliegen, Sprache, Nutzertyp, Quelle. Beim Anlegen ist das billig, beim Nachtragen teuer. Ohne Metadaten gibt es später keine Teilmengen, nach denen Sie auswerten können.

Gehen Sie mit diesen Daten sauber um. Produktions-Traces enthalten Nutzerinhalte. Sie als Eval-Set zu nutzen ist ein eigener Verarbeitungszweck. Der braucht eine Rechtsgrundlage, eine Löschregel und meist eine Pseudonymisierung. Das ist kein Punkt für den Schluss: Die Aufbewahrungsfrist entscheidet, ob das Eval-Set überhaupt existieren darf.

Längere Gespräche als Fälle

In einem Chat mit mehreren Nachrichten ist ein Fall nicht „eine Nachricht, eine Antwort“. Ein Fall ist: der bisherige Chat, gespeichert wie er war, plus die nächste Nachricht des Nutzers. Das System muss nur diese eine Antwort erzeugen. Und nur diese Antwort bewerten Sie. Als Datei sieht das so aus:

{
  "id": "case-217",
  "history": [
    { "user": "Wo ist Bestellung A-2231?" },
    { "system": "Sie ist beim Paketdienst und kommt am Donnerstag." },
    { "user": "Können Sie sie an meine Arbeitsadresse schicken?" },
    { "system": "Ja. Wie lautet die Adresse?" }
  ],
  "input": "Hauptstraße 12, 80331 München.",
  "expect": { "nennt": ["A-2231"] },
  "note": "Original-Antwort: 'Welche Bestellung war das noch mal?' Die Nummer aus Nachricht 1 wurde vergessen."
}

history ist eingefrorener Text. Das System liest ihn, beantwortet ihn aber nicht neu. Sonst würden Sie bei jedem Lauf ein anderes Gespräch testen. Neu ist nur die Antwort auf input. Und expect sagt, was diese Antwort richtig machen muss.

Aus einem Chat, in dem etwas schiefging, wird so ein Fall: history reicht bis zur Nachricht vor dem Fehler, input ist diese Nachricht. Notieren Sie in der Fehleranalyse deshalb, bei welcher Nachricht der Fehler passiert ist. Wenn Sie aus einem Chat mehrere Fälle schneiden, hängen diese Fälle zusammen. Statistik erklärt, warum sie weniger zählen als unabhängige Fälle.

Synthetische Erzeugung, strukturiert

Manchmal haben Sie keinen Verkehr: ein Produkt vor dem Launch, ein neues Feature. Dann erzeugen Sie Beispiele. Der naive Ansatz lautet „schreib mir 100 Kundenfragen“. Er liefert 100 Umformulierungen derselben drei Fragen. Denn genau das kommt heraus, wenn das Modell aus seinem Modus zieht, also aus seinem häufigsten Muster.

Befund: Dass Modelle nach dem Alignment auf wenige typische Ausgaben zusammenfallen, wurde unabhängig untersucht. Eine Ursache liegt in den Präferenzdaten selbst: Annotatoren bevorzugen systematisch vertraut klingenden Text („typicality bias“). Faltet man die Vielfalt gezielt wieder auf, statt einfach mehr zu ziehen, steigt sie beim kreativen Schreiben um das 1,6- bis 2,1-Fache gegenüber direktem Prompting.

Quelle: Verbalized Sampling: How to Mitigate Mode Collapse and Unlock LLM Diversity

Das strukturierte Rezept von Husain und Shankar vermeidet das:

1. Benennen Sie die Dimensionen, entlang derer echte Eingaben variieren. Für einen Rezept-Assistenten: Ernährungseinschränkung, Küche, Komplexität, Nutzerkompetenz, Zutatenverfügbarkeit.
2. Bilden Sie Tupel. Wählen Sie dafür pro Dimension einen Wert. Schreiben Sie zuerst etwa 20 von Hand. Dabei entdecken Sie Dimensionen, die Sie übersehen haben.
3. Erzeugen Sie in zwei Schritten. Erst bauen Sie die Tupel strukturiert. Dann übersetzen Sie jedes Tupel in einem eigenen Prompt in natürliche Sprache. Beides auf einmal zerstört die Vielfalt, die Sie gerade aufgebaut haben.
4. Lassen Sie die Fragen durch das System laufen. Dann analysieren Sie die Ergebnisse wie gewohnt.

Die Zweiteilung ist der entscheidende Punkt. Verlangt ein einziger Prompt Struktur und Formulierung zugleich, optimiert er auf flüssige Formulierung. Die Struktur gibt er still auf.

Ein durchgerechnetes Beispiel. Angenommen, Sie bauen diesen Rezept-Assistenten. Schritt 1 liefert fünf Dimensionen mit je drei bis vier Werten:

Schritt 2 zieht daraus ein Tupel, etwa (Nussallergie, thailändisch, 15 Minuten, Anfänger, Restebestand). Das ist noch keine Nutzerfrage. Es ist nur ihr Bauplan. Fünf Dimensionen mit je drei bis vier Werten ergeben über 500 Kombinationen. Sie brauchen nicht alle. Aber Sie sehen sofort, wie schmal die Ausbeute eines einzelnen „schreib mir 100 Fragen“ dagegen ist.

Schritt 3 übersetzt genau dieses eine Tupel in einem eigenen Aufruf in natürliche Sprache. Der Prompt enthält nur das Tupel und eine Anweisung: Schreibe eine realistische Nutzerfrage. Keine Liste, keine weiteren Beispiele. So kann das Modell nicht in seinen Standardmodus zurückfallen. Heraus kommt etwas wie:

„Hab noch Kokosmilch und Reste vom Gemüse da, muss aber Nüsse komplett meiden. Geht da was Thailändisches in einer Viertelstunde? Koche sonst eher selten.“

An diesem einen Satz sehen Sie den Unterschied. Einschränkung, Küche, Zeitbudget, Zutatenlage und die Unsicherheit des Nutzers stehen alle darin. Sie stehen darin, weil sie vorher als Struktur festgelegt wurden. Nicht, weil das Modell zufällig daran gedacht hat. Wiederholen Sie Schritt 3 für jedes Tupel. Dann haben Sie ein Eval-Set, dessen Vielfalt Sie benennen können.

Wann synthetische Daten in die Irre führen

Befund: Vier Situationen, in denen synthetische Erzeugung unrealistische Daten liefert und nicht vertrauenswürdig ist: komplexe fachspezifische Inhalte (Schriftsätze, Krankenakten), ressourcenarme Sprachen, Hochrisiko-Domänen mit Pflicht zur manuellen Prüfung und die Darstellung unterrepräsentierter Nutzergruppen.

Quelle: Husain & Shankar, LLM Evals FAQ

Der gemeinsame Nenner: Die Kompetenz des Generators ist die Obergrenze für den Realismus der Daten. Wo das Modell schwach ist, sind die synthetischen Daten selbstbewusst falsch. Und zwar genau so falsch wie das Modell. Ihr Eval-Set erbt damit den blinden Fleck, den Sie eigentlich messen wollten.

Kontamination und Leakage

Beide Probleme laufen auf dasselbe hinaus: Die Antworten sind vorher bekannt. Ihr Wert misst deshalb etwas anderes, als Sie glauben. Nur der Weg dorthin ist verschieden.

Kontamination öffentlicher Benchmarks. Der Benchmark stand in den Trainingsdaten des Modells. Das Modell hat die Testfragen also gesehen, bevor Sie es getestet haben. Der Wert misst dann Erinnerung statt Fähigkeit. Über Ihre Eingaben sagt er nichts. Bei öffentlichen Ebene-A-Benchmarks gehen Sie davon aus, dass das passiert ist. Behandeln Sie es nicht als bloße Möglichkeit.

Ihr eigenes Leakage. Wissen über die Testfälle sickert in das System, das Sie prüfen wollen. Dieser Fall ist der wahrscheinlichere, denn Sie verursachen ihn selbst. Ein Beispiel: Sie nehmen drei besonders knifflige Fälle aus Ihrem Eval-Set. Sie setzen sie als Few-Shot-Beispiele in den Prompt, damit das Modell sie besser löst. Danach besteht es genau diese drei. Gemessen haben Sie nur eines: Ein Modell kann wiedergeben, was in seinem eigenen Prompt steht.

Dasselbe passiert, wenn Sie am Prompt feilen, bis der Eval-Wert stimmt. Der Prompt ist dann auf Ihr Eval-Set angepasst. Die Zahl sagt nichts mehr über neue Eingaben. Oder das synthetische Set stammt von demselben Modell, das Sie prüfen wollen. Dann testen Sie das Modell gegen seine eigenen Annahmen.

Die Vorbeugung ist unspektakulär und wirksam:

• Halten Sie ein Testset zurück: einen Teil der Beispiele, den Sie beim Entwickeln nie ansehen. Sie öffnen es nur, wenn eine Entscheidung ansteht („liefern wir aus?“). Nicht beim Ausprobieren. Wie groß es ist, wie lange es hält und was danach kommt, steht im nächsten Abschnitt.
• Ziehen Sie nie Few-Shot-Beispiele aus dem Eval-Set.
• Nehmen Sie frische Produktions-Traces auf, im selben Takt wie Ihre Fehleranalyse.
• Versionieren Sie das Set. Halten Sie fest, welche Version welche Zahl erzeugt hat.

Entwicklungs- und Testdaten trennen

Wenn Sie den Prompt so lange ändern, bis Ihre Fälle bestehen, sagen die Fälle nichts mehr über neue Eingaben. Das ist wie bei einem Schüler, der die Prüfungsfragen vorher kennt. Er besteht. Aber Sie wissen nicht, ob er das Fach kann.

Darum teilen Sie Ihre Fälle in zwei Teile. Das Team im durchgerechneten Beispiel kommt am Ende auf 147 Fälle. Dafür sieht die Teilung etwa so aus:

„Sie“ heißt in diesem Abschnitt: das Team, das das System baut und die Fälle schreibt. Das Modell sieht nie eines der beiden Sets als Ganzes; es bekommt bei jedem Lauf nur einzelne Eingaben.

Nehmen Sie ins Testset keine Vorfälle, also keine Fälle aus echten Tickets, bei denen das System schon einmal falsch lag. Vorfälle müssen bei jedem CI-Lauf mitlaufen, weil jeder einzelne davon eine Regression anzeigt. Evals in der CI erklärt, warum ein Vorfall keine Fehlerspanne braucht. Vorfälle bleiben deshalb immer im Entwicklungsset.

Die Ergebnisse auf dem Entwicklungsset darf das Team so oft lesen, wie es will: welche Fälle scheitern, warum, was der Entwurf sagt. Die Ergebnisse auf dem Testset liest das Team nur vor einer Entscheidung, ob ausgeliefert wird. Fällt das Testset schlecht aus, geht das Team zurück ins Entwicklungsset und sucht dort nach der Ursache. Es bessert nicht an den Fällen des Testsets nach. Sonst richtet es das System Stück für Stück auf genau diese Fälle aus, so wie ein Schüler, der die Prüfungsfragen vorher kennt. Das Testset misst dann nicht mehr, wie gut das System ist, sondern wie gut es diese 20 Fälle kennt.

Nach ein paar Entscheidungen hat das Team die Testfälle trotzdem oft genug gelesen. Dann werden sie zu normalen Entwicklungsfällen, und die frischen Traces aus der nächsten Fehleranalyse werden das neue Testset. Nichts wird weggeworfen, und es gibt immer ein Testset, das noch niemand zum Nachbessern benutzt hat.

In der Fünf-Tage-Woche legen Sie das Testset an Tag 3 beiseite. Gebraucht wird es erst bei der ersten Entscheidung über die Auslieferung.

Beschriftung

Beschriften heißt: Sie gehen Ihre Eval-Beispiele durch. Für jedes halten Sie fest, ob die Antwort in Ordnung war oder nicht. Diese Urteile sind die Referenz. Alles andere wird später daran gemessen, auch ein LLM-Judge, den Sie darauf ausrichten. Ohne diese Urteile haben Sie ein Eval-Set, aber keinen Maßstab dafür.

Wie viel von diesem Abschnitt Sie betrifft, hängt an einer Frage: Beschriftet eine Person oder mehrere? Arbeiten Sie allein, brauchen Sie nur die ersten beiden Unterabschnitte: binär statt Skala, und Richtlinien aufschreiben. Der dritte Unterabschnitt misst die Übereinstimmung. Er wird erst wichtig, wenn mehr als eine Person urteilt.

Binär, nicht Likert

Befund: Der Praktiker-Konsens lautet: binäres Bestanden/Nicht bestanden statt 1–5-Skalen. Die Gründe: Eine Skala versteckt Unsicherheit in den mittleren Werten. Annotatoren sind uneins, wo aus einer 3 eine 4 wird. Ein Unterschied auf einer abgestuften Skala braucht eine größere Stichprobe. Und binäre Entscheidungen sind schlicht schneller.

Quelle: Husain & Shankar, LLM Evals FAQ

Brauchen Sie Nuancen, zerlegen Sie das Kriterium. Stufen Sie nicht ab. Statt „Qualität: 3“ nehmen Sie drei binäre Prüfungen: nennt eine echte Quelle, beantwortet die gestellte Frage, bleibt im Rahmen der Richtlinie. Aus jeder einzelnen können Sie etwas ableiten. Aus dem Mittelwert der drei nicht.

Eine dritte Form neben binär und Skala ist die Kategorie: Der Judge ordnet jeder Antwort einen Fehlermodus aus einer festen Liste zu, etwa „falscher Tarif“, „veralteter Abschnitt“, „keine Quelle“, „kein Fehler“. Das ist keine Skala, denn die Kategorien haben keine Reihenfolge. Messen Sie sie wie mehrere binäre Kriterien: je Kategorie eine Trefferquote gegen die Labels. Eine Skala bleibt nur für eine Aufgabe tragbar: zwei Antworten in eine Reihenfolge bringen, etwa im paarweisen Vergleich. Als Gate oder als absolute Zahl taugt sie nicht.

Umstritten: Die akademische Literatur berichtet weiterhin Likert-Korrelationen. Und referenzbasierte Bewertung setzt oft abgestufte Ausgaben voraus. Das ist eine echte Kluft zwischen Forschungspraxis und Produktpraxis. Beide Seiten haben einen Punkt: Abgestufte Werte tragen mehr Information pro Element. Binäre Labels tragen mehr verlässliche Information pro Element.

Ein zweiter Beleg gegen die 1–5-Skala kommt aus einer ganz anderen Ecke, der Annotationsforschung. Kiritchenko und Mohammad ließen Sätze nach ihrer Stimmung bewerten. Einmal auf einer Skala. Und einmal so: Die Bewerter bekommen vier Sätze und nennen nur den besten und den schlechtesten. Bei gleichem Aufwand war die zweite Methode zuverlässiger. Denn Menschen beantworten „Welcher ist besser?“ stabiler als „Wie gut ist dieser, von 1 bis 5?“. Die Methode heißt Best-Worst-Scaling. Beide Befunde sagen also dasselbe: Die Skala ist das Problem, nicht die Bewerter. Sie unterscheiden sich nur im Ersatz. Hier bestanden/nicht bestanden, dort bester/schlechtester.

Quelle: Kiritchenko & Mohammad, Best-Worst Scaling More Reliable than Rating Scales, ACL 2017

Schreiben Sie die Richtlinien auf

Annotatoren sind die, die Labels vergeben: Sie lesen eine Antwort und schreiben bestanden oder nicht bestanden dazu, mit Begründung. Im Praxisbeispiel ist das die Supportleitung. Es kann auch ein Modell sein, wenn Sie ein Modell labeln lassen. Die Richtlinie ist der Text, nach dem sie entscheiden: das Kriterium in einem Satz, dazu Beispiele. Wer labelt, kann mitten in der Arbeit niemanden fragen, wie ein Fall gemeint ist. Das gilt für Menschen wie für Modelle. Eine aufgeschriebene Richtlinie ist deshalb der einzige Weg, dass alle Labels nach derselben Regel entstehen.

Die Richtlinie ist beim ersten Label nicht fertig. Beim Labeln stoßen Sie auf Fälle, an die niemand gedacht hat, und dann ändern Sie die Richtlinie und labeln die bisherigen Fälle nach der neuen Fassung nach. Das ist Kriteriendrift: Man findet die Kriterien erst, während man bewertet. Das ist kein Prozessfehler, sondern der Normalfall.

Eine brauchbare Richtlinie enthält pro Kriterium: eine Definition in einem Satz, zwei bestandene Beispiele, zwei nicht bestandene Beispiele und mindestens einen Randfall mit ausdrücklicher Auflösung. Die Randfälle sind der Teil, der sich wirklich übertragen lässt.

So sieht eine aus. Angenommen, Ihr Kriterium heißt „nennt eine echte Quelle“:

Definition. Die Antwort verweist auf mindestens ein Dokument, das tatsächlich abgerufen wurde.

Bestanden. „Laut der Preisliste 2026 (Dokument PL-2026) kostet der Tarif 49 €.“ Das Dokument war im Kontext, die Kennung stimmt.

Bestanden. „Das steht in der Preisliste, die Sie mir geschickt haben.“ Kein Titel genannt, aber eindeutig ein abgerufenes Dokument gemeint.

Nicht bestanden. „Solche Tarife liegen üblicherweise bei etwa 50 €.“ Plausibel, aber ohne Quelle.

Nicht bestanden. „Laut § 5 der AGB …“, obwohl die AGB nicht im Kontext waren. Klingt nach Quelle, ist aber erfunden. Der teure Fall.

Randfall, aufgelöst. Die Antwort nennt zwei Quellen, eine davon erfunden. → gilt als nicht bestanden. Begründung: Eine erfundene Quelle neben einer echten ist für Leser schwerer zu erkennen als eine allein. Nicht leichter.

Der letzte Block ist der eigentliche Zweck der Übung. Zwei Leute lesen dieselbe Definition und urteilen bei dieser einen Antwort verschieden. Das bleibt so, bis jemand den Fall aufschreibt und die Begründung dazu.

Übereinstimmung messen, wenn Sie mehr als einen Annotator haben

Wozu das dient: Sie prüfen damit nicht die Annotatoren. Sie prüfen Ihre Richtlinien. Bewerten zwei Leute dieselben Antworten verschieden, ist meist die Regel unklar. Nicht die Person unzuverlässig. Und wenn Sie später einen LLM-Judge auf diese Labels ausrichten, erbt er genau diese Unschärfe. Ein Judge wird nie konsistenter als die Labels, aus denen er gebaut ist.

Rohe Übereinstimmungsquoten täuschen bei unausgewogenen Klassen. Beispiel: 90 % der Antworten sind bestanden. Zwei Annotatoren sagen immer „bestanden“. Sie stimmen zu 90 % überein und haben nichts gezeigt.

κ (Kappa) beantwortet genau eine Frage: Wie viel Übereinstimmung bleibt übrig, wenn man den Anteil abzieht, den zwei Leute allein durch Raten erreicht hätten? 0 heißt „nicht besser als Zufall“. 1 heißt „vollständig einig“. Drei Varianten sind gebräuchlich:

• Cohens κ: zwei Annotatoren, zufallskorrigiert. Der Standard.
• Fleiss’ κ: mehr als zwei Annotatoren.
• Krippendorffs α: verkraftet fehlende Bewertungen und nicht-binäre Skalen. Die richtige Wahl für unordentliche reale Abläufe, in denen nicht jeder alles bewertet.

Zur Einordnung: Die verbreiteten Bänder gehen auf Landis und Koch (1977) zurück. 0,41–0,60 heißt „moderat“, 0,61–0,80 „substanziell“, darüber „nahezu vollständig“. Die Autoren selbst nennen diese Grenzen willkürlich. Sie sind eine Konvention, kein Messwert.

Umstritten: Wie hoch die Latte liegen sollte, ist zwischen den Disziplinen strittig. In der Computerlinguistik gilt seit Artstein und Poesio die Faustregel: κ > 0,8 für verlässliche Schlüsse, 0,67–0,8 für vorläufige. Das ist deutlich strenger als κ ≥ 0,5. Diesen Wert schlagen wir hier als Arbeitslatte für Eval-Labels vor. Wir halten die niedrigere Schwelle für vertretbar, weil Eval-Labels eine Entscheidung stützen und keine Publikation. Aber das ist eine Abwägung, keine Regel. Wer veröffentlicht oder auditiert wird, nimmt die strengere Latte.

Quelle: Artstein & Poesio, Inter-Coder Agreement for Computational Linguistics, Computational Linguistics 34(4), 2008; Landis & Koch, Biometrics 33(1), 1977

Mensch-zu-Mensch-κ kann bei einer sauberen Aufgabe 0,97 erreichen (siehe die TriviaQA-Zahl in wo Judges versagen). Geringe Übereinstimmung heißt also meist: Die Richtlinien sind unterbestimmt. Nicht: Die Aufgabe ist von Natur aus subjektiv.

Die Zahl ist nur der Anfang. Was danach kommt, macht die Labels besser. Nehmen Sie die Fälle, bei denen die Annotatoren uneins waren. Besprechen Sie sie. Ändern Sie dann die Richtlinie, also einen aufgelösten Randfall mehr. Ändern Sie nicht die Meinung einer Person. Danach labeln beide die strittigen Fälle neu. Bleibt ein Fall weiter strittig, markieren Sie ihn als mehrdeutig. Nehmen Sie ihn aus dem Stapel, an dem Sie den Judge messen. Ein Judge kann nicht besser sein als Menschen, die sich nicht einig sind. Die Übereinstimmung Ihrer Annotatoren auf denselben Fällen ist die Obergrenze. Vor ihr lesen Sie seine Trefferquote.

Haben Sie eine einzelne Person, die entscheidet, brauchen Sie diese Zahlen nicht. Die Richtlinien brauchen Sie trotzdem. Für den Tag, an dem diese Person im Urlaub ist. Und für den Judge, den Sie gleich aus ihren Labels bauen.

Versionierung

Behandeln Sie das Eval-Set wie Quellcode. Denn genau das ist es.

• Es liegt im Repository oder in einem Speicher mit unveränderlichen Versionen.
• Jede berichtete Zahl trägt die Version des Datensatzes, die sie erzeugt hat.
• Beispiele hinzufügen erzeugt eine neue Version. Werte über Versionen hinweg zu vergleichen ist ungültig. Machen Sie es schwer, das aus Versehen zu tun.
• Ein Beispiel entfernen braucht eine Begründung in der Commit-Nachricht. Wer still Beispiele löscht, an denen das System scheitert, macht das Eval-Set zur Dekoration.