类似的过程也适用于生成器模型,其中generator outputs 根据其值 进行二值化,并通过比较同一query 下的输出创建偏好对 。
ChatDev 引入了聊天链,将每个阶段进一步分解成更小、更易于管理的子任务,从而引导不同角色之间的多轮交流,为每个子任务提出并验证解决方案。此外,为了减少意外的冲突,还设计了一种名为 communicative dehallucination 的交流模式。
因此,ChatDev 采用了瀑布模型的核心原则, 将软件开发流程分为三个连续阶段:设计、编码和测试。如图 2 所示,编码阶段进一步细分为代码编写和完成两个子任务,而测试阶段则细分为代码审查(静态测试)和系统测试(动态测试)。
ChatDev使用带有顺序阶段 () 的聊天链 (),每个阶段包括顺序子任务 ()。在每个子任务中,都有两个代理,他们各自扮演着不同的角色(例如,擅长识别无限循环的审查员和擅长图形用户界面开发的程序员),分别履行导师()和助理()的职能。导师代理发出指令,指示()话语完成子任务,而助理代理则遵守这些指令,并用()表示适当的解决方案做出回应。他们进行多轮对话 (),相互合作直到达成共识,提取 () 从文本(如定义软件功能点)到代码(如创建源代码的初始版本)的解决方案,最终完成子任务。代理工作流的整个任务解决过程可表述为
ChatDev双代理通信设计,通过避免复杂的多代理拓扑结构,简化了通信,简化了达成共识的过程。然而,简单地(在两个agent间)交换回复并不能实现有效的多轮任务导向型交流,因为它不可避免地面临着角色翻转、指令重复和虚假回复等挑战。
因此,ChatDev 采用了 inception prompting机制(Li 等人,2023a)来启动、维持和结束代理的通信,以保证工作流程的稳健和高效。该机制由 instructor system prompt 和 assistant system prompt 组成。这两种角色的系统提示大多是对称的,包括当前子任务的概述和目标、特定角色、可访问的外部工具、通信协议、终止条件以及避免不良行为的约束或要求。然后基于这两个prompt来实例化 导师和助理
为了避免上下文长度限制agent保持完整通信记录的能力,我们根据聊天链的性质,将代理的上下文记忆按其顺序阶段进行了相应的划分,形成了两种功能不同的记忆类型:短期记忆和长期记忆。短期记忆用于保持单个阶段内对话的连续性,而长期记忆则用于保持不同阶段的上下文意识。
通过只共享每个子任务的解决方案而不是整个交流历史,ChatDev 最大限度地降低了被过多信息淹没的风险,从而提高了每个任务的专注度,鼓励更有针对性的合作,同时促进了跨阶段情境的连续性。
LLM 经常会产生编码幻觉,包括不完整的实现、不可执行的代码和不符合要求的不一致性等潜在问题。编码幻觉经常出现在助手难以精确遵从指令的情况下,这通常是由于某些指令的模糊性和概括性,使得助手难以完全遵从指令。
我们引入了 Communicative Dehallucination,鼓励助手在做出正式回应之前积极向导师寻求更详细的建议。
一般来说,导师与助手之间的交流模式是一种简单明了的指令-回应模式,即上面的 。相比之下,我们的 communicative dehallucination 机制具有刻意的 “角色转换 ”特点,即助手扮演类似于导师的角色,在给出结论性回复之前主动寻求更具体的信息(例如,外部依赖关系的精确名称及其相关类)。在指导员提出具体的修改建议后,助手开始进行精确优化。
由于这种机制一次只处理一个具体问题,因此需要多轮通信来优化各种潜在问题。通信模式指导代理如何进行通信,实现更细粒度的信息交换,从而有效优化解决方案,这实际上有助于减少编码幻觉。
首先,虽然代理可以提高开发质量,但它们往往执行简单的逻辑,导致信息密度低。如果没有明确、详细的要求,代理很难掌握任务的思路
其次,与传统的函数级代码生成不同,通用软件的自动化评估非常复杂。论文强调完整性、可执行性、一致性和总体质量,但未来的研究应考虑功能性、鲁棒性、安全性和用户友好性等其他因素。
第三,与单个代理方法相比,多个代理需要更多的token和时间,从而增加了计算量。未来的研究应着眼于以更少的交互增强代理能力。
个人认为瀑布流还是太理想化,更复杂的软件工程实践或许会有更好的效果,但是其信息交换与上下文限制等问题也会更显著。