基本信息

2024ACL

博客贡献人

田心

作者

Yuze Zhao, Zhenya Huang, Yixiao Ma, Rui Li, Kai Zhang, Hao Jiang, Qi Liu, Linbo Zhu, Yu Su

摘要

程序可靠性的重要性与人工修复的高成本之间的矛盾，使得自动化程序修复（Automated Program Repair, APR）成为不可或缺的研究方向。APR能将存在缺陷的程序转化为更健壮的版本，不仅提升程序的可靠性，也显著降低人工修复所带来的经济负担。商业级的语言模型(LM)将APR提升到了前所未有的水平。然而，研究发现，当模型参数规模较小（如少于 100B 参数）时，仅通过单步修改往往难以实现理想修复效果。此外，传统的人机交互方式主要依赖显式提示（prompts），使得模型无法像人类一样从编译器和测试用例反馈中获得指导，从而自动优化自身的修复策略。

在本文中，我们探讨了小规模LM（小于20B参数）如何通过过程监督与反馈实现优异的性能。我们首先构建一个名为CodeNet4Repair的数据集，其中包含多个修复记录，用于监督基础模型的微调。在此基础上，我们借鉴强化学习的思想，我们进一步训练了一个奖励模型（Reward Model），作为评判器，为微调后的LM提供反馈，逐步优化其修复策略。在推理过程中，我们要求LM迭代生成解决方案，直到修复效果不再提升或达到最大步长限制。

实验结果表明，这种基于过程反馈的修复框架不仅超越了依赖结果监督的生成方法，而且在性能上几乎可与闭源商业级LLMs相媲美。

1 引言

自计算机程序诞生以来，程序的可靠性一直是核心关注点。大语言模型（Large Language Models, LLMs）自动生成代码的能力，进一步加剧了这种担忧。程序修复（Program Repair）以存在缺陷的程序为输入，通过错误定位、修正和测试来增强程序的稳定性和正确性。这一过程在软件开发和编程竞争中通常是具有挑战性的。特别是，当程序仅在某些罕见或极端输入下才会触发错误时，程序员往往需要投入大量时间和专业经验去发现并修复问题。一个高效的自动化程序修复系统（Automated Program Repair, APR），能够显著降低修复门槛与时间成本，从而提高程序整体的可靠性。

早期研究通常将 APR 视为一个序列到序列（sequence-to-sequence）的任务。大语言模型（LLMs）凭借其庞大的参数量和训练数据，可以通过零样本或少样本学习来解决这一问题。然而，这种传统做法有两大局限：

1）无论是传统方法还是 LLMs，它们通常都通过一次修改来完成修复。这种基于结果（outcome-based）的监督方式，需要模型在一次生成中跨越较大的编辑距离，对模型学习提出了极高的要求。

2）同时，这种“单步修改”的方式也与人类的行为模式不符。人类程序员在面对复杂 bug 时，通常采用一种循环式的修复模式：先进行修改，再通过编译器与测试反馈验证，然后再进行后续修正。这启发我们关注 APR 任务中的修改过程。与基于结果的监督不同，基于过程（Process-based）的方法要求在每一步修改中都提供指导和监督。

Figure 1: 参赛者在编程竞赛平台上完善解决方案的一般流程。

图1展示了编程竞赛中选手改进代码的典型流程：该流程由编译器和测试用例引导:参赛者首先根据题意和约束条件构建程序的初步版本，然后通过不断提交、获取反馈、进行交互来完成修复。

举个例子：在解决“寻找数组中出现次数超过 n/2 的元素”这一问题时，他们最初可能尝试通过排序并选择中间元素来解决，却因时间复杂度为O(nlogn)，遇到时间限制；于是改用统计频率的哈希表方法，却因空间复杂度为O(n)，而触发内存限制；最终，他们发现 Boyer-Moore 投票算法可在题目约束条件下解决问题。

这个例子说明了基于过程的程序修复的特点：需要持续与编译器和测试用例交互，以反馈为导向进行修复。然而，将这种基于过程的反馈应用于LM存在以下几个困难：

1）缺乏过程数据集：缺乏现实世界中的基于过程的数据集是阻碍相关研究的主要障碍。

2）中间步骤难以直接监督：APR 任务中中间过程的监督方式仍在探索中。此前的一些研究在数学推理任务中探索了基于过程的监督，这些研究要求中间步骤必须是正确的；但在 APR 中，中间步骤往往是错误的，不能直接作为训练信号。

