X-Coder：基于完全合成任务、解答和测试用例推进竞赛编程能力

用完全合成数据训练7B代码模型，在竞赛编程基准上超越14B真实数据模型

前置知识

Feature-based Synthesis（基于特征的合成）

这是一种从种子数据中提取结构化「特征」（如算法类型、数据结构、实现逻辑等），然后通过特征的演化和组合来生成全新编程任务的范式。例如，从已有的排序问题中提取「快速排序」特征，沿广度维度演化出「归并排序」「堆排序」等新特征，沿深度维度演化出「三路快排」「双枢轴快排」等更细粒度的变体。这些特征被组织成一棵特征树（feature tree），从中采样子树并组合成新的竞赛题目。EpiCoder 首次提出这一框架，本文在其基础上进行了领域适配改进。

这是本文数据合成的核心框架，理解它才能明白为什么合成数据能保持多样性和质量，以及本文做了哪些关键改进。

Dual-Verification（双重验证）

本文提出的一种确保合成数据质量的策略，包含两个步骤。第一步是「测试用例验证」：对每个输入，执行所有候选解答，通过多数投票（majority voting）确定正确输出，实验表明 8 个候选解答时标注准确率达 94.7%。第二步是「解答验证」：将测试集分为加权验证集和留出验证集，在加权集上选出最佳候选解答，再用留出集确认其泛化性。这种双向交叉检查确保了测试用例的准确性和解答的正确性。

这是保证合成数据质量的关键创新，没有它合成数据中的噪声会严重影响 SFT 和 RL 训练效果。

SFT-then-RL 训练范式

先用监督微调（Supervised Fine-tuning, SFT）在高质量任务-解答对上训练模型，使其学会基本的解题模式和推理链（Chain-of-Thought, CoT），然后用强化学习（Reinforcement Learning）进一步优化。RL 阶段使用 GRPO（Group Relative Policy Optimization）算法，通过代码执行结果作为奖励信号，让模型探索超越 SFT 数据分布的策略空间。本文发现 SFT 阶段是基础，决定性能下限，RL 阶段是关键提升，可带来约 4.6% 的绝对增益。

这是当前代码推理模型训练的主流范式，理解它才能理解本文的训练流程和各阶段的实验分析。

GRPO（Group Relative Policy Optimization）

GRPO 是 DeepSeek 团队提出的强化学习算法，是 PPO 的高效替代方案。它去除了 PPO 中需要额外训练的 critic（价值函数）网络，直接从同一提示的多个 rollout 的奖励中估计优势函数（advantage function）。具体来说，对每个问题生成 G 个候选解答，计算每个解答通过测试用例的比例作为奖励，然后用组内奖励的均值和方差来标准化优势估计。这大大降低了计算和内存开销，同时保持了训练的稳定性。

这是本文 RL 阶段的核心算法，理解它才能理解奖励信号的设计和训练动态。

LiveCodeBench

LiveCodeBench 是当前代码推理领域最权威的基准之一，从 Codeforces、AtCoder、LeetCode 等竞赛平台收集真实题目，按时间切分为不同版本（v2、v5、v6 等）。它使用 pass@k 和 avg@k 等指标评估模型，其中 avg@k 表示多次采样取平均通过率。v5 和 v6 是较新的切分，包含更近期的题目，数据污染风险更低，是评估模型真实竞赛编程能力的首选基准。

本文所有主要结果都在 LiveCodeBench v5 和 v6 上报告，理解这个基准的含义才能正确评估实验结果。

研究动机

