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è)嗎？答案是——目前絕對不會。

要么適應(yīng)，要么滅亡

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

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

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

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

因此，Stack Overflow的流量大大減少，ChatGPT、GPT-4驅(qū)動的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è)務(wù)，那時會發(fā)生什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)果發(fā)現(xiàn)，像GPT-4、Claude 2這樣領(lǐng)先的大模型，解決實際問題的能力，都不過5%。

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

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

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

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

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

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

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

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

SWE-bench：專為編碼模型設(shè)計

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LLM任務(wù)：編輯代碼庫，解決問題

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

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

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

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

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

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

基準(zhǔn)的度量指標(biāo)，是已解析任務(wù)實例的百分比。

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

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

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

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

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

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

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

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

微調(diào)SWE-Llama

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

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

為了評估這些模型的能力，研究人員對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)的模型進行了評估。

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

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

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

不同資源庫的難度不同。

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

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

難度與上下文長度相關(guān)。

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

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

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

難度與問題解決日期無關(guān)。

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

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

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

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

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

沒錯，這也是我的經(jīng)驗之談。通才模型還不夠好，沒有足夠?qū)挼纳舷挛拈L度，除了相對較短的代碼片段外，無法自行編碼。

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

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

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