ISSTA 2024 | 北大提出CoderUJB，面向代码大模型的可执行多任务代码评估基准揭示真实能力与局限
论文地址：
代码地址：
研究背景和贡献
近期研究揭示了大型语言模型（LLMs）在复杂代码编程任务上的出色表现。除了通用 LLMs，还有针对软件工程任务定制的 Code-LLMs，如 CodeX、CodeLlama 和 StarCoder。为评估这类 LLMs 的编程能力，出现了多种基准测试集，如 HumanEval、CoderEval、CodeXGLUE 和 XCodeEval。
然而，现有基准测试集都存在局限性：如，HumanEval 仅关注 Python 独立函数生成能力，CoderEval 虽更贴合实际开发场景但仅涵盖单一函数生成任务，CodeXGLUE 的评估倚重基于相似度的评估指标，不涉及代码执行准确性的评估，XCodeEval 则聚焦编程竞赛问题而非典型软件开发场景。
因此，缺乏一个兼顾多编程任务、可执行性评估和符合实际软件开发场景的综合基准测试集，这阻碍了我们对 LLMs 在广泛的编程任务中性能的全面评估。
在此背景下，我们提出 CoderUJB，一个旨在评估 LLMs 在多种编程任务以及真实软件开发场景中性能的综合性 Java 基准测试集。
CoderUJB 的编程试题提取自 17 个开源 Java 项目，覆盖五种实际编程任务，其中包含 238 个功能性代码生成试题、140 个基于代码的测试生成试题、451 个基于 Issue 的测试生成试题、470 个自动程序修复试题和 940 个缺陷检测试题，共 2,239 个编程试题，每个问题附带完整的项目上下文（含源码与执行环境），以测试用例通过率为指标来评估 LLMs 的编程能力。
为展示 CoderUJB 对领域的贡献和价值，我们在 CoderUJB 下对现有的具有代表性的 LLMs 进行了全面实证研究，考察各 LLMs 的编程能力以及考察继续预训练与指令微调的影响。我们的研究发现：
当前 LLMs 在非功能性代码生成任务（尤其是缺陷检测）上表现欠佳。
优秀开源 LLMs 在功能性代码生成与测试用例生成任务上接近甚至超越 GPT-3.5-Turbo。
针对特定语言的继续预训练可能导致 LLMs 在其他语言下的性能下降，且该负面影响随下游任务与预训练任务相似性的减小而减弱。
不同任务对同一训练策略反应各异，凸显 CoderUJB 作为多任务综合评估基准的重要性。
指令微调对功能性代码生成与测试用例生成任务有负面影响，与 HumanEval 的评估结果相反，证明 CoderUJB 作为实际软件开发评估基准的实用价值。
本研究的主要贡献包括：
基准创建：发布 CoderUJB，用于评估 LLMs 在多元实际编程任务中的性能，含 2,239 个编程问题，具备完整程序上下文与可执行测试用例。
实证研究：运用 CoderUJB 对现有 LLMs 进行全面分析，探讨其在不同编码任务上的表现、特定语言继续预训练效果及指令微调对模型的影响。
启示：程序上下文对代码生成任务至关重要；需谨慎采用特定语言继续预训练，其效果难以预测，尤其当下游任务与预训练任务差异较大时；应谨慎使用指令微调，其可能降低 LLMs 在下游任务的性能，尤其是与预训练任务相似的下游任务；鉴于相同训练策略对不同下游任务的影响不同，更全面评估不可或缺。
数据集构建
为了全面评估 LLMs 在实际软件开发场景下的编程能力，CoderUJB 包含五个细分任务：功能性代码生成（FCG）、基于代码的测试用例生成（CTG）、基于 Issue 的测试用例生成（ITG）、缺陷检测（DD）和自动程序修复（APR）。
在 FCG 任务中，LLMs 必须根据函数注释准确地生成与之对应的函数代码实现，然后我们会执行相关的测试用例，以评估生成代码的正确性。在 CTG 任务中，LLMs 需要生成用于测试给定代码的测试用例，在该任务中我们还评估了测试覆盖率等性能指标。
ITG 任务要求 LLMs 从 Github Issue 的描述中提炼出关键信息，并据此设计出能够复现缺陷的测试用例。DD 任务则专注于 LLMs 检测代码中 Bug 的能力。至于 APR 任务，LLMs 需要在为给定的缺陷代码提供可行的代码修复方案。
CoderUJB 的编程试题精选自 Defects4j 数据集中的 17 个 Java 项目，以确保编程试题的质量和挑战性，该数据集因其出色的数据质量，已被先前的软件工程领域工作所广泛采用。
图一详细展示了 CoderUJB 编程试题的详细收集、筛选和构建流程。在构建流程中中，我们首先选择 Defects4j 中的 17 个开源项目的最新无缺陷版本作为原始项目库，因为这些版本经过持续的演变和开发，因此可能拥有最少的潜在缺陷并拥有更好的代码质量。
接下来，我们通过抽象语法树（Abstract Syntax Tree, AST）调查提取项目中所有的函数和测试用例。然后，如图一中“分析和过滤过程”所示，我们首先通过测试覆盖分析工具分析测试用例与函数之间的覆盖关系。
在此之后，我们收集每个函数相关的试题数据，包括函数体、注释、相关类的源代码和相关测试用例。随后，我们参照先前工作的指南，采用一系列的自动化规则和人工审核排除掉低质量数据。最终，为五个编程任务收集了 2,239 个编程试题。
▲ 图一：CoderUJB构建流程
为了确保 LLMs 能够生成高质量的代码，我们为每一任务都精心设计了相应的 Prompt，这些 Prompt 综合提供了程序上下文、任务描述、函数注释和函数签名等信息。我们也考虑了不同 LLMs 的调用模式，为基座模型和指令微调模型分别设计了补全式 Prompt 和对话式 Prompt。
图二展示了我们为功能性代码生成（FCG）任务设计的两种 Prompt 样例，可见每个 Prompt 包含当前类的上下文信息、任务描述、函数注释以及函数签名。同时，两类 Prompt 所含的上下文信息相同，以便我们对两类模型进行公平的比较。
▲ 图二：功能性代码生成任务Prompt示例
最后，在评估指标方面，我们考虑了多种丰富的评估指标，包含当前广受采用的 pass@k，用以表示 LLMs 成功解决试题数量的 count@n、用以评估测试覆盖率的 coverage@n，和常用的 accuracy。以进行全面和准确的评估分析。
实验结果与分析
本节旨在运用 CoderUJB 平台对当前主流 LLM（大型语言模型）进行深度评估，聚焦于对研究人员具有重要意义的问题，并展现 CoderUJB 对推动该领域发展的贡献。
3.1 研究问题及对象
我们关注以下核心问题：
RQ1：开源与闭源 LLM 在 CoderUJB 上的性能对比如何？
RQ2：针对特定编程语言（PL）数据的继续预训练如何影响 LLM 在 CoderUJB 中的代码生成能力？
RQ3：指令微调如何改变 LLM 在 CoderUJB 中的表现？
我们研究对象涵盖现有的主流开源 Code-LLM（CodeLlama 系列、StarCoderBase 以及 CodeShell）及闭源商业 LLM（GPT-3.5-Turbo、GPT-4等）。
3.2 结果与分析
▲ 表一：CoderUJB 评估结果，p-a@k 表示 pass@k，c-a@k 表示 count@n，其中绿色结果表示微调后 LLM 优于原 LLM，红色结果表示微调后 LLM 差于原 LLM。
▲ 图三：CoderUJB 下开源 LLMs 和闭源 LLMs 的 pass@k=1 与 accuracy 结果。
RQ1：开源与闭源LLMs在CoderUJB上的表现
表一呈现了 LLMs 在 CoderUJB 下的评估结果。图三通过 pass-all@k=1 与准确率雷达图更直观展示 LLMs 间的性能。
结合表一与图三，我们发现现有 LLMs 在 CoderUJB 下的表现不及在 HumanEval 与 CoderEval 中的成果。具体来说，CodeLlama-34B 与 GPT-4 在功能代码生成任务中的 pass-all@k=1 仅为 22.82 与 30.52，远低于在 HumanEval 上的 45.11 和 67.00 。这些发现凸显了 CoderUJB 等高难度基准的价值，表明其提供比 HumanEval 与 CoderEval 更具挑战性的编程问题。
此外，我们的实验结果显示，开源与闭源 LLM 在不同任务中性能差异明显。在功能代码生成任务下，开源 LLM CodeLlama-34B 与优秀闭源模型 GPT-3.5-Turbo 表现相当。在两个测试生成任务中，CodeLlama-34B 甚至超越 GPT-3.5-Turbo。然而，在自动程序修复任务上，最佳开源 LLM WizardCoder-Python-34B 与 GPT-3.5-Turbo 之间仍存在显著差距。
结论1：当前 LLMs 在 CoderUJB 上面对真实编程挑战（尤其是缺陷检测）成绩不尽人意，近乎随机猜测。
结论2：开源 LLM 已取得显著进步，在功能代码生成与两个测试生成任务上达到或超越 GPT-3.5-Turbo，但在自动程序修复任务上仍表现不佳。GPT-4 在所有 LLM 中遥遥领先，揭示模型规模扩大仍是提升性能的有效手段。
RQ2：特定编程语言数据继续预训练对Code-LLM编程能力的影响如何？
为解答此问题，我们对比了表一中 Base-LLMs 与特定编程语言（PL）LLMs 在 CoderUJB 上的表现差异。结果表明，特定编程语言继续预训练的效果因任务类型而异。
对于功能代码生成（FCG）任务，针对性编程语言训练能提升 LLMs 在相应编程语言任务下的表现，但可能损害其在其他编程语言任务下的性能。这与学术共识一致：领域训练提升领域内任务性能的同时可能削弱领域外任务。
然而，在更高难度任务如基于 Issue 的测试用例生成（ITG）与自动程序修复（APR）中，特定编程语言训练的影响变得随机且不显著。我们认为，测试生成与自动程序修复任务与预训练任务差异较大，导致特定 PL 训练效果难以预测。相反，当下游任务与预训练任务相似度高（如功能代码生成），性能增减更显著和可预测。上述差异性结果进一步突显了 CoderUJB 作为综合性编程评估基准的价值，覆盖多种编程难题。
结论3：特定编程语言训练的影响与下游任务与预训练任务的差异程度相关。任务越相似（如功能代码生成），性能影响越可预测且显著；任务差异越大（如自动程序修复），特定编程语言训练效果则趋于不可预测。
RQ3：指令微调对Code-LLM编程能力的影响如何？
▲ 表二：语法检查通过率（p-s@1）和编译通过率（p-c@1）结果
我们对比了表一中指令微调 LLM 与未微调基模型在编程任务上的表现。结果显示，指令微调对功能代码生成（FCG）与测试生成任务多有负面影响，如CodeLlama-Instruct-13B 在 FCG 任务中 𝑝𝑎𝑠𝑠-𝑎𝑙𝑙@𝑘 指标较其基座模型下降明显。
为探查性能下降原因，我们在表二分析了代码生成任务的 𝑝𝑎𝑠𝑠-𝑠𝑦𝑛𝑡𝑎𝑥@𝑘=1 和 𝑝𝑎𝑠𝑠-𝑐𝑜𝑚𝑝𝑖𝑙𝑒@𝑘=1。微调 LLM 生成代码语法正确性与基模型相当，说明问题在于生成解决方案质量低，而非语法错误。
这一现象在多数开源指令微调 LLM 中普遍存在，与 HumanEval 中微调显著提升性能的情况形成对比。我们认为，HumanEval 的独立函数生成任务相对简单，未能充分反映真实开发场景的复杂性，而 CoderUJB 通过其设计弥补了这一差距，从而导致指令微调在两基准间产生不同效应，凸显了 CoderUJB 作为实用编程评估基准的价值。
然而，在自动程序修复任务中，指令微调确实提升了模型性能，这一趋势普遍存在于多数微调 LLM 中。我们认为，这是由于自动程序修复任务格式与预训练任务显著不同，导致基座 LLM 的表现不佳，而指令微调通过引入不同任务格式数据提高了 LLM 适应性与泛化能力，从而改善了 LLM 在自动程序修复任务上的表现。
结论4：指令微调在与预训练任务高度一致的任务（如功能代码生成和测试生成）中降低 LLM 性能，而在与预训练任务格式迥异的任务（如自动程序修复）中提升表现。我们建议开展更多研究，探寻 LLM 更有效的微调策略。
总结
CoderUJB 通过整合 17 个开源 Java 项目的真实执行环境，构建起一个高度贴近现实软件工程场景的评估平台，有力推动了对大型语言模型（LLM）在软件工程领域适用性的研究。
本研究揭示了 LLM 在非功能代码生成与缺陷检测等关键任务中的性能瓶颈，揭示了继续预训练与指令微调过程中潜在的性能波动问题，即这两种策略在特定情境下可能非但未能增强 LLM 能力，反而引发意外的性能下滑。
这一发现强调了对 LLM 进行训练时，必须采取精细化策略，兼顾广泛的任务类型，以确保其在面对多样化编程任务时展现出强大适应性和可靠性。换言之，CoderUJB 不仅提升了评估 LLM 在软件工程应用中性能的标准，而且通过揭示 LLM 训练过程中的影响，为后续研究指明了方向。
更多阅读
#投 稿 通 道#
让你的文字被更多人看到
如何才能让更多的优质内容以更短路径到达读者群体，缩短读者寻找优质内容的成本呢？答案就是：你不认识的人。
总有一些你不认识的人，知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁，促使不同背景、不同方向的学者和学术灵感相互碰撞，迸发出更多的可能性。
PaperWeekly 鼓励高校实验室或个人，在我们的平台上分享各类优质内容，可以是最新论文解读，也可以是学术热点剖析、科研心得或竞赛经验讲解等。我们的目的只有一个，让知识真正流动起来。
📝 稿件基本要求：
• 文章确系个人原创作品，未曾在公开渠道发表，如为其他平台已发表或待发表的文章，请明确标注
• 稿件建议以 markdown 格式撰写，文中配图以附件形式发送，要求图片清晰，无版权问题
• PaperWeekly 尊重原作者署名权，并将为每篇被采纳的原创首发稿件，提供业内具有竞争力稿酬，具体依据文章阅读量和文章质量阶梯制结算
📬 投稿通道：
• 投稿邮箱：hr@paperweekly.site
• 来稿请备注即时联系方式（微信），以便我们在稿件选用的第一时间联系作者
• 您也可以直接添加小编微信（pwbot02）快速投稿，备注：姓名-投稿
△长按添加PaperWeekly小编
🔍
现在，在「知乎」也能找到我们了
进入知乎首页搜索「PaperWeekly」
点击「关注」订阅我们的专栏吧