论文翻译：增强大型语言模型的代码调试能力：基于通讯代理的数据精炼框架

原文链接：https://arxiv.org/pdf/2408.05006

---

增强大型语言模型的代码调试能力：基于通讯代理的数据精炼框架

作者：Weiqing Yang（东北大学，沈阳，中国）、Hanbin Wang（北京大学，北京，中国）、Zhenghao Liu（东北大学，沈阳，中国）、Xinze Li（东北大学，沈阳，中国）、Yukun Yan（清华大学，北京，中国）、Shuo Wang（清华大学，北京，中国）、Yu Gu（东北大学，沈阳，中国）、Minghe Yu（东北大学，沈阳，中国）、Zhiyuan Liu（清华大学，北京，中国）、Ge Yu（东北大学，沈阳，中国）

摘要
调试是软件开发中至关重要的环节，但大型语言模型（LLMs）的调试能力尚未被广泛探索。本文首先介绍了DEBUGEVAL，一个全面的基准测试，用于评估LLMs的调试能力。DEBUGEVAL收集了现有高质量数据集的数据，并设计了四种不同的任务来评估调试效果，包括BUG定位、BUG识别、代码审查和代码修复。此外，为了提高LLMs的代码调试能力，本文提出了一种基于通讯代理的数据精炼框架（MASTER），该框架生成经过精炼的代码调试数据，用于监督微调。具体而言，MASTER采用“代码问答器”根据DEBUGEVAL定义的任务生成精炼数据，然后“代码学习者”作为评论员，保留其无法解决的问题，最后“代码教师”提供基于连锁思维的详细解决方案。我们收集了合成的数据，并微调了代码学习者以增强其调试能力，进而形成NeuDebugger模型。我们的实验在DEBUGEVAL的零样本环境中评估了各种LLMs和NeuDebugger。实验结果表明，这些规模为7B的LLMs的调试能力较弱，甚至包括那些面向代码的LLMs。然而，规模较大的模型（超过70B）显示出令人信服的调试能力。进一步的分析表明，MASTER通过合成用于监督微调的数据是一种有效的方法，可以增强LLMs的代码调试能力。所有数据和代码可在https://github.com/NEUIR/DebugEval获得。

关键词—代码调试、大型语言模型、DEBUGEVAL基准、数据优化、代理

I. 引言

在软件开发领域，代码调试是确保应用程序功能和可靠性的不可或缺的过程 [1], [2]。随着软件系统复杂性的增长，传统的调试方法通常依赖于启发式方法 [3], [4] 和预定义模式 [5], [6]，正逐渐达到其局限性。大型语言模型（LLMs） [7], [8] 的新兴能力为自动化调试开辟了新视野，提供了一种更灵活和全面的方法来识别和纠正代码错误 [9]。

*表示两位作者对本文贡献相同。
† 表示通讯作者。

LLMs的能力已在代码相关任务如代码生成和翻译方面得到了广泛探索 [10]–[14]，然而它们的调试能力仍然相对未被深入研究。最近，研究人员开始关注使用LLMs进行自我调试，以迭代修复有缺陷的代码 [9], [15], [16]。为了更好地评估代码调试能力，研究人员现在正在建立基准来评估LLMs的代码调试能力 [17], [18]。然而，现有的代码调试基准面临两个主要问题：1）它们主要围绕代码修复设计任务，这不足以全面评估代码调试能力；2）使用GPT-4 [19] 构建有缺陷的代码无法捕捉到真实开发环境中遇到的代码错误的复杂性和多样性。

为了解决这些挑战，本文介绍了DEBUGEVAL，一个旨在评估LLMs调试能力的综合基准。DEBUGEVAL引入了四个任务：错误定位（BUG Localization）、错误识别（BUG Identification）、代码审查（Code Review）和代码修复（Code Repair），这些任务旨在测试LLMs不仅识别和分类错误的能力，还包括提供正确的代码解决方案。这些任务具有不同的难度级别，并代表了真实软件开发环境中常见的调试场景，使得评估既具有代表性又具挑战性。此外，DEBUGEVAL中的每个任务包括Python、C++和Java。此外，DEBUGEVAL结合了用户编写的有缺陷代码和GPT-4生成的有缺陷代码，以更好地模拟真实世界的软件开发。在收集用户编写的有缺陷代码时，我们还实施了严格的质量控制，以防止DEBUGEVAL中的数据泄漏。

此外，本文提出了一个基于沟通代理的数据优化框架（MASTER），旨在提高大型语言模型（LLMs）的调试能力。为了确保监督微调（SFT）数据的质量，MASTER定义了三个代理：代码测验器（Code Quizzer）、代码学习者（Code Learner）和代码教师（Code Teacher），它们协作合成高质量的代码调试数据以用于微调代码学习者。具体来说，代码测验器生成一组多样的代码调试问题，引导LLM在监督微调（SFT）过程中获取调试知识。然后，代码学习者作为批评者，评估合成问题的教育价值。代码学习者错误回答的问题被收集为SFT数据，代码教师为这些问题提供详细的解决方案和解释。最后，我们使用合成的SFT数据微调代码学习者，并开发了我们的NeuDebugger模型。

我们在DEBUGEVAL上对13个开源和闭源LLMs进行了基准测试，并评估了NeuDebugger的整体性能。结果如图1所示，表明：1）具有7亿参数的模型表现出相对较弱的调试能力，而拥有70亿参数以上的模型和闭源模型表现更好。2）DeepSeek系列模型表现出优越的性能，其中开源模型DeepSeek-Coder-V2-0724优于闭源模型GPT-4o-mini。3）基于DeepSeek-Coder-6.7BIns和Llama3-8B-Ins的NeuDebugger-DS-6.7B和NeuDebugger-Llama3-8B分别在MASTER合成的数据上训练后，实现了27.7%和4.1%的提升，表明MASTER可以显著优化SFT数据以提升模型在调试任务上的表现。

进一步分析显示，仅为SFT收集数据并不能提升LLMs的调试能力 [20]。代码教师通过生成思维链（CoT）有效地在三个任务中教授代码学生：错误定位、错误识别和代码审查。然而，CoT结果在代码修复任务中降低了LLMs的性能，因为它们引入了额外的噪声并扰乱了代码结构。在SFT过程中，不同的模型表现出不同的学习行为。我们发现，合成数据可以显著提升面向代码的LLMs，如DeepSeek-Coder-6.7B-Ins，相较于通用LLMs，如Llama3-8B-Int。这些实验发现为未来研究如何增强LLMs的调试能力提供了重要的见解和方向。

II. 相关工作

本节首先介绍了一些用于代码理解和生成的基础模型，然后介绍了与代码调试和修复相关的研究工作。

面向代码的语言模型。为了定制用于代码理解的语言模型，相关研究主要集中在预训练语言模型，并引导它们学习代码的语法语义和惯用表达 [22]–[24]。CodeBERT 通过屏蔽自然语言（NL）和编程语言（PL）的词元，然后要求预训练语言模型填补被屏蔽的部分。接着，CodeBERT 遵循 ELECTRA 方法 [25]，预训练语言模型以检测词元是否被替换，这有助于模型更好地捕捉代码的语义 [26]。DOBF [27] 进一步考虑了代码相关任务的独特属性，更多地关注于屏蔽和生成代码段的类名、函数名和变量名。CodeT5 [28] 使用跨度屏蔽策略持续预训练 T5 模型 [29]，并通过更加关注代码中的标识符来优化屏蔽策略。这种预训练方法要求 T5 模型生成这些标识符，从而增强其在代码相关任务中识别和理解标识符信息的能力。此外，一些研究人员还结合了多模态数据源，如代码、注释和抽象语法树（AST），来预训练语言模型，这有助于通过对齐代码语义与自然语言之间的语义来提高代码理解能力 [30], [31]。

