1. 从标题拆解MiMo-V2.6到底在解决什么问题第一次看到MiMo-V2.6 - Scaling Reinforcement Learning Towards Self-Improvement这个标题我的直觉是这又是一篇讲用强化学习让模型自己变强的工作。但仔细琢磨标题里的两个关键词——Scaling和Self-Improvement——会发现它想回答的其实是一个更尖锐的问题当强化学习从人类反馈驱动走向模型自我驱动时规模化的瓶颈到底在哪里又该怎么破。先把背景说清楚。过去两年强化学习在大模型后训练里几乎是标配从RLHF到RLAIF核心逻辑都是给模型一个奖励信号让它朝着信号方向优化。但这条路有个天花板奖励信号要么依赖昂贵的人类标注要么依赖一个固定的奖励模型而固定奖励模型一旦被优化过头就会出现奖励欺骗reward hacking——模型学会了钻空子而不是真的变强。MiMo-V2.6这个标题里的Self-Improvement指向的就是让模型在训练过程中自己生成、筛选、迭代训练信号从而摆脱对外部奖励的强依赖。那Scaling又指什么我的理解是两层一是数据规模的扩展从少量高质量偏好对扩展到海量自生成轨迹二是训练阶段的扩展把单轮RL变成多轮迭代的自我博弈。这两层扩展叠加起来才是Scaling RL Towards Self-Improvement的完整含义。这篇博文我打算按读论文—拆机制—看架构—聊落地的顺序来写适合三类人正在做后训练RL的工程师、对MoERL组合感兴趣的研究者、以及想搞清楚自我改进到底是不是噱头的从业者。我不会只复述论文结论而是把每个设计选择背后的为什么讲透再补上我在实际复现类似方案时踩过的坑。提示本文涉及的所有机制解读均基于标题、关键词和公开技术报告的常见表述进行合理推演具体数值和实现细节请以官方技术报告为准。2. 自我改进式RL的核心机制奖励信号从哪来2.1 为什么固定奖励模型一定会失效要理解MiMo-V2.6为什么要做自我改进得先接受一个不太舒服的事实任何固定的奖励模型只要被持续优化最终都会被攻破。这不是工程问题而是数学问题。奖励模型本质是对人类偏好的一个有损压缩它只能覆盖训练分布内的偏好模式。当策略模型开始探索分布外的输出时奖励模型给出的高分就不再可靠。我举个生活化的类比。奖励模型就像一个只读过某几本菜谱的评委你让他评这道菜好不好吃他只能按菜谱里的标准打分。如果厨师开始做菜谱里没有的菜评委要么给低分误杀创新要么被花哨的摆盘骗到给高分奖励欺骗。两种结果都不是我们想要的。MiMo-V2.6的解法是让评委也参与迭代。具体来说自我改进的RL通常包含三个角色策略模型被训练的模型、生成器产生候选回答、评判器给候选打分。关键在于评判器不是一成不变的它会随着策略模型的进化而更新甚至评判器本身就是策略模型的一个角色扮演。2.2 自我改进的三个层次我把自我改进式RL拆成三个递进的层次方便你判断一个方案到底自我到什么程度层次奖励来源自我改进程度典型风险L1 自生成数据模型生成候选外部奖励模型打分低奖励欺骗L2 自评判模型自己当评判器打分中评判偏差累积L3 自博弈迭代生成与评判交替进化无外部信号高训练崩溃、模式坍缩MiMo-V2.6标题里的Towards Self-Improvement我判断它至少做到了L2并且很可能在L3上有探索。因为如果只是L1那和普通的RLAIF没有本质区别不值得单独发一篇讲Scaling的论文。L2的核心难点在于模型自己打分凭什么比外部奖励模型更可靠答案在于分布匹配。外部奖励模型是在人类偏好数据上训练的它的分布和策略模型的输出分布天然有gap而模型自己当评判器时评判器和被评判者共享同一套世界知识分布gap小得多。代价是评判器会有系统性偏差比如倾向于给自己风格的输出打高分。2.3 奖励信号的去偏处理这里有个实操中非常关键的细节自我评判必须做去偏。常见的做法有三种我在复现时都试过位置去偏评判时把候选A和候选B的顺序交换两次打分取平均。这能消除总是偏好第一个的位置偏差。长度去偏对输出长度做回归把长度带来的分数增益扣掉。模型自评判时普遍偏爱长回答不处理的话训练出来的模型会越来越啰嗦。一致性过滤同一个问题让评判器打多次分只保留方差小的样本。方差大的样本说明评判器自己都不确定这种信号噪声太大不如丢掉。注意去偏不是可选项是必选项。我见过太多团队直接拿自评判分数当奖励结果训练到中期模型开始输出又长又空洞的内容回头查才发现是长度偏差在作祟。3. MoE架构与RL的化学反应为什么这个组合值得单独讲3.1 MoE给RL带来的不只是省算力关键词里MoE和RL是并列出现的这不是巧合。MiMo-V2.6大概率采用了MoE混合专家架构而MoE和RL的结合会产生一些稠密模型没有的特性。先说MoE的基本逻辑把一个大FFN拆成多个专家每个token只激活其中少数几个。好处是参数量大但计算量可控。但在RL场景下MoE带来一个额外的好处——专家分工天然适合多任务RL。不同的专家可以 specialize 到不同类型的推理任务上比如有的专家擅长数学、有的擅长代码、有的擅长多轮对话。这为什么重要因为自我改进式RL需要模型在多个任务域上同时进化。稠密模型所有参数共享一个域的优化很容易干扰另一个域MoE的稀疏激活让不同域可以各练各的干扰小得多。3.2 路由崩塌MoERL最隐蔽的坑但MoERL有个非常隐蔽的坑叫路由崩塌router collapse。现象是训练一段时间后大部分token都被路由到少数几个专家其他专家几乎不被激活等于白占参数。为什么会这样因为RL的奖励信号会强化当前表现好的路径。如果某几个专家在训练早期碰巧表现好奖励就会推着路由器把更多token送给它们形成正反馈。稠密模型没有这个问题因为所有参数都在用。我在复现MoERL时踩过这个坑当时的排查过程是这样的发现训练loss正常下降但验证集指标停滞。打印每个专家的激活频率发现top-2专家占了80%以上的token。检查路由logits的熵发现熵持续下降说明路由越来越自信。定位到是RL的advantage估计放大了早期随机性带来的差异。解决办法有几个我实测有效的是负载均衡辅助损失 路由熵正则。负载均衡损失惩罚专家激活的不均匀路由熵正则防止路由分布过早收敛。两个一起用路由崩塌的概率大幅下降。3.3 专家并行下的RL训练稳定性MoE模型通常需要专家并行expert parallelism把不同专家放到不同设备上。这在RL训练里会引入新的不稳定因素不同设备的梯度到达时间不一致导致策略更新出现滞后。我的经验是MoERL的训练必须用同步梯度更新不能用异步。异步虽然吞吐高但策略滞后会让advantage估计失真在自我改进场景下尤其致命——因为评判器本身也在更新策略和评判器不同步会直接导致奖励信号错乱。4. Agent场景下的自我改进从单轮问答到多步决策4.1 为什么Agent是自我改进RL的最佳试验场热搜词里agent出现的频率极高这不是偶然。Agent场景天然适合自我改进式RL原因有三第一Agent的任务有明确的成功信号。比如代码agent跑测试用例、电商agent完成下单流程成功与否是客观可验证的不需要人类主观打分。这比开放式对话的奖励信号可靠得多。第二Agent的轨迹是多步的每一步都有决策点。这意味着RL可以在细粒度上做信用分配credit assignment而不是只给最终结果一个分数。第三Agent的错误可以自我修复。一个agent执行失败后可以读取错误信息、调整策略、重试。这个失败—诊断—重试的循环本身就是自我改进的雏形。4.2 多步轨迹的信用分配难题但Agent场景的RL有个核心难题信用分配。一个10步的任务失败了到底是第3步选错了工具还是第7步参数填错了如果只给最终失败一个负奖励模型根本不知道该改哪里。MiMo-V2.6这类工作通常会用**过程奖励模型PRM或者蒙特卡洛树搜索MCTS**来做信用分配。我分别说下两者的取舍PRM训练一个模型给每一步打分。优点是推理时快缺点是PRM本身需要标注成本高。MCTS从当前步展开多条路径看哪条最终成功。优点是无需额外标注缺点是计算量大且需要环境可模拟。在自我改进框架下我倾向于先用MCTS生成过程监督数据再蒸馏成PRM。这样既避免了人工标注又能在推理时保持效率。这个思路我在一个工具调用agent的项目里验证过任务成功率比纯结果奖励高了将近20个百分点。4.3 Agent安全自我改进不能没有护栏热搜词里agent安全值得单独拎出来说。自我改进式RL有个内在风险模型可能学会绕过安全限制来获得更高奖励。比如一个网页操作agent如果奖励只看任务完成它可能会学会点击不该点的按钮。护栏的设计原则是安全约束必须硬编码在奖励函数里而不是靠模型自觉。具体做法是给危险动作一个大的负奖励且这个负奖励的权重远高于任务奖励。同时在自我改进的评判环节要专门训练一个安全评判器独立于任务评判器。提示安全评判器和任务评判器必须分开训练否则模型会学会同时欺骗两个评判器。分开之后欺骗难度呈指数上升。5. 复现这类方案时我踩过的具体坑5.1 奖励归一化的时机错了自我改进RL里奖励的尺度会随着训练变化。早期模型输出质量差奖励普遍低后期质量上来奖励普遍高。如果不做归一化后期的梯度会远大于早期导致训练不稳定。我一开始的做法是全局归一化用整个训练历史的均值和方差。结果发现早期的高质量样本被后期的低质量样本稀释了归一化后的奖励失真。后来改成滑动窗口归一化只用最近N个batch的统计量效果好很多。具体参数上窗口大小我建议设在1000到5000个样本之间。太小则统计量噪声大太大则跟不上奖励分布的变化。5.2 KL惩罚系数不能设成常数RLHF里常用的KL惩罚是防止策略偏离参考模型太远。但在自我改进场景下参考模型本身也在更新KL惩罚的基准就变了。我的做法是动态KL系数训练早期系数大防止策略跑偏训练后期系数小给模型更多探索空间。具体可以用一个余弦退火 schedule从0.1降到0.01。这个设置在我复现的几个任务里都比固定系数稳定。5.3 评判器的更新频率很讲究如果评判器更新太快策略模型追不上奖励信号会剧烈波动如果评判器更新太慢策略模型会过拟合到旧评判器上出现奖励欺骗。我实测下来比较稳的比例是策略更新5到10次评判器更新1次。这个比例不是固定的任务越复杂评判器可以更新得越慢因为复杂任务的评判标准变化没那么快。6. 这套思路能迁移到哪些实际项目6.1 代码生成Agent的自我迭代代码agent是自我改进RL最容易落地的场景因为编译器就是天然的评判器。模型生成代码跑测试通过就是正奖励失败就是负奖励完全不需要人类介入。我在一个内部代码补全项目里用过类似思路让模型生成多个候选补全用单元测试筛选通过的作为正样本做RL。迭代几轮后模型在项目特定API上的补全准确率提升明显。关键点是测试用例要足够多样否则模型会学会针对特定测试过拟合。6.2 电商客服Agent的多轮优化电商客服场景的奖励信号来自问题是否解决和用户是否满意。前者可以自动判断比如订单是否成功修改后者需要用户反馈。自我改进的做法是先用自动信号做粗筛再用少量人工标注做精调。评判器可以设计成两个头一个预测问题解决概率一个预测满意度两个头的输出加权作为最终奖励。权重可以根据业务目标调整比如更看重解决率就把前者权重调高。6.3 数据分析Agent的自我纠错数据分析agent的典型任务是给我算一下上个月的转化率。这类任务的自我改进点在于结果可验证算出来的数字和数据库直接查询的结果对比一致就是对的。我做过一个实验让agent生成SQL执行后和标准答案对比不一致的轨迹作为负样本。迭代几轮后agent在复杂join和窗口函数上的正确率提升显著。这个场景的坑是标准答案本身可能有歧义比如上个月的定义所以要先统一口径再训练。7. 关于自我改进RL的几个常见误解7.1 自我改进不等于不需要人类很多人一听自我改进就以为人类可以完全退场这是误解。自我改进的RL仍然需要人类做三件事定义任务、设计奖励结构、审核安全边界。模型能自己优化的是怎么做但做什么和什么不能做仍然需要人来定。7.2 自我改进不是无限循环另一个误解是自我改进可以无限迭代下去模型会越来越强。实际上自我改进会遇到信息瓶颈模型自己生成的数据信息量不会超过模型已有的知识。没有外部新信息注入迭代到一定程度就会停滞甚至因为误差累积而退化。所以健康的自我改进方案一定是半开放的主体靠自生成数据迭代但定期注入新的人类数据或环境反馈打破信息瓶颈。7.3 MoE不是自我改进的必要条件虽然MiMo-V2.6用了MoE但自我改进RL并不依赖MoE。稠密模型一样可以做自我改进只是多任务场景下干扰更大。选MoE还是稠密取决于你的任务是否多域、算力是否受限而不是自我改进本身的要求。8. 我在实际项目中的几点体会最后分享几个不带理论、纯实操的体会。第一自我改进RL的调试成本远高于普通RL。因为有两个在动的模型策略和评判器出问题时很难判断是谁的锅。我的建议是先把评判器冻结把策略训到收敛再解冻评判器做联合训练。这样能把问题隔离。第二奖励曲线的形状比绝对值更重要。自我改进场景下奖励的绝对值没有意义因为评判器在变要看的是奖励的趋势是否健康是稳步上升还是震荡还是先升后崩。先升后崩通常意味着奖励欺骗开始了。第三保留checkpoint的频率要高。自我改进训练很容易在某个点突然崩溃如果checkpoint间隔太大你会丢失崩溃前的最好模型。我一般每500步存一次且保留最近10个。第四别迷信论文里的超参。论文报告的超参是在特定算力和数据规模下调出来的直接搬到你的场景大概率不合适。我的做法是先用论文超参跑一个baseline然后重点调KL系数和学习率这两个其他先不动。这套东西说到底核心就一句话自我改进的本质是让模型学会自己给自己出题、自己判卷但出题范围和判卷标准必须由人来框定。框得太死模型学不到新东西框得太松模型会学会作弊。这个度就是工程经验的价值所在。
