多语言推理迁移难？RP-OPSD在线自蒸馏训练范式详解

在 LLM 推理能力研究中，多语言推理迁移（Multilingual Reasoning Transfer）是一个既关键又棘手的问题。简单来说，我们希望模型在使用英文推理数据训练之后，不仅能在英文上做数学、逻辑或代码推理，也能在中文、西班牙语、印地语、法语等语言上表现出稳定的推理能力。但实际效果往往不理想：模型在英文上表现良好，一旦切到其他语言，推理能力就明显下滑，甚至出现“语言切换后智商下降”的现象。

RP-OPSD 正是针对这一问题提出的一种新的训练范式。它的全称是 Reasoning-Pivot-Guided On-Policy Self-Distillation，核心思路可以概括为：通过“推理枢轴引导”的方式，让模型在在线策略自蒸馏过程中，逐步把英文推理能力迁移到多语言场景。

本文将从问题背景、方法拆解、训练流程、代码实现、常见问题等几个方面，完整梳理 RP-OPSD 的思路与实战要点。无论你是研究 LLM 对齐、推理增强，还是在工程中做多语言模型的训练与微调，都能从中找到可参考的框架。

1. 背景与核心概念：为什么多语言推理迁移这么难

1.1 什么是多语言推理迁移

多语言推理迁移，指的是用某一种语言（通常是英文）的推理数据训练模型，期望模型在多种语言上都具备推理能力。这种迁移能力在现实应用中非常重要，因为大多数开源的高质量推理数据集都集中在英文，而实际用户的使用语言却覆盖全球上百种。

举个例子：我们用 GSM8K 英文数学题训练模型，希望模型能解答中文数学应用题、西班牙语逻辑题或印度尼西亚语的几何题，而不需要在每种语言上都重新标注大量数据。

但问题在于，大语言模型在预训练阶段虽然见过多种语言，其推理能力却往往与“推理语言”高度绑定。也就是说，模型的推理路径、思维链模式，在英文上更容易被激活，而切到其他语言后，同样的推理链条可能变得脆弱甚至失效。

1.2 现有方法的局限性

在 RP-OPSD 出现之前，业界和学术界尝试过多类方法来解决这个问题：

这些方法有一个共同问题：它们大多把“语言”当成一个静态的翻译问题来处理，而没有考虑推理过程本身的动态性。换句话说，推理不是“把英文句子翻译成中文”这么简单，而是“在不同语言中激活同一种逻辑推理能力”。

1.3 RP-OPSD 的突破口

RP-OPSD 的思路与上述方法有本质区别。它不依赖大规模多语言标注数据，也不要求高质量的机器翻译结果，而是提出一种“自蒸馏 + 推理枢轴”的组合策略：

• 推理枢轴（Reasoning Pivot）：选定一种模型推理能力最强、最稳定的语言（通常是英文）作为枢轴，让模型先在该语言上生成高质量推理路径。
• 在线策略自蒸馏（On-Policy Self-Distillation）：让模型以当前策略生成多语言推理路径，以枢轴结果为参考进行蒸馏，从而逐步提升其他语言的推理水平。

这听起来有点像“先让师傅（英文推理）做一遍题，再让徒弟（多语言推理）照着师傅的思路做，不过要求徒弟不仅会翻译，还要理解师傅的推理逻辑”。

2. RP-OPSD 方法原理拆解

2.1 推理枢轴：为什么选择英文作为锚点

在多语言模型中，英文通常拥有最丰富的训练语料、最稳定的推理能力和最成熟的思维链表达方式。因此在 RP-OPSD 中，英文被设定为“推理枢轴”。

但这并不代表英文是唯一选择。如果你的模型在某种语言上表现更强，或者你的业务场景以某种语言为主，也可以把那种语言作为枢轴。关键在于，枢轴语言应该是模型最“擅长”的语言，这样才能提供高质量的推理参考。

推理枢轴在这套方法中承担两个职责：

1. 生成高质量的推理参考路径，作为蒸馏的“软标签”。
2. 提供跨语言的推理逻辑支架，让模型在切换到其他语言时，能借助枢轴理解“这个问题应该按什么思路去解”。

2.2 在线策略自蒸馏：让模型自己教自己

