RP-OPSD 这套方法看起来是冲着多语言推理迁移中的一个老大难问题去的模型在英语上推理很强一换成中文、印地语、泰语或者斯瓦希里语性能就明显衰减。Reasoning-Pivot-Guided On-Policy Self-Distillation简单说就是用高资源语言先产生一个“推理枢轴”再让模型从自己的在线采样里做自蒸馏把推理模式跨语言搬过去。如果你正在做多语言大模型微调、推理蒸馏或者需要在低资源语言上保持复杂推理能力这篇内容值得往下看。我会先拆解方法设计再按实际落地顺序讲怎么准备数据、怎么跑训练循环、怎么判断结果最后给一套排查思路。1. 先弄清楚多语言推理迁移为什么难1.1 多语言模型有“语言鸿沟”多语言模型并不是天然把所有语言映射到同一个推理空间。很多人在测评时发现同一个模型用英文做数学题和逻辑题表现不错换成母语或低资源语言后准确率可能会掉十几个点。更奇怪的是模型可能不是不会这个能力而是不知道该用什么语言去启动推理。也就是说知识是共享的但“如何调用推理过程”是跟着语言走的。这种语言鸿沟通常表现为三种情况输入语言变了模型的激活模式跟着变导致推理步骤被打断。输出语言受限模型被迫用低资源语言生成中间推理时表达不流畅错误累积。监督信号不平衡低资源语言上高质量推理样本很少模型没有机会学到完整的推理路径。我在实际跑多语言训练任务时最明显的感觉是增加语料并不一定增加推理能力。模型可能学会了很多语言碎片但遇到需要多步推理的题目依然会在第二步、第三步“断掉”。这时候需要的不是更多数据而是把推理过程本身变成一种可以跨语言传递的中间表示。很多人误以为只要扩大词表和多语言预训练就能解决。实际上模型在预训练阶段可能已经看过足够多的多语言文本知识层面并不缺缺的是把“知识”转化为“多步推理行动”的稳定路径。语言切换之后这条路径被掐断了。所以多语言推理迁移本质上不是语料问题而是训练目标问题。1.2 传统蒸馏和微调的局限常规做法有两种。第一种是直接微调低资源语言。比如用低资源语言的少量带推理标注数据继续训练。问题是低资源语言样本少模型很容易过拟合而且如果只训练答案不训练推理步骤模型学到的只是机械查表。我见过不少项目这样做之后测试集上准确率看起来不错但换一批新题表现立刻掉下去因为模型根本没有形成真正的推理链。第二种是离线蒸馏。先用一个教师模型生成大量英文推理链再翻译成目标语言用学生模型去模仿。这种方式的问题是教师模型生成的推理链和当前学生模型的能力不匹配。学生模型真实环境中的错误类型、表达方式、中间步骤偏好离线数据根本没有覆盖。我见过不少项目这样做了之后loss降得很低但实际评测效果一般因为模型只是在拟合翻译后的文本而不是在学推理行为。更隐蔽的问题是离线蒸馏很容易让模型学会“翻译”而不是学会“推理”。比如教师模型用英文生成了“Let x be the number of apples. Set up equation: x 5 12.”翻译成中文后学生模型可能学会写出对应中文但它并没有理解“设未知数”与“列方程”之间的逻辑关系。当题目变为完全不同的场景时它就失灵了。1.3 RP-OPSD 的核心思路把推理过程变成可迁移的中间表示从命名看Reasoning-Pivot-Guided 表示它会先指定一个推理枢轴语言通常是数据充足、推理能力最好的语言比如英语。训练时模型先尝试输出一个基于枢轴语言的推理骨架再把这个推理骨架转换成目标语言或者用这个骨架指导目标语言的生成。这里的关键是pivot 不是最终答案而是推理过程的中转表示。On-Policy Self-Distillation 则解决数据匹配问题。它不用固定教师提前生成数据而是让当前训练中的模型自己采样推理路径再把路径中的关键步骤作为学习目标。这种在线方式让训练数据始终匹配模型当前的能力边界所以更像“边做边学”。把两者组合起来就是先用高资源语言确定“这段推理应该怎么走”再让模型自己生成并蒸馏这些路径从而把推理能力迁移到低资源语言。训练信号不再是翻译后的文本而是一组“推理枢轴 当前策略采样”的混合信号。这套思路最大的价值是它把“推理”和“语言表达”拆开处理了。推理逻辑写在 pivot 里语言表达在目标语言侧训练时两边同时对齐而不是把两种问题搅在一起。2. 拆解两个关键机制2.1 Reasoning-Pivot给推理过程一个“锚点”Reasoning-Pivot 可以理解为一个推理骨架。假设我们有一个中文数学题模型用中文直接推理容易出错那么训练时让模型先在英文枢轴空间里生成类似“Step 1: Let x be the unknown. Step 2: Translate the problem into equation. Step 3: Solve…”然后再把对应信息映射回中文作答。这个英文推理骨架就是 pivot。它本质上是一种中间监督。好处是高资源语言的推理步骤更稳定不容易因为表达问题出错。同一个推理骨架可以对应多个目标语言减少低资源语言样本不足的压力。训练时可以把“推理逻辑”和“语言表达”分开学习。但要注意pivot 语言选择不能太随意。我一般建议优先选训练语料最多、并且模型本身推理准确率最高的语言。常见选择是英语但如果你是做中日韩场景也许英语仍然合适如果你发现模型在某种语言上推理能力明显更强也可以换。不要机械地认为“英语永远是最好枢轴”。pivot 并不是越长越好。我见过有的实验把 pivot 写成了完整的小作文模型光是复述都吃力更别说迁移。合理的 pivot 应该是一组可操作的步骤指令而不是对题干的复述。2.2 On-Policy Self-Distillation让模型从自己的采样中学Self-Distillation 不是新概念但“On-Policy”很关键。简单说训练的每一步用当前模型生成一批推理样本这些样本包括正确和错误路径。然后让模型学习这些路径中的潜在推理模式。它不同于使用固定教师模型输出因为固定教师和当前学生之间存在“能力差”。为什么在线策略自蒸馏更适合低资源推理迁移因为模型在目标语言上当前的薄弱点会实时暴露在采样里训练信号更有针对性。学生模型自己生成的文本在分布上更接近推理阶段的真实输入避免“教师输出风格”带来的分布偏移。可以不断产生新样本解决低资源语言标注不足的问题。不过这种“自己教自己”的方式如果处理不好会放大错误。所以需要引入一些过滤或加权机制例如对采样路径按最终答案正确性、自我一致性或逻辑完整性进行筛选。错误样本不是完全不用而是可以作为一种负样本信号。这个细节直接决定蒸馏效果。我在实际操作中会先做一轮“样本体检”让当前模型在验证集上生成若干路径人工看几十条确认哪些路径是“答案错了但推理过程完整”哪些是“答案对了但推理过程跳步”。这两类样本在蒸馏里的处理方式完全不同。2.3 两个机制为什么能组合“先定锚点再同策略校正”Reasoning-Pivot 和 On-Policy Self-Distillation 其实是互补的。pivot 负责解决“迁移什么”在线自蒸馏负责解决“怎么让模型真正学会”。训练过程中的典型逻辑是用高资源语言生成一个推理枢轴。用当前模型在目标语言上尝试顺着枢轴生成推理。对比目标语言生成结果与枢轴之间的逻辑一致性。根据一致性计算蒸馏损失同时更新模型。下一步重新采样重复这个过程。这样模型每走一步都能看到自己当前的能力边界同时又被枢轴不断校正。如果只保留 pivot不做在线自蒸馏模型可能只会复述翻译后的模板如果只保留在线自蒸馏缺少 pivot低资源语言推理路径容易漂移。两者结合才形成“锚定 校正”的闭环。从工程视角看这个闭环并不复杂但需要训练框架支持“采样、打分、蒸馏”三个操作同时发生。很多微调框架只支持标准前向和反向需要额外加采样逻辑。这里不要想着复用现成 SFT 代码直接跑要提前设计好数据流。3. 想复现这套思路从环境到训练的落地流程3.1 环境准备建议这里给的是通用建议实际以你的环境为准。硬件方面如果你要跑一个 7B 或 13B 规模的多语言模型至少需要一块 24G 以上显存的 GPU如果只有 16G也可以考虑 LoRA 等参数高效微调方式。RP-OPSD 因为涉及在线采样和自蒸馏训练的显存开销通常会比普通监督微调高一些因为每个 step 除了前向传播还要额外采样生成推理路径。如果显存吃紧可以先从一个小模型如 3B、7B验证方法不要一上来就跑大模型。软件方面建议使用 PyTorch 和 Transformers 或你熟悉的训练框架配合 DeepSpeed 或 Accelerate 做分布式训练。在线采样通常会频繁调用生成接口这一步会成为瓶颈。所以如果是多卡环境需要确保数据并行和生成并行能分开调度。我个人的建议是先不要直接复现完整流程而是写一个 Mini 训练循环用很小的数据集验证“当前模型能够根据 pivot 生成目标语言推理”。这个环节能帮忙排除很多环境问题。否则你很可能把时间花在“显存不足”和“生成卡住”上而不是方法本身。3.2 数据格式和处理在 RP-OPSD 思路下训练样本至少需要四部分输入问题目标语言推理枢轴通常用高资源语言表达目标回答或推理步骤目标语言可选的答案标签或评分信号数据构造可以按这个流程收集多语言推理题例如数学、逻辑、科学问答。用高资源语言模型或规则生成英文/枢轴语言的推理链。对推理链做质量和一致性过滤保留步骤完整、答案正确的样本。用当前模型采样目标语言推理路径。将采样路径与枢轴路径做对齐构建蒸馏训练对。这里要注意如果你没有现成的高质量推理链可以用一个较强的教师模型生成但不要把它当成“官方最终数据”后面还要配合在线自蒸馏不断更新。数据文件建议保存成 JSONL 格式每一行一个样本至少包含{ source: zh, question: 一个水箱的容积是120升已经注入了75升还需要注入多少升, pivot: Step 1: Identify capacity and current volume. Step 2: Subtract current from capacity., target_reasoning: 第一步读取容量120升。第二步已经注入75升。第三步120-7545升。, answer: 45升 }这个格式写出来是为了让你先看到样本长什么样。实际项目里pivot 可以是更短的引导式文本也可以是结构化的推理步骤列表。关键是要保证“pivot 和 target_reasoning”在逻辑上对齐而不是各自独立。否则蒸馏时模型会学到两套不一致的模式。3.3 训练循环示意在没有官方代码的情况下这里只给一个伪代码示意说明训练循环需要哪些环节for batch in train_dataloader: # 1. 用当前模型对目标语言问题采样推理路径 sampled_paths model.sample_reasoning(batch[question], langbatch[source]) # 2. 根据 pivot 和 answer 给采样路径打分/过滤 filtered_paths filter_by_quality(sampled_paths, batch[pivot], batch[answer]) # 3. 计算蒸馏损失让模型输出对齐 pivot 逻辑 目标语言表达 loss distill_loss(model_output, target_reasoning, pivot_logits) # 4. 反向传播更新模型 loss.backward() optimizer.step() scheduler.step()这里有几个容易出错的位置采样时不要关闭梯度但要控制生成长度和批大小否则显存会爆。loss 不只有一个通常包含“答案正确性”的监督损失和“推理路径一致性”的蒸馏损失。两者要加权。在线采样需要做缓存或定期更新不要每个 step 都重新生成超大 batch这样训练会非常慢。我一般会先用固定教师模型生成一批初版 pivot 数据把训练循环跑通之后再把在线采样打开。这样如果出问题至少能定位到是采样环节还是训练环节。直接一步到位开在线采样报错时很难判断是谁的问题。3.4 关键超参数和判断标准我在做类似训练时会重点盯这组参数参数常见范围示例作用太大/太小的表现蒸馏温度 Temperature0.5 到 2.0控制分布平滑度太大输出分散太小容易塌缩蒸馏损失权重 lambda0.1 到 0.5控制在线蒸馏强度太大会忽略真实标注太小迁移效果弱采样数量 num_samples1 到 8控制自蒸馏覆盖度太多训练慢太少不稳定学习率与微调基线一致或更低控制更新步长太高 loss 抖动大太低训练过慢最大生成长度128 到 512控制推理链长度太短推理不完整太长占用资源怎么判断参数是否合适的标准训练开始时loss 应该缓慢下降而不是瞬间变成很小。每隔一定的训练步数要单独跑一个评估集看目标语言推理准确率不能只看训练 loss。采样文本应该包含合理的中间步骤而不是直接输出答案或反复重复同一句话。如果你发现训练 loss 一直下降但评估准确率不动很可能是蒸馏信号太强模型学会了模仿 pivot 的表面文本但没有真正学会推理。这时候要适当降低蒸馏权重或增加目标语言的真实监督信号。4. 多语言任务怎么设计才像“迁移”而不是“混训”4.1 语言划分和 pivot 语言选择很多人在做多语言训练时直接把所有语言样本混在一起导致模型只是记住各个语言的碎片没有形成跨语言推理能力。RP-OPSD 的思路更强调语言角色分离一部分语言作为 pivot负责提供稳定的推理骨架其他语言作为目标语言负责学习如何把骨架落地到本地表达。语言划分我建议按“数据量和模型能力”两个维度数据量最大、推理准确率最高的语言选为 pivot。其他语言按资源多少分成“低资源目标语言”和“中资源目标语言”。同一批次里不要所有样本都来自低资源语言要混入 pivot 语言样本保持模型对 pivot 的敏感度。例如你做一个高资源英语、低资源印地语/泰语/斯瓦希里语的多语言模型可以把英语作为 pivot每次训练都同时采样英语推理样本和一种低资源语言样本。模型既能在英语上稳定生成推理骨架也能在低资源语言上尝试套用同一套骨架。这里有个容易犯的错把 pivot 语言样本直接混进训练集但没有显式标记“这是 pivot”。结果模型只知道要输出某种语言不知道要先把推理过程抽象成可迁移的骨架。训练时要通过 prompt 或 loss 结构让模型能理解“先产生 pivot再生成目标语言”。4.2 数据配比与评估集设计数据配比方面不要按语言人口比例来而要看推理任务难度和样本质量。低资源语言虽然有少量样本但推理题通常更难所以可以给低资源语言更高的采样权重但不能太高到让模型忘记 pivot 语言。一个比较稳的做法是先按 1:3 到 1:5 设置低资源语言样本:pivot语言样本然后根据评估集表现调整。评估集设计比训练集更重要。我一般会准备三组测试同语言测试例如训练时见过中文推理题测试时用新中文题看基本能力有没有保住。跨语言测试训练用中文和英文测试用从未出现的泰语或印地语题看迁移是否真的发生。翻译回 pivot 测试把目标语言问题翻译成英文看模型在英文上的推理能力有没有下降。如果第三个测试下降很厉害说明训练过程牺牲了 pivot 语言。这种情况在自蒸馏中很常见需要减少蒸馏损失或者在 loss 里加一个 pivot 语言回归项。另外评估集不要只选容易题。多语言推理迁移如果只在一两步推理题上测试很难看出方法差异。至少要包含 3 步以上推理题并且问题场景要多样否则模型可能靠关键词匹配就能答对。4.3 结果验证不能只看准确率我在实际评估时会先记录三个指标答案准确率最终答案是否正确。推理步骤完整性中间有没有“设未知数”“列方程”“逐步计算”这样的逻辑动作。语言保持度目标语言的表达是否自然是否夹杂过多 pivot 语言碎片。如果你发现模型答案对了但推理过程完全用英文输出而目标是要求中文推理那说明迁移没有完成只是套了一个翻译壳。更合理的验证方式是要求模型用目标语言生成完整推理链同时对推理链做关键步骤的语义比对比如检查第一步是否提到了“容量”第二步是否涉及“减法”。这里有一个比较实用的做法把模型生成的目标语言推理链翻译成 pivot 语言再和原始 pivot 做相似度对比。如果相似度高说明模型真的学会了“按骨架推理”如果像散文一样自由发挥说明蒸馏信号没有起作用。5. 训练不稳定、输出崩了优先排查这几条链路5.1 先看 loss 曲线哪一段开始异常遇到训练不稳定先不要怀疑模型结构把 loss 曲线拉出来看三个位置最开始几步是不是 loss 直接变成 NaN 或特别大。如果是大概率是学习率太高、数值不稳定或者数据里有异常值。训练中期 loss 突然抬升。这种情况常见于在线采样生成了一条特别长的坏路径导致这步梯度异常。loss 缓慢下降但没有收敛。这种情况要看蒸馏损失和真实监督损失的权重是否平衡。如果训练日志里每步的生成文本都能保存下来赶紧回去看异常 step 的采样结果。很多所谓的“训练崩溃”其实只是某条采样路径太差把 loss 拉爆了。解决办法不是降低学习率而是对采样路径做长度和词数限制或者把异常样本过滤掉。我习惯在训练脚本里加一个“采样样本落盘”开关每隔几十步把当前 batch 的生成结果存成 JSONL。这样一旦出问题可以直接查看模型在崩溃前到底生成了什么。5.2 排查数据、路径、模型保存和日志在线自蒸馏有一个很隐蔽的错误训练数据里 pivot 字段是空的或者 target_reasoning 是翻译后的文本而非模型真实推理。这种情况模型很容易学到“短平快”的答案模式。我的排查顺序通常是检查数据加载器确认每个 batch 里 pivot 字段、target 字段都非空。检查采样函数确认生成时使用的是当前模型而不是加载了旧的 checkpoint。检查保存目录和日志确认每个 step 的 loss 记录、采样文本输出都正确落盘不然你无法追溯。检查 tokenizer多语言场景经常出现某个低资源语言的 token 被 tokenizer 切成很多碎片导致生成质量下降。这时候需要对比不同语言的平均 token 长度。如果模型生成的内容是空的先别怀疑模型有问题。先去看输入 token 是不是被截断了再看最长生成长度是不是设置得太短。很多“输出为空”的 case其实是 max_new_tokens 设成了十几模型刚写完几个词就触发停止。5.3 参数边界温度、权重、学习率先别一起改很多人一看到效果不好就同时调 temperature、lambda、学习率、batch size结果根本不知道是哪个参数起的作用。我的习惯是每次只改一个变量并且先在小评估集上比较。举个例子第一次实验固定 temperature1.0lambda0.1学习率1e-5。第二次实验只把 lambda 调到 0.3。第三次实验温度调到 1.5。这样对比起来至少能知道哪个因素影响更大。一般来说温度适合调高一点让采样路径更丰富但是太高会导致生成文本发散。lambda 适合从小到大慢慢加太低迁移效果不够太高模型会变得“只学 pivot、不学目标语言”。学习率不要一开始就拉满尤其是在线采样和蒸馏混合训练学习率往往要比普通微调低一个数量级。我还遇到过一种情况模型在训练集上 loss 正常但评估集准确率始终不高。后来发现是评估集里混了很多和训练集相同来源的题模型靠记忆就答对了换一批新题立刻露馅。所以在多语言推理迁移里评估集的新颖度比训练集大小更重要。6. 适用边界与接下来的优化空间6.1 这套方法适合什么场景不适合什么场景RP-OPSD 这类思路最适合的场景是你有一定量的高资源语言推理数据也有少量低资源语言推理数据但低资源语言数据不足以让模型独立学会多步推理。典型例子包括多语言数学题库、多语言法律问答、低资源语言的知识推理任务。它不太适合的场景也包括几个完全没有任何标注的低资源语言推理数据。如果不给 pivot 和答案单纯在线自蒸馏很难无中生有。推理任务本身要求极强的领域知识而低资源语言语料里根本没有相关概念。这时先要补语料而不是单纯调训练方法。对延迟要求极高的在线推理场景。因为训练过程多次采样会显著增加成本但推理阶段不一定增加复杂度。如果你只是想在单语场景下提升模型推理能力这套方法大概率是绕远路。它真正的收益来自“一套推理骨架多种语言表达”的跨语言复用。6.2 与常见蒸馏方案的对比如果你正在做技术选型可以按这个表格快速判断方案数据来源稳定性对低资源语言适配成本固定教师离线蒸馏教师预生成稳定但容易脱离学生能力依赖翻译质量中等直接多语言 SFT混合语料标注稳定但容易过拟合低资源语言需要大量低资源标注低RP-OPSD 思路在线采样枢轴引导需要调参但有针对性能利用高资源推理骨架较高这里列的不是官方测评而是我基于常见实验经验的判断。如果你的项目重点是“低资源语言上真的有推理能力提升”RP-OPSD 值得试如果项目重点是“让所有语言都平均兼顾”那直接多语言 SFT 可能更省事。需要说明的是RP-OPSD 的成本压力主要在训练阶段。因为每个 step 都要采样、过滤、蒸馏比普通 SFT 慢不少。如果时间预算有限可以先离线生成一批高质量 pivot 样本再用一个较小的采样预算跑在线自蒸馏这样能折中。6.3 可以继续尝试的改进方向如果你已经跑通基础版本后续可以从这几个方向做扩展把 pivot 从单一语言改成多语言混合 pivot例如同时用英文和另外一门高资源语言生成推理骨架再投票选择一致路径。在在线采样时加入自我一致性过滤只保留多次采样中指向同一答案的路径提高训练信号质量。适配参数高效微调例如用 LoRA 训练先验证方法效果再决定是否全量微调。扩展成多语言 Agent 场景让模型不只要输出推理链还要调用工具或搜索这时 pivot 可以变成“计划骨架”在线自蒸馏的覆盖面会更广。我自己如果从头做这个方向会优先把基础 pivot 和在线采样这步跑稳而不是过早追求花哨的加权策略。只有当前模型产生的采样路径确实可以稳定对齐到 pivot 上后面加过滤、加一致性评价才有效。多语言推理迁移是一个容易“看起来有效、实际没迁移”的方向。RP-OPSD 至少提供了一种更贴近模型真实状态的训练路径先定义推理锚点再让模型从自己的行为中学习。如果你正准备在低资源语言上做推理能力增强不妨从小模型、小数据集开始把训练循环里的采样、过滤、蒸馏、评估四个环节拆开来验证再逐步扩展到真实规模。