Schwimmende Ground Truth: Festlegung der Datensatzversion in LLM-Bewertungssuiten

Wenn sich der Score eines LLM-Benchmarks bei zwei Durchläufen ändert, möchte man wissen, ob sich das Modell geändert hat oder die Daten, anhand derer es bewertet wurde. In den meisten offenen Bewertungssystemen wird die zweite Möglichkeit nicht erfasst. Eine kürzliche Überprüfung des Aufgabenkatalogs in lm-evaluation-harness, einem der am weitesten verbreiteten Tools für die Bewertung offener Modelle, ergab, dass von 841 Konfigurationen genau eine ein Feld für die Dataset-Revision enthält – doch dieser Wert ist keineswegs ein Versionsbezeichner. Dieser Artikel erklärt, wie diese Zahl ermittelt wurde, warum der Nenner genauso wichtig ist wie der Zähler, wie ein anderes Tool einen gegenteiligen Kompromiss eingegangen ist und wie Sie dieselbe Überprüfung für Ihre eigenen Bewertungen durchführen können.

Die Hauptzahl und die verworfene Zahl

Diese Messung lohnt es, sie zu untersuchen – teilweise wegen der Art und Weise, wie sie zunächst fehlschlug. Eine frühe Version der Zählung gab an, dass eine Konfiguration von 13.986 deren Daten gespeichert habe, was eine weitaus dramatischere Zahl darstellt. Diese Angabe wurde bereits innerhalb weniger Stunden verworfen. Von diesen 13.986 Dateien bezeichnen 10.391 keine eigene Datensammlung, sondern erben diese über include: von einer Elterndatei, während 2.966 Gruppendateien sind, die überhaupt keine Datensammlung benennen. Beide Arten haben nichts zu speichern, wodurch ihre Einbeziehung den Nenner vergrößert und die Ergebnisse stärker erscheinen lässt, als sie tatsächlich sind. Die Analysten wiesen darauf hin, dass dies bereits das zweite Mal innerhalb einer Woche war, dass beeindruckende Zahlen aufgrund mangelnder Überprüfung des Inhalts des Nenners entstanden – was eine nützliche Warnung für alle darstellt, die eigene Metriken erstellen.

Nach der Korrektur lautet die Erkenntnis wie folgt: In lm-evaluation-harness nennen 841 Task-Konfigurationen direkt ein Datensatz, und genau eine füllt ein Revision-Feld aus. Dieses Feld enthält refs/convert/parquet, einen Verweis, der ein Speicherformat statt eine spezifische Datenversion auswählt. Praktisch gesehen ist keine Konfiguration festgelegt. Jeder Ausführungsvorgang wird anhand des Zustands des übergeordneten Datensatzes am Tag der Ausführung bewertet.

Kernergebnisse im Überblick

• Von 13.986 Task-Konfigurationen nennen 841 direkt einen Datensatz. Die übrigen 13.145 teilen sich in 10.391 Dateien auf, die einen Datensatz über include: erben, sowie 2.966 Gruppierungsdateien ohne eigenen Datensatz.
• Nur eine dieser 841 Konfigurationen legt ein Revision- oder SHA-Schlüssel fest, und der darin enthaltene Wert refs/convert/parquet wählt ein Dateiformat anstelle einer festgelegten Version aus.

Von den 673 Python-Aufgabendateien rufen nur 15 die Funktion load_dataset auf, und von diesen liefern lediglich 2 den Parameter revision=.

Die Konfigurationen beziehen sich auf 273 verschiedene Datensätze. Bei dem mittlerweile am häufigsten genutzten Datensatz wurde keine Konfiguration, die auf ihn verweist, in 547,9 Tagen geändert. 196 der 273 Datensätze (71,8 %) waren bereits länger als ein Jahr alt und 245 (89,7 %) länger als sechs Monate.

openai/evals verfolgt einen gegenteiligen Ansatz: 455 der 463 Bewertungen lesen eine im Repository vorhandene samples_jsonl-Datei, die wiederum von 722 Datendateien unterstützt wird, die im Repository gespeichert sind. Die Referenzwerte können sich nicht verschieben, können aber veraltet werden.

