写在最前面

Yihong Dong∗, Xue Jiang∗, Zhi Jin†, Ge Li† (Peking University)
arXiv May 2023

arXiv 2023.4.15
https://arxiv.org/pdf/2304.07590.pdf

一位不愿意透露姓名的朋友分享了Self-collaboration Code Generation via ChatGPT《基于ChatGPT的自协作代码生成》
这篇论文是chatgpt的黑盒api调用，因此没有关于模型的微调等操作，更多的是提示工程的框架设计（后面同学提到，和思维链的工作有相通之处）
同时，由于是大模型，因此是零样本和少样本学习
如果之后有类似的idea，或许可以尝试模仿论文中的图设计、消融实验

朋友讲解论文叙述框架性强，梳理论文的逻辑清晰
PPT也很清晰明了，很多值得学习的细节

朋友分享的收获与启发

1.框架性的idea也是一种方向，有时也可以带来显著的结果，在AI领域不止有提升算法的思路。
2.实现这种idea也需要严谨完整的推理和验证，将high-level的想法落到细节
3.作者的结论里说明了自协作架构还是要结合人类程序员的指导，避免系统脱离需求，这说明ChatGPT暂时还不能完全自主地工作

课堂讨论

框架性idea
实现idea，需要严谨完整的推理和验证

代码生成如何协作，是一种方法吗

漏洞检测帮助这个框架，这个框架本身首先需要能检测出漏洞，才能去辅助漏洞检测

思路相同

思维链（2022），分步骤
三个人员可以用一个提示来完成

交互实用性

运行时间上
将全部都用chatgpt，写代码换成codeX

代码生成与自协作框架 摘要

目的： 代码生成旨在生成符合特定规范、满足人类需求的代码，以提高软件开发效率和质量，甚至推动生产模式的转变。

创新点： 本研究提出了一种自协作框架，使大型语言模型（LLM，例如ChatGPT）能够应对复杂的代码生成任务。

方法： 该框架首先为三个不同角色的大型语言模型分配任务，包括分析员（analyst，负责需求分析）、程序员（coder，负责编写代码）、测试员（tester，负责检验效果），然后通过软件开发方法（SDM）规定了这些角色之间的交互方式。

结果： 通过所提出的自协作框架，相较于ChatGPT3.5，实验结果显示在四种不同基准测试中，Pass@1的性能提高了29.9%至47.1%。

相关工作

PPT学习

大语言模型在代码生成方向

自2021至现在，有许多团队证实了LLM在代码生成领域的潜力
[Chen et al., 2021, Shen et al., 2022, Li et al., 2022, Dong et al., 2023a，Nijkamp et al., 2022, Fried et al., 2022, Zheng et al., 2023]

• 仍然存在的挑战
  在复杂任务上正确地生成代码
• 解决方法
  团队培训方法：团队合作理论+软件工程实践
• 好处
  分解成子任务，高效，可控；
  加入错误检测和质量控制；
  保证与要求相符

提高生成的代码的准确性和质量：前期、后期处理

后期处理（post-processing）和先期处理（prior-processing）
post-processing：对多个候选人重新排序，选出最正确的方案
CodeT[Chen et al., 2021]和Coder-Reviewer[Zhang et al.,2022]
问题：引入了额外的计算成本用于测试用例生成
post-processing：引导LLM进行rubber duck debugging
self-debugging[Chen et al.,2023]
问题：依赖于few-shot prompting，要求对于每个数据集专门生成一些提示例子，耗时耗力
prior-processing：在代码生成之前引入planning
self-planning[Jiang et al., 2023]
问题：并不完善

将团队协作理论应用于代码生成的研究

[Schick et al., 2022]

• 原理：先训练不同模型执行对应子任务，然后用联合训练增强相互理解
• 问题：这种训练方法非常costly；缺乏相关的训练数据
  改进

[Ouyang et al., 2022, Chung et al., 2022, OpenAI, 2023]

• 原理：经过足够的训练让LLM在软件开发的各个阶段都可以出色地完成任务，方便后续分配；根据人类命令做出调整，开发模型交互的潜力
• 问题：依赖于人类程序员的专业知识，依然耗时耗力

解决方法：本论文提出自协作框架，让ChatGPT形成团队

