利用基于执行的可验证监督引导小众多语言代码翻译的强化学习方法

# 通过基于执行的可验证监督强化学习引导特定领域多语言代码翻译

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

曾杰 Kyoko Ogawa Ryunosuke Ikeda 小桥洋平 小嶋武史 山田郁也 岩沢祐介 松尾豊

###### 摘要

代码翻译必须在多种编程语言间保持可执行行为的一致性，然而神经代码翻译的研究大多集中于 C++、Java 和 Python 等少数流行语言。这留下了一个特定领域的多对多场景，其中并行监督稀疏，导致生成看似合理但不可执行的翻译。我们通过基于执行监督的偏好强化学习来应对此场景。我们的流水线首先将可验证的种子 Python 程序扩展为经过执行验证的多语言代码库。利用该代码库，基础大语言模型生成跨语言对的翻译候选，我们根据其执行结果对其进行标记。由此产生的偏好用于训练奖励模型，以评估跨语言翻译质量。最后，我们使用 GRPO 算法，以奖励模型为信号，对基础大语言模型在 600 个有向语言对（25 × 24）上进行优化。为评估特定领域翻译能力，我们引入了 HumanEval-X++，这是一个基于执行的基准测试，它将 HumanEval-X 扩展到了广泛的多对多语言空间。我们使用 Qwen-3.5 4B 和 9B 模型评估了我们的方法。在 HumanEval-X++ 和现有基准测试中，相较于未训练的基线模型，该方法均带来了一致的提升。特别是，4B 模型在 HumanEval-X++ 上所有语言的平均改进达到 13%，在中等规模语言上提升了 21%。我们的研究建立了一种可靠的数据生成、训练和基准测试方法，为进一步提升编程语言多对多翻译质量铺平了道路。

## 1 引言

模型代码翻译利用基于执行的验证训练方法源语言数量目标语言数量TransCoder (Lachaux et al. 2020)33×反向翻译TransCoder-ST (Roziere et al. 2021)33✓自训练CoTran (Jana et al. 2023)22✓SFT + RL (PPO)CodeGeeX (Zheng et al. 2023)77×SFTExeCoder (He et al. 2025)33×SFTOORL (Wu et al. 2025)26✓RL (GEPO + REINFORCE++)EffiReasonTrans (Wang et al. 2025)33✓SFT + RL (GRPO)BootTrans (Wu et al. 2026)33✓RL (GRPO)CodePivot (Li et al. 2026)19✓SFT + RL (GRPO)本研究2525✓RL (GRPO) + 学习的奖励模型表 1：通过模型训练引导多对多代码翻译的相关工作。语言数量（“源语言数”，“目标语言数”）指的是每种方法训练流水线所覆盖的语言数量。“利用基于执行的验证”指示在训练过程中是否使用实际单元测试执行来验证和奖励翻译结果。现代软件采用多种不同的编程语言编写，这些语言具有不同的语法、惯用法和类型系统。代码翻译是软件迁移、现代化、重用和互操作的一项重要能力，但实用的翻译模型必须能够在多种语言对之间可靠地工作，同时保持可执行行为。在多对多代码翻译场景中，监督稀疏且特定语言的知识可靠性较低，这增加了看似合理的翻译无法保持可执行行为的风险 (Roziere et al. 2021)。

先前的工作通过执行验证的自训练、基于反馈的优化以及增强推理的训练，提升了大型语言模型的代码翻译能力 (Lachaux et al. 2020; Roziere et al. 2021; Jana et al. 2023; Wang et al. 2025)。然而，这些努力主要针对少量流行语言对或特定的翻译方向，如 C++、Java 和 Python (Lachaux et al. 2020)，使得使用率较低的语言尽管有实际需求，但探索不足（参见第 2 节）。这留下了一个开放问题：如何构建可扩展的、基于执行的监督，以引导基于强化学习的特定领域多对多翻译。多对多翻译通常需要我们处理大量低资源语言，因为随着目标语言变得特定且长尾，其监督翻译数据变得稀疏。

