📚 plmblog

Appearance

Code RL 任务

📅 发表于 2025/12/18
🔄 更新于 2025/12/18
👁️ -- 次访问
📝 0 字
⏳ 0 分钟

参考文章 ​

参考文章

代码生成(生成+补全+翻译) ​

代码合成 ​

代码合成 NL2Code

PPO 时代

  • (2022) CodeRL：PPO算法，训练Critic预估每步价值，在APPS和MBPP效果不错。

DPO 时代

  • (2410) CodeDPO：引入PageRank算法生成高质量偏好数据对
  • (2502) Focused-DPO：针对容易出错的地方进行优化

RLVR 时代

代码补全 ​

代码补全

检索/RL

  • (2407) RLCoder：仓库级代码补全，学习检索有用信息，在CrossCodeEval和RepoEval上提升12.2%
  • (2409) Repogenreflex：仓库级代码补全，RL + RAG，动态优化检索。
  • (2401) IRCoco：提供即时奖励。
  • (2503) aiXcoder-7B-v2：RL监督信号去解决LLM忽略长距离上下文的问题。

DPO

  • (2508) SynthCoder：课程学习 + DPO，在FIM上达SOTA。

工业应用

  • (2509) Cusor-Tab-Online-RL：每天4亿请求，通过用户反馈持续优化模型。
  • (2412) AugmentCode RLDB：学习开发者-IDE的交互，相当于模型参数翻倍的提升。

代码翻译 ​

代码翻译
  • CoTran
  • TransAgent

代码理解(摘要+注释+搜索) ​

代码理解

摘要

  • 难点：暴露偏差、结构信息丢失。
  • 方法：
    • Actor-Critic + AST
    • ICSER：先理解找关键部分，再用RL去生成摘要。

注释生成

  • 核心：解释具体实现逻辑、参数含义、API用法等。
  • 利用类型信息：TAG，分层RL
  • 关注块结构/块注释：RL-BlockCom
  • CoRAL：面向下游任务优化：认为好的注释能帮助改进代码。
    • 奖励函数：语义相似度 + 是否能作为输入帮助模型完成代码优化

搜索

  • 任务：输入NL，找到对应的代码片段
  • CoaCor：希望RL生成提高检索区分度的注释。
  • QueCos：改写扩充query
    • 奖励信号：搜索结果的准确性。

SWE (Issue修复+重构+评审+优化) ​

Issue修复 ​

Issue修复

解决github Issue核心挑战

  • 环境复杂：需要在成百上千的文件中找到出错的那一行。
  • 步骤繁琐：需要理解issue描述、复现bug、修改代码、跑测试、确定修好了再提交。
  • 反馈稀疏：只有测试通过，才算成功。中间没有明确指导

RL 工作

  • (2502) SWE-RL：开源仓库+RL+提升推理能力，能够有效解决Github Issue。
  • (2507) DeepSWE：扩展RL规模，完全开源，SWE-Bench SOTA。
  • (2508) SWE-Swiss：2阶段训练策略
    • 多任务SFT：增加定位、修复和单元测试的能力。
    • RL：优化repair技能
  • (2505) Satori-SWE：EvoScale，进化式TestTimeScaling，
    • 自我进化：生成一个补丁没过，继续分析为什么没过，生成下一个补丁，继续迭代
    • RL作用：训练模型自我纠错能力，教会模型如何反馈不断迭代，直到正确。
    • 效果：较少样本、多轮迭代，32B达到100B效果

代码重构 ​

代码重构
  • (2412) Refactor-RL
    • 识别代码块 -> 提取成新函数 -> 起个好名字
    • PPO 算法，奖励信号：编译成功、是否重构。
    • 效果：RL比SFT强，BLEU/CodeBLEU指标、单元测试通过率提升。

Code Review ​

Code Review
  • Attn+PG+RL
  • CodeMentor

代码优化 ​

代码优化
  • Pearl

代码安全 ​

Bug 检测 ​

Bug检测

挑战

  • 调试信息有限、bug搜索空间大

工作

  • (20) RecBI：RL应用于编译器隔离，智能引导诊断测试程序生成
  • (24) RLocator：
    • 用户报bug，需要定位找到文件；传统方法：基于相似度找文件。
    • 看作排序问题，把MAP指标当做奖励函数，引导把正确答案排在前面。

Bug 修复 ​

Bug修复
  • (24) Repair：过程监督，引入Critic为每一步操作打分
  • (2507) Repair-R1：左右互搏，边修bug 边写测试用例，协同训练。
  • (2506) Repairity：GPT4蒸馏 + SFT + RL

代码测试 ​

测试生成 ​

测试生成

背景

  • AI写出高质量测试，能够自动评估代码、反过来帮助训练模型。

关键工作

  • (2506) Co-Evolving：协同优化，代码生成和单元测试生成的能力。
  • (2508) UTRL：对抗训练，测试用例生成(找bug) + 代码生成(写出健壮代码)。

模糊测试 ​

模糊测试

背景

  • 自动化软件测试，向程序输入随机数据来找出bug。

关键工作

  • (2019) REINAM：无种子，利用RL去猜输入。
  • (2022) RLF：区块链安全。
  • (2024) CovRL-Fuzz：JS，LLM负责生成复杂代码片段，RL负责探索路径，找bug。

算法相关 ​

RL 算法 ​

大致发展

整体流程

  • 流程：编译 -> 运行 -> 测试，生成 -> 运行 -> 调试
  • 奖励：单元测试通过率，语法错误，验证反馈等。

主要算法

  • PPO：KL约束，限制策略更新幅度，实现在线探索。结合循环，提高pass@k指标。
  • DPO：无法在线采样。
  • RAIF：利用强模型提供dense/结构化的奖励信号。
  • O1/R1：执行反馈、验证器、自我迭代修正。
