大模型無法替代碼農！ 普林斯頓芝大驚人發現：GPT-4解決GitHub程式設計問題成功率為0

文章來源：新智元

ChatGPT之類的AI編碼工具來勢洶洶，Stack Overflow又裁員了！ 不過，普林斯頓和芝大竟發現，面對真實世界GitHub問題，GPT-4的解決率竟是0%。

Stack Overflow，已經被ChatGPT創飛了！

因為碼農大量湧向ChatGPT、Github Copilot，Stack Overflow今天不得已宣布裁員100多人，幾乎占員工人數的1/3。

所以，ChatGPT這類AI編碼工具，真的要顛覆整個行業了？

不過最近，普林斯頓和芝大的一項研究發現，LLM想要替代碼農，其實沒那麼容易。

論文位址：

在2294個GitHub真實問題面前，GPT-4解決隨機GitHub問題的通過率，竟然是0%！

而即使是最佳模型Claude 2，也只能解決其中的1.96%而已。

碼農會因為ChatGPT而失業嗎？ 答案是——目前絕對不會。

要麼適應，要麼滅亡

作為全世界每個開發者最愛的代碼輔助網站，Stack Overflow在此前的形勢還一片大好，在去年掀起了一場招聘狂潮，整個公司的員工人數都翻了一番，達到了540人。

然而，自從去年11月OpenAI發佈了ChatGPT后，一切都變了。

AI聊天機器人提供的説明，比5年前的論壇帖子更加具體。 通過LLM，開發者可以即時更正確切的代碼、優化建議，以及每行代碼正在執行操作的說明。

雖說LLM提供的答案也並不是100%可靠，但代碼具有獨特的能力，只需在IDE集成開發環境中進行測試，即可立即驗證代碼了，這一切都使寫代碼成為了ChatGPT的理想用例。

因此，Stack Overflow的流量大大減少，ChatGPT、GPT-4驅動的Github Copilot等AI程式設計工具，都成為了碼農的新去處。

今天，CEO Prashanth Chandrasekar宣佈，Stack Overflow裁員一百多人，占員工總數的28%。

CEO對於裁員的解釋是，宏觀經濟壓力下，Stack Overflow在努力走上盈利之路，不斷推出產品創新。

**過河拆橋？ **

ChatGPT給Stack Overflow造成衝擊這件事，最大諷刺之處在於，大語言模型的強大能力，很大程度上就是來自像Stack Overflow這樣的抓取網站。

大語言模型吸空了這些數據，卻不回饋任何東西，如果所有數據源都被迫趕出了這一業務，那時會發生什麼？

現在，不少科技公司面前已經存在著迫在眉睫的問題：如果程式師減少，人造數據就會減少。

如果沒有最新的數據，怎麼訓練新的AI模型呢？

想用我們的數據？ 拿錢來

Stack Overflow當然不能坐以待斃，它選擇了兩種方式自救——

一是開發自己的AI編碼工具OverflowAI，二是直接和OpenAI這樣的科技公司尋求合作，因為這些公司會使用Stack Overflow的數據構建AI模型。

據悉，OpenAI正在為ChatGPT開發網路爬蟲控制，這樣Stack Overflow這樣的網站的數據就不會被爬取。

CEO表示，Stack Overflow已經表明瞭立場：誰想用我們的數據來訓練LLM，誰就來付費。

CEO認為，像Stack Overflow這樣的網站對於大語言模型的發展至關重要，為了進步，它們需要在新知識上進行訓練。

Stack Overflow首席執行官Prashanth Chandrasekar

LLM想取代碼農，還早著呢

所以，大語言模型真能取代碼農嗎？

普林斯頓和芝大團隊發現，沒那麼容易！

在最新論文中，研究人員提出了一種全新框架SWE-bench，以評估大模型在解決2294個GitHub真實問題中的能力。

結果發現，像GPT-4、Claude 2這樣領先的大模型，解決實際問題的能力，都不過5%。

再具體點，GPT-4可以解決隨機GitHub問題的通過率竟是0%，而最佳模型Claude 2，也只能解決其中的1.96%。

