Warum SWE-bench Verified keine Frontier-Coding-Fähigkeiten mehr misst

Seit der Erstveröffentlichung von SWE-bench Verified im August 2024 wird es in der Branche häufig zur Messung des Fortschritts von Modellen bei autonomen Softwareentwicklungsaufgaben eingesetzt. Nach seiner Veröffentlichung lieferte SWE-bench Verified ein starkes Signal für Fortschritte bei den Fähigkeiten und wurde zu einer Standardkennzahl, die bei der Veröffentlichung von Frontier-Modellen angegeben wird. Die Verfolgung und Prognose der Fortschritte dieser Fähigkeiten ist auch ein wichtiger Bestandteil von OpenAIs Preparedness Framework. Als wir den Verified-Benchmark ursprünglich erstellten, versuchten wir, Probleme in der ursprünglichen Evaluation zu lösen, die die Bewältigung bestimmter Aufgaben im SWE-bench-Datensatz⁠(wird in einem neuen Fenster geöffnet) unmöglich machten.

Nach anfänglichen Sprüngen hat sich der modernste Fortschritt bei SWE-bench Verified verlangsamt und sich in den letzten 6 Monaten von 74,9 % auf 80,9 % verbessert⁠(wird in einem neuen Fenster geöffnet). Dies wirft die Frage auf: Spiegeln die verbleibenden Fehlschläge Modellbeschränkungen oder Eigenschaften des Datensatzes selbst wider?

In einer neuen Analyse haben wir zwei wesentliche Probleme mit dem Verified-Set festgestellt, die darauf hindeuten, dass der Benchmark bei den heutigen Leistungsniveaus nicht mehr geeignet ist, um Fortschritte bei autonomen Softwareentwicklungsfähigkeiten für Frontier-Launches zu messen:

1. Tests lehnen korrekte Lösungen ab: Wir prüften eine 27,6%ige Teilmenge des Datensatzes, die Modelle oft nicht lösen konnten, und stellten fest, dass mindestens 59,4 % der geprüften Aufgaben fehlerhafte Testfälle aufweisen, die funktional korrekte Einreichungen ablehnen, trotz unserer besten Bemühungen, dies bei der initialen Erstellung von SWE-bench Verified zu verbessern.
2. Training mit Lösungen: Da große Frontier-Modelle Informationen aus ihrem Training lernen können, ist es wichtig, dass sie niemals mit Problemen und Lösungen trainiert werden, anhand derer sie bewertet werden. Das ist vergleichbar damit, Schüler:innen vor der Prüfung die Aufgaben und Lösungen für eine anstehende Prüfung zu zeigen – sie lernen die Antwort vielleicht nicht auswendig, aber Schüler:innen, die die Antworten schon einmal gesehen haben, werden sicherlich besser abschneiden als diejenigen, bei denen dies nicht der Fall ist. SWE-bench-Probleme stammen aus Open-Source-Repositorys, die viele Modellanbieter zu Trainingszwecken verwenden. In unserer Analyse haben wir festgestellt, dass alle Frontier-Modelle, die wir getestet haben, in der Lage waren, den ursprünglichen, von Menschen geschriebenen Bugfix, der als Ground-Truth-Referenz diente und als Gold Patch bekannt ist, oder bei bestimmten Aufgaben die wörtlichen Details der Problemstellung zu reproduzieren, was darauf hindeutet, dass sie alle während des Trainings zumindest einige der Probleme und Lösungen gesehen haben.

Wir fanden außerdem Hinweise darauf, dass Modelle, die die Probleme während des Trainings gesehen haben, mit höherer Wahrscheinlichkeit erfolgreich sind, weil sie über zusätzliche Informationen verfügen, die erforderlich sind, um die unzureichend spezifizierten Tests zu bestehen.

Das bedeutet, dass Verbesserungen bei SWE-bench Verified keine aussagekräftigen Verbesserungen der realen Softwareentwicklungsfähigkeiten der Modelle mehr widerspiegeln. Stattdessen spiegeln sie zunehmend wider, wie stark das Modell während des Trainings dem Benchmark ausgesetzt war. Aus diesem Grund haben wir die Berichterstattung über SWE-bench Verified-Ergebnisse eingestellt und empfehlen anderen Modellentwickler:innen, dies ebenfalls zu tun.

