RP-OPSD：基于推理枢轴与在线自蒸馏的多语言推理迁移

这次我们来看一个多语言推理方向的新方法：RP-OPSD，全称是 Reasoning-Pivot-Guided On-Policy Self-Distillation for Multilingual Reasoning Transfer。它不是模型权重，也不是一键部署工具，而是一套训练与数据生成策略，适合解决多语言场景下推理能力迁移的问题。最值得关注的点有三个：第一，它强调 On-Policy，也就是用当前模型自己生成的推理样本来训练自己；第二，它引入 Reasoning-Pivot，用高资源语言的推理链作为跨语言对齐的“枢轴”；第三，目标是多语言推理迁移，把英语、中文等资源丰富语言上已经比较成熟的推理能力，迁移到低资源语言上。本文会从方法动机、训练流程、环境准备、评估验证和排查思路五个角度拆解，尽量让没有接触过知识蒸馏的读者也能跟着理解并尝试复现。

从使用角度看，RP-OPSD 和常见的“加载一个开源模型做推理”完全不一样。你不能像跑一个 LLM 那样，把 RP-OPSD 当成模型权重下载下来直接调用。它更像是一种训练范式：你需要有一定的 GPU 资源、一个具备多语言能力的基座模型，以及一份覆盖多种语言的高质量问答数据。复现时，重点观察的也不是单次推理速度，而是训练后的模型在低资源语言上的推理指标是否提升、训练过程是否稳定、数据生成环节是否可靠。如果你关心的不是训练方法，而是“现成模型能不能用”，这篇博客可能不适合你；但如果你想做多语言模型调优、数据增强或者推理能力迁移，RP-OPSD 的思路值得仔细看。

为了让文章更有操作性，我会把整个方法拆成“能直接照着做的流程”。先从核心能力速览开始，再讲方法设计，然后给出一套通用的环境准备、训练循环、评估流程和排查清单。需要说明的是，由于目前能看到的公开材料只有方法名和技术背景，文中不会编造官方配置、模型规模、显存占用或 benchmark 指标；所有实现细节都按通用做法给出，并标注哪些地方需要以论文原文和开源代码为准。

1. RP-OPSD 核心能力速览

从表格可以看出，RP-OPSD 的输入不是“提示词”，而是“训练数据集和训练配置”。它的产出也不是一个单独文件，而是一组训练后的模型权重。因此，如果你是做工程部署的读者，更合适的关注点是：如何把多语言推理数据变成训练样本，如何在多卡环境下跑通自蒸馏，以及如何评估迁移效果。

2. 适用场景与使用边界

2.1 这种方法适合谁

RP-OPSD 适合以下几类读者：

• 做多语言 LLM 微调的同学，尤其是想让模型在低资源语言上也能一步步推理。
• 做知识蒸馏、自蒸馏方向的研究者，希望减少对外部大模型教师依赖。
• 做数据流水线的工程师，需要批量生成高质量多语言思维链数据。
• 想要把英语推理能力迁移到业务语言的算法团队，例如从英文问答迁移到印尼语、阿拉伯语、斯瓦希里语等。

如果只是想在本地跑一个现成的多语言模型，不需要了解训练细节，RP-OPSD 对你来说优先级不高。它的价值主要体现在“模型效果不够好，又缺少目标语言的高质量标注数据”时。

2.2 能解决什么问题

多语言推理迁移的核心问题不是“翻译”，而是“让模型用低资源语言也能完成多步推理”。直接翻译英文思维链再微调，往往存在语义漂移、表达不自然、逻辑链断裂等问题。RP-OPSD 的设想是：模型自己生成目标语言的推理链，并把这些推理链作为训练信号，从而让模型逐步适应当前语言的推理方式。由于训练信号来自当前模型本身，数据分布和模型能力是匹配的，这比离线蒸馏更贴近真实推理场景。

同时，Reasoning-Pivot 提供了一条跨语言对齐路径。高资源语言的推理链结构更完整、质量更可控，用高资源语言推理链作为中间“枢轴”，可以降低低资源语言推理链的生成难度。这个方法在数据稀缺场景下尤其有价值。

2.3 不适合什么场景