3）反馈信号难以融入训练：虽然可以通过显式提示工程（prompt）与LM交互，但这种方式难以准确构建人类意图，也无法替代编译器和测试用例提供的精确反馈。

在本文中，据我们所知，我们首次全面探索了在 APR 任务中，将基于过程的反馈（process-based feedback）与语言模型（LM）结合的可能性。为此，我们首先构建了一个名为 CodeNet4Repair 的多步程序修复数据集。每个样本记录从错误代码到最终正确代码的整个修复轨迹，包括编译状态、测试结果、资源使用情况等。接着，我们提出了一个名为 RePair 的基于过程反馈的 APR 框架。RePair 包含两个模型：奖励模型（reward model）和修复模型（repair model）。我们首先训练奖励模型，使其作为“虚拟编译器”，接收程序文本并判断程序状态。修复模型则对错误程序进行逐步修复，每次修改后将程序状态交由奖励模型评估，并根据反馈调整下一步的修复策略。最终，我们使用 pass@k （见4.4 评估指标）作为评估指标，客观衡量修复质量。

2 数据收集

据我们所知，目前尚不存在一个专门用于程序修复任务、并包含修复过程信息的数据集。因此，我们尝试构建一个面向过程建模的程序修复数据集。总体而言，该数据集包括以下内容：

• 问题描述

• 题目的内存与时间限制

• 修复过程（即最初的错误程序到最终正确程序的一系列程序版本）

• 执行过程中的资源使用情况（内存占用、CPU 时间、代码长度）

我们从CodeNet这一大规模编程竞赛数据集中提取原始数据，并对其进行清洗与过滤，以保证数据质量。具体步骤包括：澄清问题描述、清理程序代码、收集高质量的测试用例，并将程序整理为基于过程的格式。

在表1中，我们将CodeNet4Repair与其他已有数据集进行对比，展示了其独特优势：包含测试用例、问题描述以及详细的修复步骤。CodeNet4Repair的测试集中包含10,144个复杂的程序修复过程，均来源于真实竞赛场景。

Table 1: CodeNet4Repair 数据集与现有程序修复数据集的比较。

2.1 问题描述收集

即使是专业的程序员，在修复程序时也需要了解程序要解决的问题是什么。CodeNet为每道题提供了以HTML格式存储的原始题目描述，但这些内容结构复杂且混乱。我们使用正则表达式从这些HTML文件中提取描述内容，并对难以识别的部分进行人工补充，例如通过OCR（光学字符识别）技术辅助提取。

2.2 程序初步过滤

我们选择Python作为基准语言。并设计了以下初步过滤规则：

1）去除重复提交：无意义的重复或抄袭提交对程序修复无益。

2）去除恶意提交：包括自动化的破坏行为、攻击平台代码的无效代码，或干扰系统运行的破坏性代码。

3）去除泄露隐私的提交：某些IDE会自动生成包含作者信息的注释，可能泄露身份。

4）确保每个修复过程至少包含一个“AC”提交：只保留那些至少有一个提交版本被评测系统标记为 “AC” 的问题。

经过初步过滤后，我们获得了1,227,259份提交程序。在精细过滤之前，我们还去除了代码注释中的所有非英文字符。

2.3 程序精细过滤

虽然原始CodeNet数据集提供了程序执行状态(例如，“WA”或“AC”)，但由于Python版本和环境的差异，这些状态可能会有所不同。为此，我们搭建了标准的Python 3.11.3运行环境，并使用测试用例逐一重新执行这1,227,259份程序，以确保状态一致性。假设每份程序平均执行时间为4秒，忽略进程切换等额外开销，我们总共需要CPU时间。最后，我们得到了278,408个状态一致的程序。对每个题目，我们按照时间顺序排列对同一用户的多次提交排序，确保最后一个版本是“AC”的。

为了提高评估精度，我们还在网上收集并手动标注了高质量测试用例，并将其作为隐藏测试用例加入数据集中。最终，我们将这些程序组织成一个无信息泄露、基于过程的程序修复数据集，命名为CodeNet4Repair。

3 方法论

我们的基座模型选用 StarCoderBase，这是一个 15.5B 参数、8K 上下文长度的代码预训练LM，训练语料为 The Stack 的 1 万亿 token。图 2 总结了训练RePair的流程。

