GRPO训练数据能否直接复用SFT？同源不同用的三重约束

前言

前阵子圈子里有人去淘天面算法岗，面试官抛了一道他本以为手到擒来的题：

他几乎是脱口而出：“技术上可行，把 SFT 的 Prompt 提取出来配上奖励函数就能跑 GRPO。”

面试官点了点头，接着追问：“那假如 SFT 阶段喂的是 LeetCode 题解，现在直接拿这些题跑 GRPO，你想想有什么问题？”

他正要开口，忽然卡住了。

这时他才意识到事情没那么简单——力扣题的难度跨度极大。简单题模型一次通过，组内无法区分优劣；难题不论怎么采样都做不对，组内同样拉不开差距。更棘手的是，GRPO 所需的奖励信号必须是可验证的——代码能否运行、测试能否通过，这与 SFT 直接拿参考答案比对完全是两码事。

走出面试间他才真正想通：数据可以共享源头，但使用方式截然不同。SFT 是为模型搭建起跑线，GRPO 是为模型指明正确路径——两条赛道根本不是一回事。

读完这篇文章，你能理解：

• GRPO 和 SFT 的本质差异——一个是模仿，一个是探索
• GRPO 对数据的三重约束——可验证性、难度分布、数据格式
• 为什么“数据同源”在技术上没问题，但实践中需重新做数据工程
• 过度 SFT 会给后续 GRPO 埋下哪些隐患
• DAPO 为何出现——GRPO 在长 CoT 上的序列级偏袒问题
• 面试话术三层模板——60 分答法与 90 分答法的差距在哪

无论你是做 LLM 后训练的算法工程师，还是需要在面试中讲清 RLHF 链路的开发者，这道题都值得提前想明白。开拆！

一、核心结论：技术上可行，实践中需调整

GRPO 的训练数据能否与之前的 SFT 完全一致？答案是：技术上没啥问题，但实践中不建议直接照搬。

这个问题乍看普通，但深挖下来很考验人——它并非考察你是否记住某个 API 参数，而是看你是否真正理解强化学习的训练逻辑。

很多人会卡在“能不能”的二元选择上，给出“能”或“不能”的回答。但这道题真正的考点是：能，不代表应该。数据同源不等于数据同用，原始数据可以共享，但进入 GRPO 流程前的数据工程需要重新执行。

接下来先理清两套机制的本质差异，再看 GRPO 对数据的三重约束。

二、SFT 与 GRPO 的本质差异

要搞清楚数据能不能复用，先把两套机制放在一起对比。

SFT（监督微调）走的是 NTP（Next Token Prediction）路线。拿到一个 Prompt，配上一组标准答案 Completion 作为标签，模型的任务就是让自身输出分布去逼近这条标签。这套机制本质上是数据驱动的黑盒拟合——训练集长什么样，模型就学成什么样。优点是训练稳定、易于控制，天花板则被数据集质量直接卡死。

GRPO 走的是另一条路径。核心玩法是：拿到一个 Prompt，让模型连续采样出多个不同回答，然后奖励函数给每个回答打分，再算出组内的相对优势，用这个相对优势作为梯度信号更新模型。关键词是“组内相对”——它不关心单个回答的绝对好坏，只关注这个回答在自己那组采样里排第几。换句话说，GRPO 告诉模型的不是“标准答案长这样”，而是“你生成的这堆里，哪几个更优一点”。

从算法谱系看，GRPO 是 PPO（Proximal Policy Optimization）的改良版。最关键的变化是砍掉了 Critic（价值模型）这个需要单独训练的组件，改用多采样输出的奖励归一化来近似优势函数。这一改动大幅降低了显存开销，但代价是：训练数据的配置方式与 SFT 完全不同。

一句话总结：SFT 是给模型安装起跑线，GRPO 是告诉它往哪个方向奔跑。

三、第一重约束：可验证性是前提

GRPO 对数据的特殊要求可归纳为三重约束，第一重是可验证性——这是基本前提。

GRPO 依赖奖励函数来区分输出的优劣。正因为如此，DeepSeek 选择将 GRPO 主要应用于数学推理和代码生成这两类任务，原因很直接：这些领域拥有天然的二元验证逻辑——数学答案对就是对、错就是错；代码能运行就是能运行、报错就是报错。

但换到开放式写作、主观问答这类任务上，这种二元验证就失效了。将 SFT 中的开放式样本硬塞进 GRPO，奖励函数该如何定义？这恰恰是工程上最棘手的环节。