Wir entwickeln neue, unverfälschte Evaluierungen, um Coding-Fähigkeiten besser nachzuverfolgen. Wir glauben, dass dies ein wichtiger Bereich ist, auf den sich die breitere Forschungsgemeinschaft konzentrieren sollte. Bis wir diese haben, empfiehlt OpenAI, Ergebnisse für SWE-bench Pro zu melden.

Die ursprüngliche SWE-bench⁠(wird in einem neuen Fenster geöffnet)-Evaluierung wurde 2023 veröffentlicht. Jedes Problem stammt aus einem gelösten GitHub-Issue in einem von 12 Open-Source-Python-Repositorys und ist mit dem entsprechenden pull request (PR) gepaart. Um festzustellen, ob eine vom Modell generierte Codeänderung korrekt ist, enthält jedes Problem zwei Testsätze:

• Tests, die auf der unveränderten Codebasis fehlschlagen, aber erfolgreich sind, wenn das Problem korrekt behoben wird
• Regressionstests, die sowohl vor als auch nach der Behebung erfolgreich durchlaufen werden, um sicherzustellen, dass nicht verwandte Funktionalität intakt bleibt.

Das Modell sieht die Tests nicht. Es muss eine Codeänderung erzeugt werden, basierend nur auf dem ursprünglichen Problemtext und dem Zustand des Repository vor der Korrektur. Es besteht ein Problem nur dann, wenn alle Tests erfolgreich sind, nachdem die Codeänderung angewendet wurde.

Wir haben bei dieser Bewertung zahlreiche Probleme festgestellt, die zu einer Unterbewertung der Leistungsfähigkeit der Modelle führen könnten.

• Einige Unit-Tests waren zu spezifisch oder nicht auf die Aufgabe abgestimmt, sodass korrekte Fehlerbehebungen abgelehnt werden konnten.
• Viele Aufgabenstellungen waren unzureichend spezifiziert, was zu mehreren gültigen Interpretationen führen könnte – während die Tests nur eine bestimmte Interpretation abdeckten.
• Je nach Einrichtung der Umgebung (z. B. Linux vs. Windows oder der Python-Version) können einige Tests fälschlicherweise fehlschlagen

Wir haben SWE-bench Verified im Jahr 2024 erstellt, um diese Issues zu beheben. Wir haben mit erfahrenen Softwareentwickler:innen zusammengearbeitet, um 1.699 SWE-bench-Probleme zu überprüfen und Probleme herauszufiltern, die diese Issues aufwiesen. Jedes Problem wurde von drei Expert:innen unabhängig überprüft. Dieser Überprüfungsprozess führte zu SWE-bench Verified, einer kuratierten Sammlung von 500 Problemen.

Obwohl SWE-bench Verified eine große Verbesserung gegenüber der ursprünglichen Version ist, bleiben Restprobleme bestehen. Wir führten ein Audit von 138 SWE-bench Verified-Problemen durch, die OpenAI o3 über 64 unabhängige Durchläufe hinweg nicht konsistent löste. Jeder Fall wurde unabhängig von mindestens sechs erfahrenen Softwareentwickler:innen überprüft. Wenn ein:e Expert:in ein Problem meldete, wurde es von einem zusätzlichen Team erneut verifiziert.

Wir stellten fest, dass 59,4 % der 138 Probleme wesentliche Mängel im Testdesign und/oder in der Problembeschreibung aufwiesen, wodurch sie selbst für das leistungsfähigste Modell oder den leistungsfähigsten Menschen extrem schwierig oder unmöglich zu lösen waren. 

• 35,5 % der geprüften Aufgaben haben strenge Testfälle, die bestimmte Implementierungsdetails erzwingen und dadurch viele funktional korrekte Einreichungen ungültig machen; wir nennen sie enge Testfälle.
• Bei 18,8 % der geprüften Aufgaben gibt es Tests, die zusätzliche Funktionalitäten prüfen, die in der Problembeschreibung nicht spezifiziert waren. Wir nennen dies breite Testfälle.
• Bei den verbleibenden 5,1 % der Aufgaben handelte es sich um verschiedene Probleme, die sich nicht gut in diese Taxonomie einordnen ließen.