这套方法不适合完全没有训练资源的场景。至少需要一张能加载基座模型的 GPU，并且要能承受多轮生成和训练迭代。如果连“用脚本批量生成推理链”的环境都没有，建议先跑通一个更简单的自蒸馏流程再考虑 RP-OPSD。

另外，如果目标语言是英语、中文这类高资源语言，且你已经有了大量标注数据，RP-OPSD 的优势就不明显。它的收益主要在“低资源、少标注、强逻辑”的任务组合上。

2.4 数据版权与模型合规边界

训练数据的版权问题必须单独说。多语言推理数据通常来自公开问答集、翻译平台或业务日志，使用前要确认授权范围。如果使用翻译工具生成低资源语言数据，要留意翻译服务条款是否允许用于模型训练。低资源语言涉及少数民族语言、跨境语言或特定区域语言时，也要注意数据来源是否合规、是否涉及隐私信息。涉及用户数据时，必须做脱敏和授权确认。任何训练方法都不能替代数据合规审查。

3. 方法设计拆解

3.1 从多语言推理迁移说起

多语言推理迁移要解决的是：模型在 A 语言上会推理，换成 B 语言后推理能力下降。这个问题的原因很直接——训练数据分布不同。大模型的高质量推理链绝大多数是英语，少量是中文、日语等资源丰富语言，低资源语言几乎没有。于是模型学会了“英语问题的推理模式”，却不知道如何把同样的推理步骤用另一种语言表达出来。

传统的解决思路有两种：第一种是翻译，把英文思维链翻译成目标语言；第二种是平行语料微调，用大量双语或多语数据让模型对齐语义。翻译路线的问题在于机器翻译会破坏逻辑连接词和多步推理结构；平行语料路线的问题是高质量平行语料难找。RP-OPSD 想绕开这两条路的限制，让模型自己生成“符合当前语言习惯”的推理链，再通过自蒸馏强化这种能力。

3.2 什么是 On-Policy Self-Distillation

自蒸馏是指模型不借助外部教师，而是用自己的输出作为监督信号来训练自己。传统蒸馏通常是“大模型教小模型”，而自蒸馏可以发生在同一个模型的不同迭代阶段。On-Policy 这个词来自强化学习，表示数据来自“当前正在更新的策略”。在 RP-OPSD 中，On-Policy 的意思是：每一轮训练用到的推理样本，是由当前版本的模型生成的，而不是从静态数据集里拿的。

这样做的好处是避免分布偏移。比如一个早期模型生成的目标语言推理链可能很混乱，如果强行把这批数据放入训练集，后期模型即使变强了，也会被旧数据拉低。On-Policy 则让训练数据始终跟随模型当前能力，不断产生“跳一跳够得着”的样本，更像人类在练习中逐步提高。

当然，On-Policy 也有代价：需要在训练过程中反复让模型做生成，计算开销大，数据质量也更容易波动。所以实际实现时，通常不会每个 step 都生成，而是每隔一定步数重新生成一批样本，或者对生成样本做过滤后再训练。

3.3 Reasoning-Pivot 的“枢轴”是什么

Reasoning-Pivot 是 RP-OPSD 的关键设计。Pivot 可以理解为“推理链的中间锚点”。在多语言场景中，比较可行的做法是：给定一个低资源语言的问题，先让模型用高资源语言生成一段推理链，再把这段推理链转换成目标语言。高资源语言推理链就是 pivot。

为什么这么做有效？因为推理链的核心不是语言表面，而是逻辑步骤。英文推理链步骤清晰，先做什么、再做什么、最后得到什么结果，容易评估。模型生成英文推理链时，可以更专注地完成“推理”，而不是同时处理“目标语言表达”。等英文推理链稳定后，再引导模型用目标语言复述同样的步骤，难度会降低。

从训练角度，pivot 还提供了比对信号。如果模型生成的目标语言推理链与英文 pivot 在语义上不一致，说明逻辑偏移了，这时可以降权或丢弃。这种“用高资源语言约束低资源语言”的思路，是 RP-OPSD 名称里 Reasoning-Pivot-Guided 的核心含义。具体的 pivot 获取方式可能包括：直接翻译、双语对照生成、或让模型根据语言标签生成双语推理链，都取决于实现。

3.4 训练目标与损失设计