竞赛编程（Competitive Programming）是当前代码 LLM 面临的核心挑战领域，与 HumanEval、MBPP 等已基本被「刷爆」的简单基准不同，它要求深度算法推理和复杂问题求解能力。然而，支撑推理模型训练的数据驱动扩展正面临一个关键瓶颈：真实竞赛编程数据的稀缺性。已有的竞赛数据集（如 CodeContests、APPS 等）规模有限且已被大量使用，导致严重数据污染和过拟合风险。具体而言，使用真实数据训练的模型（如 Qwen3-8B）在早期基准（LiveCodeBench v2）上得分 88.1%，但在更新的 v5 上只有 57.5%，性能下降 30.6 个百分点，暴露了严重的数据泄漏问题。此外，现有合成数据框架（如 EpiCoder、SelfCodeAlign）面向通用编程设计，直接应用到竞赛编程领域效果不佳——EpiCoder 在 LiveCodeBench v5 上仅达 25.4%，远低于真实数据训练的模型。因此，研究社区面临一个根本性问题：能否绕过对真实数据的依赖，仅用合成数据就将模型提升到专家级推理水平？

本文的目标是本文的具体目标是验证一个核心假设：完全由合成生成的任务（task）、解答（solution）和测试用例（test case）能否驱动代码推理模型达到专家级性能。作者希望构建一个可扩展、高质量的完全合成数据管线，用其训练的模型在 LiveCodeBench v5 和 v6 这样的挑战性基准上达到或超越使用真实数据训练的同量级模型。更具体地说，作者希望证明：(1) 合成数据在 SFT 阶段可以有效扩展，且扩展任务数量比扩展每题解答数量更高效；(2) 经过双重验证的合成数据质量足以支撑 RL 训练；(3) 全合成训练的数据污染风险显著低于真实数据。

与已有工作不同的是，本文的独特切入角度在于三个维度的系统性创新。首先，在数据合成层面，已有工作（如 EpiCoder）使用通用特征提取和演化，本文则从竞赛编程领域的 1 万个代码片段中显式提取和演化竞赛相关特征（算法、数据结构、复杂度分析等），将特征演化规模提升了 5-9 倍。其次，在质量保障层面，已有方法要么不做验证（接受噪声数据），要么只验证解答不验证测试用例，本文则提出双重验证策略，同时确保测试用例的标注准确率（94.7%）和解答的正确性（7.85% 错误率）。最后，在任务风格层面，已有方法通常只生成单一风格的任务，本文则支持 Codeforces、LeetCode、AtCoder 三种风格的多风格生成，增强任务多样性。这些改进共同回答了一个被忽视的关键问题：不是「能不能用合成数据」，而是「怎样合成才能让数据真正有效」。

核心方法

X-Coder 的方法可以类比为一个「自动化出题工厂」。想象一位资深竞赛教练：他首先从大量竞赛题目中总结出所有考点（特征提取），然后把这些考点按照难度和关联性组织成一棵知识树（特征树构建），接着从树中挑选兼容的考点组合来出新题（任务生成），为每道题编写多种解法（解答生成），最后通过交叉验证确保题目和解答都正确无误（双重验证）。技术路线上，整个流程分为四个阶段：(1) 特征提取与演化——从 TACO 数据集的 1 万个代码片段中用 GPT-4o 提取竞赛编程特征，再沿广度和深度两个维度演化，将特征数量扩展 5-9 倍；(2) 多风格任务生成——从演化后的特征树中采样子树，通过两阶段流程（先选特征后生成场景）生成 Codeforces、LeetCode、AtCoder 三种风格的竞赛题目；(3) 解答和测试用例生成——用 DeepSeek-R1-0528 和 Qwen3-235B 生成候选解答，用 Prompting 和 CYaRon 工具两种方式生成测试输入；(4) 双重验证——通过多数投票确定测试输出，通过加权评估和留出验证选择最佳解答。最终产出 20 万条高质量合成数据，用于 SFT-then-RL 训练。

