---

  新智元報(bào)道  

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

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

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

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

論文地址：https:///abs/2310.06770

在2294個(gè)GitHub真實(shí)問題面前，GPT-4解決隨機(jī)GitHub問題的通過率，竟然是0%！

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

碼農(nóng)會(huì)因?yàn)镃hatGPT而失業(yè)嗎？答案是——目前絕對(duì)不會(huì)。

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

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

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

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

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

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

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

過河拆橋？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如圖所示，模型的任務(wù)（通常是錯(cuò)誤報(bào)告或功能請(qǐng)求）是解決提交到GitHub倉(cāng)庫的問題。

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

然后使用倉(cāng)庫的測(cè)試框架SWE-bench，評(píng)估修改后的代碼庫。

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

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

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

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

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

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

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

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

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

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

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

研究者強(qiáng)調(diào)，這些代碼庫都很大，包含數(shù)千個(gè)文件，而且參考拉取請(qǐng)求通常會(huì)同時(shí)對(duì)多個(gè)文件進(jìn)行修改。

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

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

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

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

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

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

如何評(píng)價(jià)LLM給出的方案好不好？

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

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

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

構(gòu)建SWE-bench的獨(dú)特?cái)?shù)據(jù)集

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

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

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

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

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

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

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

微調(diào)SWE-Llama

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

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

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

由此產(chǎn)生的模型是專門的倉(cāng)庫編輯器，可在消費(fèi)級(jí)硬件上運(yùn)行，并解決GitHub問題。

大模型都敗北

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

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

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

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

不同資源庫的難度不同。

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

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

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

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

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

即使增加BM25的最大上下文大小，會(huì)提高相對(duì)于甲骨文文件的召回率，但性能仍然會(huì)下降，因?yàn)槟Ｐ透緹o法在茫茫詞庫中定位有問題的代碼。

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

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

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

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

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

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

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

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

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