編輯：編輯部
【新智元導讀】6月，IEEE刊登了一篇對ChatGPT代碼生成任務進行系統評估的論文，資料集就是程式員們最愛的LeetCode題庫。研究揭示了LLM在代碼任務中出現的潛在問題和能力局限，讓我們能夠對模型做出進一步改進，并逐漸了解使用ChatGPT寫代碼的最佳姿勢。
有了ChatGPT，還需要人類程式猿編碼嗎？
上個月，一項發表在IEEE TSE期刊（Transactions on Software Engineering）上的研究評估了ChatGPT所生成的代碼在功能性、複雜性和安全性方面的表現。
結果顯示，ChatGPT生成可用代碼的能力差異很大。
其成功率從0.66%到89%不等，這主要取決于任務的難度、程式設計語言等多種因素。
論文位址：https://ieeexplore.ieee.org/document/10507163
具體來說，研究人員測試了GPT-3.5在5種程式設計語言（C、C++、Java、JavaScript和Python）中，解決LeetCode測試平台上的728個編碼問題，以及應對18個CWE（常見缺陷枚舉）場景的能力。
雖然在某些情況下，AI能夠生成比人類更優質的代碼，但分析也揭示了，一些AI生成代碼的安全性問題。
論文作者、格拉斯哥大學助理教授Yutian Tang指出，「AI代碼生成一定程度上，可以提升開發效率，自動化軟體工程。然而，我們必須認識這類模型優勢和不足，以便合理應用」。
「通過全面的分析，可以發現ChatGPT生成代碼過程中，出現的潛在問題和局限性，進而改進生成技術」。
有網友慶幸地發出疑問，是以我還沒有被解雇？另一人對此表示，至少不是今天。
還有人指出，這項研究是關于GPT-3.5的評估。要是GPT-4早就在編碼能力上大幅提升，Claude 3.5更是如此。
确實，現在我們有了更好的模型，對于GPT-3.5模型的評估，并沒有太大的意義。
0.66%-89%，驚人反差率
總體而言，ChatGPT在不同程式設計語言的問題上表現相當不錯——特别是在嘗試解決2021年之前LeetCode上的編碼問題時。
例如，它能夠為簡單、中等和困難的問題生成可運作代碼，成功率分别約為89%、71%和40%。
然而，當涉及到2021年之後的算法問題時，ChatGPT生成正确運作代碼的能力受到影響。即使是簡單級别的問題，它有時也無法了解問題的含義。
比如，ChatGPT在生成「簡單」編碼問題的可運作代碼方面的能力，在2021年後從89%下降到52%。
而它在生成「困難」問題的可運作代碼方面的能力也在此時間後從40%下降到0.66%。
Tang對比表示，「一個合理的假設是，ChatGPT在2021年之前的算法問題上表現更好的原因是這些問題在訓練資料集中經常出現」。
接下裡，具體看看研究者們對ChatGPT進行了哪些方面的評估。
實驗評估
評估的整體流程如圖2所示。
首先為給定的LeetCode問題或CWE場景構造合适的提示并發送給ChatGPT，讓它根據提示和上一輪對話的上下文資訊給出響應。
之後，研究人員将模型響應中的代碼片段送出給LeetCode平台，利用其線上判斷功能來檢驗代碼的正确性，CWE漏洞則使用CodeQL進行手動分析。
如果測試結果通過，則生成結束，否則就需要利用LeetCode和CodeQL的回報繼續建立新的提示、輸入給ChatGPT，再次進行代碼生成。
如果ChatGPT在對話輪數限制（5輪）之内始終沒有生成出通過測試的代碼，則認為生成任務失敗。
功能性正确代碼生成
ChatGPT生成的代碼在功能上是否正确？
研究動機：
給定提示，ChatGPT生成相應的文本，這種能力可能會提高開發者的生産力。首先去評估ChatGPT在單輪對話中，自動生成功能正确代碼的能力。
研究方法：
- 讓ChatGPT閱讀問題描述，在單輪對話中生成相應代碼。（最大對話輪數設為1）
- 使用LeetCode平台上的程式設計問題作為資料集，截止研究時，有2500個難度不等的問題。
- 将LeetCode所有問題分為2021年之前（Bef.problems）和2021年之後（Aft.problems）兩類，因為ChatGPT的訓練資料截止于2021年。
- 考慮到2021年之前的問題可能已存在于ChatGPT的訓練集中，這可能使代碼生成任務退化為簡單的資料庫查詢（即代碼複用）。為了進行全面評估，研究中同時考慮了這兩類問題。
具體而言，研究人員重點關注LeetCode上的算法問題，因為算法問題是該平台上最重要、最多和最多樣化的問題。
Bef.problems和Aft.problems的總數分别為1624個和354個。此外，兩者的難度分布為難、中、易，比例為1:2:1。
在所有Bef.problems中，作者随機抽取了374個問題，其數量與Aft.problems相似，難度分布也與Aft.problems相同。
同樣，在354個Aft.problems和Bef.problems中，難、中、易問題的數量比例也是1:2:1，與LeetCode平台上所有問題的難度分布一緻。
此外，研究人員還檢查了Bef.problems和Aft.problems之間是否存在顯著差異。
如果Aft.problems隻是Bef.problems的重構，那麼ChatGPT很可能可以輕松解決這些問題，這可能會影響實驗結果在區分時間段方面的可靠性。
論文中，作者總共找到了142對問題。然後，再讓2名研究所學生獨立檢查這些問題對。
通過仔細核對和讨論，結果發現這些相似的問題要麼情景相似，但求解目标完全不同；要麼情景和條件不同，但可以使用類似的算法（如動态程式設計）求解。
經過仔細的人工分析，作者沒有發現在任何情況下，Bef.problems可以很容易地重新表述為Aft.problems。
是以，作者認為Aft.problems和Bef.problems之外，對于每個問題，都要求ChatGPT用5種不同的語言生成代碼：C、C++、Java、Python3和JavaScript。
此外，他們還使用相同的提示模闆為每個 < 問題、語言> 對建立了相應的提示。
Bef.problems和Aft.problems分别共有1,870和1,770個提示。由于ChatGPT的查詢速度有限，研究者将每條提示輸入一次，要求生成代碼。
然後，研究者将解析後的解決方案，送出給LeetCode進行功能正确性判斷，并得到送出狀态，包括接受、回答錯誤、編譯錯誤、超過時間限制和運作錯誤。
它們分别對應于A.、W.A.、C.E.、T.L.E.和R.E.。一個問題對應一個唯一的對話，以避免從其他問題觸發ChatGPT的推理。
實驗中，作者以狀态率（SR）來評估 ChatGPT 的代碼生成能力。其中
和
分别是根據狀态生成的代碼片段數和輸入的提示數。
提示：
所設計的提示模闆由4個部分組成：它們分别是<Content>、<Examples>、<Template>和<Command>。
<Content> 用自然語言描述問題，<Examples> 顯示功能正确的代碼 <input, output> 對，<Template> 指定生成代碼的方法簽名（method signature），<Command> 要求用特定語言生成代碼。
結果：
表1和表2顯示，LeetCode對五種程式設計語言在兩個時間段、兩種形式下的代碼生成結果、SR以及相應的相對頻率柱形圖。
由于Python3和JavaScript都是動态程式設計語言，是以這兩列不包含C.E.。
從總體結果來看，ChatGPT為Bef.problems生成的功能正确代碼的A.率明顯高于Aft.problems。
具體來說，Bef.problems的五種語言平均正确率（68.41%）比Aft.problems的（20.27%）高出 48.14%。
五種語言在不同階段的代碼生成性能差異顯著，P值為0.008，效應大小值為1。
對于Aft.problems，總體正确率低于25%，其中難、中、易問題的正确率分别為0.66%、13.90%和52.47%。
用Holm-Bonferroni校正程式調整的P值和五種語言不同難度之間的效應大小值分别小于0.05和等于1。
結果表明，面對Aft.problems，随着問題難度的增加，ChatGPT在功能上正确生成代碼的能力明顯下降。
此外，即使是簡單的問題，它也隻能正确回答一半。
在這五項/四項名額中，W.A.率是所有語言中最高的一項，達到58%。
此外，每個W.A.代碼片段平均有109個測試用例，而ChatGPT生成的代碼隻能通過其中的25%。
難題、中難題和簡單難題的測試用例通過率分别為20.90%、21.03%和38.41%。是以，無論難度如何，生成代碼的語義都與相應問題描述的邏輯有很大差異。
此外，C.E.率和R.E.率也都達到了16%，而且難題和中難題的C.E.率明顯高于簡單難題。
ChatGPT生成的中難題代碼，更容易出現編譯和運作時錯誤。比如，圖4中顯示生成的函數cmpfunc，在調用前沒有聲明。文法錯誤隻占這些錯誤的一小部分（3.7%）。
至于T.L.E.率，雖然數值不高（6%），但測試用例的平均通過率為51%，高于W.A.代碼片段。
T.L.E.問題的難、中、易三個難度級别的測試用例，平均通過率分别為68%、50%和1%（易問題由于其T.L.E.率接近0%，可以忽略不計）。
由于T.L.E.代碼片段的測試用例通過率是部分的，不過生成的代碼中最多還有6%在功能上是正确的，盡管它們的時間複雜度可能并不理想。
細分到每種語言，C、C++、Java、Python3和JavaScript的A.率分别為15.38%、19.37%、20.17%、23.93%和22.51%。
此外，圖5顯示了将五種不同語言與每個問題（僅考慮至少有一個正确解決方案的問題）相結合的A.率分布（接受率分布）。
從圖中可以看出，Medium語言的平均線和中位線都≤0.5，而Easy語言的平均線和中位線都≥0.6。
對于簡單問題ChatGPT更容易将生成的代碼泛化到不同的語言中。簡單問題和中等問題的中位數和均值分别為0.4和0.5。
對于Bef. Problems問題方面，難、中、易問題的正确率分别為40.13%、70.95%和89.80%，遠高于Aft. problems，但不同難度之間仍存在顯著差異。
用Holm-Bonferroni校正程式調整後的P值和難與中、難與易之間的效應大小值分别小于0.05和大于0.9。
五種語言中，中等難度和簡單難度之間的調整後P值和效應大小值分别為0.056和0.76。
ChatGPT在解決2021年之前訓練集中可能出現的問題時，表現更好，尤其是中等難度和簡單難度的問題。
解決難題的正确率提高了40%，但仍低于50%，這表明ChatGPT生成邏輯複雜問題代碼的能力仍有很大的提升空間。
總體正确率下降到 17.03%，難、中、易問題的正确率分别為32.89%、15.05%和6%。
生成的代碼仍能通過平均112個測試用例中的25%。難、中、易問題的測試用例通過率分别為19.19%、31.12%和47.32%。
後兩者都提高了10%，這表明ChatGPT對Bef. Problems有更好的了解力。
不過，C.E.率和R.E.率仍達到13%，接近Aft. problems的16%，兩個階段之間的P值和效應大小值分别為0.328和0.3125，且困難問題通過率最高，中難度問題通過率次之。
編譯錯誤和運作時錯誤與Aft. problems類似，例如，圖6所示代碼用于重塑給定的二維矩陣，但在第15行引發了運作時錯誤，該行為*returnColumnSizes配置設定了錯誤大小的記憶體。
至此，T.L.E.率降至1.87%，測試用例平均通過率為74%。
接下來，再細分到每種語言，C、C++、Java、Python3和JavaScript的A.率分别為47.24%、68.63%、76.37%、75.35%和74.44%。
後四種語言的A.率值彼此接近，且大大高于C（最低級别語言）的A.率值，至少高出20%。
圖 7 顯示的是與圖 5 相同的Bef. Problems。從圖中可以看出，中等題和簡單題的平均線和中位線都≥0.75，而且它們的中位數和平均值之間的差異比之前的Aft. problems要小一半。
此外，有難度的平均線和中位線都≥ 0.55。對于Bef. Problems，ChatGPT更容易将代碼擴充到不同的語言中。
ChatGPT接受的問題的人類平均接受率為55%，而ChatGPT未接受的問題的人類平均接受率為47%。
總而言之，通過實驗，ChatGPT在功能性正确代碼生成任務上，比起Aft. problems，更加擅長解決不同程式設計語言中的Bef. Problems。
尤其是，前者的平均正确率比後者高出48.14%。此外，不同的難度也會影響基于ChatGPT的代碼生成。
對于兩個階段的問題，ChatGPT都能生成運作時間和記憶體開銷小于至少50%的人類解決方案的代碼。
無論哪個階段的問題，ChatGPT生成的代碼出現編譯或運作時錯誤的機率都差不多，平均為14.23%。
在所有問題中，C++、Java、Python3和JavaScript的A.率值分别為44.75%、48.74%、50.00%和48.80%，彼此接近，且大大超越C的31.28%。
多輪修複功能管用嗎
在這個方面，作者想探究ChatGPT支援的多輪對話能力在改進代碼正确性上究竟表現如何？人類能夠「知錯就改」，LLM可以嗎？
首先，研究人員對ChatGPT生成的157段代碼的錯誤類型進行了分析，可以大緻分為以下幾類：
- 細節錯誤（WD）：代碼細節上的錯誤一般源于誤解題意，或者代碼與問題了解不一緻，但大體邏輯基本正确，是以這類錯誤很容易被修複。
- 誤解某些内容（MCC）：生成代碼沒有滿足給定問題的主要條件，使用的算法合适，但需要修改其核心。
- 誤解問題（MP）：指ChatGPT完全錯解了題意，這是最難修複的一種情況，代碼需要完全重寫，
将錯誤資訊回報給ChatGPT的方式依舊延續了圖3所示的格式，包括原始問題、生成代碼片段、LeetCode的報錯資訊以及相應指令。
進行不超過5輪的對話修複後，得到了表5所示的結果。
可以看到，157個問題中能通過自動化修複的隻有25個，其中16個屬于簡單模式，困難問題的錯誤答案幾乎不可能被修複。
如果把對話輪數的上限增加到10輪呢？結果依舊不樂觀。
從157個問題中随機選出10個，結果隻有其中2個能在10輪内成功修複，剩下的8個依舊無法通過。這能讓研究人員進一步分析ChatGPT很難自動修複的原因。
作者認為，一方面，ChatGPT缺乏掌握邏輯細節的能力；另一方面，在需要複雜邏輯推理的問題中，生成代碼往往偏離問題的實際含義，這即使對于人類程式員也很難修複。
代碼複雜度
代碼的複雜性對于可讀性、可維護性以及整體品質來說，都是一個重要的影響因素。想象一下，如果ChatGPT對簡單的排序問題都生成出了你很難看懂的代碼，那會大大拉低使用體驗。
作者利用了SonarQube和cccc兩個名額來評估LeetCode資料集中Bef.問題的複雜程度，并評估響應生成代碼的循環複雜度（cyclomatic complexity）和認知複雜度（cognitive complexity）。
循環複雜度會計算執行時線性獨立路徑的數量，進而展現源代碼的測試難度。認知複雜度則從人類角度衡量了解、推理一段代碼的難度。
由于以上量化标準不夠直覺，研究人員還同時評估了人類編寫的C++和Python3的LeetCode問題解答來與ChatGPT進行比較。
圖20的對比中可以看出，C代碼的複雜度最高，C++、Java和JavaScript次之并基本處于同一水準，Python3是最不複雜的，這與我們的固有認知基本吻合。
此外，與人類相比，ChatGPT生成的代碼雖然複雜度稍高，但差距并不明顯。
随着LeetCode問題難度逐漸升高（表16），無論是人類還是ChatGPT，低複雜度代碼的占比都會逐漸降低，複雜度被分類為「高」和「非常高」的占比也随之逐漸提高，這種趨勢也是類似的。
然而，不好的消息是，ChatGPT的多輪修複功能似乎沒法讓代碼更簡潔，多數情況下會維持甚至提高代碼的複雜
性，這或許也是多輪修複功能效果不理想的原因之一。
代碼安全性
由于ChatGPT訓練時可能學習到了各種各樣的内容，包括品質較低、易受攻擊的代碼，是以評估生成代碼的安全性也非常重要。
由于LeetCode的算法代碼通常專注于解決特定的邏輯或計算問題，并不涉及管理系統資源、網絡通信等通常有敏感安全問題的操作，是以在這部分的評估中，論文同時采取了兩種路徑。
1)利用CodeQL對LeetCode答案的所有C、C++和Java代碼進行漏洞檢測，針對MITRE Top25中的5個CWE問題，包括指針和記憶體相關的共30個查詢。
2)針對MITRE Top25中的18個CWE問題，每個問題提供3種上下文場景，給ChatGPT「挖坑」，要求它補全代碼，再用CodeQL自動檢測看是否确實出現了相應問題。
在第一個測試中（表18），ChatGPT表現良好，91.8%的錯誤集中在MissingNullTest這一類，其餘的漏洞的出現頻次則一般不超過5次。
但仍要注意的是，ChatGPT在CWE 787，即「越界寫入」問題上表現不佳，這可能會導緻潛在的代碼漏洞。
而且，由于這些漏洞的修複比較簡單，是以在給定錯誤資訊并要求生成修複代碼後， ChatGPT也能較好完成任務。
要求ChatGPT修複CWE-787問題的提示模闆
在第二個測試——安全代碼生成方面，ChatGPT共生成了2983（99.07%）個有效代碼片段，其中994個存在安全漏洞，占比達到33.32%。
而且，C語言中的易受攻擊片段的百分比（51.64%）遠遠高于Python3（17.08%），這有可能是由于C代碼本身就對程式的記憶體安全提出了更高的要求，也可能源于訓練資料中C和Python3代碼的品質差距。
多輪修複功能依舊表現出色，89.4%的漏洞都能在給出CWE資訊後成功解決，比如溢出、資料洩露、不安全記憶體操作、未經身份驗證通路等相關問題。
ChatGPT非确定性
ChatGPT的非确定性輸出如何影響代碼生成？
如下表所示，表22和表23分别列出了所選算法問題和溫度為0.7時的實驗結果。
在溫度為0的條件下，10次試驗中，算法問題和CWE代碼場景的非确定性代碼生成統計結果如表24、表25和表26所示。
其中表26列出了所選的20個CWE代碼場景。
此外，作者還研究了非确定性對多輪修複過程的影響，修複結果如表27-32所示。
溫度設為0.7，5次試驗中算法問題的多輪修複過程。
溫度設為0，5次試驗中算法問題的多輪修複過程。
溫度設為0.7，5次試驗中算法問題的CWE多輪修複過程。
溫度設為0，5次試驗中算法問題的CWE多輪修複過程。
溫度設為0.7，5次試驗中安全代碼生成的多輪修複過程。
溫度設為0，5次試驗中安全代碼生成的多輪修複過程。
總之，實驗中，當溫度設定為0.7時，單輪流程中的代碼生成可能會受到ChatGPT非确定性因子的影響，進而導緻代碼片段在功能正确性、複雜性和安全性方面出現差異。
要減輕ChatGPT在單輪過程中的非确定性，一種可能的政策是将溫度設定為0。
然而，在多輪修複過程中，無論溫度設定為0.7還是0，ChatGPT固定的代碼片段在功能正确性、複雜性和安全性方面都可能存在差異。
參考資料：
https://ieeexplore.ieee.org/document/10507163
https://spectrum.ieee.org/chatgpt-for-coding
https://arxiv.org/abs/2308.04838