用开源模型拟合闭源模型：影子模型如何恢复推理过程

最近团队接了个长期且挺磨人的需求：把某个闭源商用模型在业务场景里的推理过程“恢复”出来，用于合规审计和风险定位。许多人对“闭源模型”的第一反应是：API 只给输入输出，权重不公开，内部推理过程根本看不见，怎么恢复？其实在实操层面，业内早有一套成熟打法：不是去逆向拆解闭源模型的权重，而是用开源模型去拟合闭源模型的行为，尤其是把“中间推理链条”尽量对齐地生成出来。简单说，就是训练一个白盒模型，让它变成闭源模型的影子，需要审计时让影子模型告诉你：在同样输入下，那个黑盒大概在想什么。

这篇文章我把整套流程从头到尾拆一遍，包括数据构造、底座选型、微调方案、效果评估和常见坑。适合三类人看：一是做模型应用落地、需要给业务方解释模型行为的工程师；二是做AI安全与审计、需要可解释记录的算法同学；三是对开源底座微调感兴趣、想找个实际场景练手的学习者。整个过程不追求100%还原闭源模型，但可以把“一致性”拉到可用水平，覆盖大多数需要解释的场景。

1. 先搞清楚“恢复推理过程”到底在做什么

1.1 你拿到的是什么：黑盒API vs 白盒开源

闭源模型通常只暴露一个API接口，你丢进去一段输入，它返回一段输出。中间发生了什么，你不知道，也没法知道，因为权重、注意力矩阵、每一层的隐状态都不在你手里。开源模型则相反，权重完全开放，你可以拿到每一层的输出，可以微调、可以剪枝、可以做各种解释性分析。

“恢复推理过程”这件事，本质上是把黑盒模型在某个输入分布下的行为，迁移到一个白盒模型上。它不是“破解”闭源模型，而是“行为对齐”。你可以把它理解成：我喝到一杯很好喝的奶茶，不知道店家的配方，但通过反复品尝、记录甜度、茶底、配料比例，最后用自己店里的原料做出一杯味道几乎一样的奶茶。开源模型就是我的原料和配方，闭源模型的输出就是那杯奶茶。

这个类比能帮助我们想清楚目标：我们不是要复刻一个一模一样的大脑，而是要复刻它在特定问题上的“思考路径和回答风格”。这在业务上是有实际价值的，比如某个闭源模型在风控场景给了一个拒绝决策，审计方需要知道它为什么拒绝，这时候影子模型就可以生成一份“推理说明”，帮业务人员定位是哪个风险特征触发了拒绝。

1.2 为什么不是“逆向破解”，而是“行为对齐”

我见过不少人一上来就问：能不能直接提取闭源模型的参数？答案是不能，也没有必要。从安全角度讲，闭源模型的参数是核心资产，不可能通过API暴露出来；从技术角度讲，即使你能访问到输出分布，也无法唯一确定一组权重，因为很多不同的内部结构可以产生相同的输入输出映射。

行为对齐是另一种思路：我不关心它内部怎么实现，我只关心它“在什么输入下产生了什么输出”。通过大量输入输出对，让开源模型学会闭源模型的“输入到输出映射”，同时让开源模型在生成时把推理步骤也展示出来。这样，我们既有了一个可控、可解释的白盒模型，又能在功能上近似替代闭源模型。

实际操作中，我发现这个思路还有一个额外的好处：影子模型可以离线运行，不依赖闭源API，也不受接口频率限制。你可以用它做批量分析、做压力测试、做敏感内容脱敏，这些都是调公共API不方便做的事情。

1.3 核心流程一览

整套流程可以压缩成四步：

1. 采样：构造一批种子输入，调用闭源模型API，诱导它输出“推理过程 + 最终答案”。
2. 清洗：过滤质量差、被拒绝、格式混乱的样本，整理成“输入—推理过程—输出”三元组。
3. 训练：用整理好的数据对开源底座模型做微调，让开源模型学会闭源模型的推理风格和结论。
4. 评估：用没参与训练的测试集，对比开源模型与闭源模型的推理步骤和最终答案，量化对齐程度。

下面我按步骤拆开讲，每一步都会有具体操作和踩过的坑。

2. 第一步：构造高质量“输入—推理过程—输出”三元数据

2.1 用提示词让闭源模型“开口说推理”

闭源模型不一定主动给你推理过程。很多模型在默认设置下只会输出最终答案，尤其是一些商业模型，为了减少生成长度和延迟，会把中间思考省略掉。这时候需要用提示词把它“引出来”。

我常用的几个提示语模板，直接复制就能用：

