RLPF：面向代码生成的基于性能反馈的强化学习

# RLPF：用于代码生成的性能反馈强化学习

来源：https://arxiv.org/html/2607.27271

Huihao Jing![无标题图片](https://arxiv.org/html/2607.27271v1/x1.png)、Haozhe Cui![无标题图片](https://arxiv.org/html/2607.27271v1/assets/hku.png)、Wenbin Hu![无标题图片](https://arxiv.org/html/2607.27271v1/x2.png)、Shaojin Chen![无标题图片](https://arxiv.org/html/2607.27271v1/x3.png)、Haochen Shi![无标题图片](https://arxiv.org/html/2607.27271v1/x4.png)、Changxuan Fan![无标题图片](https://arxiv.org/html/2607.27271v1/x5.png)、Yuxuan Liu![无标题图片](https://arxiv.org/html/2607.27271v1/x6.png)、Hanyu Yang![无标题图片](https://arxiv.org/html/2607.27271v1/assets/swupl.png)![无标题图片](https://arxiv.org/html/2607.27271v1/x7.png)、Sirui Zhang![无标题图片](https://arxiv.org/html/2607.27271v1/assets/nyu.png)![无标题图片](https://arxiv.org/html/2607.27271v1/x8.png)、Ziyi Chen![无标题图片](https://arxiv.org/html/2607.27271v1/x9.png)、Haoran Li![无标题图片](https://arxiv.org/html/2607.27271v1/x10.png)\\corresponding、Yangqiu Song![无标题图片](https://arxiv.org/html/2607.27271v1/x11.png)

###### 摘要

代码模型越来越多地使用执行反馈进行训练，但大多数训练信号仍然止步于正确性。这给系统级代码留下了重要空白：两个程序可能通过相同的测试，但运行时间差异巨大。我们研究如何训练代码智能体偏好更快的正确实现，而不是仅仅把效率当作评估指标。关键困难在于运行时是一种脆弱的奖励信号。它只有在程序正确之后才有意义，且因任务而异，当大多数采样程序无法编译或运行时，它几乎无法提供指导。我们提出 RLPF，即性能反馈强化学习，将执行结果转化为分阶段奖励。失败的程序按执行进度排序，正确的程序则按从基线到专家参考的相对改进程度排序。这就在正确性之前提供了有用的反馈，并在正确性之后提供了对性能敏感的反馈。使用 RLPF 在 PerfCodeBench 上微调 Qwen3-32B，将正确且可运行解决方案的比例从 11.1% 提升到 54.6%，并将相对效率从 8.1% 提升到 38.6%。训练后的模型可与更强的开放权重系统竞争，但与专家参考和专有前沿模型仍有明显差距。进一步研究表明，模型生成的参考能提供有用但较弱的监督，完整的复合奖励比仅正确性或仅运行时的基线更可靠。这些结果表明，代码智能体不仅可以训练为通过测试，还可以训练为优化它们编写的程序。

代码——https://github.com/HKUST-KnowComp/RLPF
模型——https://huggingface.co/Egbertjing/RLPF-Qwen3-32B-PerfCodeBench

## 引言

大型语言模型（LLMs）已成为能力强大的代码生成器。Claude Code（Anthropic2026 (https://arxiv.org/html/2607.27271#bib.bib4)）和 Codex 智能体（OpenAI2026 (https://arxiv.org/html/2607.27271#bib.bib5)）等前沿系统，加上不断增长的智能体软件工程研究方向（Yang et al.2024 (https://arxiv.org/html/2607.27271#bib.bib7); Wang et al.2025 (https://arxiv.org/html/2607.27271#bib.bib8)），能够导航代码仓库、运行测试并修复自身输出。从函数级合成到仓库级问题解决（Jimenez et al.2024 (https://arxiv.org/html/2607.27271#bib.bib1); Jain et al.2025 (https://arxiv.org/html/2607.27271#bib.bib2); Zhuo et al.2025 (https://arxiv.org/html/2607.27271#bib.bib3)），面向正确性的基准测试因此将可执行正确定性为代码模型进步的核心衡量标准。对于性能关键的代码，这只是部分目标。一个通过所有测试的程序，如果比简单基线慢得多，或远未达到优化实现，仍然可能无法使用。近期面向效率的研究（Huang et al.2024 (https://arxiv.org/html/2607.27271#bib.bib6); Du et al.2024 (https://arxiv.org/html/2607.27271#bib.bib40); Qiu et al.2025 (https://arxiv.org/html/2607.27271#bib.bib41); Liu et al.2024 (https://arxiv.org/html/2607.27271#bib.bib42); Qing et al.2025 (https://arxiv.org/html/2607.27271#bib.bib29); Ouyang et al.2025 (https://arxiv.org/html/2607.27271#bib.bib38); Peng et al.2025 (https://arxiv.org/html/2607.27271#bib.bib9); Jing et al.2026 (https://arxiv.org/html/2607.27271#bib.bib10)）清楚地显示了这一差距：强模型通常能生成正确的程序，但其解决方案仍无法媲美专家运行时间。随着代码智能体被用于更真实的软件工作流，问题不再仅仅是它们能否编写可运行的代码，而是它们能否学会偏好更优秀的可运行代码。这使得性能成为强化学习的自然目标，但并非简单目标。运行时是一种基于执行的信号，只有在生成的程序有效、可运行并通过测试用例之后才能观测到。它还具有任务相关的尺度：在某个问题上改进一秒钟与在另一个问题上改进一毫秒，含义并不相同。因此，朴素的运行时或加速比奖励会在异构任务中产生不稳定的监督信号。在组相对策略优化（GRPO）（Shao et al.2024 (https://arxiv.org/html/2607.27271#bib.bib11)）下，这个问题更加尖锐。如果一组 rollout 中所有样本在正确性之前就失败，运行时无法提供有效的排序，而此时恰恰是训练最困难的时候，策略能获得的信号却很少。

我们提出 RLPF，即性能反馈强化学习。核心思想是对执行过程进行分阶段奖励。在正确性之前，RLPF 根据失败程序在可执行流程中的进展程度对它们排序，从代码提取、编译到执行和测试用例检查。在正确性之后，它根据程序在多大程度上缩小了从基线到专家参考之间的性能差距来排序。这种设计在一次训练中为策略提供了两类反馈：针对失败程序的进度反馈，以及针对正确程序的效率反馈。它还通过衡量相对于任务自身基线和专家参考的改进，使性能在不同任务之间具有可比性。我们在 PerfCodeBench 上实例化了 RLPF。在按族划分的测试集上，RLPF 将弱基础模型的正确且可运行率从 11.1% 提升到 54.6%，并将 CGRE 从 8.1% 提升到 38.6%。这一改进不仅仅是正确性虚增：大多数正确输出也超越了基线。训练后的模型可与更强的开放权重系统竞争，但与专家参考和专有前沿模型之间仍有明显差距。我们进一步测试了一种较弱的类蒸馏设置，其中 GPT-5.4 的输出作为性能参考；这些参考有帮助，但不如精心整理的专家实现稳定。最后，奖励基线、组件消融和 EffiBench-X 迁移结果表明，完整奖励比仅正确性或仅运行时的监督更可靠，并且学习到的“偏好更快正确代码”的倾向在一定程度上会迁移到训练基准之外。

我们的贡献如下：

- • 我们将性能表述为代码智能体的可训练目标。RLPF 超越“通过测试”，根据正确程序相对于基线和专家参考的效率对其进行奖励。
- • 我们针对异构执行结果引入了分阶段奖励。该奖励在正确性之前提供进度反馈，在正确性之后提供性能反馈，避免了朴素运行时奖励信号稀疏的问题。
- • 我们证明性能反馈会改变模型行为。RLPF 显著提升了 Qwen3-32B 在 PerfCodeBench 上的表现，并适度迁移到 EffiBench-X；受控研究同时揭示了模型生成参考、简单奖励基线和奖励组件的价值与局限。

## 相关工作

### LLM 代码生成

大型语言模型在代码生成方面取得了快速进展，从函数级合成到竞争性编程和软件工程工作流。这一进展由可执行基准测试塑造，例如 HumanEval 和 EvalPlus（Chen et al.2021 (https://arxiv.org/html/2607.27271#bib.bib12); Liu et al.2023b (https://arxiv.org/html/2607.27271#bib.bib43)）、MBPP（Austin et al.2021 (https://arxiv.org/html/2607.27271#bib.bib13)）、APPS（Hendrycks et al.2021 (https://arxiv.org/html/2607.27271#bib.bib14)）、LiveCodeBench（Jain et al.2025 (https://arxiv.org/html/2607.27271#bib.bib2)）和 SWE-bench（Jimenez et al.2024 (https://arxiv.org/html/2607.27271#bib.bib1)），它们通过单元测试、执行或真实仓库级任务来评估生成的代码。最近的基准测试进一步向实际开发者场景迈进；例如 DevBench（Kumarappan et al.2026 (https://arxiv.org/html/2607.27271#bib.bib30)）是一个由遥测驱动并参考开发者反馈的基准测试，涵盖真实的代码补全场景。因此，功能正确性已成为代码质量的默认衡量标准，许多后续工作专注于通过执行反馈、自我调试、检索、多智能体协作或测试时扩展来提升测试通过率。然而，对于性能关键的代码，仅仅通过测试并不够：两个正确的程序在运行时间、内存使用和硬件效率上可能差异巨大。PIE、PerfCodeGen、EffiPair 和 PhyloEvolve 使用执行反馈或配对编辑来生成更快的实现（Shypula et al.2023 (https://arxiv.org/html/2607.27271#bib.bib39); Peng et al.2024 (https://arxiv.org/html/2607.27271#bib.bib15); Hajizadeh and Jana2026 (https://arxiv.org/html/2607.27271#bib.bib16); Zhao et al.2026 (https://arxiv.org/html/2607.27271#bib.bib17)）。效率基准测试现已涵盖通用语言和 GPU 内核（Du et al.2024 (https://arxiv.org/html/2607.27271#bib.bib40); Qiu et al.2025 (https://arxiv.org/html/2607.27271#bib.bib41); Liu et al.2024 (https://arxiv.org/html/2607.27271#bib.bib42); Qing et al.2025 (https://arxiv.org/html/2607.27271#bib.bib29); Ouyang et al.2025 (https://arxiv.org/html/2607.27271#bib.bib38); Jing et al.2026 (https://arxiv.org/html/2607.27271#bib.bib10)）。EffiCoder 表明，对精心整理的优化解进行 SFT 可以提升正确性和效率（Huang et al.2025 (https://arxiv.org/html/2607.27271#bib.bib46)）。RLPF 则使用在线 RL，将失败阶段反馈与正确性门控、任务归一化的性能奖励结合起来。

### 代码强化学习

强化学习近来已成为代码 LLM 重要的后训练范式，尤其是通过可验证奖励强化学习（RLVR）（Le et al.2022 (https://arxiv.org/html/2607.27271#bib.bib34); Liu et al.2023a (https://arxiv.org/html/2607.27271#bib.bib35); Yu et al.2024 (https://arxiv.org/html/2607.27271#bib.bib36); Shen et al.2023 (https://arxiv.org/html/2607.27271#bib.bib37); Guo et al.2025 (https://arxiv.org/html/2607.27271#bib.bib33)）。在代码生成中，可验证奖励通常来自执行结果，使模型能够直接针对可执行正确性信号进行优化。近期工作将这一范式扩展到多个方向。RLEF 训练模型在代码合成过程中使用执行反馈（Gehring et al.2024 (https://arxiv.org/html/2607.27271#bib.bib28)）。CodeRL+ 通过执行语义对齐增强稀疏的通过/失败奖励（Jiang et al.2025 (https://arxiv.org/html/2607.27271#bib.bib18)）。CodeScaler 使用学习得到的奖励模型来减少对在线执行的依赖（Zhu et al.2026 (https://arxiv.org/html/2607.27271#bib.bib19)）。其他研究探索了离线 RL（Wu et al.2026b (https://arxiv.org/html/2607.27271#bib.bib20)）、针对小模型的验证反馈（Skopin and Kotelnikov2026 (https://arxiv.org/html/2607.27271#bib.bib25)）、协作式多智能体 RL（Dou et al.2026 (https://arxiv.org/html/2607.27271#bib.bib26)）以及合成数据驱动的代码 RL（Wu et al.2026a (https://arxiv.org/html/2607.27271#bib.bib27)）。尽管取得了这些进展，代码 RL 仍然在很大程度上以正确性为中心：奖励通常只区分正确与不正确的程序，效率则被留作训练后的评估指标。这种训练提升了测试通过率，但并未教会模型偏好更快的正确实现。RLPF 通过将效率视为一等可验证信号来弥补这一空白，将代码 RL 从可验证正确性扩展到经过验证的优化。

### 代码优化的加速比奖励

加入性能反馈的一种自然方式是使用运行时改进、加速比、吞吐量或硬件利用率作为奖励。近期几个面向优化的系统遵循了这一思路。Wei 等人（Wei et al.2025 (https://arxiv.org/html/2607.27271#bib.bib21)）研究了用于汇编代码优化的 RL，并比较了正确性引导的加速比与仅加速比奖励。CUDA-L1（Li et al.2025 (https://arxiv.org/html/2607.27271#bib.bib22)）使用基于加速比的奖励来训练 LLM 进行 CUDA 内核优化。Mikasa 等人（Mikasa et al.2026 (https://arxiv.org/html/2607.27271#bib.bib23)）在高性能计算（HPC）代码生成中使用真实机器 GFLOPS 反馈作为在线 GRPO 的奖励。MaxCode（Ou et al.2026 (https://arxiv.org/html/2607.27271#bib.bib24)）同样将执行性能作为候选搜索过程中的核心信号。这些工作表明性能反馈可以改进代码优化。然而，它们通常使用候选程序的最终实测性能（如加速比、运行时、吞吐量或 GFLOPS）作为主要奖励信号。这在任务专业且可比较时是有效的，但对于通用代码生成会变得不稳定。不同任务具有不同的运行时尺度、优化空间和失败模式，因此原始性能值难以跨问题比较。更重要的是，当程序无法编译、执行或通过测试时，它们提供的有效信号非常有限。因此，RLPF 只在构建了更密的执行状态信号之后才使用性能反馈。它首先对编译、执行和正确性结果进行塑形，然后按相对效率对正确程序排序。这既保留了基于加速比优化的优点，又使奖励在异构执行结果中更加稳定。

## 使用 RLPF 训练 LLM

参见图 1：从仅正确性奖励到正确性门控的性能反馈。RLVR 只奖励正确性，无法区分快速正确程序与慢速正确程序。朴素的加速比奖励以运行时改进为主要信号，但在正确性之前提供的反馈很少。RLPF 将执行结果分解为有序奖励结构：失败的 rollout 接收分阶段塑形反馈，而正确的 rollout 则按正确性门控的相对效率进行排序。

RLPF 基于这样一个原则：代码性能训练应该奖励整个执行过程，而不是把性能当作一个单一的最终标量。生成的程序必须首先可提取、可编译、可执行且正确，运行时效率才有意义。因此，RLPF 将奖励设计分为两个区间。在“失败区间”中，奖励衡量执行进度：一个不正确 rollout 在执行流程中前进了多远。在“成功区间”中，奖励衡量相对性能：一个正确 rollout 相对于任务基线和专家参考的效率如何。这种设计使 RLPF 即使在正确性之前也能提供学习信号，同时仍然优化性能。