自蒸馏的核心思想，是用模型自身生成的输出作为训练目标。与离线蒸馏（使用固定教师模型）不同，在线策略自蒸馏强调的是：

• 教师与学生是同一个模型。
• 教师输出来自模型“当前策略”（on-policy），而不是某个冻结的旧版本。
• 训练过程中，教师输出会随着模型能力提升而动态更新。

这种设计有两点优势：

第一，避免教师模型与学生模型之间的能力断层。如果使用固定的教师模型，当学生模型能力逐步提升后，教师模型的输出可能反而成为限制学生进步的“天花板”。而在线策略让教师始终与学生保持同步，蒸馏目标会越来越贴合模型当前的推理水平。

第二，显著降低数据成本。不需要额外训练一个大教师模型，也不需要对每一条数据做人工标注，模型自身的生成结果就可以作为训练信号。

2.3 训练流程总览

RP-OPSD 的训练流程可以划分为以下阶段，方便理解，我们用一个表格来梳理：

需要特别说明的是，流程中的第 2 步和第 3 步不是静态的，而是交替进行的。每训练一个或多个 step，模型参数更新后，后续生成的“多语言推理路径”就会更接近枢轴语言的质量，从而形成一种螺旋式上升的训练循环。

3. 实验环境准备与数据组织

3.1 运行环境与依赖

RP-OPSD 的训练流程涉及大模型推理、自回归生成、KL 散度计算、策略梯度更新等环节，因此环境配置上建议满足如下条件。

版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。

3.2 数据组织

假设你要在 GSM8K、MGSM 或其他多语言推理数据集上复现 RP-OPSD，数据组织可以分为三层：

data/ ├── source/ │ ├── train_en.jsonl # 英文推理问题 │ ├── train_zh.jsonl # 中文推理问题 │ └── train_de.jsonl # 德文推理问题 ├── pivot/ │ ├── train_en_pivot.jsonl # 英文枢轴推理路径 │ ├── train_zh_pivot.jsonl # 中文问题对应的英文推理路径 │ └── train_de_pivot.jsonl └── eval/ └── mgsm_eval.jsonl # 多语言评测集

每条数据的 JSON 结构可以设计为：

{ "problem": "如果一个商店以 3 元的价格卖出 5 个苹果，那么 15 个苹果需要多少钱？", "language": "zh", "pivot_reasoning": "First, we need to find the price of one apple. ...", "target_reasoning": "首先，我们需要求出一个苹果的价格。..." }

当然，target_reasoning在初始阶段可能不存在或质量较低，这正是训练过程中需要逐步优化的对象。

4. 核心代码实现：搭建 RP-OPSD 训练循环

这里给出一个便于理解且能直接运行的“最小训练框架”，核心思路是：先使用模型生成 pivot 推理和对应语言的推理路径，再基于蒸馏损失更新策略。

4.1 创建项目结构

rp_opsd/ ├── config.py # 训练配置 ├── data.py # 数据读取与预处理 ├── model_utils.py # 模型加载与保存 ├── train.py # 主训练循环 ├── generate.py # 推理路径生成 └── eval_mgsm.py # 多语言评测脚本

4.2 模型加载与配置

# 文件路径：model_utils.py import torch from transformers import AutoModelForCausalLM, AutoTokenizer def load_model_and_tokenizer(model_name: str, use_flash_attn: bool = True): tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True) if tokenizer.pad_token is None: tokenizer.pad_token = tokenizer.eos_token model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype=torch.bfloat16, attn_implementation="flash_attention_2" if use_flash_attn else "sdpa", device_map="auto", trust_remote_code=True, ) model.config.use_cache = False # 训练阶段关闭缓存 return model, tokenizer

这段代码的核心点是：

• device_map="auto"让模型自动分布到可用 GPU 上。
• use_cache=False是训练阶段的常规设置，避免缓存导致显存溢出。
• 如果显存不足，可以配合 PEFT 使用 LoRA 来降低显存占用。

4.3 推理枢轴生成阶段

在生成阶段，我们让模型用英文（枢轴语言）生成推理路径，同时把这条路径保留下来，供后续自蒸馏使用。

