SFT构造数据的一些经验

过去一年 SFT 领域如果只能选一个关键词，那就是 Long-CoT。

蒸馏来的比手写的好得多

但也不能一味追求长

长 CoT 有一个很烦人的副作用：模型在简单问题上也会启动”深度思考”模式，1+1=2 也要推理半天。Draft-Thinking、LS-Mixture SFT 这些工作都在解决这个问题，核心思路就是数据里要有长有短：

难题给完整的长链推理，10K token 以上都行
中等难度的问题，把推理链压缩一下，去掉冗余步骤
简单问题就直接给答案，训练模型学会”这题不用想”
这个”难度自适应”现在已经是标准做法了。你要是数据集里全是长 CoT，训出来的模型推理一道小学算术题都要输出三千 token，用户体验会很差。

Long-CoT SFT 是 RL 的前置条件

一条反直觉的结论

在长链推理上要多加注意

Agent 场景对 SFT 数据的要求跟传统场景完全不一样。传统 SFT 数据是一问一答的 pair，Agent 数据是一整条交互轨迹：推理 → 选工具 → 调工具 → 拿到结果 → 再推理 → 可能还要纠错 → 最终回答。一条数据几千 token、多次工具调用是常态。

真实轨迹 vs 拼接的轨迹

这个区别比很多人想象的大。在真实环境中端到端采集的 agent 轨迹上做 SFT，效果远好于把各个环节拼接起来的合成轨迹。4B 参数的小模型在真实轨迹数据上训出来的效果，可千问 Qwen 教程以超过之前 32B 模型的水平。

怎么采集

别忘了负样本

纯文本 SFT 数据只是故事的一半。VLM 的 SFT 有自己的一套问题。

文本域的经验搬不过来

领域专家这笔钱省不了

推理模式级别的去重

格式污染和身份泄露

现在 SFT 数据大量靠模型生成，“模型指纹”污染很普遍。常见的有：蒸馏数据里残留的标签，“作为一个 AI 语言模型” 开头，Markdown 格式滥用——以及一个容易被忽略的问题：身份泄露。模型生成的回答里可能无意间说出”我是 DeepSeek”或”我是 ChatGPT”。如果你拿这些数据去训自己的模型，它也会这么说。
清洗 pipeline 里加一道身份泄露检测，成本很低但能省不少麻烦。Nemotron-Terminal 的论文里专门提到了这个过滤步骤。

数据配比别再拍脑袋了

Cold-start 数据要精不要多。 R1 的训练里只用了几千条 cold-start CoT 数据，但每条都是精心打磨的——few-shot 引导生成，人工精修可读性，从 R1-Zero 的输出里筛选好的样本。这几千条数据决定了后面整个 RL 的上限。
蒸馏时优先保留”最短正确解”。 同一道题让教师模型生成多个推理轨迹，留最短的那个正确解。推理质量有了，冗余步骤砍了，模型不容易学到”注水”的习惯。
System prompt 的多样性。 训练数据里如果 system prompt 只有一种写法（比如永远是”你是一个有用的 AI 助手”），模型到了新的 system prompt 下表现会断崖式下降。尤其 Agent 场景，system prompt 千差万别，数据构造时要刻意覆盖。
训练模型”不调工具”。 Agent 数据里如果全是调用工具的正样本，模型会形成”收到消息就调工具”的条件反射。要刻意放一些”判断不需要调工具、直接回答”的样本进去。
Targeted Human Feedback 能省标注预算。 RLTHF 的思路是先用 LLM 做粗对齐，再用 reward model 找出”模型不确定”的难样本，只对这些做人工标注。据报道 6-7% 的人工标注量就能达到全量标注的效果。这个思路在 SFT 数据的人工验证环节也能用。
版本管理。 最后一条也是最老生常谈但最多人做不到的一条。每个版本的 SFT 数据集：来源、筛选标准、配比、评估结果、跟上个版本的 diff，全部记下来。没有这些记录，三个月后 v23 和 v24 的区别你不会记得的。
如果让我用一句话概括现在做 SFT 数据应该想什么，那就是：

SFT不是教模型”什么是对的”，而是给RL搭一个好的搜索空间。
“好数据”的定义变了。以前是”答案正确、格式规范”就行，现在还得看推理结构是否合理、跟目标模型的分布是否匹配、跟后续 RL 阶段是否能配合。
一年前的最佳实践今天可能已经过时。保持 pipeline 的可迭代性比任何单一技巧都重要。

假如你从2026年开始学大模型，按这个步骤走准能稳步进阶。

接下来告诉你一条最快的邪修路线，

3个月即可成为模型大师，薪资直接起飞。