Es wurde nicht überprüft, ob sich tatsächlich irgendwelche upstream-Datensätze geändert haben, da huggingface.co aus der Prüfumgebung nicht erreichbar war. Die Erkenntnis ist, dass eine Verschiebung unentdeckt bleiben würde, nicht, dass tatsächlich eine solche aufgetreten ist.

Kurz gesagt

Eine Bewertungsumgebung ist im Grunde ein Abhängigkeitsgraph, und Softwareteams fixieren Abhängigkeiten aus guten Gründen. Wenn man jede Konfiguration in lm-evaluation-harness durchgeht, das Datensatzensemble extrahiert, gegen das jede Bewertung vorgenommen wird, und nach einer fixierten Version sucht, ergibt sich ein Kandidat – doch das ist eigentlich keine echte Fixierung. Die Überprüfung, wie lange diese Konfigurationen unverändert geblieben sind, zeigte, dass das mediane Datensatzensemble seit etwa achtzehn Monaten keine bearbeitete Referenzkonfiguration hatte. All das zeigt nicht, dass irgendeine veröffentlichte Benchmark-Zahl falsch ist. Es zeigt lediglich, dass, falls eine Zahl aufgrund von Datenänderungen falsch werden sollte, die Umgebung selbst kein Signal geben würde.

Warum ein Benchmark eine fixierte Datensatzversion benötigt

Das getestete Modell ist nicht das Einzige, was sich ändern kann. Jede Aufgabekonfiguration bezieht sich auf ein Datensatz, zum Beispiel alexandrainst/m_truthfulqa, OALL/ACVA oder CogComp/mc_taco, und ein auf einer öffentlichen Plattform gehosteter Datensatz ist ein lebendiges Werkzeug. Er hat Wartungspersonal und erhält Korrekturen, Lizenzänderungen, Neuteilungen, neue Konfigurationen sowie gelegentlich eine stillschweigende Korrektur einer als fehlerhaft bekannten Etikette. Diese Aktivitäten sind normal und meist vorteilhaft.

Das Problem liegt darin, wie dies Vergleiche beeinflusst. Eine Bewertung hat nur dann eine Bedeutung, wenn sie relativ zu einem stabilen Referenzwert angegeben wird. Wenn eine neue Modellversion einen anderen Wert ergibt, haben Sie etwas über das Modell gelernt. Wenn hingegen die Daten sich ändern, beobachten Sie lediglich ein Messfehlerphänomen, das wie eine Erkenntnis aussieht. Ohne aufgezeichnete Überarbeitung gibt es keine Möglichkeit, die beiden voneinander zu unterscheiden – weder im Nachhinein noch zum Zeitpunkt der Auswertung.

Eine nicht gespeicherte Bewertung ist eine Messung, deren Referenzwert niemals in den Protokollaufzeichnungen festgehalten wurde.

Dies ist derselbe Grundsatz hinter Lockfiles in JavaScript-Projekten: Ein package.json-Bereich wie ^4.2.0 ermöglicht es den Builds, stumm neue Codeversionen zu verwenden, während ein Lockfile die genaue verwendete Version im Protokoll festhält. Auch Bewertungsdaten verdienen denselben Umgang.

Wie die Zählung ermittelt wurde

Die Methodik ist der Bereich, in dem die meisten interessanten Entscheidungen getroffen werden, insbesondere was den Nenner betrifft.

• Repository: EleutherAI/lm-evaluation-harness, geklont mit vollständiger Historie unter Verwendung von --filter=blob:none --unshallow. Dabei wurden 4.115 Commits vom 27.08.2020 bis zu einem HEAD-Tag vom 10.09.2026 berücksichtigt, wobei die Messung am 12. September 2026 durchgeführt wurde. Der Katalog ändert sich ständig, sodass spätere Ausführungen unterschiedliche Zahlen liefern werden.
• Config-Prüfung: Jedes .yaml- und .yml-Datei unter lm_eval/tasks. Für jede Datei extrahierte das Skript dataset_path oder hf_path, suchte nach dataset_revision, revision, dataset_sha oder sha und protokollierte, ob die Datei include: verwendete.