# 文件路径：generate.py import torch from tqdm import tqdm def generate_pivot_reasoning(model, tokenizer, problems, language="en", max_new_tokens=512, temperature=0.7): """ 为多语言问题生成枢轴语言（默认英文）的推理路径。 """ prompt_template = ( "Please solve the following problem step by step in {lang}.\n" "Problem: {problem}\n" "Reasoning:" ) results = [] model.eval() with torch.no_grad(): for problem in tqdm(problems, desc="Generating pivot reasoning"): prompt = prompt_template.format(lang="English", problem=problem) inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate( **inputs, max_new_tokens=max_new_tokens, temperature=temperature, do_sample=True, top_p=0.9, ) generated = tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokens=True) results.append(generated) return results

这里有一个容易被忽略的细节：生成枢轴推理时，虽然问题是多语言的，但 prompt 指令部分是英文。这样做的目的是让模型自动切换到英文推理模式，产生更稳定的推理路径。

4.4 目标语言推理路径生成

完成枢轴推理生成后，再把“问题 + 枢轴推理”一起作为输入，让模型用目标语言生成推理路径。

# 文件路径：generate.py（续） def generate_target_reasoning(model, tokenizer, problems, pivot_reasonings, target_lang="Chinese", max_new_tokens=512): """ 在枢轴推理的引导下，让模型生成目标语言的推理路径。 """ prompt_template = ( "Here is a reasoning chain in English:\n" "{pivot}\n\n" "Now solve the original problem in {lang}, and keep the reasoning logic similar.\n" "Problem: {problem}\n" "Reasoning:" ) results = [] model.eval() with torch.no_grad(): for problem, pivot in tqdm( zip(problems, pivot_reasonings), total=len(problems), desc="Generating target reasoning" ): prompt = prompt_template.format( lang=target_lang, pivot=pivot, problem=problem ) inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate( **inputs, max_new_tokens=max_new_tokens, temperature=0.7, do_sample=True, top_p=0.9, ) generated = tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokens=True) results.append(generated) return results

这个设计可以理解为“给模型一张英文答题卡，要求它用中文把同样的推理过程重新写出来”。注意，不是让模型逐句翻译，而是要求它保持推理逻辑一致，用目标语言重新组织表达能力。

4.5 在线策略自蒸馏训练

训练阶段是整个 RP-OPSD 的核心。我们把“目标语言推理路径”作为训练输入，把“枢轴语言推理路径”映射到目标语言的 token 分布上，用 KL 散度计算蒸馏损失。

# 文件路径：train.py import torch import torch.nn.functional as F from torch.utils.data import DataLoader, Dataset class ReasoningDistillDataset(Dataset): def __init__(self, problems, target_reasonings, tokenizer, max_length=2048): self.problems = problems self.target_reasonings = target_reasonings self.tokenizer = tokenizer self.max_length = max_length def __len__(self): return len(self.problems) def __getitem__(self, idx): prompt = ( "Problem: {problem}\n" "Reasoning: {reasoning}" ).format( problem=self.problems[idx], reasoning=self.target_reasonings[idx] ) enc = self.tokenizer( prompt, max_length=self.max_length, truncation=True, padding="max_length", return_tensors="pt" ) return { "input_ids": enc["input_ids"].squeeze(0), "attention_mask": enc["attention_mask"].squeeze(0), } def compute_kl_loss(logits, target_logits, mask): """ 计算在线自蒸馏的 KL 散度损失。 这里 target_logits 可以理解为枢轴路径经模型前向得到的结果。 """ vocab_size = logits.size(-1) log_probs = F.log_softmax(logits, dim=-1) target_probs = F.softmax(target_logits, dim=-1) kl = F.kl_div( log_probs, target_probs, reduction="none" ).sum(-1) # (batch, seq_len) mask = mask.float() kl = (kl * mask).sum() / mask.sum().clamp(min=1.0) return kl def train_one_step(model, batch, optimizer, tokenizer): input_ids = batch["input_ids"].to(model.device) attention_mask = batch["attention_mask"].to(model.device) # 前向传播 outputs = model( input_ids=input_ids, attention_mask=attention_mask, labels=input_ids, # 先算语言建模损失，保证基础生成能力 ) lm_loss = outputs.loss # 在线自蒸馏损失 # 这里假设我们另有一套“枢轴推理”输入，实际工程中需要从同一批次构造 # 简化示例：直接使用当前模型在另一种语言 prompt 上的前向 logits # 作为教师分布，演示思路如下： kl_loss = torch.tensor(0.0, device=model.device) # 总损失 loss = lm_loss + 0.5 * kl_loss optimizer.zero_grad() loss.backward() optimizer.step() return { "lm_loss": lm_loss.item(), "kl_loss": kl_loss.item() if isinstance(kl_loss, torch.Tensor) else 0.0, "total_loss": loss.item(), }