Ein anschauliches Beispiel für den ersten Fehlermodus ist pylint-dev__pylint-4551⁠(wird in einem neuen Fenster geöffnet), bei dem der PR im Rahmen der Gesamtlösung eine neue Funktion „get_annotation“ einführt. Dieser Funktionsname wird in der Problembeschreibung nicht erwähnt, wird aber direkt von den Tests importiert. Während einige Modelle möglicherweise intuitiv eine solche Funktion erstellen würden, ist es nicht unbedingt erforderlich, eine Funktion mit diesem spezifischen Namen zu implementieren, um das Problem korrekt zu lösen. Viele gültige Lösungen scheitern aufgrund von Importfehlern bei den Tests.

Ein Beispiel für zu breite Testfälle ist sympy__sympy-18199⁠(wird in einem neuen Fenster geöffnet). Diese Aufgabe stammt aus einem PR, der drei unterschiedliche Probleme mit der Funktion „nthroot_mod“ behoben hat, nämlich #17373⁠(wird in einem neuen Fenster geöffnet), #17377⁠(wird in einem neuen Fenster geöffnet) und #18212⁠(wird in einem neuen Fenster geöffnet). Die Beschreibung für die SWE-bench Verified-Aufgabe deckt jedoch nur das letzte Problem #18212⁠(wird in einem neuen Fenster geöffnet) ab. Dadurch entsteht eine Diskrepanz: Die PR-Tests decken alle drei Probleme ab, während die Beschreibung nur eines im Detail beschreibt. In unseren Durchläufen implementieren Modelle oft korrekt die beschriebene Lösung und scheitern dann an Tests, die die Implementierung für die anderen beiden Probleme abdecken.

SWE-bench Verified und die Repositorys (Codebasen und Versionshinweise) sind beide Open Source und werden breit genutzt und diskutiert, was es für Modellentwickler:innen schwierig macht, Kontamination zu vermeiden.

Wir stießen erstmals in unseren eigenen Modellen auf Anzeichen von Kontamination. Zum Beispiel, als GPT‑5.2 31 Aufgaben löste, die wir als nahezu unmöglich zu lösen identifiziert hatten. In django__django-14725⁠(wird in einem neuen Fenster geöffnet) erfordern die Tests einen bestimmten neuen Parameter „edit_only“, der in der Problembeschreibung nicht ausdrücklich gefordert wird. Während der Lösung des Problems zeigt GPT‑5.2 in seiner Gedankenkette, dass es Informationen über die Versionshinweise hat, die Änderungen an der Codebasis detailliert beschreiben, und identifiziert korrekt, dass der Parameter „edit_only“ in Django 4.1 eingeführt wurde.

Um das Ausmaß der Kontamination umfassender zu beurteilen, haben wir ein automatisiertes Red-Teaming-Setup erstellt. Für jede SWE-bench Verified-Frage beauftragten wir GPT‑5 damit, einen GPT‑5.2‑Chat, Claude Opus 4.5 und Gemini 3 Flash Preview auf Kontamination zu untersuchen. Diese Modelle wurden ausgewählt, um Reasoning-Modelle auszuschließen, aber wir erkennen an, dass es wahrscheinlich eine nicht unerhebliche Fähigkeitslücke zwischen ihnen gibt.

Zur Prüfung auf Kontamination erhielt GPT‑5: die ID, die Beschreibung, den Gold-Patch und die PR-Tests der SWE-bench Verified-Aufgabe. In über 15 Durchgängen erlaubten wir GPT‑5, den System-/Entwickler-Prompt, den Benutzer-Prompt und das Assistenten-Prefill sowie verschiedene Erhebungsstrategien zu variieren. Nach jeder Runde kennzeichnete ein Bewerter-Modell, wie viele neue aufgabenspezifische Informationen erschienen, und jede Antwort wurde hinsichtlich der Kontaminationsschwere von „keine“ bis „stark“ gekennzeichnet. GPT‑5 durfte seine Strategie basierend auf vorherigen Durchgängen anpassen, um iterativ aufgabenspezifische Details wiederherzustellen. Bei jedem Beispiel starker Kontamination haben wir mit einem weiteren Bewerter verifiziert, dass GPT‑5 nicht zu viele Informationen an das Zielmodell weitergegeben hat. Schließlich haben wir dann die „starken“ Beispiele, aus denen die Transkripte in diesem Beitrag bestehen, manuell überprüft.