我们通过引入 NicheCodeTranslator 来解决这一差距，该模型将 RL 应用于长尾多对多代码翻译，使用通过可扩展的、验证驱动的引导流水线构建的基于奖励模型的监督（参见第 3 节）。具体而言，该流水线首先将可验证的种子 Python 程序扩展为经过执行验证的多语言代码库。利用该代码库，基础大语言模型生成跨语言对的翻译候选，我们根据其执行结果标记其成功或失败。由此产生的偏好用于训练奖励模型，以评估跨语言翻译质量。最后，我们使用 GRPO 算法，以奖励模型为信号，对基础大语言模型在 600 个有向语言对（25 × 24）上进行优化。

我们还提出了 HumanEval-X++，这是一个新的基于执行的基准测试，用于长尾多对多代码翻译，以实现对流行和非主流翻译方向之间翻译质量的受控评估（参见第 4 节）。基于 HumanEval-X (Zheng et al. 2023)，HumanEval-X++ 通过整理目标语言提示、可执行函数签名和具有跨语言可比问题语义的测试套件，将代码翻译的原始评估对（源：6 种语言 -> 目标：6 种语言）扩展到更广泛的多对多语言空间（源：6 种语言 -> 目标：25 种语言）。

我们在 HumanEval-X++ 和现有代码翻译基准 CodeScope (Yan et al. 2024) 上评估了我们的方法，使用 Qwen-3.5 4B 和 9B 模型，这些模型在这些参数规模下为代码翻译提供了强大的基线（参见第 5 节）。我们的实验显示，相较于未经训练的基线模型，一致性地有所提升。特别是，4B 模型在 HumanEval-X++ 上所有语言的平均改进达到 13%，在中等规模语言上提升了 21%，表明相对于流行语言，改进在特定语言上尤为显著。

参见图例图 1：我们流水线的概览。数据生成：阶段 1 为每个 KodCode Python 种子合成断言，并进行基于沙盒执行的过滤，然后进行类型推断。阶段 2 将代码和断言对导出到另外 24 种语言。只有通过所有转译测试的候选才被接受，产生 25 种语言中经过执行验证的源程序。阶段 3 通过将每个源程序翻译成其他 24 种语言来构建标记的配对数据，沙盒执行标记每个候选为正或负，覆盖 25×24=600 个方向。训练：阶段 1 在这些经过执行验证的标签上训练奖励模型。单个模型对所有翻译方向进行评分。阶段 2 使用 GRPO 在经过验证的源代码库上优化策略。学习的奖励在滚出时取代了每种语言的沙盒：RL 稳定且高效地扩展到 600 个方向。评估：通过相同的基于规则的转译，HumanEval-X 被扩展为 HumanEval-X++，将目标从 6 种语言拓宽到 25 种语言。模型通过将生成的代码与转译的测试套件进行执行来评估。

## 2 相关工作

代码翻译长期以来一直用于多种场景，包括遗留资产的迁移、由不同语言组成的系统的集成，以及规范变更场景，例如将 Python 2 更新为 Python 3 或将 COBOL 迁移到 Java。与自然语言翻译不同，代码翻译优先考虑功能等价性而非表面相似性。因此，基于执行的评估——基于可编译性、可执行性和单元测试通过率——比 BLEU 等静态指标更受重视。特别是在多对多场景中，必须在不失败的情况下，跨多种语言再现相同的功能。

TransCoder (Lachaux et al. 2020) 是该领域的开创性工作，实现了 C++、Java 和 Python 之间的无监督多对多翻译（例如，去噪自编码、反向翻译等），证明了在没有并行数据的情况下翻译是可行的。然而，其训练并未利用代码可执行性信息（例如，编译或测试结果），且其关注的语言局限于三种。后续的工作 TransCoder-ST (Roziere et al. 2021) 提出了自训练，即使用通过单元测试的自生成翻译样本来训练模型。CoTran (Jana et al. 2023) 是将执行反馈直接引入训练循环的早期尝试。它通过在 Java-Python 翻译上交替进行有监督微调和基于 PPO 的强化学习来微调模型。然而，其覆盖范围仍局限于两种语言。