更值得一提的是，在使用BM-25檢索每個問題的相關代碼檔時，Claude 2編寫的補丁中只有23%是有效的（可以用於repo），只有~1%真正解決了問題。

此外，不同的模型，在解決12個流行的Python庫問題的性能，也有所差異。

GPT-4大模型取得這樣的結果，真是讓人大跌眼鏡，畢竟許多人都早已將其視為「程式設計利器」。

但要看清，AI真正的實力，不要被刷榜評分而陷入擔憂。

有網友表示，這是對「碼農是否因程式設計而失業」問題的最好的解答。

終於有人為代碼模型製作了一個真正的數據集，Hum只是LLM的leetcode面試。 我們都知道，這對人類工程師來說是個錯誤的衡量標準。 不到4%聽起來是對的，因為大模型離完全自主還很遠。

那麼，SWE-bench評估大模型能力的結果，事實真是如此嗎？

SWE-bench：專為編碼模型設計

在這項研究中，作者發現，當前許多評測大模型編碼能力的基準已經趨於飽和，無法評測出大模型真正的實力。

比如，Human中，挑戰問題太過簡單，LLM只需要幾行代碼就能解決獨立的問題。

然而，現實中軟體工程並非如此簡單。

修復一個bug可能需要流覽龐大的資源庫，理解不同檔中函數之間的關係，又或者在錯綜複雜的代碼中發現一個小錯誤。

受此啟發，普林斯頓、芝大研究人員介紹了SWE-bench。

SWE-bench通過連接GitHub問題和解決相關測試的合併請求解決方案，從真實Python代碼庫中獲取任務實例。

如圖所示，模型的任務（通常是錯誤報告或功能請求）是解決提交到GitHub倉庫的問題。

每項任務都需要生成一個補丁，並描述要應用到現有代碼庫中的更改。

然後使用倉庫的測試框架SWE-bench，評估修改後的代碼庫。

為了找到高品質的大規模任務實例，研究者通過了三個階段的篩選：

**第一階段：倉庫選擇和數據搜索。 **

首先從GitHub上12個流行的開源Python代碼庫中收集拉取請求（PR），總共產生了約90,000個PR。

研究人員將重點放在流行的倉庫上，因為這些倉庫往往維護得更好，有明確的貢獻者指南，並且有更好的測試覆蓋率。 每個PR都有一個相關的代碼庫，即PR合併前的倉庫狀態。

**第二階段：基於屬性的篩選。 **

創建候選任務的方法是，選擇符合以下條件的合併PR：（1）解決了GitHub問題; （2）修改了倉庫的測試檔，這表明使用者很可能貢獻了測試來檢查問題是否已解決。

**第三階段：基於執行的過濾。 **

對於每個候選任務，都會應用PR的測試內容，並記錄應用PR其他內容前後的相關測試結果。

研究者會過濾掉沒有至少一項測試的任務實例，這些測試的狀態從失敗變為通過（以下簡稱「失敗到通過測試」）。 此外，還會過濾掉導致安裝或運行錯誤的實例。

通過這些階段的篩選，原始的90,000個PR被篩選為2,294個任務實例，這些任務實例構成了SWE-bench。

如下圖3所示，顯示了這些任務實例在不同資源庫中的最終分類，表是SWE-bench任務實例的主要特徵。

研究者強調，這些代碼庫都很大，包含數千個檔，而且參考拉取請求通常會同時對多個檔進行修改。

與現有的LM程式設計基準相比，SWE-bench具有多項優勢。

其中包括，利用使用者提交的問題和解決方案的真實設置、來自12個資源庫的獨特代碼問題為特色的多樣化輸入、基於執行的強大評估框架，以及利用新實例不斷更新基準的能力，且只需極少的人工干預。

LLM任務：編輯代碼庫，解決問題

研究者會給大模型關於問題的文本描述，以及完整的代碼庫。

大模型的任務，就是對代碼庫進行編輯，來解決問題。

在實踐中，研究者將修改表示為補丁檔，它會指定要修改代碼庫中的哪些行以解決問題。

如何評價LLM給出的方案好不好？

研究者會使用unix的補丁程式，將生成的補丁應用於代碼庫，然後執行與任務實例相關的單元和系統測試。

