大模型竞赛编程金牌之路：Post-Training核心原理与实战

很多做 LLM 应用的人都有过这样的疑惑大模型写普通业务代码已经很顺了但交给它一道 Codeforces Div.1 的困难题它往往输出一段逻辑上“看着合理”、却根本跑不通的代码。而最近一段时间一个研究方向在竞赛圈和 AI 圈同时被频繁提起——Post-Training Language Models for Gold-Medal Performance in Coding Competitions它讨论的正是如何把通用大模型改造成能在真实编程竞赛中拿金牌的选手。这类工作的核心结论可以浓缩成一句话决定竞技编程水平上限的已经不是预训练阶段塞进多少代码而是后训练阶段怎么教模型推理、怎么用执行反馈修正错误。换句话说基座模型就像一个有天赋但没受过系统训练的学生知识储备够了缺的是做题方法论和考场策略。Post-Training 要补的正是这两块。这篇文章会从四个层面拆解这个方向先说明为什么竞赛级代码生成和日常代码生成本质上是两回事再梳理 Post-Training 的核心原理包括 SFT、RLHF、RLVR 的区别与联系然后给出一套可落地的实验流程包括数据准备、训练配置、奖励函数、推理采样和评测脚本最后聊一聊这类方法在生产实践中的坑、边界和后续值得深入的方向。1. 为什么“会做题”和“会竞赛”是两回事如果只看表面大模型写代码这件事已经被解决得差不多了给它一个需求描述它能生成几十行的函数、补齐单元测试、甚至重构整个模块。但编程竞赛完全不是这么回事。竞赛题有几个典型特征放大了大模型的短板。第一个特征是多步骤推理。一道 Codeforces 的 C 题或 D 题往往需要先做数学建模再推导贪心策略或动态规划状态最后才落实到代码。自回归模型在生成过程中非常容易“先入为主”一旦中间某一步推理偏了后面的代码即使语法完全正确最终答案也是错的。这种错误不像业务代码那样容易通过编译错误暴露而是逻辑上的隐性错误非常难排查。第二个特征是程序正确性由执行结果决定。日常开发中代码能跑、能覆盖主要路径基本就满足了需求。竞赛评测则完全不同模型生成的代码必须通过全部隐藏测试用例边界条件、时间复杂度、内存占用全部被严格约束。这要求模型不仅要“写得出代码”还要“一次写对”并且要“在约束内写对”。第三个特征是问题难度跨度大。入门题和金牌题之间的差距不是数据量能简单拉平的。金牌选手面对一道新题时会主动尝试多种思路、构造反例、检验复杂度然后才开始写代码。这种“解题策略”层面的能力预训练阶段很难从语料中自然涌现必须通过后训练显式地教会模型。这也是为什么“Post-Training Language Models for Gold-Medal Performance in Coding Competitions”这个方向在 2024 年以后迅速升温。它背后的工业价值和学术价值都很直接如果大模型能在竞赛中达到金牌水平意味着它在“长链条推理”和“精确生成”两件事上都有了质的突破这会直接迁移到复杂工程代码、算法设计、自动化测试生成等真实场景。所以读这篇文章时建议你先建立一个判断竞赛级代码生成不是预训练问题的延伸而是一个典型的“后训练目标优化”问题。理解了这一点后面的技术路线才有意义。2. Post-Training 到底在训练什么Post-Training 不是一个新词但很多人把它和微调混为一谈。严格来说预训练得到一个通用的基座模型之后所有为了让模型更好地适配特定任务而进行的继续训练都可以叫 Post-Training。它包含但不限于指令微调SFT、人类反馈对齐RLHF、基于规则的强化学习RLVR、知识编辑、以及持续预训练。它们的核心差异在于“训练目标和数据形态”。下面用一个表格直观对比训练阶段训练目标数据形态适用任务预训练预测下一个 Token海量文本通用语言建模指令微调 SFT模仿标准答案指令-回答样本对话、通用任务RLHF符合人类偏好模型输出 人工排序对齐、安全性RLVR最大化规则奖励模型输出 自动打分代码、数学、竞赛表格里的 RLVR 是这类竞赛模型方法中最关键的一环。VR 是 Verifiable Rewards 的缩写意思是“可验证的奖励”。代码任务天然适合 RLVR因为一段代码对不对不需要人来判断直接丢到编译器或评测器里跑测试用例通过率就是最客观的奖励信号。这也是 Post-Training 在编码竞赛领域比通用 RLHF 更有效的原因。RLHF 需要人工标注偏好成本高、噪声大而且人类偏好不等于代码正确性。RLVR 则把正确性判断交给机器奖励信号密度高、反馈快、可大规模并行。竞赛题目的评测标准是明确的正好是最理想的 RLVR 应用场景。不过这里要澄清一个容易误解的点Post-Training 并不是把模型“调成只会做竞赛题的专用工具”。更好的理解是通过后训练模型在原有语言能力之上增加了一层“竞赛级推理和验证”的能力。它依然能写业务代码只是在面对复杂算法问题时有了更强的解题策略和错误修正能力。3. 从研究方法看金牌水平的实现路线基于目前这类工作的公开思路要让一个基座模型达到金牌水平通常不是一步到位的而是分阶段组合出来的。这里给出一个经过实践检验的总体路线后面章节会给出对应的代码示例。3.1 阶段一高质量竞赛数据 SFT第一步是收集大量“问题-解法-代码”的样本对让模型先学会竞赛题的标准解答模式。这一步的关键不是数据量而是数据质量。如果直接把 Codeforces 上所有提交记录拿来做 SFT模型会学到大量错误或低效的写法。推荐的做法是筛选高通过率选手的代码最好标注了解题思路。每道题保留多种不同解法的样本避免模型只记住单一套路。数据必须覆盖不同难度和不同算法标签保证泛化能力。SFT 之后模型已经能够生成“看起来正确”的竞赛代码但它没有能力判断自己写得好不好也不会在出错后主动修正。接下来需要强化学习阶段。3.2 阶段二基于代码执行的 RLVR这一阶段的核心是让模型在生成代码后通过执行结果获得奖励信号。具体来说模型根据题目描述生成一段代码。将代码在本地评测器上运行得到一组测试用例的通过情况。通过率作为奖励通过策略梯度更新模型参数。用代码执行结果作为奖励比让模型自评要可靠得多。模型很快会学会代码要能编译过、要能处理边界条件、要能在限定时间内跑完。这些能力很难通过文本描述教给模型但强化学习可以在大量交互中自动发现。3.3 阶段三推理时扩展与自我修正即使经过 SFT 和 RLVR单次生成的正确率也未必足够金牌。竞赛选手在真实比赛中也不会只写一版代码就交而是会反复验证和修改。对应到模型推理阶段就是 test-time compute 的扩展。常见做法包括多次采样为同一道题生成 K 份候选代码逐个评测。执行反馈修正把错误输出反馈给模型让它分析失败原因并重写。生成-验证循环模型先想解法再写代码再构造边界测试最后提交。这类方法不需要改动模型权重只改变推理策略是“性价比”很高的性能提升手段。金牌级表现往往是“训练阶段强化学会做题 推理阶段学会验题”两者叠加的结果。4. 环境准备与实验资源参考读到这里你可能会想这套流程到底需要什么实验环境下面给出一个相对完整的参考清单。具体版本请以实际项目为准这里重点讲通用思路。4.1 软件环境操作系统Linux 为佳推荐 Ubuntu 22.04 及以上。Python 版本3.10 或更高。深度学习框架PyTorch 2.x。大模型训练工具Hugging Face Transformers、TRL、DeepSpeed 或 ZeRO。推理加速vLLM 或 TensorRT-LLM用于高吞吐采样。代码评测器本地可以基于 Python 的subprocess实现一个轻量判题机生产环境建议对接竞赛平台提供的评测接口。4.2 数据与评测环境训练数据Codeforces、AtCoder、USACO 等竞赛题目的题目描述、标准解法和参考代码。评测数据建议额外保留一套模型未见过的新题用于验证真实泛化能力。本地判题器至少支持编译执行 C、Python 等主流语言并且能设置时间和内存限制。4.3 硬件资源这类实验和普通微调不一样需要做大量采样和代码执行因此对算力和并行调度有较高要求。从公开项目的一般配置来看训练阶段通常需要多卡 GPU 集群建议至少具备 8 张以上高端显卡的节点推理阶段可以采用 vLLM 部署降低采样成本。如果资源有限可以先在小规模模型和少量题目上验证流程再把规模放大。这里特别提醒一点代码执行有安全风险。训练过程中会执行模型生成的代码必须在沙箱环境或容器中运行避免恶意代码影响宿主机器。5. 核心流程示例从基座模型到竞赛模型这一节我们用一个最小可运行的示例把 SFT、RLVR、推理采样三个环节串起来。示例的目标不是复现金牌模型而是帮助你把整个技术路线跑通。5.1 构造 SFT 训练样本先准备一个标准格式的数据集文件。每条样本包含题目描述、解析思路、参考代码。格式如下。{ problem_id: CF_1850E, problem_statement: 给定一个长度为 n 的数组 a每次操作可以选择一个下标 i 并令 a[i] 增加 2求使所有数相等的最小操作次数。, reasoning: 设最终所有数变为 x。每个位置需要的操作次数为 (x - a[i]) / 2所以总操作次数是所有 (x - a[i]) / 2 的和。问题转化为选择一个 x 使这个和最小。由于操作次数必须是整数x 的奇偶性必须和 a[i] 一致因此先对 a[i] 做奇偶修正。, solution_code: def solve():\n n int(input())\n a list(map(int, input().split()))\n max_a max(a)\n total 0\n for x in a:\n if (max_a - x) % 2 1:\n total (max_a 1 - x) // 2\n else:\n total (max_a - x) // 2\n print(total)\n\nif __name__ __main__:\n solve() }SFT 数据的关键是reasoning字段。它不只是解法描述更是一种“解题策略”的展示从问题建模到边界处理再到复杂度分析。训练时模型需要学习在写代码之前先输出一段推理过程再生成最终答案。5.2 使用 TRL 配置 SFT 训练下面是一个基于 Hugging Face TRL 的 SFT 训练配置示例。这个文件放在项目根目录命名为sft_config.yaml。model_name_or_path: Qwen/Qwen2.5-Coder-7B dataset_name: ./data/sft_dataset.jsonl output_dir: ./checkpoints/sft_ckpt num_train_epochs: 3 per_device_train_batch_size: 4 gradient_accumulation_steps: 8 learning_rate: 2.0e-5 lr_scheduler_type: cosine warmup_ratio: 0.1 bf16: true max_seq_length: 4096 packing: false对应的启动命令如下。accelerate launch \ --num_processes 8 \ train_sft.py \ --config sft_config.yaml这里没有给出train_sft.py的完整代码因为 TRL 本身提供了标准入口。实际项目里你只需要在加载数据集后把字段映射到prompt和completion即可。需要注意max_seq_length不能设置太小否则长题面和长代码会被截断影响训练质量。5.3 RLVR 奖励函数实现RLVR 阶段的核心是一个奖励函数。对于竞赛代码奖励函数需要做三件事编译检查、测试用例执行、结果打分。import subprocess import tempfile import os def run_code(code: str, test_input: str, timeout: int 5) - dict: 在沙箱中执行模型生成的 Python 代码并返回执行结果。 with tempfile.TemporaryDirectory() as tmp_dir: code_path os.path.join(tmp_dir, solution.py) with open(code_path, w, encodingutf-8) as f: f.write(code) try: proc subprocess.run( [python3, code_path], inputtest_input, capture_outputTrue, textTrue, timeouttimeout, cwdtmp_dir, ) except subprocess.TimeoutExpired: return {status: timeout, output: } if proc.returncode ! 0: return {status: runtime_error, output: proc.stderr} return {status: ok, output: proc.stdout} def code_reward(code: str, test_cases: list[tuple[str, str]]) - float: 根据测试用例通过率计算奖励值。 test_cases 的元素是 (input, expected_output) 的元组。 passed 0 for test_input, expected_output in test_cases: result run_code(code, test_input) if result[status] ok and result[output].strip() expected_output.strip(): passed 1 return passed / len(test_cases)在实际 RLVR 训练中奖励函数会被高频调用因此性能很关键。建议先把所有测试用例缓存到内存并启用多进程并发执行避免subprocess创建进程的开销拖慢训练。上面的代码只演示核心逻辑生产环境还需要加入资源限制、白名单等安全措施。5.4 推理时多次采样与执行反馈RLVR 训练好之后模型已经具备了一定的竞赛水平。但实际推理时单次生成仍然可能因为某一步推理失误而失败。这时候可以用多次采样加执行反馈来提升正确率。from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) def generate_solutions(prompt: str, model: str qwen-coder-rl, n: int 8) - list[str]: 从同一个 prompt 生成 n 份候选代码。 response client.chat.completions.create( modelmodel, messages[ {role: system, content: 你是一名编程竞赛选手请先分析题目再给出通过全部测试用例的代码。}, {role: user, content: prompt}, ], temperature0.7, nn, max_tokens2048, ) return [choice.message.content for choice in response.choices] def select_best_solution(candidates: list[str], test_cases: list[tuple[str, str]]) - str: 从多个候选中选出通过测试用例数最多的代码。 best_code candidates[0] best_score -1.0 for code in candidates: score code_reward(code, test_cases) if score best_score: best_score score best_code code return best_code这里的code_reward复用了上一步的奖励函数。区别在于训练阶段奖励函数用于引导参数更新推理阶段则用于选择最终答案。这个思路可以进一步扩展成“生成-评测-反馈-重写”的循环第一次生成的代码如果没通过全部用例就把错误信息拼接回 prompt让模型针对失败用例重新分析并修改。5.5 评测脚本训练和推理完成后需要在一批未见过的题目上做最终评测。下面是一个轻量评测脚本的骨架。python eval_competition.py \ --model ./checkpoints/rlvr_ckpt \ --data ./data/test_contest.jsonl \ --language python \ --timeout 5 \ --output ./results/eval_result.json评测脚本的核心职责包括从测试集中读入题目描述和隐藏测试用例。调用模型生成代码。在沙箱中执行并统计通过率。按题目难度和算法标签分组输出结果。要注意评测集必须和训练集严格隔离。如果评测题在训练过程中出现过指标会虚高无法反映真实泛化能力。6. 运行结果与效果验证任何后训练实验都不能只看“Loss 降了”就认为成功。竞赛场景下建议从以下四个维度判断模型是否真正变强了。6.1 通过率指标最基础的指标是passk。pass1表示单次生成的正确率pass8表示生成 8 份候选中至少有一份正确的比例。对于一个竞赛级模型pass1更接近真实比赛场景因为比赛提交次数有限passk则更适合衡量模型能力的上限。如果 SFT 后pass1有明显提升说明模型学到了标准解法如果 RLVR 后pass1再次提升说明执行反馈强化了模型对正确性的感知。这两个阶段的提升幅度直接验证了 Post-Training 各环节的有效性。6.2 难度梯度分析只看平均通过率不够还需要按题目难度分组。一个理想的竞赛模型在简单题上的通过率应该接近 90%中等题在 60% 以上困难题可能只有 20% 到 30%。如果困难题通过率为 0说明模型的策略只覆盖了套路题没有真正学会复杂推理。建议在评测结果里输出如下分组统计难度题目数量pass1pass8平均运行时间Div.2 A/B500.880.961.2sDiv.2 C/D500.610.782.4sDiv.1 E/F300.240.414.6s这个表格是示意数据实际结果以你的实验为准。重点在于如果中等题和困难题差距过大说明模型的“上限”还不够高应该优先改进推理时的自我修正策略而不是继续堆训练数据。6.3 错误类型消融运行失败时第一步要分清错误类型。编译错误、运行时错误、超时、答案错误这四类问题对应的优化手段完全不同编译错误多半是模型对语言语法的掌握不够可以增加目标语言的 SFT 样本。运行时错误通常是边界条件处理不当比如数组越界、除零、空输入。超时算法复杂度太高需要模型学会估算时间复杂度。答案错误推理逻辑偏了需要强化学习阶段更多的负反馈。在评测脚本中显式记录错误类型比只看“对错”更有诊断价值。6.4 与基线模型对比每次实验都要保留一个未经过后训练的基座模型作为基线。对比时建议同时报告基座模型的pass1。SFT 后的pass1。RLVR 后的pass1。加入推理时采样和多轮修正后的pass1。通过这条递进链路你能清晰看到每个阶段贡献了多少提升。如果某个阶段提升微弱就要回头检查数据质量、奖励设计或采样策略。7. 常见问题与排查思路实战中最怕的不是模型能力不够而是训练流程出了问题却不自知。下面整理了几个高频问题都是这类实验容易踩的坑。问题现象可能原因排查方式解决方案SFT 训练 Loss 正常但 pass1 没有提升数据里有大量低质量或重复题解检查训练数据是否包含多种难度和不同解法的样本清洗数据只保留通过率高且思路清晰的题解RLVR 训练过程中 Reward 不上升奖励信号过于稀疏测试用例太少统计每道题的平均通过率确认测试用例覆盖了边界条件增加更多边界测试用例或先用少量种子数据预热模型只学会“猜输出”而不写算法训练数据里包含大量简单题模型走捷径查看简单题和难题的通过率差异按难度均衡采样加重难题权重推理时多次采样耗时太长采样数量过大或模型推理效率低分析单个请求的平均时延使用 vLLM 批量推理或先采样 4 份再逐步增加评测结果忽高忽低不稳定评测集太小或题目太难方差大检查评测集题目数量分组看置信区间扩大评测集保留至少 100 道不同难度的题目模型在训练过的题上过高新题上拉胯数据泄露或过拟合确认评测集与训练集没有重复题目构建独立评测集定期加入新题这里要特别强调数据泄露问题。竞赛题目的变体非常多有些题改个数据范围或条件就是“新题”但本质解法相同。如果评测集和训练集共享了同一题源指标就会失真。稳妥的做法是在评测集中加入一定比例的最新比赛题目这些题在训练时肯定没有出现过。8. 最佳实践与工程建议Post-Training 一个竞赛级模型不仅仅是调包跑通训练脚本更是一套需要精细管理的工程流程。下面几条建议来自大量类似项目的经验沉淀值得在实际工作中提前规划。8.1 数据质量永远是第一优先级很多团队在复现这类方法时第一反应是“再多收几万道题”。但实际上增加低质量数据只会让模型学到更多错误模式。建议从以下三个维度控制数据质量正确性所有参考代码必须经过本地评测器验证。多样性同一道题尽量保留不同解法的代码避免模型只学一种套路。难度平衡训练集中简单题和困难题的比例要合理简单题过多会导致模型走捷径困难题过多会导致训练不稳定。一个有效的做法是把数据按算法标签分组例如贪心、DP、图论、数论、字符串每组采样固定比例保证模型在每个方向都有足量样本。8.2 奖励函数要防“奖励黑客”RLVR 的一个隐藏风险是模型可能会“钻奖励函数的空子”。比如如果测试用例只覆盖了正常输入模型可能会生成一段直接输出固定答案的代码来碰运气。虽然这种情况下通过率不高但会在训练早期误导策略。要减少这类问题可以在奖励函数中增加如下机制测试用例必须包含边界值、随机大数、构造反例。对编译失败和运行时错误给予明显负分。对超时和内存超限单独扣分。8.3 评测集要独立、定期更新竞赛题目更新很快一个静态评测集很快会被模型“记住”。建议建立动态评测机制每个月更新一次评测集加入最新比赛题目。每次训练前随机抽取一部分未公开题目做 holdout。评测结果要按时间段记录观察模型在新题上的表现变化。8.4 训练过程要可复现、可回滚Post-Training 实验周期长、成本高中途出现一次不收敛可能浪费大量算力。建议从一开始就做好三件事保存每个阶段的 checkpointSFT 和 RLVR 的权重分开管理。记录每次实验的完整配置包括数据版本、代码版本、超参数、随机种子。在 RLVR 训练中开启评估回调每隔固定步数在 holdout 集上跑一次 pass1而不是等训练结束才评估。这样一旦发现指标下降可以快速定位是在哪个阶段出了问题并回滚到上一个稳定版本。8.5 安全与合规边界训练和执行模型生成的代码本质上是一种代码生成加自动执行的场景必须遵守以下安全底线所有代码执行都必须在沙箱或容器内完成禁止以当前用户权限直接运行。训练数据使用竞赛题解时注意其版权和许可协议避免用于商业用途时产生纠纷。使用模型辅助正式竞赛时必须遵守比赛规则不能在禁止 AI 助力的比赛中使用。在工程系统中使用这类模型时要对生成代码进行人工审查不能直接作为生产环境判题或决策的唯一依据。9. 从竞赛到真实工程值得继续深挖的方向竞赛级代码生成模型的真正价值不在于它能在 Codeforces 上拿到多高的分而在于它验证了一套“通过执行反馈优化复杂生成”的方法论。这套方法论还可以延伸到很多方向。第一个方向是复杂工程代码生成评估。竞赛代码有明确对错但工程代码没有单一正确答案。如果把 RLVR 的思路改造为“单元测试通过率 静态检查评分 代码覆盖率的加权奖励”理论上也能用来优化真实项目中的代码生成模型。第二个方向是自动化形式化验证。竞赛模型学会了生成严格满足约束的代码这本质上是一种弱化的形式化能力。未来可以引导模型同时生成代码和证明或者在生成过程中调用验证器检查不变式从而提升代码的安全性。第三个方向是模型可解释性。后训练让模型学会了解题策略但模型内部究竟发生了什么变化目前仍然是个黑盒。类似 ICA Lens 这类可解释性分析思路不重新训练一个语义词典而是直接用统计学方法分离模型内部的计算成分可以用来观察“金牌级推理能力”到底编码在哪些神经元和注意力模式里。这类分析不仅有助于理解模型还能反过来指导后训练数据的构造。如果接下来你想在这个方向继续深入建议按这样的顺序推进先在小规模模型上完整跑通 SFT RLVR 推理扩展把所有代码和评测脚本沉淀下来然后逐步扩大数据规模和模型规模每次只改一个变量确保实验可比较最后把评估体系扩展到真实工程项目中用竞赛训练得到的推理优势解决更复杂的代码生成问题。竞赛是 AI 能力的一个极限测试场景但它的意义从来不只是竞赛本身。希望这篇文章能帮你理解 Post-Training 的价值也给你提供一套可以马上动手实践的路线。建议收藏备用等你真正开始做竞赛模型后训练时大概率会用到这里面的代码和排查思路。