Dachte, man könnte auf "Erdbeeren" warten, aber stattdessen kam "Grünkohl"
Obwohl die ganze Welt auf den "Erdbeerplan" starrte, scheint das rebellische OpenAI immer wieder nicht den Erwartungen zu entsprechen. Du willst "Erdbeeren", aber sie geben dir stattdessen "Grünkohl".
Am 14. um 2 Uhr morgens Pekinger Zeit veröffentlichte OpenAI auf seiner offiziellen Website einen Artikel, in dem angekündigt wurde, dass sie eine manuell verifizierte Teilmenge von SWE-bench veröffentlichen, die die Fähigkeit von KI-Modellen, reale Softwareprobleme zu lösen, zuverlässiger bewerten kann.
SWE-bench Hugging Face Adresse:
https://huggingface.co/datasets/princeton-nlp/SWE-bench_Verified
Als Teil des Vorbereitungsrahmens (ein von OpenAI eingerichtetes Verfahren zur sicheren Entwicklung und Bereitstellung seiner fortschrittlichen Modelle) hat OpenAI eine Reihe von Metriken entwickelt, um die autonomen Handlungsfähigkeiten der Modelle zu verfolgen, zu bewerten und vorherzusagen.
Die Fähigkeit, Softwareentwicklungsaufgaben autonom zu erledigen, war schon immer ein wichtiger Bestandteil der mittleren Risikostufe in der Kategorie der autonomen Risiken fortschrittlicher Modelle. Aufgrund der Komplexität von Softwareentwicklungsaufgaben, der Schwierigkeit, generierten Code genau zu bewerten, und der Herausforderung, reale Entwicklungsszenarien zu simulieren, ist die Bewertung dieser Fähigkeiten eine Herausforderung. Daher muss OpenAIs Vorbereitungsmethode auch die Bewertung selbst sorgfältig prüfen, um die Möglichkeit einer Über- oder Unterschätzung des Risikofaktors zu minimieren.
Eines der beliebtesten Softwareentwicklungs-Bewertungssuiten in dieser Methode ist SWE-bench. Es kann verwendet werden, um zu bewerten, ob große Sprachmodelle tatsächliche Softwareprobleme von GitHub lösen können und in welchem Ausmaß sie die Probleme lösen können. Der Benchmark beinhaltet die Bereitstellung eines Code-Repositorys und einer Problembeschreibung für den Agenten und fordert ihn auf, einen Patch zu generieren, der das beschriebene Problem löst.
Laut der SWE-bench Rangliste haben Coding-Agenten bis zum 5. August 2024 bemerkenswerte Fortschritte auf SWE-bench gemacht, wobei der bestbewertete Agent eine Punktzahl von 20% auf SWE-bench und 43% auf SWE-bench Lite erreichte.
Nach Tests wurde festgestellt, dass einige Aufgaben auf SWE-bench möglicherweise schwierig oder unlösbar sind, was dazu führt, dass SWE-bench die autonomen Softwareentwicklungsfähigkeiten der Modelle systematisch unterschätzt. Daher hat OpenAI mit den Autoren von SWE-bench zusammengearbeitet, um diese Probleme in einer neuen Version des Benchmarks zu beheben, die eine genauere Bewertung liefern sollte.
Was ist also der Hintergrund von SWE-bench?
Jedes Beispiel im SWE-bench Testset wurde basierend auf einem gelösten GitHub-Problem in einem von 12 Open-Source-Python-Repositorys auf GitHub erstellt. Jedes Beispiel hat einen zugehörigen Pull Request (PR), der den Lösungscode und Unit-Tests zur Überprüfung der Coderichtigkeit enthält. Diese Unit-Tests schlagen fehl, bevor der Lösungscode im PR hinzugefügt wird, bestehen aber danach, daher werden sie als FAIL_TO_PASS-Tests bezeichnet. Jedes Beispiel hat auch zugehörige PASS_TO_PASS-Tests, die sowohl vor als auch nach dem Zusammenführen des PR bestehen und verwendet werden, um zu überprüfen, ob bestehende, nicht verwandte Funktionalitäten im Codebase nicht durch den PR beschädigt wurden.
Für jedes Beispiel in SWE-bench erhält der Agent den Originaltext aus dem GitHub-Problem (als Problembeschreibung bezeichnet) und erhält Zugriff auf das Code-Repository. Mit diesen muss der Agent Dateien im Code-Repository bearbeiten, um das Problem zu lösen. Die Tests werden dem Agenten nicht gezeigt.
FAIL_TO_PASS und PASS_TO_PASS werden verwendet, um die vorgeschlagenen Bearbeitungen durch Ausführen und Testen zu bewerten. Wenn die FAIL_TO_PASS-Tests bestehen, bedeutet dies, dass das Problem gelöst wurde. Wenn die PASS_TO_PASS-Tests bestehen, bedeutet dies, dass die Bearbeitung nicht versehentlich nicht verwandte Teile des Codebase beschädigt hat. Die Bearbeitung muss beide Testgruppen bestehen, um das ursprüngliche GitHub-Problem vollständig zu lösen.
Verwendung von SWE-bench als Vorbereitungsbewertung
Angesichts der potenziellen Relevanz von SWE-bench für den Vorbereitungsrahmen zielten die Forscher darauf ab, Wege zur Verbesserung der Robustheit und Zuverlässigkeit des Benchmarks zu finden. Daher wurden drei Hauptverbesserungsbereiche identifiziert:
Die Unit-Tests zur Bewertung der Korrektheit der Lösungen sind oft zu spezifisch und in einigen Fällen sogar irrelevant für das Problem. Dies kann dazu führen, dass korrekte Lösungen abgelehnt werden.
Viele Beispiele haben unklare Problembeschreibungen, was es schwierig macht, das Problem und dessen Lösung klar zu verstehen.
Manchmal ist es schwierig, die SWE-bench Entwicklungsumgebung für den Agenten zuverlässig einzurichten, was unbeabsichtigt dazu führen kann, dass Unit-Tests fehlschlagen, unabhängig von der gewählten Lösung. In solchen Fällen können vollständig gültige Lösungen als inkorrekt bewertet werden.
Hier ist ein Beispiel, das das erste Problem veranschaulicht.
Die SWE-bench Beispielaufgabe scikit-learn__scikit-learn-14520 besteht darin, dass der Agent ein Problem im scikit-learn Repository löst. Diese Problembeschreibung berichtet, dass der copy-Parameter der Funktion vom Benutzer angegeben werden kann, aber von der Bibliothek ignoriert wird (das Verhalten ist stattdessen in der Funktion hartcodiert):
Um das oben genannte Problem zu lösen, muss der Agent zunächst entscheiden, ob das Funktionsverhalten beabsichtigt oder ein Fehler ist, und dann Änderungen am Codebase vornehmen, um das Problem zu beheben. Gemäß der SWE-bench-Konfiguration muss jede vom Agenten vorgeschlagene Lösung den folgenden Test bestehen, der aus dem PR entnommen wurde, der das Problem ursprünglich löste:
Dieser Test prüft explizit, ob die Lösung eine DeprecationWarning auslöst, wenn der copy-Parameter verwendet wird, obwohl diese Anforderung in der ursprünglichen Problembeschreibung im obigen Problemtext nicht vermittelt wurde. Darüber hinaus verlangt der Test, selbst wenn der Agent erkennt, dass eine DeprecationWarning ausgelöst werden sollte, dass der Agent die Warnmeldung exakt übereinstimmt, was das Ergebnis einiger Diskussionen im PR war, auf die der Agent keinen Zugriff hat.
Beachten Sie, dass der Agent nur die Problembeschreibung aus dem Hauptproblemtext erhält und die Tests, die er bestehen muss, nicht sehen kann. In dieser Konfiguration ist es für den Agenten nahezu unmöglich, dieses Beispiel in SWE-bench zu lösen.
SWE-bench Verified
Um diese Probleme anzugehen, startete OpenAI zusammen mit professionellen Softwareentwicklern eine manuelle Annotationskampagne, um jedes Beispiel im SWE-bench Testset auf angemessen umfangreiche Unit-Tests und klar spezifizierte Problembeschreibungen zu prüfen.
OpenAI hat zusammen mit den Autoren von SWE-bench SWE-bench Verified veröffentlicht: eine Teilmenge des ursprünglichen SWE-bench Testsets mit 500 Beispielen, die von manuellen Annotatoren als problemlos verifiziert wurden. Diese Version ersetzt die ursprünglichen SWE-bench und SWE-bench Lite Testsets. Darüber hinaus hat OpenAI manuelle Annotationen für alle SWE-bench Testbeispiele veröffentlicht.
Gleichzeitig hat OpenAI in Zusammenarbeit mit den SWE-bench Autoren neue Evaluierungswerkzeuge für SWE-bench entwickelt. Es verwendet containerisierte Docker-Umgebungen, um die Evaluierung auf SWE-bench einfacher und zuverlässiger zu machen.
Auf SWE-bench Verified löste GPT-4o 33,2% der Beispiele, wobei der leistungsstärkste Open-Source-Scaffold Agentless auf SWE-bench doppelt so viele Punkte erzielte wie die vorherigen 16%.
Statt der Ankündigung des "Erdbeerplans" kann dieses Testset höchstens als kleine Vorspeise betrachtet werden. Ist es also wert, dass OpenAI dafür Aufmerksamkeit erregt?
Vor einer Woche veröffentlichte OpenAI CEO Sam Altman einen Tweet mit einem Erdbeerbild und dem Text "Ich liebe den Sommer im Garten". Die vier Erdbeeren im Bild deuteten möglicherweise darauf hin, dass eine neue Version von GPT-4 speziell für Reasoning entwickelt wurde und zusammen mit GPT-4o, das für Kreativität und Interaktion entwickelt wurde, laufen könnte. Dies führte zu verschiedenen Spekulationen über die Veröffentlichung eines neuen Modells namens Strawberry durch OpenAI.
In den letzten zwei Tagen hat der X-Leaker @iruletheworldmo häufig Nachrichten über die Veröffentlichung von Strawberry gepostet und angegeben, dass OpenAI sein neues Modell - eine KI mit Fokus auf Reasoning namens "Strawberry" - am 13. August um 10 Uhr pazifischer Zeit veröffentlichen würde. Die gesamte Community war voller Erwartungen.
Was ist der mysteriöse "Erdbeerplan"?
OpenAIs neuer "Erdbeerplan" könnte ChatGPT ermöglichen, freier im Internet zu suchen und komplexe Probleme zu lösen.
Der "Erdbeerplan" wurde erstmals am 12. Juli von ausländischen Medien enthüllt. Laut Insidern und internen Dokumenten, die Reuters überprüft hat, erforscht ChatGPT-Hersteller OpenAI in einem Projekt mit dem Codenamen "Strawberry" neue Ansätze für seine KI-Modelle.
Details des Projekts wurden zuvor jedoch nicht berichtet, während das von Microsoft unterstützte Startup darum wetteifert zu beweisen, dass die von ihm angebotenen Modelltypen fortgeschrittene Reasoning-Fähigkeiten bieten können.
Laut einer Kopie eines internen OpenAI-Dokuments, das Reuters im Mai sah, wird Strawberry von internen Teams bei OpenAI entwickelt. Reuters konnte das genaue Veröffentlichungsdatum des Dokuments nicht feststellen, das Details darüber enthielt, wie OpenAI Strawberry für Forschungszwecke einzusetzen plant. Quellen beschrieben den Plan gegenüber Reuters als laufende Arbeit. Die Nachrichtenagentur konnte nicht feststellen, wie weit Strawberry von einer öffentlichen Veröffentlichung entfernt ist.
Die Quelle sagte, dass selbst innerhalb von OpenAI die Funktionsweise von Strawberry ein streng gehütetes Geheimnis sei.
Das Dokument beschreibt ein Projekt, das das Strawberry-Modell verwendet, um die KI des Unternehmens nicht nur in die Lage zu versetzen, Antworten auf Anfragen zu generieren, sondern auch im Voraus zu planen und autonom und zuverlässig im Internet zu navigieren, um das durchzuführen, was OpenAI als "tiefe Recherche" bezeichnet, so die Quelle.
Laut Interviews mit über einem Dutzend KI-Forschern ist dies ein Problem, das KI-Modelle bisher nicht gelöst haben.
Damals, als nach Strawberry und den in diesem Artikel berichteten Details gefragt wurde, sagte ein OpenAI-Sprecher in einer Erklärung: "Wir hoffen, dass unsere KI-Modelle die Welt so sehen und verstehen können wie wir. Die kontinuierliche Erforschung neuer KI-Fähigkeiten ist in der Branche üblich, und es besteht ein gemeinsamer Glaube, dass sich die Reasoning-Fähigkeiten dieser Systeme im Laufe der Zeit verbessern werden."
Der Sprecher beantwortete die Fragen zu Strawberry nicht direkt.
Google fordert heraus
Strawberry hat sich bisher "halb verborgen" gehalten, und OpenAIs plötzliche Ankündigung und Werbung kann kaum als nicht auf Googles fast gleichzeitige "Made by Google 2024" Hardware-Veranstaltung abzielend betrachtet werden.
Bei dieser Veranstaltung präsentierte Google seine neuesten Hardwareprodukte, darunter die lang erwartete nächste Generation von Pixel-Telefonen: Pixel 9, Pixel 9 Pro und das neue Pixel 9 Fold, sowie neue Pixel Watch und Pixel Buds Hardware. Obwohl es sich um eine Hardware-Veröffentlichung handelte, war das KI-Thema während der gesamten Präsentation präsent. Insbesondere ist Googles KI-Chatbot Gemini der Standard-Assistent für die Pixel 9 Telefone.