把 GRPO 扩展到开放式、长文本生成任务（如写诗、创意写作、通用指令跟随）时，核心挑战是缺乏客观的评估标准，很难区分高质量输出与低质量输出。即便请来通用奖励模型打分，它的评分也常常与回答长度正相关——字数多就给高分，与实际内容质量关系不大。

换句话说，只要离开可验证任务的舒适区，GRPO 的奖励信号就会充满噪声，模型甚至可能摸索出投机套路——比如用正确格式包装错误答案，或者编写一段能通过测试但本质是硬编码的代码来蒙混过关。

工程判断：如果你的 SFT 数据中混有大量开放式写作类样本，直接拿去跑 GRPO，这些样本不仅不会带来学习信号，反而会注入噪声，拉低整体训练效果。进入 GRPO 流程前，必须把不可验证的任务剔除，或者为它们单独设计一套奖励机制（比如用 LLM-as-Judge，但需要接受噪声更大的代价）。

四、第二重约束：难度分布决定学习信号

GRPO 对训练样本的难度有隐性要求，这一点经常被忽视。从机制上推导可以明白：

• 如果一个 Prompt 对当前模型来说太简单，模型采样出的所有输出奖励都接近满分，组内优势趋近于零，基本上等于没有学习信号。
• 如果一个 Prompt 太难，模型始终全部答错，奖励同样会趋近一致，优势也会消失。

全对和全错的结果一模一样——白练。真正有训练价值的，是那些让模型“时对时错”的中等难度题——模型在这道题上的通过率既不是 0 也不是 1，恰好卡在能拉开差距的区间。

实际落地时，业内团队通常会先用 LLM 给每道题估算一个通过率，把通过率过高或过低的样本剔除，同时配合 N-gram 和向量相似度过滤，确保数据的多样性。而 SFT 数据集的难度覆盖通常比较均匀，有时还会刻意加入大量“示范性”的简单例子——这类数据如果直接拿来做 GRPO 训练，效率会非常低。

不过这里有个反直觉的发现：在 0.5B 到 3B 这个参数量段，只用低难度样本跑 GRPO，效果竟然与全量难度数据训练持平，训练步数还节省了将近一半。也就是说，“挑难题才能练出真本事”这个直觉并不成立——GRPO 该喂什么难度的数据，得看基础模型自己的能力边界，不能拍脑袋决定。

工程判断：SFT 数据中那些“示范性简单例子”是给模型做模仿用的，对 GRPO 而言几乎全是噪声。进 GRPO 流程前，按通过率过滤是必做的一步——保留通过率在 0.1-0.9 之间的样本，剔除两端。

五、第三重约束：数据格式的结构性差异

第三重约束是数据格式的结构性差异，这个区别看似不大，但实际上影响了整套数据处理流程。

SFT 的数据格式：Prompt + Completion 的完整配对，模型直接对 Completion 做监督学习。标注成本主要集中在“写出高质量答案”。

GRPO 的数据格式：训练时只使用 Prompt 这一列，Completion 完全由模型自身采样产出。即便数据集里带有标准答案（例如数学题的最终结果），它的角色也不是给模型看的标签，而是用来搭建奖励函数的验证基准。因此标注成本的重心从“写好答案”转向了“设计可靠的验证规则”。

这个差异看似只是“少了 Completion 那一列”，但它意味着：

1. 数据预处理流程不同：SFT 数据进 GRPO 流程前，需要将 Completion 列剥离（或仅作为奖励函数的参考答案），不能让模型在训练时看到它。
2. 标注成本结构不同：SFT 花钱请人写答案，GRPO 花钱请人写验证规则（测试用例、答案匹配逻辑）。同一道题，SFT 标注和 GRPO 标注是两套不同的工作。
3. 质量评估标准不同：SFT 数据质量看“答案写得好不好”，GRPO 数据质量看“验证规则严不严格”。一条 SFT 数据答案写得再好，如果没有配套的可验证规则，对 GRPO 来说就是废数据。

工程判断：数据同源的“同源”指的是 Prompt 同源，并非标注同源。Prompt 可以共享，但 Completion 和验证规则是两套独立的标注产物。

六、为什么“可以用相同的数据”但“不能直接复用”

从纯工程落地角度看，把 SFT 数据集的 Prompt 列单独抽取出来，挂上自定义奖励函数，GRPO 就能运行。DeepSeek-R1 的训练日志也佐证了这一点：其 RL 阶段使用的题目，其实就是指令微调阶段题库的一个子集，两个阶段共享同一批底层数据源。所以“数据同源”在技术层面毫无障碍。

但这并不意味着直接复用就是合理的。同源数据在进入 GRPO 流程前，需要经过与 SFT 完全不同的筛选和处理：

