以為能等到「草莓」，沒想到來了個「羽衣甘藍」
儘管全世界都在盯著「草莓計劃」，但似乎叛逆的 OpenAI 總是不盡如人願。你要「草莓」，他們偏偏給你個「羽衣甘藍」。
北京時間 14 日凌晨 2 點，OpenAI 在其官網上發文稱正在發布一個經過人工驗證的 SWE-bench 子集，該子集可以更可靠地評估 AI 模型解決現實世界軟體問題的能力。
SWE-bench Hugging Face 地址：
https://huggingface.co/datasets/princeton-nlp/SWE-bench_Verified
作為準備框架的一部分（準備框架是 OpenAI 設立的一套安全地開發和部署其前沿模型的方法），OpenAI 開發了一系列指標來追蹤、評估和預測模型的自主行動能力。
一直以來，自主完成軟體工程任務的能力是前沿模型自主風險類別中中等風險水平的關鍵組成部分。由於軟體工程任務的複雜性、準確評估生成的程式碼的難度以及模擬真實世界開發場景的挑戰，評估這些能力具有挑戰性。因此，OpenAI 的準備方法還必須仔細檢查評估本身，盡量減少高估或低估風險係數的可能性。
而這一套方法中最流行的軟體工程評估套件之一就是 SWE-bench。它能用於評估大型語言模型到底能不能解決來自 GitHub 上的實際軟體問題，以及能把問題解決到什麼程度。基準測試包括為代理提供程式碼儲存庫和問題描述，並要求它們生成解決該問題所述問題的補丁。
根據 SWE-bench 排行榜，截至 2024 年 8 月 5 日，編碼代理在 SWE-bench 上取得了令人矚目的進步，得分最高的代理在 SWE-bench 上的得分為 20%，在 SWE-bench Lite 上的得分為 43%。
經過測試發現，一些 SWE-bench 上的任務可能難以解決或無法解決，這導致 SWE-bench 系統性地低估了模型的自主軟體工程能力。因此 OpenAI 與 SWE-bench 的作者合作，在新版本的基準測試中解決了這些問題，該版本應該可以提供更準確的評估。
那麼，SWE-bench 的背景是怎樣的？
SWE-bench 測試集中的每個示例都是根據 GitHub 上 12 個開源 Python 儲存庫之一中已解決的 GitHub 問題創建的。每個示例都有一個關聯的拉取請求 (PR)，其中包括解決方案程式碼和用於驗證程式碼正確性的單元測試。這些單元測試在添加 PR 中的解決方案程式碼之前失敗，但之後通過，因此稱為 FAIL_TO_PASS 測試。每個示例還有關聯的 PASS_TO_PASS 測試，這些測試在 PR 合併之前和之後都通過，用於檢查程式碼庫中現有的不相關功能是否未被 PR 破壞。
對於 SWE-bench 中的每個樣本，代理都會獲得來自 GitHub 問題的原始文本（稱為問題陳述），並被授予訪問程式碼庫的權限。有了這些，代理必須編輯程式碼庫中的文件來解決問題。測試不會向代理顯示。
FAIL_TO_PASS 通過運行和測試來評估擬議的編輯 PASS_TO_PASS。如果測試通過，則意味著解決了問題。如果測試通過，則編輯沒有無意中破壞程式碼庫的不相關部分。編輯必須通過這兩組測試才能完全解決原始 GitHub 問題。FAIL_TO_PASS PASS_TO_PASS
採用 SWE-bench 作為準備情況評估
鑑於 SWE-bench 與準備框架的潛在相關性，研究人員旨在找到提高基準穩健性和可靠性的方法。因此確定了三個主要改進領域：
用於評估解決方案正確性的單元測試通常過於具體，在某些情況下甚至與問題無關。這可能會導致正確的解決方案被拒絕。
許多示例的問題描述不明確，導致無法明確問題是什麼以及如何解決。
有時很難為代理可靠地設置 SWE-bench 開發環境，無論採用哪種解決方案，都可能無意中導致單元測試失敗。在這種情況下，完全有效的解決方案可能會被評為不正確。
下面是一個說明第一個問題的例子。
SWE-bench 示例 scikit-learn__scikit-learn-14520 任務是讓代理解決 scikit-learn 儲存庫中的問題 此問題陳述報告函數的 copy 參數可以由用戶指定，但被庫忽略（該行為而是在函數內部硬編碼）：
解決上述問題的代理首先必須處理函數行為是有意為之還是錯誤的問題，然後對程式碼庫進行更改以解決問題。根據 SWE-bench 設置，代理提出的任何解決方案都需要通過以下測試，該測試摘自 最初解決問題的 PR：
此測試明確檢查解決方案是否在 copy 使用該參數時必須引發 DeprecationWarning，儘管上述問題文本中的原始問題陳述並未傳達此要求。此外，即使代理意識到應該引發 DeprecationWarning，測試也要求代理完全匹配棄用消息，這是在代理無法訪問的 PR 中進行一些討論後才得出的結論。
請注意，代理僅從主要問題文本中獲得了問題描述，並且無法看到它需要通過的測試。在這種設置下，代理幾乎不可能在 SWE-bench 中解決此示例。
已通過 SWE-bench 驗證
為了解決這些問題，OpenAI 與專業軟體開發人員一起發起了一項人工註釋活動，以篩選 SWE-bench 測試集的每個樣本，以獲得適當範圍的單元測試和明確指定的問題描述。
OpenAI 與 SWE-bench 的作者一起發布了 SWE-bench Verified：SWE-bench 原始測試集的一個子集，包含 500 個經人工註釋員驗證無問題的樣本。此版本取代了原始 SWE-bench 和 SWE-bench Lite 測試集。此外，OpenAI 還發布了所有 SWE-bench 測試樣本的人工註釋。
同時，OpenAI 還與 SWE-bench 作者合作，為 SWE-bench 開發了新的評估工具。它使用容器化的 Docker 環境使得在 SWE-bench 上進行評估更容易、更可靠。
在 SWE-bench Verified 上，GPT-4o 解析了 33.2% 的樣本，其中表現最好的開源支架 Agentless 在 SWE-bench 上的得分是之前 16% 的兩倍。
沒有等來「草莓計劃」官宣，這款測試集最多只能算得上一道餐前小吃。那麼，這樣一款測試集也值得 OpenAI 為此造勢嗎？
一週前，OpenAI 首席執行官 Sam Altman 發布了一個帶有草莓圖片的推文，並配文「我喜歡花園裡的夏天」。圖片中的四顆草莓，或許暗示了 GPT-4 的新版本可能專為推理而打造，可與專為創造和互動而打造的 GPT-4o 一起運行。這引發了大家對 OpenAI 發布新模型 Strawberry 的各種猜想。
近兩天，X 上的爆料人 @iruletheworldmo 頻繁發布 Strawberry 發布相關的消息，並表示 OpenAI 將在太平洋時間 8 月 13 日上午 10 點發布其新模型——一個以推理為重點的人工智能「草莓計劃」（Strawberry）。整個社區全都是各種期待。
神秘的「草莓計劃」是什麼？
OpenAI 的新「草莓計劃」可以讓 ChatGPT 更自由地搜索網絡並解決複雜問題。
「草莓計劃」最早是在 7 月 12 日被外媒曝出。據知情人士和路透社審查的內部文件稱，ChatGPT 製造商 OpenAI 正在一個代號為「Strawberry」的項目中研究其人工智能模型的新方法。
但該項目的細節此前未曾報道過，而微軟支持的初創公司正在競相證明其提供的模型類型能夠提供高級推理能力。
根據路透社 5 月份看到的一份 OpenAI 內部文件副本，OpenAI 內部團隊正在開發 Strawberry。路透社無法確定該文件的具體發布日期，該文件詳細說明了 OpenAI 打算如何使用 Strawberry 進行研究的計劃。消息人士向路透社描述了該計劃，稱其為一項正在進行的工作。該通訊社無法確定 Strawberry 距離公開發布還有多久。
這位知情人士表示，即使在 OpenAI 內部，Strawberry 的工作原理也是一個嚴格保密的秘密。
該文件描述了一個使用 Strawberry 模型的項目，目的是使公司的人工智能不僅能夠生成查詢的答案，而且能夠提前規劃，自主可靠地瀏覽互聯網，從而執行 OpenAI 所稱的「深度研究」，消息人士稱。
根據外媒對十多位人工智能研究人員的採訪，這是迄今為止人工智能模型尚未解決的問題。
當時，被問及 Strawberry 以及本文報道的細節時，OpenAI 公司發言人在一份聲明中表示：「我們希望我們的人工智能模型能夠像我們一樣看待和理解世界。持續研究新的人工智能能力是業內的常見做法，大家共同相信這些系統的推理能力會隨著時間的推移而提高。」
該發言人沒有直接回答有關草莓的問題。
谷歌打擂台
Strawberry 一直以來「猶抱琵琶半遮面」，這次 OpenAI 再突然宣造勢宣傳，### 很難說不是為了追擊谷歌幾乎同時進行的「Made by Google 2024」硬體活動。
此次活動上，谷歌自己最新的硬體產品，包括期待已久的下一代 Pixel 手機：Pixel 9、Pixel 9 Pro 和新款 Pixel 9 Fold，此外還有新款 Pixel Watch 和 Pixel Buds 等硬體產品。雖然是硬體發布，但 AI 主題依然充滿了整場發布。其中，谷歌的 AI 聊天機器人 Gemini 是 Pixel 9 手機的默認助手。