Eignung als Nenner: Nur Dateien, die selbst einen Datensatz benennen. Konfigurationen, die vererbt werden, sowie Gruppendateien, die lediglich andere Aufgaben zusammenfassen, wurden ausgeschlossen, da sie nichts Eigenes zum Verknüpfen haben.

Veraltetheit: Ein git log pro Datei gibt das Datum an, an dem jede Datei hinzugefügt und zuletzt geändert wurde. Dieses Datum wird im Vergleich zum HEAD-Commit-Datum und nicht zum aktuellen Datum gemessen, damit die Werte im Laufe der Zeit konstant bleiben.

Durch dieses Filtern blieben 841 geeignete Konfigurationen übrig, die auf 273 verschiedene Datensätze verweisen.

Wie veraltet sind die Konfigurationen?

Die Veraltetheit muss auf zwei Arten angegeben werden, denn die offensichtliche Berechnung erwies sich als irreführend – das wurde erst durch manuelle Überprüfung klar.

Berechnet pro Konfiguration beträgt die mittlere Zeit seit der letzten Änderung 729,8 Tage. Von den 841 Konfigurationen wurden 691 (82,2 %) seit über einem Jahr nicht mehr angefasst, und 551 (65,5 %) wurden nach ihrer Hinzufügung überhaupt nie geändert.

Diese Zahlen übertreiben die Realität. Schon fünf Commit-Operationen führten zu 50,9 % der 841 Konfigurationen, und allein ein Commit mit dem Code decc533d führte an einem einzigen Tag zu 272 Änderungen. Die Verteilung pro Konfiguration spiegelt daher nicht 841 unabhängige Entscheidungen wider, die nach eigenen Zeitplänen altern; vielmehr zeigt sie einige umfangreiche Beiträge sowie eine lange Schwanzverteilung.

Durch Gruppierung nach Datensätzen anstelle von Dateien wird diese Clusterung ausgeglichen:

• Im Fall des mittleren Datensatzes waren seit der letzten Änderung einer referenzierenden Konfiguration 547,9 Tage vergangen.
• Von den 273 Datensätzen lagen 196 (71,8 %) bereits über einem Jahr zurück.
• 245 der 273 Datensätze (89,7 %) lagen bereits über 180 Tagen zurück.

Der am meisten vernachlässigte Fall lag bei 994,1 Tagen.

Die Zahl pro Datensatz ist diejenige, die es wert ist, zitiert zu werden, denn sie übersteht den Einwand bezüglich der Clusterung. Der Median liegt weiterhin bei etwa achtzehn Monaten, und neun von zehn Datensätzen liegen über sechs Monaten.

Pinning wird unterstützt, aber nur selten genutzt

Es wäre ungerecht, das Tool zu kritisieren, wenn es Pinning unmöglich machen würde – doch das tut es nicht. Der zugrunde liegende Lader ist die Standard-Hugging Face datasets-Bibliothek, und load_dataset akzeptiert ein Argument für die Revision. Im Python-Teil des Task-Katalogs geben 2 von 15 Dateien, die load_dataset aufrufen, den Wert revision= an – von insgesamt 673 Python-Dateien in diesem Verzeichnis – wobei eine dieser beiden Dateien auf einen Pull-Request-Referenzpunkt verweist.

Auch wenn das Pinnen verfügbar ist, nutzt es fast niemand, und im Arbeitsablauf gibt es nichts, was die Mitwirkenden dazu anregt. Wenn der Standardwert „schwimmen“ ist, schwimmen 841 Konfigurationen herum, denn genau darauf basieren große Kataloge in der Praxis.