1. 只保留可验证的任务——开放式写作类样本要么剔除，要么单独设计奖励机制。
2. 剔除通过率两极化的样本——太简单和太难的都删掉，只留中等难度。
3. 专门设计奖励函数——SFT 数据中的 Completion 不能直接当作奖励信号，需将其转化为验证逻辑（测试用例、答案匹配规则）。

换句话说，原始数据可以共享，但对应的数据工程需要重新完成。

这也呼应了 GRPO 在算法生态中的定位。在当前主流后训练体系里，SFT 负责建立格式和指令跟随能力，RL（包括 GRPO）则在此基础上针对特定规则做二次优化。两者是接力关系，而非替代关系。若是将 GRPO 当作另一个 SFT 来跑——数据原样搬、流程原样抄——就等于让一个擅长“探索对比”的算法去干“模仿”的活，它的优势一点没发挥出来，反而可能因为训练信号全是噪声，白白消耗大量算力。

七、过度 SFT 会埋下 GRPO 的隐患

值得指出的是，过度 SFT 本身也会给后续的 GRPO 训练埋下隐患。

已有研究表明，SFT 训练轮数一旦拉得过长，模型进入 RL 阶段后，探索行为会被显著抑制——同一道题采样出的回答越来越相似，多样性持续走低，最后 GRPO 带来的增益反而跑不赢那些只做了适度 SFT 的基线模型。

这里的逻辑是这样的：GRPO 的学习信号来自“同一 Prompt 的多个采样输出之间的相对优势”。如果模型经过过度 SFT 后，对同一个 Prompt 的采样输出高度趋同（都长一个样），则组内优势趋近于零——又回到了“太简单”的困境。过度 SFT 把模型的输出分布“收窄”了，而 GRPO 恰恰需要输出分布“足够宽”才能产生有区分度的相对优势。

这意味着 SFT 和 GRPO 之间不只是数据的接力，更是一种需要动态平衡的协同关系：

• SFT 太少：模型连基本格式都学不会，GRPO 采样出的输出乱七八糟，奖励信号也是噪声。
• SFT 适度：模型掌握了基本格式和指令跟随能力，采样输出既有多样性又有合理结构，GRPO 能产生有效学习信号。
• SFT 太多：模型输出分布收窄，采样多样性下降，GRPO 组内优势趋零，学习信号消失。

在工程实践中，这个平衡点通常通过监控“采样多样性指标”（如 distinct-n、entropy）来寻找——SFT 训练到多样性指标开始快速下降时就应停止，不要等到归零。

八、从架构师视角看 GRPO 数据工程的几个取舍

讲完三重约束和 SFT-GRPO 协同关系，从架构师视角看几个 GRPO 数据工程的取舍。

取舍一：可验证任务 vs 开放式任务的奖励函数设计。 GRPO 在数学和代码上效果好的原因在于二元验证逻辑。但真实业务场景中不可能只做这两类——客服对话、文案生成、摘要总结都需要 RL 优化。对于开放式任务，工程上有三条路径：（1）用 LLM-as-Judge 作为奖励模型，接受长度偏见的噪声；（2）设计多维度的规则奖励（格式合规分+关键词覆盖分+长度约束分），将“好”拆解为可量化的子目标；（3）用 pairwise 排序代替绝对评分，让 Judge 模型比较两个输出的好坏而非打绝对分，降低偏见。三条路各有代价，选择哪条取决于任务对奖励精度的敏感度。

取舍二：通过率过滤的阈值——严格 vs 宽松。 保留通过率 0.1-0.9 的样本是经验值，但阈值可以调整。严格过滤（0.2-0.8）数据质量高但样本量可能不足；宽松过滤（0.05-0.95）样本量大但混入噪声。工程上建议先用宽松阈值跑一轮观察学习曲线，如果 reward 上升缓慢或震荡大，再收紧阈值。没有一次性固定的阈值，需要根据训练动态调整。

取舍三：采样数量 G 的选择——成本 vs 信号质量。 GRPO 对每个 Prompt 采样 G 个输出计算组内优势。G 太小（如 4）统计噪声大，组内优势估计不准；G 太大（如 64）算力成本激增。工程上 G=8 到 16 是常见区间，具体取决于任务难度和预算。高难度任务需要更大的 G 才能覆盖“有时对有时错”的区间，低难度任务 G=8 即可。

