ChatGPT无法取代人类程序员！ IEEE 35页论文测出艰巨编码正确率仅为0.66%

有了ChatGPT，还须要人类程序猿编码吗？

上个月，一项宣布在IEEE TSE期刊（Transactions on Software Engineering）上的钻研评价了ChatGPT所生成的代码在配置性、复杂性和安保性方面的表现。

结果显示，ChatGPT生成可用代码的才干差异很大。

其成功率从0.66%到89%不等，这关键取决于义务的难度、编程言语等多种要素。

论文地址：

详细来说，钻研人员测试了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的非确定性输入如何影响代码生成？

如下表所示，表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固定的代码片段在配置正确性、复杂性和安保性方面都或许存在差异。

原文链接:​ ​​ ​