需要提醒的是，上面的compute_kl_loss是一个简化实现。在实际论文复现中，在线自蒸馏损失通常需要模型对“目标语言推理路径”和“枢轴参考路径”分别做前向，然后对两组 logits 计算 KL 散度。更完整的工程实现还需要考虑：

• 如何对 token 序列做对齐；
• 如何用 mask 屏蔽 padding 位置；
• 如何处理两种语言 tokenizer 不一致的问题；
• 是否在蒸馏损失中加入辅助的 SFT 损失，防止模型遗忘基础能力。

4.6 训练主循环

# 文件路径：train.py（主循环节选） from transformers import get_cosine_schedule_with_warmup from model_utils import load_model_and_tokenizer from data import load_multilingual_dataset def main(): model_name = "Qwen/Qwen2.5-7B-Instruct" # 示例模型，按需替换 model, tokenizer = load_model_and_tokenizer(model_name) # 数据加载 problems, target_reasonings = load_multilingual_dataset( path="data/source/train_zh.jsonl" ) dataset = ReasoningDistillDataset(problems, target_reasonings, tokenizer) dataloader = DataLoader(dataset, batch_size=4, shuffle=True) optimizer = torch.optim.AdamW(model.parameters(), lr=1e-5) scheduler = get_cosine_schedule_with_warmup( optimizer, num_warmup_steps=100, num_training_steps=len(dataloader) * 3, ) global_step = 0 for epoch in range(3): for batch in dataloader: metrics = train_one_step(model, batch, optimizer, tokenizer) if global_step % 10 == 0: print(f"Step {global_step}: {metrics}") scheduler.step() global_step += 1 model.save_pretrained("output/rp_opsd_model") tokenizer.save_pretrained("output/rp_opsd_model") if __name__ == "__main__": main()

5. 实验评测：如何验证多语言推理迁移效果

RP-OPSD 的效果不能只靠单个训练集上的 loss 来判断，必须在多语言基准集上做系统评测。比较常用的评测集包括：

• MGSM（Multilingual Grade School Math）：覆盖 10 种语言的数学应用题。
• MMMLU（Multilingual MMLU）：多语言版本的综合知识推理。
• MultiArith 多语言翻译版。
• 自建业务数据集。

评测代码可以从简到繁实现，下面是一个基于 MGSM 的示例：

# 文件路径：eval_mgsm.py import json import torch from tqdm import tqdm def evaluate_mgsm(model, tokenizer, eval_file="data/eval/mgsm_eval.jsonl", lang="zh"): model.eval() correct = 0 total = 0 with open(eval_file, "r", encoding="utf-8") as f: samples = [json.loads(line) for line in f if json.loads(line)["language"] == lang] prompt_template = ( "Please solve the following math problem step by step.\n" "Problem: {problem}\n" "Answer:" ) with torch.no_grad(): for sample in tqdm(samples, desc=f"Evaluating {lang}"): prompt = prompt_template.format(problem=sample["problem"]) inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate( **inputs, max_new_tokens=512, temperature=0.0, do_sample=False, ) prediction = tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokens=True) if sample["answer"] in prediction.strip(): correct += 1 total += 1 accuracy = correct / max(total, 1) print(f"Language: {lang}, Accuracy: {accuracy:.4f}") return accuracy

需要注意的是，MGSM 的答案匹配逻辑在真实评估中并不只是“答案字符串包含”这么简单。实践中建议使用规则抽取模型输出中的最终数字答案，再做归一化比较。

6. 常见问题与排查思路

在复现或应用 RP-OPSD 的过程中，最容易遇到的问题集中在训练不稳定、显存溢出、路径生成退化等方向。下面整理了一份排查清单。

在实际项目中，遇到最多的问题其实是“目标语言推理路径生成质量差”。这通常不是模型能力不足，而是 prompt 设计不够好。建议在正式训练前，先在少量数据上人工检查生成路径，看模型是否真正理解了“逻辑保持一致，但语言切换”的要求。