Falls Sie Bewertungen verwalten, ist die günstigste Vorgehensweise, heute in Ihren eigenen Aufgabendefinitionen nach einem Revisionsfeld zu suchen und zu prüfen, wie viele Treffer dabei auftauchen.

Der gegenteilige Kompromiss: Vordefinierte Daten in openai/evals

openai/evals beantwortet dieselbe Frage in die entgegengesetzte Richtung, und sein Ansatz ist keineswegs deutlich schlechter. Von 463 Bewertungskonfigurationen lesen 455 ein samples_jsonl-Datei, die im Repository selbst gespeichert ist und 722 Datendateien enthält, um sie zu unterstützen. Die Referenzdaten sind vordefiniert, was bedeutet, dass sie per Konstruktion gepinnt werden: Die Daten werden zusammen mit allem anderen von Git versioniert.

Der Vorteil ist die perfekte Reproduzierbarkeit: Eine im Jahr 2024 durchgeführte Bewertung kann mit bytegenau identischen Eingaben erneut durchgeführt werden. Der Preis ist die Währung. Eine kommerziell verfügbare Kopie erhält niemals Korrekturen aus der Quelle, sodass das Tool zwar nicht abweichen kann, aber allmählich zu einem „Museum“ werden kann – wobei neue Modelle anhand eines Snapshots bewertet werden, dessen Fehler bereits vor Jahren anderswo behoben wurden.

Auch kein der beiden Tools wählt den dritten Weg: Die Festlegung auf eine bestimmte Version und deren bewusste Weiterentwicklung. Das eine Tool bleibt ohne Aufzeichnungen im Fluss, das andere erstarrt ohne Aktualisierungen. In beiden Fällen wird die Wahl standardmäßig getroffen und nicht durch eine bewusste Entscheidung.

Was die Messung nicht zeigt

Die Grenzen der Analyse sind genauso wichtig wie ihre Ergebnisse.

• Es wurden keine Änderungen am Datensatz festgestellt. Die Netzwerkpolicy der Prüfumgebung lehnte Verbindungen zu huggingface.co ab; der Proxy gab bei CONNECT-Anfragen von beiden getesteten Maschinen den Fehler 403 zurück, sodass keine Informationen zur Auflösung des Namens und zum letzten Änderungszeitpunkt abgerufen werden konnten. Hier geht es ausschließlich darum, ob eine Änderung erkannt werden würde, nicht darum, ob tatsächlich eine stattgefunden hat.
• „Nicht angepinnt“ bedeutet nicht „falsch“. Viele dieser Datensätze haben vermutlich nie geändert werden müssen. Die Aussage bezieht sich auf das Fehlen einer Kontrolle, nicht auf einen bestehenden Fehler.
• „Veraltet“ bedeutet nicht „vernachlässigt“. Eine Konfiguration, an der seit 700 Tagen niemand mehr gearbeitet hat, könnte vollständig und korrekt sein. Das Alter gibt lediglich an, dass niemand sie erneut überprüft hat – was sich von einem Defekt unterscheidet.

Ein einziges Harness repräsentiert nicht das gesamte Feld. Ein Katalog wurde im Detail untersucht und ein weiterer als Vergleich herangezogen. Werkzeuge wie promptfoo, deepeval und ragas sind Bibliotheken und keine Register, und es gibt kein vergleichbares YAML-Task-Katalog für sie, sodass das Ergebnis nichts über diese Werkzeuge aussagt.

Die Ausklammerung von include:-Dateien ist eine eigene Entscheidung. Eine strengere Interpretation könnte fragen, ob Elternkonfigurationen im Namen ihrer Kinder festgelegt werden. Dies wurde überprüft, und das ist nicht der Fall.

Häufige Fragen

Sind veröffentlichte Benchmark-Werte dann unzuverlässig?

Nicht unbedingt, und diese Interpretation sollte abgelehnt werden. Es fehlt eine spezifische Kontrolle. Ein Wert wird nur beeinträchtigt, wenn sich die zugrunde liegenden Daten ändern; die Überprüfung zeigt, dass das Tool in einem solchen Fall keine Aufzeichnungen hinterlässt, die es ermöglichen würden, dies später festzustellen.