大型语言模型（LLMs）。近年来，诸如 ChatGPT [7] 和 Llama [8] 等大型语言模型在处理不同任务，特别是代码理解和生成任务方面展示了其卓越的能力。为了增强代码生成能力，一些广泛使用的 LLMs，如 ChatGPT [7]，在预训练语料库中混入了一些代码数据，这已被证明有助于增强 LLMs 的推理能力 [32]–[34]。一些典型的基于代码的 LLMs 还收集了不同代码相关任务的指令数据，以进行监督微调，这显著提升了 LLMs 的代码生成能力 [35]–[37]。尽管 LLMs 在生成代码段方面具有强大的效能，但生成的代码段通常包含错误 [9]，降低了生成代码的通过率。为了解决这些问题，现有的研究主要集中在采用迭代代码修复方法，持续优化生成的代码段 [9], [15], [16]。

---

代码调试与修复

早期的调试模型主要依赖于基于特征的方法，例如使用模板 [5], [6]、启发式规则 [3], [4] 或约束 [38], [39] 来修正有缺陷的代码。然而，这些基于特征的调试方法由于需要研究人员预定义的有限模式或规则，因此难以扩展到修正不同类型的错误和处理更复杂的代码缺陷。

随着预训练语言模型（Pre-trained Language Models, PLMs）的发展，相关工作也遵循先预训练后微调的策略来构建调试模型，以应对现实生活中出现的各种代码缺陷。例如，夏等人 [40] 使用面向代码的预训练模型 CodeX [41] 来探索 PLMs 在调试方面的能力。研究表明，CodeX [41] 在代码修复性能上表现出色，尤其是在 Python 和 Java 编程语言上。Kolak 等人 [42] 也使用 GPT-2 [43] 和 CodeX [41] 来评估它们在给定相应代码前缀时生成正确补丁行的有效性。所有这些研究都证明，基于 PLM 的调试模型的有效性主要依赖于预训练过程中获得的代码理解能力。

与以往的调试工作不同，近期的研究更多地关注于修正由大型语言模型（LLMs）生成的错误。SelfDebug [9] 促使 LLMs 生成代码审查，以帮助自身优化生成的代码，而 Self-Repair [44] 则结合了人类提供的反馈来修复有缺陷的代码。此外，Self-Edit [15] 训练了一个额外的故障感知编辑器，利用来自测试用例评估的错误消息和生成的代码段来修复代码。Wang 等人 [16] 进一步探讨了交互式修复链（Chain-of-Repair, CoR）的有效性，该方法利用 LLMs 生成修复代码的指南，通过结合生成的代码和来自代码编译器的错误消息。显然，这些代码修复模型的有效性主要依赖于 LLMs 的调试能力。

为了提升 LLMs 的调试能力，近期的工作更多地聚焦于生成用于监督微调的数据。InstructCoder [45] 采用 Self-Instruct 方法 [46] 构建了一个指令调优数据集，以提升 LLMs 在代码调试方面的有效性。Li 等人 [47] 进一步构建了 APR-INSTRUCTION 数据集，并利用该数据集使用四种不同的参数高效微调（Parameter-Efficient Fine-Tuning, PEFT）方法：LoRA [48]、p-tuning [49]、prefix-tuning [50] 和 (IA) [51] 对 LLMs 进行微调。为了进一步评估 LLMs 的调试能力，一些研究人员专注于构建基准来评估 LLMs。Wang 等人 [16] 从 Atcoder 网站收集了真实用户提交的有缺陷代码，构建了 CodeError，用于评估 LLMs 在 Python 代码上的修复能力。Tian 等人 [17] 进一步提出了 DebugBench，旨在探索 LLMs 在 Python、C++ 和 Java 上的调试能力。他们使用 GPT-4 [19] 在代码段中插入一些代码错误以合成有缺陷的代码，并要求 LLMs 修复这些代码。然而，仅仅进行代码修复任务不足以全面评估 LLMs 的调试能力。

III. 使用 DEBUGEVAL 评估 LLMs 的调试能力

在本节中，我们介绍了基准测试 DEBUGEVAL，该基准测试旨在从不同方面评估大型语言模型（LLMs）的调试能力。我们首先描述 DEBUGEVAL 中设计任务的任务定义（第 III-A 节）。然后，我们详细介绍了构建 DEBUGEVAL 基准测试的过程（第 III-B 节）。

A. 任务定义

DEBUGEVAL 引入了四个不同的任务来评估 LLMs 的调试能力。这些评估任务包括错误定位（BUG Localization）、错误识别（BUG Identification）、代码审查（Code Review）和代码修复（Code Repair）。

DEBUGEVAL 的数据统计如表 I 所示。对于每个任务，分别使用 Python、C++ 和 Java 提供问题，以评估 LLMs 在不同编程语言上的调试性能。错误定位、错误识别、代码审查和代码修复任务分别有 578、2320、2400 和 414 个测试实例，这些实例在三种编程语言之间几乎均匀分布。在本小节的其余部分，我们将在图 2 中展示这四个评估任务的示例，并深入描述每个评估任务。

错误定位（BUG Localization）。错误定位任务的重点是识别包含错误的具体代码行，这通常被视为调试过程的第一步。对于错误定位任务的每个测试实例，我们提供一个有缺陷的代码 P，从 P 中提取四个代码片段 {SA, SB, SC, SD}，然后要求 LLMs 识别包含错误的黄金代码片段 SE。

错误识别（BUG Identification）。在此任务中，LLMs 应该分类代码中发生的错误类型。具体来说，给定一个包含代码错误的程序 P，我们要求 LLMs 从四个选项中分类错误类型 E，包括语法错误（SyntaxError）、引用错误（ReferenceError）、逻辑错误（LogicError）和多重错误（MultiErrors）。语法错误表示代码包含语法错误。引用错误通常发生在代码尝试访问未声明或超出作用域的变量、函数或对象时。逻辑错误表示代码通常在语法上是正确的，但包含逻辑错误，未获得预期的输出。多重错误表示代码段包含语法错误、引用错误和逻辑错误等各种错误。

代码审查（Code Review）。对于代码审查任务，我们提供正确的代码 Ci 和有错误的代码 Ei，要求 LLMs 区分哪个是错误的。具体来说，Ci 和 Ei 之间只有少数代码片段不同。此外，我们在实验中交换 Ci 和 Ei 的选择标识符（A 和 B），以避免任何潜在的偏差。

代码修复（Code Repair）。代码修复任务要求为给定的有缺陷代码 P 生成修正后的版本 P′，这是对模型调试能力的最终测试。在这四个调试任务中，代码修复任务难度更大。它不仅涉及代码错误的检测/识别，还需要修正代码的错误。在生成修正代码 P′ 后，我们使用 n 个测试用例 X = {(x1, y1), …, (xn, yn)} 来评估 P′ 的正确性。具体来说，我们将测试用例的输入 xi 输入到修正后的代码 P′ 中，然后获得执行结果 P′(xi)。如果存在测试用例 (xi, yi) ∈ X 满足 P′(xi) ≠ yi，则表明代码 P′ 仍然包含需要解决的错误。代码修复任务的目标是将有缺陷的程序 P 转换为 P′，使其通过所有测试用例（∀(xi, yi) ∈ X, P′(xi) = yi）。

B. 数据构建细节

