Ein KI-Evaluationsdatensatz ist eine versionierte Sammlung produktrelevanter Inputs, Kontexte, Referenzurteile, Fehlerlabels und Metadaten zum Vergleich von Systemverhalten mit Abnahmekriterien. Er bildet die vorgesehene Betriebsverteilung und wichtige Ausnahmen ab statt nur bequeme historische Beispiele. Jedes Element besitzt rechtmässige Herkunft, Annotationsrichtlinie und nachvollziehbaren Entscheid; Sampling, Splits, Grenzen und Änderungen werden dokumentiert, damit Resultate interpretierbar und reproduzierbar sind.
Teams bauen ein “Golden Set” aus zwanzig bekannten Beispielen, kopieren Trainingsmaterial hinein oder behandeln die unaufgezeichnete Präferenz einer Fachperson als Wahrheit. Einfache Fälle dominieren, weil sie häufig sind. Seltene schwere Fehler verschwinden im Mittelwert. Prompts und Modelle werden wiederholt gegen sichtbare Testfälle optimiert, bis der Test zum Entwicklungsdatensatz wird. Der Benchmark steigt, während Produktionsnutzer neue Formate, Richtlinienunklarheit und Verteilungsverschiebung sehen, die nie enthalten waren.
Beginnen Sie mit Produktaufgabe und Entscheidfolge, nicht vorhandenen Zeilen. Definieren Sie Einheit, Systemkontext, akzeptiertes Verhalten, Enthaltung und Fehlertaxonomie. Ziehen Sie normale Verteilung und ergänzen Sie kritische Slices bewusst, ohne ihre Anteile als natürlich auszugeben. Dokumentieren Sie Rechte und Herkunft, trennen Sie Entwicklung und geschützte Evaluation, messen Sie Prüferübereinstimmung und entscheiden Sie Mehrdeutigkeit. Führen Sie eine stabile Regression neben einem rollenden Produktionssatz und berichten Sie je Slice und Version.
Evaluationsvertrag
Definieren, was ein Testfall im Produkt bedeutet
Schreiben Sie den Aufgabenvertrag vor der Sammlung. Definieren Sie Inputeinheit, gesamten sichtbaren Kontext, erwarteten Output oder Aktion, nachgelagerten Nutzer, Entscheidfolge und Referenzquellen. Legen Sie fest, ob das System sich enthalten, fragen oder mehrere gültige Optionen liefern darf. Bei Retrieval verbindet ein Fall eine Anfrage mit einem autorisierten Korpus und Relevanzurteilen. Bei Dokumentextraktion enthält er Quelle, Schema, Feldreferenzen und zulässige Normierung. Bei Entwurf ist eine perfekte Antwort meist schwächer als eine Rubrik zu Wahrheit, Vollständigkeit, Beleg, Weisung und schädlicher Zusage.
Definieren Sie Fehlertaxonomie und Abnahme. Trennen Sie Auslassung, falsche Tatsache, unbelegte Aussage, falschen Umfang, unsichere Aktion, Datenexposition, Weisungsfehler und Latenz. Benennen Sie Fehler mit Nulltoleranz im Release und solche mit statistischer Schwelle. Erfassen Sie Richtlinien-Owner und Entscheidbefugnis für Randfälle. Der Datensatz erzeugt keine Richtlinie; er kodiert eine Version. Können Prüfende wegen undefiniertem Verhalten nicht entscheiden, lösen Sie die Produktregel, statt Widerspruch in einem Label zu verstecken.
| Feld | Definition | Bedeutung |
|---|---|---|
| Evaluationseinheit | Input, Kontext und erwartetes Verhalten | Setzt Vergleichsgrenze |
| Entscheidnutzer | Konsumierende Person oder System | Verbindet Folge |
| Referenzrichtlinie | Quellen und zulässige Variation | Macht Urteil reproduzierbar |
| Fehlertaxonomie | Benannte falsche und schädliche Modi | Verhindert Mittelwertblindheit |
| Enthaltung | Wann keine Antwort erlaubt ist | Testet sicheren Fallback |
| Abnahme | Schwellen und Befugnis | Unterstützt Release-Entscheid |
Sampling
Produktion abbilden und kritische Fälle getrennt sichtbar machen
Beschreiben Sie die Zielpopulation: Zeitraum, Kanäle, Dokumentquellen, Formate, Sprachen, Nutzergruppen, Rechtsräume, Komplexität, Qualität und Saisonalität. Ziehen Sie danach ein repräsentatives Sample und bewahren Sie Auswahlgewichte oder Zählungen. Fehlt Produktion, nutzen Sie einen klar benannten Proxy und beschreiben Sie Unterschiede. Wählen Sie nicht nur bereits gelöste oder sauber lesbare Fälle. Enthalten Sie negative und ausserhalb liegende Inputs, damit auch geprüft wird, ob das System handeln soll.
Erstellen Sie Challenge-Slices für seltenes, aber wichtiges Verhalten: lange Inputs, fehlende Belege, widersprüchliche Anweisungen, Minderheitensprachen, ungewöhnliche Layouts, adversarial Content, sensible Daten und folgenreiche Entscheide. Übersampling macht Fehler sichtbar, schätzt aber nicht ihre Häufigkeit; berichten Sie getrennt. Bewahren Sie je Element Quelle, Zeit, Erlaubnis, Zweck, Transformation und Ausschluss. Begrenzen Sie Zugriff und Aufbewahrung und entfernen Sie unnötige Identität bei Erhalt der für Evaluation nötigen Attribute.
- Zielpopulation vor der Auswahl charakterisieren.
- Proxies kennzeichnen und Unterschiede zur Produktion nennen.
- Negative und ausserhalb liegende Fälle aufnehmen.
- Bewusst überrepräsentierte Challenges getrennt berichten.
- Erlaubnis, Herkunft, Transformation und Aufbewahrung erhalten.
Referenzurteile
Annotation als Messprozess statt Etikettierarbeit behandeln
Schreiben Sie Anweisungen mit Definitionen, Regeln, Beispielen und Eskalation. Trennen Sie objektive Quellenfakten von Produktpolitik und Geschmack. Nutzen Sie bei offenen Outputs strukturierte Rubriken und belegte Begründung statt Stilranglisten. Pilotieren Sie mit qualifizierten Fachpersonen. Messen Sie Übereinstimmung je Label und Slice, untersuchen Sie Verwechslung und überarbeiten Sie Regeln. Hohe Übereinstimmung bei einfachen Fällen beweist keine Konsistenz bei den wichtigen Fehlern.
Erfassen Sie unabhängige Einzelurteile vor der Entscheidung, wo dies zählt. Speichern Sie Label, Begründung, zitierte Evidenz, Rolle, Vertrauen und Anweisungsversion. Widerspruch kann fehlenden Kontext, mehrdeutige Quelle, anderes Fachwissen oder offene Richtlinie zeigen. Ein benannter Adjudicator entscheidet nach Befugnis und darf unbestimmt markieren oder aufteilen statt Mehrheitszwang. Modell-Judges können ausgewählte Vergleiche skalieren, müssen aber gegen zuständige Menschen validiert werden und dürfen nicht unbefragte Autorität derselben Modellfamilie sein.
| Feld | Zweck | Kontrolle |
|---|---|---|
| Label oder Score | Referenzurteil | Erlaubte Werte |
| Begründung | Erklärt Entscheid | Mit Regel verbunden |
| Quelle | Belegt Faktenurteil | Genaue Referenz |
| Prüfermetadaten | Zeigt Kompetenz | Rolle statt unnötige Identität |
| Vertrauen | Zeigt Mehrdeutigkeit | Definierte Skala |
| Adjudikation | Löst oder erhält Widerspruch | Befugnis und Grund |
Lebenszyklus
Integrität schützen und den Datensatz trotzdem lebendig halten
Trennen Sie nach Zweck. Entwicklungsbeispiele sind sichtbar für Prompt-, Modell- und Workflowarbeit. Ein geschützter Abnahmesatz unterstützt Releases und hat beschränkten Zugriff. Eine stabile Regression verfolgt bekanntes Verhalten. Ein rollender Produktionssatz erkennt Drift. Gruppieren Sie verwandte Dokumente, Vorlagen, Kunden oder Zeitfälle vor Splits, damit keine Leakage entsteht. Suchen Sie exakte und semantische Überlappung. Protokollieren Sie Evaluationszugriffe, weil wiederholtes Betrachten geschützter Fehler sie zu Entwicklungswissen macht.
Versionieren Sie Elementmenge, Aufgabenvertrag, Annotationspolitik und Slices zusammen. Berichten Sie mit exakter Version, Fallzahl, Unsicherheit und Grenzen. Löschen Sie schwere Fehler nicht, nur weil die Politik ändert; erfassen Sie Grund und Verlauf. Fügen Sie Produktionsfehler über geprüfte Aufnahme mit Rechten, Deduplizierung, Repräsentativität und Taxonomie hinzu. Aktualisieren Sie den rollenden Satz und entscheiden Sie regelmässig, ob der geschützte Benchmark das Produkt noch abbildet. Ein höherer Score auf veraltetem Material ist keine Betriebsverbesserung.
- Entwicklung, Abnahme, Regression und rollende Produktion trennen.
- Verwandte Inputs vor Splits gruppieren und semantische Leakage prüfen.
- Geschützte Evaluation beschränken und protokollieren.
- Fälle, Richtlinie, Annotation und Slices gemeinsam versionieren.
- Geprüfte Produktionsevidenz zur Entwicklung des Portfolios nutzen.
Woran gute Arbeit erkennbar ist
Konkrete Ergebnisse für KI Evaluationsdatensatz erstellen
- Jedes Element entspricht einer definierten Produktaufgabe und Entscheidung.
- Sampling bildet normalen Traffic ab und lässt kritische seltene Fälle sichtbar.
- Rechte, Quelle, Transformation und sensible Merkmale sind dokumentiert.
- Annotationsregeln trennen Tatsache, Präferenz, Richtlinie und zulässige Variation.
- Prüferuneinigkeit wird Evidenz für Mehrdeutigkeit oder Richtlinienlücken.
- Entwicklungsbeispiele bleiben von geschützter Abnahme getrennt.
- Gesamtmetriken werden durch wichtige Slices und Fehlerklassen ergänzt.
- Produktionsfehler und Verteilungsänderung aktualisieren das Evaluationsportfolio kontrolliert.
Betriebsmodell
So wird die Arbeit ausgeführt
- 01
Evaluationsvertrag schreiben
Definieren Sie Produktentscheid, Input- und Outputeinheit, verfügbaren Kontext, Quellen, erlaubte Variation, Enthaltung, schädliche Fehler, Metriken und Schwellen. Benennen Sie die Befugnis für schwierige Fälle.
- 02
Sampling-Rahmen entwerfen
Charakterisieren Sie Menge, Quellen, Formate, Sprachen, Nutzergruppen, Komplexität und Zeit. Ziehen Sie repräsentative Fälle und ergänzen Sie kritische, seltene, ausserhalb liegende und fehlerhafte Inputs als benannte Challenge-Slices.
- 03
Daten sichern und dokumentieren
Prüfen Sie Erlaubnis, Zweck, Aufbewahrung, Datenschutz und Zugang. Erfassen Sie Herkunft, Zeitraum, Transformationen, Ausschlüsse und Lücken. Entfernen Sie unnötige sensible Daten, ohne wichtige Testattribute zu zerstören.
- 04
Annotieren und entscheiden
Pilotieren Sie klare Regeln mit mehreren qualifizierten Prüfenden. Erfassen Sie Label, Begründung, Quelle, Vertrauen und Widerspruch. Ändern Sie unklare Richtlinie und nutzen Sie dokumentierte Entscheidwege statt erzwungener Mehrheit.
- 05
Teilen, versionieren und aktualisieren
Trennen Sie Entwicklung, geschützte Abnahme, Regression und rollende Produktion. Suchen Sie Überlappung. Versionieren Sie Elemente und Richtlinien, berichten Sie mit Version und fügen Sie geprüfte Produktionsfehler kontrolliert hinzu.
Bewertung
Fragen, die den Entscheid verändern
- Welches Produktverhalten und welcher Folgeentscheid werden evaluiert?
- Welchen Kontext und welche Quelle erhalten System und Prüfende?
- Welche Outputs sind richtig, zulässig, unvollständig oder schädlich?
- Wie werden normaler Traffic und folgenreiche Minderheitsfälle beide sichtbar?
- Besteht das Recht, jeden Input zu speichern und zu evaluieren?
- Welche Fachkompetenz und Entscheidbefugnis sind nötig?
- Welche Beispiele dürfen Entwickler sehen und welche bleiben geschützt?
- Welches Produktionssignal löst neue Version oder Slice aus?
Fehlermuster
Wo Teams die Kontrolle verlieren
Convenience Sampling kann saubere Inputs und kooperative Nutzer überbetonen.
Ein Label kann falsche Eindeutigkeit bei mehreren gültigen Outputs schaffen.
Historische Resultate können alte Richtlinie oder schädlichen Bias kodieren.
Das Entfernen sensibler Attribute kann die Messung von Gruppenschaden verhindern.
Seltene kritische Fälle können im repräsentativen Mittel verschwinden.
Übersampling kann mit Produktionshäufigkeit verwechselt werden.
Wiederholtes Prompt-Tuning gegen den Abnahmesatz kann ihn kontaminieren.
Nahe Duplikate können zwischen Entwicklung und Evaluation leaken.
Modell-Judges können dieselben Blindstellen wie das getestete System tragen.
Ein eingefrorener Benchmark kann steigen, während Produktion und Richtlinie driften.
Messung
Das fertige Ergebnis messen
Gemessen wird der abgeschlossene Prozess inklusive Review-Aufwand und Ausnahmen. Reines Output-Volumen beweist noch keine bessere Arbeitsweise.
- Abdeckung nach Quelle, Format, Sprache und Komplexität
- Zahl kritischer Slices und seltener Fehler
- Elemente mit dokumentierter Erlaubnis und Herkunft
- Annotationsübereinstimmung und Entscheidrate je Label
- Elemente mit Quellenbegründung und Vertrauen
- Duplikat- und semantische Überlappung zwischen Splits
- Zugriffe auf geschützte Evaluation
- Qualität je Slice und Fehlerklasse mit Unsicherheit
- Produktionsfehler ausserhalb des aktuellen Portfolios
- Datensatz- und Richtlinienänderungen je Release
Fragen
Häufige Fragen
Wie gross sollte ein KI-Evaluationsdatensatz sein?
Die Grösse folgt Entscheidpräzision, Aufgabenvariation und kritischen Slices. Beginnen Sie mit genug qualifizierten Fällen für Fehler und Unsicherheit und erweitern Sie dort, wo Abdeckung oder Resultate instabil sind.
Was ist ein Golden Dataset für KI?
Meist ein kuratierter Referenzsatz mit vertrauenswürdigen Urteilen. Dokumentieren Sie Sampling, Richtlinie, Herkunft, Widerspruch, Version und Entscheid, statt “golden” mit vollständiger Wahrheit gleichzusetzen.
Dürfen dieselben Daten für Tuning und Schlussevaluation dienen?
Nicht für eine unabhängige Abnahme. Sobald Entwickler an Beispielen optimieren, sind sie Entwicklungsdaten. Halten Sie einen geschützten Satz und neue Produktionssamples für Generalisierung.
Sollten KI-Judges den Evaluationsdatensatz labeln?
Sie können validierte Teilaufgaben unterstützen, dürfen aber keine zirkuläre Autorität sein. Vergleichen Sie mit qualifizierten Menschen und erhalten Sie menschliche Adjudikation bei Folgen und Mehrdeutigkeit.
Quellen
Primärquellen
- AI test, evaluation, validation and verification National Institute of Standards and Technology
- AI RMF Playbook: Measure National Institute of Standards and Technology
Über den Autor
Tony Kim
Tony schreibt über angewandte AI, verlässliches Product Engineering und Systeme, die komplexe Response-Arbeit kontrollierbar machen.
Zeke
AI Product Engineering, das aus einem Software-Briefing ein zuverlässiges Produkt im Betrieb macht.
Produktverantwortliche, Gründungsteams und Software-Engineering-Teams. Ausgangspunkt sind der bestehende Ablauf, seine Grenzen und die vorhandenen Nachweise.
Zeke ansehen→