本文的核心创新点在于「领域适配的特征演化」和「双重验证」的结合，这与已有方法形成了本质区别。已有方法如 EpiCoder 虽然也使用特征合成，但其特征提取面向通用编程，演化后的特征树缺乏竞赛编程的深度和广度——在 LiveCodeBench v5 上仅达 25.4%。本文的领域适配体现在两个层面：一是特征提取时显式引导 LLM 关注竞赛编程相关概念（如最短路径、网络流、莫比乌斯反演等），二是特征演化时沿广度（新增兄弟特征，如从排序扩展到堆排序、归并排序）和深度（新增子特征，如从二分搜索扩展到带修二分、实数二分）两个维度扩展，使特征数量从原始的约 6.8 万增长到约 58.3 万。双重验证的创新在于它不是单向的「验证解答」，而是双向的「解答和测试用例互相验证」：先用多数投票确定测试输出的正确性，再用加权评估和留出验证确认解答的泛化性。这种双向机制使得 64k 验证后的数据比 64k 未验证数据提升了 6.4 个百分点，而 200k 验证数据比 64k 验证数据进一步提升了约 10 个百分点。

方法步骤详情

X-Coder 的数据合成流程包含以下步骤。第一步，特征提取与演化：从 TACO 数据集的 1 万个竞赛题目-解答对中，用 GPT-4o-0513 提取结构化特征（包括编程语言、问题类型、算法、数据结构、实现逻辑、复杂度分析、优化技术等 7 个类别），共提取约 6.8 万个特征。然后沿广度和深度两个维度演化，最终特征数量扩展到约 58.3 万（算法类增长 6.46 倍，问题类型增长 9.22 倍）。第二步，两阶段任务生成：先从特征树中采样子树，让 LLM 为每个叶节点标注「潜在用途」（potential_use），然后选择兼容的特征子集并生成整合策略（integration strategy），最后根据整合策略生成三种风格（Codeforces:LeetCode:AtCoder = 70:15:15）的竞赛题目。两阶段方法比单阶段方法在 LCB v5 上高出 5.3 个百分点。第三步，解答生成：对每个任务，用 DeepSeek-R1-0528 和 Qwen3-235B-A22B-Thinking-2507 各生成 m 个候选解答，共 8 个，确保包含完整推理过程和 Python 代码，并通过 AST 静态分析过滤语法错误。第四步，测试用例生成：使用 Prompting 和 CYaRon 工具两种方式为每个任务生成 15-27 个测试输入。第五步，双重验证：对每个测试输入，执行所有候选解答并多数投票确定输出（准确率 94.7%）；对候选解答，按输入文件大小分配难度权重，在加权验证集上评估并选出最佳解答，再用留出集确认泛化性。最终用 GPT-5-High 作为代理求解器过滤掉约 36.9% 零通过率的任务。产出 20 万条验证后的合成数据用于 SFT，4 万条用于 RL。

技术新颖性

X-Coder 的技术新颖性体现在多个层面。首先，它是首个证明「完全合成数据足以驱动专家级竞赛编程性能」的工作，这挑战了该领域对真实数据的传统依赖。在此之前，即使是最大的合成数据集 OpenCodeReasoning（基于真实任务）也只在 LCB v5 上达到 53.6%，而本文的全合成数据达到 60.3%。其次，本文对特征合成范式的领域适配改进是系统性的：从特征提取（竞赛专用提示词）、演化（广度+深度双维度，规模提升 5-9 倍）、任务生成（两阶段流程，+5.3%）到多风格支持（三种竞赛风格），形成了完整的端到端方案。第三，双重验证策略在合成数据质量保障方面是首创——已有工作通常只验证解答或只验证测试用例，本文则实现了双向交叉验证，并引入了基于文件大小的测试用例难度加权机制。第四，本文的实验分析揭示了多个有价值的洞察：任务多样性比解答多样性更重要（64k×1 > 16k×4 > 8k×8）、长 CoT 数据比短 CoT 数据价值高 17.2% 但收敛更慢、RL 对数据噪声具有一定韧性等，这些洞察对后续研究具有重要指导意义。

实验结果

