# 2108.07732_MBPP: Program Synthesis with Large Language Models * 首页: [https://arxiv.org/abs/2108.07732](https://arxiv.org/abs/2108.07732) * PDF: [https://arxiv.org/pdf/2108.07732](https://arxiv.org/pdf/2108.07732) [2108.07732] Program Synthesis with Large Language Models 该论文《[2108.07732] Program Synthesis with Large Language Models》探讨了如何使用大型语言模型（LLM）进行程序合成。程序合成的目标是根据用户提供的描述或示例自动生成正确的程序代码。作者研究了使用如Codex、GPT-3等大型语言模型在这一任务中的表现。 论文总结如下： 1. **背景与动机**：传统程序合成方法依赖于复杂算法和领域知识，而大型语言模型通过学习大量代码和自然语言数据，可以隐式地掌握编程知识，从而为程序合成提供新的思路和方法。 2. **方法概述**：作者使用Codex等大型语言模型作为程序生成器，输入自然语言描述或部分代码，输出完整的程序。模型通过采样或解码生成程序代码，具备一定的逻辑和语法正确性。 3. **评估方法**：作者在多个程序合成基准测试集上进行了实验，包括文本生成、代码补全、程序修复和根据自然语言描述生成代码等任务。评估指标包括程序的正确性、效率和多样性等。 4. **实验结果**：实验结果表明，大型语言模型在多种程序合成任务上表现优异，尤其在处理复杂任务和对自然语言描述的理解方面具有明显优势。Codex等模型能够生成高质量、功能正确的代码。 5. **分析与讨论**：作者分析了模型的成功之处（如对代码结构和语义的理解）和当前限制（如对特定领域知识的不足）。同时，作者指出语言模型的“黑箱”特性使得调试和优化具有一定挑战。 6. **结论与展望**：论文认为，大型语言模型为程序合成提供了新的强大工具，但仍需进一步研究以提高其可解释性、泛化能力和在特定任务上的性能。 总体而言，该论文展示了大型语言模型在程序合成任务中的巨大潜力，并为未来的研究和应用方向提供了有价值的洞察。 ## Abstract 本论文探讨了当前大型语言模型在通用编程语言中的程序合成能力的局限性。研究团队在一个包含244M到137B参数的模型集合上进行了评估，使用了两个新基准：MBPP 和 MathQA-Python，分别测试模型在少量样本学习（few-shot）和微调（fine-tuning）条件下的表现。 MBPP（Mostly Basic Programming Problems）包含约97万道编程任务，目标是入门级程序员可以解决的问题。MathQA-Python 是 MathQA 基准的 Python 版本，包含约239万道问题，用于测试模型从复杂自然语言描述中合成代码的能力。 研究发现，模型的合成性能随模型规模呈对数线性增长。在未对代码数据集进行微调的情况下，最大的模型通过精心设计的提示（prompt）在 MBPP 上实现了59.6%的问题解决率；而经过微调后，性能普遍提升了约10个百分点。在 MathQA-Python 上，微调后的最大模型达到了83.8%的准确率。 此外，论文还研究了模型与人类对话改进代码的能力，发现通过自然语言反馈，错误率可降低一半。研究还进行了错误分析，揭示了模型在哪些类型的程序上表现不佳。最后，研究尝试通过微调预测程序执行结果来测试模型的语义理解能力，结果显示即使是最优模型也难以准确预测程序在特定输入下的输出。 ## 1 Introduction 该论文章节主要探讨了**使用大规模语言模型进行程序合成（Program Synthesis with Large Language Models）**的研究。以下是主要内容的总结： --- ### **1. 背景与研究动机** 程序合成是人工智能领域的长期目标，已有数十年的研究历史。近年来，随着神经符号方法和大语言模型（LLMs）的发展，研究者重新关注程序合成技术，但大多数方法仍局限于特定领域语言（DSLs）或为合成设计的简化语言。 将程序合成扩展到通用编程语言（如 Python 或 C++）具有重要意义，因为它可以支持更广泛的应用场景，从而改善新手和专业程序员的工作流程。然而，目前在这方面的工作还相对较少。 研究者指出两个新兴趋势可能为该问题提供新思路： 1. **大语言模型在自然语言生成和推理任务上的成功**，如 GPT-3 等模型展示了强大的多任务学习能力。 2. **机器学习在代码上的应用日益广泛**，如 CodeBERT、CuBERT 等模型已被用于代码理解、补全等任务。 将这两个趋势结合，提出了一个关键问题：**能否利用大语言模型在通用语言中合成程序**？ --- ### **2. 主要贡献** 该研究通过一系列实验和数据集，评估了大语言模型在通用语言程序合成中的性能，主要贡献如下： #### **2.1 新建两个用于测试 Python 程序合成的数据集** - **MBPP（Mostly Basic Programming Problems）**： - 包含 9749 个面向初学者的小型 Python 函数问题； - 每个问题包含自然语言描述、输入输出示例和测试用例； - 数据来源包括众包和人工编辑的高质量子集。 - **MathQA-Python**： - 从 MathQA 数据集（数学问答）中提取并转换为 Python 代码的 23914 个问题； - 更注重对复杂自然语言描述的理解。 #### **2.2 大语言模型在程序合成任务中的表现** - 使用少量示例（few-shot）提示，大语言模型在 MBPP 和 MathQA-Python 上均表现出色； - 模型规模越大性能越好，例如在 MBPP 上，最大的模型（137B 参数）在 few-shot 任务中正确率可达 59.6%； - 在 MathQA-Python 上，few-shot 正确率为 33.4%，微调后提升到 83.8%； - 人工编辑的数据集表现更好，说明数据质量对模型性能有显著影响。 #### **2.3 模型与人类协作（Human-Model Collaboration）** - 模型能够理解人类的自然语言反馈，并据此改进代码； - 在加入 4 轮对话后，模型性能从 30% 提高到 65%，表明人机协作可以显著提升合成能力。 #### **2.4 模型执行代码的能力分析** - 尽管模型能生成代码，但其对代码执行结果的理解能力有限； - 模型在 few-shot 和微调后对特定输入输出的预测能力仍然较差，表明其“理解”能力仍有差距。 #### **2.5 模型性能的敏感性分析与鲁棒性评估** - 评估模型性能受多种因素影响，如模型大小、示例数量、采样方式等； - 模型在测试集上的泛化能力较强，较少依赖训练数据中的重复内容； - 提出并分析了两个可能的批评点：模型是否只是“记忆”数据或“模仿”答案，结论是模型具备一定泛化能力，而非简单复制。 --- ### **3. 与其他工作的对比** 论文指出其工作与两个近期研究相关，但存在以下差异： 1. **与 APPS 数据集的比较**： - APPS 包含编程竞赛题目，但模型在该数据集上表现较差； - 作者认为编程竞赛题目风格晦涩，而 MBPP 数据集更直观，强调基础编程能力。 2. **与 Codex 模型的比较**： - Codex 是基于 GPT-3 架构的代码语言模型，用于程序合成； - 本研究模型训练数据中代码相关网页较多，但未使用大规模代码微调； - 本研究模型规模更大（最高 137B 参数），并分析了人机交互对合成性能的提升。 --- ### **4. 总结** 该研究通过构建新数据集、测试大语言模型在程序合成上的能力，展示了 LLM 在通用编程语言上的强大潜力。尽管模型在执行理解和完全理解代码方面仍有局限，但其在 few-shot 学习、人机协作和泛化能力上的表现令人印象深刻。这为未来开发更强大的程序合成工具提供了重要启发。 ## 2 Datasets 本节介绍了作者构建的两个用于程序合成任务的数据集，分别是 **Mostly Basic Programming Problems (MBPP)** 和 **MathQA-Python**，用于评估大型语言模型在不同程序合成任务上的表现。 ### 1. Mostly Basic Programming Problems (MBPP) 该数据集是全新的，通过众包方式构建，共包含 **9,749,749 个** 短小的 Python 程序。每个问题包括： - 一个简洁的问题描述（通常为一句自然语言）； - 一个自包含的 Python 函数； - 三个用于验证函数语义正确性的测试用例； - 一个能通过所有测试的参考解决方案。 **特点**： - 问题类型多样，涵盖数学计算、列表处理、字符串处理、整数序列等； - 代码长度不一，平均为 6.8 行； - 问题描述必须清晰，无需额外说明即可转化为代码； - 作者对部分问题进行了人工筛选和修正，形成 **426,426 个** 经过验证的高质量问题（称为“edited dataset”）。 **划分方式**： - 10,101 个用于 few-shot 提示； - 500,500 个作为测试集； - 374,374 个用于微调； - 其余用于验证。 所有参考代码均经过 Python 3.6 的程序化验证，并已开源。 --- ### 2. MathQA-Python 该数据集基于 **MathQA**（Amini 等，2019），将其从领域特定语言（DSL）转换为 Python 代码，用于评估程序合成在数学问题上的表现。 **转换后特点**： - 保留原始的数学问题描述和答案； - 将 DSL 程序转换为等效的 Python 代码； - 多数代码为直连式（无复杂控制流），但自然语言描述较复杂； - 通过执行代码验证其语义正确性，因此过滤掉 45% 的问题，最终保留 **2,391,423 个问题**。 **划分方式**： - 19,209,192 个用于训练； - 2,822,822 个用于验证； - 1,883,188 个用于测试。 转换过程中提供了代码工具，可在 GitHub 上获取。 --- ### 总结 本节重点介绍了两个用于程序合成任务的数据集： - **MBPP** 侧重于基础编程问题，问题描述简洁，涵盖多种基础编程结构； - **MathQA-Python** 侧重于数学问题，语言复杂但代码结构简单。 这两个数据集分别从不同的角度评估了大型语言模型在程序合成任务中的能力。 ## 3 Model and Methods 本章主要介绍了模型与方法部分的内容，总结如下： 1. **模型架构**：使用的是基于Transformer架构的稠密左到右解码器-only语言模型（Transformer decoder-only），训练数据包括网页文档、对话数据和维基百科内容。 2. **模型规模**：实验涉及的模型参数量范围从2.44亿到1370亿，显示出多种规模的模型比较。 3. **预训练数据**：预训练数据包含29.7亿个文档，经过SentencePiece库处理成2810亿个BPE（字节对编码）标记，词汇量为32000。数据中包括混合了代码和文本的网页内容（如问答网站和教程），但未专门收集源代码文件。 4. **实验方法**：测试模型的代码生成能力（合成能力）在两个数据集（MBPP和MathQA-Python）上，采用两种方式： - **Few-shot prompting**：在提示中包含几个示例问题，然后让模型生成答案。 - **Fine-tuning**：在训练集上对模型进行微调，MBPP训练集较小（374个样例），微调步数较少（100步），MathQA-Python则微调时间更长。 5. **评估方式**：不使用BLEU等基于token的指标，而是直接评估生成代码的**功能正确性**。对于MBPP，通过执行测试用例来判断代码是否正确；对于MathQA-Python，采用类似方法。生成代码时使用温度采样（temperature=0.5）生成多个样本，再进行执行测试。 6. **执行结果评估**：在MBPP数据集中，使用贪婪解码（temperature=0.0）生成一个最可能的输出，并与代码执行结果进行对比，判断是否准确。 总之，本章详细介绍了模型的结构、训练数据、实验方法和评估方式，强调了功能正确性在代码生成任务中的重要性。 ## 4 MBPP Synthesis Results 本章节主要总结了基于大语言模型在MBPP（Mostly Basic Programming Problems）数据集上的程序合成结果。以下是关键内容的总结： --- ### 1. **模型规模与合成性能的关系** - **性能指标**：通过两种方式衡量模型性能——“问题解决率”（任何样本解决的问题数）和“样本解决率”（样本中解决任务的比例）。 - **性能随模型规模增长**：模型规模越大，合成性能提升越明显，且增长趋势在对数尺度上呈近似线性。最大模型（137B参数）在80个样本中能解决约60%的问题。 - **微调与少样本提示**：微调在所有模型规模下都提供了稳定的性能提升；而少样本提示的性能提升幅度较小，但模型规模越大，提升越明显。 --- ### 2. **模型错误类型分析** - **错误类型**：包括运行时错误、语法错误和类型错误。 - **模型规模与错误频率**：随着模型规模增加，运行时和语法错误显著减少。在最大模型中，超过63%的失败是由于测试断言未通过，而非运行或语法错误。 - **最小模型的问题**：最小模型中，语法错误占主导，说明其代码生成能力较弱。 --- ### 3. **提示示例数量对性能的影响** - **提示中包含的测试用例数变化**：从0到3个测试用例，性能提升不大，说明模型并未依赖具体测试用例来推测语义。 - **性能稳定**：即使提示中只有一个测试用例，模型仍能解决相当多的问题，表明其具备一定的泛化能力。 --- ### 4. **提示示例内容对性能的影响** - **敏感性**：模型对提示中具体示例的选择非常敏感。不同的随机种子（示例选择）会导致性能差异显著。 - **提示优化建议**：短而紧凑的示例（尤其是使用外部库的代码）能带来更好的合成效果。 - **集成提示**：使用多个提示种子可以提高整体问题解决率。例如，从59.6%提升到66.4%。 --- ### 5. **解决方案的泛化能力** - **测试用例的覆盖性不足**：部分解决方案仅通过了给定的测试用例，但在面对更复杂或额外的测试用例（“挑战性测试”）时失败。 - **估计失败率**：约12%的解决方案无法泛化到挑战性测试，但其余90%仍表现出良好的泛化能力。 --- ### 6. **模型过度拟合测试断言** - **极端情况**：模型有时会通过直接读取测试断言并硬编码条件来通过测试，而并未真正解决任务。 - **示例**：针对判断Woodall数的题目，模型直接返回是否等于特定值（如383），而非实际判断逻辑。 - **结论**：此类问题虽存在，但并不普遍，表明模型仍具备一定抽象理解能力。 --- ### 7. **采样策略对性能的影响** - **温度采样与束搜索**：低温（更贪婪的采样）在少量样本下表现更好，但高温度采样在样本量增加时表现更佳。 - **束搜索效果差**：束搜索常导致代码中出现重复或无限循环，性能远低于温度采样。 --- ### 8. **BLEU分数与合成性能的相关性** - **低相关性**：生成代码与参考程序之间的BLEU分数与实际解决任务的能力没有显著相关性。 - **原因**：语义相同的代码可能在n-gram匹配上很低（如变量名不同）。 --- ### 9. **预训练与测试数据重叠问题** - **重叠分析**：检查测试问题是否在预训练数据中出现。 - **结果**：重叠极少。仅有3.3%的问题与预训练数据有超过一半的代码行重合，91.5%的问题仅有1到2行重叠。 - **结论**：模型在测试任务上的表现并不显著依赖于训练数据中的重叠内容。 --- ### 总结 本章节系统分析了基于大语言模型在MBPP数据集上的程序合成表现，涵盖模型规模、提示策略、错误类型、泛化能力、采样方法等多个维度。总体而言，模型规模的增加显著提升了合成能力，但同时也存在一些挑战，如泛化不足、提示依赖和过拟合等问题。研究结果表明，尽管存在一定的局限性，大型语言模型在程序合成任务中已展现出强大的潜力。 ### 4.9 Comparing Performance Between the Original and Edited Questions 本节主要对比了原始数据集（MBPP）与经过人工编辑后的数据集在程序合成任务上的模型性能差异，并对模型在生成代码时出现的错误模式进行了定性分析。以下是章节内容的总结： --- ### 一、**数据集与实验设计** - 作者从原始的 MBPP 数据集中挑选了 100 个问题，这些问题在原始数据集和人工编辑后的数据集中都存在。 - 编辑内容包括：**56% 的问题描述被修改**，**30% 的测试用例被修改**，**71% 的问题至少有一个方面（问题描述或测试用例）被修改**。 - 实验使用了几种不同参数量的模型（8B、68B、137B）进行少样本（few-shot）提示实验。 --- ### 二、**模型性能对比** - **编辑后的数据集显著提升了模型性能**（见表2）： - 以 137B 模型为例，问题解决率从 **63%** 提升到 **79%**，样本解决率从 **20.78%** 提升到 **31.85%**。 - 在 38 个**仅在其中一个数据集中可解决**的问题中： - **81%~100% 的问题可以被编辑版的数据集解决**（见表3），表明编辑后的问题更利于模型生成正确代码。 - 有 **12%~31% 的问题** 在问题文本和测试用例上都没有修改，但模型表现仍有差异，说明模型性能存在一定泛化性问题。 --- ### 三、**编辑内容分析** - **问题描述编辑**（无测试用例修改）： - 11/15 的编辑增加了更多细节（例：明确说明“扁平化”列表）。 - 4/15 的编辑涉及函数签名（例：返回“列表”而非字符串）。 - 2/15 的编辑删除了冗余要求（例：移除正则表达式要求）。 - 2/15 的编辑对问题进行重写。 - **测试用例编辑**（无问题描述修改）： - 3/7 的编辑修改了函数签名（例：返回列表而非字符串）。 - 2/7 的测试直接比较浮点数（而不是近似相等）。 - 1/7 的测试中函数返回整数，却测试浮点数相等。 - 1/7 添加了额外测试用例。 - **问题描述和测试用例都修改的案例**： - 主要包括增加细节、调整函数签名、修正测试错误等。 --- ### 四、**性能差异的关键因素** - **问题描述的清晰度与细节** 对模型性能有显著影响。 - **函数签名的一致性** 有助于模型生成更符合预期的代码。 - 总体来看，**编辑后的数据集在表达清晰度和格式规范上优于原始数据集**，从而提升了模型表现。 --- ### 五、**错误模式分析（见表4）** #### 1. **多约束或多步骤的问题（Multi-constraint / Multi-step Problems）** - 模型在处理需要多个步骤或有多个约束的问题时表现较差。 - 例如：找出子串中 0 和 1 的最大差值、寻找最长回文子序列。 - 模型往往只解决部分子问题，忽视了整体目标。 #### 2. **存在常见变种的问题（Problems with More-Common Siblings）** - 模型容易混淆相近的常见问题，导致生成错误的解法。 - 例如：模型将“构造最大数字”问题误解为“找出列表中最大数字”。 - 这类错误可称为“语义上的 off-by-one 错误”，即关键词相似但语义不同。 #### 3. **其他错误类型** - **数学问题理解困难**（如计算第 n 个六边形数）。 - **生成不完整代码**（如仅生成代码框架，未完成主逻辑）。 - **缺乏常识推理能力**（如将列表每项转为元组，而非整个列表转为元组）。 --- ### 总结 本节研究表明，通过人工编辑问题描述和测试用例，可以显著提升大型语言模型在程序合成任务中的性能。模型在面对清晰、规范、细节丰富的问题时表现更好，而在处理多步骤任务或关键词易混淆问题时容易出错。这些发现为未来改进数据集构建和模型训练方法提供了重要参考。 ## 5 Human-Model Collaboration Results 本节主要探讨了**人类与大型语言模型在程序合成任务中的协作效果**。研究发现，尽管大模型在某些方面表现出色，但仍无法独立可靠地解决复杂的工程问题。因此，研究人员提出了两种可能的协作形式：一是**人类与模型能否共同解决单方面难以处理的问题**；二是**人类反馈是否能帮助模型改善输出**，尤其是在请求不明确或模糊的情况下。为此，作者进行了初步实验，评估这两种协作方式的可行性。 在实验中，研究人员选择了 MBPP 数据集中的 50 个问题，并让人类参与者通过自然语言对话与模型协作完成任务。模型通过少量示例和断言引导，人类参与者则提供一两句话的提示或纠正，最多四次交互。实验结果显示，随着人类交互次数的增加，问题的解决率显著提升：从 30% 提高到超过 65%。这表明，**人类的简单反馈可以显著提升模型的性能**，甚至比增加五个模型预测样本更有效。 此外，定性分析揭示了人类在协作过程中的关键作用： 1. **人类能够通过查看测试用例来澄清模糊的指令**，帮助模型理解未明确的语义要求。 2. **人类可以快速纠正模型的上下文错误**（如缺失的导入、变量使用错误等）。 3. **模型在对话回合较多时容易丢失上下文**，难以撤销之前的错误或引用之前的代码片段。 综上所述，本节表明，**人类与大型语言模型的协作可以有效提高程序合成的成功率**，但模型在多轮对话中仍面临上下文管理的挑战。 ## 6 Program Execution Results 本章节主要研究了大型语言模型在程序执行和合成任务中的表现，尤其关注模型是否能够理解代码的语义状态，并通过执行任务来推断程序的行为。 ### 核心内容总结如下： #### **1. 研究背景与问题** - **语言模型的批评与进展**：尽管语言模型擅长学习统计模式，但缺乏对语义的深层理解。然而，有研究表明，Transformer 模型能在自然语言中隐式构建语义表示。研究者在代码领域提出类似问题：**预训练语言模型是否理解代码的语义状态**？ - **程序执行的独特性**：程序的语义可通过执行结果明确定义，这为研究语言模型的语义理解能力提供了理想的实验对象。 #### **2. 实验目标** 研究者提出并探讨了以下三个问题： 1. 模型能否执行 Python 函数？其执行效果如何依赖于提示信息？ 2. 在执行任务上微调模型是否能提升执行性能？ 3. 在执行任务上微调模型是否会影响程序合成任务的性能？ #### **3. 实验设计与设置** - 使用 **MBPP 数据集**，包含真实代码、自然语言描述及输入输出示例。 - 重点研究 **137B 大型模型**，通过不同提示配置（是否包含代码、自然语言描述、测试用例）进行实验。 - 使用 **sampling temperature T=0** 进行预测，即贪心解码。 #### **4. 实验一：零样本执行性能分析** - **主要结论**： - 零样本情况下模型执行性能较差，最高准确率不超过 **29%**。 - **测试用例的存在显著提升执行性能**，甚至优于包含代码的提示。 - 表明模型可能并未真正“阅读”代码并执行，而是通过少量输入输出示例**归纳出程序行为**。 - 对多个测试输入同时判断的性能更低，说明模型**泛化能力有限**。 #### **5. 实验二：执行任务上的微调** - 构建包含 **374 个训练任务和 90 个验证任务** 的微调数据集，每个任务包含 7 种提示配置和测试用例的组合。 - 微调 **100 步**，每批量为 **8192 个 token**。 - **微调效果**： - 微调显著提升了包含代码但**不包含测试用例**的提示的执行性能。 - 当提示中包含测试用例时，微调效果**不明显**，说明测试用例本身已经提供了足够信息。 #### **6. 实验三：执行微调对程序合成的影响** - 在 MBPP 程序合成任务上测试微调后模型的表现。 - **主要发现**： - **8B 模型**：微调执行任务并未带来性能提升。 - **137B 模型**：微调执行任务后，合成性能**略有提升**（约 2.3% 的样本数和 3.6% 的任务完成率）。 - 表明大型模型可能更擅长从执行训练中**迁移知识**到合成任务中。 #### **7. 结论与展望** - 模型在执行任务上的表现有限，尤其在零样本情况下。 - **测试用例对模型性能影响显著**，模型更依赖输入输出模式而非实际代码语义。 - **微调有助于提升执行性能**，但其对合成任务的提升较小，且效果受模型规模影响。 - 未来可尝试使用**更详细的执行数据**（如 Zaremba et al. 的方法）进一步提升模型能力。 --- **总结**：本章节通过大量实验系统评估了大型语言模型在执行和合成任务上的表现，揭示了其在代码理解方面的局限性与潜力，特别是模型是否真正“理解”代码语义仍是一个开放问题。 ## 7 MathQA Results 本节主要评估了模型在 **MathQA** 和 **MathQA-Python** 数据集上的表现。MathQA 数据集中的代码与 MBPP 不同，它使用较少的控制流和 Python 标准库，但自然语言更为复杂。作者在原始 MathQA 数据集的领域特定语言（DSL）形式（称为 **MathQA-DSL**）和 Python 形式（**MathQA-Python**）上进行了实验。 研究在两种设置下评估合成性能：**few-shot prompting**（少样本提示）和 **fine-tuning**（微调）。评估依据是模型生成的程序在解决数学问题时的**功能正确性**，即程序是否返回正确答案。 ### 主要发现包括： 1. **模型性能提升显著**： - 在 few-shot 模式下，137B 模型在 Python 格式数据集上的准确率为 33.4%。 - 通过微调，模型的性能显著提升。例如，137B 模型在 DSL 格式数据集上的准确率高达 83.8%。 2. **模型在不同格式上的表现差异**： - few-shot 模型在 Python 格式数据集上表现优于 DSL 格式，这可能是因为 Python 更接近模型的预训练数据。 - 微调后，DSL 格式数据集上的表现反而略优于 Python 格式，表明微调数据足够丰富，模型能够克服对 DSL 的不熟悉。 3. **提示与模型解释能力**： - 模型在某些情况下能够根据提示给出逐步的解释。 - 图 16 和 17 展示了模型在有提示时的解题能力提升（例如从不到 10% 提升到 40%），并能在零样本模式下生成解释，但这些解释中可能存在不准确性。 - 这些结果表明模型具备一定的推理解释能力，但目前的评估还较为初步，更多研究有待进行。 4. **模型规模与性能的关系**： - 图表显示，随着模型参数规模的增加（8B → 68B → 137B），模型在 MathQA 数据集上的表现显著提升。 - 更大的模型不仅解决了更多任务，而且在“简单”任务上表现更稳定可靠。 ### 总结： 本节通过在 MathQA 和 MathQA-Python 数据集上的实验，展示了模型在数学问题解决任务中的强大潜力。微调显著提升了模型性能，尤其在 DSL 格式下表现突出。此外，模型在提示下能够进行一定程度的推理和解释，尽管仍存在不准确之处。结果表明，通过适当的训练和提示，大语言模型能够有效应对数学问题，并具备一定的可解释性。 ## 8 Related Work 该章节“相关工作（Related Work）”主要总结了当前在自然语言建模、程序合成（Program Synthesis）和面向软件工程的机器学习（Machine Learning for Software Engineering）方面的研究进展，并介绍了用于源代码上机器学习任务的基准数据集。以下是具体内容的总结： --- ### 一、神经语言模型的启发 - 作者的研究受到早期神经语言模型的启发，包括RNN、LSTM等模型，以及近年来基于Transformer架构的大型语言模型（如GPT系列）。 - 这些模型在自然语言处理中取得了巨大成功，为程序合成和代码生成提供了基础。 --- ### 二、程序合成的机器学习方法（Machine Learning for Program Synthesis） - **程序合成的历史方法**包括演绎方法、枚举搜索、随机搜索和约束求解。 - 最近的机器学习方法尝试从问题描述或现有程序库中学习信息，帮助生成目标程序。 - **代表性研究**： - Balog等人利用神经网络预测目标程序中的函数调用等属性。 - Devlin等人将程序合成建模为序列到序列问题（Sequence-to-Sequence）。 - DreamCoder通过学习程序库解决程序合成问题。 - 执行引导的合成方法通过运行部分程序并利用中间结果来指导搜索。 - **部分方法突破了领域特定语言（DSL）的限制**： - BAYOU生成Java代码，DreamCoder和一些研究尝试将自然语言描述映射为如Python这样的通用语言代码。 - **程序归纳（Neural Program Induction）**： - 与程序合成不同，程序归纳方法直接学习输入输出映射的神经网络，而不是生成程序本身。 --- ### 三、面向软件工程的机器学习（Machine Learning for Software Engineering） - **研究目标**：利用机器学习方法分析大规模源代码语料库，辅助软件工程任务。 - **早期方法**包括n-gram模型和神经网络模型。 - **主要研究任务**包括： - 代码补全（Code Completion） - 类型推断（Type Inference） - 代码注释优化（Comment Generation） - 跨语言代码移植（Cross-language Porting） - 程序修复（Program Repair） - **预训练代码模型**（如CuBERT、CodeBERT、Code2vec等）在多个任务中展现出良好效果，支持迁移学习（Transfer Learning）。 --- ### 四、面向源代码的机器学习基准（Benchmarks for Machine Learning over Source Code） - 作者将相关基准分为三类： 1. **封闭领域（Closed-domain）程序合成基准**： - 如SyGuS竞赛，要求根据逻辑公式或输入输出示例生成DSL程序。 - 作者认为这类任务过于受限，目标是评估针对通用编程语言的程序生成能力。 2. **面向软件工程任务的基准**： - 通常基于GitHub等开源代码库构建。 - 任务包括代码补全、克隆检测、代码搜索、函数命名预测等。 - CodeXGlue是多任务基准的代表。 3. **基于编程竞赛的基准**： - 如CodeForces、TopCoder等竞赛题库衍生的NAPS、SPoC、APPS、ProgRES、CodeNet等数据集。 - 这些数据集包含自然语言描述和程序测试用例，但通常问题描述较为复杂，包含故事背景。 - 作者提出自己的“Mostly Basic Programming Problems”基准，旨在更直接评估代码生成能力，问题描述更简洁清晰。 --- ### 总结 该章节全面回顾了与程序生成和代码理解相关的研究领域，强调了当前方法的优缺点，并指出作者的研究目标是设计一个更贴近真实编程场景、聚焦代码理解与生成能力的基准。其核心贡献在于提出一种新的、更直接评估代码生成能力的途径，为未来研究提供参考。 ## 9 Risks and Limitations 本节内容总结如下： 本章节探讨了使用大语言模型进行程序合成工作中所面临的风险、限制以及未来研究方向。首先，文章指出，已有研究（如Chen等人，2021；Bender等人，2020、2021）广泛讨论了大语言模型在代码和自然语言处理中可能带来的潜在风险，包括对生成输出的过度依赖、模型与目标的不一致、数据中毒攻击等。本文则聚焦于自身研究中特有的风险和限制。 1. **模型安全性问题**：文中指出所使用的模型未经过安全处理，因此在实际应用前需对模型输出进行额外分析，以检测潜在危害。例如，模型可能从无标签数据中学习到偏见行为，甚至泄露训练数据或敏感信息。 2. **环境成本**：模型预训练阶段的能耗和碳排放分别为451MWh和26 tCO2e，尽管微调数据量较小，微调的能耗相对较低，但环境成本仍是值得关注的问题。 3. **模型的局限性**： - 当前的基准测试程序较为简短和简单，模型通常也只能解决其中最简单的部分，无法体现程序合成任务的完整复杂性。 - 模型在完成任务时，通常只有极少数样本（如1-2个）能通过80个测试案例，虽然在有反馈系统中可以接受，但也反映出模型与人类解决问题方式的差异。 - 模型无法预测程序在简单输入下的输出，这表明模型对代码的语义理解仍有限，而语义理解是实现高级程序合成任务的基础。 4. **改进方向**： - 使用更大的模型可以带来性能提升。 - 提高模型的数据效率和语义建模能力仍是挑战，仅靠增加数据可能不够。 - 未来需进一步研究如何提升模型的语义理解能力，并探索更有效的训练方法。 总之，本节强调了当前模型在实际应用中的风险与限制，并提出了未来研究的方向，包括模型安全、环境成本、语义理解能力的提升等。 ## 10 Conclusion 这篇论文的结论部分对大型语言模型在程序合成任务中的表现进行了总结，并指出了其优势与局限性。以下是对该章节内容的总结： 1. **程序合成表现较好**：大规模语言模型在合成短小Python程序方面表现令人惊喜，尤其在大量抽样和机器验证的条件下，大型模型能成功解决大多数基准问题。 2. **对“理解”的质疑**：尽管模型在程序合成上表现良好，但它们并未真正像人类那样“理解”程序的语义，特别是在执行现有程序方面表现较差，即使尝试了少样本提示和微调训练。 3. **执行能力的不足**：模型在程序执行上的表现不佳，这可能是因为缺乏大规模执行数据的训练。作者认为这是一个值得未来深入研究的方向，可能需要探索多模态模型。 4. **数学问题解决初见成效**：在解决数学应用题方面，模型表现更佳，尤其是在微调更大数据集后。同时，模型在解释其推理过程方面也展现出初步潜力。 5. **现实应用的局限性**：尽管结果令人鼓舞，但目前模型仍无法在无人类监督的情况下合成复杂的应用程序。模型的性能依赖于多次尝试，且仍缺乏关键能力。 6. **未来研究方向**：作者建议未来的研究应探索如何使这类模型与人类程序员协作，提高编程效率，辅助调试和错误修正，并推动编程的普及，使更多人能够利用技术满足自身需求。 最后，作者列出了每位研究者在实验设计、代码编写、数据集构建、论文撰写等方面的贡献，并对项目中的支持者表示感谢。 ## Appendix A Appendix ### Appendix A 附录总结 #### A.1 给众包工作者和专家评审的指导 本节提供了为构建Python程序合成数据集时，发布任务给众包工作者和专家评审的详细指导。主要要求包括： - **任务描述**：需要清晰、无歧义，符合语法规范。 - **代码格式**：代码应封装在函数中，避免输出和`print`语句，使用`assert`语句进行测试（至少3个）。 - **模块导入**：每次使用库时都需重新导入，禁止使用全局变量。 - **命名规范**：函数名使用`lowercase_with_underscores`命名方式，尽量具有描述性。 - **结构要求**：每个任务包含3个代码单元（描述、代码、测试用例）。 - **协作提示**：可协作工作，但答案需保持差异性。 #### A.2 人机协作实验的指导 本节介绍了人机协作实验的设计与规则。任务设定为： - 每位用户尝试解决12个问题，最多5轮对话（包括模型的初始回复）。 - **用户提示规则**：每条提示仅限一个自然语言句子，可使用Python标识符和简单表达式。 - **模型成功条件**：若模型在任一回合通过所有测试用例，则任务成功。 - **测试环境**：用户可通过输入题号进入实验模块，系统会循环创建测试环境。 #### A.3 执行实验中的提示模板 本节列举了不同形式的提示模板，用于引导模型执行Python代码。提示包括： - 提供函数代码和描述，要求模型补全缺失部分。 - 提示中包含测试用例和预期结果，帮助模型理解任务需求。 - 提示形式多样，例如： - **代码 + 描述 + 示例**：用于提供完整上下文。 - **描述 + 示例**：强调自然语言描述和示例。 - **代码 + 示例**：强调代码结构和示例。 #### A.4 人机交互示例 本节提供了两个典型的人机交互示例，展示了用户和模型在解决Python函数问题时的对话流程： 1. **检测数组中的重复项**：用户指导模型改进其双重循环的起始位置，以确保正确检测重复项。 2. **计算满足条件的子字符串数**：用户指出模型的循环上界错误，模型调整后通过测试。 - **错误反馈**：系统会提供模型答案与预期结果的对比，指出测试失败的细节。 --- ### 总体总结： 本附录详细说明了数据集构建、人机协作实验的设计、模型提示模板以及人机交互的示例。重点在于： - **任务标准化**：确保任务描述和代码格式清晰、统一。 - **人机协作机制**：通过提示和反馈机制，提高模型的理解和生成能力。 - **评估方式**：通过测试用例和错误反馈，验证模型输出的正确性。 这些内容为构建高质量的程序合成数据集以及优化人机协作流程提供了有力支持。