代码生成 | RexBlog

基本信息标题: MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework 作者: Sirui Hong、Mingchen Zhuge、Chenglin Wu（通讯作者）等。作者单位: DeepWisdom、阿卜杜拉国王科技大学、厦门大学、香港中文大学、南京大学、宾夕法尼亚大学、加州大学伯克利分校、瑞士人工智能实验室期刊/会议: ArXiv 发表年份: 2023 DOI: 2308.00352 开源地址: Github 关键词: MetaGPT, Multi-Agent Collaboration, Standardized Operating Procedures (SOPs), Large Language Models (LLMs), Code Generation 研究背景 (Background) 利用大语言模型的Agent为增强和复制人类的工作流程提供了机会。但是实际应用中，现有系统将复杂问题过度简化。很多人想努力实现有效、连贯和准确的解决问题，尤其是需要协作的任务。而SOP可以有效的分解任务并且协调各个任务，明确的SOPs能够提高任务执行的一致性和准确性，确保其与定义的角色和质量标准相符。研究问题 (Research Questions) 如何使用应用SOPs与Agent协作开发。如何优化Agent协作通信能力。如何提高代码生成的质量。核心贡献 (Key Contributions) 总结本文的主要贡献点：引入了MetaGPT，一个基于LLM的多智能体协作元编程框架。作者在MetaGPT设计中创新性地集成了SOP，减少了LLM的代理之间的无效协作。此外，还引入了一种新颖的执行反馈机制，可以在运行时调试和执行代码，从而提高了代码生成的质量（MBPP上提高了5.4%）在HumanEval和MBPP达到了SOAT MetaGPT 框架 (MetaGPT Framework) SOP中的Agent（Agents in Stanndard Operating Procedures）角色的特定职能解决复杂的任务或问题通常需要具有不同技能和专业知识的智能体协作，每个智能体都针对特定问题提供专门的输出。如在一家软件公司，产品经理的任务是分析业务、软件工程师负责编程开发。因此MetaGPT定义了五个角色：产品经理（Product Manager）、架构师（Architect）、项目经理（Project Manager）、工程师（Engineer）以及QA工程师（QA Engineer）。如下面图1所示：图1：MetaGPT与真实世界人类团队之间的软件开发SOPs。在MetaGPT中，对于每个角色制定了Agent的名字（name）、资料（profile）、目标（goal）和约束（constraints）。同时也初始化每个角色的特定的上下文（context）和技能（skill）。例如，产品经理可以使用网络搜索技能，而工程师可以执行代码。如下图2所示。所有Agent遵循ReAct风格。 ...

基本信息标题: Evaluating Large Language Models Trained on Code 作者: Mark Chen、Jerry Tworek、Heewoo Jun、Qiming Yuan等作者单位: OpenAI, Anthropic AI, Zipline 期刊/会议: arXiv 发表时间: 2021年7月14日 DOI: 2107.03374 开源地址: GitHub 关键词: 代码生成, 代码评估, 代码理解研究背景(Background) 对于代码生成任务由于语言模型的推动最早的研究在1963、1971年就开始了（Experiments with a heuristic compiler、Toward automatic program synthesis）,最近的有基于掩码语言模型(masked language modeling)和跨度预测(span prediction)改编用于训练其编程对应物的有CodeBert和PyMT5。OpenAI在GPT3发布的时候，就已经可以通过文档注释(docstrings)生成python代码了，但是能力还是比较有限。研究目标(Research Objectives) 提出一种评估大型语言模型生成代码能力的方法，包括pass@k指标和HumanEval数据集。提出Codex，通过对GPT-3进行微调。提出Codex-S，通过有监督微调Codex。提出Codex-D，通过训练docstring生成模型。评估框架 (Evaluation Framework) 作者定义了pass@k指标，以及HumanEval数据集，用于评估Codex的性能。功能的正确性(Functional Correctness) 评估生成质量可以通过匹配的方式：精确匹配或模糊匹配（如BLEU得分）。然而有研究揭示了基于匹配的代码评估指标的不足。如论文CodeBLEU: a Method for Automatic Evaluation of Code Synthesis中发现BLEU在捕捉代码特有的语义特征方面存在问题，并建议对分数进行几个语义的修改。更加根本的问题是，基于匹配的方式无法评估庞大的并且复杂的代码。近期无监督的代码翻译或伪代码到代码的翻译相关问题也转向了功能性准确性的评估，如果样本通过了测试用例，那么就认为生成的代码是正确的。作者认为这种方式应用到代码生成的评估中是合理的。评估功能正确性最有说服力的理由是程序员常使用这种方式进行评估（单元测试）。 Kual等人在2019(SPoC: Search-based Pseudocode to Code)就用了pass@k，对于每个问题生成k个代码样本，如果其中有一个样本通过了单元测试就认为问题已得到了解决，并计算解决问题的总比例。然而作者认为以这种方式计算pass@k会有很高的方差，而且计算量大。相反，为了评估pass@k，我们给每个任务生成n个样本（n > k, 论文中使用n = 200, k = 100）, 统计通过单元测试的正确样本数c（c <= n），并计算无偏估计量。其中 $\text{pass@}k := \mathbb{E}_{\text{Problems}} \left[ 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}} \right]$。 ...