取舍四：奖励函数的稀疏 vs 密集。 数学题的奖励通常是稀疏的（最终答案是否正确，0 或 1），代码题可以做得更密集（编译通过+测试通过+代码风格）。稀疏奖励训练慢但信号干净，密集奖励训练快但容易让模型钻空子（例如为了代码风格分写一堆无意义注释）。工程上建议从稀疏奖励起步，确认训练稳定后再逐步增加密集信号。

取舍五：SFT-GRPO 的训练顺序——串行 vs 交替。 标准做法是先 SFT 再 GRPO，串行执行。但有研究发现交替训练（SFT 一轮→GRPO 一轮→SFT 一轮……）在某些场景下效果更好——GRPO 探索出来的好输出可以反哺 SFT 的训练数据。代价是训练流程复杂度翻倍，且交替节奏不易控制。工程上，如果标准串行效果已达标，不建议为了“可能更好”而采用交替；只有当标准方案效果碰壁时才值得尝试交替。

取舍六：DAPO 的启示——长 CoT 场景的序列级偏袒。 GRPO 本身也并非终点。DAPO 的出现表明一个问题：当 CoT 输出变长时，GRPO 那种序列级的损失归一化会悄悄偏袒短输出（越长越吃亏），训练稳定性也会随之下降。这些工程问题的解决，归根结底都指向更精细的数据设计，而不是单纯堆算力。如果你的任务涉及长链推理，需提前评估 GRPO 的长度偏袒是否会影响训练收益。

九、面试话术：考官想听的是什么

回到面试场景。当面试官问“SFT 数据包含不适合二元验证的任务（如开放式写作）时，怎么设计 GRPO 的奖励函数”，这道题考的不是你记不记得某个奖励模型的名字，而是你是否真正理解 GRPO 依赖可验证奖励这个前提。

常见错误回答一：二选一。 “能”或“不能”——这是最差的答法。面试官问的是“能不能直接复用”，你回答一个字，信息量约等于零。

常见错误回答二：只讲技术不讲工程。 “技术上可以，SFT 的 Prompt 抽出来配奖励函数就行。”——这是开头那个回答，方向对但缺深度。面试官追问“开放式写作怎么办”时就会卡住。

高分答题模板：三层结构。

第一层（抛本质）：“数据同源在技术上没问题，DeepSeek-R1 的 RL 阶段就是指令微调阶段问题集的子集。但‘同源’不等于‘同用’，进入 GRPO 流程前必须做针对性处理。”

第二层（讲三重约束）：“GRPO 对数据有三重约束：可验证性——开放式写作没有二元验证逻辑，奖励信号噪声大，需要用 LLM-as-Judge 或规则奖励兜底；难度分布——太简单和太难的都没学习信号，要按通过率过滤留中等难度；数据格式——SFT 用 Prompt+Completion，GRPO 只需 Prompt，标注成本结构完全不同。”

第三层（升华）：“SFT 和 GRPO 是接力关系不是替代关系。过度 SFT 会收窄输出分布，抑制 GRPO 的探索能力。数据可以同源，但数据工程要重做。”

60 分 vs 90 分对比：

加分项提示： 如果你能主动提到 DAPO——“GRPO 在长 CoT 场景有序列级偏袒短输出的问题，DAPO 就是为解决这个出现的”——面试官会认为你不只懂 GRPO，还在跟进算法前沿。

总结

回到开头那道面试题。“GRPO 训练数据能不能直接复用 SFT 的”——这道题考察的是你对强化学习训练逻辑的理解深度，不是记不记得某个 API 参数。

• 核心结论：技术上可以同源，实践中不建议直接复用。数据同源 ≠ 数据同用。
• SFT 与 GRPO 的本质差异：SFT 是模仿（NTP 拟合标签），GRPO 是探索（组内相对优势驱动）。SFT 装起跑线，GRPO 指方向。
• 三重约束：可验证性（数学/代码有二元验证，开放式写作没有）、难度分布（通过率 0 和 1 的都没信号）、数据格式（SFT 用 Prompt+Completion，GRPO 只需 Prompt）。
• 数据工程要重做：只保留可验证任务、剔除通过率两极、专门设计奖励函数。原始数据共享，处理流程独立。
• 过度 SFT 埋隐患：输出分布收窄→采样多样性下降→GRPO 组内优势趋零→学习信号消失。监控 distinct-n 找 SFT 停点。
• DAPO 的启示：长 CoT 场景 GRPO 偏袒短输出，序列级损失归一化有问题。工程问题的解法指向更精细的数据设计，不是堆算力。

数据可以共用源头，但用法截然不同。更精确地讲：SFT 干的是把起跑线搭好，GRPO 干的是告诉模型哪条道更快——两边要的“赛道”，打一开始就不是同一条。