请先写出你的推理过程，要求分步骤说明，每一步解释为什么这么做，最后再给出最终结论。

你是一名善于教学的专家，请用通俗的语言，按步骤拆解你的思考过程，然后给出答案。

对于下面的问题，请先列出已知条件，再说明每一步的计算或分析逻辑，最后给出结论。

这个方法看起来简单，但有一个关键细节：提示语要针对任务类型做调整。数学题强调“列出条件、逐步计算”，代码问题强调“先分析需求、再设计思路、最后给代码”，文本分类问题强调“先说明分类依据、再下结论”。不要一个模板打天下，否则采集到的推理过程会很干瘪。

另外，采样时要设置temperature在0.7到1.0之间。同样的输入多采样几次，能拿到不同的推理路径，增加数据多样性。不要用temperature=0，那样模型每次都走同一个思考方向，数据内部相关性太高，微调出来的模型缺少泛化能力。

2.2 采样策略：覆盖率比单条质量更重要

刚开始做的时候，我很容易陷入“样本质量要好”的执念，盯着个别样本反复优化提示词。后来发现，真正影响最终效果的是覆盖面。闭源模型在某个业务域里会遇到各种边界情况，如果你的采样数据只覆盖了“正常问题”，影子模型遇到异常输入就会发懵。

我建议分三类来采样：

• 正常样本：业务中高频出现的典型问题，占总量的60%-70%。
• 边界样本：参数极端、条件缺失、多条件冲突的问题，占20%-30%。
• 对抗样本：故意设计成容易引导错误、带有歧义的输入，占5%-10%。

边界样本和对抗样本特别重要，因为审计中最需要解释的恰恰是那些非正常情况。比如风控模型拒绝了一个看起来正常的申请，审计人员最想知道的就是“为什么拒绝”，而不是“为什么通过”。

采样规模方面，我的经验是：如果业务场景比较垂直，一两万条数据就能看到效果；如果是通用对话场景，建议至少准备五万条以上。数据量不足时，影子模型会背题，而不是学会推理。

2.3 数据清洗与质量控制

采集回来的原始数据很脏，直接扔给模型训练会出事。我整理了一个清洗检查清单：

• 过滤拒绝回答。很多模型对某些敏感问题会回复“抱歉，我不能回答”，这些样本没有推理过程，必须去掉。
• 过滤格式错乱。比如“步骤1”重复出现、推理过程被截断、输出中夹带HTML标签等。
• 过滤过短文本。如果推理过程只有一两句话，信息量太低，对训练的贡献有限。
• 过滤重复样本。同一问题采样多次后，有些回复会高度相似，需要做去重。
• 统一格式。把“推理过程”和“最终答案”拆成两个字段，方便后续训练和评估。

清洗之后，我习惯把数据存成JSONL格式，样子大概是这样的：

{"instruction": "一个三角形的三条边分别是3、4、5，请问这个三角形是什么类型？", "reasoning": "首先，3的平方加4的平方等于9加16，结果是25。5的平方也是25。两边平方和等于第三边平方，因此满足勾股定理，所以这是一个直角三角形。", "answer": "直角三角形"}

注意，instruction是输入，reasoning是推理过程，answer是最终答案。训练时，模型需要学会的是“看到instruction后，先输出reasoning，再输出answer”。

2.4 平行语料里最容易踩的坑

这里说一个我踩过两次的坑：闭源模型的推理过程不一定是“正确”的。有时候它推理过程完全合理，但最终答案是错的；有时候推理过程偷换了概念，但答案碰巧对了。微调时如果盲目让开源模型模仿这些过程，等于把错误逻辑也学了。

解决办法是加一道“人工抽检”环节。我一般会随机抽500条样本，逐条看推理过程和最终答案是否一致、是否有明显逻辑漏洞。发现问题比例超过5%时，就要考虑修改提示词，或者在清洗阶段去掉这些“推理与答案矛盾”的样本，只保留逻辑自洽的对齐数据。

另有一个容易被忽略的点：采样要记录闭源模型的版本和日期。很多商业模型会频繁更新版本，同一输入在不同版本的输出可能不同。如果你的影子模型是在旧版本数据上训练的，新版本发布后需要重新采样和微调，否则对齐度会慢慢下降。

3. 第二步：选底座模型和微调方案，别一上来就全参

3.1 底座模型怎么选：参数规模、语言能力、上下文长度

底座模型选得对不对，直接决定微调的天花板。我选底座时主要看三个维度。

