OpenAI「草莓」模型再次跳票，凌晨釋出的SWE-bench Verified是個啥？
机器之心發表於2024-08-14
有人說，「我們期待的是草莓，但他們釋出的是羽衣甘藍。」我們來看看這個「羽衣甘藍」是做什麼用的。
一直以來，大模型的程式設計能力都備受關注，超強 AI 程式設計師 Devin 的問世更是將「AI 能否替代程式設計師」這一話題推上了風口浪尖。最近，Devin 也迎來了新對手 —— 初創公司 Cosine 推出的自主 AI 程式設計師 Genie。該公司表示，Genie 的表現輕鬆超越了 Devin，在第三方基準測試 SWE-bench 上的得分為 30%，而 Devin 的得分僅為 13.8%。
這個 SWE-Bench 是一個用於評估 LLM 解決 GitHub 上真實軟體問題能力的基準測試資料集。它收集了來自 12 個流行的 Python 倉庫的 2,294 個 Issue-Pull Request 對。在測試時，LLM 會拿到一個程式碼庫和 issue 描述，然後生成一個補丁來解決 issue 描述的問題。這個資料集在 AI 程式設計能力的評估中已被廣泛使用。在 AI 程式設計能力進化的同時，這個基準也在進化。今天凌晨，網傳的 OpenAI「草莓」模型再次跳票，但 OpenAI 確實釋出了新東西，就是 SWE-Bench 的改進版本 ——SWE-bench Verified。OpenAI 指出，原始的 SWE-bench 存在一些問題，可能導致模型的自主軟體工程能力被低估。因此，在改進過程中，他們與 SWE-Bench 原作者合作，進行了人工篩選和改進，確保單元測試的範圍適當且問題描述明確。在 SWE-bench Verified 上進行的新測試中，很多 AI 程式設計智慧體的得分都比原來要高。其中，UIUC 的無 Agent 方案 Agentless 甚至實現了得分翻倍，OpenAI 認為，這證明之前的基準確實存在低估 AI 程式設計能力的缺陷。但對於蹲守「草莓」的全世界網友來說，這個釋出還是過於敷衍了。有人說，「我們期待的是草莓，但他們釋出的是羽衣甘藍。」
SWE-bench 測試集中的每個示例都是根據 GitHub 上 12 個開源 Python 程式碼庫中一個已解決的 GitHub issue 建立的。每個樣本都有一個相關的拉取請求（PR），其中包括解決方案程式碼和用於驗證程式碼正確性的單元測試。這些單元測試被稱為 FAIL_TO_PASS 測試，因為在 PR 中的解決方案程式碼新增之前它們會失敗，新增之後則會透過。每個樣本還包括 PASS_TO_PASS 測試，這些測試在 PR 合併前後都會透過，用於檢查 PR 是否破壞了程式碼庫中與問題無關的其他功能。在 SWE-bench 中，AI 智慧體會獲得來自 GitHub issue 的原始文字，即問題陳述，並可以訪問程式碼庫。給定這些資訊，智慧體必須編輯程式碼庫中的檔案以解決問題。AI 智慧體給出的編輯將透過執行 FAIL_TO_PASS 和 PASS_TO_PASS 測試來評估。如果 FAIL_TO_PASS 測試透過，這意味著編輯解決了問題。如果 PASS_TO_PASS 測試透過，則意味著編輯沒有破壞程式碼庫中無關的部分。要完全解決原始的 GitHub 問題，兩組測試都必須透過。提高 SWE-bench 穩健性、可靠性的三個改進方向為了提高 SWE-bench 的穩健性和可靠性。開發團隊確定了三個主要的改進方向：- 用於評估解決方案正確性的單元測試通常過於具體，有時甚至與問題無關。這可能導致正確的解決方案被拒絕。
- 許多樣本的問題描述不夠明確，導致對問題是什麼以及應該如何解決存在歧義。
- 有時很難為智慧體可靠地設定 SWE-bench 開發環境，這會無意中導致單元測試失敗，而不管解決方案如何。在這種情況下，完全有效的解決方案可能被評為不正確。
為了解決這些問題，OpenAI 啟動了一項由專業軟體開發人員進行的人工註釋活動，對 SWE-bench 測試集中的每個樣本進行了篩查，以確保單元測試的範圍適當，問題描述清晰明確。他們與 SWE-bench 的作者們一起釋出了 SWE-bench Verified：這是 SWE-bench 原始測試集的一個子集，包含 500 個樣本，這些樣本已經透過了人工註釋者的驗證。這個版本取代了原來的 SWE-bench 和 SWE-bench Lite 測試集。此外，他們還在釋出所有 SWE-bench 測試樣本的人工註釋。他們還與 SWE-bench 的作者合作，為 SWE-bench 開發了一個新的評估工具，該工具使用容器化的 Docker 環境，使在 SWE-bench 上進行的評估變得更容易、更可靠。- 工具地址：https://github.com/princeton-nlp/SWE-bench/tree/main/docs/20240627_docker
OpenAI 與 93 位具有 Python 經驗的軟體開發人員合作，手動篩選 SWE-bench 樣本，並對 SWE-bench 測試集中的 1699 個隨機樣本進行了註釋，最終得到 SWE-bench Verified。他們的方法是對 SWE-bench 測試集中的樣本進行註釋，以確保測試的公平性和準確性。具體來說，他們關注兩個關鍵點：首先，評估問題描述是否足夠詳細，以防過於模糊的描述導致測試不公平；其次，檢查 FAIL_TO_PASS 單元測試是否會錯誤地篩選掉有效的解決方案。每個註釋標準都有一個標籤，範圍為 [0, 1, 2, 3]，嚴重程度逐漸增加。標籤 0 和 1 是次要的；標籤 2 和 3 是嚴重的，表明樣本在某些方面不充分，應該被丟棄。此外，假設樣本沒有問題，OpenAI 會透過讓註釋者估計開發人員決定和實施解決方案需要多長時間來評估每個樣本的難度。最後，OpenAI 提供了一個自由格式輸入選項來標記樣本的任何其他主要問題。為了構建 SWE-bench Verified，OpenAI 從原始測試集中過濾掉問題陳述或 FAIL_TO_PASS 單元測試嚴重性為 2 或以上的任何樣本，並且還過濾掉所有標記有其他嚴重問題的樣本。按照新的標準，原始 SWE-bench 中的樣本有很大一部分是不合格的。如圖所示，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/