CodeAlchemy：大规模合成代码重写

# CodeAlchemy：大规模合成代码重写

来源：https://arxiv.org/html/2606.10087 | MIT-IBM Watson AI Lab, IBM Research

###### 摘要

在原始代码上预训练可以教授语法，但缺乏针对多样化真实任务格式的丰富信号。虽然合成数据已被证明对语言模型具有变革性，但代码领域除有限的改进外，仍较少被探索。我们提出**CodeAlchemy**，一个通过5种策略将公开代码转换为语义丰富的训练数据的合成数据生成框架：**CodeEnhance**（质量感知重写）、**CodeQA**（基于模板的问题）、**CodeDev**（开发者任务）、**CodeDialogue**（多轮对话）和**CodeTrace**（执行跟踪）。我们处理了涵盖15种语言的3个语料库，生成了>500B tokens的合成数据以及350B推理tokens，规模比之前的工作高出数个数量级。**CodeTrace**对14种语言和5K个库中的>1.3M文件进行插桩并执行，捕获控制流、状态跟踪和库知识。我们引入了**DevEval**（开发者任务）和**TraceEval**（执行预测）基准测试；前沿模型（如 Claude Sonnet 4.5）在TraceEval上的准确匹配率仅为5.6%，揭示了语义理解方面的关键差距。我们的3B模型在HumanEval上达到83.5%，在MBPP上达到63.2%，在DevEval上达到8.09%胜率，在TraceEval上达到15.36 ROUGE-2，性能优于包括27B Gemma-3和32B Granite-4.0在内的10倍规模的前沿模型。

## 1 引言

表1：合成代码数据生成方法比较。CodeAlchemy在所有维度上提供全面覆盖，并支持多种语言。

| 特性 | **CodeAlchemy（本工作）** | Nemotron-Pretraining-Code-v2 | SwallowCode-v2 |
|------|---------------------------|------------------------------|----------------|
| **数据转换策略** |  |  |  |
| 质量增强/重写 | ✓ (15种语言) | ✓ (Python) | ✓ (Python) |
| 基于模板的QA生成 | ✓ (7种语言) | ✓ (11种语言) | ✗ |
| 基于真实项目的开发者任务 | ✓ (15种语言) | ✗ | ✗ |
| 多轮对话 | ✓ (15种语言) | ✓ (Python, C++) | ✗ |
| 代码执行跟踪 | ✓ (14种语言, 1.3M文件) | ✗ | ✗ |
| 跨语言任务 | ✓ (14种语言) | ✓ (仅Python→C++) | ✗ |
| 质量评分过滤 | ✓ (120M文件评分) | ✗ | ✗ |
| **基础设施与评估** |  |  |  |
| 多语言沙盒执行 | ✓ (14种语言, 5.4K库) | ✗ | ✗ |
| 基于难度的过滤 | ✓ | ✗ | ✗ |
| 基于执行的验证 | ✓ (CodeQA, CodeTrace) | ✗ | ✗ |
| 新评估基准 | ✓ (DevEval, TraceEval) | ✗ | ✗ |
| **规模与覆盖范围** |  |  |  |
| 总语言数 | 15 | 11 | 1 |
| Tokens | 500B + 350B 推理 | ∼480B (估计自1918GB数据) | 50B |

用于代码的大型语言模型（LLMs）通过规模化训练公开代码取得了进展(Lozhkov et al., 2024)，但这一范式面临3个限制：(1) 高质量数据稀缺，低质量代码会损害性能(Allal et al., 2025)；(2) 原始代码为多样化的用户交互（调试、重构、解释）提供的信号稀疏；(3) 下一个token预测教授语法而非语义；一个模型预测 `for i in range(n):` 学到的是模式而非执行行为、循环取值或终止条件。

基于LLM的数据重写已被证明对文本模型具有变革性(Maini et al., 2024)。Kimi K2重写低质量文档以提高质量和多样性(Bai et al., 2025)，而Nemotron-CC和Rewire从文档中提取结构化QA对，显著提升了MMLU分数(Su et al., 2024; Nguyen et al., 2025)。尽管取得了这些成功，但**用于预训练的合成代码数据**仍然探索不足。SwallowCode专门关注Python质量增强(Fujii et al., 2025)，而Nemotron-Pretraining-Code-v2在11种语言上提供QA生成，但将质量重写限制在Python，跨语言任务仅限Python→C++(NVIDIA, 2025)（详细比较见表1）。这留下了关键差距：(1) **质量**：大多数代码缺乏测试、文档和错误处理；(2) **格式对齐**：基准测试格式（文档字符串、函数签名、测试用例）在原始代码中代表性不足；(3) **任务多样性**：原始代码未能捕捉真实的开发者工作流或多轮对话；(4) **推理**：复杂的QA实例包含隐式的推理步骤；(5) **语义**：下一个token预测教授语法而非执行语义（控制流、状态跟踪等）。为了解决这些问题，我们提出**CodeAlchemy**，一个多层面流水线，将原始代码转换为多样化、语义丰富的训练数据（图1）。