如果補丁應用成功，並且通過所有這些測試，就可以認為LLM建議的方案成功地解決了問題。

基準的度量指標，是已解析任務實例的百分比。

構建SWE-bench的獨特數據集

傳統的NLP基準，通常只涉及短的輸入和輸出序列，並考慮一些專門為基準創建的“人為”問題。

相比之下，為了構建SWE-bench，研究者為數據集注入了獨特的屬性。

比如，採用的是真實的軟體工程任務。

由於SWE-bench中的每個任務實例都包含一個龐大而複雜的代碼庫和相關問題的描述，解決SWE-bench，就需要經驗豐富的軟體工程師擁有的複雜技能和知識，但在傳統的代碼生成基準中，這些通常不被評估。

而且，收集過程可以輕鬆地應用於GitHub上的任何Python存儲庫，幾乎不需要人工干預。

因此，研究者就可以通過不斷提供新的任務實例來擴展SWE-bench，並就訓練日期后創建的問題對語言模型進行評估，這就確保了訓練語料庫中，並沒有包含解決方案。

此外，研究者還保證了基準中不同的長輸入、穩健評估、跨上下文代碼編輯、解決方案的廣泛範圍等。

微調SWE-Llama

接下來，就是到了評估開放模型與專有模型在SWE-bench框架的效果了。

可是研究者發現，現成的CodeLlama微調模型，無法遵循詳細的指令生成整個資源庫範圍內的代碼編輯，通常會輸出佔位元回應或不相關的代碼。

為了評估這些模型的能力，研究人員對70億參數的CodeLlama-Python模型和130億參數的CodeLlama-Python模型進行了監督微調（SFT）。

由此產生的模型是專門的倉庫編輯器，可在消費級硬體上運行，並解決GitHub問題。

### 大模型都敗北

接下來，研究者對GPT-3.5、GPT-4、Cluade 2以及微調的模型進行了評估。

結果發現，所有模型都失敗了——除了發現最簡單的問題外，它們都無法解決所有問題。

比如，Claude 2和GPT-4分別只能解決4.8%和1.7%的任務。

在使用BM25檢索器后，Claude 2的性能進一步下降到1.96%。

**不同資源庫的難度不同。 **

如果按資源庫對性能進行細分，就會發現所有模型在不同資源庫中都表現出相似的趨勢。

儘管如此，每個模型所解決的問題並不一定廣泛重疊。 比如，在oracle設置中，Claude 2和SWE-Llama 13b的性能相當，每個模型分別解決了110個和91個實例。

**難度與上下文長度相關。 **

模型可以在長代碼序列上進行預訓練，但通常要求一次生成單個函數，並提供有限的上下文來確定問題的框架。

如圖所示，可以看到隨著上下文總長度的增加，Claude 2 的性能大幅下降，這種情況在其他模型中也可以觀察到。

即使增加BM25的最大上下文大小，會提高相對於甲骨文檔的召回率，但性能仍然會下降，因為模型根本無法在茫茫詞庫中定位有問題的代碼。

**難度與問題解決日期無關。 **

在表7中，展示了在「oracle」檢索設置下，針對2023年之前或之後創建的 PR，按日期劃分的模型結果。

對於大多數模型來說，除GPT-4外，在這一日期之前或之後的性能差別不大。

另外，研究還發現微調模型對上下文分佈變化很敏感，生成補丁比生成整個檔更容易。 而且大模型傾向於生成更短、更簡單的編輯。

LLM無法替代程序師，但可以加快工作流

有網友對「通才模型」的未來有所憧憬和希望。

沒錯，這也是我的經驗之談。 通才模型還不夠好，沒有足夠寬的上下文長度，除了相對較短的代碼片段外，無法自行編碼。

但我認為這隻是時間問題。 我可以預見，在不久的將來，接受過特定訓練的通才LLM將成為非常專業的模型。

雖然大模型無法替代程式師，但可以加速他們的工作流。 過去需要10人的團隊，現在可能只需要4個人。 這樣就能騰出資源，用於公司籌備的其他目標。

與其為了省錢而解僱員工，不如讓開發人員驚人的速度完成偉大的事業！

參考資料：