RP-OPSD 的损失设计需要结合论文实现，这里只能给一个通用框架。通常自蒸馏的损失包含两部分：一部分是标准交叉熵，用于学习硬标签；另一部分是 KL 散度，用于对齐模型当前输出和自蒸馏目标。

# 伪代码：自蒸馏损失示例，具体实现以论文为准 loss_ce = CrossEntropyLoss(logits, labels) loss_kd = KLDivergence(log_softmax(logits), soft_targets) loss = alpha * loss_ce + beta * loss_kd

在多语言推理迁移场景下，目标语言推理链的质量通常参差不齐，因此还需要一个质量过滤机制。比如对生成样本计算平均 logprob，低于阈值的样本直接丢弃；或者把推理链是否与最终答案一致作为过滤标准。只有那些“推理链完整、答案正确”的样本才进入训练，这样能减少错误累积。

4. 环境准备与前置条件

4.1 硬件建议

RP-OPSD 训练流程包含“生成”和“训练”两个阶段。生成阶段需要加载基座模型并做多轮自回归，训练阶段需要反向传播。如果你的基座模型是 7B 参数，建议至少准备一张 24GB 显存的 GPU，或使用多卡并行；如果使用 LoRA 等参数高效微调方法，显存需求会降低，但生成阶段的显存依旧取决于模型大小和序列长度。

更稳妥的判断是：先用最小配置跑通流程，再根据实际显存调整 batch size 和生成长度。不要一开始就追求大批量。显存不足时，优先考虑降低生成长度、减小 batch size、开启梯度累积和混合精度。

4.2 软件依赖

下面给出通用依赖清单，版本不在本地锁死，安装时建议以当前生态稳定版为准。

conda create -n rpopsd python=3.10 conda activate rpopsd pip install torch transformers accelerate datasets peft bitsandbytes

如果需要做文本评估，再补充安装：

pip install evaluate sacrebleu

注意：不同版本的 Transformers 对 generate 接口、logits 处理和模型加载方式有差异。如果训练中遇到 API 变化，优先查看当前版本的官方文档。

4.3 数据准备

多语言推理迁移的数据通常包含三部分：源语言问题、源语言推理链、目标语言问题。如果目标语言缺少标注推理链，可以让模型基于英文 pivot 生成。一个通用的 JSON 数据格式如下：

{ "instruction": "Solve the problem and explain your reasoning.", "source_question": "If a train travels 120 km in 2 hours, what is its average speed?", "source_reasoning": "Average speed is distance divided by time. 120 km divided by 2 hours equals 60 km/h.", "target_question": "Jika sebuah kereta menempuh 120 km dalam 2 jam, berapa kecepatan rata-ratanya?", "target_reasoning": "", "language": "id" }

实际项目中，target_reasoning 可以由模型自动生成，也可以留空。数据质量比数据量重要。建议先人工清洗一批高置信度样本，作为初始训练集，再逐步引入自生成样本。

5. 复现训练流程（伪代码）

下面给出一个通用实现思路，用于理解 RP-OPSD 的流水线。由于这不是官方代码，需要你根据实际模型和框架做适配。

5.1 推理枢轴样本生成

首先生成英文推理链作为 pivot。输入是源语言问题，模型输出英文推理步�骤。为了让步骤更稳定，可以设置 temperature 低一些，比如 0.7；如果希望多样性高，可以设置do_sample=True。

from transformers import AutoTokenizer, AutoModelForCausalLM model_name = "your-multilingual-base-model" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForCausalLM.from_pretrained(model_name, device_map="auto") def generate_reasoning(prompt, max_new_tokens=256, temperature=0.7): inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate( **inputs, max_new_tokens=max_new_tokens, do_sample=True, temperature=temperature, pad_token_id=tokenizer.eos_token_id, ) return tokenizer.decode(outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True)

生成后需要简单过滤：如果推理链太短、重复度过高，或者没有包含答案，就丢弃。过滤比例会直接影响训练效果。

5.2 On-Policy 自蒸馏训练循环

On-Policy 训练循环的关键是“每隔 N 步重新生成数据”，并把这些新数据混入训练集。下面的伪代码展示了这个思路。

