当我把一个开源大模型从英文切到泰语时最明显的感受不是“答案变少了”而是模型开始拒绝推理。它不再尝试一步一步思考而是直接给一个简短结论甚至把问题重新拼一遍就交差。这不是偶发而是多语言推理迁移里的常态高资源语言上的推理能力很难自动平移到低资源语言。于是越来越多工作开始把目光投向一个方向能不能不只用答案做蒸馏而是把推理路径本身也搬过去。今天想聊的这篇工作标题叫RP-OPSD: Reasoning-Pivot-Guided On-Policy Self-Distillation for Multilingual Reasoning Transfer。它至少揭示了一个关键判断多语言推理迁移的核心问题不是词汇表的对齐而是推理路径的对齐。相比传统“教师生成答案学生模仿答案”的做法RP-OPSD 更强调用推理过程作为“枢轴”并结合在策略自蒸馏让模型在目标语言上自己生成推理链再把它拉回正确的结构。这个思路值得展开聊。1. 多语言推理迁移的真正难点不是词汇翻译而是推理路径迁移1.1 为什么答案蒸馏经常失效很多人一开始接触多语言推理迁移第一反应是“把英文的思维链数据翻译成目标语言然后拿去微调”。这个做法不是不行而是瓶颈很明显翻译会引入噪声而且翻译后的思维链往往不是目标语言母语者会使用的表达方式。更关键的是模型从答案级蒸馏里学到的只是一种“结果模仿”没有真正学会如何在新语言里组织推理步骤。举个例子一个英文问题带有完整的思维链Q: 如果一件商品打八折后是 80 元原价是多少 A: 打八折表示现价是原价的 80%所以原价 80 / 0.8 100 元。直接翻译成泰语模型可以背下来。但遇到一个类似的泰语问题商品换成“运费”或者“折扣率”变了模型未必能把“设未知数-建立等式-解方程”这组推理结构迁移过去。因为它在训练时看到的是一段翻译文本而不是一个“可复用的推理范式”。答案蒸馏失效的深层原因是它把“推理”压缩成了一个点。一个点无法承载过程信息模型只能记住输入到输出的映射关系却无法理解中间那些关键决策发生在哪里。这也是为什么在很多低资源语言上微调后的模型准确率看起来还可以一旦需要多步推理就崩盘。1.2 推理路径才是迁移的载体有一个更符合直觉的类比不同语言就像不同材质的门板而推理路径是那根贯穿所有门板的轴。中文、英文、泰语、斯瓦希里语的门板外观可以完全不同但只要它们绕着同一根轴转开合逻辑就是一致的。多语言推理迁移要搬的不是门板上的花纹而是那根轴。所谓“推理路径”不只是一句句自然语言的思考过程还包括中间步骤之间的依赖关系。比如“先求比例再求整体”“先列出已知条件再选择公式”“遇到矛盾时回到上一步重算”——这些结构在语言之间是可迁移的。RP-OPSD 里的 Reasoning-Pivot本质上就是想把这类结构单独抽出来作为一个对齐锚点。这就引出了方法层面的问题如果推理路径是迁移的载体那怎么让模型在目标语言上也生成这条路径答案往往不是外部翻译而是让模型在目标语言上自己生成推理链再通过蒸馏信号把它拉向高质量结构。这正是标题里“On-Policy Self-Distillation”要做的事情。2. 拆解 RP-OPSD三个关键词背后的设计逻辑2.1 Reasoning-Pivot把推理链当作对齐的轴“Pivot”在数据处理里经常被理解为“枢轴”或“桥接项”。在机器翻译里有的方法会用英语作为 pivot 语言把低资源语言先翻译成英语再翻译成目标语言。但这里的 Reasoning-Pivot 不是拿语言做桥而是拿推理步骤做桥。用更工程化的语言说推理步骤可以看作一组中间状态。给定输入问题x模型输出推理链r [s1, s2, ..., sn]最后得到答案a。传统蒸馏只对齐(x, a)而 Reasoning-Pivot 的思路是让不同语言下的r在某种表示空间里尽量靠近或至少在结构上保持一致。具体怎么实现原论文没有在标题里展开但常见的做法有几种让模型在源语言和目标语言上分别生成推理链再计算语义相似度作为奖励信号把推理链的关键步骤抽取成伪代码、结构化标签或中间结论再作为训练目标的一部分用对比学习把同义推理链在表示空间里拉近把不同语义的推理链推开。不管哪种实现核心都是同一个把“推理过程”显式地变成优化目标而不是只盯最终答案。这个转化是整个方法成立的基础也是它和普通蒸馏最明显的差异。2.2 On-Policy Self-Distillation让模型“边做边学”On-Policy 这个词来自强化学习意思是“用当前策略去采样数据然后用这些数据更新当前策略”。放在蒸馏场景里它和 Off-Policy 的差别很关键。典型的教师-学生蒸馏是 Off-Policy 性质的教师模型根据教师自己的参数生成数据学生模型去学习这些静态数据。问题是教师生成的数据分布和学生当前的能力分布可能差得很远。学生可能还没有能力输出教师那样的长推理链强行拟合只会让训练不稳定。On-Policy Self-Distillation 则不同。它不再依赖一个固定教师而是让模型自己采样推理路径再用某种“更好”的参考标准来校准。这个参考标准可以是模型在源语言高资源语言上生成的推理链从验证集中抽取的优质推理链模型历史版本中表现更好的输出经过规则筛选后的高置信度推理链。这样一来学生拿到的训练样本和它当前的生成能力处于同一个分布训练目标不是“一步跳到教师水平”而是“从当前位置逐步改进”。这个思路在强化学习里很成熟用在自蒸馏里可以解决分布失配问题。Self 的意思是模型既是采样者也是学习者。它不需要一个外部大模型来当老师这在地域受限、算力受限或模型需要保密的环境里尤其有落地价值。因为自己生成、自己校准天然避开了“教师模型不可用”的依赖。2.3 Multilingual Transfer从高资源语言到低资源语言的桥梁把前面两块拼起来多语言推理迁移就变得清晰了。源语言比如英文或中文上模型已经具备相对强的推理能力。我们希望把这种能力搬到目标语言比如泰语、斯瓦希里语、印地语上。传统路线是把源语言思维链翻译成目标语言用翻译后的数据进行监督微调期望模型在目标语言上学会推理。RP-OPSD 的路线更像是让模型在目标语言上尝试生成推理链利用源语言或监督数据中的推理枢轴来判断这条推理链对不对通过自蒸馏信号调整目标语言上的推理分布反复迭代直到模型在目标语言上也能产生结构合理的推理路径。这个做法的好处是目标语言始终是“原生”的模型不是在被翻译文本绑架。坏处也很明显它要求模型已经具备一定的目标语言能力否则第一步就生成不出像样的推理链。所以这个方法更适用于“有一定多语言基础但推理能力不足”的模型而不是完全没见过目标语言的模型。3. 一个可参考的训练流程先想清楚再写代码3.1 数据准备问题、语言对和参考推理在看代码之前先把数据准备好。RP-OPSD 通常需要三类数据源语言问题最好带高质量推理链和答案目标语言问题至少需要问题和答案推理链可以没有如果能拿到少量目标语言的人工推理链哪怕只有几百条也会对质量筛选帮助很大。数据格式可以做成这样{ source_question: If a shirt costs $80 after a 20% discount, what was the original price?, source_reasoning: Let the original price be X. After 20% discount, the price is 80% of X, so 0.8*X 80. Therefore X 100., source_answer: 100, target_question: 如果一件衬衫打八折后售价为80元原价是多少, target_answer: 100 }如果你的目标语言没有原生问题可以先用翻译工具把问题翻译过去但推理链不要直接翻译。因为翻译后的推理链往往表达方式僵硬反而干扰模型学习。3.2 推理路径生成与筛选这一步是整个流程里最容易被低估的部分。很多实验跑完发现效果不好回头看都是因为模型在目标语言上生成的推理链太乱根本没有可用信息。实际操作时我会用以下筛选规则推理链末尾的答案必须和标准答案一致推理链至少要包含两个步骤不能直接给结论推理链中不能出现大段的重复文本或乱码如果目标语言是低资源语言可以用源语言推理链的语义相似度作为辅助过滤条件。这一步的目的是拿到“可信推理链”而不是“所有推理链”。宁可少不可脏。On-Policy 方法对样本质量非常敏感脏样本会把整个蒸馏过程带偏。3.3 蒸馏目标设置一段通用示例因为 RP-OPSD 的具体损失函数需要看原论文这里给一个符合标题语义的通用示例流程。实现思路是模型在目标语言上通过采样生成推理链然后让这些推理链向参考推理枢轴靠近。# 通用示例多语言推理自蒸馏训练伪代码 # 仅用于说明方法流程不是原论文实现 for batch in dataloader: # 1. 让当前模型在目标语言上生成推理链 target_inputs tokenize(batch[target_question]) sampled_reasoning model.generate( target_inputs, num_return_sequences4, # 多次采样 temperature0.7, max_new_tokens256, ) # 2. 筛选答案正确且结构合理的推理链 valid_reasonings filter_by_answer_and_length( sampled_reasoning, batch[target_answer] ) # 3. 用参考推理枢轴比如源语言推理链计算对齐信号 pivot_embeddings encode(batch[source_reasoning]) candidate_embeddings encode(valid_reasonings) alignment_loss contrastive_loss(candidate_embeddings, pivot_embeddings) # 4. 同时保留在目标语言上的语言建模损失 lm_loss cross_entropy(valid_reasonings, target_inputs) # 5. 更新模型 total_loss lm_loss lambda * alignment_loss total_loss.backward()这段代码里的contrastive_loss只是说明一种可能实际可以用 KL 散度、序列奖励、排序损失等替代。重点在于训练信号不只来自答案还来自推理链和枢轴之间的结构关系。3.4 评估不能只看准确率多语言推理迁移有一个很常见的假象准确率上去了但推理质量没上去。原因很简单模型可能在目标语言上靠记忆或模式匹配猜对了答案并没有真正生成推理步骤。评估时要分两层看第一层答案准确率这个必须看第二层推理链有效性包括是否有中间步骤、中间步骤是否自洽、是否能推广到变体问题。我自己会额外做一个小型泛化测试把目标语言问题里的数值、人名、场景替换掉看模型还能不能保持正确的推理结构。如果一换数字就崩说明模型学到的只是答案模板而不是推理路径。这是判断 RP-OPSD 类方法是否有效的关键测试。4. 实际落地中的工程直觉与常见坑点4.1 推理枢轴的质量直接决定迁移效果Reasoning-Pivot 这个“枢轴”是方法的名字来源也是整个方法里最需要打磨的部分。如果枢轴本身就是脏的、弱的那后面所有对齐都是空转。我见过一个常见错误用机器翻译的源语言推理链作为枢轴。这些推理链可能语法正确但推理逻辑却因为翻译误差而变形。比如“因为商品价格下降所以利润提高”这类常识错误在自动翻译结果里并不少见。以这种推理链为 pivot模型学到的“正确结构”本身就是错的。建议是在构造枢轴时至少要有一次人工抽检。抽检比例不需要高几百条就够重点看推理步骤之间的因果关系是否成立。如果枢轴里的推理步骤只是“与问题相关”而不是“能推导出答案”那它就不适合做 pivot。4.2 在策略采样的计算开销和随机噪声自蒸馏听起来比外部教师蒸馏省资源但实际上并不便宜。每次迭代都要让模型生成多条推理链再对候选做筛选和编码。如果模型足够大采样几十万条推理链的成本会非常可观。更麻烦的是采样噪声。同一个问题模型在目标语言上可能生成三种完全不同的推理路径其中只有一种是对的。盲目把噪声样本加入到训练里会让模型对推理结构的建模变得更混乱。处理方法有两种思路提高筛选阈值只在高置信度样本上计算蒸馏损失引入确定性解码如束搜索作为补充但这样会降低路径多样性需要权衡。从经验看先跑小批量实验观察生成推理链的多样性是否合理再决定采样参数比一上来就大规模采样更稳妥。4.3 什么时候该停过度蒸馏与能力遗忘On-Policy Self-Distillation 有一个很隐蔽的风险模型反复用自己的输出校准如果初始能力不足可能会把自己锁在一个局部最优里。更常见的现象是模型在目标语言上的推理变好了但在源语言上的通用能力却下降了。这就是灾难性遗忘的一个变体。很多人在训练后只测目标语言忽略了源语言任务。等到上线时才发现中英文能力已经退化到不可用。应对办法在训练混合数据中保留一部分源语言通用样本每个训练轮次后同时评估源语言和目标语言指标如果源语言指标下降超过阈值降低蒸馏损失权重。停下来不是看训练 loss而是看目标语言与源语言的能力差。这个差越小迁移越成功。4.4 一个排查链路如果训练后效果不理想可以按这个顺序定位问题先看目标语言生成结果模型是否真的生成了多步推理还是直接给结论再看筛选后保留的样本比例如果过滤后候选太少说明生成质量差问题在采样或基础模型能力。然后看蒸馏损失是否下降如果 loss 抖动剧烈说明 pivot 或采样样本不稳定。再测一个小样本泛化集换掉原始问题里的实体和数字看准确率是否保持。最后回头看源语言能力如果源语言退化说明训练目标失衡。这一步做完基本能找到问题出在数据、采样、目标还是评估。5. RP-OPSD 的适用边界适合谁不适合谁5.1 适合的场景和语言条件RP-OPSD 适合处理那些“模型能听懂但不会推理”的语言场景。它需要模型已在目标语言上有基本的 token 级能力词表覆盖、语法结构认知都已经具备只是缺少高质量的推理链数据来激活推理能力。典型适合场景高资源语言如英文、中文推理能力不错目标语言有一定训练语料但 CoT 数据稀缺目标语言属于同一语系或相似拼写体系模型迁移基础较好客观条件限制不能使用外部大模型做教师蒸馏只能用现有模型自举现有模型是通用多语言模型如各类开源 MoE 或 dense 多语言模型需要做轻量化领域适配。在这些情况下RP-OPSD 的价值在于不依赖大规模人工标注也不需要强外部教师能比较自然地完成推理能力迁移。5.2 不适合的场景如果模型在目标语言上几乎没有见过任何语料连基本词义都建模不好那么自蒸馏就是空中楼阁。模型自己生成的推理链全是乱码筛选后样本接近零蒸馏无从谈起。这种情况应该先做语言模型继续预训练或指令微调而不是直接做推理迁移。另外如果目标语言推理问题需要大量领域知识而模型本身缺乏这些知识RP-OPSD 也帮不上太多。它能迁移的是“推理结构”不是“知识内容”。知识缺失需要靠外部检索或继续训练解决。还有一种不适合的情况任务只要求短答案不要求解释。比如抽取式问答、关键词分类等强行要求模型生成推理链反而会把简单任务复杂化影响效果。5.3 和传统蒸馏、指令微调的关系RP-OPSD 不是传统蒸馏的替代而是补充。传统教师蒸馏在“学生需要学习一个比自己强很多的模型”时仍然有效RP-OPSD 更适合“没有强教师或教师分布与学生差异太大”的场景。指令微调解决的是“模型听懂指令并格式化成答案”的问题RP-OPSD 解决的是“模型在低资源语言上也保持推理结构”的问题。两者可以叠加使用先用指令微调让模型服从格式再用 RP-OPSD 提升推理迁移质量。所以选型时不要问“哪个方法最好”而应该问“当前瓶颈在哪”。瓶颈在数据格式就用指令微调瓶颈在推理质量再考虑 RP-OPSD。6. 长期视角从迁移答案到迁移推理习惯把 RP-OPSD 放进更大的技术趋势里看它真正有启发的地方不是某个具体损失函数而是把“推理过程”变成了一等公民。长期以来蒸馏、微调、评估都围绕答案精度展开过程信息只是附带产物。但随着模型越来越强大家发现答案对不代表会推理会推理也不代表能在所有语言里推理。推理是一种抽象能力它在语言表层之下。RP-OPSD 尝试用 Reasoning-Pivot 把这条抽象能力显式锚定再通过 On-Policy Self-Distillation 让模型在目标语言上自主生成和校准。这条路未必是最终答案但方向是对的与其把高资源语言上的推理结果搬运过去不如帮助模型自己长出推理路径。如果你也在做多语言推理迁移我的建议是先不要急着复现完整方法。先拿一个很小的语言对比如中文到泰语用当前模型生成一批目标语言的推理链人工看一眼质量。如果生成结果里还能看到清晰的因果步骤那 RP-OPSD 的思路就值得试如果生成结果只是词汇拼凑那先解决基础语言能力再谈推理迁移。毕竟枢轴的质量决定了整个结构能转多稳。