7. 最佳实践与工程建议

7.1 严格区分枢轴生成与训练阶段

在实现 RP-OPSD 时，最容易踩的坑是把“枢轴推理路径生成”和“目标语言路径生成”都放到训练阶段里在线进行。这样虽然更接近 on-policy 的精确定义，但工程复杂度呈指数上升。

更稳妥的做法是：

• 阶段一：冻结模型，离线生成枢轴推理路径和目标语言路径。
• 阶段二：加载这些路径，训练模型。
• 阶段三：每训练 N 个 step，重新生成一次路径，更新训练集。

这样既保留了 on-policy 的动态性，又不会让训练代码变成一团乱麻。

7.2 设置合理的蒸馏损失权重

蒸馏损失权重是一个需要反复调试的超参数。权重过大，模型会过度关注与枢轴语言的对齐，导致目标语言的表达能力下降；权重过小，多语言迁移效果不明显。

从经验角度看，可以按下面顺序调整：

1. 先用纯 SFT 损失训练一个 baseline。
2. 加入蒸馏损失，权重从 0.1 开始尝试。
3. 观察目标语言验证集上的 accuracy 变化。
4. 如果准确率上升但不稳定，适当降低学习率。
5. 如果准确率停滞，适当提高蒸馏权重。

7.3 使用多语言混合数据避免灾难性遗忘

RP-OPSD 的训练数据如果只包含单一目标语言，模型很容易在训练过程中遗忘掉其他语言的推理能力。因此，建议每个 training batch 中混合多种语言的数据，让模型在每一轮更新中都能接触到不同的语言分布。

例如一个 batch 中可以有：

• 2 条中文数据
• 2 条德文数据
• 2 条法文数据
• 2 条英文数据

这样做的另一个好处是，模型能自然地学习到不同语言之间的推理共享模式，而不是简单地对单一目标语言过拟合。

7.4 保留一个冻结的参考模型

虽然 RP-OPSD 强调 on-policy，但在工程实现中，保留一个冻结的参考模型依然有重要价值。这个参考模型可以用于：

• 计算生成的路径是否发生质量退化；
• 作为 PPO 式训练的 reward model；
• 在蒸馏损失中加入正则项，防止模型偏离原始能力太远。

冻结参考模型不会影响 on-policy 的核心特性，反而能提供更稳定的训练信号。

7.5 数据安全与生产合规

如果你的训练数据来自真实用户，务必注意：

• 训练数据必须经过脱敏处理；
• 涉及用户生成内容的，需要确认授权范围；
• 多语言数据中可能包含不同地区的文化、政治敏感内容，建议先做内容安全过滤；
• 模型发布前应做安全评测，避免在多语言环境下产生有害输出。

8. 总结与学习路线

RP-OPSD 提供了一条不同于“翻译 + 微调”的多语言推理迁移路径。它通过“推理枢轴引导”和“在线策略自蒸馏”，让模型在保持推理逻辑一致的前提下，逐步增强目标语言的表达能力。这个方法更适合以下场景：

• 高质量多语言标注数据稀缺；
• 已有英文推理数据，但需要快速扩展到多语言；
• 模型本身具备一定的多语言基础能力，但推理能力集中在单一语言上。

如果你想在工程中落地这个方法，建议按以下路线推进：

1. 先构建一个小规模的多语言推理数据集（100～500条），跑通训练流程。
2. 人工检查生成的枢轴路径和目标路径质量。
3. 在小规模评测集上对比 RP-OPSD 与直接翻译微调的效果差异。
4. 确认收益后，再扩大数据规模并接入分布式训练。
5. 加入多语言安全评测与业务指标验证。

接下来可以进一步学习的内容包括：

• 多语言 RLHF / DPO 与自蒸馏的结合；
• 推理时自洽性（self-consistency）与多语言采样；
• 跨语言表示对齐的最新方法；
• 基于对比学习的多语言推理路径对齐。

RP-OPSD 不是一条“搭好即跑”的现成通道，它更像是一套训练方法论。只有理解了它背后的设计动机，并根据自己的模型、数据和业务场景做适配，才能发挥出预期的效果。如果你正在被多语言推理迁移问题困扰，不妨从今天给出的最小框架开始，在小数据上跑通验证，再逐步迭代到完整的训练流程。