什么才是好的Reasoning数据？

过去，社区关于模型Reasoning能力提升的讨论常常落在RL 算法的优化，或者 Math / Code 这些domain的 verifiable 数据构造上。在M2 项目中，我们做了一些更「General」的探索。作为Reasoning组的成员，我想在此分享一些我们关于数据的发现和思考 —— 什么才是好的Reasoning 数据。

CoT和Response的质量

CoT的质量体现为逻辑完整而不过度冗余。比如在IF类型的任务上，过于简略的CoT往往导致模型跳步或过度自信，对模型最终的表现和能力的泛化有很大损害。对于Response，我们注意到多数开源工作都过于在过拟合某些榜单的格式pattern以求更好的刷榜效果，这对于一个通用模型来说，非常不利于模型能力的泛化。所以在合成数据时，我们做了多样性的格式混淆，并且在多方向融合实验中观察到了显著的收益。同时，对于CoT和Response中可能存在的Badcase，如幻觉、指令遵循、逻辑错误等，我们进行了规则+LLM-as-a-judge的清洗,并且持续迭代这个Misalignment消除的链路, 随着项目的进行, 我们越来越坚信所有的Badcase都有其对应的脏训练数据,而数据质量的提升必然会有模型表现上的回响。

数据分布的难度和多样性

同社区内的众多讨论一样，我们在实验中也发现了math和code数据是Reasoning能力提升的关键。这两类数据带来的Reasoning能力往往能给所有的任务带来收益，比如STEM和IF。但同时我们也发现，我们仍然需要足够多样的数据覆盖更多的domain，比如逻辑推理、科学类、指令遵循、以及开放创意类任务。不同领域的任务有相异的思考范式, Reasoning 的多样性是能力泛化的基础。另外，我们在实验中也注意到更加难、复杂的query对模型的训练更有效，所以要根据passrate (for verifiable) 或复杂度评分 (non-verifiable) 进行数据分布的调整。

数据Scaling

最后是一个老话题: Scaling。当数据质量和多样性都过关时，数据规模的提升总能带来显著收益。不论是增加query 数量、做“1Q多A”、多 epoch 训练，甚至是混合不同方向的数据带来更多的训练步数，模型都会稳步变好。在实际实现中，数据Scaling是一个非常工程化的问题，所以我们尝试根据任务特点对所有的数据做了归并，分为Verifiable和Non-Verifiable两条数据管线进行自动化数据合成与处理。管线在保证高效地Scaling数据规模的同时，也保证了不同方向的同学能以相同的标准和目标构造数据并进行实验。比如说，Reasoning团队主要由实习生们构成 (他们都很优秀)，在面对繁杂的数据标准和训练细节时，管线帮助大家快速地熟悉并融入了这个项目。

后续工作

接下来我们会继续往两个方向深入。一个是复合能力，比如知识+Reasoning，以及在Agent场景下工具对Reasoning任务的增益。另一个是如何融合Verifiable和Non-Verifiable两类任务，比如不同domain上的CoT的融合与Reasoning能力的泛化，以及训练方式的统一。