成果和贡献

提出LLM的自协作框架，以应对“在复杂任务上生成正确的代码”的挑战

根据SDM实例化初始团队，在software development环节分配三个角色负责不同stage

由GPT3.5组成的自协作虚拟团队在各种代码生成的基准测试上，性能超过了GPT-4

在现实场景下，自协作模式有效完成复杂任务

自协作框架原理

1、DOL任务分配

根据任务分配角色指令，然后将对应的任务传递给角色

2、共享黑板协作

不同角色间，将输出的信息共享

3、Instance实例化

3.Instance实例化
1）采用SDM中的经典瀑布模型 [Petersen et al., 2009]，简化为三个阶段：分析、编码、测试。
2）分析员：生成一个高维的计划，着重指导程序员。程序员：根据分析员的计划写代码；根据测试员的测试报告修改代码。测试员：从功能性、可读性和可维护性评判程序员的代码
3）终止条件：达到最大交互次数n或者测试员报告没有错误

案例说明

简单任务：基本操作

1）分析员：分解任务
+制定high-level计划
2）程序员：按照计划生成对应代码
3）测试员：检验代码的功能性和边缘测试情况，反馈错误让程序员修改

复杂任务：游戏开发

未展示训练过程，仅说明结果
满足所有游戏逻辑，保障了精确的角色控制，设置正确的碰撞检测，必要的游戏资产加载和适当的图像缩放。此外，注意到了没有直接规定但是符合常识的游戏逻辑，比如炸弹掉落至底部后会被重置位置
单个LLM只能生成脚本的粗略草稿

实验

设置

数据集

四个基准测试（数据集）

1）MBPP(sanitized version) [Austin et al., 2021]

427个Python编程任务，属于调用标准库功能函数的基础代码生成任务
包含：自然语言描述+编程计划提示+3个测试用例

2）HumanEval [Chen et al., 2021]

164个编程任务
包含：自然语言描述+函数签名+函数主体+单元测试

3）MBPP-ET

4）HumanEval-ET

比原本的数据集多100余个测试，包含边缘案例

实验结果1：与其他代码生成方法比较

输入：自然语言+函数签名+公共的测试用例
分析：相较于GPT-3.5增长了29.9%-34.6%；在后两个数据集上表现更佳，证明自协作代码生成的可靠性。
原因可能为：成员多可以考虑更多边界条件和处理常见bug。

实验结果2：评估不同角色的影响

输入：自然语言
分析：在HumanEval基准测试上三角色团队效果最好，在MBPP基准测试上coder-tester团队表现最好，
原因是：MBPP的两个数据集任务较简单，不需要计划

实验结果3：评估有无角色的影响

few-shot prompting：每个阶段给予一些案例提示
zero-shot：给予指令删除角色，不给予提示
分析：角色指令的特定的上下文语境限制了LLM的生成空间，令其在场景约束下进行推理，生成与命令一致的结果。few-shot比zero-shot表现差的原因是有限的例子提示不能完全反映目标反而让LLM的理解产生偏差，此外提示太长阻碍了LLM的理解。

实验结果4：评估交互次数的影响

Maximum Interaction(MI)=0， 相当于只有coder
分析：大多数任务在两轮内就可以完成；轮数越大，效果越好，但是由于maximum token的限制只能做4轮交互

结论与展望

优势

自协作框架允许团队成员的数量被修改，以适应不同难度的代码生成任务
在通用人工智能（AGI）时代，也可以不受限制，创造新的软件开发模型和新角色组成的虚拟团队

问题

完全自主的系统，可能会脱离需求
有可能的解决方案：结合人类专家的指导监督虚拟团队的操作

有价值的探索方向

通过外部工具弥补LLM自身存在的局限，比如通过角色指令调动Toolformer [Schick et al., 2023]

课堂讨论

框架性idea
实现idea，需要严谨完整的推理和验证

代码生成如何协作，是一种方法吗

漏洞检测帮助这个框架，这个框架本身首先需要能检测出漏洞，才能去辅助漏洞检测

思路相同

思维链（2022），分步骤
三个人员可以用一个提示来完成

交互实用性

运行时间上
将全部都用chatgpt，写代码换成codeX