Auf dem Hugging Face Open LLM Leaderboard belegen zusammengeführte und per DPO nachtrainierte Modelle die Spitzenplätze aller Kategorien, wodurch die Vergleichbarkeit der Rangliste laut Community-Diskussion grundlegend in Frage gestellt wird. Wenn Trainingsdaten synthetisch aus Benchmark-ähnlichen Quellen abgeleitet werden, messen Ranglisten keine echte Modellqualität mehr. Nutzer, die auf Basis des Leaderboards Modelle für den Produktiveinsatz auswählen, riskieren Fehlentscheidungen. Da zudem GPT-4 und GPT-3.5 wegen fehlender Reproduzierbarkeit bewusst ausgeschlossen bleiben, fehlt ein wichtiger Referenzpunkt. Entscheider sollten Benchmark-Ergebnisse daher stets gegen interne Evaluierungen prüfen.

Synthetic Data Leakage im Open LLM Leaderboard: Wenn Benchmark-Ergebnisse die Realität verzerren

Das Hugging Face Open LLM Leaderboard verliert zunehmend seine Funktion als verlässlicher Maßstab für Open-Source-Sprachmodelle. Der Grund: Modelle, die durch Merging-Techniken und Direct Preference Optimization (DPO) trainiert wurden, dominieren die Spitzenplätze, ohne dass ihre tatsächliche Leistungsfähigkeit im Praxiseinsatz diese Rankings rechtfertigt. Community-Mitglieder haben in öffentlichen Diskussionen auf der Plattform dokumentiert, dass Trainingssets Fragen enthalten, die Test-Fragen aus Benchmark-Datensätzen wie TruthfulQA und GSM8k in ihrer Struktur so stark ähneln, dass eine sinnvolle Evaluation kaum noch möglich ist.

Das Kernproblem: Benchmark-Daten im Training

In einer viel beachteten Diskussion auf dem Leaderboard-Forum wurde festgestellt, dass Modelle aller Größenklassen die Rangliste anführen, nachdem sie Merging- und DPO-Verfahren durchlaufen haben. Dabei geht die ursprüngliche Leaderboard-Funktion verloren: die Beurteilung des tatsächlichen Mehrwerts eines Open-Source-Modells.

Konkret identifizierte die Community zwei Problemtypen:

Direkte Datenkontamination: Feinabstimmungsdatensätze enthalten TruthfulQA-Daten direkt. Das Modell lernt die Antworten auf Testfragen, anstatt das abgefragte Wissen zu internalisieren. Dies gilt nach Einschätzung von Community-Mitgliedern als klar unangemessen.

Strukturähnliche Kontamination: Bei GSM8k zeigen sich Fälle, in denen Trainingsfragen nahezu identisch mit Testfragen sind, lediglich mit veränderten Zahlenwerten. Diese Form ist schwerer zu erkennen und schwerer zu regulieren, denn wie auch bei GPT-4 festgestellt wurde, haben selbst bekannte Modelle GSM8k-Daten im Training verwendet. Der Unterschied zwischen Kompetenztraining und direktem Wissensinjizieren verschwimmt damit zunehmend.

Reproduzierbarkeit als strukturelles Hindernis

Ein paralleles Problem betrifft den Vergleich mit proprietären Modellen. Nutzer des Leaderboards forderten wiederholt, GPT-3.5 und GPT-4 als Referenzwerte einzubeziehen. Das Leaderboard-Team lehnte dies aus zwei Gründen ab: Erstens handelt es sich erklärtermaßen um ein Leaderboard für offene Modelle. Zweitens ändern sich OpenAI-APIs kontinuierlich, sodass eine Evaluation nur für den exakten Erhebungszeitpunkt valide wäre. Reproduzierbarkeit, ein Kernanspruch wissenschaftlicher Benchmark-Methodik, ist bei Closed-Source-APIs strukturell nicht gewährleistet.

