ReCode: Updating Code API Knowledge with Reinforcement Learning¶
会议: AAAI 2026
arXiv: 2506.20495
代码: https://github.com/zjunlp/ReCode
领域: LLM推理
关键词: 代码生成, API更新, 强化学习, GRPO, 版本迁移
一句话总结¶
提出 ReCode 框架，通过基于规则的强化学习（而非 SFT）训练 LLM 在 prompt 中正确利用 API 更新文档完成代码版本迁移，使 7B 模型在 CodeUpdateArena 上超越 32B 模型。
研究背景与动机¶
LLM 已经展现出很强的代码生成能力，但外部库的 API 更新非常频繁（如 NumPy、PyTorch 版本迭代），而模型参数中存储的是训练时的旧版 API 知识。当用户使用新版本环境时，模型生成的代码可能调用已废弃的 API 导致运行失败。
现有方案的问题：（1）SFT 直接微调模型学习新 API 知识，但 API 更新频率高，持续微调成本大且容易产生灾难性遗忘；（2）将更新文档放入 prompt（类似 RAG），虽然不改参数但效果有限——模型存在"懒惰"倾向，当 prompt 中的新信息与参数中的旧知识冲突时，模型倾向于使用内部旧知识而忽略外部文档。
核心矛盾：参数内旧知识与 prompt 中新知识之间的冲突。模型天然倾向于信任自己的参数知识，导致即使提供了完整的更新文档，代码仍然使用旧 API。
本文切入角度：既然问题不是"不知道新 API"而是"不愿意用 prompt 中的新信息"，那就用强化学习训练模型养成"尊重 prompt 中外部知识"的习惯。模仿人类程序员的学习模式——先学旧版本，看到更新说明后将代码迁移到新版本。
方法详解¶
整体框架¶
ReCode 的核心思路是：构建一个版本迁移训练任务，用 RL（而非 SFT）微调模型，使其学会根据 prompt 中的 API 更新文档将旧代码迁移为新代码。测试时，模型则基于更新文档完成实际编程任务。
训练流程：输入为 [依赖库, 目标版本, 更新说明, 旧代码]，输出为迁移后的新版本代码。通过 RL 的奖励信号（字符串匹配 + AST 语法检查）引导模型学会读懂更新文档并正确迁移。
测试流程：在 CodeUpdateArena 上，给定依赖库、API 更新文档、编程问题和函数签名，模型生成使用新 API 的完整函数代码，用测试用例 Pass@k 评估。
关键设计¶
- 训练数据构建（约 2000 条）
- 从 NumPy、Pandas、PyTorch、matplotlib 等主流库的 release notes 中提取真实 API 更新描述
- 用 GPT-4 为每条更新生成旧版和新版两段等功能代码
- 人工审核确保代码正确性，覆盖 API 重命名、参数新增、功能修改等多种变更类型
-
与测试集 CodeUpdateArena（LLM 合成数据）在来源上完全隔离，避免数据泄露
-
奖励设计（Format + Correctness）
- 格式奖励：输出必须包含
<think>...</think><answer>...</answer>标签，满足 +1 否则 -1 - 正确性奖励：关键创新点——不用测试用例通过率（因为迁移任务关注的是"迁移"而非综合正确性），而是基于字符串匹配度
- 提出 ES*（Edit Similarity + AST 语法检查）：先检查输出是否通过 AST 解析（语法正确），语法错误直接 -2.0；语法正确则按 \(ES^*(x) = ES(x) \times 3.5 - 1.5\) 映射到 \([-1.5, 2.0]\) 区间
-
对比实验表明 ES 优于 EM，因为 ES 提供连续奖励值避免 GRPO 中 group 内奖励全相同导致优势为零的问题
-
RL 算法选择
- 支持 GRPO 和 DAPO 两种策略梯度算法
- 使用 DoRA（r=64, α=64）做参数高效微调，训练 5000 步，batch size 8，学习率 \(5 \times 10^{-5}\)
损失函数 / 训练策略¶
总奖励 = 格式奖励 + 正确性奖励（ES*）。训练前 150 步用 warm-up，之后 cosine 衰减。训练初期奖励会短暂下降（instruction-tuned 模型丢失原有指令跟随能力进入探索阶段），之后稳步上升。
实验关键数据¶
主实验¶
| 模型 | 方法 | CodeUpdateArena Pass@1 | Pass@5 | HumanEval+ (Δ) |
|---|---|---|---|---|
| Qwen2.5-Coder-32B-Instruct | 未训练 | 75.7 | 84.3 | - |
| DeepSeek-R1-Distill-Qwen-32B | 未训练 | 78.2 | 86.1 | - |
| Qwen2.5-Coder-7B-Instruct | 未训练 | 67.3 | 74.0 | 84.1 |
| Qwen2.5-Coder-7B-Instruct | SFT | 69.4 (+2.1) | 78.2 (+4.1) | 70.2 (-11.7) |
| Qwen2.5-Coder-7B-Instruct | ReCode GRPO | 74.6 (+7.4) | 82.1 (+8.0) | 82.3 (-1.8) |
| Qwen2.5-Coder-7B-Instruct | ReCode DAPO | 78.7 (+11.3) | 84.3 (+10.2) | 81.7 (-2.4) |
| DS-v1.5-Coder-7B-Instruct | ReCode DAPO | 63.6 (+4.5) | 78.2 (+5.6) | 68.9 (-2.4) |
核心发现：Qwen2.5-Coder-7B + ReCode DAPO 的 Pass@1 达到 78.7，超越 32B 指令微调模型（75.7）和 32B 推理模型（78.2）。
消融实验（奖励设计）¶
| 正确性奖励 | Pass@1 (Δ) | Pass@5 (Δ) |
|---|---|---|
| 仅 format | -2.3 | -3.0 |
| +EM | -1.2 | -3.2 |
| +ES | +5.4 | +5.2 |
| +EM* (加 AST) | +1.1 | +2.0 |
| +ES* (加 AST) | +7.4 | +8.0 |
关键发现¶
- ES 优于 EM：连续相似度奖励比严格匹配更适合 GRPO，避免 group 内所有样本奖励相同导致零优势
- AST 语法检查必要：加入 AST 检查后 EM 和 ES 均优于原始版本，纯字符串匹配可能导致模型对任务理解退化
- SFT 严重损害通用能力：SFT 在 HumanEval+ 上掉了 11.7 分，而 ReCode 仅掉 1.8-2.4 分
- 多 API 更新场景：在 20 个涉及多 API 同时更新的测试中，ReCode 将 7B 模型从 35→60 Pass@1，接近 32B 推理模型的 65
亮点与洞察¶
- RL 解决知识冲突的新思路：不是往模型里写新知识，而是训练模型"尊重 prompt 中的外部信息"，这是一个通用且可迁移的方案，对所有 RAG 场景都有启发
- 训练-测试任务解耦：训练做代码版本迁移，测试做基于更新文档的编程，两个任务不同但能力可迁移，说明 RL 学到了泛化能力而非记忆特定模式
- 连续奖励避免 GRPO 零优势问题：ES 比 EM 更适合 group-based RL 算法，因为能提供区分度
局限性 / 可改进方向¶
- 训练数据仅 2000 条且限于 Python 数据科学库，覆盖面有限，能否扩展到 JavaScript/Rust 等其他语言生态？
- 模型能力上限受预训练基座限制——需要物理推理等能力的代码任务，RL 无法弥补
- 当前奖励基于字符串匹配而非执行测试，对功能等价但写法不同的代码可能给低分
- DAPO 比 GRPO 效果更好但未深入分析原因
相关工作与启发¶
- vs SFT 方案 (Liu et al. 2025c)：SFT 通过 prompt-answer 对记忆迁移模式，泛化差且通用能力退化严重；ReCode 通过 RL 鼓励模型真正理解文档，泛化更好
- vs RAG 方案：单纯 RAG 受限于模型"懒于使用外部信息"，ReCode 从根本上增强了模型利用 prompt 信息的能力，可作为 RAG 系统的增强训练方案
- vs Versicode (Wu et al. 2024)：Versicode 只覆盖 API 重命名，本文数据集涵盖参数新增、功能修改等更多变更类型
评分¶
- 新颖性: ⭐⭐⭐⭐ 将 RL 用于 API 更新场景是首次探索，但方法本身（GRPO + LoRA）是已有组件的组合
- 实验充分度: ⭐⭐⭐⭐ 消融实验设计精巧，多 API 场景和通用能力评估都有覆盖
- 写作质量: ⭐⭐⭐⭐ 问题动机清晰，Case Study 有说服力
- 价值: ⭐⭐⭐⭐ RL 解决参数-prompt 知识冲突的思路具有通用价值，对 RAG 系统优化有启发