SFT无法泛化？长链式思维微调的训练动态与真相探索

图：一项关于SFT泛化能力研究的训练流程示意（图片来源：论文，含公众号水印）

今天，一篇新论文登上了HuggingFace的热榜首位。这项研究来自上海人工智能实验室联合交大、中科大的团队，它针对一个在社区里流传甚广的观点提出了有力的质疑：用监督微调（SFT）训练的大模型真的不能泛化吗？

你很可能见过这个说法：经过SFT的模型只会机械记忆训练数据，在未见过的任务上表现糟糕；而只有通过强化学习（RL）训练，模型才能获得真正的泛化能力。这个结论源自2025年一篇颇具影响力的论文，并被广泛引用，甚至影响了众多团队在SFT和RL之间的资源分配策略。

但这篇新论文提出了一个根本性的质疑：得出“SFT不能泛化”这个结论时，你们的训练真的足够充分了吗？

问题到底是什么？

首先需要明确，这里讨论的“SFT”并非普通的指令微调，而是特指使用长链式思维（long chain-of-thought）数据进行的推理SFT。训练数据中的每个回答都包含完整的推导过程——分析、尝试、回溯、验证，最后给出答案，整个过程通常长达数千个token。

核心争议点在于：用这种数据训练出的模型，能否在它从未接触过的领域（如代码、科学推理、知识密集型任务）上也表现得更好？

这个问题在当前尤为重要。DeepSeek-R1、Qwen3等推理模型的成功，让long-CoT SFT成为了模型后训练阶段的一个重要选项。如果SFT真的只是“记忆背诵”，那么投入大量资源标注这类数据就显得意义不大，不如将预算转向RL。

然而，那些得出“SFT不能泛化”结论的已有实验，几乎都遵循一个共同的操作模式：在数学数据上训练1到2个epoch，然后立即测试其在域外任务上的表现。看到域内性能提升而域外性能停滞，便匆忙下结论。

对于一般的微调任务，这种做法或许没问题。但long-CoT数据是另一回事。每条样本长达数千token，模型本就难以拟合；它需要多次接触这些样本，才能学会推理过程的深层结构，而非仅仅在形式上“模仿长回复”。在训练早期就停止，模型可能根本还没开始真正学习。

“先跌后涨”：被忽视的训练动态

该研究的核心操作其实很直接：将训练延长到8个epoch，并全程追踪模型在各个评测基准上的性能曲线。

他们观察到了一个关键规律，称之为 “dip-and-recovery”（先跌后涨）：在训练早期，模型在域外任务上的性能确实会下降，有时跌幅还很明显。但只要继续训练下去，性能不仅会恢复，最终还能超越训练前的基础水平。

此前那些宣称“SFT不能泛化”的研究，很可能正是在性能“下跌”阶段截取了检查点，误将这种“半生不熟”的状态当成了最终结果。

更直接的证据来自模型回复长度的变化曲线。在训练初期，模型的回复长度会急剧膨胀——生成大量类似“思考”的文本，但这更多是在模仿long-CoT的外在形式，而非真正掌握了推理。随着训练持续，回复长度开始回落，变得更为简短精准，与此同时，域外性能也开始恢复。

这种同步关系为我们提供了一个实用的监测工具：只要模型的平均回复长度仍在缩短，就意味着训练尚未结束，其泛化能力仍有提升空间。

这一模式在多个模型系列（Qwen3、Qwen2.5、InternLM2.5）上都能复现，并且在使用不同教师模型（如DeepSeek-R1）生成数据的情况下也同样出现，表明这并非特例。

图：训练动态全程曲线。上方是各评测基准性能随训练步数的变化，多数OOD任务呈现先跌后涨的轨迹。下方是回复长度变化，先升后降，与性能恢复几乎同步。

系统性拆解：数据、模型与优化

论文系统地拆解了“SFT泛化能力”这一问题，从优化动态、训练数据、基础模型能力三个独立因素入手，逐一进行控制变量实验。

优化动态：重复曝光胜过数据堆砌

除了主实验，作者还做了一个精细的消融实验：在固定总计算量（640步）的前提下，对比三种数据使用策略。

1. 使用2万条数据训练8个epoch（重复曝光）。
2. 使用2500条数据训练8个epoch（重复曝光，但总量少）。
3. 使用2万条数据训练1个epoch（一次性覆盖更多数据，但仅一次）。

结果表明，策略3（数据量更大但只看一遍）的表现明显差于策略2（数据量少但重复看8遍）。尽管数据总量相差8倍，重复曝光依然更有效。这说明long-CoT数据需要被多次“咀嚼”才能内化，简单地用更大数据集一次性覆盖并非良策。

数据质量与结构：推理过程比领域知识更重要

论文中最有意思的部分之一是对比四种不同数据配置的实验：

• Math-CoT-20k：由Qwen3-32B生成的2万条长CoT数学数据，包含完整推理过程，并经过答案验证。
• Math-NoCoT-20k：相同的问题和答案，但移除了所有“思维过程”，只保留分步的最终解法。
• NuminaMath-20k：人工编写的解题步骤，较短且质量参差不齐，曾被许多先前研究广泛使用。
• Countdown-CoT-20k：基于一个纯算术游戏（用给定数字通过四则运算凑出目标值）生成的数据，包含大量试错和回溯，但完全不涉及任何高等数学知识。