在本小节中，我们详细说明了 DEBUGEVAL 数据集的源数据收集和构建方法。

为了确保 DEBUGEVAL 的质量，我们从可靠的数据源收集高质量的数据，例如 DebugBench [17]、LiveCodeBench [52] 和 AtCoder 网站¹。

错误定位（Bug Localization）。对于错误定位任务，我们从 DebugBench 中抽取测试实例。具体来说，我们通过为每种编程语言的每种单一代码错误类型抽取最多 20 个实例来构建错误定位任务的数据集。我们将有缺陷的代码与正确的代码进行比较，找出包含错误的代码片段作为黄金选择 SE。为了构建其他混淆选项，我们丢弃错误代码片段，并随机抽取一行代码作为混淆选项之一。

错误识别（Bug Identification）。为了进行错误识别任务的评估，我们同样从 DebugBench 中抽取测试实例。具体而言，任务的选项被分为四种类型：语法错误（SyntaxError）、引用错误（ReferenceError）、逻辑错误（LogicError）和多重错误（MultiErrors），因此确保每种选项（代码错误类型）的平衡非常重要。对于每种编程语言，我们比较不同类型代码错误的测试样本集的大小，然后选择最小的集合作为抽样数量。最后，我们根据这个抽样数量从不同的代码错误测试集中抽取测试实例。

代码审查（Code Review）。我们首先混合 DebugBench 和 LiveCodeBench 的测试实例。然后，我们通过从混合数据集中随机抽取每种编程语言 800 个测试实例来收集测试对。每个测试实例包含有缺陷的代码和正确的代码，要求 LLMs 选择有缺陷的那一个。

代码修复（Code Repair）。对于代码修复，我们首先从 AtCoder 收集了 138 个新发布的编程竞赛问题，时间范围为 2023 年 9 月 1 日至 2024 年 4 月 1 日，以降低数据泄漏的风险。然后，我们收集了真实用户提交的有缺陷代码，并分别选择一个 Python、C++ 和 Java 的有缺陷代码。大量有缺陷的代码（82.7%）有以下提交版本，这些提交版本修正了有缺陷的代码并通过了所有测试用例，这些被视为有缺陷代码的黄金答案。对于其余的有缺陷代码（17.3%），我们使用不同的 LLMs 来修正这些有缺陷代码，直到修正后的代码通过所有测试用例。

总结。如表 II 所示，不同于其他调试基准测试，DEBUGEVAL 是一个多语言和多任务的调试基准测试，对 LLMs 的调试能力进行了更全面的评估。此外，DEBUGEVAL 包含由 GPT-4 和人类生成的有缺陷代码，使得评估更加令人信服、现实和真实。
IV. 基于沟通代理的数据优化框架

监督微调（Supervised Fine-Tuning, SFT） 已被广泛采用以提升大型语言模型（LLMs）在特定领域的性能 [37]。然而，SFT 依赖于标注数据的可用性和质量，这限制了其整体有效性。在这种情况下，本文引入了基于沟通代理的数据优化框架（MASTER），该框架自动优化用于监督微调的代码调试数据。如图 3 所示，我们向 LLM 提供任务示例，然后提示 LLM 扮演不同角色以合成 SFT 数据（第 IV-A 节）。最后，MASTER 使用不同的代理来优化合成的数据，以确保 SFT 数据的质量（第 IV-B 节）。

A. 代理构建

为了进行数据优化，MASTER 构建了三个代理，协作生成和优化调试问题数据，以合成高质量的 SFT 数据集。如图 4 所示，我们使用不同的提示语引导 LLM 扮演代码测验器（Code Quizzer）、代码学习者（Code Learner）和代码教师（Code Teacher）等角色。每个代理的详细描述如下。

代码测验器（Code Quizzer）。代码测验器旨在为 SFT 数据生成高质量的问题。它使用一个更强大的 LLM 作为基础模型，并提供以下指令：“你是一名代码调试专家，擅长生成代码调试问题以挑战程序员”。这种设置使代码测验器能够通过分析调试任务的示例来生成定制的问题。这些问题旨在评估代码学习者解决相应调试任务的能力。

代码学习者（Code Learner）。代码学习者与 SFT 模型共享相同的基础模型，并作为批评者评估代码测验器生成的问题的教育价值。使用以下提示语：“你是一名学生，请使用你自己的知识回答以下代码调试问题”，代码学习者的任务是基于其记忆的知识解决问题。

代码教师（Code Teacher）。受到先前工作的启发 [16]，我们还通过提示相同的 LLM 以“你是一名经验丰富且富有洞察力的调试器”为指令，开发了代码教师。这个提示语引导 LLM 作为一名熟练的代码调试器，生成基于思维链（Chain-of-Thought, CoT）的详细解决方案，以更好地指导 LLM 在 SFT 过程中的学习。

B. 基于沟通多代理的数据优化

MASTER 通过多代理协作实现自动化数据优化，利用更强模型的专业知识来增强较弱模型的能力。数据优化过程包括三个主要步骤。

步骤 A，代码测验器根据调试任务的示例合成各种代码调试问题。为了确保合成数据的多样性，我们指示代码测验器生成与 DEBUGEVAL 定义的任务（包括错误定位、错误识别、代码审查和代码修复）相一致的不同调试问题。每个调试任务的数据合成过程由一个单一示例引导，该示例作为示范 [59]。这种方法确保合成数据涵盖各种错误类型和难度级别，这对于在 SFT 代码学习者过程中从代码测验器/教师模型中提炼调试知识至关重要。

步骤 B，代码学习者尝试解决代码测验器提供的问题。在此步骤中，代码学习者作为批评者，评估每个合成问题对代码学习者的教育价值。如果代码学习者正确解决了问题，表明学习者已经具备解决该问题所需的知识，因此该问题被舍弃。另一方面，如果代码学习者提供了错误的解决方案，则将该问题保留为 SFT 数据，因为它对指导代码学习者具有教育价值。

步骤 C，代码教师审核保留的问题并生成详细的解释和解决方案。这些基于思维链的解释可能包括错误类型识别、错误解释和解决问题的正确方法。这些反馈对于代码学习者理解问题和优化其解决方案至关重要。代码教师生成的响应被视为合成问题的最终输出，形成用于微调我们的 NeuDebugger 模型的 SFT 数据。

V. 实验方法论

在本节中，我们描述了监督微调（SFT）策略、评估指标、被评估的基础模型的详细信息以及实验的实现细节。

监督微调策略。如表 III 所示，我们描述了不同监督微调策略的实验细节，包括基础 SFT 和 MASTER。

表 III
不同监督微调策略的数据统计

SFT 数据	数据来源	实例数量
人类/GPT-4	UltraInteract [35]	154,347
	InstructCoder [60]	6,913
	RepairLlama [61]	64,643
MASTER	错误定位数据	4,681
	错误识别数据	4,474
	代码审查数据	4,420
	代码修复数据	11,317

对于基础 SFT，我们从 UltraInteract [35]、InstructCoder [60] 和 RepairLlama [61] 收集 SFT 数据以微调 LLM。这些数据集由 GPT-4 生成或由人类标注，质量较高。对于 MASTER，我们通过使用多代理合成 SFT 数据。

评估指标。我们首先介绍用于在 DEBUGEVAL 上评估不同模型的评估指标。对于错误定位、错误识别和代码审查任务，LLMs 需要从给定问题的多个选项中给出一个答案。因此，我们使用准确率作为这三个任务的评估指标，这与之前的工作一致 [62]。特别地，对于代码审查任务，由于模型被要求在两个选项之间进行选择，我们打乱了选项的顺序以避免潜在的偏差。对于每条测试数据，只有在两种顺序下都回答正确时，模型才被认为是正确的。对于代码修复任务，我们遵循先前的工作 [11], [12], [63], [64]，使用 Pass@k [63] 来评估不同 LLM 的有效性：

