Signal und Rauschen bei Code-Bewertungen trennen

Die genaue Messung der Fähigkeiten unserer Modelle ist wichtig für fundierte Einsatz- und Sicherheitsentscheidungen, einschließlich Entscheidungen im Rahmen des Preparedness Framework⁠(wird in einem neuen Fenster geöffnet) von OpenAI. Mit jeder Modellveröffentlichung veröffentlichen wir Ergebnisse für verschiedene externe und interne Benchmarks, um den Modellfortschritt nachzuverfolgen. Wenn Evaluierungen Mängel aufweisen, die die Ergebnisse beeinflussen, können sie ein falsches Verständnis von Fähigkeiten vermitteln, Sicherheitsfälle verfälschen und Forschungsprioritäten beeinflussen.

Wir haben kürzlich untersucht, wie einer der am häufigsten verwendeten Coding-Benchmarks, SWE-bench Verified, grundlegende Design- und Kontaminationsprobleme aufwies, und festgestellt, dass die Evaluation keine aussagekräftigen Erkenntnisse zu Fähigkeiten in der Softwareentwicklung mehr lieferte. Damals haben wir die größere Community dazu ermutigt, auf SWE-Bench Pro umzusteigen.

SWE-Bench Pro⁠(wird in einem neuen Fenster geöffnet) wurde entwickelt, um SWE-bench Verified zu verbessern, indem Modelle anhand längerer Zeithorizonte und realistischerer Programmieraufgaben getestet werden, um Fähigkeiten im agentischen Programmieren besser zu erfassen. Wie bei SWE-bench Verified werden Aufgaben programmgesteuert aus der Historie von Feature-Änderungen in einer Reihe von öffentlichen und privaten Repositories abgeleitet. Modelle müssen eine Lösung implementieren, die neue Tests für ein Feature besteht, ohne bestehende Funktionalität zu beeinträchtigen. Beim öffentlichen Split mit 731 Aufgaben verbesserten sich Frontier-Modelle innerhalb von acht Monaten von einer Bestehensrate von 23,3 % auf 80,3 %.

Seitdem haben wir ein ähnliches Audit für SWE-Bench Pro durchgeführt und den Datensatz mithilfe einer Pipeline zur Analyse von Datenpunkten überprüft. Die Pipeline prüfte Modellversuche zur Aufgabe, Aufgabenmetadaten und Fehlerprotokolle, um wahrscheinliche Schwachstellen in der Evaluierung zu kennzeichnen. Jede gekennzeichnete Aufgabe wurde anschließend in mehreren Durchläufen von Ermittleragenten bewertet und unabhängig von fünf erfahrenen Softwareingenieuren geprüft; Unstimmigkeiten wurden zur weiteren Untersuchung eskaliert.

Die Probleme ließen sich hauptsächlich in vier Kategorien einteilen:

• Übermäßig strenge Tests¹ erzwingen bestimmte Implementierungsdetails, die im Prompt nicht angegeben sind, wodurch viele funktional korrekte Einreichungen als ungültig gewertet werden.
• Unterspezifizierte Prompts² lassen Anforderungen unberücksichtigt, die durch verdeckte Tests erzwungen werden und die nicht vernünftigerweise ableitbar sind.
• Tests mit niedriger Abdeckung prüfen die angeforderte Funktion nur unzureichend, sodass unvollständige Korrekturen durchgehen können.
• Ein irreführender Prompt lenkt Modelle zu falschem Verhalten oder widerspricht dem, was Tests verlangen.

Unsere Ergebnisse weisen auf die Schwierigkeit hin, anspruchsvolle, aber faire Benchmarks zusammenzustellen, sowie auf den zunehmenden Nutzen von Agenten für skalierbare Datenqualitätsprüfungen. Angesichts dieser Ergebnisse schätzen wir, dass etwa 30 % der SWE-bench Pro-Aufgaben fehlerhaft sind, und empfehlen Modellentwicklern, die Ergebnisse sorgfältig zu prüfen.

Unser Ziel ist es, sicherzustellen, dass Fehlschläge bei Aufgaben tatsächliche Einschränkungen des Modells widerspiegeln und Erfolge bei Aufgaben vollständige und gültige Lösungen für den Prompt darstellen. Um die Qualität der in der Evaluierung verwendeten Daten zu überprüfen, haben wir eine Qualitätssicherungs-Pipeline erstellt, um zu beurteilen, ob jeder Datenpunkt die Fähigkeiten des Modells korrekt widerspiegelt.

Ein erster automatisierter Filter überprüft die dem Modell erteilten Anweisungen, die Versuche des Modells, die Aufgabe zu lösen, sowie die Tests, mit denen diese Versuche bewertet werden, um wahrscheinlich fehlerhafte oder problematische Beispiele zu kennzeichnen. Dieser Filter hat 286 potenziell fehlerhafte Aufgaben markiert. Anschließend führten wir eine eingehendere Prüfung dieser Teilmenge auf zwei Arten durch: eine von Menschen beaufsichtigte Agentenprüfung, die umfangreiche Prüfungen mit Ermittleragenten und eine abschließende menschliche Beurteilung umfasst; sowie eine von Menschen durchgeführte Annotationskampagne in Zusammenarbeit mit erfahrenen Softwareentwicklern.