#### CodeEnhance
公开代码通常包含错误、糟糕的命名，并缺乏测试、文档和错误处理(Fujii et al., 2025)。我们使用LLM对文件进行0-10分的评分，然后选择性地重写低质量代码（≤6），以添加：包含边界情况的单元测试、文档、依赖项的桩模块/模拟、符合风格指南等。无论原始质量如何，质量得分均提升至∼8（第2.1节），产出15种语言共计120B tokens。

#### CodeQA
基准测试使用特定格式（函数签名、文档字符串、测试用例），这些在原始代码中很少见。在文本领域，从文档中提取的QA对进行训练能显著提升MMLU性能(Maini et al., 2024; Su et al., 2024; Nguyen et al., 2025)。为了研究类似模式是否适用于代码，我们手工制作了5种QA模板及参考示例，然后提示LLM根据每个源文件生成符合模板格式、且**灵感来源于**源代码模式的实例。将生成过程扎根于多样化文件自然引入了变化，产出了2200万新颖的QA对。

#### CodeDev
原始代码为真实的开发者请求提供的信号稀疏。我们提示LLM根据每个源文件生成多样化的开发者任务：调试、重构、移植、解释等（表A3）。每个任务均引用**实际的代码元素**，确保具体性，避免纯基于提示的生成带来的人工性。这产出了215B tokens的6200万个提示-响应对（覆盖15种语言），以及68B推理tokens。

#### CodeDialogue
真实的开发者交互需要多轮对话来完善需求、调试问题并探索替代方案。我们将CodeDev扩展到多轮对话中，通过提示LLM生成后续轮次，识别先前回复中的空白、引入约束或自然地推进任务。这产生了多样的交互模式：澄清请求、迭代细化、调试会话、代码审查，共产出150B tokens，包含3100万次对话（平均3.6轮）以及271B推理tokens。

#### CodeTrace
下一个token预测为语义提供的信号稀疏。给定 `x = foo(y)`，模型学到的是语法而非x取何值、哪个分支执行或状态如何演变。公开代码因未解析的导入、缺失依赖和缺乏插桩而无法直接执行。我们构建了执行跟踪基础设施，能够：(1) 在14种语言和5K个库的400万文件上植入插桩，发射结构化的跟踪事件；(2) 生成测试输入；(3) 在隔离容器中执行；(4) 过滤非确定性代码（∼75%）。这产出了130万对（代码，跟踪）数据，捕捉了控制流、状态演变和库行为。关键的是，**前沿模型难以应对**：Claude Sonnet 4.5的行二元组F1仅为30.8%，验证了任务难度。虽然执行跟踪已被用于评估新架构的状态跟踪能力，但先前的工作仅使用玩具语法或简单Python函数(Sun et al., 2025; Ding et al., 2024; Armengol-Estapé et al., 2025)。

#### 新基准
CodeAlchemy框架还揭示了模型评估方面的空白。现有基准衡量的是算法问题求解能力（HumanEval, MBPP, CodeContests），而非模型能否处理开发者针对给定源文件的具体目标，或者能否在脑海中模拟代码运行时的行为。为了针对这些空白，我们引入两个基准测试。**DevEval**包含12种语言的1488个多样化开发者任务（调试、功能扩展、移植等），评估超越孤立函数补全的实际能力。**TraceEval**包含14种语言的1050个执行预测任务，要求模型在脑海中模拟控制流、状态演变和数据转换。这些基准测试挑战了前沿模型：Claude Sonnet 4.5在TraceEval上的准确匹配率仅为5.6%，揭示了语义理解方面的关键差距。我们以Apache 2.0许可证开源CodeAlchemy数据和代码库。本工作使用的所有指令提示均包含在附录C中，示例见附录D。

![图1：CodeAlchemy数据流水线。从多语言种子数据（阶段0）开始，我们通过LLM评分评估代码质量（阶段1），为五种合成方法（阶段2）的采样提供依据：CodeEnhance提升质量，CodeQA使用受基准启发的模板，CodeDev生成开发者任务，CodeDialogue创建多轮开发者-助手对话，CodeTrace从130万次运行中产生执行跟踪。该流水线生成500B tokens加上350B推理tokens，在两个新基准（阶段3）上评估。](caption)

## 2 方法

我们从3个代码语料库（stack-edu, the-stack-v2-train-smol-ids, RefineCode）中构建CodeAlchemy，涵盖15种语言：Java, Python, JavaScript, PHP, C, C++, C#, TypeScript, Shell, Go, Markdown, Ruby, Rust, Swift, SQL(Allal et al., 2025; Lozhkov et al., 2024; Huang et al., 2024)。

### 2.1 增强原始代码质量

