三場PK，暴露了ChatGPT的層次！

作者：徐杰承 2023-02-14 10:30:07

程序員就要失業(yè)啦，快轉(zhuǎn)行吧！這大概是用戶們見識(shí)過ChatGPT能自動(dòng)生成代碼后最常對程序員們提起的一句話了。

?作者 | 徐杰承

審校 | 言征

正當(dāng)谷歌與微軟為搶占AI搜索引擎市場爭得不可開交時(shí)，一部分程序員卻無心吃瓜。因?yàn)樗麄円呀?jīng)提前意識(shí)到了，當(dāng)這場搜索之戰(zhàn)落下帷幕后，軟件巨頭們將繼續(xù)攜帶著ChatGPT或其他人工智能生成工具，向著自動(dòng)編碼的藍(lán)海大步進(jìn)發(fā)。到時(shí)別說是吃瓜，連自己的飯碗都有可能受到威脅。

在如今的自動(dòng)編碼領(lǐng)域，最成熟且最為人熟知的兩款A(yù)I，正是近來風(fēng)頭無兩的ChatGPT以及微軟于去年6月上線的AI編程工具Copilot，而這“二位”也正是現(xiàn)階段最被寄予厚望將取代程序員的當(dāng)紅明星。那么就目前而言，ChatGPT與Copilot的編碼能力究竟如何，是否真如傳言所說將在短期內(nèi)取代所有初級(jí)甚至部分中級(jí)開發(fā)者呢？

日前，一位美國技術(shù)專家利用多個(gè)JavaScript函數(shù)需求，測試了ChatGPT與Copilot在數(shù)據(jù)處理與算法生成方面的能力。接下來，就讓我們一起通過這些結(jié)果來了解一下目前AI在編碼方面的真實(shí)水平，然后捫心自問，自己是否真的將會(huì)被取代呢？

1、JavaScript函數(shù)接受可變數(shù)量數(shù)組并返回交集

第一場測試中，測試者首先要求ChatGPT和Copilot生成一個(gè)JavaScript函數(shù)，具體條件為：需要能接受可變數(shù)量的數(shù)組并返回它們的交集。

OpenAI ChatGPT：

微軟 Copilot：

對此ChatGPT所生成的函數(shù)假定提供少于一個(gè)數(shù)組是無效的。通過使用Set，ChatGPT確保結(jié)果中不存在重復(fù)項(xiàng)。交集應(yīng)該是一個(gè)集合操作，重復(fù)的應(yīng)該被刪除。Copilot代碼則返回了一個(gè)可能包含重復(fù)項(xiàng)的數(shù)組。

而ChatGPT和Copilot都沒有按照長度對原始參數(shù)進(jìn)行升序排序，這是一個(gè)微不足道的優(yōu)化，卻能帶來巨大的改變。如果任何參數(shù)的長度為0，則沒有交集；不管怎樣，它縮短了循環(huán)，因?yàn)樽畲蠼患c最短數(shù)組參數(shù)相同。

隨后，測試者要求ChatGPT和Copilot提高函數(shù)的執(zhí)行效率。

OpenAI ChatGPT：

微軟 Copilot：

面對以上問題，Copilot生成了與此前請求相同的代碼。而ChatGPT給出了不同的答案并添加了評論，稱該函數(shù)不會(huì)像預(yù)期那樣對對象起作用，但這項(xiàng)描述并不準(zhǔn)確。

而后，測試者利用相同方式檢驗(yàn)了ChatGPT與Copilt所提供的兩個(gè)最快交集庫所生成代碼的運(yùn)行效率和內(nèi)存消耗情況。

ChatGPT所生成代碼執(zhí)行時(shí)所占用的CPU較低，但運(yùn)行效率并不理想，而Copilot生成代碼雖然對于堆的使用量較低，但CPU占用率和運(yùn)行效率較差。

總而言之，在這項(xiàng)測試中ChatGPT與Copilot都無法生成足夠高效的代碼；ChatGPT在該問題中給出的假設(shè)有誤；而Copilot所生成的函在參數(shù)包含重復(fù)值時(shí)，會(huì)生成不產(chǎn)生集合的代碼。

2、JavaScript函數(shù)：笛卡爾積

第二場測試，則是要求ChatGPT與Copilot完成一個(gè)笛卡爾積的JavaScript函數(shù)。

OpenAI ChatGPT：

微軟 Copilot：

熟悉笛卡爾積的人都會(huì)知道，從內(nèi)存利用率和性能的角度看，ChatGPT和Copilot所生成的結(jié)果都是爆炸性的。簡單的實(shí)現(xiàn)將消耗大量的RAM用以存儲(chǔ)所有的組合，并且直到所有組合生成后才能返回結(jié)果。ChatGPT和Copilot所生成的函數(shù)都存在這些缺點(diǎn)。

隨后，測試者再次要求ChatGPT和Copilot提高函數(shù)效率。

