有了ChatGPT，还需要人类程序猿编码吗？
上个月，一项发表在IEEE TSE期刊（Transactions on Software Engineering）上的研究评估了ChatGPT所生成的代码在功能性、复杂性和安全性方面的表现。
结果表明，ChatGPT在生成可用代码方面的能力存在显著差异。
其成功率从0.66%到89%不等，这主要取决于任务的难度、编程语言等多种因素。
具体来说，研究人员测试了GPT-3.5在五种编程语言（包括C、C++、Java、JavaScript和Python）中解决LeetCode测试平台上的728个编码问题，以及应对18个CWE（常见缺陷枚举）场景的能力。
虽然在某些情况下，人工智能能够生成比人类更优质的代码，但分析也揭示了，一些人工智能生成的代码的安全性问题。
论文作者、格拉斯哥大学助理教授Yutian Tang指出，「人工智能代码生成技术在一定程度上能够提升开发效率，实现软件工程的自动化。然而，我们必须认识到这类模型的优势和不足，以便进行合理的应用」。
「通过全面的分析，可以发现ChatGPT生成代码过程中，出现的潜在问题和局限性，进而改进生成技术」。
有网友感到庆幸地发问，因此我还没有被解雇？另一人对此表示，至少不是今天。
还有人指出，这项研究是关于GPT-3.5的评估。要是GPT-4早就在编码能力上大幅提升，Claude 3.5更是如此。
确实，现在我们有了更强大的模型，对于GPT-3.5模型的评估，并没有太大的意义。
Explanation: – 原始文本是中文，无需进行英文解释。 – 原始的HTML结构被保留，只对文本内容进行了合理性的扩写。
从0.66%增长到89%，展现了惊人的反差率
总体而言，ChatGPT在不同编程语言的问题上表现相当不错——特别是在尝试解决2021年之前LeetCode上的编码问题时。
例如，它能够为简单、中等和困难的问题生成可运行的代码，成功率分别约为89%、71%和40%。
然而，当涉及到2021年之后的算法问题时，ChatGPT生成正确运行代码的能力受到影响。即使是简单级别的问题，它有时也无法理解问题的含义。
比如，ChatGPT在生成「简单」编码问题的可运行代码方面的能力，在2021年后从89%下降到52%。
而它在生成「难题」问题的可运行代码方面的能力也在此时间后从40%下降到0.66%。
Tang对比表示，「一个合理的假设是，ChatGPT在2021年之前的算法问题上表现更好的原因是这些问题在训练数据集中经常出现」。
接下里，具体看看研究者们对ChatGPT进行了哪些方面的评估。
实验评估
评估的整体流程如下图所示。
首先为给定的LeetCode问题或CWE场景构造合适的提示并发送给ChatGPT，让它根据提示和上一轮对话的上下文信息给出响应。
之后，研究人员将模型响应中的代码片段提交给LeetCode平台，利用其在线判断功能来检验代码的正确性，CWE漏洞则使用CodeQL进行手动分析。
如果测试结果通过，则生成结束，否则就需要利用LeetCode和CodeQL的反馈继续建立新的提示、输入给ChatGPT，再次进行代码生成。
如果ChatGPT在对话轮数限制（5轮）之内始终没有生成出通过测试的代码，则认为生成任务失败。
生成能够正确实现功能的代码
ChatGPT生成的代码在功能上是否正确？
研究动机：
给定提示，ChatGPT生成相应的文本，这种能力可能会提高开发者的生产力。首先去评估ChatGPT在单轮对话中，自动生成功能正确代码的能力。
研究方法：
Explanation: 根据您的要求，由于原文 “” 是无法进行合理性扩写的内容，我已经将原文直接返回，并保留了原始的HTML结构。
– 让ChatGPT阅读问题描述，在单轮对话中生成相应代码。（最大对话轮数设为1）
– 使用LeetCode平台上的编程问题作为数据集，这个平台提供了广泛的编程问题，涵盖了从基础到高级的各种难度。截止到研究时，共有2500个问题，这些问题涵盖了不同的算法和数据结构，适用于不同层次的编程练习。
– 将LeetCode所有问题分为2021年之前（之前的问题）和2021年之后（之后的问题）两类，因为ChatGPT的训练数据截止于2021年。
– 考虑到2021年之前的问题可能已存在于ChatGPT的训练集中，这可能使代码生成任务退化为简单的数据库查询（即代码复用）。为了进行全面评估，研究中同时考虑了这两类问题。
具体而言，研究人员重点关注LeetCode网站上的算法问题，因为算法问题是该平台上最重要、最多和最多样化的问题。
Bef.problems和Aft.problems的总数分别为1624个和354个。此外，两者的难度分布为难、中、易，比例为1:2:1。具体来说，在Bef.problems中，困难级别的问题占总数的25%，中等难度的问题占50%，而容易的问题也占25%。在Aft.problems中，困难级别的问题占总数的25%，中等难度的问题占50%，而容易的问题也占25%。
在所有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对问题。接着，再让两名研究生分别独立检查这些问题。
通过仔细核对和讨论，结果发现这些类似的问题要么情景相似，但求解目标完全不同；要么情景和条件不同，但可以使用类似的算法（比如动态规划）求解。
经过仔细的人工分析，作者没有发现在任何情况下，Bef.problems可以很容易地重新表述为Aft.problems。
因此，作者认为Aft.problems和Bef.problems之外，对于每个问题，都要求ChatGPT用5种不同的语言生成代码：C、C++、Java、Python3和JavaScript。
此外，他们还使用相同的提示模板为每个 < 问题、语言> 对创建了相应的提示。
Bef.problems和Aft.problems分别共有一千八百七十个和一千七百七十个提示。由于ChatGPT的查询速度有限，研究者将每条提示输入一次，要求生成代码。
然后，研究者将解析后的解决方案，提交给LeetCode进行功能正确性判断，并得到提交状态，包括接受、回答错误、编译错误、超过时间限制和运行错误。
它们分别对应于A、W.A.、C.E.、T.L.E.和R.E。一个问题对应一个唯一的对话，以避免从其他问题触发ChatGPT的推理。
实验中，作者以状态率（SR）来评估 ChatGPT 的代码生成能力。其中
可以理解你的需求是对HTML标记中的内容进行合理性的扩展或保留原始文本。对于你提到的 `
和
`，由于这个内容无法进行合理性的扩写或处理，我将直接返回原始文本，保持HTML结构不变：
和
如果你有其他需要处理的HTML内容或有任何其他问题，请继续告诉我！
分别是根据状态生成的代码片段数和输入的提示数。
所设计的提示模板由4个部分组成：它们分别是<Content>、<Examples>、<Template>和<Command>。
<Content> 用自然语言描述问题，<Examples> 显示功能正确的代码 <input, output> 对，<Template> 指定生成代码的方法签名（method signature），<Command> 要求用特定语言生成代码。
结果：
表1和表2显示，LeetCode对五种编程语言在两个时间段、两种形式下的代码生成结果、SR以及相应的相对频率柱形图。
原文内容已经是合理的中文，不需要进一步扩写。
由于Python3和JavaScript都是动态编程语言，因此这两种语言不包含C.E.。
从总体结果来看，ChatGPT为Bef.problems生成的功能正确代码的准确率明显高于Aft.problems。
具体来说，Bef.problems的五种语言平均正确率（68.41%）比Aft.problems的（20.27%）高出四十八点一四个百分点。
五种语言在不同阶段的代码生成性能差异显著，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%）。
至于Time Limit Exceeded率，虽然数值不高（6%），但测试用例的平均通过率为51%，高于Wrong Answer代码片段。
针对T.L.E.问题，我们准备了难度分为难、中、易三个级别的测试用例。这些测试用例的平均通过率分别为68%、50%和1%。对于易问题，由于其T.L.E.率接近于零，因此可以忽略不计。
由于T.L.E.（Time Limit Exceeded）代码片段的测试用例通过率是部分的，不过生成的代码中最多还有6%在功能上是正确的，尽管它们的时间复杂度可能并不理想。
细分到每种语言，C、C++、Java、Python3和JavaScript的使用率分别为15.38%、19.37%、20.17%、23.93%和22.51%。
此外，图5显示了将五种不同语言与每个问题（仅考虑至少有一个正确解决方案的问题）相结合时，A.率分布（即接受率分布）的情况。这些数据展示了在不同编程语言下，解决这些问题的成功率如何变化，以及各语言之间的表现差异。
从图中可以看出，Medium语言的平均线和中位线都小于或等于0.5，这说明在Medium语言中，整体表现和大部分数据点的表现都较低。而Easy语言的平均线和中位线都大于或等于0.6，这表明在Easy语言中，整体表现和大部分数据点的表现都较高。
对于简单问题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语言的A.率为47.24%，C++的A.率为68.63%，Java的A.率为76.37%，Python3的A.率为75.35%，以及JavaScript的A.率为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的使用率分别为44.75%、48.74%、50.00%和48.80%，彼此接近，且大大超越C的31.28%。
多轮修复功能管用吗
在这个方面，作者想探究ChatGPT在提升代码正确性方面的多轮对话能力如何表现？人类能够「知错就改」，那么语言模型能否也做到？
首先，研究人员对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.问题的复杂程度。SonarQube是一个开源的代码质量检测工具，通过静态代码分析来识别代码中的潜在问题。而cccc是一个计算代码复杂度的工具，能够测量代码的循环复杂度（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时的实验结果。
在温度为零的情况下，进行了十次试验，统计结果显示算法问题和CWE代码场景中非确定性代码的生成情况如下表所示：
其中表26列出了所选的20个CWE代码场景。
此外，作者还研究了非确定性在多轮修复过程中的影响，修复结果如下表所示：
温度设置为0.7，经过5次试验，涉及算法问题的多轮修复过程。
温度设为0，5次试验中算法问题的多轮修复过程。
温度设为0.7，5次试验中算法问题的CWE多轮修复过程。
温度设为0，5次试验中算法问题的CWE多轮修复过程。
温度设为0.7，5次试验中安全代码生成的多轮修复过程。
温度设为零，五次试验中安全代码生成的多轮修复过程。
总之，实验中，当温度设置为0.7时，单轮流程中的代码生成可能会受到ChatGPT非确定性因子的影响，从而导致代码片段在功能正确性、复杂性和安全性方面出现差异。
为了减少ChatGPT在单一交互过程中的不确定性，一种可能的方法是将温度设置为0。
然而，在多轮修复过程中，无论温度设置为0.7还是0，ChatGPT固定的代码片段在功能正确性、复杂性和安全性方面都可能存在差异。