PPO及其变体
  • PPO：CLIP限制幅度/GAE平衡偏差方差。
    • 但PPO在稀疏奖励场景效果一般，因为Critic不好训，价值崩塌，难以区分状态好坏，输出几乎相同。
  • GRPO：不学Critic，使用组相对优势。
    • 降低显存，稳定更新。
    • 优化方向：group baseline、rollout效率、group多样性。
  • (2503)DR.GRPO：解决长度和问题难度偏差，样本间平均以及不除以标准差。
  • (2504) DAPO：CLip-Higher, 动态采样，Token-level Loss，超长Reward奖励
  • (2504) VAPO：解决价值偏差、长度不一致、奖励稀疏问题。
    • 价值预训练、解耦GAE、长度自适应GAE、Token-Level Loss、CLip-HIgher、正样本LMLoss、分组采样。
  • (2501) REINFORCE++：全局归一化、PPO训练目标无需Critic
DPO 及其变体
  • DPO：偏好建模，直接优化策略，纯依赖离线偏好数据。
    • 缺点：无在线采样数据、优化不稳定、依赖SFT模型和数据质量。
    • 优点：简单、快速、成本低，无需reward或value model
  • (2503) DPO-VP：集成数学和code，把正确输出的作为正样本。
  • Iterative DPO：多轮迭代、Offline-RL，仍使用DPO Loss
    • 多轮迭代：模型生成数据、验证打分，挑选出好的，构造Pair数据
  • (2410) CodeDPO：Code+DPO，代码和测试用例同时创建评估，PageRank更新分数
RLAIF
  • 直接使用高级LLM做打分，来给反馈。
    • 自己训的RM可能会失真，reward hacking。
  • LLM-based Critic：自我修正、CoT Review、宪法原则，提供结构化反馈。
    • Skywork-OR1，CRITIC、宪法AI等。
  • 挑战：reward hacking、bias 传播、计算成本

Reward 设计 ​

面向正确性 ​

Reward Shaping

背景

  • 期望模型：功能正确、安全、可维护、符合软件工程标准。
  • 四个维度：正确性、任务对齐、安全性、结构质量。

三个层次

  • 人类偏好：RLHF。
    • 解决：主观质量、可读性、风格等问题。
  • ORM(Outcome-superviesd RM)
    • 解决：正确性问题。
    • 局限性：奖励稀疏问题，只看结果，有时候代码逻辑正确、仅最后一步错误，可能会判0分。
  • PRM(Process RM)
    • 解决：ORM局限性问题，在每一步都做一个评估。
面向正确性的奖励

面向任务正确的奖励

  • 静态分析奖励：检查语法和规范
    • 基于Pylint,Flake8等编译器，检查语法、拼写、类型等错误。
    • 优点：快、安全、即时。
  • 测试用例奖励：检查逻辑和功能
    • RLVR最核心部分。
    • 测试用例：可以由AI或专门工具生成，自我验证。

面向代码质量 ​

除正确性以外，还需满足软件工程标准。

高质量代码
  • 任务对齐(Task Alignment)：指令跟随、听懂人话。
  • 安全性
    • 避免漏洞：避免已知安全缺陷(SQL注入等)，可给奖励。
    • 执行访问控制：权限检查、认证机制时，可给奖励。
  • 结构好：代码整洁
    • 模块化可重用性：职责清晰、函数模块定义较好、可读性好，可给奖励。
    • 接口兼容：遵循现有API、类结构、可无缝集成等， 可给奖励。
两种方法

硬指标奖励

  • 直接给奖励。

软指标奖励：RLHF

  • 正确性奖励难以捕捉可读性、清晰度、风格等审美维度。
  • 让人类进行标注：A 和 B 偏好比较
  • DPO、PPO。

过程奖励：PRM

  • ORM存在奖励稀疏问题。
    • 写了几百行代码，第3行错误，全部都给0分。但模型不知道是第3行错误。
    • PRM 能减少探索空间，支持渐进式学习。
  • 设计原则：
    • 局部有效性：如当前token的语法正确性。
    • 全局一致性：是否符合全局问题逻辑。
  • 实现机制
    • Token-Level PRM：预测每个token的奖励。
    • State-Tracking PRM：维护内部状态，评估部分代码是否满足结构约束。

数据相关 ​

可用数据集 ​

数据集
  • CodeContests：1.33w，程序竞赛题，早期基石。
  • CodeContets+：Seed扩充了高质量测试用例。
  • TACO：算法代码数据，2.5w训练 + 1k测试，总计155w个答案。
  • Eurus-2-RL：2.7w编程+45w数学题。
  • IOI：国际奥林匹克竞赛，229问题，高级挑战。
  • ACECode-87k：合成代码数据集，技术：自动测试用例生成。
    • GPT-4o-mini为每个问题生成了16个测试用例；并提出无效的。
  • Synthetic-1：140w任务，数学、编程、软件工程等多个领域。14.4w代码合成和理解问题。
  • Synthetic2：400w，更大。
  • KodCode：48.4k，问题+解决方案+测试 三元组。
    • 领域广泛：基础算法、经典数据结构、复杂特定领域等。
  • HardTests：4.71w问题，合成测试用例增强。
  • Code-R1-12k：精选RL数据集，2k leetcode + 1w TACO筛选。
  • LeetCodeDataset：python数据集，90%leetcode问题。每个问题有难度、标签，有100测试集。
  • Klear-CodeTest：快手，2.7w编程题。通过生成-检查器构建的。
总访客数：   ·   总访问量：
PLM's Blog @ 2016 - 2026