Dieser Umstand ist nicht trivial: Entscheider, die Leaderboard-Ergebnisse für Beschaffungsentscheidungen nutzen, können nicht sicherstellen, dass ein zu einem bestimmten Zeitpunkt dokumentiertes Modellverhalten heute noch zutrifft.

Neue Benchmarks, neue Interpretationsfragen

Mit der Einführung aktualisierter Benchmarks im Jahr 2024 versuchte das Leaderboard-Team, die Evaluierungsbasis zu verbessern. Community-Mitglieder erstellten eigenständig Übersichten zu den neuen Benchmark-Kategorien, um das Verständnis zu erleichtern. Das offizielle Team bestätigte, dass Normalisierungen auf Multiple-Choice-Aufgaben wie MMLU-Pro angewandt werden, verwies jedoch für technische Details zur Implementierung auf externe Dokumentationsquellen. Fragen nach dem genauen Code-Pfad für diese Normalisierungslogik blieben in der Community-Diskussion offen.

Das verdeutlicht ein strukturelles Transparenzproblem: Selbst fortgeschrittene Nutzer können Ergebnisse ohne Zugang zu vollständigen Implementierungsdetails nicht vollständig reproduzieren.

Praktische Implikationen für Entscheider

1. Leaderboard-Rankings nicht als alleinige Entscheidungsgrundlage verwenden. Spitzenplätze auf dem Open LLM Leaderboard können das Resultat von Merging-Techniken und Benchmark-spezifischem Training sein, nicht zwingend überlegener Allgemein-Kompetenz. Unternehmen sollten aufgabenspezifische Evaluierungen in ihrer eigenen Infrastruktur priorisieren.

2. Auf Herkunft und Zusammensetzung von Feinabstimmungsdaten achten. Beim Einsatz oder der Beschaffung feinabgestimmter Modelle sollten Sie nachfragen, welche Datensätze für das Training verwendet wurden und ob Überschneidungen mit gängigen Benchmark-Datensätzen dokumentiert sind. Transparente Anbieter liefern entsprechende Modellkarten.

3. Reproduzierbarkeit als Auswahlkriterium etablieren. Bevorzugen Sie Modelle und Evaluierungsquellen, bei denen Benchmark-Ergebnisse unabhängig reproduziert werden können. Closed-API-Ergebnisse ohne Zugang zur Evaluierungsinfrastruktur sind per se nicht verifizierbar. Vergleichende Analysen unabhängiger Messdienste bieten hier mehr Substanz als Hersteller-Eigenangaben.

4. Benchmark-Validierungsmethoden in die eigene KI-Governance aufnehmen. Wer intern oder im Einkauf Sprachmodelle bewertet, sollte Datenkontamination als eigene Risikokategorie erfassen. Das betrifft sowohl den Einkauf externer Modelle als auch den Aufbau eigener Feinabstimmungs-Pipelines. Strukturähnliche Datenleckagen, bei denen Testfragen mit minimal veränderten Parametern im Training auftauchen, sind schwerer zu detektieren als direkte Übernahmen.

Weiterführende Einschätzungen zu Benchmark-Methodik und Validierungsansätzen finden Sie in unseren Analysen zu LLM-Benchmark-Manipulation und Validierung, zur Datenkontamination in LLM-Benchmarks sowie zum Vergleich von Hugging Face Open LLM Leaderboard und HELM. Methodische Hintergründe zur Reproduzierbarkeitskrise liefert zudem unsere Übersicht zur LLM-Benchmarks-Reproduzierbarkeitskrise.

Quellen

