在很长一段时间里大家讨论大模型落地时重心都放在“提示词工程”。同一道题换个措辞效果可能天差地别。于是出现了各种长篇模板、CoT 链、Few-shot 示例堆叠。这种方法在小规模验证时很有效但一旦进入生产环境问题就暴露了上下文越来越长、单次调用越来越贵、推理延迟越来越高而且模型对提示词的微小扰动非常敏感。围绕这些问题业界开始尝试另一条路线把技能蒸馏进权重而不是写进提示词。这个思路的技术表达是 “Distill Skills into Weights, Not Prompts”其核心是让模型在训练阶段就把可复用的抽象技能内化到参数中推理时不再依赖冗长的提示词描述。本文将围绕这一主题拆解其中的关键概念抽象技能、特权信号、在线策略自蒸馏以及它们的组合方式。会先解释概念本身再给出一套可落地的训练流程示意最后聊一聊工程化过程中常见的坑。1. 背景提示词工程的边界在哪里1.1 提示词方案的三个硬伤先看一个典型场景。假设业务上需要模型完成“从用户对话中提取结构化订单信息”的任务。用提示词方案通常是写一段很长的描述告诉模型字段含义、抽取规则、输出格式然后在线调用时把这段描述拼到输入前面。这样做的第一个问题是Token 成本。描述本身可能占几百甚至上千 Token每次请求都要重复携带。如果业务流量是每天几百万次调用这部分开销会被急剧放大。第二个问题是上下文长度。提示词越长留给真实用户输入的空间就越少。尤其在需要结合多轮对话、历史记录、知识库片段时提示词模板和业务数据会互相争抢上下文窗口。第三个问题是稳定性。提示词本质上是在“约束”模型的行为但模型的注意力分布并不完全可控。顺序换一下、标点改一下、示例数量变一下结果可能就不一样。开发团队需要不断调试措辞维护成本很高。1.2 把技能固化到权重一种更本质的做法如果换个思路在离线训练阶段把“如何抽取订单信息”这个过程变成模型参数里的一种先验。推理时模型不再需要看到一段长描述而是直接“会做这件事”。这就是把技能蒸馏进权重。从工程角度看这种做法的优势非常直观推理时不再携带大量模板上下文更短成本更低技能的触发更加自动化不再依赖用户措辞碰巧命中提示词行为一致性由参数保证而不是由提示词临场约束。当然这条路也有代价训练成本更高、数据准备更复杂、模型迭代周期更长。因此理解其原理比复制一行代码更重要。2. 核心概念技能、特权信号与自蒸馏要理解 “Distill Skills into Weights, Not Prompts”先要理清三个概念抽象技能、特权信号、在线策略自蒸馏。2.1 抽象技能是什么技能Skill在这里不是指某个具体回答而是指“面对一类状态时采取的一系列决策动作”。它面向的不是单次问答而是可复用的行为模式。举一个例子在修 bug 的场景中“先定位日志异常、再缩小函数范围、接着修复并回归测试”这是一个技能在数据分析场景中“先了解字段语义、识别缺失值、分布异常再建模”也是一个技能。抽象技能Abstract Skill则是把这类行为模式从具体实例中提炼出来去掉细节只保留可迁移的策略骨架。比如“根据报错关键字搜索代码位置”这个技能既可以用于 Python 项目也可以用于 Java 项目。在蒸馏框架中抽象技能通常不是人工逐条编写的而是通过数据聚类、自动归纳或者由更强模型从轨迹中总结得到。2.2 特权信号Privileged Signals特权信号这个词来自机器人控制和模仿学习领域原意是指训练时可以利用、但推理时拿不到的信息。举一个直观的例子。训练一个自动驾驶模型时如果给模型看“障碍物的精确坐标”来学习避障这就是特权信号——真实部署时摄像头只能给像素给不了精确坐标。但在训练阶段这些信号可以加快模型收敛。放在自蒸馏场景里特权信号可以指全局最优策略给出的动作训练时对未来环境的“提前观察”由更大模型产出的高质量中间决策轨迹级别的人工标注反馈。关键是特权信号只在教师侧使用不进入学生模型推理时的输入。2.3 在线策略自蒸馏蒸馏Distillation通常指把大模型/教师模型的知识迁移到小模型/学生模型。而在线策略自蒸馏On-Policy Self-Distillation有几个特点教师和学生不是完全固定的训练过程中会同步更新训练数据是模型自己在环境交互/采样过程中产生的也就是在线策略学生不仅学教师的输出还从自身的探索反馈中学习并让技能逐渐内化。这种方式不同于离线蒸馏使用静态数据集它更接近强化学习中的自我对弈模型一边探索一边把探索到的好行为蒸馏进自己的参数。3. 为什么“蒸馏进权重”优于“写进提示词”前面讲了概念这一节做更细致的对比。可以用一张表快速看清楚两条路线的差异对比维度提示词方案权重蒸馏方案推理成本每次携带长模板Token 开销大无模板开销上下文更短推理延迟长上下文导致预填充耗时增加输入更短首 Token 延迟更低行为一致性受措辞影响波动较大参数固化稳定性更好技能维护模板散落在代码和配置中集中在训练数据和评估流程中可解释性可直接阅读提示词需要额外解释性工具更新代价修改提示词即可速度快需要重新训练/微调周期长泛化能力依赖提示词覆盖度技能抽象程度决定泛化边界从这张表可以看到提示词方案的最大优势是“快”改一行文本就能上线。而权重蒸馏方案的优势在于“稳”和“省”一旦技能固化生产环境里的表现会更可靠单位请求成本也更低。从技术演进的角度看两者并不是完全互斥的。很多团队的实际落地路径是先用提示词做原型验证验证技能的可行性后再收集数据、蒸馏到权重中最终在推理阶段去掉长提示词。4. 在线策略自蒸馏的技术框架理解了概念下面看具体的训练框架拆解。这里的框架不限定具体某个模型库而是给出通用的抽象结构方便读者对照自己的项目进行调整。4.1 整体流程整个训练流程可以分成五个阶段定义技能空间确定模型需要具备哪些可复用技能。这一步可以由专家梳理也可以用聚类算法从轨迹数据中挖掘。准备在线采样环境模型在任务环境中持续交互产生轨迹数据。这部分数据是“在线策略”的来源。生成特权信号在每条轨迹上利用教师模型或全局信息标注“该状态应该使用哪个技能”“这个步骤的理想输出是什么”。蒸馏训练学生模型不仅要学习复制教师输出还要学习“技能路由”——即在什么状态下选择什么技能。路由信息和技能执行一起被蒸馏进参数。评估与迭代用评测集验证技能是否真正内化并针对失败案例补充数据或调整技能空间。4.2 技能路由一个被忽略的关键模块很多初学者只关注“模型输出对不对”却忽略了一个更关键的问题模型怎么知道当前该用哪个技能在提示词方案中技能选择靠的是用户显式指定或者模型从上下文中自己判断。而在蒸馏方案中技能选择需要被“内化”成一个隐式的路由策略。这个路由策略的训练依赖特权信号。比如在训练数据中每个状态节点都被标注了“当前应执行技能 A”学生模型在学习时不仅要学会技能 A 的决策逻辑还要学会在相似状态下自动激活技能 A。从实现层面看这通常意味着模型需要额外学习一种“隐式意图识别”的能力。它不直接输出“我要使用技能A”这样的文本而是通过参数表达这种状态到技能的映射。4.3 蒸馏损失的设计思路蒸馏训练中损失函数通常包括两个部分。第一部分是输出蒸馏损失目标是让学生模型的输出分布逼近教师模型L_output KL( student_output || teacher_output )第二部分是技能路由损失目标是让学生模型在对应状态下激活正确的技能L_skill CrossEntropy( student_skill_logits, privileged_skill_label )在实际实现中两个损失会加权组合L_total alpha * L_output beta * L_skill其中 alpha 和 beta 是超参数。alpha 过大会让学生只模仿教师的“形”而忽略技能的抽象迁移beta 过大会让学生过度依赖技能标注失去在未知状态下的泛化能力。5. 实战示意搭建一个技能蒸馏训练流程这一节给出一个可运行的示意代码。说明一下由于不同团队使用的模型库、训练框架差异较大以下代码是伪代码风格的最小实现重点在于展示整体流程布局不能直接复制到生产环境运行。读者需要将其适配到自己的训练框架中。5.1 项目结构建议按下面的结构组织代码skill_distill/ ├── config.py ├── skill_lib.py ├── teacher_model.py ├── student_model.py ├── sampled_trajectory.py ├── train.py └── evaluate.py5.2 技能库定义# skill_lib.py # 技能库维护技能列表以及每个技能的描述 SKILL_LIBRARY [ { skill_id: 0, name: code_error_locate, description: 根据异常堆栈定位代码位置并给出修复建议 }, { skill_id: 1, name: data_quality_check, description: 检查数据集字段缺失、类型异常和分布倾斜 }, { skill_id: 2, name: sql_optimization, description: 分析慢查询执行计划并优化索引和SQL结构 } ]5.3 特权信号标注在采样轨迹中每个状态节点需要附带一个特权标签。这里用简洁的字典结构表示一个轨迹片段# sampled_trajectory.py # 一条在线采样轨迹的示例 trajectory { state: [ 用户输入: 系统报错 OutOfMemoryError, 当前代码堆栈: Java heap space, 运行环境: 生产环境批次任务 ], privileged_skill_id: 0, # 特权信号当前应该使用 code_error_locate 技能 teacher_action: 先检查堆栈中重复分配的对象再排查大对象缓存, reward: 1.0 }# 在 collect_trajectory 中特权信号来自全局信息或教师模型的离线标注 def collect_trajectory(env, teacher_model): observations [] state env.reset() done False while not done: # 教师模型根据特权信息给出动作 privileged_action, skill_id teacher_model.act(state, privilegedTrue) observations.append({ state: state, privileged_action: privileged_action, privileged_skill_id: skill_id }) state, reward, done env.step(privileged_action) return observations5.4 学生模型与训练循环# train.py # 在线策略自蒸馏训练循环示意 import torch import torch.nn as nn from skill_lib import SKILL_LIBRARY from sampled_trajectory import collect_trajectory class StudentModel(nn.Module): def __init__(self, vocab_size, hidden_size, num_skills): super().__init__() self.backbone nn.TransformerEncoder(...) self.output_head nn.Linear(hidden_size, vocab_size) self.skill_head nn.Linear(hidden_size, num_skills) def forward(self, input_ids): features self.backbone(input_ids) logits self.output_head(features) skill_logits self.skill_head(features) return logits, skill_logits def compute_distill_loss(student_logits, teacher_logits, student_skill_logits, privileged_skill_id, alpha0.7, beta0.3): # 输出蒸馏损失让学生的输出分布逼近教师 output_loss nn.KLDivLoss(reductionbatchmean)( nn.LogSoftmax(dim-1)(student_logits), nn.Softmax(dim-1)(teacher_logits) ) # 技能路由损失学习特权信号中的技能选择 skill_loss nn.CrossEntropyLoss()( student_skill_logits, torch.tensor([privileged_skill_id]) ) return alpha * output_loss beta * skill_loss def train_online(): env create_task_environment() teacher load_teacher_model() student StudentModel(...) optimizer torch.optim.AdamW(student.parameters(), lr1e-5) for step in range(10000): # 1. 在线采集 batch collect_trajectory(env, teacher) # 2. 学生模型前向 input_ids batch[state] student_logits, student_skill_logits student(input_ids) # 3. 教师模型前向教师使用特权信号 teacher_logits teacher(input_ids, privilegedTrue) # 4. 蒸馏损失 loss compute_distill_loss( student_logits, teacher_logits, student_skill_logits, batch[privileged_skill_id] ) # 5. 反向传播 optimizer.zero_grad() loss.backward() optimizer.step() if step % 100 0: print(fstep {step}, loss {loss.item():.4f})5.5 推理阶段的变化训练完成后推理阶段不再需要教师模型和特权信号也不再需要把技能描述写进提示词。模型直接根据用户输入内部完成技能路由和技能执行# inference.py # 推理时只需要学生模型和用户输入 def inference(student_model, user_input): input_ids tokenizer.encode(user_input) with torch.no_grad(): output_ids, _ student_model(input_ids) return tokenizer.decode(output_ids)这个阶段的核心区别是全程不出现技能描述文本也不出现长提示词模板。6. 常见问题与排查思路在实际应用中把技能蒸馏进权重的方案会遇到一些典型问题。这里整理一份排查清单。问题现象常见原因排查思路蒸馏后模型在通用任务上变差灾难性遗忘技能训练挤压了原有能力在蒸馏损失中加入通用任务数据或使用回放机制技能切换不准确该用技能A时用了技能B特权信号噪声大技能边界模糊检查标注质量细化技能定义增加过渡状态样本模型只会模仿教师输出无法举一反三输出蒸馏损失权重过高忽略技能路由调高 beta让技能路由损失发挥更大作用训练损失下降但推理效果波动大在线采样分布和推理分布不一致增加在线采样环境的多样性避免策略陷入局部最优技能库过大导致路由混乱技能数量过多区分度不足重新做技能聚类保持每个技能之间有明确边界训练数据不干净教师信号包含错误动作对教师输出增加置信度过滤低置信度样本不入库下面挑选三个最常遇到的问题展开说明。6.1 灾难性遗忘怎么解决技能蒸馏本质上是利用任务数据做持续学习。如果新技能数据占比过高模型在通用能力上的表现会明显退化。解决办法通常是在蒸馏数据中混入一定比例的通用语料或原任务数据使用参数隔离技术例如 LoRA 等低秩适配模块让技能相关的参数与原参数解耦定期回到通用评测集上做回归测试监控遗忘程度。6.2 技能边界模糊怎么办技能蒸馏的成败很大程度上取决于技能空间的划分。如果两个技能之间经常出现难以判断的样本学生模型学到的路由策略就会不稳定。遇到这种情况建议先回头审视技能定义本身。技能不是越细越好也不是越粗越好。判断标准是一个技能是否对应一套稳定、可复用的决策逻辑。如果某个状态下的决策逻辑经常有两种截然不同的走向说明它可能横跨了两个技能。6.3 在线采样的分布漂移在线策略蒸馏里学生模型在更新采样的轨迹分布也在变化。如果采样环境太单一模型很快就会过拟合到少数状态上如果环境太开放训练又很难收敛。一个折中的做法是用“课程学习”的思路先让模型在受限环境中训练逐步扩大状态空间。7. 工程化落地的几点建议7.1 先提示词验证再蒸馏权重对一个团队来说最稳妥的落地路径不是一上来就做权重蒸馏而是分两步走用提示词方案快速验证技能定义是否合理。把抽象技能写成提示词模板让模型在少量评测集上跑出基线效果。确认技能有效后再收集数据、构建蒸馏训练集把技能固化进权重。这样做的好处是可以在早期快速验证业务假设避免在训练上浪费大量资源。7.2 用评估集守住技能边界技能是否真正被蒸馏进权重需要一套专门的评估集来衡量。建议每个技能都有独立的评测用例并记录以下指标路由准确率模型是否在正确状态下触发正确技能技能执行成功率触发技能后任务是否顺利完成迁移能力在未见过的输入分布上技能是否依然可用。7.3 理智看待“提示词 vs 权重”的取舍有些场景依然适合提示词方案。比如技能内容频繁变动、单次需求不需要长期复用、或者对推理成本不敏感。而权重蒸馏更适合那些“长期稳定、高频复用、对成本和延迟敏感”的技能。一个比较务实的判断标准是同一个技能如果被调用超过一定次数就值得蒸馏成权重。具体阈值取决于团队训练成本与推理成本之间的平衡。7.4 数据质量优于模型结构设计最后想强调一点在这个方案里数据质量往往比模型结构更决定最终效果。特权信号标注是否准确、采样轨迹是否覆盖充分、技能划分是否合理这些因素叠加起来影响远大于某个网络层的设计。如果你准备在业务中落地这套思路建议从一个小而完整的技能开始。先选择一个边界清晰、数据容易获取、效果可量化的技能走通“在线采样 → 特权信号标注 → 蒸馏训练 → 推理部署”的全流程再逐步扩大技能库。训练过程中重点观察两条曲线一条是蒸馏损失的收敛情况另一条是技能路由准确率的变化。后者更关键因为它直接反映了模型是否真正学会了“在什么状态下用什么技能”。