„Benchmarks are more broken than we could have imagined.“ Unter diesem Titel – die Benchmarks seien kaputter, als man es sich hätte vorstellen können – hat Horizon Analytics Labs am 21. September seinen Audit-Bericht veröffentlicht. Überraschend ist der Befund nicht: Epoch AI hatte zuvor fünfzehn Benchmarks geprüft und neun als fehlerhaft eingestuft – durchgesickerte Antworten, belohnte Abkürzungen, unvollständige Tests, versagende Prüfroutinen.
Das allein war schon unangenehm. Horizon ging trotzdem weiter und nahm sich die öffentlich einsehbaren Aufgabendatensätze großer Anbieter im Harbor-Hub vor. Die Leitfrage: Passen Anweisung, Umgebung, Referenzlösung und Bewerter zusammen? Wer sich mit KI-Evaluierung beschäftigt, kommt an dieser Frage nicht vorbei.
Eine Benchmark-Aufgabe lässt sich als Prüfung mit vier Beteiligten beschreiben: ein Aufgabenblatt, ein Prüfungsraum, eine Musterlösung und jemand, der korrigiert. Wenn das Aufgabenblatt etwas anderes verlangt, als der Korrektor bewertet, wenn die Musterlösung selbst durchfällt oder die Antwort im Prüfungsraum ausliegt, dann sagt die Note nichts mehr darüber aus, welche Fähigkeit geprüft werden sollte. Horizon hat diese vier Teile gegeneinander gehalten – und dabei Fehler gefunden.
Was Epoch AI fand und was darunter liegt
Epoch AI hat fünfzehn Benchmarks geprüft und bei neun davon Probleme gefunden. Die Bandbreite reichte von durchgesickerten Antworten über belohnte Abkürzungen bis zu Tests, die nicht messen, was sie messen sollen. Das reicht, um misstrauisch zu werden.
Horizon Analytics Labs nahm sich die öffentlich einsehbaren Aufgabendatensätze großer Anbieter vor. Für jede Aufgabe stellte das Team dieselbe Frage – passen Anweisung, Umgebung, Referenzlösung und Bewerter zusammen? So kamen zwanzig Datensätze mit 5.241 Aufgaben zusammen. Das Ergebnis: 29 bestätigt defekte Aufgaben.
Wie diese Zahl zustande kam: Das Team hat alle 5.241 Aufgaben gescannt, 239 davon genauer geprüft und 34 einzeln durchgesehen. Die 29 bestätigten Fälle stammen aus dem gesamten Verfahren, nicht nur aus der manuellen Einzelprüfung. Der Bericht ist der erste Teil einer fortlaufenden Untersuchung und Ausgangspunkt für einen Anbieter-Qualitätsindex, den Horizon aufbauen will. Dazu gehört eine Einordnung: Horizon verkauft selbst Datensatz-Audits, der Bericht wirbt also auch für die eigene Dienstleistung. Die Befunde sind allerdings einzeln belegt und mit den betroffenen Aufgaben verlinkt.
Fünf Arten von Benchmark-Fehlern
Die gefundenen Fehler waren unterschiedlich, aber nicht zufällig verteilt. Jeder bestätigte Fall ließ sich einer von fünf Kategorien zuordnen. Die erste ist die Antwortkontamination in Benchmarks: Die Umgebung enthält die Lösung. Ein Agent kann zum Beispiel den fertigen Fix aus der Git-Historie holen, statt den Fehler zu suchen.
Die zweite Kategorie sind unvollständige Tests. Der Bewerter prüft weniger, als die Anweisung verlangt. Ein Beispiel aus dem Bericht: Eine Aufgabe verlangt Änderungen an vier Teilen eines Streaming-Systems, die Tests fassen aber nur ein einziges Paket an.
Die dritte Kategorie ist die trivial spielbare Bewertung. Ein Modell punktet, ohne die Arbeit zu erledigen. Wird etwa ein editierbares Wörterbuch ausgetauscht, springt dieselbe erfundene Antwort von null auf volle Punktzahl. Die Bewertung lässt sich mit einem Handgriff umgehen.
Die vierte Kategorie ist der Spec-Test- oder Fähigkeits-Mismatch: Anweisung und Bewerter widersprechen sich, oder das Bestehen beweist nicht die Fähigkeit, die die Aufgabe zu prüfen vorgibt. In einem Fall verlangten zwei Teile der Bewertungskonfiguration unterschiedliche Finanzwerte für dieselbe Antwort.
Die fünfte Kategorie ist der Oracle-Fehler oder das instabile Grading. Die veröffentlichte Lösung scheitert, oder das Ergebnis hängt von etwas Unstabilem ab. Ein Beispiel: Die Lösung des Autors erhält null Punkte, nachdem sich eine externe Datenbank geändert hat.
Die Verteilung fällt deutlich aus: 17 Aufgaben mit unvollständigen Tests, 14 mit Antwortkontamination, elf mit Spec-Test-Mismatch, acht mit spielbarer Bewertung und vier mit Oracle- oder Flaky-Problemen. Eine Aufgabe kann auf mehr als eine Weise scheitern, deshalb überschneiden sich diese Zahlen. Insgesamt ergibt das 54 Kategorie-Platzierungen.
Warum die meisten Fehler die Modelle besser aussehen lassen
Kontamination, unvollständige Tests und spielbare Bewertung machen 39 dieser 54 Platzierungen aus. Diese Fehler verschenken Punkte. Ein Modell erscheint leistungsfähiger, weil es die Antwort in der Umgebung gefunden, nur den zufällig getesteten Teil erledigt oder eine akzeptierte Abkürzung entdeckt hat.
Der Bericht nennt das Ergebnis deshalb nicht einfach Rauschen, sondern schmeichelhaftes Rauschen. Der Fehler verzerrt die Rangliste nicht in eine beliebige Richtung, sondern systematisch zugunsten der Modelle. Deshalb bleiben fehlerhafte KI-Benchmarks oft unbemerkt: Ein zu gutes Ergebnis fällt niemandem unangenehm auf.
Die Probleme waren außerdem nicht gleichmäßig verteilt. In der geprüften Stichprobe von Scale AI dominierte Kontamination, bei Terminal-Bench 2.1 häuften sich unvollständige Tests, Shortcuts und Bewertungsfehler, bei OpenThoughts fanden sich editierbare Bewerter-Eingaben und Referenzlösungen, die ihre eigenen Aufgaben nicht lösten. Das heißt nicht, dass jeder Datensatz dieser Anbieter dasselbe Problem hat. Es heißt, dass die geprüften Stichproben auf unterschiedliche Weise scheiterten – eine einzige Gesamtfehlerquote würde diesen Unterschied verwischen.
Die Autoren betonen, dass es sich um Zählungen bestätigter Befunde in den geprüften Stichproben handelt, nicht um Fehlerquoten des gesamten Anbieters. Eine leere Zelle bedeutet nur, dass dieser Fehlertyp hier nicht bestätigt wurde – nicht, dass er nicht existiert.
Fünf Beispiele
Bei Scale AI im Datensatz SWE-bench Pro sollte ein Modell einen Ansible-Fehler reparieren. Das Aufgaben-Image enthielt den fertigen Fix allerdings noch in seiner Git-Historie. Mit deaktiviertem Netzwerk ließ sich die Lösung wiederherstellen, und die echte Prüfroutine gab volle Punktzahl: 16 von 16 Tests. Die Lösung lag bereit. Einen Tag nach dem Audit hat Scale eine überarbeitete Fassung veröffentlicht, SWE-Bench Pro V2; ob sie diese Lecks schließt, prüft der Bericht nicht.
Ein zweites Beispiel aus demselben Datensatz verlangte, einen Zeitversatz durch einen kompletten Streaming-Pfad zu leiten: Cache-Schlüssel, zwei Endpunkte und die Templates. Das Team änderte eine einzige Datei, während zwei weitere relevante Pakete nicht kompilierten – und erhielt trotzdem volle Punktzahl, weil der Bewerter nur das FFmpeg-Paket ausführte. Die Aufgabe beschrieb eine systemweite Änderung, die Note maß einen Befehlsstring.
Bei OpenThoughts las der Bewerter sein Wörterbuch aus demselben Arbeitsbereich, den der Löser bearbeiten konnte. Dieselbe erfundene Antwort erhielt null Punkte mit dem Original-Wörterbuch und volle Punktzahl, nachdem das Wörterbuch ersetzt worden war. An der Antwort hatte sich nichts verbessert, nur an dem, was der Bewerter für wahr hielt.
Im Datensatz Apex Agents von Mercor erwartete ein Teil der Bewertungskonfiguration ein Sponsoren-Eigenkapital von 28.137 Dollar und eine IRR von 20,4 Prozent. Ein anderer Teil akzeptierte nur 28.517 Dollar und 20,8 Prozent. Eine Antwort konnte einer veröffentlichten Erwartung folgen und an der anderen scheitern. Das ist keine schwere Aufgabe, sondern eine Aufgabe mit zwei Definitionen von richtig.
Bei Terminal-Bench 2.1 schließlich führte das Team die Lösung des Autors fünfmal aus, dreimal gegen die vom Hub ausgelieferte Version. Sie erhielt jedes Mal null Punkte, weil sich die externen Proteindaten geändert hatten. Die Tests erwarteten weiterhin die ältere Darstellung, sodass keine gültige Sequenz Daten und Bewerter gleichzeitig erfüllen konnte. Eine Aufgabe, deren akzeptierte Antwort nicht mehr existiert, ist nicht lösbar.
Ein Shortcut, den niemand nutzt, ist trotzdem ein Defekt
Manche Modelle erledigen eine kontaminierte Aufgabe vielleicht, ohne je in die Git-Historie zu schauen. Sicher ist das Paket deshalb nicht. Sobald die Antwort erreichbar ist, kann dieselbe Punktzahl zwei völlig verschiedene Dinge bedeuten: Ein Modell versteht den Code und repariert ihn, ein anderes inspiziert die Umgebung, findet den versteckten Commit und kopiert den Patch. Der Bewerter kann beide nicht auseinanderhalten.
Mit leistungsfähigeren Agenten wird dieser Punkt wichtiger. Gute Modelle erkunden ihre Umgebung, lesen Repository-Historie, prüfen Build-Artefakte und suchen den kürzesten verlässlichen Weg zum Ergebnis. Eine Abkürzung zu finden ist in echter Arbeit oft nützlich. Zum Problem wird es erst, wenn der Benchmark behauptet, die erzielte Punktzahl messe eine andere Fähigkeit.
Ein Benchmark sollte die Modelle überleben, für die er gebaut wurde. Man sollte nicht darauf hoffen müssen, dass ein Modell die Antwort übersieht. Wer fehlerhafte KI-Benchmarks erkennen will, muss deshalb nicht nur nach falschen Ergebnissen suchen, sondern nach erreichbaren Antworten und zu großzügigen Bewertern.
Harbor ist ein Format, kein Qualitätssiegel
Harbor macht solche Audits möglich. Die Plattform gibt Aufgaben eine gemeinsame Struktur: Anweisungen, Umgebungen, Lösungen und Bewerter lassen sich so verpacken, dass sie lauffähig sind und sich über Anbieter hinweg vergleichen lassen. Ohne dieses Format wäre ein Benchmark-Audit für KI-Modelle in dieser Breite kaum machbar.
Harbor entscheidet aber nicht, ob eine Anweisung vollständig ist. Das Format weiß nicht, ob die Antwort in der Git-Historie liegt. Es beweist nicht, dass der Bewerter prüft, was die Aufgabe verlangt. Harbor vereinheitlicht das Paket; der Audit sagt, ob der Inhalt Vertrauen verdient. Format und Benchmark-Qualität sind zwei verschiedene Dinge.
Für den geplanten Index will Horizon mehrere Dinge zusammen zeigen: die abgeschlossenen Urteile, also wie viele geprüfte Aufgaben sauber oder fehlerhaft waren, die Schwere der Defekte, die Breite der Fehlertypen, die Stärke der Belege und die Verlässlichkeit der Prüfung. Eine Gesamtnote bildet Horizon daraus bewusst nicht: Schwere, Fehlerbreite und Belegstärke stehen nebeneinander, statt in einer undurchsichtigen Punktzahl zu verschwinden.
Der Index startet mit Bewertungen auf Datensatzebene. Anbieter-Rankings entstehen erst, wenn die Abdeckung einen Vergleich erlaubt. Ein Anbieter, der eine Aufgabe repariert, soll dafür Anerkennung bekommen, und ein Datensatz, der sich ändert, behält nicht die Bewertung einer älteren Version. Einmal gefundene Fehler dauerhaft als Urteil zu konservieren wäre unfair.
Was heißt das für den Alltag mit LLM-Benchmarks? Eine Rangliste ist nur so viel wert wie die Aufgaben, auf denen sie beruht. Wer Modellvergleiche liest, sollte genauer hinschauen: Wurden die Bewerter ausgeführt, besteht die Referenzlösung zuverlässig, und pflegt der Anbieter seine Datensätze, wenn sich Abhängigkeiten ändern? Solange diese Fragen offen bleiben, ist jede Platzierung eine Momentaufnahme mit unbekannter Fehlertoleranz. Der Audit liefert dafür eine erste Grundlage.
Quelle: horizonanalyticslabs.com