current_train_data = load_initial_data() for step in range(total_steps): if step % regenerate_interval == 0: # 用当前模型生成新推理样本 new_samples = generate_samples(model, current_train_data) # 过滤低质量样本 new_samples = filter_samples(new_samples) # 与初始数据合并 mixed_data = merge_data(current_train_data, new_samples) batch = sample_batch(mixed_data) outputs = model(batch["input_ids"], labels=batch["labels"]) loss = outputs.loss loss.backward() optimizer.step() lr_scheduler.step()

可以看到，On-Policy 的特点不是固定数据集，而是不断用当前模型刷新训练样本。这里实现时要注意：generate_samples和filter_samples会在训练过程中占用大量时间，所以 regenerate_interval 不宜太小，否则训练效率会很低。

5.3 训练配置示例

训练配置可以保存成 JSON，方便多卡复现。

{ "model_name": "your-multilingual-base-model", "batch_size": 1, "gradient_accumulation_steps": 8, "learning_rate": 2e-5, "num_epochs": 3, "regenerate_interval": 200, "max_source_length": 512, "max_target_length": 512, "temperature": 0.7, "filter_threshold": 0.5, "lora_rank": 16, "lora_alpha": 32 }

lora 相关参数仅在你要做参数高效微调时使用。如果直接全量微调，去掉 lora 字段即可。filter_threshold是过滤生成样本的阈值，通常需要根据验证集反复调整。

6. 功能测试与效果验证

6.1 多语言推理评估基准

复现 RP-OPSD 后，需要验证“推理迁移”是否真的发生了。可以选择公开的多语言推理基准，比如 MGSM、M-MMLU、M-CEval 等。这些基准覆盖多种语言，包含数学推理、常识问答和学科知识，能比较直观地反映模型在目标语言上的推理能力。

选择基准时要注意语言覆盖范围。基准里必须包含你训练的目标语言，否则无法评估迁移效果。如果公开基准不满足需求，可以自己构建一个双语测试集：取 100 到 200 道源语言推理题，翻译成目标语言，再人工校验翻译质量。

6.2 评估流程

评估主要分两步：先生成答案，再对比标准答案。数学推理任务可以对比最终数字，常识推理可以对比选项，开放生成任务则需要用 ROUGE、BLEU 或人工评价。

下面是一个简单的批量评估示例。

import json from tqdm import tqdm def evaluate_model(model, tokenizer, eval_data): correct = 0 total = 0 for item in tqdm(eval_data): prompt = item["prompt"] gold = item["answer"] pred = greedy_decode(model, tokenizer, prompt) if normalize_answer(pred) == normalize_answer(gold): correct += 1 total += 1 return correct / total if total else 0

greedy_decode对应低温或贪心解码，normalize_answer负责去除大小写、标点和多余空格。

6.3 判断成功标准

判断 RP-OPSD 是否有效的标准，不是看训练 loss 是否下降，而是看目标语言测试集上的指标是否提升。理想情况下，低资源语言上的推理准确率应该比未训练前高，并且比“只翻译英文思维链微调”的基线要好。如果训练后源语言推理能力明显下降，说明迁移过程出了问题，可能是数据混合比例不对，或者 Reasonging-Pivot 引导过强。

6.4 常见失败原因

如果验证指标没有提升，优先检查这几个方面：

• 基座模型本身是否支持目标语言。如果目标语言的 token 在词表中覆盖率很低，生成的文本很可能残缺。
• 初始数据里是否包含足够多的目标语言问题。如果目标语言问题只占 5%，迁移效果不会明显。
• 过滤阈值是否过严或过松。过严会丢掉有用样本，过松会把错误推理链送进训练。
• temperature 是否过高。过高的 temperature 会让生成推理链偏离逻辑结构。
• 训练步数是否足够。On-Policy 自蒸馏效果出现比较慢，需要观察多个检查点。

7. 批量数据处理与训练加速

7.1 批量生成推理链

多语言推理迁移非常依赖数据量，因此推理链生成阶段可以做成批量任务。把输入数据写成 JSONL，逐行读取，生成结果也逐行写入，方便断点续跑。

python batch_generate.py \ --input_file ./data/train.jsonl \ --output_file ./data/train_generated.jsonl \ --model_name your-multilingual-base-model \ --batch_size 1 \ --max_new_tokens 256