$\text{Pass@k}:=\frac{\text{Number of problems passed}}{\text{Total number of problems}}$

其中 ( n ) 是样本总数，( c ) 是正确样本的数量，( k ) 是前 ( k ) 个样本的数量。在我们的实验中，我们设定 ( k = 1 )。

基础模型。我们在 DEBUGEVAL 上评估了 13 个 LLM，包括闭源和开源模型。

OpenAI GPTs。GPT-4o-mini-0718 [65] 和 GPT-3.5-Turbo-0125 [7] 是两个流行且强大的 LLM，属于 OpenAI 开发的 GPT 家族的不同变体。GPT-4o-mini-0718 是 GPT-4o 模型的轻量版本，但仍继承了 GPT-4o 的核心优势，包括强大的文本生成、逻辑推理和代码生成能力。这两个模型都是黑盒模型，提供商业 API 供使用。

Meta Llama。Llama2-7B-Ins [8] 是一个开源的 LLM。它使用高达 1.4 万亿个标记进行训练，其中 4.5% 是来自 Github 的代码标记。CodeLlama-7B-Ins [37] 进行了额外的指令调优阶段，以适应 Llama2 [8]，提高其在代码相关任务中的有效性。最近，发布了 Llama3 [68] 模型，这些模型相较于 Llama2 模型有了重大飞跃，并建立了新的最先进水平。

阿里云 Qwen。Qwen2-72B-Ins 是一个拥有 720 亿参数的 LLM。Qwen2-72B 采用多种自动化方法获取高质量的指令和偏好数据，使其在代码和数学任务上表现出色。CodeQwen1.5-7B-Ins [36] 是 Qwen1.5-7B [71] 的面向代码的版本。CodeQwen1.5-7B-Ins 使用约 3 万亿个代码相关数据进行调优。它支持 92 种编程语言，并支持长上下文理解和生成，具有 64K 个标记的上下文长度。

DeepSeek。DeepSeek 系列模型由 High-Flyer 发布。DeepSeek-LLM-7B [70] 从头开始训练，使用 2 万亿个英语和中文标记。DeepSeek-LLM-7B-Ins [70] 以 DeepSeek-LLM-7B 为初始模型，并使用额外的 100 万指令数据进行调优。DSCoder-6.7B-Ins [64] 和 DSCoder-33B-Ins [64] 从头开始训练，使用 2 万亿个标记，其中 87% 是代码，13% 是自然语言。DeepSeek-V2-0628 [66] 拥有 2360 亿参数，并采用专家混合（Mixture-of-Experts, MoE）架构进行高效训练和推理。它在一个包含 8.1 万亿个标记的高质量语料库上进行训练。DeepSeek-Coder-V2-0724 [67] 也是一个基于 MoE 的开源 LLM，在代码相关任务上与 GPT-4-Turbo 表现相当。DeepSeek-Coder-V2 从 DeepSeek-V2 的中间检查点开始，并使用 6 万亿个标记进行调优。

实现细节。对于所有 LLM，我们将生成温度设定为 0.2，最大生成长度设定为 1024 个标记。对于闭源模型，我们使用各自供应商提供的 API 端点，对于开源模型，我们使用 vLLM [73] 框架进行推理。对于 DEBUGEVAL 中的所有任务，我们在实验中使用零样本设置。为了微调 NeuDebugger 模型，我们使用 DeepSeek-Coder-6.7B-Ins [64] 和 Llama3-8B-Ins [68] 作为基础模型，并利用 MASTER 合成的相同数据作为 SFT 数据。在 SFT 过程中，所有模型均使用 Llama-Factory [74]，并使用 LoRA [75] 进行高效微调。在我们的实验中，我们将学习率设定为 2e-5，训练轮数设定为 1。我们使用 AdamW 优化器，批量大小设定为 8，梯度累积步数设定为 4。

VI. 评估结果

在本节中，我们在 DEBUGEVAL 上对 LLM 进行基准测试，并评估 NeuDebugger 的整体性能。然后，我们进行消融研究并讨论不同 SFT 数据量对模型性能的影响。下一项实验探索 NeuDebugger 在处理不同代码错误类型问题上的有效性。最后，展示案例研究。

表 IV
不同 LLM 在 DEBUGEVAL 上的评估结果
前三个任务，包括错误定位、错误识别和代码审查，使用准确率进行评估。代码修复使用 Pass@1 进行评估。在此，DS 代表 DeepSeek 模型，PY 代表 Python。

模型	错误定位	错误识别	代码审查	代码修复	平均值
GPT-4o-mini-0718 [65]	84.8 (PY)	81.0 (C++)	81.5 (JAVA)	82.4 (Avg.)	72.1
GPT-3.5-Turbo-0125 [7]	40.4 (PY)	47.2 (C++)	52.2 (JAVA)	46.9 (Avg.)	55.1
DeepSeek-V2-0628 [66]	82.0 (PY)	81.0 (C++)	85.9 (JAVA)	83.0 (Avg.)	72.2
DeepSeek-Coder-V2-0724 [67]	88.8 (PY)	83.1 (C++)	89.8 (JAVA)	87.2 (Avg.)	75.7
Llama3-70B-Ins [68]	74.2 (PY)	75.9 (C++)	82.0 (JAVA)	77.5 (Avg.)	58.0
Qwen2-72B-Ins [69]	79.8 (PY)	69.2 (C++)	74.6 (JAVA)	74.4 (Avg.)	57.6
DSCoder-33B-Ins [64]	52.2 (PY)	50.3 (C++)	51.7 (JAVA)	51.4 (Avg.)	39.1
Llama2-7B-Ins [8]	18.0 (PY)	20.0 (C++)	22.4 (JAVA)	20.2 (Avg.)	14.9
CodeLlama-7B-Ins [37]	27.0 (PY)	20.0 (C++)	23.9 (JAVA)	23.5 (Avg.)	31.9
CodeQwen1.5-7B-Ins [36]	29.2 (PY)	30.8 (C++)	38.0 (JAVA)	32.9 (Avg.)	35.1
DeepSeek-LLM-7B-Ins [70]	27.0 (PY)	19.0 (C++)	25.9 (JAVA)	23.9 (Avg.)	28.3
DSCoder-6.7B-Ins [64]	22.5 (PY)	25.6 (C++)	33.7 (JAVA)	27.5 (Avg.)	28.7
Llama3-8B-Ins [68]	55.6 (PY)	55.9 (C++)	61.0 (JAVA)	57.6 (Avg.)	53.8
NeuDebugger-DS-6.7B	62.4 (PY)	55.4 (C++)	59.0 (JAVA)	58.8 (Avg.)	56.4
NeuDebugger-Llama3-8B	64.6 (PY)	57.9 (C++)	61.0 (JAVA)	61.1 (Avg.)	53.8

A. 整体性能

不同规模的 LLM 在代码调试效能上表现出差异。总体而言，较大规模的 LLM 展示了更强的代码调试能力。如评估结果所示，参数超过 700 亿的 LLM 在各种调试任务上通常表现出一致的性能。错误定位和错误识别任务是多项选择题，随机猜测的准确率约为 25%。不幸的是，大多数 7B 规模的 LLM 在这两个任务上准确率低于 30%。这一现象强调了模型规模在保持新兴能力和通过监督微调（SFT）在代码数据上获取关键知识的重要性 [20], [35]。

