Stack Overflow，已經(jīng)被ChatGPT創(chuàng)飛了！

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

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

不過最近，普林斯頓和芝大的一項研究發(fā)現(xiàn)，LLM想要替代碼農(nóng)，其實沒那么容易。

論文地址：https://arxiv.org/abs/2310.06770

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

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

碼農(nóng)會因為ChatGPT而失業(yè)嗎？答案是——目前絕對不會。

要么適應，要么滅亡

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

然而，自從去年11月OpenAI發(fā)布了ChatGPT后，一切都變了。

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

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

因此，Stack Overflow的流量大大減少，ChatGPT、GPT-4驅動的Github Copilot等AI編程工具，都成為了碼農(nóng)的新去處。

今天，CEO Prashanth Chandrasekar宣布，Stack Overflow裁員一百多人，占員工總數(shù)的28%。

CEO對于裁員的解釋是，宏觀經(jīng)濟壓力下，Stack Overflow在努力走上盈利之路，不斷推出產(chǎn)品創(chuàng)新。

過河拆橋？

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

大語言模型吸空了這些數(shù)據(jù)，卻不回饋任何東西，如果所有數(shù)據(jù)源都被迫趕出了這一業(yè)務，那時會發(fā)生什么？

現(xiàn)在，不少科技公司面前已經(jīng)存在著迫在眉睫的問題：如果程序員減少，人造數(shù)據(jù)就會減少。

如果沒有最新的數(shù)據(jù)，怎么訓練新的AI模型呢？

想用我們的數(shù)據(jù)？拿錢來

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

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

據(jù)悉，OpenAI正在為ChatGPT開發(fā)網(wǎng)絡爬蟲控制，這樣Stack Overflow這樣的網(wǎng)站的數(shù)據(jù)就不會被爬取。

CEO表示，Stack Overflow已經(jīng)表明了立場：誰想用我們的數(shù)據(jù)來訓練LLM，誰就來付費。

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

Stack Overflow首席執(zhí)行官Prashanth Chandrasekar

LLM想取代碼農(nóng)，還早著呢

所以，大語言模型真能取代碼農(nóng)嗎？

普林斯頓和芝大團隊發(fā)現(xiàn)，沒那么容易！

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

結果發(fā)現(xiàn)，像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真正的實力，不要被刷榜評分而陷入擔憂。

有網(wǎng)友表示，這是對「碼農(nóng)是否因編程而失業(yè)」問題的最好的解答。

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

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

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

在這項研究中，作者發(fā)現(xiàn)，當前許多評測大模型編碼能力的基準已經(jīng)趨于飽和，無法評測出大模型真正的實力。

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

然而，現(xiàn)實中軟件工程并非如此簡單。

修復一個bug可能需要瀏覽龐大的資源庫，理解不同文件中函數(shù)之間的關系，又或者在錯綜復雜的代碼中發(fā)現(xiàn)一個小錯誤。

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

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

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

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

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

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

第一階段：倉庫選擇和數(shù)據(jù)搜索。

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

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

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

創(chuàng)建候選任務的方法是，選擇符合以下條件的合并PR：（1）解決了GitHub問題；（2）修改了倉庫的測試文件，這表明用戶很可能貢獻了測試來檢查問題是否已解決。

第三階段：基于執(zhí)行的過濾。

對于每個候選任務，都會應用PR的測試內(nèi)容，并記錄應用PR其他內(nèi)容前后的相關測試結果。

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

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

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

研究者強調(diào)，這些代碼庫都很大，包含數(shù)千個文件，而且參考拉取請求通常會同時對多個文件進行修改。

與現(xiàn)有的LM編程基準相比，SWE-bench具有多項優(yōu)勢。

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

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

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

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

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

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

研究者會使用unix的補丁程序，將生成的補丁應用于代碼庫，然后執(zhí)行與任務實例相關的單元和系統(tǒng)測試。

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

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

構建SWE-bench的獨特數(shù)據(jù)集

傳統(tǒng)的NLP基準，通常只涉及短的輸入和輸出序列，并考慮一些專門為基準創(chuàng)建的“人為”問題。

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

比如，采用的是真實的軟件工程任務。

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

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

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

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

微調(diào)SWE-Llama

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

可是研究者發(fā)現(xiàn)，現(xiàn)成的CodeLlama微調(diào)模型，無法遵循詳細的指令生成整個資源庫范圍內(nèi)的代碼編輯，通常會輸出占位符響應或不相關的代碼。

為了評估這些模型的能力，研究人員對70 億參數(shù)的CodeLlama-Python模型和130億參數(shù)的CodeLlama-Python模型進行了監(jiān)督微調(diào)（SFT）。

由此產(chǎn)生的模型是專門的倉庫編輯器，可在消費級硬件上運行，并解決GitHub問題。

大模型都敗北

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

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

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

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

不同資源庫的難度不同。

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

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

難度與上下文長度相關。

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

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

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

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

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

對于大多數(shù)模型來說，除GPT-4外，在這一日期之前或之后的性能差別不大。

另外，研究還發(fā)現(xiàn)微調(diào)模型對上下文分布變化很敏感，生成補丁比生成整個文件更容易。而且大模型傾向于生成更短、更簡單的編輯。

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

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

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

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

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

與其為了省錢而解雇員工，不如讓開發(fā)人員驚人的速度完成偉大的事業(yè)！