原创 孔某人 2025-02-15 20:30 北京
（其一）长度惩罚并没有想象的那么简单
本文是尝试用GRPO进行RFT实验的一些炼丹经验笔记。
1、关于算力硬件与训练框架
截至本文写作之时，开源框架对于GRPO的支持都还比较早期，各种bug还在不断发现和修正中。硬件使用效率、对多卡和多机多卡的支持都还很早期。
从硬件角度来说，目前方案对于显存的消耗都是比较大的。成本明显比SFT要高不少。
总体来说算力和训练框架方面的问题还是比较多的，但这并非本文关注的。这方面看起来是需要RFTaaS平台来解决的。
2、炼丹思考
2.1、RFT不只限于推理模型
虽然RFT由OpenAI首先作为产品发布时，明确说明是针对 o 系列模型的，但这并不代表RFT/GRPO只适用于推理模型。
实际上它可以作为一种通用的优化方式优化传统LLM。只是它更适合优化存在类似CoT过程的应用场景，这个思考过程并不一定要放在<think>标签之中，传统的CoT也可以的。不要被o1和R1模型现在的回答format限制了自己的视野。
现阶段的开源模型中，具有独立类似<think>阶段的模型并不多，强制使用这样的format并不能得到多少借力。我提倡的方式仍然是：所有的结构化设计都应该是为了与外部“非语义系统”交互而设计的。例如设计<think>标签就是为了能够从整个回答中将思考部分和答案部分简单分离，如果不需要这种分离，那么设计<think>的意义就不大。
2.2、无法解释的跨领域泛化
看别人的实验中发现了一些无法解释的跨领域泛化：两个看起来完全无关的领域A和B，在领域A的问题上使用GRPO进行了RFT，但在领域B上也看到了显著的性能改善。
我目前对此无法给出任何有预测性的解释。我们对于LLM RL post-training的理解还很少。
2.3、关于GRPO的学习效率
GRPO的过程并不复杂，但它的学习过程完全依赖于一个样本在rollout出的回答在reward衡量之后是否有区分度。如果一个样本rollout的回答都是错误，或者都是正确，那么基本上这个样本的本次计算就白费了。对于算力充足的团队大概可以用算力换系统复杂度，但对于不少人来说，这方面的学习效率是个需要关注的问题。
比较好的情况是rollout出的回答中好坏都有，这就需要模型当前的能力在reward的衡量下成功率应该在一个合适的区间，太小（~0）或者太高（~1）都不好。
如果一上来的给的样本都太难，可能GRPO训练过程摸索了很久都找不到正确的方向。所以需要在数据集中问题从简单到难都有覆盖。如果想要进一步优化学习效率，就需要采用类似课程学习的方式，根据模型当前的能力水平精准地喂难度（成功率）适合的样本。而很遗憾，到目前为止，我并没有在任何支持GRPO的开源框架中看到这类功能。
为了降低问题的难度曲线，一个方式是提供中间过程reward。看似这又回到了PRM，但实际上它可以在ORM的框架下实现。就是在reward中对中间过程的结果也进行reward反馈，这样就可以在GRPO框架上实现对于中间过程的引导，降低问题的探索难度。
但这种方式与PRM面对的问题类似，个人建议只有在明确该场景下一定需要通过某些中间结果最终获得答案时才使用这种方案，如果存在很多种解决问题的路径，而reward只奖励了某些路径的中间结果，则会限制模型的探索范围，降低得到其他更好方案的可能性。
2.4、重新理解 长度惩罚
长度惩罚是一个有些特别的业务目标，它一般并不是业务的效果指标，而是一种常见的成本指标。我们不希望无谓的浪费计算量，输出无意义的结果，就好像生物演化中基因组中的各种遗留废弃片段一样。
但当我们认真尝试长度惩罚reward时，会发现它没有我们预想的那么简单，而这就是本节要讨论的。
长度惩罚和效果指标并非不可兼得，特别是我们一般并没有很强的长度限制，我们只是希望在保持效果的条件下长度尽量短。但大部分长度惩罚reward的设置方式都会意外的无法实现这个目标，即使我们对其进行了仔细设计，在理想情况下不会影响主reward时也是会遇到问题。
具体来说，考虑如下场景：主reward是正确性指标，是0-1变量，记作I(correctness)，此外长度惩罚项设计为max(0, 1 - len/L)，其中L为常数。考虑如下几种组合方式：
I(correctness)+a -len/L
I(correctness) * max(0, 1-len/L)
I(correctness) * ( max(0, 1-len/L) * I(step>S))
从实践中来看，这些方式都不能取得目标的效果。以第二种I(correctness) * (1 + max(0, -len/L))为例，似乎该reward不会产生任何负面效果，长度惩罚只有在已经在该样本上成功时才引入，如果我们有一个完美的optimizer，似乎应该能取得期望的效果。那么是GRPO不够完美么？是否应该分析是哪些近似导致了这个问题？
实际可能并非如此，这个问题也远比我们原本想象的复杂。接下来会介绍一个解释角度：
LLM在通过CoT方式求解问题时，并非我们传统理解的固定的程序代码。它存在一些不可靠的捷径，例如根据一些信息来直接猜测结果，这些捷径可以以一定概率解决一些简单的问题，但它可能并不能很好的泛化到更难的问题上，表现为在困难的问题上成功率更低。
当使用GRPO进行rollout采样时，可能偶然会采样到一些使用了这种不靠谱捷径，但偶然成功的结果。此时由于长度惩罚reward的存在，它相对于标准的求解路径具有明显的长度的优势。所以此时更稳定但更长的答案会被惩罚，GRPO会去学习这种偶然的捷径。在整个数据集中，会趋向于学习整体的平均效果，即中等难度的样本会被以合适的长度和成功率解决，但少数较难的样本则会被放弃。这也就导致了我们会看到长度reward会牺牲整体效果的情况。
总结一下，这个问题有两个原因共同导致：LLM中存在一些不可靠的捷径思考方式，GRPO的rollout过程采样总是很有限的，导致很难区分不同路径的可靠性高低。所以我们不能过于相信那些太短的回答，不能因此就去惩罚那些更长的回答。
目前我没有找到一个完美的解决方案，不过我相信大部分在调reward的读者看了这个原因应该能想到一些应对方式，它们不完美，但有用。
这个问题说清楚之后也不算难理解，但确实在LLM RL之前我们没有遇到类似的实例，我们知道LLM是概率系统，但我们对于概率系统的认知还不够。
（花絮：这个最简化的解释角度是我和OpenAI Deep Research合作才找到的，光靠我思考和光靠ODR都不行。）
2.5、GRPO的启动慢问题
本节的内容重要性就相对较低了。刚上手GRPO的读者会遇到的一个问题就是，不知道自己有没有搞对。由于GRPO训练过程的启动较慢，就更容易让新人陷入自我怀疑中。
GRPO的训练过程启动是较慢的，在我的少量测试下，都大概在100 step之后才能看到reward的明显改变。而在这之前没有太多征兆，loss也很接近于0。
实际上它不仅是启动慢的问题，第一步的loss在数学上其实就是0，这方面可以参考下文中的分析
GRPO Loss初期为0的原因与改进方法https://www.zhangshengdong.com/post/grpo_loss/
需要说明的是，此文中的解决方案在我的场景中并不work，并不能加速启动过程，也会对后续收敛为止产生明显的影响，并没有文中说的那么好。
所以目前这个启动慢的问题仍然是一个开放问题，有待寻找更鲁棒的解决方案。
A、结语
本文就到此为止了，这些大概是我一周的摸索结果。
做GRPO的实验真的很慢，需要的工程支持也真的不少，还是希望工程框架的同学能够做先集中精力做好自己擅长的工作。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请加微信，联系方式请点击 -> 联系方式。
本文于2025.2.15首发于微信公众号和知乎，知乎链接：
https://zhuanlan.zhihu.com/p/23947569402
