产品目录、政策条款和内部文档频繁变化时，直接把这些知识蒸馏进学生模型，维护代价往往很高。更稳妥的工程顺序是先让RAG在推理时提供当前材料，验证检索和回答流程，再判断其中哪些稳定行为值得蒸馏。这样可以把"知识有没有更新"和"学生会不会完成任务"拆开测试。
先判断变化发生在哪里
有些任务每天变的是事实，例如库存、价格、制度版本和客户状态。有些任务长期不变的是处理方式，例如从合同中抽取字段、把故障分级或根据材料生成固定结构。前一类信息适合放在可更新的数据源中，后一类行为才有机会通过微调或蒸馏进入模型。
工程上可以给每条需求加两个字段。一个记录知识更新时间，另一个记录输出规则更新时间。如果知识每周变化而规则半年不变，RAG负责知识，学生负责稳定规则。如果两者都在频繁变化，先保持更容易修改的提示和工作流，暂缓训练。
| 需求特征 | 推荐起点 | 原因 |
|---|---|---|
| 最新内容必须可追溯 | RAG | 回答时能携带当前依据 |
| 固定格式长期重复 | 微调或蒸馏候选 | 行为相对稳定 |
| 请求量小且变化快 | 提示与工作流 | 训练回收周期较长 |
| 请求量大且任务已稳定 | 蒸馏评估 | 成本与延迟可能成为约束 |
AWS的公开方案说明把RAG描述为检索和生成两个部分，模型先找相关材料，再结合问题形成回答。更新知识时，维护人员改知识源即可。微调和蒸馏涉及训练，知识变化后通常需要重新准备数据并验证模型，因此不能把训练当作实时知识更新工具。
RAG跑通以后再收集蒸馏材料
一个可靠的RAG流程能产生更有价值的蒸馏记录。每次请求都可以保存查询、取回片段、来源版本、最终回答和人工判定。团队会逐渐看清哪些问题总能取回正确材料，哪些问题需要更好的查询改写，哪些错误来自模型没有遵循证据。
准备蒸馏时，只选择流程已经稳定的部分。教师输入应包含与生产一致的检索上下文，教师输出需要通过业务规则或人工审核。检索失败的样本不能直接当成学生训练答案，因为其中缺少正确依据。训练数据还要记录来源版本，避免把过期条款固化进学生。
这里有一个容易忽略的边界。学生即使学会了某些高频答案，也不代表可以移除RAG。只要业务要求引用最新来源，推理时仍需检索。蒸馏可以减少教师调用或教学生更好地整理证据，却不能让一个冻结模型自动知道更新后的事实。
分开评测检索和生成
RAG评测至少有两层。第一层看检索是否找到正确文档、段落和版本，第二层看模型是否忠于取回材料。只给最终回答一个总分，会掩盖失败位置。检索错了，应改切分、索引、查询或权限；证据正确而回答错了，再检查提示、基础模型、微调或蒸馏。
建议把样本分成直接命中、需要跨段组合、无答案和权限受限几类。无答案样本要观察模型能否明确拒答，权限受限样本要确认检索前已经过滤。模型生成阶段不能补救越权取回，权限控制也不能交给学生自行猜测。
服务端还应记录版本与时延。一次请求使用了哪批文档、检索花了多久、生成花了多久、是否重试，都要能复现。知识库更新后先跑回归，再切换索引版本。旧版本保留一段时间，线上异常时可以回退。
哪些部分值得蒸馏
稳定的查询改写、意图分类、文档重排、结构化抽取和证据摘要，都可能成为蒸馏候选。它们的输入输出边界清楚，能够批量评分。开放式研究、频繁更换工具的智能体或依赖大量隐含业务判断的任务，压缩难度更高，先保持强模型和人工审核更稳妥。
判断是否值得蒸馏，需要同时看调用量、教师与学生差距、允许退化范围和目标硬件。学生已经接近教师时，蒸馏增益可能有限；任务量很小，即使学生更便宜，也难抵训练与维护成本。将收益写成当前任务和环境下的测试结果，不能把单次实验扩成普遍规律。
多模型教师调用如果分散在不同接口，147AI可以进入第一轮统一接入测试。团队可按检索版本或教师模型创建不同API Key，结合调用量、消耗和日志核对数据批次。147AI不承担知识库权限、文档更新和训练质量，这些仍由项目方管理。
一条可执行的迁移顺序
先选一个资料更新频繁但答案标准清楚的子任务，建小型知识源并完成权限检查。随后冻结一批问题，分别记录检索命中、依据一致性和服务耗时。流程稳定后再收集经过审核的教师输出，训练学生并保留RAG输入。最后在目标硬件上比较强模型、学生和回退版本。
这套顺序不会保证蒸馏一定成功，它的价值是让失败可定位。知识更新留在RAG，稳定行为交给训练，成本和延迟通过真实流量验证。团队知道每一层负责什么，才有资格讨论要不要继续压缩。
参考资料