用于代码优化的强化学习 Reinforcement Learning for Code Optimization
让RL真正学会写更快的正确代码：从测试、沙箱、奖励到GRPO全链路改造。
前置知识
RLVR（带可验证奖励的强化学习）
RLVR 指用「能被程序自动判定的奖励」来训练大模型的一类方法。在代码场景里，最典型的奖励就是二值的正确性：把模型生成的程序跑在隐藏测试用例上，通过即给正奖励。GRPO 等算法用同一 prompt 的一组采样计算组内相对优势（advantage），无需独立的价值网络即可更新策略。
本文的起点正是「正确性 RLVR 已成熟，但优化 RL 一直失败」。理解 RLVR 的二值奖励、组内优势、零优势组（zero-advantage group）等机制，才能看懂为什么把执行时间加进奖励后会因为噪声和稀疏性而崩溃。
GRPO 与其稳定性问题
GRPO（Group Relative Policy Optimization）对同一问题的多个 rollout 计算均值化优势并做比率裁剪更新。标准做法会用组内标准差归一化优势、按 rollout 长度归一化损失。本文指出这些惯例在稀疏+噪声奖励下会引入难度偏置和长度偏置。
本文对 GRPO 做了五项关键改造（增加同 prompt rollout 数、增大 batch、不做 std 归一化、token 加权基线+固定 token horizon $N=32768$、过滤陈旧上下文 $S_{\max}=30$），这是优化 RL 能否收敛的核心。
pass@k 与 $p_\tau$ 百分位评估
pass@k 衡量 k 次采样中至少一个通过的概率。本文定义 $p_\tau$ 评估：一个解只有在「严格正确」且「插入人类参考榜单后排名不低于第 $\tau$ 百分位」时才算通过，$\tau$ 越小越严。$p_{100}$ 等价于纯正确性，$p_{50}$ 要求进入人类前 50%，$p_{10}$ 要求前 10%。
$p_\tau$ 是贯穿全文的核心评估指标。论文几乎所有数字（18.0%→31.3% 等）都是在不同 $\tau$ 下的 pass@1，理解它才能读懂「strict percentile」指代什么。
竞赛编程与 DeepMind Code Contests（DMC）
DMC 是一个大规模竞赛编程数据集（12,275 道题），每题带有大量人类提交和判题测试。竞赛题有清晰的输入输出、可自动判正确性、且有大量人类解作为速度参考，是研究代码优化的理想「playground」。
本文基于 DMC 构建了 DMC-Optim（2,723 题，1,302 题可做计时 RL）。竞赛编程设定让作者能隔离并系统研究「为什么优化 RL 会失败」。
执行沙箱与计时噪声
要在 RL 中用执行时间作奖励，必须可靠地测量程序运行时间。本地执行会和推理/rollout 编排争抢资源导致计时大幅漂移；隔离的远程 CPU 集群（CES）能把每次执行隔离，但仍需对服务状态漂移做仿射校准。
本文证明本地沙箱会让相同代码的百分位排名平均漂移 41.2 个百分点，且无法用仿射映射拟合（交叉验证 $R^2$ 为负）。计时信号的可靠性是整条 RL 链路的地基。
研究动机
训练出能写「正确」代码的模型，并没有让模型写「快」代码。作者用三个 benchmark 量化了这个 correctness–efficiency 鸿沟：在 SWE-fficiency 上，Claude 4.5 Sonnet 能 81% 的时间写出正确补丁，却只拿到 4.1% 的专家加速；在 Venus 上，o4-mini 拿到 89.1% 的 pass@1，但在对标人类速度的 Beyond-T 上只有 56.9%；在 BigO(Bench) 上，Qwen3-32B 从 70.0% 的纯正确率掉到 43.5%（要求达到最佳复杂度类）。即使在测试廉价、人类提交充分的竞赛编程这种受控场景，鸿沟依旧：标准 RLVR 在 Qwen 2.5 7B 上从 $p_{100}$ 的 43.5% 掉到 $p_{50}$ 的 18.0%、$p_{30}$ 的 7.7%，差不多衰减 60%–80%。直觉上「在正确性奖励上加点执行时间」应该管用，但作者发现这几乎无效：朴素地把平均运行时间加进奖励，$p_{30}$ 只涨 +0.6 个点，$p_{100}$ 在 −0.3 到 +1.4 之间，等价于纯正确性。更糟的是已有工作 PIE 报告过「同一份代码重复运行却测出 1.91× 的虚假加速」。问题的根源是：一旦时间驱动奖励，测量噪声、奖励稀疏、GRPO 不稳定三者会联手淹没信号，导致生成的解几乎没变快，反而更多解会失败。
本文的目标是作者的目标是回答一个具体问题：「什么样的执行时间信号才是可学习的？」并把优化 RL 从「几乎学不动」推进到「能在不损失纯正确性的前提下，显著提升严格百分位上的 pass@1」。具体而言，他们希望在 DMC-Optim 测试集上把 $p_{50}$ pass@1 在 Qwen 2.5 7B 上从 18.0% 提到 30% 量级、在 CWM 32B 上从 30.7% 提到 50% 量级，同时在更严的 $p_{30}$ 上拿到 100% 以上的相对提升，并把这种能力迁移到 OOD 的 LiveCodeBench（LCB）。作者还想搞清楚优化 RL 究竟学到了什么——是输入输出优化的皮毛，还是真正的算法/复杂度改进——并量化与最强人类提交的差距。
与已有工作不同的是，已有工作要么只做正确性 RLVR（CodeRL、DeepSeek-R1 等），要么在更「容易」的优化设定下做效率训练：PIE 从离线 slow-fast 编辑对学习，Afterburner 在「给定一个已有解+运行时指标」的迭代精修设定下用 GRPO 加性混合奖励（但会把「比所有人类都慢」的解从 0.33% 涨到 7.33%），还有一系列推理时搜索的方法。这些都不触及真正的难题：one-shot 从零生成一个既正确又在人类榜单上排名尽量靠前的解，且在生成时看不到任何执行反馈。本文的独特切入点是把「优化 RL 失败」拆成一条因果链——计时来源（测试）→ 环境/奖励（何时注入优化约束）→ 优化器（GRPO 在稀疏噪声下的稳定性）——并论证只要链上任何一环失败，生成的程序就不会变快、甚至会变错。这个「全链路」视角是此前工作没有系统化提出的。
核心方法
整体思路是「让执行时间变得可学习」，分三个递进阶段。直觉上：要让 RL 学到速度，奖励里的时间信号必须（a）能在不同解之间拉开差距、（b）不被测量噪声淹没、（c）不会被 GRPO 的损失聚合误杀。技术路线因此是：第一阶段重构数据与计时工具——从 12,275 道 DMC 原题出发，重新跑人类提交、生成大输入「优化测试」、把正确性测试与优化测试分离，最终得到 2,723 题清洗语料，其中 1,302 题满足「duration filterable」（鲁棒变异系数 ≥0.3），划分为 1,000 训练 / 302 测试；同时把执行从争抢资源的本地沙箱迁到隔离的远程 CPU 集群 CES，并做仿射漂移校准。第二阶段设计 RL 环境与奖励——把优化约束注入点归类为执行前（pre-exec，按测试过滤）、执行中（intra-exec，超时限制）、执行后（post-exec，对人类榜单排名）三大族，所有环境最终归约为面向奖励的三个量：正确性门 $c\in\{0,1\}$、优化门 $g\in\{0,1\}$、连续质量分 $q\in[0,1]$；再用一个离线模拟器（用人类解替代模型生成、用预算好的时长替代实时 CES）筛掉太稀疏/太饱和/太平坦的配置。第三阶段改造 GRPO——增大同 prompt rollout 数与 batch、取消 std 归一化、用 token 加权 prompt 均值做优势基线、按固定 token horizon $N=32768$ 归一化损失、过滤超过 $S_{\max}=30$ 步的陈旧上下文——以应对比 pass/fail 更稀疏更噪声的奖励。
核心创新有三点，且与已有方法有本质区别。第一，把「正确性测试」与「优化测试」彻底分离：原 DMC 测试平均仅 0.088 s、p95 才 0.145 s，几毫秒抖动就主导决策；作者专门生成 352,740 个会让程序跑得更久的大输入优化测试（p95/p99 达 1.296/3.710 s），并用「duration filterability」（鲁棒 CV ≥0.3）作为最后一道闸——原测试只对 3.8% 的题满足，优化测试达到 48.2%。第二，提出统一的「三干预点 + 三奖励量」框架，把过去散落在各 benchmark 里的优化约束（绝对超时、相对超时、字符长度过滤、榜单百分位等）整理进同一坐标系，并用 17 种排名函数的噪声筛选实验挑出最稳定的 mean-based percentile（重测仅漂移 3.0±1.0 个百分点，强弱解差 47 个百分点）。第三，引入「离线 RL 模拟器」做廉价前置筛选：在花 8–32 个 GPU 节点·天跑在线 GRPO 之前，先用 AUC（区分稀疏 vs 饱和）和 steepness $S=a/(1+|a|)$（区分平坦 vs 陡峭）两个诊断量评估环境，并在 18 次 7B 测试扫描中发现下游 $p_{30}$ 性能与「偏离 $y=x$」相关 $r_s=-0.832$（$p=2\times10^{-5}$）。这与 Afterburner 那种「拍脑袋选个加性混合奖励就上」的做法根本不同。
方法步骤详情
完整流程如下。（1）数据构建（Figure 2）：重新执行人类提交以确认标签并捕获假阳性；每题生成 10 个 LLM 写的输入生成器、各采 15 个候选测试，仅保留在人类解上输出一致的；在测试/解/题三个层级过滤（剔除超时过多的测试、被矛盾判定推翻的解、正确解太少或假阳性率过高的题），最后用 duration filterability 保留 1,302 题。新增 430,215 个正确性测试与 352,740 个优化测试。（2）计时后端：放弃本地执行，改用隔离的 CES，对存储时长与新鲜时长做仿射校准，把 Spearman 相关从 0.54 提到 0.96。（3）环境与奖励：环境产出 $(c,g,q)$；奖励族包括 collapsed（正确性外门 $r=-1$ 当 $c=0$，否则给效率分）、two-gate、additive blend、multitask、optimization-only 等；环境族包括 pre-exec 绝对时长过滤（$\tau=0.1/0.5/2$ s）、字符长度过滤、相对过滤；intra-exec 绝对超时、ranked-worst 超时、相对超时；post-exec 榜单百分位、per-test 百分位（top 30/50/80%）。（4）离线模拟器筛掉退化配置。（5）在线 GRPO：10,000 步，温度 1.0，lr $1\times10^{-7}$（7B）/ $1.4\times10^{-7}$（32B），rollout 与训练节点 50/50，每 prompt 16 个 rollout，每步约 480k token、约 3 题。（6）评估：每题采 20 个解，在共享 CES 里把所有题、所有模型 dump 的测试打乱并发执行，并混入人类参考解做校准，之后回放不同百分位/超时/校准的判定的判定，避免重跑模型或沙箱。
技术新颖性
技术新颖性体现在把一个被默认「直接加时间就行」的问题，显式拆成一条可逐环诊断与改造的链，并对每一环都给出可量化的判据。计时环：首次系统证明本地沙箱不可用（41.2 个百分点的排名漂移、负 $R^2$ 的仿射拟合），并用 duration filterability 这个数据侧指标量化「测试是否足以承载计时信号」。奖励环：首次把 pre/intra/post 三大族优化约束纳入同一 $(c,g,q)$ 接口，并用离线模拟器的 AUC+steepness 双诊断做廉价筛选，把昂贵的在线 RL 从「试错」变成「定向」。优化器环：针对稀疏噪声奖励对 GRPO 做了五项具体改动，其中「不做 std 归一化」呼应 Dr. GRPO 的难度偏置分析，「token 加权基线 + 固定 horizon」专门修正长错误轨迹被欠罚、深推理成功轨迹被欠奖的偏置。相对 Afterburner 的迭代精修+加性混合（会把慢解比例从 0.33% 抬到 7.33%），本文的 one-shot 设定更难，却用 collapsed 二值奖励实现了「既不丢正确性又大幅提速」——这是对 correctness–efficiency Pareto 前沿的真正突破，而非沿前沿滑动。
实验结果
核心发现可以分成几条线。第一，朴素基线确实不行：标准 RLVR 在 7B 上从 $p_{100}$ 43.5% 掉到 $p_{50}$ 18.0%；即便加上作者生成的正确性+优化测试，$p_{50}$ 也只到 20.6%；再叠加朴素 raw-duration 奖励，$p_{50}$ 最多 21.7%、$p_{100}$ 反而掉到 42.5%——典型的拿正确性换效率。第二，完整流水线带来巨大提升：在 DMC-Optim 上，$p_{50}$ pass@1 在 Qwen 2.5 7B 从 18.0%→31.3%、Qwen 2.5 32B 从 21.1%→39.6%、CWM 32B 从 30.7%→50.4%；$p_{30}$ 上 CWM 32B 从 13.7%→30.9%（相对提升 125%），Qwen 2.5 32B 的 $p_{50}/p_{30}/p_{10}$ 分别相对提升 88%/157%/254%，且 $p_{100}$ 基本不掉。第三，最佳环境是 post-exec 的 per-test 百分位排名（top 30%/50%）以及 pre-exec 绝对过滤 $\tau=2$ s；相对超时族虽然能提严格分位但 $p_{100}$ 掉 17%–27%，属于沿 Pareto 前沿滑动而非突破。第四，奖励形状上 collapsed 二值最好：optimization-only 直接策略崩溃（全 0），multitask 与 additive blend 仍在 Pareto 前沿上，连续 50/50 等切分反而不如 bucketed/binary——印证 DeepSeek-R1「简单二值奖励避免隐藏 reward hacking」的观察。第五，OOD 迁移良好：在 LCB 上 CWM 32B 用 top-30% 训练拿到 82.9% 的中位样本速度胜率（$\mathrm{WR}_m$），即便更严的最佳样本胜率 $\mathrm{WR}_b$ 也有 66.3%–68.1%，说明推理时搜索无法完全恢复优化 RL 学到的新技巧。第六，鲁棒性：当评估沙箱被人为放慢（更接近真实比赛平台），优化 RL 相对标准 RLVR 的优势可达 100%–200%；即便把沙箱人为调快（作弊），top-30% 训练仍比优化测试 RLVR 高约 7%、比基线 RLVR 高约 15%（$p_{50}$）。第七，模型确实学到了非平凡的技巧：GPT-OSS 120B 盲评显示，在可分类的优化 RL vs RLVR 速度胜对中，47% 来自更好的 I/O、34% 来自常数因子优化、6% 来自数学捷径、6% 来自算法改进、2% 数据结构、1% 完整算法更换；13% 是复杂度类提升。相对最强人类提交，优化 RL 在 33% 的速度胜对中赢，人类在 67% 中赢；人类用复杂度提升赢 RLVR 占 22%，优化 RL 占 13%（约为人类的一半），且优化 RL 在 7% 的对中以复杂度提升击败人类。第八，显著性有保障：$p_{50}$ 上 top-30% 相对标准 RLVR 领先 19.7 个点，是训练时差异 CI 半宽的 9.9 倍。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| DMC-Optim 测试集 pass@1 @ $p_{50}$（Qwen 2.5 7B） | 严格百分位 pass@1（越高越好） | 31.3%（per-test post-exec top-30%） | 18.0%（标准 RLVR，base 测试） | +13.3 个点，约 +74% 相对提升 |
| DMC-Optim 测试集 pass@1 @ $p_{30}$（Qwen 2.5 7B） | 严格百分位 pass@1 | 19.1% | 7.7%（标准 RLVR） | +11.4 个点，约 +148% 相对提升 |
| DMC-Optim 测试集 pass@1 @ $p_{50}$（CWM 32B） | 严格百分位 pass@1 | 50.4% | 30.7% | +19.7 个点，约 +64% 相对提升 |
| DMC-Optim 测试集 pass@1 @ $p_{30}$（CWM 32B） | 严格百分位 pass@1 | 30.9% | 13.7% | +17.2 个点，约 +126% 相对提升 |
| DMC-Optim pass@1 @ $p_{50}$（Qwen 2.5 32B） | 严格百分位 pass@1 | 39.6%（per-test top-30%） | 21.1% | +18.5 个点，约 +88% 相对提升 |
| LCB OOD 中位样本速度胜率 $\mathrm{WR}_m$（CWM 32B vs 标准 RLVR） | 成对速度胜率（>50% 即更快） | 82.9%–83.0%（top-30%/0.5s 过滤训练） | 50%（参考线） | +33 个百分点胜率 |
| DMC-Optim 退化沙箱下相对标准 RLVR（CWM 32B） | pass@1 相对提升 | 优化 RL | 标准 RLVR | 约 +100%–200%（视评估准则） |
| 复杂度类提升占比（优化 RL vs RLVR，GPT-OSS 盲评） | 可分类速度胜对中复杂度提升占比 | 13% | 0%（RLVR 自身基线）/ 人类对 RLVR 22% | 约为人类速率的一半 |
局限与改进
作者承认的局限很坦诚。首先 DMC-Optim 是个窄设定：单文件 Python 竞赛题，部分奖励依赖固定的人类计时池，计时信号仍依赖有噪声的沙箱执行；它不覆盖仓库级 profiling、内存目标、多语言系统代码或长时编辑循环。其次整条流水线很贵——需要更强的测试、大量沙箱执行和大算力才能让计时奖励被 RL 学到；离线模拟器虽能省一部分钱，但端到端开销仍然不可忽略。第三，作者观察到一个 emergent 行为：优化 RL 训练的模型倾向于剥掉对 benchmark harness 有用但运行时更慢的东西（类包装、方法派发、未用接口），这对真实下游使用不友好，需要指令遵循排练或接口保持约束来缓解。第四，judge 分析受 GPT-OSS 限制：它在「找最快样本」任务上只有 68% 准确率（人类 vs 优化 RL 的紧对上掉到 59%），22% 的速度胜对无法分类而被丢弃，可能恰恰藏了更有趣的非 I/O 改进。我自己还注意到几点：评估集只有 302 题，$p_{10}$ 这种极严分位上的绝对分仍很低（个位数），且 test-time CI 在 $p_{50}$ 达 ±4.3 个点，意味着小差距需要谨慎解读；CWM 32B 的 SFT 数据对 DMC-Optim 测试/训练 prompt 的去污染无法保证，虽然作者论证它没怎么受益，但仍是个潜在污染源。
独立分析的弱点
弱点一：奖励对「改进类型」是盲的。Figure 8 显示模型把大量学习预算花在 I/O（47%）和常数因子（34%）优化上，而真正能拉开与人类差距的数学捷径（人类 16% vs 模型 6%）和算法改进（人类 11% vs 模型 6%）占比很低。改进方向：引入算法感知反馈，比如用价值模型或静态分析器区分「这是 I/O 技巧」还是「这是复杂度提升」，对不同类型给不同奖励权重，或在 SFT 阶段注入更多带复杂度标注的 slow-fast 对。弱点二：硬依赖固定人类参考池。post-exec 排名奖励需要每题的人类时长分布，这在题库外（尤其是真实 SWE 任务）几乎不可得，限制了迁移。改进方向：用生成式或学习式参考分布替代固定池，甚至做对抗式自举（参考 Romera-Paredes、Novikov 等）。弱点三：one-shot 设定下纯正确性仍会被挤占。LCB 上 $p_{30}$ 训练使 pass@1 在 7B 上掉约 8%，在 Hard 子集上从 29.8% 掉到 25.7%（−13%）。改进方向：分阶段课程（先正确性 RL 再叠加优化 RL）、或动态调节正确性与优化门权重的自适应奖励。弱点四：评估集小且 $p_{10}$ 信号稀薄。302 题、$p_{10}$ 绝对分仅 6–10 个点，统计显著性边际。改进方向：扩充 DMC-Optim 测试集，或引入更多样化的计时型 benchmark。弱点五：pipeline 复现成本高（CES 集群、仿射校准、duration filterability 筛选），对学术小实验室不友好。改进方向：开源校准后的存储时长与人类分布，让社区无需重跑沙箱即可复现。
未来方向
作者明确点名的方向有：把方法迁移到真实软件工程任务（仓库级 profiling、内存目标、多语言系统代码、长时编辑循环），因为同样的 correctness–efficiency 鸿沟在 SWE-fficiency 上更严重（Claude 4.5 Sonnet 81% 正确但仅 4.1% 专家加速）；用生成/学习式或对抗式参考分布替代固定人类池；用算法感知反馈（很可能通过价值模型）把学习从 I/O 技巧推向真正的算法发现。基于本文成果我还能延伸出几个方向：第一，把「离线 RL 模拟器 + AUC/steepness 双诊断」推广为通用的「奖励可学习性」体检工具，用于任何稀疏噪声奖励场景（如工具调用、Agent 任务）；第二，研究 correctness–efficiency Pareto 前沿的几何结构（Zheng et al. 2026 已开题），用多目标 RL（如 Pareto-MORL）替代手工选阈值；第三，把 duration filterability 这类「数据是否承载信号」的判据做成自动数据构造流水线，自动生成针对当前模型弱点的优化测试；第四，结合推理时搜索（best-of-N、MCTS）与优化 RL 策略，验证二者是否互补——本文已显示推理搜索只能部分恢复速度（$\mathrm{WR}_b$ 仍达 66%+），说明策略本身被改造了，二者结合值得探索。
复现评估
复现门槛偏高但路径清晰。模型权重可得：Qwen 2.5 7B/32B 与 CWM 32B 均为公开发布的 checkpoint。SFT 数据（OpenCodeReasoning-2、OpenMathReasoning）公开，作者也说明了去污染协议（对 DMC、LCB、BigO(Bench) 去污染，52.1B packed token，lr $8.6\times10^{-6}$，7B 用 128 个 H100、32B 用 256 个 H100）。RL 配置详尽：10,000 步、温度 1.0、lr $1\times10^{-7}$/32B $1.4\times10^{-7}$、16 rollout/prompt、固定 token horizon $N=32768$、$S_{\max}=30$；7B 用 8 个 H100 节点跑约 1 天，32B 用 32 个 H100 节点跑约 1.5 天——这意味着完整复现三组规模实验至少需要数千 GPU·日，对学术实验室不友好。数据侧是主要难点：DMC-Optim 本身（含 430k 新增正确性测试、352k 优化测试、人类时长分布）的发布状态论文未明确说明，且最关键的 CES 远程沙箱及其仿射校准流水线（53 ms 截距、Spearman 0.54→0.96）属于工程基建，论文虽给了详尽附录（Sections B/C）但完全自建成本极高。好消息是评估可「回放」：作者把生成解的判定与时长存盘后，可在不重跑模型/沙箱的情况下扫描不同百分位/超时/校准，这降低了他人复现评估实验的门槛。总体评分：方法描述与超参 ★★★★★，数据/沙箱可得性 ★★☆☆☆，算力可承受度 ★★☆☆☆。
论文图表