OpenAI ChatGPT：

微軟 Copilot：

針對這項(xiàng)需求，ChatGPT的表現(xiàn)令人感到驚喜。但在整體函數(shù)中，ChatGPT犯了一個(gè)嚴(yán)重的錯(cuò)誤，yield [item,...result]并不在生成器內(nèi)部，而是在一個(gè)recursion之中。而Copilot則直接無視了需求變化，返回了與此前相同的結(jié)果。

在代碼運(yùn)行效率及內(nèi)存消耗情況方面，ChatGPT和Copilot的表現(xiàn)則如下表所示。

總體看來，ChatGPT與Copilot均無法生成笛卡爾積函數(shù)的正確代碼；ChatGPT會(huì)作出可能無效的假設(shè)，例如需要兩個(gè)參數(shù)；雖然檢測結(jié)果顯示ChatGPT生成的代碼內(nèi)存效率更高，但其根本無法順利運(yùn)行。

3、JavaScript函數(shù)儲(chǔ)存對象與原始參數(shù)

第三回合，測試人員要求二者生成能夠存儲(chǔ)對象和原始參數(shù)的JavaScript函數(shù)。

OpenAI ChatGPT：

微軟 Copilot：

對此，ChatGPT與Copilot均生成了較為低效的代碼，先進(jìn)行字符串轉(zhuǎn)化再進(jìn)行字符串比較的效率很差，并且會(huì)大量消耗內(nèi)存。

雖然有一些JavaScript值無法被轉(zhuǎn)化為字符串，例如Infinity和NaN。但遺憾的是，JavaScript JSON規(guī)范是在數(shù)據(jù)科學(xué)和微服務(wù)時(shí)代之前定義的，而這些值的存在主要是為了在代碼出現(xiàn)某些錯(cuò)誤條件時(shí)，程序還可以用特定的值來表示所產(chǎn)生結(jié)果。

最后，為驗(yàn)證函數(shù)效率，測試者將ChatGPT與Copilot所生成的代碼與常用緩存工具nano-memoize 和micro-memoize進(jìn)行了橫向?qū)Ρ龋褂靡韵麓a生成第12個(gè)斐波那契數(shù)列。

其中nano-memoize是運(yùn)行效率最高的，幾乎是ChatGPT和Copilot所生成代碼運(yùn)行效率的兩倍，并且其所使用的內(nèi)存也是最低的，而micro-memoize的表現(xiàn)則可以說緊隨其后。雖然在CPU利用率方面，Copilot表現(xiàn)不錯(cuò)，但綜合來看，ChatGPT和Copilot在這場測試中的表現(xiàn)依然不足以擊敗一個(gè)成熟的程序員。

4、總結(jié)與預(yù)測

通過這三場測試，我們不難發(fā)現(xiàn)，雖然使用ChatGPT和Copilot所生成的代碼肯定具有一定價(jià)值。但就目前而言，無論是ChatGPT還是Copilot，均無法通過簡單的任務(wù)描述生成足夠準(zhǔn)確且高效的代碼，甚至在某些情況下，它們也會(huì)犯下一些非常糟糕的錯(cuò)誤。在得知這個(gè)結(jié)果后，不少開發(fā)者也分分表示：感覺自己還能再堅(jiān)持幾年。

對于如今的企業(yè)或是程序員而言，如果你希望利用ChatGPT、Copilot或是其他代碼生成工具幫助自己完成一些簡單的輔助編碼任務(wù)以加速構(gòu)建，那么你完全能夠得到足夠的支持。但如果希望依靠它們徹底解放研發(fā)，那么你可能需要花大價(jià)錢為其配備一整支強(qiáng)大的調(diào)試團(tuán)隊(duì)。

然而即便結(jié)果如此，今天的我們?nèi)圆荒芎鲆旳I在自動(dòng)編碼領(lǐng)域的潛力以及這些系統(tǒng)背后強(qiáng)大的軟件企業(yè)。可以肯定的是，伴隨著訓(xùn)練量與技術(shù)成熟度的增長，未來的自動(dòng)編碼工具將繼續(xù)擴(kuò)充其在不同場景的業(yè)務(wù)數(shù)據(jù)，并逐步嘗試解決一些更專業(yè)、更場景化的實(shí)際任務(wù)。

最后，對于“AI到底能否在未來取代程序員”這個(gè)問題，目前最可靠的答案，也許就是前阿里以色列機(jī)器視覺實(shí)驗(yàn)室負(fù)責(zé)人Itamar Friedman在一次采訪中所做出的預(yù)測了——“在未來的10到20年內(nèi)，人工智能系統(tǒng)將可能使非程序員的創(chuàng)造者使用自然語言指令進(jìn)行0錯(cuò)誤的開發(fā)，屆時(shí)我們的世界仍會(huì)需要大量的程序員，但其角色將可能會(huì)發(fā)生難以預(yù)測的變化。”