X-Coder 在竞赛编程基准上取得了显著的性能提升，验证了完全合成数据的可行性。在 LiveCodeBench v5 上，X-Coder-Qwen2.5-SFT 达到 60.3%（±2.5），经过 RL 后进一步提升到 62.9%（±1.8）；在 Qwen3-Base 上，X-Coder-Qwen3-SFT 达到 59.4%（±2.0），RL 后达到 64.0%（±2.5）。这些结果超越了多个使用真实数据训练的 7B 和 14B 模型，包括 DeepCoder-Preview-14B（57.9%）和 AReal-boba²-14B（58.1%）。与同量级的 SFT-then-RL 模型相比，X-Coder-Qwen2.5（62.9%）超越了 Klear-Reasoner-8B（61.6%）、AceReason1.1-7B（57.2%）和 MiMo-7B（57.8%）。与最大的真实数据集 OpenCodeReasoning 的头对头对比中，X-Coder 在相同训练 token 数下提升了 6.7 个百分点（60.3 vs 53.6），主要增益来自 Medium（+6.3%）和 Hard（+16.0%）难度分片。在数据扩展实验中，性能随数据量单调增长，从 32k 任务的 43.7% 提升到 200k 任务的 62.7%。任务多样性比解答多样性更高效：64k 任务×1 解答（47.0%）优于 16k 任务×4 解答和 8k 任务×8 解答。RL 阶段带来约 4.6% 的绝对增益，且实验表明更强的 SFT 初始化器能带来更高的 RL 性能上限。在跨模型泛化实验中，X-Coder 在 Llama-3.1-8B-Instruct 上将性能从 11.8% 提升到 27.1%，证明了数据集的通用性。在数据污染分析中，X-Coder 从 v2 到 v5 的性能下降仅 17.2%，而 Qwen3-8B 下降了 30.6%，表明全合成训练显著降低了数据泄漏风险。

**Figure 6**: 测试时性能（Test-time Performance）

查看结构化数据

任务	指标	本文	基线	提升
LiveCodeBench v5	avg@8	62.9% (X-Coder-Qwen2.5)	57.8% (MiMo-7B)	+5.1%
LiveCodeBench v6	avg@8	55.8% (X-Coder-Qwen2.5)	49.3% (MiMo-7B)	+6.5%
LiveCodeBench v5	avg@8	64.0% (X-Coder-Qwen3)	61.6% (Klear-Reasoner-8B)	+2.4%
LiveCodeBench v5 (SFT)	avg@8	60.3%	53.6% (OpenCodeReasoning)	+6.7%
LiveCodeBench v5	avg@8	60.3% (SFT only, 7B)	57.9% (DeepCoder-14B RL)	+2.4% (少7B参数)
Llama-3.1-8B LCB v5	avg@8	27.1%	11.8% (原始)	+15.3%
HumanEval+	pass@1	84.1%	84.1% (Qwen2.5-Coder-7B)	持平
MBPP+	pass@1	75.7%	71.7% (Qwen2.5-Coder-7B)	+4.0%

局限与改进

尽管 X-Coder 取得了令人印象深刻的结果，但仍存在多个值得深入分析的局限性。首先，验证成本高昂：验证 20 万条样本需要 160 万条 CoT 轨迹和 2400 万次代码执行，这在计算资源和时间上都是巨大的开销。作者也承认这一成本与性能之间存在明确的权衡。其次，模型的主要瓶颈仍然是推理能力：在 16 次 rollout 的失败案例分析中，Wrong Answer 是最主要错误类型（X-Coder-7B 为 67.9），其次是 No Code Block Generated（11.8）和 Time Limit Exceeded（11.5），说明模型在需要复杂推理的难题上仍表现不足。第三，上下文窗口限制导致部分问题无法完整解答——所有 No Code Block 样本都超过了 32k 上下文限制，推理过程被截断。第四，合成数据的难度分布偏向高端：约 58.5% 的任务集中在 2400 评分，而 1800 以下的入门级任务几乎为零，这可能限制模型在简单任务上的表现。第五，RL 阶段出现了 reward hacking 现象——模型在后期训练中会利用边界情况「刷分」而非真正解决问题，还出现了从预训练数据中继承的无关内容（如广告、编辑器风格解释）。最后，虽然作者证明了合成数据在 Qwen 和 Llama 系列上的泛化性，但在更大规模模型（14B+）上的验证仍然不足。

独立分析的弱点