Warum prüft man nicht einfach, ob sich die Datensätze geändert haben?

Dafür muss man auf huggingface.co zugreifen, um Datensatz-Revisionen zu ermitteln – was durch die Netzwerkpolicy der Überprüfung mit einer 403-Fehlermeldung bei CONNECT sowohl auf Cloud- als auch auf lokalen Maschinen blockiert wurde. Anstatt Abweichungen aus schwächeren Signalen abzuleiten, beschränkte sich die Prüfung auf das, was allein aus dem Repository überprüft werden kann; deshalb bezieht sich die Feststellung auf das Fixieren statt auf Änderungen.

Ist das Fixieren immer die richtige Lösung?

Nicht automatisch. Ein fixierter Evaluationsprozess erkennt niemals echte Korrekturen fehlerhafter Labels – wodurch openai/evals zwar perfekt reproduzierbar, aber gleichzeitig allmählich ungenau werden kann. Eine besser vertretbare Strategie ist „Fixieren und Vorantreiben“: Eine Revision wird gesperrt, absichtlich weitergeführt und jeder Schritt protokolliert – genau das macht jedoch fast niemand.

Wie kann man sein eigenes Set überprüfen?

Gehen Sie Ihre Aufgabenbeschreibungen durch, extrahieren Sie die Feldnamen des Datensatzes und suchen Sie in diesen Dateien nach irgendwelchen Revisionen oder SHA-Schlüsseln. Das Verhältnis der zweiten zu der ersten Zählung ist die hier besprochene Metrik. Der Audit-Bericht gab etwa dreißig Sekunden Rechenzeit pro tausend Dateien an, sodass es sich um eine kostengünstige Überprüfung handelt, die in CI hinzugefügt werden kann.

Zusammenfassung

• Betrachten Sie Bewertungsdatensätze als Abhängigkeiten: Notieren Sie genau welche Revision zu jedem Wert gehört, den Sie vergleichen möchten.
• Siezen Sie dramatische Verhältnisse, bis Sie geprüft haben, was im Nenner enthalten ist; vererbte und aggregierte Konfigurationen hätten fast eine unauffällige Erkenntnis in eine irreführende verwandelt.
• Schwankende Daten und eingefrorene Daten versagen in entgegengesetzte Richtungen: Die einen verändern sich spurlos, die anderen altern ohne Korrektur. Durch Festlegung von Referenzwerten in Kombination mit einem Changelog lässt sich beides vermeiden.

Veraltetes Material und fehlende Pins deuten auf fehlende Kontrollmechanismen hin, nicht auf fehlerhafte Ergebnisse.

Die offene Frage für jedes Team, das Evaluierungen in CI durchführt, ist konkret: Wenn sich die Bewertung zwischen verschiedenen Ausführungen ändert, was in Ihrer Konfiguration zeigt an, ob sich das Modell oder die Daten verändert haben? Wenn die Antwort „nichts“ ist, ist ein Feld für Überarbeitungen in Ihren Aufgabendefinitionen der günstigste Ausgangspunkt. Sie können das lm-evaluation-harness Task-Katalog sowie das openai/evals Registry direkt prüfen, um die beiden Ansätze zu vergleichen.

Verwandte Literatur

• Eine stufige Karte zu Konzepten der KI-Ingenieurwesen und wann sie bedeutend sind — Erfahren Sie, welche Konzepte der KI-Ingenieurwesen darüber entscheiden, ob ein System überhaupt funktioniert, welche für die Produktion wichtig sind und welche warten können.
• Das Management von LLM-as-a-Judge als lebendigem Produktionssystem — Erfahren Sie, wie Netflix’ vierstufiges Lebenszyklusmodell – Grunddaten, an Richtlinien angepasste Schulung, sicheres Rollout sowie kontinuierliche Überwachung – dazu beiträgt, dass ein LLM-Judge in großem Maßstab präzise bleibt.