Figure 2: 基于过程的自动程序修复示意图，结合编译器和测试用例反馈：（1）引入一个无信息泄露、基于过程的程序修复数据集，称为 CodeNet4Repair。（2）在预训练语言模型上应用监督微调（SFT）。（3）通过强化学习（RL）引入基于过程的反馈。此过程包括：建立作为评论员的奖励模型，语言模型根据评论员的反馈调整其修复策略。SFT 和 RL 都在 CodeNet4Repair 训练集上进行训练。

3.1 对APR任务的监督微调（SFT）

A.1: 程序修复的提示模板。

为了让LM理解程序修复任务，我们采用附录 A.1 的提示模板进行监督微调（SFT）。给定一段有缺陷的程序序列，LM需输出一段能通过全部测试的健壮程序其中为词汇表。在训练阶段，通过最大化输出与真值的对数似然来学习模型参数。训练目标是最小化以下损失：

其中是整个数据集的期望，是时间步长之前的部分序列。

3.2 基于过程的反馈

经过 SFT 后，模型已能在给定 的条件下提供一个可能的解决方案 ，但这个模型缺乏来自编译器与测试用例的过程级监督与反馈。为了确保LM可以通过交互逐步完善程序，我们引入了强化学习(RL)：把微调后的LM视为演员（actor），给定一个状态  ，它的输出  被认为是一个动作。用奖励模型充当评论家（critic），根据动作给予反馈，指导演员持续优化策略。

3.2.1 奖励建模

我们不直接调用编译器与测试用例，而是训练了一个奖励模型(RM)来评估程序质量。主要原因可以归结为两点:

1）训练阶段直接与环境交互会严重拖慢吞吐。cuda中批量处理的张量必须首先被转移到内存中进行解码，依次进行语法检查和用例测试;在提供反馈时，将这些结果重新编码并发回cuda。这个过程大大降低了吞吐量——这是一个难以承受的成本。

2）在推理阶段，无法获取错误程序的隐藏测试用例，直接反馈会损害泛化性能。

我们首先凭经验定义了一个基于程序质量从高到低的非严格偏序:

（AC=通过，PE=格式错，WA=答案错，TLE=超时，MLE=超内存，CE=编译错，RE=运行错）

然后，基于上述偏序，采用成对排序学习（Pairwise Ranking）训练奖励模型 。奖励模型的目标是学习一个函数​，使其对程序的打分结果符合这种偏序关系。

对于同一道题的两个提交结果  和  ：如果 ​ 的评测状态优于 ​（例如 是 WA，而 是 CE），则希望模型满足：

通过最小化标准的成对排序损失（pairwise ranking loss）训练奖励模型：

3.2.2 强化学习

在前两节中，我们微调了一个LM，并开发了一个能够通过优化损失  和  来现实地评估程序状态的奖励模型。在本节中，我们将利用强化学习（RL）通过与微调后的LM和训练良好的奖励模型进行多次交互，来完成程序修复。我们采用近端策略优化（Proximal Policy Optimization, PPO）算法来微调我们的LM。LM充当演员（actor），根据输入程序（状态）和LM的策略 （即LM参数 ）生成修复后的程序（动作）。训练好的奖励模型充当评论家（critic），评估修复的效果，并相应地给予LM奖励。我们的目标是通过最大化这些奖励来优化LM的参数 θ。

更具体地说，我们通过最大化以下目标函数来对过程进行监督：

其中 是基于输入和学习到的LM策略 生成的优化输出，由学习到的奖励模型计算得出， 奖励系数 控制 惩罚的强度，表示对改进程度的评估。

3.3 奖励模型监督下的多步生成

我们通过最大化奖励函数实现了带有反馈的过程监督。在本节中，我们将展示LM在生成阶段如何与虚拟工具交互，以在训练和生成阶段实现对齐。我们不断要求LM优化解决方案，直到满足以下两个条件之一:

(1)在个连续步骤中没有改进;

(2)达到最大迭代次数。

算法1阐明了生成的具体过程。

Algorithm 1：生成基于过程反馈的修复程序，采用演员-评论家模式

4 实验

4.1 数据准备

我们从CodeNet4Repair中抽取那些经过两步修改后修复成功的记录，得到三个版本，并计算这些版本之间的编辑距离。如图 3(a) 所示，结果与我们的假设一致：一次性修复所需的编辑距离远大于多步修复所需的编辑距离。尽管多步修复在总体代价上有所增加，但逐步修复能显著降低任务复杂度。

