RL 训练 LLM：永不放弃硬问题
Learning to solve hard problems in RL for LLMs by never giving up
在 RL 后训练 LLM 时，评估曲线上升未必代表模型真正变强。我发现了导致性能停滞的 Matthew Effect，并提出 Never Give Up 策略来攻克难题。通过异步 RL 技巧，我们在 Math 和 Code 任务上验证了这一方法的有效性。这不仅解决了评估偏差，还揭示了 Primacy Bias 的深层影响。
每个优秀的 RL 实践者无疑都见过评估曲线上升，但这真的意味着模型能力提升了么？
- austin-cheney
我最近也遇到过类似的情况。
大约一个月前，我为我的应用写了一个性能分析工具，用来测量网络消息速度。结果显示，在我的 TypeScript 应用中，每秒可以发送 3,250,000 条 WebSocket 消息。如果我把实验中的每个测试放到独立的调用栈中，我就能以 0.002 秒的速度发送 3,250,000 条消息。Claude 也确认了这个数字。
大约两周后，我才意识到这个数字是错的。如果这只是一个线性指令处理问题，那这个数字才是对的。实际上，处理时间、CPU 和网络处理只占了约 0.08%。其余 99.92% 的处理时间都花在了内存上。当时发生的情况是，性能工具会从 JavaScript 循环中将消息推送到套接字的队列中，但处理这些消息并清空网络缓冲区的速度却低于循环的执行速度。
修正这个问题后，我的传输速度降到了更现实的每秒 100,000 条消息。优化队列管理后，速率提升到了每秒 800,000 条消息。再将每条消息的发送推入独立的调用栈，则能在单个套接字上实现每秒 6,000,000 条消息的速率，但这会牺牲稳定性来换取这样的传输速度。
我的错误数字之所以被 Claude 确认，原因和我当初相信它的原因一样：这是一种基于逻辑推理的确认偏误。Claude 和我一样得出了这个结论，但推导过程却完全不同。
- MiliasGeiger
> 想要更深入、更技术性的解读，请查看 arxiv 上的论文和 github 上的代码。
顶部的这些链接指向的是同一个页面，而不是论文或代码！
- tpoacher
为什么这条线程下两条高质量的评论一上来就挂了？
最近我经常看到这种情况，当页面评论还不多时，深刻的评论被埋没，留下的全是琐碎的。到底怎么回事？