Im Folgenden sind Beispiele für starke Kontamination bei verschiedenen Modellanbietern aufgeführt.

GPT‑5.2 gibt anhand eines kurzen Snippets aus der Aufgabenbeschreibung den exakten Gold-Patch aus. Insbesondere kennt es den exakten Klassen- und Methodennamen sowie die neu eingeführte frühe Rückgabebedingung `if username is None or password is None`.

Aufgaben-ID: django__django-11451⁠(wird in einem neuen Fenster geöffnet)

Opus kann nicht nur die genaue 4-zeilige Funktionsänderung, die der PR eingeführt hat, zusammen mit dem spezifischen Dateinamen und der Methode, die betroffen war, wiedergeben, sondern zitiert auch wörtlich den Inline-Kommentar, der Teil des Diffs war. 

Aufgaben-ID: astropy__astropy-13236⁠(wird in einem neuen Fenster geöffnet)

Gemini 3 Flash kann, wenn keine weiteren Informationen zur Aufgabe außer der ID angegeben werden, wörtliche Details aus der Aufgabenbeschreibung und dem Gold-Patch ausgeben. Dies beinhaltet die neue Regex-Formel zur Validierung des Benutzernamens und die genauen Zeilennummern für die Änderung.

Aufgaben-ID: django__django-11099⁠(wird in einem neuen Fenster geöffnet)

Aus dieser Prüfung von SWE-bench Verified ziehen wir zwei übergeordnete Lehren für das Design von Evaluierungen. Erstens bergen Benchmarks aus öffentlich verfügbarem Material ein Kontaminationsrisiko, da die Exposition gegenüber Trainingsdaten die Ergebnisse unbemerkt nach oben verzerren kann. Wenn öffentlich gecrawlte Daten bei der Erstellung von Benchmarks verwendet werden, sollten Modellentwickler:innen zusätzliche Tests auf Kontamination durchführen. Benchmarks und sogar ihre Lösungen, die öffentlich gepostet werden, können in Trainingsdaten landen. Besondere Sorgfalt sollte sowohl bei der Art und Weise der Veröffentlichung von Datensätzen (d. h. Passwortschutz) als auch beim Filtern der (d. h. strikte Einhaltung von Canary-Strings) angewendet werden. 

Zweitens ist korrekte Umsetzung automatisierter Bewertung schwierig; perfekte Testfälle sollten die korrekte Funktionalität vollständig überprüfen, sowohl unabhängig von unwichtigen Implementierungsdetails als auch robust gegenüber Abkürzungslösungen sein. Diese Probleme sind von Natur aus komplex und schwer zu lösen. Das Erkennen dieser Probleme erforderte mehrere umfangreiche menschliche Labeling-Kampagnen. 

Wir haben diese Erkenntnisse in unsere jüngsten Evaluierungsbemühungen einfließen lassen. In den letzten Monaten haben wir uns dafür entschieden, Ergebnisse aus der öffentlichen Aufteilung von SWE-Bench Pro zu berichten. Wir empfehlen anderen Modellentwickler:innen, dasselbe zu tun. SWE-bench Pro ist nicht perfekt, scheint aber empirisch gesehen weniger anfällig für Kontaminationsprobleme zu sein. Unsere Kontaminationsprüfung ergab einige Fälle von Kontamination, diese waren jedoch deutlich seltener und weniger gravierend als bei der SWE-Bench Verified. Kein Modell konnte einen vollständig wortgetreuen Gold-Patch erzeugen.

Wir werden auch weiterhin in originelle, privat verfasste Benchmarks investieren und Industrie sowie Wissenschaft bitten, dasselbe zu tun. In GDPVal⁠ werden Aufgaben privat von Fachexpert:innen verfasst, wodurch das Expositionsrisiko reduziert wird, und Lösungen werden ganzheitlich von geschulten Prüfer:innen bewertet. Dieser Ansatz ist ressourcenintensiv, aber zunehmend notwendig, um echte Verbesserungen der Fähigkeiten zu messen.