在我们的实验中，我们选择 DSCoder-6.7B-Ins 和 Llama3-8B-Ins 作为基础模型，然后使用 MASTER 合成的数据微调这些 LLM，分别构建 NeuDebugger-DS-6.7B 和 NeuDebugger-Llama3-8B 模型。与其他 7B 规模的 LLM 相比，我们的 NeuDebugger 显著提升了基础模型的代码调试效能，并达到了与 700 亿参数模型相当的竞争性能。这表明构建高质量的 SFT 数据对于确保这些 7B 模型的代码理解和代码调试能力至关重要。此外，NeuDebugger-DS-6.7B 和 NeuDebugger-Llama3-8B 在 DEBUGEVAL 的四个任务上表现优于基础模型 DSCoder-6.7B-Ins 和 Llama3-8B-Ins，分别带来了 27.7% 和 4.1% 的提升。这些提升表明 MASTER 可以优化代码调试数据，显著提高模型在调试任务上的性能。

在 DEBUGEVAL 定义的四个任务中，LLMs 通常在错误定位和代码审查任务上表现更好。例如，GPT-4o-mini-0718 在这些任务上分别达到了 82.4 和 89.1 的准确率。这表明这些 LLM 通过微调代码生成任务，具备了强大的代码理解能力，能够有效地识别有缺陷的代码片段，并展示出更好的代码执行能力。相反，所有 LLM 在错误识别和代码修复任务上表现较差，这些任务更多地评估 LLM 的代码调试能力。对于错误识别任务，LLMs 需要识别错误的原因。这一任务上 LLM 的低效能表明当前 LLM 在推导错误原因方面存在困难。代码修复任务更为复杂，要求 LLM 不仅要定位有缺陷的代码片段，还要确定错误类型并修复代码。这些 700 亿参数的 LLM 在此任务上的次优表现进一步表明它们在自我调试方面面临挑战 [9]。这一现象在先前的研究中也有所观察到 [16]。研究人员通过结合来自代码编译器的额外反馈来修复代码，旨在提升 LLM 的调试能力。

表 VI
基础模型与 NeuDebugger 在不同错误类型上的表现
语法、引用、逻辑和多重错误分别代表 SyntaxError、ReferenceError、LogicError 和 MultipleErrors。

任务	模型	Python	C++	Java
错误识别	Llama3-8B-Ins	0.0 (Syntax)	3.7 (Ref)	97.9 (Logic)
	NeuDebugger-Llama3-8B	34.2 (Syntax)	16.8 (Ref)	27.9 (Logic)
	DSCoder-6.7B-Ins	3.2 (Syntax)	3.2 (Ref)	99.5 (Logic)
	NeuDebugger-DS-6.7B	54.2 (Syntax)	81.1 (Ref)	32.6 (Logic)
代码修复	Llama3-8B-Ins	40.0 (Syntax)	20.0 (Ref)	35.6 (Logic)
	NeuDebugger-Llama3-8B	90.0 (Syntax)	46.7 (Ref)	39.7 (Logic)
	DSCoder-6.7B-Ins	40.0 (Syntax)	33.3 (Ref)	38.4 (Logic)
	NeuDebugger-DS-6.7B	90.0 (Syntax)	46.7 (Ref)	45.2 (Logic)

B. 消融研究

消融研究旨在探索 MASTER 模型在微调 LLM 方面的有效性。我们比较了不同的 SFT 策略，包括基础 SFT、MASTER（Answer）、MASTER（CoT）和 NeuDebugger。基础 SFT 策略从 UltraInteract [35]、InstructCoder [60] 和 RepairLlama [61] 收集高质量的 SFT 数据，用于微调大型语言模型（LLMs）。然后，我们使用 MASTER 框架构建 SFT 数据，并探索三种不同的 SFT 策略：MASTER（Answer）、MASTER（CoT）和 NeuDebugger。MASTER（Answer）表示我们在 MASTER 中移除了代码教师，并要求 LLM 在 SFT 过程中直接给出正确的选项。MASTER（CoT）要求代码学生模仿代码教师的问题解决思维。NeuDebugger 方法通过混合两种 SFT 策略（MASTER（Answer）和 MASTER（CoT））的数据集，结合这两种 SFT 策略的数据进行微调，除了代码修复任务的 MASTER（CoT） 数据。

如表 V 所示，DSCoder-6.7B-Ins 和 Llama3-8B-Ins 在基础 SFT 方法下的表现均较基线更差，表明 SFT 数据的质量在微调 LLM 方面仍然是一个挑战。当使用 MASTER 合成的数据进行 SFT 时，这些模型的代码调试能力显著增强。这表明 DSCoder-6.7B-Ins 和 Llama3-8B-Ins 在从人类/GPT-4 标注的数据中学习调试知识方面效果较差 [20]。此外，MASTER（CoT）方法通常比 MASTER（Answer）取得更好的性能，除了代码修复任务。这可能是因为代码教师生成的思维链（CoT）结果能够更好地解释答案选项背后的原因，但在代码修复任务中可能会引入额外的噪声。通过结合 MASTER（CoT）和 MASTER（Answer） 的 SFT 数据，NeuDebugger 在所有 SFT 策略中表现最佳。所有这些实验结果证明了 MASTER 模型的有效性，该模型通过多代理合成和优化 SFT 数据。

C. 数据数量的影响

本小节探讨了在使用 MASTER 合成的数据微调 LLM 时，数据数量的影响。如图 5 所示，我们使用不同数量的 SFT 数据点微调了 DSCoder-6.7B-Ins 和 Llama3-8B-Ins 模型。然后，我们通过评估它们在 DEBUGEVAL 基准测试上的表现并可视化结果，来评估它们的调试能力。

与 Llama3-8B-Ins 相比，DSCoder-6.7B-Ins 在输入更多 SFT 数据点时表现出显著的性能下降。这表明面向代码的 LLM 更擅长从调试数据中学习，而标准语言模型在没有对代码的基本理解的情况下难以增强其调试能力。在所有调试任务中，DSCoder-6.7B-Ins 在错误定位、错误识别和代码审查任务上表现出显著的提升，而在代码修复任务上仅有轻微的提升。这表明这些调试任务确实有助于提升 LLM 的代码修复能力，尽管该任务仍然具有挑战性，难以显著提升。

D. NeuDebugger 在不同错误类型上的有效性

如表 VI 所示，我们展示了 NeuDebugger 在更具挑战性的任务（包括错误识别和代码修复）上的有效性。还展示了不同错误类型的评估结果。

对于错误识别任务，评估结果表明现有的 LLM 在调试任务上仍然表现不佳。DSCoder-6.7B-Ins 和 Llama3-8B-Ins 在逻辑错误上均达到了 97% 以上的准确率，但在其他错误类型上表现较差。此外，图 6 展示了 LLM 的答案分布。评估结果表明，DSCoder-6.7B-Ins 缺乏识别错误的能力，倾向于选择逻辑错误，从而在该特定错误类型上获得高准确率。NeuDebugger 通过实现更平衡的答案选择分布，并在错误识别任务上取得显著提升，展示了其有效性。

对于代码修复任务，我们观察到 NeuDebugger 在几乎所有类型的代码错误上都取得了提升，特别是在语法错误方面，显示出其在代码调试方面的有效性。这也表明，与其他三种代码错误类型相比，语法错误相对较简单，更容易被模型学习。此外，NeuDebugger 在修复包含逻辑错误或多重错误的代码时仍然存在困难。

E. 案例研究

