普林斯頓芝大驚人發現：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想要替代碼農，其實沒那麼容易。
論文網址：https://arxiv.org/abs/2310.06770
在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真正的實力，不要被刷榜評分而陷入擔憂。
有網友表示，這是「碼農是否因程式設計而失業」問題的最好的解答。
終於有人為程式碼模型製作了一個真正的eval資料集，HumEval只是LLM的leetcode面試。我們都知道，這對人類工程師來說是個錯誤的衡量標準。不到4%聽起來是對的，因為大模型離完全自主還很遠。
那麼，SWE-bench評估大模型能力的結果，事實真是如此嗎？
SWE-bench：專為編碼模型設計
在這項研究中，作者發現，目前許多評測大模型編碼能力的基準已經趨於飽和，無法評測出大模型的真正實力。
例如，HumanEval中，挑戰問題太簡單，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架構的效果了。
可是研究者發現，現成的Co DELL ama微調模型，無法遵循詳細的指令產生整個資源庫範圍內的程式碼編輯，通常會輸出佔位符回應或不相關的程式碼。
為了評估這些模型的能力，研究人員對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個人。這樣就能騰出資源，用於公司籌備的其他目標。
與其為了省錢而解僱員工，不如讓開發人員驚人的速度完成偉大的事業！
參考資料：