第一是参数规模。7B-8B量级的模型在单卡上就能微调和推理，性价比最高；如果业务场景复杂，推理链很长，可以上13B-14B；再往上到70B，对显存和训练成本的要求会指数级上升，除非预算充足，否则不建议首选。我自己做多数业务场景时，7B-8B已经够用，关键是数据做扎实。

第二是语言能力。中文场景优先考虑Qwen系列和DeepSeek系列，英文能力强的底座也可以，但中文逻辑表达可能不如原生中文模型自然。这个没有绝对的好坏，需要用一小批验证集跑一下，看底座在未微调前对业务问题的“初步理解”是否靠谱。

第三是上下文长度。如果闭源模型输出的推理步骤特别长，比如代码设计、多步数学推导，选32K以上上下文长度的底座会更稳。上下文太短，推理过程会被截断，训练时模型看到不完整的链条，生成时也容易断。

3.2 用LoRA还是全参微调：按数据量决策

这是新手最容易纠结的问题。我的经验法则很简单：

• 数据量小于10万条，用LoRA。
• 数据量几十万条以上，同时你有4张以上高端GPU，再考虑全参微调。
• 算力紧张时，先用LoRA跑通流程，验证效果提升了，再决定要不要上全参。

LoRA的优势是显存占用小、训练速度快、不容易把底座模型的通用知识冲掉。对于“恢复推理过程”这个任务，我们本质上是在学一种特定的输出风格和推理路径，LoRA的参数量完全够用。我一般设置rank=16到64之间，rank太小表达力不足，rank太大显存和过拟合风险都会上升。

学习率也需要控制。用LoRA微调时，学习率我习惯设置在1e-4到3e-4之间。过大会导致输出乱掉，模型开始胡言乱语；过小则训不动，损失下降很慢。epoch控制在1到3个之间，不要贪多。

3.3 训练数据组织格式

不管用什么框架，训练数据最终都要转成统一的对话格式。以LLaMA-Factory为例，我通常把数据转成这种结构：

[ { "instruction": "问题文本", "input": "", "output": "推理过程\n最终答案" } ]

需要注意的是，output字段里要把推理过程和最终答案放在同一个字段中，用换行或特殊标记分隔。这样模型在生成时才能连续输出“推理过程 + 答案”。如果你希望结构更清晰，也可以在output里显式写“推理过程：...，最终答案：...”，让模型学习这种固定格式。

有一个小技巧：不要在每轮训练时都完整输出“推理过程+答案”。可以随机让模型只输出推理过程，或者只输出最终答案，增强复杂度和灵活性。但比例要控制，一般70%的样本输出完整格式，30%只输出最终答案，这样影子模型在实际使用时也能快速给出结论。

4. 第三步：训练、评估、迭代，把对齐度提到可用水平

4.1 环境准备与训练流程

我用的是LLaMA-Factory这个框架，它对中文开源模型的支持很成熟，处理LoRA微调非常省事。启动命令大致是这样的：

llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --dataset train_dataset \ --finetuning_type lora \ --lora_rank 32 \ --learning_rate 2e-4 \ --num_train_epochs 2 \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 4 \ --output_dir ./shadow_model

这里有一个关键的batch size换算逻辑：batch size是4，gradient accumulation steps是4，有效batch size就是16。显存不够时，调小batch size、调大gradient accumulation，效果基本等价，但不要用太大的有效batch size，否则模型容易陷入局部最优。

训练过程中，我习惯每保存一个checkpoint，就在一个固定的验证集上对比生成效果。不要等全部训练完再看，那样如果方向跑偏，返工成本太高。验证集我固定放300条数据，覆盖正常、边界、对抗三类样本各100条。

4.2 评估指标：不要只盯BLEU

“恢复推理过程”的评估，和普通机器翻译、文本生成评估有很大区别。BLEU和ROUGE这类指标主要看字面重合度，但推理过程的特点是“表达可以不同，逻辑必须一致”。同一个推理逻辑，可以有十种不同的措辞，字面重合度很低，但每一步的思路完全一样。

我平时会同时看几个指标，各有侧重：

“步骤覆盖度”是我最推荐的一个指标。具体做法是：从闭源模型的推理过程中，人工抽取3到5个关键步骤关键词或关键条件，然后去检查开源模型生成的推理过程是否包含这些步骤。比如“3的平方”“4的平方”“25”“勾股定理”这几个关键词，如果开源模型的推理过程中都出现了，说明逻辑链条基本对齐。

4.3 人工评估维度与抽样策略

自动化指标只能帮我们筛掉明显不对齐的样本，真正的判断还是需要人工抽检。我会组织业务同事和算法同事一起，按下面四个维度打分：