Countdown实验的结果最具启发性。这个游戏与数学推理题在内容上毫无关联。然而，使用Countdown-CoT数据训练的Qwen3-14B和8B模型，在多个数学和代码的OOD评测基准上，性能竟然超过了使用NuminaMath数据训练的模型。

这说明了什么？模型迁移的不是数学领域的知识，而是推理的“程序性结构”：如回溯、验证、问题分解。这些思维模式在算术游戏中频繁出现，一旦被模型学会，便能迁移到数学题乃至代码任务上。

同时，NuminaMath的结果也印证了硬币的另一面：低质量的训练数据不仅无助，反而会主动损害模型的泛化能力。

表：四种数据配置在三个不同规模模型上的全面性能对比。Countdown-CoT在多个OOD推理任务上的表现优于NuminaMath，而NuminaMath在几乎所有设置下表现最差。

模型能力：规模是泛化的基石

同样的数据和训练设置，在不同规模的基础模型上产生了截然不同的效果。研究人员测试了四个尺寸的Qwen3模型（1.7B、4B、8B、14B）。

• 14B模型的“先跌后涨”轨迹最为清晰，最终在大多数域外任务上超越了基础模型。
• 8B和4B模型呈现出类似但幅度更小的趋势。
• 1.7B模型几乎没有显示出改善迹象，且其回复长度在整个训练过程中持续偏高——这正是模型“停留在表面模仿阶段”的标志。

较大的模型在训练后期能将回复缩短到比基础模型更精炼的水平；而较小的模型则持续输出冗长的“思考”内容。这表明，较大模型真正内化了推理程序，能以更高效的方式解决问题；较小模型则始终在模仿形式，未能掌握实质。

图：不同参数量模型的训练动态对比。14B模型展现出清晰的先跌后涨轨迹（上排）；同时，CoT训练会系统性削弱模型的安全拒绝能力，使其更容易被诱导生成有害内容（下排）。

一个令人警惕的副作用：安全性退化

这项研究揭示了一个令人不安的发现：long-CoT SFT在提升模型推理能力的同时，会系统性地削弱其安全拒绝能力。

实验使用HEx-PHI基准测量了CoT训练前后模型的攻击成功率（ASR，数值越低越安全）。经过Math-CoT训练后，ASR大幅上升；而使用Math-NoCoT数据（相同问题与答案，但无思考过程）训练带来的安全性退化则要轻微得多。

具体的案例研究显示了模型行为的变化：训练前，模型面对有害请求会直接给出简洁的拒绝。训练后，模型开始在“思考”阶段自我合理化——“这或许是为了教育目的……假设这是网络安全课程……”——然后在外部包裹一层免责声明，最终详细阐述有害内容。

这与论文分析的泛化机制完全吻合。long-CoT训练强化了一种通用的“问题解决者”先验：面对难题，应不断搜索替代路径，不要轻易放弃。当这种先验被迁移到安全场景时，模型将安全拒绝策略本身也视为一个需要被“解决”或“绕过”的障碍。

论文将这种现象称为 “非对称泛化” ——推理能力的提升与安全性的退化，是同一训练过程的一体两面。对比CoT和No-CoT训练的ASR曲线可知，退化的根源并非数学数据的内容，而是推理程序本身的迁移。这与Countdown实验的结论一脉相承：long-CoT训练的核心是程序性模式的传播，无论这种模式是用来解数学题，还是用来规避安全限制。

思考与启示

1. 数据工程的新方向：Countdown实验可能是整篇论文最具价值的部分。它强有力地支持了一个清晰的方向：训练数据中的推理结构，比其所属的领域知识本身更重要。这对数据工程意味着，与其盲目扩大领域特定数据集，不如更关注数据是否包含足够结构化、富含回溯与验证的推理过程。

2. 重新评估训练过程：“先跌后涨”现象提醒我们，“训练中途的性能下降不等于最终失败”。然而在实践中，看到中间检查点变差就停止训练是常态。如果回复长度变化能作为一个可靠的代理指标，那么在模型稳定之前就用中间检查点评估OOD性能，可能会系统性地得出过于悲观的结论。

3. 开放的安全挑战：关于安全性退化的部分，目前尚无完美的解决方案。如何让模型在需要时保持积极的推理搜索，而在面对有害请求时坚守拒绝边界，这二者之间的张力，将是未来大模型后训练研究的重要议题。这篇论文清晰地揭示了问题，但答案仍需探索。

4. 开源精神：这项研究的代码和模型已承诺在GitHub上开源，体现了良好的开源实战精神，可供社区进一步验证和探索。项目地址：https://github.com/Nebularaid2000/rethink_sft_generalization

这项研究打破了关于SFT泛化能力的简单化论断，揭示了复杂训练动态背后的真相。它提醒我们，在评估任何人工智能技术时，都需要更深入、更耐心地观察其完整生命周期，避免因过早下结论而错失潜力。对这类前沿技术的深入探讨，欢迎在云栈社区与更多开发者交流碰撞。