• Hugging Face Open LLM Leaderboard: Suggestions for improving the leaderboard (Discussion #477)
• Hugging Face Open LLM Leaderboard: Benchmarks for GPT-3.5 & GPT-4 for comparison (Discussion #145)
• Hugging Face Open LLM Leaderboard: Resource: Understanding the new benchmarks (Discussion #796)

Häufige Fragen

Was versteht man unter ‘Synthetic Data Leakage’ im Kontext des Open LLM Leaderboards?

Von Synthetic Data Leakage spricht man, wenn Trainingsdaten eines Modells Inhalte enthalten, die den offiziellen Benchmark-Testdaten sehr ähnlich sind oder direkt aus ihnen abgeleitet wurden. Auf dem Hugging Face Open LLM Leaderboard wurde dieses Problem konkret diskutiert: Nutzer wiesen darauf hin, dass etwa beim Benchmark GSM8k Trainingsdatensätze existieren, deren Fragen den Testfragen stark ähneln und sich lediglich in einzelnen Zahlenwerten unterscheiden. Solche Daten gelten laut Community-Diskussion als ‘hochgradig ungeeignet’ für eine faire Bewertung.

Warum hat das Leakage-Problem die Aussagekraft des Leaderboards eingeschränkt?

Laut einer Community-Diskussion auf der Hugging Face-Plattform (Dezember 2023) haben Modelle, die durch Merging und DPO (Direct Preference Optimization) trainiert wurden, die Spitzenplätze des Leaderboards übernommen. Dies gelte über alle Modellgrößen hinweg, nicht nur im 7B-Segment. Die ursprüngliche Funktion des Leaderboards, die tatsächlichen Stärken von Open-Source-Modellen vergleichbar zu machen, sei dadurch erheblich beeinträchtigt worden. Die Community forderte daraufhin eine grundlegende Überarbeitung der Regeln für zugelassene Trainingsdaten.

Welche Benchmarks sind besonders anfällig für Daten-Leakage, und was empfiehlt die Community?

Besonders diskutiert werden TruthfulQA und GSM8k. Für TruthfulQA wurde gefordert, Modelle, die mit TruthfulQA-Daten feingetuned wurden, grundsätzlich vom Leaderboard auszuschließen. Bei GSM8k ist die Bewertung differenzierter: Da auch bekannte proprietäre Modelle wie GPT-4 GSM8k-Daten im Training genutzt haben sollen, wird hier weniger ein pauschales Verbot, sondern eine klare Transparenzpflicht gefordert. Entscheidend sei laut Community, zwischen Trainings- und Testdaten strikt zu unterscheiden und synthetisch generierte Varianten der Testfragen als unzulässig zu werten.

Warum werden proprietäre Modelle wie GPT-4 nicht als Vergleichsreferenz in das Leaderboard aufgenommen, obwohl das die Einordnung erleichtern würde?

Das Hugging Face-Team hat den Ausschluss von Modellen mit geschlossenen APIs wie GPT-3.5 oder GPT-4 offiziell begründet: Zum einen ist das Leaderboard konzeptionell auf offene Modelle ausgerichtet. Zum anderen verändern sich API-basierte Modelle über die Zeit, sodass eine einmalige Evaluation keine reproduzierbaren Ergebnisse liefert. Die Community wies zudem darauf hin, dass nicht bekannt ist, nach welchen genauen Verfahren OpenAI eigene Benchmark-Ergebnisse ermittelt, was eine Vergleichbarkeit mit dem standardisierten Evaluationsrahmen des Leaderboards zusätzlich erschwert.

Welche Validierungsmaßnahmen hat das Open LLM Leaderboard 2024 eingeführt, um die Benchmarkqualität zu verbessern?

Im Zuge einer Überarbeitung des Leaderboards wurden 2024 neue Benchmarks eingeführt. Das Team veröffentlichte dazu einen Blogbeitrag sowie eine About-Seite mit Erläuterungen zu den einzelnen Benchmarks. Auf Community-Ebene entstanden ergänzend Zusammenfassungen, die erklären, was jeder Benchmark misst. Diskutiert wurde auch die Normalisierung von Scores bei Multiple-Choice-Aufgaben wie MMLU-Pro. Nutzer forderten zudem, dass der zugehörige Normalisierungscode im verwendeten Evaluations-Framework ‘lm-eval-harness’ besser dokumentiert wird, um Reproduzierbarkeit sicherzustellen.

Dieser Artikel wurde von einem KI-System automatisiert erstellt. Kennzeichnung gemäß Art. 50 der EU-KI-Verordnung.