Jemand sagte: „Wir hatten Erdbeeren erwartet, aber sie haben Grünkohl herausgebracht.“ Mal sehen, wofür dieser „Grünkohl“ verwendet wird.
Die Programmierfähigkeiten großer Modelle haben schon immer große Aufmerksamkeit erregt, und das Aufkommen des supermächtigen KI-Programmierers Devin hat das Thema „Kann KI Programmierer ersetzen?“ in den Vordergrund gerückt. Kürzlich hat Devin auch einen neuen Gegner begrüßt – den autonomen KI-Programmierer Genie, der vom Startup Cosine ins Leben gerufen wurde. Das Unternehmen gab an, dass Genie Devin deutlich übertraf und im SWE-Benchmark eines Drittanbieters 30 % erreichte, während Devin nur 13,8 % erreichte. 
Dieser SWE-Bench ist ein Benchmark-Datensatz, der zur Bewertung der Fähigkeit von LLM verwendet wird, echte Softwareprobleme auf GitHub zu lösen. Es sammelt 2.294 Issue-Pull-Request-Paare aus 12 beliebten Python-Repositories. Während des Tests erhält LLM eine Codebasis und eine Problembeschreibung und generiert dann einen Patch, um das im Problem beschriebene Problem zu lösen. Dieser Datensatz wurde häufig zur Bewertung der KI-Programmierfähigkeiten verwendet. Mit der Weiterentwicklung der KI-Programmierfähigkeiten entwickelt sich auch dieser Benchmark weiter. Heute früh wurde das online gemeldete OpenAI-Modell „Strawberry“ erneut verzögert, aber OpenAI hat etwas Neues veröffentlicht, nämlich eine verbesserte Version von SWE-Bench – SWE-bench Verified. OpenAI wies darauf hin, dass der ursprüngliche SWE-Bench einige Probleme aufweist, die dazu führen können, dass die autonomen Software-Engineering-Fähigkeiten des Modells unterschätzt werden. Daher arbeiteten sie während des Verbesserungsprozesses mit den ursprünglichen SWE-Bench-Autoren zusammen, um manuelle Überprüfungen und Verbesserungen durchzuführen, um sicherzustellen, dass der Umfang der Komponententests angemessen und die Problembeschreibung klar war. In einem neuen Test auf SWE-Bench Verified erzielten viele KI-Programmierer bessere Ergebnisse als zuvor. Unter anderem hat die Agentless-Lösung von UIUC die Punktzahl sogar verdoppelt. OpenAI glaubt, dass dies beweist, dass der vorherige Benchmark den Fehler aufweist, die KI-Programmierfähigkeiten zu unterschätzen. Aber für Internetnutzer auf der ganzen Welt, die „Strawberry“ schauen, ist diese Ankündigung immer noch zu oberflächlich. Jemand sagte: „Wir hatten Erdbeeren erwartet, aber sie haben Grünkohl herausgebracht.“Hintergrund zum SWE-BenchJedes Beispiel im SWE-Bench-Testsatz wurde aus einem gelösten GitHub-Problem in 12 Open-Source-Python-Code-Repositories auf GitHub erstellt. Jedem Beispiel ist eine Pull-Anfrage (PR) zugeordnet, die Lösungscode und Komponententests enthält, um die Richtigkeit des Codes zu überprüfen. Diese Komponententests werden als FAIL_TO_PASS-Tests bezeichnet, da sie fehlschlagen, bevor der Lösungscode im PR hinzugefügt wird, und danach bestehen. Jedes Beispiel enthält außerdem PASS_TO_PASS-Tests, die vor und nach der Zusammenführung des PR durchgeführt werden, um zu überprüfen, ob der PR andere Funktionen in der Codebasis beeinträchtigt, die nicht mit dem Problem zusammenhängen. In SWE-Bench erhält der KI-Agent den Originaltext aus dem GitHub-Issue, also die Problemstellung, und hat Zugriff auf die Codebasis. Anhand dieser Informationen muss der Agent Dateien in der Codebasis bearbeiten, um das Problem zu lösen. Die vom KI-Agenten bereitgestellte Bearbeitung wird durch Ausführen der Tests FAIL_TO_PASS und PASS_TO_PASS ausgewertet. Wenn der FAIL_TO_PASS-Test bestanden wird, bedeutet dies, dass das Problem durch die Bearbeitung behoben wurde. Wenn der PASS_TO_PASS-Test bestanden wird, bedeutet dies, dass durch die Bearbeitung keine überflüssigen Teile der Codebasis beschädigt wurden. Um das ursprüngliche GitHub-Problem vollständig zu lösen, müssen beide Testreihen bestanden werden. Drei Verbesserungsrichtungen zur Verbesserung der Robustheit und Zuverlässigkeit der SWE-BankUm die Robustheit und Zuverlässigkeit der SWE-Bank zu verbessern. Das Entwicklungsteam identifizierte drei Hauptrichtungen für Verbesserungen:
- Unit-Tests zur Bewertung der Korrektheit einer Lösung sind oft zu spezifisch und manchmal nicht einmal relevant für das Problem. Dies kann dazu führen, dass die richtige Lösung abgelehnt wird.
- Die Problembeschreibung vieler Proben ist nicht klar genug, was zu Unklarheiten darüber führt, was das Problem ist und wie es gelöst werden sollte.
- Manchmal ist es schwierig, eine SWE-Bench-Entwicklungsumgebung für den Agenten zuverlässig einzurichten, was dazu führen kann, dass Unit-Tests unabhängig von der Lösung unbeabsichtigt fehlschlagen. In diesem Fall kann eine vollkommen gültige Lösung als falsch gewertet werden.
Um diese Probleme anzugehen, hat OpenAI eine menschliche Annotationskampagne durch professionelle Softwareentwickler für jedes Beispiel im SWE-bench-Testset gestartet. Das Screening wird durchgeführt, um Unit-Tests sicherzustellen sind angemessen umfangreich und die Problembeschreibungen sind klar und eindeutig. Zusammen mit den Autoren von SWE-bench veröffentlichten sie SWE-bench Verified: eine Teilmenge des ursprünglichen Testsatzes von SWE-bench, die 500 Proben enthält, die von menschlichen Annotatoren verifiziert wurden. Diese Version ersetzt die ursprünglichen Testsuiten SWE-bench und SWE-bench Lite. Darüber hinaus veröffentlichen sie menschliche Anmerkungen für alle SWE-Bench-Testproben. Sie haben außerdem mit den Autoren von SWE-bench zusammengearbeitet, um ein neues Bewertungstool für SWE-bench zu entwickeln, das eine containerisierte Docker-Umgebung verwendet, um die Bewertung auf SWE-bench zuverlässiger zu machen. - Tool-Adresse: https://github.com/princeton-nlp/SWE-bench/tree/main/docs/20240627_docker
OpenAI Arbeitete mit 93 Softwareentwicklern mit Python-Erfahrung zusammen, überprüfte manuell SWE-Bench-Proben, kommentierte 1699 Zufallsproben im SWE-Bench-Testsatz und erhielt schließlich die SWE-Bench-Verifizierung. Ihr Ansatz besteht darin, die Proben im SWE-Bench-Testsatz mit Anmerkungen zu versehen, um Fairness und Genauigkeit des Tests sicherzustellen. Sie konzentrieren sich insbesondere auf zwei wichtige Punkte: erstens die Beurteilung, ob die Problembeschreibung detailliert genug ist, um zu verhindern, dass eine zu vage Beschreibung den Test unfair macht, zweitens die Prüfung, ob der FAIL_TO_PASS-Komponententest gültige Lösungen falsch herausfiltert; Jedes Anmerkungskriterium hat eine Bezeichnung im Bereich [0, 1, 2, 3] mit zunehmendem Schweregrad. Die Markierungen 0 und 1 sind geringfügig; die Markierungen 2 und 3 sind schwerwiegend, was darauf hinweist, dass die Probe in irgendeiner Weise unzureichend ist und verworfen werden sollte. Darüber hinaus bewertet OpenAI die Schwierigkeit jedes Beispiels, indem es Annotatoren auffordert, abzuschätzen, wie lange Entwickler brauchen würden, um sich für eine Lösung zu entscheiden und diese zu implementieren, vorausgesetzt, das Beispiel weist keine Probleme auf. Schließlich bietet OpenAI eine Freiform-Eingabeoption, um alle anderen größeren Probleme mit dem Beispiel zu kennzeichnen. Um SWE-bench Verified zu erstellen, filtert OpenAI alle Proben aus dem ursprünglichen Testsatz mit einer Problemanweisung oder einem FAIL_TO_PASS-Komponententestschweregrad von 2 oder höher sowie alle Proben heraus, die mit anderen schwerwiegenden Problemen gekennzeichnet sind. Nach dem neuen Standard ist ein großer Teil der Proben im ursprünglichen SWE-Bench unqualifiziert.如图所示，38.3% 的样本因为问题陈述不够明确而被标记，61.1% 的样本因为单元测试可能会不公平地将有效的解决方案错误地标记为不正确而被标记（严重程度 2、3 两级加起来）。总体而言，他们的注释过程导致 68.3% 的 SWE-bench 样本因问题陈述不明确、单元测试不公平或其他问题而被过滤掉。
下图比较了原始 SWE-bench 数据集和新 SWE-bench Verified 数据集的难度分布。他们根据 1699 个样本的随机子集估算 SWE-bench 的难度分布。从图上可以看出，在原始的 SWE-bench 数据集中，大多数（77.8%）样本的预计完成时间少于一个经验丰富的软件工程师一个小时的工作量。SWE-bench Lite 和新 SWE-bench Verified 数据集进一步增加了这一比例，预计超过一个小时才能解决的问题少于 10%。然而，这种变化背后的机制有着很大的不同：SWE-bench Lite 是对原始数据集的子采样，使基准测试变得更容易，而 SWE-bench Verified 则试图从数据集中移除不可行的样本。
各个智能体在 SWE-bench Verified 上的性能在新的 SWE-bench Verified 数据集上，开发团队使用多个在原始 SWE-bench 排行榜上表现良好的开源支架测试了 GPT-4o 的性能。结果发现 GPT-4o 在性能最佳的支架上的性能在 SWE-bench Verified 上达到 33.2%，是原始 SWE-bench 上 16% 分数的两倍多。总的来说，这证实了 OpenAI 最初的怀疑，即原始 SWE-bench 低估了智能体的能力。值得注意的是，从 SWE-bench Lite 到 SWE-bench Verified 的跳跃并不那么明显，因为经过筛选，SWE-bench Lite 已经比完整数据集变得更容易。
在 SWE-bench Verified 上进行评估时，性能的提高可能部分是由于测试样本的分布向更简单的样本倾斜。OpenAI 通过绘制按难度分层的性能来调查这一点。如果新数据集只是改变难度分布以包含更简单的样本，则每个类别内的分层性能不会改变，就像从原始 SWE-bench 到 SWE-bench Lite 的情况一样。相反，OpenAI 观察到，当转向 SWE-bench Verified 时，智能体在各个难度类别的性能均有所提高，这与预期效果一致，即从所有类别中移除不可能的样本，而不是简单地移除困难样本。
参考链接：https://openai.com/index/introducing-swe-bench-verified/以上是OpenAI「草莓」模型再次跳票，凌晨发布的SWE-bench Verified是个啥？的详细内容。更多信息请关注PHP中文网其他相关文章！