CodeGeeX (Zheng et al. 2023) 是一个在 23 种独立语言（非翻译对）上使用约 8500 亿 token 进行预训练的大规模模型，随后在由 7 种语言组成的翻译对上进行了有监督微调。此外，它引入了 HumanEval-X，这是 HumanEval 的多语言扩展。这使得能够在相同的测试规范下比较包括翻译在内的多语言代码任务，为研究进展和基准开发做出了重要贡献。ExeCoder (He et al. 2025) 逐步纳入了与执行相关的表示，如函数语义、抽象语法树和变量依赖图，提高了 C++、Java 和 Python 之间翻译的准确性。尽管如此，其目标语言仍限于三种。

OORL (Wu et al. 2025) 引入了基于单元测试奖励的在策略强化学习。它还采用了基于中间表示等价性的 GEPO 进行偏好优化。然而，它既不执行自动测试合成，也不进行训练数据增强。EffiReasonTrans (Wang et al. 2025) 通过从更强的推理模型中蒸馏（源代码、推理过程、目标代码）三元组来增强代码翻译，仅保留通过自动语法验证和功能测试的样本。然后应用有监督微调，接着使用结合单元测试通过率和输出长度容忍项的双重奖励进行 GRPO。BootTrans (Wu et al. 2026) 采用具有丰富代码-测试对的资源丰富枢轴语言（Python），通过基于规则的模板将测试预言机移植到目标语言，扩展了翻译矩阵，并解锁了种子数据中缺失的反向和跨语言方向。然而，训练仅限于三种语言。CodePivot (Li et al. 2026) 仅通过 SFT 和 GRPO 训练 Python 到其他方向（9 个目标），利用执行奖励，并依赖零样本迁移来处理 10 种语言中的其余方向。

尽管先前的工作表明基于执行验证的 RL 是引导代码翻译的可靠训练信号，但它需要预设每种语言的编译器、运行时和测试框架用于 RL 的滚出。这一要求在扩展目标语言数量（涵盖特定和长尾语言）进行训练时，阻碍了实际可行性，例如耗时的验证和单元测试期间意外的运行时错误。我们的工作通过将奖励与每种语言的执行基础设施解耦来解决这一局限性。我们训练一个预测功能单元测试结果的奖励模型，并使用此学习的奖励通过 GRPO 优化策略。这使得训练流水线能够稳定地扩展到 25 种目标语言，比先前工作高出一个数量级，同时仍然植根于功能正确性。作为参考，先前的工作 (Zhu et al. 2024) 报告称，基于奖励模型的方法在编码（而非翻译）任务中优于基于测试的方法。

## 3 NicheCodeTranslator

### 3.1 生成经过验证的翻译数据

翻译质量由功能等价性定义 (Lachaux et al. 2020)；其实际代理是在*目标*语言中可执行的单元测试套件。因此，训练数据必须将每段翻译与这样的测试配对。由于任何语言的候选代码都可以从大语言模型中廉价采样，因此每个配对中稀缺的部分是测试。我们的流水线通过将*验证能力*从 Python 传播到每一种其他语言来解决这一稀缺性，并遵循三个原则：(1) 每个工件都源自，并针对从大型公共语料库中抽取的 Python 参考解决方案进行验证 (Xu et al. 2025)；(2) 测试和接口仅通过确定性的、基于规则的转译跨越语言边界 (Cassano et al. 2023)，从不通过生成模型；(3) 候选代码仅通过沙盒执行才能进入数据集，从不依赖易错的 LLM 判断。

流水线分为三个阶段（图 1）：阶段 1 从种子 Python 代码合成有效的断言，阶段 2 将其导出到其他 24 种语言，阶段 3 为每种语言生成翻译数据用于奖励模型训练。

#### 阶段 1：合成有效断言

##### 种子整理。

我们选择 KodCode (Xu et al. 2025) 作为 Python 种子代码的来源，因为它提供了一个庞大的、经过验证的 Python 程序集合，这些程序由多个来源合成，涵盖了广泛的编程任务和领域。KodCode 中的每个实例都是一个独立的、函数级别的任务，包含问题描述、参考解决方案和单元测试。在整理过程中，我们保留满足以下条件的实例：(1) 解决方案仅定义一个函数且没有类，(2) 仅导入标准库模块，(3) 目标函数在附加的断言测试中被实际调用。

##### 测试合成。

数据生成 LLM 生成候选测试，这些测试被限制为对字面量的单个断言，以便基于规则的转译器能够确定性地转换它们。