• 逻辑连贯性：推理过程是否前后矛盾，是否存在跳步。
• 步骤完整性：关键推理步骤是否都覆盖到。
• 结论一致性：最终答案与闭源模型是否一致。
• 表达可读性：让人看时，能否看懂。

抽样策略上，我习惯“按错误分层抽样”。先跑一遍测试集，把开源模型输出与闭源模型输出不一致的样本挑出来，从中随机抽50条做深度分析。这些不一致的样本才是真正需要关注的，因为它们直接决定“恢复”的质量上限。如果一致性已经达到95%，剩下的5%大概率是边界case，我会有针对性地补充数据去优化。

5. 常见问题与排查技巧实录

5.1 模型学会了格式，但没学会推理

这是最常遇到的问题：开源模型输出的格式很像闭源模型，有“步骤1”“步骤2”，但里面的逻辑一塌糊涂，甚至前后矛盾。出现这个现象，多半是训练数据里“表面格式”和“推理内容”不成比例，模型学会了格式，没学会内容。

我的排查思路是先看数据质量。抽看训练集里的推理过程，如果发现大量推理过程本身就没有逻辑，模型当然学不到逻辑。解决办法是重新清洗：只保留那些“步骤之间相互支撑、结论与推理一致”的样本。另外，我还会在数据里加入一部分“负样本”，也就是故意让模型知道“某些推理是错误的”，帮助它区分好坏逻辑。

5.2 灾难性遗忘：底座知识被冲掉

有时候微调之后，影子模型在业务问题上的表现提升了，但回答常识问题、开放问题时反而变笨了，这就是灾难性遗忘。原因是训练数据太单一，模型把大量参数都用来拟合业务数据的特殊分布，忘了通用知识。

解决思路是“混入通用指令数据”。我在业务数据里混入10%到20%的通用指令数据，比如百科问答、常识对话、逻辑推理题。这样可以保证模型在学业务推理的同时，不至于忘记已有的世界知识。实践下来，混入通用数据后，业务场景的对齐度几乎不受影响，但通用能力保持得明显更好。

还有一个办法是降低学习率。学习率越大，对底座参数的冲击越强，越容易遗忘。我一般会先用2e-4跑一个很短的热身，再降到1e-4左右继续训练。

5.3 推理过程与闭源模型不一致的边界情况

这类问题很让人头疼：大部分样本都对齐了，但遇到某些特殊输入，开源模型的推理方向完全跟闭源模型不同。比如闭源模型在处理长文本时喜欢先总结后分析，开源模型却直接给结论。

碰到这种情况，我第一反应不是盲调参数，而是回头检查这类边界样本的数据量。如果训练数据里“长文本类”样本占比太少，模型就没有足够的轨道去模仿。补充更多同类型数据，比调任何超参数都有效。另外也可以尝试在提示语中显式加入“请先总结关键信息再分析”，引导模型学习这个偏好。

5.4 算力不够怎么办

微调大模型确实吃算力，但不是没有省钱的路径。如果只有一张消费级显卡（比如24G显存），我的建议是：

• 选7B-8B底座，用4bit量化加LoRA。
• 数据量先控制在2万条以内，跑通全流程。
• 用gradient checkpointing，把激活值存到显存之外。
• 减小序列长度，必要时把超过2048的推理过程截断。

这条路“能跑”，但要接受效果上限低一些。等验证了流程可行，再考虑租用更高配置的服务器做完整微调。

6. 踩坑之后，我对这套方法的三点体会

第一，不要追求100%还原。闭源模型内部一定有很多随机性、版本差异、甚至prompt层面的隐藏规则，这些东西无法被任何影子模型完整复现。我给自己定的目标是一致率80%到85%，覆盖主要业务风险场景就够了。超过这个目标，投入产出比会急剧下降。

第二，数据是永远的核心。很多人想靠一个更强的底座模型直接“猜”出闭源行为，但实际操作中我感受到，数据质量和覆盖面才是决定上限的变量。一套合理的数据采集、清洗、迭代流程，比调参重要得多。

第三，这个方法可以做成流水线。我现在已经把采样、清洗、微调、评估写成了半自动的脚本，每次闭源模型发布新版本，只需要跑一遍流程，新的影子模型就能自动更新。如果你要长期依赖某个闭源API做业务，强烈建议把这套“影子模型”机制沉淀下来，它不仅是审计工具，也是你脱离单一闭源依赖的备选方案。

最后再分享一个小技巧：定期记录闭源模型的输出版本，并在影子模型评估时保留上一版结果。这样一旦发现对齐度突然下降，可以先确认是不是闭源模型悄悄更新了行为，而不是直接怀疑自己的训练流程出了问题。