最后，我们在图 7 中展示了两个案例，以展示 NeuDebugger 的有效性。NeuDebugger 在我们提出的 MASTER 框架构建的代码调试数据上进行训练。我们通过案例比较模型在训练前后的表现。

案例一：错误定位任务

在错误定位任务的第一个案例中，代码错误由 f = min(f, Cost(s[:x]) + A(s[x:], k-1’)) 行引起，该行中的索引 k-1’ 不正确。因此，正确答案是 ©。DSCoder-6.7B-Ins 将代码片段 if s[i]!=s[j]: c+=1 视为有错误的，并说明“这不是检查字符串是否为回文的正确方法”。相比之下，NeuDebugger-DS-6.7B 准确地分析了错误原因：“f = min(f, Cost(s[:x]) + A(s[x:], k-1’) 行中存在引用错误，应该是 k-1”，展示了其在错误定位方面的有效性。

案例二：代码修复任务

在代码修复任务的第二个案例中，错误涉及 continue 的误用，导致逻辑错误。DSCoder-6.7B-Ins 模型未能识别该错误，反而建议将 String s = jc.next().toLowerCase() 改为 String s = jc.nextLine().toLowerCase()。这种修改引入了新的错误，因为它未能正确处理输入。NeuDebugger-DS-6.7B 准确地识别出问题在于 continue 的使用，并将其更改为 break，成功修复了错误。

VII. 结论

本文提出了 DEBUGEVAL，一个创新的基准测试，旨在从多个角度评估大型语言模型（LLMs）的调试能力。我们引入了 MASTER，一种利用 LLM 生成高质量的监督微调（SFT）数据集的方法，专门针对调试任务，从而提升较小模型的性能。我们的实验表明，具有 7B 参数的 LLM 在这些调试任务上表现不佳，而 MASTER 通过优化 SFT 数据有效地增强了代码调试能力。

参考文献

[1] B. Hailpern 和 P. Santhanam, “软件调试、测试与验证，”IBM 系统期刊，卷 41，号 1，页 4–12，2002 年。

[2] L. Kirschner, E. Soremekun 和 A. Zeller, “调试输入，”发表于 ACM/IEEE 第42届国际软件工程会议论文集，2020 年，页 75–86。

[3] C. Le Goues, T. Nguyen, S. Forrest 和 W. Weimer, “Genprog：一种通用的自动软件修复方法，”IEEE 软件工程汇刊，页 54–72，2012 年。

[4] M. Wen, J. Chen, R. Wu, D. Hao 和 S.-C. Cheung, “上下文感知的补丁生成以提升自动程序修复，”发表于第40届国际软件工程会议论文集，2018 年。

[5] J. Hua, M. Zhang, K. Wang 和 S. Khurshid, “Sketchfix：一种使用懒候选生成的自动程序修复工具，”发表于2018年第26届ACM欧洲软件工程会议和软件工程基础研讨会联合会议论文集，2018 年。

[6] K. Liu, A. Koyuncu, D. Kim 和 T. F. Bissyandé, “Tbar：重新审视基于模板的自动程序修复，”发表于第28届ACM SIGSOFT国际软件测试与分析研讨会论文集，2019 年。

[7] OpenAI. (2022) ChatGPT：优化用于对话的语言模型。

[8] H. Touvron, L. Martin, K. Stone, P. Albert, A. Almahairi, Y. Babaei, N. Bashlykov, S. Batra, P. Bhargava, S. Bhosale 等, “Llama 2：开源基础和微调聊天模型，”ArXiv 预印本, 卷 abs/2307.09288, 2023 年。

[9] X. Chen, M. Lin, N. Schärli 和 D. Zhou, “教大型语言模型自我调试，”ArXiv 预印本, 卷 abs/2304.05128, 2023 年。

[10] M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. de Oliveira Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman 等, “评估在代码上训练的大型语言模型，”ArXiv 预印本, 卷 abs/2107.03374, 2021 年。

[11] Z. Luo, C. Xu, P. Zhao, Q. Sun, X. Geng, W. Hu, C. Tao, J. Ma, Q. Lin 和 D. Jiang, “Wizardcoder：通过 evol-instruct 赋能代码大型语言模型，”ArXiv 预印本, 卷 abs/2306.08568, 2023 年。

[12] Q. Zheng, X. Xia, X. Zou, Y. Dong, S. Wang, Y. Xue, L. Shen, Z. Wang, A. Wang, Y. Li 等, “Codegeex：一个用于代码生成的预训练模型，配备 Humaneval-x 上的多语言基准测试，”发表于第29届ACM SIGKDD知识发现与数据挖掘会议论文集，2023 年，页 5673–5684。

[13] R. Li, L. B. Allal, Y. Zi, N. Muennighoff, D. Kocetkov, C. Mou, M. Marone, C. Akiki, J. Li, J. Chim 等, “Starcoder：愿源代码与你同在！”，ArXiv 预印本, 卷 abs/2305.06161, 2023 年。

[14] D. Guo, Q. Zhu, D. Yang, Z. Xie, K. Dong, W. Zhang, G. Chen, X. Bi, Y. Wu, Y. Li 等, “Deepseek-coder：当大型语言模型遇上编程——代码智能的崛起，”ArXiv 预印本, 卷 abs/2401.14196, 2024 年。

[15] K. Zhang, Z. Li, J. Li, G. Li 和 Z. Jin, “Self-edit：面向故障感知的代码编辑器用于代码生成，”ArXiv 预印本, 卷 abs/2305.04087, 2023 年。

[16] H. Wang, Z. Liu, S. Wang, G. Cui, N. Ding, Z. Liu 和 G. Yu, “Intervenor：通过交互式修复链提示大型语言模型的编码能力，”发表于第62届计算语言学协会年会论文集，2024 年。

[17] R. Tian, Y. Ye, Y. Qin, X. Cong, Y. Lin, Z. Liu 和 M. Sun, “Debugbench：评估大型语言模型的调试能力，”2024 年。

[18] J. Guo, Z. Li, X. Liu, K. Ma, T. Zheng, Z. Yu, D. Pan, Y. LI, R. Liu, Y. Wang, S. Guo, X. Qu, X. Yue, G. Zhang, W. Chen 和 J. Fu, “Codeeditorbench：评估大型语言模型的代码编辑能力，”2024 年。

[19] J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. L. Aleman, D. Almeida, J. Altenschmidt, S. Altman, S. Anadkat 等, “GPT-4 技术报告，”ArXiv 预印本, 卷 abs/2303.08774, 2023 年。

[20] A. Gudibande, E. Wallace, C. V. Snell, X. Geng, H. Liu, P. Abbeel, S. Levine 和 D. Song, “模仿专有语言模型的虚假承诺，”发表于第12届国际学习表示会议，2024 年。

[21] J. Wei, X. Wang, D. Schuurmans, M. Bosma, B. Ichter, F. Xia, E. Chi, Q. Le 和 D. Zhou, “思维链提示引发大型语言模型的推理能力，”神经信息处理系统进展, 卷 35, 页 24824–24837, 2022 年。

[22] Z. Feng, D. Guo, D. Tang, N. Duan, X. Feng, M. Gong, L. Shou, B. Qin, T. Liu, D. Jiang 和 M. Zhou, “CodeBERT：用于编程和自然语言的预训练模型，”发表于计算语言学协会发现：EMNLP 2020。在线：计算语言学协会，2020 年，页 1536–1547。

[23] W. Ahmad, S. Chakraborty, B. Ray 和 K.-W. Chang, “统一的预训练用于程序理解和生成，”发表于2021年北美计算语言学协会分会会议：人类语言技术论文集。在线：计算语言学协会，2021 年，页 2655–2668。

[24] D. Zan, B. Chen, D. Yang, Z. Lin, M. Kim, B. Guan, Y. Wang, W. Chen 和 J. Lou, “Cert：针对库导向代码生成的持续预训练草图，”发表于国际人工智能联合会议，2022 年。

[25] K. Clark, M. Luong, Q. V. Le 和 C. D. Manning, “ELECTRA：将文本编码器预训练为判别器而非生成器，”发表于第8届国际学习表示会议，ICLR 2020，埃塞俄比亚亚的斯亚贝巴，2020 年4月26-30 日。OpenReview.net, 2020 年。

[26] S. Lu, D. Guo, S. Ren, J. Huang, A. Svyatkovskiy, A. Blanco, C. B. Clement, D. Drain, D. Jiang, D. Tang, G. Li, L. Zhou, L. Shou, L. Zhou, M. Tufano, M. Gong, M. Zhou, N. Duan, N. Sundaresan, S. K. Deng, S. Fu 和 S. Liu, “Codexglue：用于代码理解和生成的机器学习基准数据集，”发表于 NeurIPS 论文集，2021 年。

[27] M. Lachaux, B. Rozière, M. Szafraniec 和 G. Lample, “DOBF：针对编程语言的去混淆预训练目标，”发表于神经信息处理系统第34届进展：2021年神经信息处理系统年会，NeurIPS 2021，2021 年12 月6-14 日，虚拟会议，2021 年，页 14967–14979。

[28] Y. Wang, W. Wang, S. Joty 和 S. C. Hoi, “CodeT5：面向标识符的统一预训练编码器-解码器模型用于代码理解和生成，”发表于2021年自然语言处理经验方法会议论文集。在线和多米尼加共和国蓬塔卡纳：计算语言学协会，2021 年，页 8696–8708。

[29] C. Raffel, N. Shazeer, A. Roberts, K. Lee, S. Narang, M. Matena, Y. Zhou, W. Li 和 P. J. Liu, “通过统一的文本到文本转换器探索迁移学习的极限，”机器学习研究杂志，卷 21，页 140:1–140:67，2020 年。

[30] X. Li, Y. Gong, Y. Shen, X. Qiu, H. Zhang, B. Yao, W. Qi, D. Jiang, W. Chen 和 N. Duan, “CodeRetriever：用于代码搜索的大规模对比预训练方法，”发表于2022年自然语言处理经验方法会议论文集。阿布扎比，阿联酋：计算语言学协会，2022 年，页 2898–2910。

[31] D. Guo, S. Lu, N. Duan, Y. Wang, M. Zhou 和 J. Yin, “UniXcoder：用于代码表示的统一跨模态预训练，”发表于第60届计算语言学协会年会论文集（卷1：长论文）。爱尔兰都柏林：计算语言学协会，2022 年，页 7212–7225。

[32] Y. MA, Y. Liu, Y. Yu, Y. Zhang, Y. Jiang, C. Wang 和 S. Li, “在训练的哪个阶段代码数据有助于LLMs的推理？”发表于第12届学习表示国际会议。

[33] P. Liang, R. Bommasani, T. Lee, D. Tsipras, D. Soylu, M. Yasunaga, Y. Zhang, D. Narayanan, Y. Wu, A. Kumar 等, “语言模型的全面评估，”机器学习研究汇刊。

[34] Y. Fu, H. Peng 和 T. Khot, “GPT是如何获得其能力的？追踪语言模型新兴能力的来源，”姚富的 Notion, 2022 年。

[35] L. Yuan, G. Cui, H. Wang, N. Ding, X. Wang, J. Deng, B. Shan, H. Chen, R. Xie, Y. Lin 等, “通过偏好树推进LLM推理通用模型，”ArXiv 预印本, 卷 abs/2404.02078, 2024 年。

[36] J. Bai, S. Bai, Y. Chu, Z. Cui, K. Dang, X. Deng, Y. Fan, W. Ge, Y. Han, F. Huang, B. Hui, L. Ji, M. Li, J. Lin, R. Lin, D. Liu, G. Liu, C. Lu, K. Lu, J. Ma, R. Men, X. Ren, X. Ren, C. Tan, S. Tan, J. Tu, P. Wang, S. Wang, W. Wang, S. Wu, B. Xu, J. Xu, A. Yang, H. Yang, J. Yang, S. Yang, Y. Yao, B. Yu, H. Yuan, Z. Yuan, J. Zhang, X. Zhang, Y. Zhang, Z. Zhang, C. Zhou, J. Zhou, X. Zhou 和 T. Zhu, “Qwen 技术报告，”ArXiv 预印本, 卷 abs/2309.16609, 2023 年。

[37] B. Roziere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y. Adi, J. Liu, T. Remez, J. Rapin 等, “Code llama：面向代码的开源基础模型，”ArXiv 预印本, 卷 abs/2308.12950, 2023 年。

[38] S. Mechtaev, J. Yi 和 A. Roychoudhury, “Angelix，”发表于第38届国际软件工程会议论文集，2016 年。

[39] F. DeMarco, J. Xuan, D. Le Berre 和 M. Monperrus, “利用 SMT 自动修复有缺陷的 if 条件和缺失的前置条件，”发表于第6届国际软件测试、验证与分析约束研讨会论文集，2014 年。

[40] C. S. Xia, Y. Wei 和 L. Zhang, “在大型预训练语言模型时代的实用程序修复，”ArXiv 预印本, 卷 abs/2210.14179, 2022 年。

[41] M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. de Oliveira Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman, A. Ray, R. Puri, G. Krueger, M. Petrov, H. Khlaaf, G. Sastry, P. Mishkin, B. Chan, S. Gray, N. Ryder, M. Pavlov, A. Power, L. Kaiser, M. Bavarian, C. Winter, P. Tillet, F. P. Such, D. Cummings, M. Plappert, F. Chantzis, E. Barnes, A. Herbert-Voss, W. H. Guss, A. Nichol, A. Paino, N. Tezak, J. Tang, I. Babuschkin, S. Balaji, S. Jain, W. Saunders, C. Hesse, A. N. Carr, J. Leike, J. Achiam, V. Misra, E. Morikawa, A. Radford, M. Knight, M. Brundage, M. Murati, K. Mayer, P. Welinder, B. McGrew, D. Amodei, S. McCandlish, I. Sutskever 和 W. Zaremba, “评估在代码上训练的大型语言模型，”2021 年。

[42] S. D. Kolak, R. Martins, C. Le Goues 和 V. J. Hellendoorn, “利用语言模型生成补丁：可行性和扩展性表现，”发表于代码深度学习研讨会，2022 年。

[43] A. Radford, J. Wu, R. Child, D. Luan, D. Amodei 和 I. Sutskever, “语言模型是无监督的多任务学习者，”2019 年。

[44] T. X. Olausson, J. P. Inala, C. Wang, J. Gao 和 A. Solar-Lezama, “自我修复是代码生成的万能钥匙吗？”，发表于第12届学习表示国际会议，2023 年。

[45] K. Li, Q. Hu, X. Zhao, H. Chen, Y. Xie, T. Liu, Q. Xie 和 J. He, “Instructcoder：指令调优大型语言模型用于代码编辑，”2023 年。

[46] Y. Wang, Y. Kordi, S. Mishra, A. Liu, N. A. Smith, D. Khashabi 和 H. Hajishirzi, “Self-instruct：通过自生成指令对齐语言模型，”2022 年。

[47] G. Li, C. Zhi, J. Chen, J. Han 和 S. Deng, “参数高效微调在自动程序修复上的全面评估，”2024 年。

[48] E. J. Hu, Y. Shen, P. Wallis, Z. Allen-Zhu, Y. Li, S. Wang, L. Wang 和 W. Chen, “Lora：大型语言模型的低秩适应，”发表于第10届学习表示国际会议，ICLR 2022，虚拟会议，2022 年4月25-29 日。OpenReview.net, 2022 年。

[49] X. L. Li 和 P. Liang, “Prefix-tuning：优化生成的连续提示，”发表于第59届计算语言学协会年会和第11届自然语言处理国际联合会议（卷1：长论文）论文集。在线：计算语言学协会，2021 年，页 4582–4597。

[50] X. Liu, K. Ji, Y. Fu, W. Tam, Z. Du, Z. Yang 和 J. Tang, “P-tuning v2：提示调优在不同规模和任务上可以与微调相媲美，”康奈尔大学 - arXiv, 康奈尔大学 - arXiv, 2021 年。

[51] H. Liu, D. Tam, M. Muqeeth, J. Mohta, T. Huang, M. Bansal 和 C. Raffel, “少量样本参数高效微调比上下文学习更好更便宜。”

[52] N. Jain, K. Han, A. Gu, W.-D. Li, F. Yan, T. Zhang, S. Wang, A. Solar-Lezama, K. Sen 和 I. Stoica, “Livecodebench：用于代码的大型语言模型的全面且无污染评估，”ArXiv 预印本, 卷 abs/2403.07974, 2024 年。

[53] M. Yasunaga 和 P. Liang, “Break-it-fix-it：用于程序修复的无监督学习，”发表于第38届国际机器学习会议，ICML 2021，2021 年7月18-24 日，虚拟会议，机器学习研究论文集系列，卷139。PMLR, 2021 年，页 11941–11952。

[54] F. Huq, M. Hasan, M. M. A. Haque, S. Mahbub, A. Iqbal 和 T. Ahmed, “Review4Repair：代码审查辅助的自动程序修复，”信息与软件技术，页 106765，2022 年。

[55] S. Lu, D. Guo, S. Ren, J. Huang, A. Svyatkovskiy, A. Blanco, C. Clement, D. Drain, D. Jiang, D. Tang 等, “Codexglue：用于代码理解和生成的机器学习基准数据集，”ArXiv 预印本, 卷 abs/2102.04664, 2021 年。

[56] M. M. A. Haque, W. U. Ahmad, I. Lourentzou 和 C. Brown, “Fixeval：基于执行的编程问题程序修复评估，”发表于2023 IEEE/ACM自动程序修复国际研讨会（APR）论文集。IEEE, 2023 年，页 11–18。

[57] S. Yue, W. Chen, S. Wang, B. Li, C. Shen, S. Liu, Y. Zhou, Y. Xiao, S. Yun, W. Lin 等, “Disc-lawllm：微调大型语言模型用于智能法律服务，”ArXiv 预印本, 卷 abs/2309.11325, 2023 年。

[58] J. Wei, X. Wang, D. Schuurmans, M. Bosma, B. Ichter, F. Xia, E. Chi, Q. V. Le 和 D. Zhou, “思维链提示引发大型语言模型的推理能力，”神经信息处理系统进展, 卷 35, 页 24824–24837, 2022 年。

[59] T. B. Brown, B. Mann, N. Ryder, M. Subbiah, J. Kaplan, P. Dhariwal, A. Neelakantan, D. Amodei, J. Altenschmidt, S. Agarwal, A. Herbert-Voss, G. Krueger, M. Petrov, H. Khlaaf, G. Sastry, P. Mishkin, B. Chan, S. Gray, N. Ryder, M. Pavlov, A. Power, L. Kaiser, M. Bavarian, C. Winter, P. Tillet, F. P. Such, D. Cummings, M. Plappert, F. Chantzis, E. Barnes, A. Herbert-Voss, W. H. Guss, A. Nichol, A. Paino, N. Tezak, J. Tang, I. Babuschkin, S. Balaji, S. Jain, W. Saunders, C. Hesse, A. N. Carr, J. Leike, J. Achiam, V. Misra, E. Morikawa, A. Radford, M. Knight, M. Brundage, M. Murati, K. Mayer, P. Welinder, B. McGrew, D. Amodei, S. McCandlish, I. Sutskever 和 W. Zaremba, “语言模型是少量样本学习者，”发表于神经信息处理系统进展第33卷：2020年神经信息处理系统年会，NeurIPS 2020，2020 年12 月6-12 日，虚拟会议，2020 年。

[60] Q. Hu, K. Li, X. Zhao, Y. Xie, T. Liu, H. Chen, Q. Xie 和 J. He, “Instructcoder：赋能语言模型用于代码编辑，”ArXiv 预印本, 卷 abs/2310.20329, 2023 年。

[61] A. Silva, S. Fang 和 M. Monperrus, “Repairllama：高效表示和微调适配器用于程序修复，”技术报告，2023 年。

[62] M. Suzgun, N. Scales, N. Schärli, S. Gehrmann, Y. Tay, H. W. Chung, A. Chowdhery, Q. V. Le, E. H. Chi, D. Zhou 和 J. Wei, “挑战 big-bench 任务以及思维链能否解决它们，”2022 年。

[63] M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. D. O. Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman 等, “评估在代码上训练的大型语言模型，”ArXiv 预印本, 卷 abs/2107.03374, 2021 年。

[64] D. Guo, Q. Zhu, D. Yang, Z. Xie, K. Dong, W. Zhang, G. Chen, X. Bi, Y. Wu, Y. K. Li 和 W. Liang, “Deepseek-coder：当大型语言模型遇上编程——代码智能的崛起，”2024 年。

[65] OpenAI, “GPT-4o mini：推进成本效益高的智能，”2024 年。

[66] DeepSeek-AI, “Deepseek-v2：一个强大、经济、高效的专家混合语言模型，”2024 年。

[67] Q. Zhu, D. Guo, Z. Shao, D. Yang, P. Wang, R. Xu, Y. Wu, Y. Li, H. Gao, S. Ma 等, “Deepseek-coder-v2：突破闭源模型在代码智能领域的障碍，”ArXiv 预印本, 卷 abs/2406.11931, 2024 年。

[68] AI@Meta, “Llama 3 模型卡，”2024 年。

[69] “Qwen2 技术报告，”2024 年。

[70] DeepSeek-AI, “Deepseek llm：以长远主义扩展开源语言模型，”ArXiv 预印本, 卷 abs/2401.02954, 2024 年。

[71] Q. Team, “介绍 qwen1.5，”2024 年。

[72] W. Cai, J. Jiang, F. Wang, J. Tang, S. Kim 和 J. Huang, “专家混合方法的综述，”2024 年。

[73] W. Kwon, Z. Li, S. Zhuang, Y. Sheng, L. Zheng, C. H. Yu, J. E. Gonzalez, H. Zhang 和 I. Stoica, “使用分页注意机制进行大型语言模型服务的高效内存管理，”发表于ACM SIGOPS第29届操作系统原理研讨会论文集，2023 年。

[74] hiyouga, “Llama 工厂，”2023 年。

[75] E. J. Hu, Y. Shen, P. Wallis, Z. Allen-Zhu, Y. Li, S. Wang, L. Wang 和 W. Chen, “Lora：大型语言模型的低秩适应，”发表于第10届学习表示国际会议，ICLR 2022，虚拟会议，2022 年4月25-29 日。OpenReview.net, 2022 年。

---

---

1. https://atcoder.jp ↩︎