当我把一个开源大模型从英文切到泰语时，最明显的感受不是“答案变少了”，而是模型开始拒绝推理。它不再尝试一步一步思考，而是直接给一个简短结论，甚至把问题重新拼一遍就交差。这不是偶发，而是多语言推理迁移里的常态：高资源语言上的推理能力，很难自动平移到低资源语言。于是越来越多工作开始把目光投向一个方向：能不能不只用答案做蒸馏，而是把推理路径本身也搬过去。
今天想聊的这篇工作，标题叫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_sequences=4, # 多次采样 temperature=0.7, max_new_tokens=256, ) # 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 的思路就值得试；如果生成结果只是词汇拼凑，那先解决基础语言能力，再谈推理迁移。
毕竟，枢轴的质量决定了整个结构能转多稳。
