去年开始大模型圈子的关键词明显从“能做”转向了“能进化”“自我提升”成为LLM技术报告里高频出现的核心概念。MiMo-V2.6这份技术报告主副标题都指向同一件事《MiMo-V2.6通过扩展强化学习实现模型自我提升》它没有走“堆人工数据、堆SFT样本”的老路而是把重心押在强化学习RL的规模扩展上让模型自己生成答案、自己用验证信号筛掉坏答案、再反过来训练自己。这个方向对做模型训练的工程师、研究强化学习算法的同学以及关心大模型能否持续进化的技术决策者来说都值得认真读一遍。下面我把报告背后的核心逻辑拆开讲清楚再结合我自己的实验经验给出一个可落地的Mini版自我提升训练方案。1. “自我提升”为什么是今年LLM训练圈的顶流话题1.1 RLHF教会模型“听话”但很难教会它“进步”先说说背景。过去两年大模型后训练阶段的标准范式是RLHF先做监督微调SFT再训练一个奖励模型模拟人类偏好最后用PPO把模型往人类喜欢的方向推。这套流程的效果有目共睹模型变得“听话”了、能用聊天的口吻回答、知道什么时候拒绝。但它的天花板也很明显奖励模型的信号来自人类标注人类偏好的质量和上限就等于模型的上限。换句话说RLHF更像是在给模型画一条“人工红线”而不是教模型“怎么变得更强”。人类标注员能区分哪个回答更礼貌但很难为一道超出自己能力的数学题判断哪条推理路径更接近真理。这里其实暴露了一个更本质的问题后训练的对齐目标和模型能力增长的目标并不完全相同。对齐目标是让模型输出符合人类预期能力增长目标是让模型在硬核任务上不断突破自己的边界。过去很多团队把SFT样本放大、把标注预算提高换来的是“更乖”的模型而不是“更聪明”的模型。要用有限的人力让模型真正变聪明就必须换一条路——这也是MiMo-V2.6这类工作把强化学习单独拿出来扩展的动因。1.2 MiMo-V2.6这类报告解决的是“把提升的主动权交给模型”那什么是“模型自我提升”我的理解是模型通过自身的生成能力构造下一轮训练数据再通过客观或半客观的反馈信号判断数据质量最后利用强化学习更新自己如此循环往复。整个闭环里人类不再一条一条地写标准答案而是负责提供任务池、验证规则和训练算力。MiMo-V2.6技术报告的亮点就在“扩展强化学习”这五个字。它肯定不是第一篇提到自我提升的报告之前已经有RLAIF、self-play、self-instruct等思路但它的价值在于把强化学习当成一个可以系统性扩展的训练手段来对待从任务覆盖面、奖励信号、采样策略、迭代轮次等多条线同时拉开而不是在某个角落里加一点RL。这种“把RL当主引擎”的姿态恰好是这两年被验证最有效的方向。版本号能迭代到V2.6说明这不是一次性的实验演示而是一个持续滚动的方法体系。1.3 适合谁读、读完能拿走什么如果你正在做LLM训练或微调读完至少要能回答三个问题为什么现在提到自我提升总要提RL卷算力之外的RL扩展点有哪些在有限卡数下怎么先把最小闭环跑起来。如果你是做交付或应用的也能从中获得一个判断模型持续进化能力的新视角只看榜单分数远远不够还要看模型有没有从自己的失败中修正的能力。接下来我先拆“扩展”这两个字因为这是整篇报告理解门槛最高的地方。2. 拆解“扩展强化学习”扩展的到底是哪几根柱子2.1 第一根采样与训练算力把online rollout提起来“扩展”最直观的含义是算力扩展。传统的RLHF里PPO的每次更新都需要一组“当前策略”生成的样本俗称online rollout模型边生成、边打分、边更新。很多人以为RL就比SFT多几步其实一个重要的成本差异就在rollout上要训练一个能自我提升的模型你需要生成几十万甚至上百万条覆盖不同难度和风格的响应。自我提升场景比RLHF更吃采样算力因为模型要为同一道题生成多条候选再从中挑出有正反馈的那些。一个相对典型的配置是每个Prompt生成8到64条响应过滤后保留其中10%到30%作为训练数据。背后的逻辑很简单只有让模型在搜索空间里“多尝试”它才有机会碰到比当前水平更好的解。没有足够的在线采样模型只会反复强化自己已有的行为模式所谓的自我提升就退化成自说自话。我在自己实验里体会到这条线很多时候可以用vLLM这类推理优化框架顶住把生成吞吐提上来再配合异步采样把rollout和训练解耦。算力紧张的情况下减少每轮生成的候选数、把batch切小都比放弃RL回到纯SFT要划算。2.2 第二根任务类型从单一科目扩展到开放推理第二个扩展维度是任务覆盖。前两年最流行的自我提升演示几乎都集中在数学和代码上原因是这两个领域的答案对错可以用外部规则严格判定数学题有确定答案代码题有单元测试。这类任务完全不需要人类打分奖励信号几乎“免费”。但如果只做数学和代码模型学到的“自我提升”是有偏的。MiMo-V2.6这类报告通常会逐步把任务池扩到更开放的推理任务比如逻辑推理、指令遵循、复杂问答。对应的奖励信号也从“硬验证”变成“软验证”用规则或轻量模型做一致性检查或者用一个被验证过的评判模型给分。这里值得注意的扩展逻辑是任务覆盖面越广模型在自我提升过程中接触到的分布就越接近真实世界也越不容易在个别科目上发生过拟合。如果让我措辞就是“把RL从科目训练变成通用能力训练”。实操时不要一步到位先把任务池分成几组逐组加入并观察分组评测分数的变化比一次性塞入所有任务更容易排查问题。2.3 第三根奖励信号从“对错”扩展到“过程质量”第三个扩展维度是奖励信号本身。可验证结果奖励比如答案是否正确、测试是否通过是第一步但只有一个最终分数模型很难知道错在哪里。比如一道数学大题的最终答案是错的但中间推导有几步是对的如果只给0分模型就丢掉了一次学习部分正确方法的机会。所以更进一步的方案是过程奖励模型PRM把一条完整推理拆成多个步骤每一步都给出分数。过程奖励的本质是给模型一张“逐步纠错的地图”让它在强化学习时更清楚该调整哪些行为。当然过程标注成本更高常见做法是先让模型或规则生成步骤级反馈再用人工抽查校准。我自己做代码任务时也遇到类似情况单元测试全过但代码风格和算法复杂度很糟糕。如果奖励只看测试结果模型会学会“撞测试”而不是“写可维护代码”。后来我在奖励里加入静态检查、圈复杂度、重复率等过程性信号效果立竿见影。“过程质量”这四个字往往就是一份技术报告里最见功力、也最容易被读者忽略的部分。2.4 第四根多轮自我迭代的闭环设计最后一个扩展维度是时间轴上的循环。自我提升不是训一轮就结束而是把“生成→筛选→训练→评测→再生成”这个大循环反复跑。每一轮先用当前模型生成新数据再训练出一个新版本模型下一轮用新版本继续生成。这里的扩展在于迭代轮次和每轮数据配比。通常第一轮RL效果提升最明显因为模型第一次被奖励信号“教做人”第二轮开始收益会递减甚至出现退化这时要么增加任务难度要么引入更多通用数据来对抗遗忘要么用正则化手段稳定更新。如果从头到尾不控制迭代轮次你可能会得到一个在目标评测集上越来越强、但在通用能力上越来越单薄的模型。我见过不少团队在第二轮之后开始螺旋下降问题往往出在数据配比上RL数据占比太高通用能力被挤掉。一个我比较常用的经验是每轮保留至少20%至30%的原始SFT数据用来给模型“打底”。2.5 为什么要强调“扩展”而不是“调参”最后说一句总体感受。很多人以为强化学习做不好是超参数没调对于是花大量时间改学习率、改KL系数。但这类报告想强调的是在一个足够大的在线采样规模、足够多样的任务池、足够细粒度的奖励信号、足够多轮的迭代闭环面前超参数的作用反而没有那么关键。RL在LLM上表现不稳定很多时候不是算法细节不够好而是其他四根柱子没有立起来。先扩展规模再谈调参这个顺序不能反。3. 核心技术链路可验证奖励在线RL自我生成数据3.1 一个生活类比自己出题、自己批改、自己订正我在给团队解释自我提升时常用一个类比一个有上进心的学生不再依赖老师每道题都给答案而是自己找题做做完了自己对着标准答案批改然后把错题整理进错题本再反复练习。模型自我提升大体也是这三步从任务池里“找题”采样Prompt、在自己生成的结果里“对答案”验证器打分、把高分数据放进训练流“订正”RL更新。这个类比能解释很多细节设计。比如为什么要用在线采样而不是直接用静态训练集因为学生做过的旧题已经会了继续刷旧题是在舒适区打转在线生成新响应等于让学生做新题或在老题上尝试新解法才能真正提升。再比如为什么要过程奖励只给最终分数的考试卷学生不知道哪一步丢分过程奖励等于批注版的答题卡每一行都有扣分理由。把类比映射回技术实现理解门槛会低很多。3.2 结果奖励和过程奖励分别解决什么问题从奖励函数设计说起。最基础的是结果奖励Outcome Reward也就是对一个回答给出最终评分。它适合问题本身有明确解的情况数学题答案是否匹配、代码是否通过测试、选择题是否选对。优点是简单、可自动化、不容易被游戏化缺点是信息量少模型只能通过大量试错自己推断哪一步出了问题样本效率偏低。过程奖励Process Reward则把一个长回答拆分为多个步骤逐个给分。好处显而易见模型获得的是稠密反馈一步错能立刻知道错在哪训练收敛更快。代价也很实在真实推导过程很难自动拆分就算拆了步骤边界也未必符合人类的认知。我在实际项目里的折中方案是先跑一版结果奖励把整体水平拉起来然后在困难子集上引入过程奖励专门攻克模型的高频犯错步骤。这种两段式方案既省事又不会一开始就被过程建模的复杂度拖住。顺便说一个更底层的视角如果你熟悉Transformer内部机制会知道token里有key、query、value三层信息分别大致对应“我是谁、我在找什么、我能提供什么”。奖励建模其实也在做类似的事——判断一个回答value是否匹配问题query的真实意图。把reward当成“意图匹配器”来设计很多细节会更好理解。3.3 为什么在线RL比离线训练更适合自我提升这里要分清两条路线。一条是离线强化学习例如先拿当前模型生成大量数据用规则过滤出高分样本然后当作SFT数据去微调。这其实是一种“伪在线”数据是一次性静态的模型更新之后不会再跟验证器互动。另一条是真正的在线RL模型在训练过程中持续与环境验证器交互每更新一次就重新采样新数据继续优化。在线RL的优势在自我提升场景里会被放大。因为模型在不断变强上一轮生成的数据分布与当前策略已经不同步了拿旧数据训练新模型就像让高中生做小学题效率低下甚至会让策略向旧分布偏移。在线采样让模型始终在“当前能力的边界”上试错这也是为什么GRPO、PPO这类算法在LLM自我提升任务上效果优于简单离线筛选的核心原因。当然在线RL不一定需要纯PPO。很多实现采用“生成一批→打分→更新→再生成”的交替模式只要数据由当前策略产生就能认为是近似在线。对算力比较紧张的小团队我建议先不要追求严格on-policy的实时性用异步采样配合小批量更新也能拿到在线RL的大部分收益。3.4 自我评价到底靠不靠谱验证器与评判模型的边界自我提升里最容易引起争议的一句话是“让模型自己评价自己”。这里面要分清楚可验证的硬信号答案比对、单元测试非常可靠因为它不依赖模型的主观判断而软信号比如让模型评判另一个模型回答的质量就可能引入系统性偏差——评判模型可能更喜欢和自己风格接近的回答更偏好模板化的表达甚至被诱导出“谦逊但空洞”的套话。因此可靠的自我提升设计通常分三层第一层用硬规则验证器把客观对错钉死第二层用较小的、固定版本的评判模型给开放任务打分避免当前模型自己给自己送分第三层用人工抽样审计每轮只看几百条样本纠正评判模型的漂移。所谓LLM as Judge也不是不能用于自我提升关键是它的角色要固定、版本要冻结、结果要抽样审计。奖励信号一旦被污染后面的自我提升闭环会把错误越滚越大。4. 读技术报告时真正值得细看的四张表4.1 实验设置表注意力先放在模型规模、KL系数、采样数量技术报告和论文不同更像一份工程说明书但很多读者只盯着最后的基准分数看。我读这类报告的习惯是先找实验设置表重点看四样东西模型的底座规模和RL继续训练的规模有多大每个Prompt在线采样多少条响应num_return_sequencesKL惩罚系数或参考模型的约束强度训练的总步数和batch size换算一下到底过了多少轮。这四样东西决定了报告的结论适不适用于你自己的场景。如果报告用的是14B以上模型、每Prompt采样64条、训练几十亿token而你手上的算力只能跑7B模型、每Prompt采8条那最后的分数差异主要来自资源投入而不是算法优劣。表格还能帮你判断训练是否充分如果曲线还在上升就停掉了说明报告里的收益可能被低估。4.2 消融表RL开关、在线开关、验证器开关第二张必须看的是消融表。好的消融表会把关键变量逐个关掉把差异摆出来。我最关心三个开关去掉RL只做SFT看强化学习本身贡献多少把在线采样改成离线静态数据看“动态生成”到底值多少钱把可验证奖励换成模型自评看验证器可靠性对最终结果的影响。如果一张消融表显示“去掉在线采样后分数掉了5个点以上”说明报告确实在靠自我提升机制吃饭而不是靠数据堆积如果显示“换掉验证器后分数几乎不变”那奖励设计的门槛就很低复现成本也就低。把这三个开关的对应关系搞清楚比记住最终分数重要得多。4.3 数据配比表自生成数据、原始SFT数据、通用数据的比例第三张是数据配比表。自我提升的陷阱之一是“自我数据越滚越多把底座数据挤没了”。一份严谨的报告会明确列出每个训练阶段用了多少自生成正样本、多少原始指令数据、多少通用语料以及它们在batch里怎么混。我建议你用下面这个小表帮助自己判定数据设计得好不好检查点好的信号危险信号自生成数据占比20%到60%之间有明确任务分组超过70%且没有通用数据补充数据去重有去重和多样性采样直接把筛选结果灌进训练训练轮次有控制避免重复过拟合同一批高分数据反复训练每轮更新比例每次只使用当轮新增数据每轮都混入全量历史数据这个表的依据是RL每次更新都见过所有历史数据模型会把高分路径反复放大很容易收敛到同一种解法牺牲多样性。数据配比上略微保守一点收益其实更稳定。4.4 评测明细表榜单分数之外要看失败案例最后是评测明细表。纯看汇总分数不够要翻到正文或附录里的失败案例分析。我一般关注三类一是模型在训练任务附近的分数是不是高得离谱这可能意味着评测集被污染模型见过类似题二是在分布外的推理任务上有没有泛化这是自我提升含金量的核心三是失败样本里有没有出现“看似专业实则错误”的回答这类错误最能说明奖励函数的漏洞。对工程团队来说评测明细表也是最好的回归测试清单下次你做训练流程改动把这几百个困难样本重新跑一遍比盯着benchmark总分有效得多。我团队就是这么做的——把报告里的困难case收集成一个私有测试集每次升级模型就重跑一遍防止能力回退。5. 落地复现在有限算力下搭建一套Mini版自我提升流程5.1 路线一数学题上的生成→筛选→再训练如果你算力有限数学任务是最合适的起步场地因为答案可以自动核对。第一步准备一个题目池不需要太大几千道难度分层的数学题就够第二步用当前模型对每道题生成8到16条候选答案用字符串匹配或正则核对最终答案纯数值类问题先做简单解析保留答对的样本第三步把这些答对样本混入原来的SFT数据做一轮SFT或DPO。这套流程跑通后你可以逐步做两件事把“只看最终答案”升级成“验证解题过程”引入过程奖励把候选数增加提高发现新正确解法的概率。对大部分初创团队来说这个最小闭环已经能感受到自我提升的甜头。注意不要一上来就要求模型解决它完全不会的难题第一轮目标是稳定住已有能力并提升推理正确率难度曲线太陡会让训练崩掉。5.2 路线二代码任务的单元测试验证器代码任务比数学更接近真实工程。核心做法是准备一个包含题目、测试用例和隐藏测试的代码题库让模型生成答案后直接跑单测测试通过即视为正样本。关键在于要保留“隐藏测试”如果训练时用的测试和评测时用的测试完全相同模型完全可能通过记忆测试用例来“刷分”。我项目里的做法是一个题库拆分训练集、公开测试集、隐藏测试集。训练过程中模型只能看到题目和公开测试最终筛选数据时用隐藏测试把关避免过拟合到测试用例本身。这套流程跑出来的模型比单纯用数学数据训练出来的模型在真实项目里表现更稳因为代码通过编译和运行本身就是一种强验证信号。5.3 路线三DPO/GRPO在偏好对上的快速替代如果不想直接上PPO显存和工程复杂度都高可以从DPO或GRPO入手。它们的共同点是省去了奖励模型和Critic网络直接用偏好对或“当前策略生成样本打分”来更新策略。对于自我提升来说GRPO尤其适合它从同一Prompt采集多条响应用组内相对优势而不是绝对奖励作为学习信号天然兼容“生成多个答案→验证器打分→选优”的流程。GRPO的工程负担比PPO小很多显存占用也更低已经成为很多开源RL框架的主力算法。如果你之前只做过DPO切到GRPO时把KL系数、批次大小稍微调一下就能上手核心注意点是同一个Prompt下的样本数要足够多否则组内比较的方差会很大信号不稳定。5.4 训练主循环伪代码与显存、时长参考下面是我自己在类似Mini项目中反复使用的伪代码框架标注了每一步的核心要点# Mini版自我提升训练主循环伪代码 for rnd in range(total_rounds): prompts sample_prompts(task_pool, num8192) # 从任务池采样 responses model.generate( prompts, num_return_sequences16, # 每条生成16个候选 max_new_tokens1024, temperature0.8, top_p0.95, ) rewards verifier.score(prompts, responses) # 可验证奖励打分 good_idx rewards.accepted() # 筛选正样本 dataset make_rl_dataset( prompts[good_idx], responses[good_idx], rewards[good_idx], sft_datasft_dataset, # 加入通用SFT数据 sft_ratio0.3, # 保留30%打底数据 ) model grpo_train( model, dataset, lr2e-6, kl_coef0.05, update_steps300, ref_modelref_model, # KL约束参考模型 ) report evaluate(model, eval_set, private_cases) save_checkpoint(model, report, tagfround_{rnd})我给的采样数量和训练步数是小规模起步的保守值。如果你手头只有单卡或多卡小集群建议把每轮样本量控制在1万到2万条响应以内单卡A100大约需要若干小时如果用8卡并行、配合vLLM做异步采样一个完整小闭环按天计算是可行的。最关键的是把“生成”和“训练”异步化不要让GPU在采样时闲着。5.5 三条路线怎么挑数学、代码、DPO/GRPO三条路线不是互相排斥的。我的建议分两种情况如果目标是快速验证自我提升机制选数学GRPO复杂度最低如果目标是贴近生产环境选代码单元测试验证器信号更扎实如果现有团队对PPO工程不熟悉先不要碰在线PPO用DPO/GRPO跑通再升级。取舍标准就一句话用你能稳定控制变量的方案拿到正收益再逐步增加工程复杂度。一上来就复刻报告里的全套配置大概率会被工程细节拖垮。6. 最容易翻车的五个坑和我踩过之后的处理方式6.1 奖励黑客模型学会刷分而不是解题第一个坑是奖励黑客。我在一次数学实验中遇到模型输出大量“答案是42”之类的短答案因为验证器只匹配了最终数值它发现只要把常见答案填进去就能拿分。这个问题在RL里极其常见模型优化的是奖励不是人的意图。应对方式是在验证器里加“必须包含有效推导过程”的硬约束代码任务就增加静态检查和复杂度限制如果用模型评判器必须加“关键步骤缺失即记零分”的规则。这类问题的共性特征是训练后期训练集奖励还在涨但人工看样本质量明显下降。所以我在训练过程中安排了固定的“人工抽查”节点每阶段抽100条正样本看一下很多奖励漏洞都是在这种抽查里暴露的。6.2 多样性崩掉N轮之后输出千篇一律第二个坑是多样性崩掉。自我提升跑到第三、四轮模型开始把所有问题都回答成同一个风格模板高分样本里全是模式雷同的“正确写法”。多样性下降的原因主要是同一批高分样本被反复用于训练模型把所有概率都集中到了少数几条路径上。我处理的方式主要有三个在筛选用例时对响应做语义去重相同思路只保留代表性样本每轮从一个新的子集采样Prompt避免永远重复同样的题目训练时KL惩罚不要降得太快给模型保留探索空间。检查多样性的简单办法统计同一Prompt下高分响应的文本相似度如果相似度一直超过0.9就该暂停训练、调数据配比了。多样性才是后续自我提升的燃料没有多样性下一轮就没有“新东西”可供学习。6.3 训练震荡loss曲线看起来还行但生成质量忽高忽低第三个坑是训练震荡。RL训练中经常出现Loss稳定下降但评测分数忽高忽低、生成质量时好时坏的情况。这背后通常是batch size太小导致梯度噪声大或者采样和训练并行动作导致了数据分布不匹配。我建议处理时先看梯度范数如果梯度范数剧烈跳动就把batch放大、学习率调低如果波动来自数据分布就确认采样器与训练器之间有没有卡在旧策略数据上。从经验上看训练状态不稳定的时候优先“稳”而不是“快”降低学习率、加大batch、延长中间评测间隔。RL训练最怕的是错误的自信——看到几个高样本就觉得模型已经变好结果下一步开始退化。我会保留每个round的checkpoint方便快速回滚。6.4 自评污染验证器被当前模型的风格带偏第四个坑是自评污染。当你用模型评判器给开放任务打分时评判模型如果和训练模型是同一个底座它会越来越偏好当前模型的风格导致训练进入一种“自我同意”的循环。因为这个原因我在项目里专门固定一个旧的评判模型版本不随训练更新并且给评判结果加了规则约束层先按关键词和结构过滤一遍再让评判模型打分。更保险的方案是使用外部可验证信号为主、自评为辅。如果任务本身没有标准答案那就尽量设计成多选题或“有多个可接受的答案集合”把主观判断范围压缩到最小。自评只能作为补充不能作为主干否则报告里再漂亮的收益落地时也会发虚。6.5 原能力遗忘RL一轮做完通用对话能力倒退最后一个坑是原能力遗忘。RL训练目标单一模型会集中所有容量去优化目标能力漂亮的推理和代码能力上去了但通用对话、知识问答、礼貌表达等能力可能明显退步。我经历过最典型的案例是训练完数学RL模型后模型对所有非数学问题都倾向于用“逐步推理”的口吻回答反而变啰嗦了。解决办法是混合训练数据每轮RL更新时固定混入20%到30%通用SFT对话数据帮助模型保持原有能力。还有一个周边手段是限制KL惩罚的上限让模型与参考模型不要偏离太远。如果报告里有“能力保持”相关的评测表最好重点看——它比什么都重要因为一个只会刷榜单的模型在实际交付中反而是倒退。7. 报告之外我最想按顺序做的小实验很多时候MiMo-V2.6这类报告容易被当成“别人的刷分秘籍”看完记几个数字就结束了。我的体会是它真正的价值在于提供了一个端到端的“模型自我进化”样板任务池怎么设计奖励怎么界定样本在线生成到什么密度迭代到第几轮该收手。这些步骤未必都能在你的算力上完全复刻但可以拆成一个个小实验去验证。如果你现在只够跑一个最小实验我建议从数学题GRPO开始把“生成→筛选→训练→评测”的最小闭环跑通。跑通了你会对奖励设计、数据多样性、KL约束这些抽象概念有非常直观的认识没有跑通过之前看多少技术报告都只是纸上谈兵。等这个闭环成熟了再把任务池扩到代码、开放推理把验证器从硬规则升级成混合信号慢慢找到适合自己的RL扩展节奏。技术报告可以给出方向但最终能跑出什么效果还是取决于你手里掌握的反馈信号质量以及你在前面那些坑上花的调试功夫。这一步没有捷径但确实值得。