#### 质量评分
为了实现定向重写，我们提示 `gpt-oss-20b`¹（推理努力度设为“medium”，除非明确指定为“high”）使用 PromptLABEL:lst:prompt-codeenhance-scoring 对 stack-edu 文件进行0-10分评分(OpenAI, 2025)。为了加速处理，我们按语言（SQL、Markdown除外）均匀采样每语言10K个评分文件，并在 (code, score) 对上微调 SmolLM2-360M 以获得快速质量评分器(Allal et al., 2025)。图A1和表A2显示了 stack-edu 的得分分布：相当一部分文件得分为0，且大多数语言平均分低于5，表明数据远未达到生产质量。我们使用 tree-sitter²来标记语法错误，但与 SwallowCode 和 SeedCoder 不同，我们避免了基于语法的过滤，因为 SQL、C、C++ 和 C# 中假阳性率很高(Fujii et al., 2025; Seed et al., 2025)。

#### CodeEnhance
我们使用 `gpt-oss-20b` 和 PromptLABEL:lst:prompt-codeenhance-rewrite 来增强代码质量，并对 Markdown、SQL、Shell 使用专用提示。由于计算资源限制，我们专注于4-6分档，这些分档具有最高的改进潜力。我们处理了4570万个去重文件，产出112B tokens。为了评估有效性，我们按语言-质量分档均匀采样每档500个文件，并使用 `gpt-oss-120b` 作为评判者，对原始版本和重写版本进行评分。图A2显示，无论原始分数如何，重写都将质量提升至∼8，分数集中在对角线之上。

### 2.2 基于模板的QA生成

原始代码仓库为基准测试格式提供的信号有限。虽然函数可能实现了复杂的算法，但它们很少包含正式的问题陈述、函数签名、文档字符串或测试用例；这导致在原始代码上训练的模型存在格式不匹配。我们手工制作了5种QA模板，灵感来自主要基准测试（基础编程、竞赛编程、函数执行、代码补全、跟踪预测），每种模板包含5-6个参考示例，展示了期望的格式、风格和难度。与纯粹基于提示合成而产生重复问题的做法不同，我们将生成过程扎根于实际源代码。对于每对（源文件，模板），PromptLABEL:lst:prompt-codeqa-samples 生成符合模板格式且从源代码的算法模式中汲取灵感的实例。我们将此流程应用于质量评分≥7的Python文件，使用 `gpt-oss-20b`（high）为每个文件-模板对生成2个实例。对于竞赛编程，我们使用 `gpt-oss-120b`（high），并分开生成问题和解法。每个实例都在沙盒中执行以验证正确性，消除了∼28%的样本。我们将基础编程样本通过每个语言的专用模板翻译到另外6种语言。这产生了 **CodeQA** 数据集：涵盖7种语言、130亿 tokens 的2200万个QA对，具有多样的问题类型和难度，同时保持了基准质量格式。

### 2.3 开发者任务

针对覆盖15种语言的1260万个 stack-edu 源文件，我们生成真实的开发者提示和回复。

**提示生成。** 使用 `gpt-oss-20b` 和 PromptLABEL:lst:prompt-codedev-create-prompts，我们为每个文件生成10-15个多样化的提示。提示要求具体引用代码元素，并针对12个任务类别（代码理解、调试、功能扩展、跨语言等），在7个维度（范围、场景、约束、受众、格式、风格、难度）上保持多样性。

**回复生成。** 每个提示-代码对使用 `gpt-oss-20b` 和 PromptLABEL:lst:prompt-codedev-response 生成回复，指示给出专家级别的回复，产生1.53亿个（提示+代码，回复）对。

**难度演化。** 为了增加复杂度，我们对标记为“Complex”的提示应用 PromptLABEL:lst:prompt-codedev-prompt-evolve，使用4种策略：**突变**（约束叠加、对抗性转折）、**交叉**（将提示融合为工作流）、**混合**（结合两者）和**发明**（生成新提示）。这额外产生了1.12亿个对：总共2.65亿个对，涵盖685B tokens和230B推理tokens。

**质量过滤。** 为了保持平均数据质量高，我们使用 `gpt-oss-20b`（high）和 PromptLABEL:lst:prompt-codedev-prompt-scoring 对提示进行三个0-9分量表（有效性、难度、训练价值）评分，保留有效性≥8且（训练价值≥8或（训练价值==7且难度≥7））的提示。**CodeDev** 数据集包含6200万个对，涵盖207B tokens和68B推理tokens。

### 2.4 开发者-助手对话

真实的开发者交互需要多轮对话来完善需求和调试问题。我们将 CodeDev 对（难度≥7）使用 `gpt-oss-20b`（high）扩展到多轮对话中。从 CodeDev 对作为初始交流开始，我们迭代生成对话轮次。对于每个对话历史，PromptLABEL:lst:prompt-codedialogue-user 通过识别空白或...