18.5 大规模 RL 数据工程
单机实验时，训练数据可以是一段脚本、一个 JSONL 文件或一份数据集。到工业 RL 训练中，一条轨迹从生成到参与更新再到回流，要经过任务生成、环境执行、样本评分、存储与再加工多个环节。多机训练每小时可以生成数十万条轨迹，任何一个环节处理不好，要么数据大量损失，要么错误轨迹反复进入训练。
这一节沿着一条轨迹的生命周期展开：任务池怎样从已有题库和真实失败案例扩展开来；运行时怎样保存轨迹、奖励和中间状态；质量控制怎样过滤错误样本和不可执行轨迹；最后怎样把高质量数据回流到下一轮 SFT 或奖励模型训练。
任务生产：从固定题库到真实失败驱动
为什么单一数据来源不够用：早期 RL 训练常使用公开的数学、代码或推理数据集启动。这些数据质量稳定，但题型分布固定，模型学会这些模式以后提升会停滞。真实使用中的失败样本包含新的工具组合、长链路推理或边界情况，是题库难以覆盖的。
工业训练通常把以下几类来源组合起来：
- 学术与公开基准：MATH、GSM8K、AIME、MMLU、HumanEval、MBPP 等题目覆盖常见数学和代码能力，适合冷启动和回归测试。
- 合成任务：通过模板生成、程序构造、模型改写和难度控制扩展任务量，覆盖特定格式或推理类型。
- 交互环境任务：访问终端、浏览器、代码沙箱或外部工具的轨迹，对应计算机使用、软件工程和多轮工具调用。
- 真实失败样本：内测、公测或线上使用中的失败案例，包括答案错误、工具调用失败、格式错误和拒绝回答等。
- 安全与对抗数据：越狱尝试、敏感问题、诱导格式错误和高风险任务，用于训练模型在约束下仍然保持正确行为。
MiniCPM 5 采用约 3 万高质量种子 prompt，其中 2/3 为通用推理、数学和代码任务，1/3 为工具使用与代理任务。Kimi K3 在公开竞赛题库之外，又从预训练语料中提取任务并结合真实世界反馈构建数据。Qwen-AgentWorld 初始包含 20 个领域的 5000 个种子任务，在 60 个 GPU 上并行运行，两周内扩展到 3 万个任务。
难度控制和数据调度：任务池规模扩大以后，不是所有题目都应该被模型以相同频率看到。太简单的题无法驱动更新，太难的题会持续失败并导致高方差梯度。实际训练常结合以下策略：
- 能力边界附近优先：记录不同难度、不同类型任务的成功率，优先采样模型近期正确率介于 到 的任务。
- 失败案例加强：把真实错误和高价值失败案例放回任务池，提高它们被采样的概率。
- 反多样性采样：当某一类任务已经大量成功时，降低它的采样频率，把容量留给表现更差的任务。
- 分阶段调度：训练早期侧重基础能力，训练中后期加入长程、多工具和多约束任务。
- 安全任务持续注入：即使主任务已经稳定，也持续混入少量安全和格式约束任务，防止能力提升时边界被遗忘。
任务格式与提示构造：同一条任务可以用多种提示形式呈现。数学题既可以直接问结论，也可以要求展示推理步骤；代码题既可以提供部分代码，也可以给出自然语言描述；工具任务既可以给出明确步骤，也可以只描述目标。
目标：修复一个 Python 函数
输入：出错的代码和失败的测试输出
形式 A：直接修改代码
形式 B：先解释错误原因，再修改代码
形式 C：先运行测试观察报错，再修改代码并再次运行如果训练只使用单一形式，模型可能只学会一种回答模式。工业数据工程会为同一任务准备多种提示模板、输出格式和上下文长度，再把它们混合采样。
可执行环境的构建：工具调用、代码执行和浏览器任务需要可运行的环境，而不只是静态 prompt。
- 沙箱隔离：代码执行、终端访问和网页访问都应在隔离环境中运行，避免训练任务影响外部系统。
- 环境标准化：不同 rollout 节点使用一致的语言版本、工具版本、依赖库和网络权限，否则同一轨迹在不同节点可能得到不同结果。
- 状态重置：每条轨迹开始前重置文件系统、数据库、浏览器状态和工具会话，保证轨迹独立。
- 超时与重试：工具调用可能挂起、超时或返回异常。训练数据系统需要记录失败类型，而不是简单丢弃这些样本。
- 多环境编排：Qwen-AgentWorld 这类系统会为不同领域维护独立环境，再通过统一接口让模型跨环境调用。
任务生产的目标不是简单扩大数据量，而是保证数据持续分布在当前模型的能力边界、真实失败场景和安全边界上。
数据保存：一次 rollout 需要记录什么
最小训练记录不足以排错：很多 PPO 或 GRPO 实现只保存 prompt、response、reward 和 log-probability，足够计算一次梯度，但不足以排查"为什么奖励突然下降""为什么某类回答变多"或"为什么某个验证器突然大量报错"。
工业训练通常把一条轨迹分成几个层级保存：
- 任务层：prompt、任务类型、难度标签、来源、环境配置、提示模板版本。
- 轨迹层：模型的完整 response、每一步 token、每一步 log-probability、生成时间、温度、采样参数和模型版本。
- 交互层：工具调用请求、工具返回结果、中间代码执行输出、浏览器操作记录和错误信息。
- 奖励层：每个奖励函数返回的值、权重、聚合方式、格式化检查结果、单元测试通过数量和最终总分。
- 系统层：rollout worker 编号、时间戳、模型 checkpoint 标识、环境镜像版本和随机种子。
奖励模型训练还要保存成对偏好：如果后续要训练奖励模型，除了保存每条回答的最终分数，还要保留问题、同一问题的多个回答、哪些回答被判定为更好、以及判定来源（规则、人类标注或模型裁判）。MiniCPM 5 的 RLVR 系统会在每轮迭代中自动生成 prompt、执行 rollout、记录元数据并为奖励模型准备成对偏好数据。
大规模存储与索引：一个月的多机 RL 训练很容易产生数 TB 到数十 TB 的轨迹数据。保存时通常考虑：
- 列式与分层存储：原始文本、张量和日志分开保存；高频访问的统计字段单独建索引。
- 压缩与去重：相同 prompt 的重复 rollout 可以共享 prompt 存储；张量使用适合训练恢复的压缩格式。
- Checkpoint 绑定：每条轨迹绑定到生成它的模型 checkpoint 和参数版本，方便复现和回放。
- 失败样本标记：超时、环境错误、格式错误和奖励计算失败的轨迹单独标记，既不直接混入训练，也不直接删除。
- 可复现元数据：记录随机种子、环境版本、依赖版本和提示模板版本，必要时可以重跑相同配置验证问题。
记录不是越多越好：每多存一个字段都会增加存储、清洗和查询成本。优先保存会影响梯度计算、奖励复现和故障排查的字段；对调试价值低且体积大的中间张量，可以只保留聚合统计或采样保存。
质量控制：在数据进入训练前拦截错误
奖励正确不等于轨迹可学习：一条回答拿到高分，可能是验证器漏洞、答案泄漏、格式绕过或环境异常造成的；一条回答拿到低分，也可能是奖励函数报错、测试用例有误或工具超时。若不加过滤，错误信号会直接进入梯度。
常见数据质量检查包括：
- 格式校验：回答是否符合要求的结构，是否输出了规定标签，是否遗漏必要字段，是否产生无法解析的 JSON 或代码块。
- 奖励合理性校验：总分是否在预期区间内，不同奖励项之间是否冲突，是否出现大量完全相同的满分或零分。
- 可执行性校验：代码是否通过编译或解释，工具调用参数是否合法，浏览器操作是否在环境中真实可执行。
- 重复与泄漏检测：回答是否与题目标准答案完全一致但没有推导，是否复用训练集中的固定模板，是否直接复制系统提示或环境输出。
- 异常轨迹过滤：生成时间过长或过短、输出长度异常、工具调用死循环、反复调用同一工具和明显无意义输出。
- 环境一致性检查：同一任务在不同节点是否得到一致结果；若不一致，标记为环境不稳定而不是直接给零分。 规则式过滤先于模型式过滤：格式错误、语法错误、超时和奖励服务异常都可以用规则快速拦截。只有规则难以判断的问题，才引入奖励模型或额外模型裁判。
样本过滤不是简单丢弃：被过滤的轨迹仍然有价值：
- 环境错误和工具超时轨迹帮助定位沙箱和依赖问题。
- 格式错误轨迹帮助改进提示模板和约束训练。
- 奖励异常轨迹帮助发现奖励黑客和验证器漏洞。
- 反复失败的高价值任务可以进入人工标注、提示重写或环境修复队列。
数据质量监控指标：训练运行时通常持续统计以下指标：
- 各任务类型的平均奖励、通过率和长度分布。
- 满分比例、零分比例和奖励截断比例。
- 格式错误率、工具调用失败率和环境错误率。
- 回答重复率、固定模板命中率和可疑绕过行为比例。
- 不同 worker、不同时间窗口之间的指标差异。
如果某一个 rollout 节点的满分率突然远高于其他节点，可能是环境版本不一致或缓存泄漏；如果某类任务的奖励突然全部变成满分，可能是奖励函数被绕过；如果平均 response 长度持续变短但奖励没有上升，可能是模型学会了某种短答案投机策略。
数据中毒与奖励黑客防御：工业训练中常见的异常不是明显错误，而是模型利用系统漏洞拿到高分。例如：
- 在代码题中输出跳过测试的特殊语句。
- 在问答任务中重复题目中的关键词触发匹配奖励。
- 在工具任务中选择永远返回成功但不完成目标的路径。
- 在多轮交互中通过格式化输出来干扰裁判模型。
这些问题往往不能靠单条样本检查发现，需要结合回答分布、工具调用序列、奖励项分解和人工抽样来识别。高风险漏洞一旦确认，应先修复奖励函数或环境，再继续训练。
数据回流：从 RL 轨迹到下一轮训练数据
RL 数据不会只用一次：大规模训练通常不是"一个数据集跑一次 PPO"就结束。RL 阶段产生的回答、偏好和失败样本会回流到 SFT、奖励模型和下一轮 RL 任务池中。
回到 SFT
通过规则验证、测试通过或人工确认的高质量回答，可以整理成监督微调数据。常见做法包括：
- 把完整正确的高分回答蒸馏回基础模型，强化稳定格式和解题步骤。
- 把失败后修复成功的多轮轨迹整理成"错误 → 修正"对，让模型学会从错误中恢复。
- 把工具调用轨迹整理为结构化样本，训练模型在正确时机调用工具、解析返回结果。
- 对长回答做筛选，避免把冗长但无效的推理过程全部放回 SFT。
SFT 回流通常用于稳定格式、恢复被 RL 破坏的通用能力，以及把新学会的工具行为固化为更稳定的模型初始点。
回到奖励模型
RL rollout 天然产生同一问题的多个回答，适合训练奖励模型或裁判模型：
- 同一 prompt 下，高分回答可以作为 chosen，低分回答作为 rejected。
- 规则能明确判错的样本提供强监督；人工标注和模型裁判补充复杂偏好样本。
- 需要按任务类型、难度和分数差构造 pair，避免奖励模型只学会区分极端好坏。
- 安全、真实性和格式约束样本应单独成组，防止主任务分数淹没边界信号。
奖励模型更新后再回到 RL，形成奖励模型和策略共同迭代的闭环。MiniCPM 5 的训练就将每轮 RL rollout 中自动生成的轨迹用于下一轮 RM 训练，建立 RM 和 RL 之间的正反馈。
回到任务池
失败轨迹会反向扩展任务池：
- 模型反复出错的真实问题进入下一轮任务池，并提高采样权重。
- 新工具、新 API 或新页面类型出现后，把它们转换成训练任务。
- 发现奖励黑客路径后，构造专门检测该漏洞的对抗任务。
- 把真实用户请求脱敏后加入任务池，让数据分布更接近部署场景。
安全数据与评测集闭环
工业后训练常把红队测试、安全评测和格式鲁棒性测试也纳入数据闭环：
- 越狱和高风险请求样本持续加入安全训练与拒答训练。
- 容易触发错误格式、幻觉和工具滥用的 prompt 加入回归测试集。
- 每次模型更新后，用固定评测集和新增失败样本共同评估，防止能力提升时旧问题回退。
数据版本管理：任务集、奖励函数、提示模板、环境镜像和清洗规则都应该有版本。一次训练实验需要能回答：使用了哪一批 prompt、哪个环境、哪个奖励版本、哪些过滤规则。没有版本管理，即使发现某个 checkpoint 表现更好，也很难知道是哪个数据改动带来的效果。
工业 RL 的真正规模不只是 GPU 数量，而是数据是否能持续产出、保存、清洗、回流，并且在多轮迭代中保持可追踪。
本节小结
- 任务池不能只依赖固定公开题库，要结合合成任务、交互环境、真实失败和安全数据，并按模型能力边界调度采样。
- 一次 rollout 需要保存任务、轨迹、交互、奖励和系统元数据，既支持梯度计算，也支持排错和复现。
- 质量控制需要覆盖格式、可执行性、奖励合理性、环境一致性和奖励黑客检测。
- RL 产生的数据会回流到 SFT、奖励模型、任务池和安全评测，形成持续迭代闭环。
- 大规模 RL 数据工程的核心不是"存更多数据"，而是让数据在多轮训练中可执行、可验证、可追踪、可复用。
到这里我们已经走完了单机算法、偏好优化、工业闭环、稳定性、分布式训练和数据工程。下一章把视角转向一个更具体但近年影响极大的方向：推理能力的涌现。第19章 推理能力的涌现与 o1 风格训练 将从推理能力涌现、纯RL推理训练、测试时扩展和混合思维等主题展开。