Figure 3: (a) 三个程序在两步修改后的编辑距离。0-1：第一次改进的编辑距离；1-2：第二次改进的编辑距离；0-2：一步改进的编辑距离。(b) 测试用例的分布。大多数测试用例集中在10-20之间。

为了保证评估质量，我们仅选择带有高质量测试用例的问题用于训练与测试集。我们还从互联网手动收集并标注了更多高质量的测试用例，作为每个问题的隐藏测试集。最终，共得到 794 个问题的测试用例。图 3(b) 给出了测试用例数量分布，10–20 条用例的样本占比最高。按题目 ID 9:1 划分训练/测试集，训练集含 94062 条修复过程，测试集含 10144 条。表 2 列出过滤后数据集的统计信息。

Table2: 数据集信息

4.2 实验设置

在微调阶段，我们采用混合精度训练，优化器使用 AdamW ，学习率设为 2e-5 。为防止学习率过高导致训练不稳定，我们使用余弦退火学习率调度，并在初期设置学习率预热。模型参数分布使用 ZeRO++分布到多卡以提升计算效率。

在奖励建模阶段，我们采用学习率 9.6e-6 与余弦调度。每个问题随机选取 个程序样本，并根据执行状态进行排序。每批次包含 64 个单元，因此一次反向传播涉及 对比较。

在基于过程反馈阶段，我们从微调后的语言模型初始化强化学习策略，使用 PPO 算法 进行优化，训练 32k 轮次，批量大小为 512 。 惩罚因子设为 ，学习率为 9e-6 。采样时采用 nucleus sampling（top_p=0.95, top_k=50, temperature=0.2）。

4.3 Baselines

我们与当前具备少样本学习和代码理解能力的最新LLMs进行了对比，这些模型包括：

1）闭源模型：PaLM (Anil et al.,2023)、GPT-3.5、Claude2和ChatGLM-Pro。

2）开源模型：StarCoderBase/Chat(Li et al.,2023)、CodeGen2、CodeGeeX2、LLaMA2/Chat (Touvron et al., 2023)。

4.4 评估指标

以往程序修复数据集缺乏标注测试用例和稳定的执行环境，导致无法依据程序执行结果自动评估模型性能。我们主张采用基于执行结果的评估方式。参照前人代码生成任务的评估方法，我们使用 pass@k 作为指标（Hendrycks et al., 2021; Chen et al., 2021），其中：

在本文中，本文采用  的结果。原因是在 pass@k 中，  越大能力评估越全面，但在实际应用中，用户通常不会重复生成多次，因此取较小  就足以反映模型修复性能。

pass@k是自动代码生成或程序修复任务中常用的评估指标，它衡量模型在生成 k 个候选解 时，至少有一个是“正确解”（即能通过所有测试用例）的概率。

4.5 主要结果

Table 3: CodeNet4Repair 的结果：与开源模型相比，我们基于过程的反馈方法表现出更优的性能。在与商用大语言模型比较时，它仍然具有竞争力。

我们依据 140 亿条提交记录中的通过率来衡量问题难度，将问题分为简单（easy）、中等（medium）、困难（hard）三类。表 3 给出各模型在不同难度上的 pass@k 。我们的模型在所有开源模型中表现最优；即便与商业闭源大模型（如 GPT3.5、Claude2）相比，也具备竞争力；与同等规模的 StarCoder/CodeGen2 系列相比显著领先。此外，LLaMA2-Chat 的实验显示，多轮对话式监督微调并未削弱、反而增强了其对人类指令的理解与修复能力。

首先分析开源模型：我们承认部分性能提升来自监督微调（SFT）。然而，StarCoderBase/Chat 的结果表明，我们的基础模型在零样本或少样本场景下几乎不具备程序纠错能力，未经 监督微调（SFT）便难以完成修复任务。与专为代码下游任务设计的 LLMs 相比，我们的修复模型生成的程序更贴合题目要求，在各难度级别上均优于它们。尽管我们的成绩尚不及 GPT3.5 、Claude2 等商业大模型，但考虑到它们在算力、数据收集和人工标注等方面投入的资源远超我们，仍能取得与之接近的结果，这已充分验证了基于过程反馈方法的有效性，并为后续研究指明了方向。

4.6 消融实验

