前言
前阵子圈子里有人去淘天面算法岗,面试官抛了一道他觉得很拿手的题:
👔 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 那一列",但它意味着:
- 数据预处理流程不同:SFT 数据进 GRPO 流程前,要把 Completion 列剥离掉(或者只留作奖励函数的参考答案),不能让模型在训练时看到它。
- 标注成本结构不同:SFT 花钱请人写答案,GRPO 花钱请人写验证规则(测试用例、答案匹配逻辑)。同一道题,SFT 标注和 GRPO 标注是两套不同的工作。
- 质量评估标准不同:SFT 数据质量看"答案写得好不好",GRPO 数据质量看"验证规则严不严格"。一条 SFT 数据答案写得再好,如果没有配套的可验证规则,对 GRPO 来说也是废数据。
工程判断:数据同源的"同源"指的是 Prompt 同源,不是标注同源。Prompt 可以共享,但 Completion 和验证规则是两套独立的标注产物。
六、为什么"可以用一样的数据"但"不能直接复用"
纯从工程落地角度说,把 SFT 数据集的 Prompt 列单独拎出来,挂上自定义奖励函数,GRPO 就能跑起来。DeepSeek-R1 的训练日志也佐证了这条路:它 RL 阶段用到的题目,其实就是指令微调阶段题库的一个子集,两个阶段共享同一批底层数据源。所以"数据同源"这件事在技术层面毫无障碍。
但这并不意味着直接复用就是合理的。同源数据在进入 GRPO 流程之前,需要经过和 SFT 完全不一样的筛选和处理:
- 只保留可验证的任务------开放式写作类样本要么剔除,要么单独设计奖励机制。
- 剔除通过率两极化的样本------太简单和太难的都删掉,只留中等难度。
- 专门设计奖励函数------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 分对比:
| 追问点 | 60 分回答 | 90 分回答 |
|---|---|---|
| "开放式写作拿什么当奖励信号?" | "用奖励模型" | "LLM-as-Judge 有长度偏见噪声大;工程上可以拆成多维规则奖励,或用 pairwise 排序代替绝对评分" |
| "难度分布有什么要求?" | "中等难度最好" | "通过率 0 和 1 的都没信号,要按通过率过滤留 0.1-0.9 区间;小模型有反例,低难度也能跑" |
| "SFT 数据格式和 GRPO 啥区别?" | "GRPO 只要 Prompt" | "SFT 标注成本在写答案,GRPO 标注成本在设计验证规则;同源是 Prompt 同源,不是标注同源" |
| "SFT 训多了对 GRPO 有影响吗?" | "没影响" | "有,过度 SFT 收窄输出分布,采样多样性下降,GRPO 组内优势趋零;监控 distinct-n 找停点" |
加分项提示: 如果你能主动提到 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 干的是告诉模型哪条道更快------两边要的"赛道",打一开始就不是同一条。
你在后训练里踩过 SFT-GRPO 数据复用的坑吗?欢迎评论区交流你的经验。