论文阅读-Automated Repair of Programs from Large Language Models
文章主旨：研究了Codex自动生成的程序中的错误，并探讨了现有的程序修复（APR）工具以及新发布的Codex-e是否能够修复自动生成的有缺陷的程序。
现在基于大语言模型，输入自然语言，生成代码的应用非常普遍。但是生成的代码正确率很低，文章以GPT-3模型的后代-Codex模型，为例，试图利用自动化程序修复（APR）技术来修复Codex产生的代码错误。
自动化修复技术接受一个有缺陷的程序和一个正确性规范，通过稍稍修改程序使其满足给定的规范来生成一个固定的程序。典型的修复工具通过推理程序语义与给定的规范来生成补丁。例如，基于语义的修复工具（如SemFix、Angelix）通过使用符号执行和基于搜索的修复工具（如Gen-Prog、TBar）在预定义的补丁中搜索正确的补丁。
本文实验方向
本文探讨了两个方向来修复语言模型生成的代码的错误
1.现有的APR技术（TBar和Recoder）
2.研究探讨了使用Codex-e作为自动化程序修复工具的可能性。
「利用OpenAI最近发布的Codex编辑模式（这个新功能可以使现有的程序内容发生改变。）」
设计了三种构建Codex-e编辑指令的策略：
- Codex-e 𝑏𝑢𝑔：告知Codex-e存在程序中的错误并请求其修复。
- Codex-e 𝑙𝑖𝑛𝑒：利用现有的自动程序修复技术，通过统计故障定位（Ochiai）获取可能修复行的序列，作为修复提示提供给Codex-e。
- Codex-e 𝑠𝑡𝑚：直接使用可疑语句而不是可疑行号作为指令，进一步探究Codex-e的响应。
文章关键内容概述
RQ1: WHAT MISTAKES DO AUTO-GENERATED CODE USUALLY MAKE?
- 1. 先前关于基于搜索的自动化程序修复技术的研究表明，自动生成的修补程序很可能表现出某些反模式，这些反模式会导致生成无意义的修补程序。
2. 直觉上，像Codex这样的大型语言模型自动生成的代码也可能包含反模式。
3. 因此，分析了Codex生成的代码是否犯了LMDefects中的相同常见错误。
4. 对于Codex要解决的LMDefects中的编程任务，首先运行五个自动生成的解决方案在公共测试上，然后将那些通过公共测试的解决方案提交到LeetCode在线判定平台进行私有测试验证。
5. 如果Codex生成的五个自动解决方案𝑆都不能通过所有的测试（公共和私有测试），则认为𝑆是未解决的解决方案。
6. 如果没有一个未解决的解决方案𝑆对一个编程任务，则认为该编程任务已解决。
7. Codex在简单和中等难度级别上分别产生37个和5个解决问题的编程任务，研究剩余71个未解决的编程任务中355个导致编译错误或测试失败的未解决问题𝑆的错误。
8. 对于Codex生成的每个未解决的解决方案𝑆𝑏𝑢𝑔𝑔𝑦，我们首先参考其他相同编程任务的解决方案来获取修复提示，然后通过对现有代码进行最少的修改来构建修复错误的简单修补程序。
9. 我们的目标是构建每个未解决问题𝑆的“基准修补程序”𝑆𝑓𝑖𝑥𝑒𝑑，以获得𝑆𝑏𝑢𝑔𝑔𝑦和𝑆𝑓𝑖𝑥𝑒𝑑之间的“差异”。
10. 这个“差异”代表了Codex自动生成的程序中的错误或错误。
11. 根据这个“差异”，我们手动将每个未解决的解决方案归类到以下类别中：对齐算法：使用的算法与任务描述中给出的要求不一致。
12. 表2展示了未解决解决方案的缺陷分类，以及每个缺陷的示例（“示例”列）和编程任务的难度级别（“简单”和“中等”列），以解释每个缺陷。
13. 为了更容易比较缺陷类型，我们基于Codeflaws中使用的类别（一个包含编程竞赛参与者错误提交的基准）导出缺陷分类。
14. 与Codeflaws的缺陷分类相比，我们意识到自动生成的代码的错误类型与Codeflaws中的错误类型重叠。
15. 特别是，Codeflaws和我们的数据集都包含需要多块或单块修复的缺陷。
16. 此外，对于单块修复，两个数据集都具有类似的选择突变运算符（例如，运算符突变和变量突变）。
17. 这表明Codex犯了与人类参与者类似的多块或单块修复缺陷。
18.我们认为这是可以预料的，因为Codex是用很多可能存在错误的人类编写的程序进行训练的。
19. 表2显示Codex大多数的错误是语法错误和与算法相关的错误。
20. 实际上，当编程任务的难度从“简单”增加到“中等”时，语法错误和与算法相关的错误数量增加，这表明与较低难度级别的较低难度问题相比，Codex解决更难的编程任务的可能性较小。
RQ2: HOW EFFECTIVE ARE APR TOOLS IN FIXING THE CODE PRODUCED BY CODEX?
- 1. Codex的错误与人类编写的解决方案有一些相似之处。
2. 研究现有APR工具修复Codex生成代码的有效性。
3. 现有APR工具通常生成小修补（通常是一行或几行修复），因此排除无法编译的程序或需要更改整个算法的程序。
4. 知道可以自动修复编译错误的技术，但本研究仅评估修复编码错误的工具，将修复编译错误工具的评估留作后续工作。
5. 对Codex模型未解决的解决方案（排除产生语法错误和算法相关错误的解决方案）运行TBar和Recoder，以评估它们生成修补程序的能力。
6. 在修补程序验证阶段，自动生成的修补程序被归类为以下几种：可能的修补程序、正确的修补程序。
7. TBar在容易和中等难度的任务上分别产生12个和8个可能的修补程序，但只正确修复了4个容易和2个中等难度的修补程序。
8. 与TBar相比，Recoder产生更多可能的修补程序（分别在容易和中等难度任务上产生10个和12个），以及更多正确的修补程序（分别为6个和4个）。
9. 如果比较所有生成修补程序中正确修补程序的百分比，Recoder仍然优于TBar。
10. 测试用例在修补程序生成中起着重要作用。
11. 限制公共测试用例的数量是阻止APR工具生成更多正确修补程序的原因之一。
12. Table 3显示了TBar和Recoder分别生成的修补程序数量和正确修复的编程任务数量。
13. Table 4显示了使用不同APR工具正确修复的解决方案数量（仅考虑单块错误）。
14. Recoder修复了八个编程任务，而TBar只修复了五个任务。
15. TBar将容易级别任务上解决的程序数量从37增加到40（Recoder进一步通过修复另外两个容易级别任务增加这个数字），而Recoder将中等级别任务上解决的程序数量从5增加到9。
16. 结合这两个工具，APR工具帮助Codex修复了5个和4个容易级别和中等级别的任务。
17. 进一步分析两个APR工具修复的缺陷类型。
18. Table 4显示了每个缺陷类别可以正确修复的解决方案数量，其中“TBar”和“Recoder”列显示了相应工具产生的修补程序数量。
19. 对于每个类别，修补工具可能不会通过最小化程序更改来修复错误。
RQ3: CAN CODEX EDIT MODE FIX PROGRAM BUGS?
- 1. OpenAI最近发布了Codex编辑模式的更新，这个新功能可以使现有的程序内容发生改变。
2. Codex编辑模式通过输入程序和一个自然语言指令来输出一个经过编辑的程序。
3. 研究探讨了使用Codex-e作为自动化程序修复工具的可能性。
4. 为了减少自然语言描述对Codex-e的影响，去除了每个未解决方案中的任务描述。
5. 设计了三种构建Codex-e编辑指令的策略：
- Codex-e 𝑏𝑢𝑔：告知Codex-e存在程序中的错误并请求其修复。
- Codex-e 𝑙𝑖𝑛𝑒：利用现有的自动程序修复技术，通过统计故障定位（Ochiai）获取可能修复行的序列，作为修复提示提供给Codex-e。
- Codex-e 𝑠𝑡𝑚：直接使用可疑语句而不是可疑行号作为指令，进一步探究Codex-e的响应。
6. 对于每个未解决的解决方案，选择了最可疑的十句话，并要求Codex-e为每句话生成五个可能的编辑。
7. 与常规Codex模式下的初始解决方案生成类似，设置了温度参数0.8以增加找到正确编辑的可能性。
8. 表5展示了三种策略的结果，其中列Codex-e 𝑏𝑢𝑔、Codex-e 𝑙𝑖𝑛𝑒和Codex-e 𝑠𝑡𝑚分别显示了使用相应编辑指令的正确补丁数量。
9. 使用"Fix bug in the program"作为指令时，Codex-e 𝑏𝑢𝑔成功产生了15个正确的补丁。
10. 当给出错误的行号作为指令时，Codex-e 𝑙𝑖𝑛𝑒只修复了六个需要单块修复的解决方案和一个需要多块修复的解决方案。
11. Codex-e 𝑠𝑡𝑚使用程序文本（如"i -= 2;"）作为指令，成功修复了16个有错误的解决方案，效果最好。
12. Codex-e 𝑠𝑡𝑚的有效性归功于其使用可能更有助于引导像Codex这样的语言模型匹配相关语句。
实验结果表明：
- Codex生成的程序与人类程序员生成的程序有共同的缺陷类别；
- 现有的APR技术（TBar和Recoder）在修复自动生成的程序中的bug表现不佳；
- 在适当的指令（来自故障定位的信息）下，Codex-e在代码编辑生成方面显示出初步的潜力，通过修复45%更多的错误程序，其表现优于TBar和Recoder。
这项研究的影响包括：
- 通过传统软件工程技术（例如，AST信息、故障定位）增强语言模型；
- 突显了APR技术的局限性，尤其是基于模式的approach；
- 建议APR研究的未来方向（例如，灵活的故障定位形式）。