我们针对“过程监督”、“反馈”以及“奖励函数”三个维度的设计合理性进行了系统消融实验。
过程监督的影响：我们将过程监督信号完全移除，模型退化为仅依赖单步监督的传统修复模型。此时即使引入反馈，也只能依据最终结果调整策略，性能显著下降。
反馈的影响：我们在过程监督期间从奖励函数中删除了反馈，这阻止了语言模型通过强化学习（LM）动态更新策略。只能被动拟合下一条修复步骤，性能同样明显降低。
奖励函数的影响：我们比较了 pairwise、point-wise 与 list-wise 三种排序方式：point-wise 仅对单程序状态打分，无法感知“孰优孰劣”的相对关系；list-wise 一次性对 条程序进行全排序，任务复杂度最高；实验表明，pairwise 排序在全部   值下均获得最优结果（见表 4）。

Table 4: 消融实验的结果。我们对过程监督、反馈和奖励函数的设计进行了深入研究。实验结果验证了我们模型的有效性。Point: Point-wise loss；Pair: Pair-wise loss；List: List-wise loss。

从结果中我们可以得出以下结论：

1）无论采用何种监督形式，引入反馈以动态调整修复策略都是必要环节；缺少反馈的过程监督反而会因噪声放大而严重拉低性能。

2）在奖励建模环节， pair-wise 排序既能刻画程序状态的相对优劣，又避免了 list-wise 的高复杂度，是兼顾效果与效率的最佳选择。

4.7 基于过程反馈带来的性能优势

Figure 4: 在其他微调的开源模型上的性能比较。

有些人可能会质疑RePair相对于当前开源模型的优越性，因为我们在训练集上使用了监督微调（SFT）。澄清 SFT 是用来增强模型对修复任务的理解，而不是性能改进的主要因素，这一点很重要。为验证性能提升是否仅来自 SFT ，我们在相同数据集上微调了多种开源模型（如 CodeGen2、LLaMA2-Chat），结果如图 4 所示。虽然 SFT 提高了模型的性能，然而这种改进很大程度上是由于模型对任务的理解增加和输出格式的标准化。此外，当与 SFT 相结合时，基于过程的反馈方法显著放大了模型的潜力，获得了更大的性能提升。

4.8 小模型难以有效理解显式反馈

Figure5:不同训练步骤下显式提示的表现。ChatGPT能够有效理解来自编译器和测试用例的反馈。对于小模型，显式提示仍然较难理解。

正如在摘要和引言中提到的，小模型在理解显式提示（prompt）时仍存在困难。我们使用附录 A.1 中的 prompt 模板，对 StarCoder 和 CodeGen2 进行 5 轮交互实验。结果如图 5：

1）开源模型性能在第 3 轮训练后达到峰值；

2）ChatGPT 能充分理解编译器与测试用例反馈，实现逐步改进；

3）小模型难以从显式提示中有效提取反馈信息。

这表明参数规模不足 20B 的模型对自然语言形式的编译器反馈理解有限，需通过奖励模型隐式注入信号。

4.9 定性结果

Figure 6: “计算整数转换次数”的修复过程示例。

如 图6 所示，我们的模型能通过逐步修改有效简化每步修复的复杂度，并最终达到“AC”结果。

5 相关工作

5.1 大语言模型

近年来，大型语言模型（LLM）的研究取得了显著进展。语言建模（language modeling） 的核心任务是：在给定上下文的情况下预测下一个词元（token）的概率分布。规模律（Scaling Law） 的提出（Kaplan et al., 2020）表明，通过增加模型参数规模与训练数据量，可以系统性地提升模型性能。随着参数量超过 1000 亿（100B）的超大规模模型出现，其性能屡次刷新记录（Srivastava et al., 2023；Hendrycks et al., 2021；Chen et al., 2021）。这些更大的模型开始展现出小模型无法具备的能力，这一现象被称为涌现（emergence）。当参数量突破 100B 后，模型展现出“涌现”能力：在上下文学习（ICL）与思维链（CoT）等范式下，仅需少量示范或提示即可解决以往小模型无法胜任的复杂任务。本文工作聚焦于参数不足 20B 的小模型，通过过程监督与反馈机制，使其在程序修复任务上逼近甚至超越大模型的表现。

5.2 基于结果与基于过程的方法

