- SWE-bench Verified, lange Zeit die führende Kennzahl für autonome Software-Engineering-Aufgaben, ist deutlich weniger geeignet, um die Fähigkeiten von Frontier-Modellen zu messen
- Während der jüngste Leistungszuwachs nur noch von 74,9 % auf 80,9 % reichte, wurde es schwierig zu unterscheiden, ob verbleibende Fehlschläge auf Modellgrenzen oder auf Mängel des Datensatzes zurückgehen
- Bei einer Prüfung von 138 Problemen wurden bei 59,4 % gravierende Mängel in Testdesign oder Problembeschreibung festgestellt; sowohl zu restriktive als auch zu breit angelegte Tests lassen funktional korrekte Lösungen durchfallen
- Da die Bewertung auf öffentlichen Daten und Codebasen beruht, ließ sich Kontamination der Trainingsdaten kaum vermeiden; einige Modelle reproduzierten allein anhand von Aufgabenbeschreibung oder ID den Gold-Patch nahezu wortgleich
- Daher wurde die Berichterstattung von SWE-bench-Verified-Scores eingestellt, und der Fokus der Evaluation verlagert sich auf das weniger kontaminierte SWE-bench Pro sowie auf nicht öffentliche Benchmarks
Warum der Benchmark nicht mehr misst
- SWE-bench Verified wurde weithin als Standardmetrik zur Messung der Modellleistung bei autonomen Software-Engineering-Aufgaben genutzt, ist aber für die Fähigkeiten heutiger Frontier-Modelle deutlich weniger geeignet
- Da sich die Spitzenergebnisse in den letzten 6 Monaten nur von 74,9 % auf 80,9 % verbessert haben, wurde es schwierig zu unterscheiden, ob verbleibende Fehlschläge auf Modellgrenzen oder auf Mängel des Datensatzes zurückgehen
- Eine neue Analyse zeigt, dass fehlerhafte Tests und Kontamination der Trainingsdaten die zentralen Probleme sind und Scores inzwischen stärker den Grad der Benchmark-Exposition als die tatsächliche Coding-Fähigkeit widerspiegeln
- Deshalb hat OpenAI die Berichterstattung von SWE-bench-Verified-Scores eingestellt und empfiehlt anderen Modellentwicklern dieselbe Maßnahme
- Als Alternative wird die Nutzung von SWE-bench Pro empfohlen, das weniger kontaminiert ist; außerdem werden neue, nicht kontaminierte Evaluationsmetriken aufgebaut
Hintergrund
- Das ursprüngliche SWE-bench wurde 2023 veröffentlicht und besteht aus Paaren gelöster GitHub-Issues und zugehöriger PRs aus 12 Open-Source-Python-Repositories
- Für jede Aufgabe muss auf Basis der Codebasis vor dem Fix und des Issue-Texts eine Codeänderung erzeugt werden; bestanden ist nur, wenn nach Anwendung alle Tests erfolgreich sind
- Enthalten sind Tests, die vor dem Fix fehlschlagen und nach der korrekten Änderung bestehen müssen
- Ebenfalls enthalten sind Regressionstests, die prüfen, ob bestehende Funktionalität nicht beschädigt wurde
- Die ursprüngliche Evaluation hatte Probleme wie übermäßig spezifische Tests, die selbst korrekte Fixes ablehnen, unzureichende Spezifikationen mit mehreren möglichen Interpretationen und Tests, die je nach Umgebung fehlschlagen
- Um diese Probleme zu reduzieren, wurde 2024 SWE-bench Verified erstellt; aus 1.699 Aufgaben wurde per Expertenprüfung ein Satz von 500 Aufgaben zusammengestellt
- Jede Aufgabe wurde unabhängig von 3 Experten geprüft
Mängel im Testdesign
- Gegenstand des Audits waren 138 Aufgaben, die OpenAI o3 auch nach 64 unabhängigen Ausführungen nicht konsistent lösen konnte; jeder Fall wurde unabhängig von mindestens 6 erfahrenen Softwareingenieuren geprüft
- Das Ergebnis: Bei 59,4 % der 138 Aufgaben gab es gravierende Mängel in Testdesign oder Problembeschreibung, sodass sie selbst für sehr gute Modelle oder Menschen sehr schwer oder unmöglich zu lösen waren
- 35,5 % der geprüften Aufgaben enthielten restriktive Tests, die bestimmte Implementierungsdetails erzwingen
- Dadurch können mehrere funktional korrekte Lösungen als ungültig gewertet werden
- 18,8 % der geprüften Aufgaben enthielten breit angelegte Tests, die zusätzliche Funktionalität verlangen, die in der Problembeschreibung nicht vorkommt
- Die restlichen 5,1 % wiesen andere Probleme auf, die nicht klar in diese beiden Kategorien fallen
-
Restriktive Testfälle
- In pylint-dev__pylint-4551 importieren die PR-Tests die Funktion
get_annotationdirekt, doch dieser Funktionsname wird in der Problemspezifikation nicht erwähnt - Deshalb kann eine funktional korrekte Lösung dennoch an einem Importfehler scheitern, wenn sie nicht genau diesen Funktionsnamen implementiert
- In pylint-dev__pylint-4551 importieren die PR-Tests die Funktion
-
Breit angelegte Testfälle
- sympy__sympy-18199 stammt tatsächlich aus einer PR, die drei Issues zugleich behob: #17373, #17377 und #18212
- Die Aufgabenbeschreibung in SWE-bench Verified behandelt jedoch nur #18212; selbst eine Umsetzung exakt nach Beschreibung kann daher an Tests scheitern, die die beiden anderen Issues prüfen
Kontaminationsproblem
- SWE-bench Verified, die zugehörigen Repository-Codebasen und Release Notes sind alle öffentlich verfügbar, weit verbreitet und viel diskutiert, sodass Datenkontamination schwer zu vermeiden ist
- OpenAI stellte auch bei eigenen Modellen Anzeichen von Kontamination fest, darunter Fälle, in denen GPT‑5.2 31 Aufgaben löste, die man für nahezu unlösbar hielt
- In django__django-14725 verlangen die Tests den in der Problemspezifikation nicht erwähnten Parameter
edit_only; GPT‑5.2 benannte in seinem Reasoning sogar korrekt, dass dieser Parameter in Django 4.1 eingeführt wurde - Um den Schweregrad der Kontamination zu bewerten, richtete OpenAI eine automatisierte Red-Team-Testumgebung ein
- Für jede SWE-bench-Verified-Aufgabe untersuchte GPT‑5, ob bei GPT‑5.2‑Chat, Claude Opus 4.5 und Gemini 3 Flash Preview Kontamination vorliegt
- GPT‑5 erhielt Aufgaben-ID, Beschreibung, Gold-Patch und PR-Tests und durfte über insgesamt 15 Züge Prompts und Lenkungsstrategien variieren
- Nach jedem Zug klassifizierte ein Bewertungsmodell den Schweregrad der Kontamination anhand der Menge neu offengelegter aufgabenspezifischer Informationen von keine bis stark
- Fälle mit starker Kontamination wurden mit einem zusätzlichen Bewertungsmodell auf übermäßigen Informationsabfluss geprüft und abschließend manuell begutachtet
Schwere Kontaminationsfälle nach Modell
-
GPT‑5.2
- Bei django__django-11451 gab das Modell bereits anhand eines kurzen Ausschnitts der Aufgabenbeschreibung den exakten Gold-Patch aus
- Es reproduzierte die Bedingung für eine frühe Rückgabe in
ModelBackend.authenticate()beiusername is None or password is None, einschließlich Dateipfad und Methodenname
-
Claude Opus 4.5
- Bei astropy__astropy-13236 zitierte das Modell den Ziel-Dateipfad
astropy/table/table.py, die Methode_convert_data_to_colund sogar Inline-Kommentare aus dem Diff wortwörtlich - Auch die vier Codezeilen, die strukturierte ndarrays automatisch in
NdarrayMixinumwandeln, wurden exakt rekonstruiert
- Bei astropy__astropy-13236 zitierte das Modell den Ziel-Dateipfad
-
Gemini 3 Flash
- Bei django__django-11099 gab das Modell selbst bei fast vollständigem Fehlen zusätzlicher Informationen außer der Aufgaben-ID die Aufgabenbeschreibung und den gesamten Gold-Patch wortgetreu aus
- Es reproduzierte sowohl die Änderung des Regex zur Benutzernamenvalidierung von
r'^[\\w.@+-]+$'aufr'^[\\w.@+-]+\\Z'als auch das zeilenweise Diff
Zentrale Lehren
- Benchmarks, die aus öffentlich verfügbaren Materialien extrahiert werden, tragen ein Kontaminationsrisiko; Exposition gegenüber Trainingsdaten kann Scores unauffällig aufblähen
- Wenn Benchmarks aus öffentlich gecrawlten Daten erstellt werden, sollten Modellentwickler zusätzliche Tests durchführen, um Kontamination zu prüfen
- Auch veröffentlichte Benchmarks und Lösungen können letztlich in Trainingsdaten landen, daher ist sowohl bei der Bereitstellung von Datensätzen als auch bei der Filterung von Trainingsdaten besondere Sorgfalt nötig
- Erwähnt werden Bereitstellungskontrollen wie Passwortschutz
- Ebenso genannt werden Filtermethoden wie die strikte Einhaltung von Canary-Strings
- Automatische Bewertung muss robust genug sein, um unbedeutende Implementierungsunterschiede zu tolerieren und zugleich Tricksereien zu verhindern; beides gleichzeitig zu erfüllen ist sehr schwierig
- Um solche Mängel aufzudecken, waren mehrere Runden umfangreicher manueller Labeling-Arbeit nötig
Die künftige Richtung der Evaluation
- In den vergangenen Monaten hat OpenAI damit begonnen, Ergebnisse auf den öffentlichen Evaluationsdaten von SWE-bench Pro zu berichten, und empfiehlt anderen Modellentwicklern dasselbe Vorgehen
- SWE-bench Pro ist ebenfalls nicht perfekt, scheint empirisch aber weniger von Kontamination betroffen zu sein als SWE-bench Verified
- In der internen Pipeline zur Kontaminationsprüfung wurden einige Kontaminationsfälle gefunden
- Diese waren jedoch deutlich seltener und weniger gravierend als bei SWE-bench Verified
- Kein Modell konnte einen Gold-Patch erzeugen, der wortwörtlich vollständig übereinstimmte
- Künftig will man weiter in originelle und nicht öffentlich verfasste Benchmarks investieren
- Bei GDPVal erstellen Domain-Experten die Aufgaben nicht öffentlich, und geschulte Evaluatoren bewerten Lösungen ganzheitlich
- Dieser Ansatz ist ressourcenintensiv, wird aber zunehmend unverzichtbar, wenn tatsächliche Fähigkeitsverbesserungen gemessen werden sollen
1 Kommentare
Hacker-News-Kommentare
Als Mitautor von SWE-bench würde ich es so zusammenfassen: SWE-bench Verified ist mit inzwischen 93,9 % praktisch gesättigt, und Anthropic kann man dazu gratulieren.
Für Teams, die diesen Wert noch nicht erreicht haben, gibt es aber weiterhin Spielraum nach oben.
SWE-bench Multilingual und SWE-bench Multimodal sind noch nicht gesättigt, und Multimodal soll innerhalb des nächsten Monats als Open Source veröffentlicht werden.
Benchmarks sättigen sich am Ende immer, deshalb bauen wir fortlaufend Benchmarks der nächsten Stufe, und mit https://codeclash.ai/ oder https://algotune.io/ gibt es bereits entsprechende Beispiele.
Der Kernpunkt ist, dass ein erheblicher Teil der Tests ungenau ist, sodass tatsächlich richtige Lösungen als falsch bewertet werden.
Außerdem ist es sehr wahrscheinlich, dass Frontier-Modelle die PRs, auf denen die Probleme basieren, bereits gelesen und auswendig gelernt haben.
Manche Aufgaben sind sogar praktisch unmöglich zu lösen, wenn man die Lösung nicht auswendig kennt, etwa wenn man zum Bestehen der Tests exakt den Namen einer bestimmten Helper-Funktion ausgeben muss, obwohl dieser im Problem gar nicht vorkommt.
Dass Frontier-Modelle so etwas bestehen, scheint daran zu liegen, dass sie sich gemerkt haben, dass genau dieser Name nötig ist.
Wenn die nächste Benchmark-Generation das nicht behebt, bleibt dasselbe Problem unabhängig vom Sättigungsgrad bestehen.
Rechnerisch gilt 0,191 * 0,594 > 1 - 0,936, deshalb frage ich mich, ob die auditierte Teilmenge nicht repräsentativ war oder ob Anthropic seinen hohen Score auf etwas fragwürdige Weise erreicht hat.
Benchmark erstellen, Sättigung erreichen, ausmustern, ersetzen, wiederholen.
Am Ende wirkt dieses ganze Tretmühlenmuster selbst wie ein Produkt; ich kenne die Lösung nicht, aber es fühlt sich wie eine Wiederholung der Geschichte an.
Soweit ich es verstehe, wirkt es wie eine interessante Abwandlung von SWE-bench.
Dass es gerade so hart überprüft wird, scheint eher die Gegenreaktion darauf zu sein, dass es so breit übernommen wurde und erfolgreich ist.
Bei jedem neuen Benchmark ist eigentlich nur allzu klar, dass er schnell in die Trainingsdaten wandert und bald veraltet.
Es gibt immer einen Anreiz, auf einen bestimmten Benchmark hin zu optimieren, selbst wenn es nur fürs Marketing ist, und selbst mit einem Trainings-Cutoff liegt der Abstand zum Veröffentlichungszeitpunkt meist nur bei 3 bis 6 Monaten.
Die eigentliche Schwierigkeit bei Coding-Benchmarks besteht deshalb darin, völlig neue Probleme zu erstellen, die keine bestehenden Benchmarks recyceln und garantiert nie in den Trainingsdaten waren.
Aus dieser Sicht ist ein Benchmark, der vor dem Release eines Modells erstellt wurde, kaum repräsentativ für dessen Leistung, und der finanzielle Anreiz, Daten einzuschleusen, um kleine Verbesserungen zu vermarkten, ist viel zu groß.
Ehrlich gesagt sollte man Benchmarks aus Marketingmaterialien ganz weglassen, das Modell für sich sprechen lassen und die Community urteilen lassen, aber Unternehmen, für die Geld auf dem Spiel steht, werden das wohl nie tun.
Das Text-Adventure-Spiel Zork ist in den Trainingsdaten von LLMs enthalten und deterministisch, also sollte ein Modell es eigentlich leicht spielen und abschließen können.
In der Praxis ist das aber nicht so, und genau warum das so ist, ist das Ziel der Zork bench.
https://github.com/mnky9800n/zork-bench
Da ist alles dabei, von Experten, die seit über 10 Jahren mit LLMs arbeiten, bis zu Vibe Codern, die noch nie Code geschrieben haben, und online gibt es Leute, die GPT 5.5 wie einen Erlöser sehen, während andere es für dümmer als 5.4 halten.
Ich habe auch nicht die Zeit, für jedes neue Modell eigene private Benchmarks zu bauen, also verlasse ich mich am Ende auf private oder halbprivate Benchmarks, um einzuschätzen, wie groß die Verbesserung ist, und abonniere es dann und probiere es selbst aus.
Das ist zumindest etwas vertrauenswürdiger als die Stimmung, die zufällige Reddit-Nutzer oder Bots verbreiten.
Oder man lässt Tests im selben Kontext nacheinander weiterlaufen, um zu sehen, wie lange das Modell durchhält, bevor es den Kontext verliert.
Die heutigen Benchmarks sind immer Greenfield-Probleme, tatsächlich wollen wir aber Modelle, die mit verrottetem Kontext umgehen können.
Der aktuelle Flaschenhals ist nicht die Fähigkeit an sich, sondern was ein Modell in Produktion überhaupt sehen kann.
Kontextstruktur, Retrieval-Qualität, Tool Use und die Fähigkeit, Zustände über mehrere Turns hinweg zu kombinieren, sind wichtig, und in SWE-bench kommt davon fast nichts vor.
SWE-bench sieht aus wie eine One-Shot-Aufgabensammlung, aber Frontier-Coding-Arbeit hat diese Form längst nicht mehr.
Selbst wenn man einen perfekten, vollständig kontaminationsfreien Benchmark bauen würde, würde er wahrscheinlich immer noch überwiegend die falsche Achse messen.
Bei isolierten Problemen ist bereits menschliches Graduierten-Niveau erreicht; der Hebel liegt darin, wie Modelle in größeren Systemen funktionieren.
Das ist aber fast schon eine Frage des Geschmacks oder der Präferenz und deshalb objektiv äußerst schwer zu messen.
Anthropic bezahlt Influencer dafür, Claude Code zu pushen, und scheint auch massiv Bots einzusetzen, deshalb ist Online-Konsens schwer ernst zu nehmen.
Selbst wenn alle in gutem Glauben handeln, können die Wahrnehmungen je nach Domäne stark auseinandergehen.
Zum Beispiel kann AI im Frontend oder bei weit verbreiteten Libraries deutlich besser sein.
Am Ende bleibt nur, Modelle selbst auszuprobieren, aber das für jedes neue Modell zu wiederholen ist extrem ermüdend und trotzdem nicht umfassend genug.
Benchmarks/Evals waren schon immer schwierig, und noch schwieriger werden sie, wenn der Anreiz, das Ganze im Branchenmaßstab zu gamen, enorm groß ist.
ELT-Bench ist ein jüngstes Beispiel: Es war der erste ernsthafte Benchmark für Data-Engineering-Workloads und wurde vor etwa einem Jahr veröffentlicht.
Vor ein paar Tagen auditierte jedoch ein Folgepapier, an dem einer der ursprünglichen Autoren beteiligt war, den Benchmark selbst und kam zu dem Schluss, dass die Ergebnisse wegen struktureller Probleme verzerrt waren.
Das Papier ist hier: https://arxiv.org/abs/2603.29399
Eigentlich ist so etwas auch nichts Neues; frühere Branchen haben all das in kleinerem Maßstab bereits durchlebt.
Es gibt auch einen Text darüber, wie sehr die heutige Lage den Benchmarketing-Kriegen bei Datenbanken ähnelt.
https://www.typedef.ai/blog/from-benchmarketing-to-benchmaxx...
Ein ähnliches Problem sieht man bei BrowseComp plus und anderen Deep-Research-Datensätzen; das liegt nicht unbedingt daran, dass Frontier Labs betrügen wollen, sondern entsteht ganz natürlich, wenn das gesamte Web trainiert wird.
Neue Datensätze müssen dauerhaft immer weiter erzeugt werden.
Ich habe das selbst beim Bauen eines Classifiers erlebt: Bei manchen Aufgaben ist ein Modell konsistent besser als Menschen, sodass man die Precision selbst nicht mehr messen kann.
Dann wird dieser Classifier selbst zum State-of-the-Art-Benchmark, und außer sich selbst gibt es keinen Vergleichsmaßstab mehr.
Wenn so etwas schon bei komplexen Aufgaben passiert, die weniger logisch und weniger von anhaltendem Reasoning geprägt sind als Coding, dann könnte irgendwann sogar die Möglichkeit verschwinden, kalibrierte Benchmarks zu haben, die unabhängig vom Messobjekt sind.
Im Grunde bekommen wir also meist die selbstverschuldeten Benchmarks, die wir verdienen.
Ein beträchtlicher Teil der PRs, die SWE-bench bestehen, würde in der Realität wahrscheinlich trotzdem nicht gemergt werden: https://news.ycombinator.com/item?id=47341645
Außerdem könnten die SWE-bench-Scores der Topmodelle durch Lecks in der Git-History verzerrt sein: https://news.ycombinator.com/item?id=45214670
Vielleicht sollte man stattdessen Spitzenmodelle die Benchmarks einfach selbst bauen lassen.
Spaß beiseite: Worauf ich hoffe, ist ARC-AGI-3, und als ich Menschensimulationen ausprobiert habe, wirkte der Reasoning-Anteil tatsächlich sehr hoch.
Das Leaderboard ist hier: https://arcprize.org/leaderboard
Aktuell schaffen die meisten Spitzenmodelle nicht einmal 5 %.
Selbst das aktuell beste verifizierte Modell, Claude Opus 4.6, liegt nur bei etwa 0,45 %.
Allerdings ist das alles noch sehr neu, daher erwarte ich, dass die nächste Modellgeneration hier deutlich besser abschneidet.
Man könnte ein früheres Modell ein neues Modell interviewen lassen und dann beide oder ein drittes Richtermodell entscheiden lassen, welches intelligenter ist, das Ganze mit anderen Seeds 100-mal wiederholen und dann den Anteil als Score nehmen, in dem beide Seiten den Sieg des neuen Modells anerkennen.
Die lassen sich am schwersten gamen.
Wenn man darüber nachdenkt, ist das schon etwas komisch.
Bessere Benchmarks sollten objektive Bewertung, multidisziplinäre Breite und Skalierbarkeit bieten und Formate mit nur einer einzigen richtigen Antwort vermeiden.
Was wir bei https://gertlabs.com entworfen haben, geht grob in diese Richtung und hängt überwiegend mit Problemlösung durch Coding zusammen.
Nach meinem Eindruck ist gpt 5.4/5.5 technisch fast makellos, und wenn Probleme auftreten, liegt es meist an unklaren Eingaben.
Auch bei Bugfixes oder Problemen während der Implementierung reagiert es meist selbstständig und hat eine starke Tendenz, Aufgaben lückenlos abzuschließen.
Opus halte ich dagegen in Bezug auf die technische Leistungsfähigkeit für etwas überschätzt.
Es hat zwar mehr Gespür als Designer/Entwickler für schöne UX, aber zur Verifikation von Arbeit greife ich am Ende immer zu gpt 5.5.
Am überraschendsten waren für mich die Xiao-Mi-Ergebnisse; ich habe es noch nicht benutzt, will es jetzt aber wegen dieser Resultate ausprobieren.
Glückwunsch an das Team, dass ihr in diesem chaotischen AI-Geschwindigkeitsrennen einen sinnvollen Maßstab geschaffen habt.
Das könnte auf Verzerrungen im Trainingsdatensatz oder Unterschiede im Go-to-Market-Fokus hindeuten; vielleicht ist es auch das Ergebnis davon, dass Anthropic stärker als OpenAI auf Enterprise-Kunden ausgerichtet ist.
Das passt auch zu meinem eigenen Eindruck, als ich Opus für C++ verwendet habe.
Allerdings sind die C#-Ergebnisse leer; @gertlabs, gibt es dafür schon eine ETA?
Mich würde ein Kommentar dazu interessieren, warum das so ausgefallen ist.
So oder so musste es irgendwann dazu kommen, organisch oder nicht.
Wenn am Ende nur noch zählt, gute Benchmark-Scores zu erzielen, und es egal ist, ob das nach außen generalisiert, dann ist diese Entwicklung fast unvermeidlich.
Ein ähnlicher Fall, an den das erinnert, ist auch Graduate student descent.
https://sciencedryad.wordpress.com/2014/01/25/grad-student-d...
Rückblickend war SWE-bench vielleicht von Anfang an gar nicht so überragend.
Über das ganze Jahr 2025 hinweg hat sich der Anteil an Modellen, die guten Code schreiben, faktisch kaum verbessert; plausibler wirkt die Interpretation, dass nur ihre Fähigkeit gewachsen ist, automatisierte Tests zu bestehen.
https://entropicthoughts.com/no-swe-bench-improvement
Im Januar 2025 waren Claude 3.5 Sonnet, Gemini 1.5 Pro und bei OpenAI GPT-4o die Hauptmodelle; nachdem ich diese und die heutigen Frontier-Modelle alle benutzt habe, ist für mich klar, dass die aktuellen Modelle definitiv einen großen Sprung nach vorn gemacht haben.
Die Modellqualität scheint zu stagnieren, und neue Verbesserungsvektoren zu finden ist offenbar alles andere als einfach.
Auch die Verbreiterung der Modelle, die das Verbesserungstempo bisher angetrieben hat, scheint an Grenzen zu stoßen, und ich frage mich, welche Implikationen das in Zukunft haben wird.
Langfristig gibt es auch Grenzen dafür, was sich allein durch Tooling lösen lässt.
Das ist auch einer der Gründe, warum Anthropic mit zig Milliarden Dollar bewertet wird.
Dass SWE-bench im Coding-Bereich nützlich war, liegt daran, dass es in der Softwaretechnik eine sehr starke Tradition und Infrastruktur gibt, automatisierte Tests zu erstellen und zu nutzen.
Ich verstehe den Artikel so, dass man die 27,6-%-Teilmenge, die Modelle oft nicht lösen konnten, auditiert hat und dabei feststellte, dass in mindestens 59,4 % davon fehlerhafte Tests enthalten waren, die auch funktional korrekte Einreichungen zurückweisen.
Wenn das stimmt, wirkt es so, als wären große Teile von Aufgaben und Lösungen die ganze Zeit über falsch gewesen, und dann stellt sich natürlich die Frage, wie das überhaupt ein valides Maß sein konnte.
Die Beschreibung des Benchmark-Erstellungsprozesses lässt die Qualitätslatte eigentlich recht hoch erscheinen; deshalb verstehe ich auch nicht, wie ein derart schwaches Datenniveau zusammen mit solchen Verfahren herauskommen konnte.
Es ist lobenswert, dass das Problem offengelegt wurde, aber viele Fragen bleiben offen.
Und aus praktischen Gründen kann ein Benchmark im Kern weder deinen konkreten Use Case noch alle Use Cases repräsentieren.
Er ist nur dafür gültig, die Elemente zu messen, die tatsächlich darin enthalten sind, und nicht mehr und nicht weniger.
Genau deshalb verstehe ich nicht, warum das Ökosystem an öffentlichen Benchmarks so festhängt.
Nur weil Qwen 3.5 bei Benchmark X 50 % besser abschneidet als Qwen 2.5, heißt das fast nie, dass es bei meinen tatsächlichen Aufgaben 50 % besser ist.
Ich habe laufend private Benchmarks erstellt, basierend auf Fällen, in denen Modelle bei meiner realen Nutzung versagt haben, und dabei die Prompts angepasst.
Selbst wenn ein neues Modell-Update erscheint, bewegen sich die Ergebnisse in meinen Benchmarks meist nur um 2 bis 3 %, während in öffentlichen Benchmarks Zuwächse von 30 bis 40 % beworben werden; da fällt es schwer zu glauben, dass keine Kontamination der Trainingsdaten vorliegt.
Im Extremfall kann es sogar Bereiche geben, in denen man einen höheren Score erzielt, wenn man sich an der falschen Antwort orientiert.
Die Antwort ist letztlich, dass ML ein Gebiet ist, das auf die eine oder andere Weise versucht zu funktionieren, und deshalb trotz Defekten erstaunlich weit kommt.
Gleichzeitig erklärt das auch, warum man große Durchbrüche erzielen kann, wenn man Fehler erkennt, die andere übersehen haben.
Solange die meisten Aufgaben korrekt bewertet werden, kann die Richtung erhalten bleiben.
Selbst ein miserabler Benchmark mit 49 % falschen Labels könnte also die Rangfolge noch korrekt wiedergeben, wenn ein Modell immer die richtige Antwort gibt und 51 % erreicht, während ein Modell, das immer falsch liegt, 49 % bekommt.
Viele Machine-Learning-Benchmarks enthalten nicht wenige Fehl-Labels, aber wenn das Ziel die Unterscheidung zwischen Modellen ist, lohnt es sich meist mehr, einen größeren Datensatz zu sammeln, als den Aufwand für perfekt garantiertes Scoring zu treiben.