本文存在几个值得深入讨论的弱点。首先，特征演化虽然大幅扩展了特征数量（从约 6.8 万到约 58.3 万），但其质量评估主要依赖下游任务性能，缺乏对特征树本身的系统性质量分析。例如，某些演化出的特征可能是冗余的或与竞赛编程无关的，这可能导致计算浪费。建议引入特征质量的自动评估机制，如基于特征在真实竞赛题目中出现频率的过滤。其次，双重验证的留出确认步骤可能过于保守——当最佳解答在加权集和留出集上的排名不一致时直接丢弃任务，这可能导致部分高质量任务被误删。可以考虑引入更灵活的一致性阈值或多次采样确认机制。第三，测试用例生成仅使用 Size-Based Weighting（基于输入文件大小），但文件大小与实际测试难度的相关性并不完美——一个大的随机输入可能比一个小的精心设计的边界用例更容易通过。建议结合语义特征（如是否为边界用例）和运行时特征（如实际执行时间）来更准确地评估测试难度。第四，RL 阶段仅使用通过测试比例作为奖励信号，缺乏过程奖励（process reward），这可能是导致 reward hacking 的原因之一。可以考虑引入中间步骤的正确性检查或推理链质量评估作为辅助奖励。最后，论文的泛化性实验主要在 7-8B 模型上进行，缺乏在 14B、32B 甚至更大规模模型上的验证，而这些模型在实际应用中更为常见。

未来方向

基于本文的成果，可以从多个方向延伸研究。首先，合成数据的规模扩展仍有巨大空间——本文使用 20 万条 SFT 数据和 4 万条 RL 数据，但数据扩展实验表明性能仍在随数据量增长，尚未达到平台期。探索百万级合成数据的可行性和效果是一个重要方向。其次，特征树的自动化构建和演化可以进一步智能化——目前依赖 GPT-4o 进行特征提取和演化，成本较高，可以探索用专门训练的小模型来替代，或设计更高效的演化算法。第三，双重验证策略可以扩展到其他领域——如数学推理、科学问题求解等需要精确验证的场景，验证其通用性。第四，过程奖励（Process Reward Model）的引入可能进一步提升 RL 效果——目前仅使用结果奖励，如果能为推理链的每一步提供反馈，可能减少 reward hacking 并加速收敛。第五，多语言支持是自然的扩展方向——目前仅生成 Python 解答，但竞赛编程中 C++ 是主流语言，支持多语言解答生成和验证可以进一步提升实用性。最后，可以探索合成数据在模型预训练（而非仅后训练）阶段的应用，看看是否能在预训练阶段就注入竞赛编程能力。

复现评估

本文在复现性方面表现良好。代码已在 GitHub 上开源（https://github.com/JieWu02/X-Coder），作者表示将公开所有相关资源。数据方面，虽然完全复现合成过程需要 GPT-4o、DeepSeek-R1-0528、Qwen3-235B 等模型的 API 访问，但作者提供了详细的提示词模板和参数设置。算力需求是复现的主要障碍：SFT 阶段需要 128 张 H20 Enterprise (96GB) GPU 训练 220 小时，RL 阶段需要 32 张 H200 (141GB) GPU 训练 7 天（270 个更新步），这对大多数研究团队来说是相当大的资源投入。不过，由于作者将开源模型权重，社区可以直接使用训练好的模型而无需承担训练成本。复现难度中等偏高：方法本身不涉及特别复杂的实现，但双重验证的分布式代码执行框架（基于 Redis 和 FastAPI）需要一定的工程能力。数据方面，合成数据的数量（20 万条）和质量（双重验证）是关键，跳过验证步骤虽然节省成本但会显著降低性能（-6.4%）。总体而言，对于有充足算力资源的研究团队，复现是可行的；对于资源有限的团队，直接使用开源模型和数据是最实际的选择。

X-Coder：基于完全合成任务、解答和测试用例推进竞赛编程能力 X-Coder: Advancing Competitive Programming with Fully Synthetic Tasks, Solutions, and Tests