Jedes gekennzeichnete Problem wird mithilfe von Codex-basierten Ermittleragenten geprüft, denen Zugriff auf das Aufgaben-Repository und die Umgebung gewährt wurde. Dies hilft ihnen dabei, vertretbare Mehrdeutigkeiten in Aufgabenstellungen, die sich oft durch das Untersuchen von umliegendem Code und Repository-Konventionen klären lassen, von echter Unterspezifikation zu unterscheiden. Der Agent kann Tests ausführen, Dateien im Repository prüfen und Modellversuche sowie deren häufige Fehlermodi bei der Aufgabe untersuchen. Nach mehreren unabhängigen Wiederholungen dieser eingehenderen Audits überprüfte ein Forscher die Zusammenfassungen, traf eine abschließende Beurteilung und kennzeichnete die wahrscheinlichen Probleme.

Parallel dazu führten wir eine menschliche Annotierungskampagne für die markierte Teilmenge durch. Wir arbeiteten mit erfahrenen Softwareingenieurinnen und -ingenieuren zusammen, die vor der Prüfung der Aufgaben in den Benchmark-Zielen, der Issue-Taxonomie und den Randfällen geschult worden waren. Jede Aufgabe wurde von fünf Ingenieuren überprüft.

Die Prüfer bildeten sich anhand der sichtbaren Problemstellung, der Testfälle und der Ground-Truth-Referenzlösung (bekannt als „Gold Patch“) ein unabhängiges Urteil, bevor sie die Pipeline-Analyse oder das Transkript als unterstützenden Kontext heranzogen. Die Prüfer wiesen anschließend auf Grundlage konkreter Nachweise ein Label und eine Schweregradbewertung zu und eskalierten Unstimmigkeiten oder Fälle mit geringer Zuverlässigkeit zur weiteren Überprüfung.

Im Vergleich zu den Ermittleragenten markierten menschliche Prüfer Aufgaben häufiger als fehlerhaft. Es gab auch einige Uneinigkeit hinsichtlich der Kategorien zwischen den beiden Überprüfungspfaden, aber bei keiner markierten Aufgabe war „nicht fehlerhaft“ die am häufigsten von Menschen vergebene Kennzeichnung. Bei den Kategorien, die die Agentenpipeline markiert hatte, überschnitten sich die Einschätzungen der Prüfer in 74 % der Fälle.

Im Vergleich zur Agenten-Pipeline wählten die menschlichen Prüfer auch häufiger mehrere Labels für eine Aufgabe aus, was darauf hindeutet, dass sie die Aufgaben auf mehrere Arten als fehlerhaft empfanden oder dass sie sich nicht eindeutig einer einzigen Kategorie zuordnen ließen. Dies deutet darauf hin, dass die Agenten-Prüfer-Pipeline zu einer konservativen Kennzeichnung führte: sie erfasste die gleichen breiten Fehlermodi, die auch von Menschen identifiziert wurden, während Fälle, in denen Prüfer zusätzliche oder sich überschneidende Probleme feststellten, unterzählt wurden. Der größte Unterschied zeigte sich bei Tests mit geringer Abdeckung, die Menschen bei 9,4 % des Benchmarks als häufigstes Problem auswählten, verglichen mit 4,1 %, die von der Agenten-Pipeline ermittelt wurden.

Die von uns identifizierten Probleme zeigen zusammen mit ähnlichen Fällen in SWE-bench Verified, wie wichtig es ist, Benchmarks gründlich zu überprüfen. Probleme und Pull Requests aus Open-Source-Repositories wurden ursprünglich für die Zusammenarbeit zwischen Menschen erstellt, oft im Rahmen langer Hin und Her-Kommunikation zwischen Betreuern und Mitwirkenden. Infolgedessen passen Problembeschreibungen, zusammengeführter Code und Unit-Tests nicht immer so zusammen, dass sie saubere, isolierte Aufgaben zur zuverlässigen Bewertung von Modellen bilden. Insbesondere können die in Pull Requests enthaltenen Tests übermäßig streng sein, da sie dazu dienen, eine bestimmte Änderung zu validieren, anstatt einen implementierungsunabhängigen Standard für die Lösung der Aufgabe zu definieren.

Gleichzeitig sind Mängel bei der Evaluation heute leichter zu erkennen, als dies noch vor kurzer Zeit der Fall gewesen wäre. Mit zunehmenden Modellfähigkeiten können wir diese Modelle nutzen, um Prompts, Tests, Patches, Traces und Edge Cases deutlich gründlicher und konsistenter zu prüfen. So lassen sich Benchmark-Probleme aufdecken, deren Ermittlung in großem Maßstab zuvor zu kostspielig oder unpraktikabel war.

Wir hoffen, dass die breitere Evaluierungs-Community neue Benchmarks entwickelt, die von erfahrenen Softwareentwicklern speziell dafür konzipiert sind, die Fähigkeiten von Modellen zu testen. Dieser Ansatz kann den hohen Standard und die Realitätsnähe bewahren, die wir zur Messung der Fähigkeiten von Modellen anstreben, und ermöglicht eine bessere menschliche Aufsicht während des gesamten Prozesses. Angesichts der in dieser Analyse aufgedeckten Probleme ziehen wir unsere frühere Empfehlung zurück, SWE-Bench Pro einzuführen.

Letztlich sollte eine Evaluierung durch Benchmarks aussagekräftige Hinweise liefern, die schwer auszutricksen sind, denen man leicht vertrauen kann und die Modellfähigkeiten oder die Ausrichtung wirklich widerspiegeln. Da diese Ergebnisse als Grundlage für OpenAIs Entscheidungen zur Bereitstellung und Sicherheit dienen, müssen die von uns nachverfolgten Evaluierungen valide und aussagekräftig sein.