基于结果的方法仅对最终答案进行监督，而基于过程的方法则对达到答案的每一步进行引导。两者各有优劣：前者监督信号稀疏、成本低；后者更符合人类逐步思考的习惯。在(Uesato et al.， 2022)中，研究人员在数学问题求解任务上进行实验，发现两种方法的错误率相近，考虑到数据标注与计算成本，基于结果的方法在性价比上表现更佳。然而，最近的研究(Light-man et al.， 2023)提出了不同的观点;在构建更大规模的数据集并引入更多过程标注后，基于过程的方法展现出了明显优势。这种方法不仅有助于机器学习系统更准确地理解人类的思维路径，还能有效缓解模型出现幻觉（hallucination）的问题。本文首次将过程监督引入程序修复，并验证了其在小模型上的有效性。

5.3 基于反馈的学习

通过反馈学习（Learning from Feedback），语言模型能够利用超越标签（label）的信号来优化自身表现（Gou et al., 2024）。在自然语言处理（NLP）任务中，常见的自动评价指标如 BLEU、ROUGE 等，能基于真实标签提供一定的反馈。然而，这类仅依赖精确匹配的自动反馈并不能充分反映模型生成质量（Colombo et al., 2022）。为此，研究者开始用人类偏好（human preferences）作为监督信号训练模型。例如，在开放式文本生成任务中，引入人类反馈的强化学习（RLHF）显著提升了生成质量（Jaques et al., 2019；Bahdanau et al., 2016；Stiennon et al., 2020）。遵循这条路线，(Ouyang et al.， 2022)将人类反馈应用于GPT-3，使模型在遵循人类指令和输出真实内容方面实现了显著改进，从而缓解了“虚假生成”和“有害内容”的问题。本文则提出以“编译器+测试用例”作为虚拟反馈源，将工具信号融入模型训练，从而避免了昂贵的人工偏好标注，同时显著提升了程序修复效果。

6 结论

在本文中，我们提出了一种基于过程反馈的自动化程序修复方法。该方法借鉴了编程竞赛中的策略，将过程监督引入修复流程。由于现有数据集无法满足多步修复的需求，我们首先构建了一个名为 CodeNet4Repair 的多步修复数据集。该数据集不仅包含初始的错误程序和最终通过的正确程序，还记录了中间的修复过程。在此基础上，我们实现了带有反馈的过程监督。具体而言，我们首先以预训练模型 StarCoderBase 为基础，通过监督微调使其理解程序修复任务。随后，我们基于经验定义了程序状态之间的偏序关系，并使用成对排序方法训练奖励模型。该奖励模型充当“评判者”，对语言模型每次尝试修改的程序进行评分；同时，语言模型作为“演员”，根据获得的奖励不断调整其修复策略。在推理阶段，模型迭代地对程序进行修复，直到满足退出条件。实验结果表明，基于过程反馈的方法能够在较小的模型规模下实现优异的性能，RePair 甚至能够与闭源的商业大模型相媲美。我们相信，过程反馈在自动化程序修复领域仍有巨大的探索空间，未来的工作将进一步提升其通用性与实用性。

7 局限性

在本研究中，我们贡献了一个名为 CodeNet4Repair 的新数据集，该数据集专注于真实竞赛场景下的程序修复任务。然而，我们也必须承认，它在评估模型修复能力方面仍然存在一定的局限性。首先，CodeNet4Repair 的覆盖范围有限。由于时间与计算资源的限制，我们无法收集所有编程语言及所有软件工程领域中的完整修复过程。这意味着目前的数据集主要聚焦于 Python 语言与编程竞赛类任务，尚未完全涵盖工业级软件系统中的多样化修复场景。然而，竞赛场景与工程场景在缺陷类型、调试策略和测试需求等方面具有高度相似性。这意味着我们的模型在面向真实工程项目时仍具备一定的可用性，且 CodeNet4Repair 可在一定程度上评估其工程化修复性能。未来工作将进一步扩充语言种类、缺陷类别和工程上下文，以提升数据集的多样性与代表性。

启发

采用基于过程的角度，关注程序修改的中间状态

BibTeX

@inproceedings{zhao2024repair,
      title={RePair Automated Program Repair with Process-based Feedback}, 
      author={Yuze Zhao and Zhenya Huang and Yixiao Ma and Rui Li and Kai Zhang and Hao Jiang and Qi Liu and Linbo Zhu and Yu Su},
      year={2024},
      booktitle = {Findings of the Association for Computational Linguistics ACL 2024},
      month = aug,
      year = 2024,
      publisher = {Association for Computational Linguistics},
      pages = {16415--16429},
}