如果单卡生成太慢，可以按语言或问题 ID 分片，多卡并行生成，最后合并。生成任务本身没有梯度，所以可以使用半精度加载模型，减少显存占用。

7.2 显存优化

训练阶段显存不足时，优先使用以下手段：

• 降低 batch size，用 gradient_accumulation_steps 补偿。
• 开启混合精度fp16或bf16。
• 使用 LoRA 或 QLoRA 做参数高效微调。
• 限制生成序列长度，避免超长推理链占用显存。
• 如果多卡可用，使用 DeepSpeed Stage 2 或 Stage 3。

需要注意，QLoRA 会降低模型量化精度，可能影响自蒸馏目标的质量。建议先用 LoRA 跑通流程，再尝试量化方案。

7.3 训练稳定性

On-Policy 自蒸馏的常见问题是“生成数据质量随训练波动”。解决思路是引入 EMA（指数移动平均）模型来生成推理链。EMA 模型的参数比当前训练模型更稳定，生成的推理链质量也更平滑。这个方法并非 RP-OPSD 专属，但在自蒸馏任务中非常实用。

另外，学习率不宜过高。自蒸馏任务对灾难性遗忘比较敏感，建议学习率保持在 1e-5 到 3e-5 之间，并配合 warmup 和 cosine decay。

8. 常见问题与排查方法

排查时，建议每次只改一个变量。很多问题不是单一原因造成的，同时调参只会让结果更难定位。

9. 最佳实践与使用建议

第一，先用小模型跑通流程。不要一上来就用 70B 模型。用一个 1B 或 3B 的多语言模型，配合很小的数据集，把“生成 -> 过滤 -> 训练 -> 评估”闭环跑通。确认每个环节没有 bug 后，再换目标模型。

第二，保留一份高质量种子数据。初始训练集的质量决定了自蒸馏的上限。建议人工整理 500 到 1000 条高质量多语言推理样本，覆盖不同推理类型。后续自动生成的样本只能作为补充，不应完全替代种子数据。

第三，On-Policy 数据不要过于频繁更新。每个 step 都重新生成数据会非常慢，而且模型参数还没稳定，生成样本之间差异太大。合理的做法是每隔 200 到 500 步重新生成一次，或者在每个 epoch 结束后批量生成。

第四，评估必须看多语言分组指标。不要只看总平均准确率。把源语言、目标语言、低资源语言分开统计，才能看出迁移是否真的发生。总准确率可能被源语言提升掩盖，但目标语言反而下降。

第五，训练数据中要保留源语言推理样本。完全用目标语言训练会造成灾难性遗忘。通常的做法是混合比例，比如源语言 70%、目标语言 30%，再根据验证集调优。

第六，涉及人脸、声音、隐私数据或版权材料时，必须确认授权。这一点在 2.4 节已经强调过，但在实际训练中很容易被忽略。多语言数据的版权边界比单语言更复杂，因为涉及的翻译工具、语料库和地区法律可能不同。

第七，发布或商用前要做效果复核。自蒸馏模型可能在测试集上表现不错，但开放域生成时会出现重复、逻辑错误或目标语言表达不自然。上线前要做人工抽检和红队测试，不要让模型直接面对真实用户。

10. 总结与下一步

RP-OPSD 最值得尝试的点在于它的“自我迭代”设计。传统蒸馏需要一个更强教师模型，而 RP-OPSD 尝试让模型用自身生成的推理链完成跨语言迁移，配合 Reasoning-Pivot 做跨语言对齐，思路干净，工程可落地。

如果你要复现，建议最先验证三个功能点：一是模型能否稳定生成目标语言推理链；二是过滤机制能否有效筛掉低质量样本；三是训练后低资源语言验证集指标是否提升。最容易踩的坑是生成样本质量不稳定和评估指标不涨，这两个问题都能通过数据过滤和 EMA 生成缓解。

后续可以扩展的方向包括：把目标语言换成更多语种；把 Reasoning-Pivot 从英文替换成中间语言；把 On-Policy 自蒸馏和强化学习偏好优化结合；或将这套流程应用到代码生成、数学定理证明等强逻辑任务上。任何训练方法都是手段，最终要回归到数据质量、评估指标和模型可控性这三个基本问题上。建议先跑通最小实验，留存完整训练日志，再逐步扩大数据规模和模型规模。