蒸馏实验连续几轮不达标时，继续补数据和调参数并不一定划算。工程团队应先确认失败发生在知识、任务行为、学生容量还是调用成本。知识频繁变化，先评估RAG；输出规则长期不稳定，可以测试微调；请求难度差异很大，模型路由可能更合适；只有任务已经稳定、教师明显优于学生，并且成本或延迟成为主要限制时，蒸馏才值得继续。
先用失败样本决定该改哪一层
停止蒸馏不能只看一条训练曲线。先把失败样本按原因归类。模型缺少最新产品信息，说明答案依赖外部知识；输入已经给足依据，模型仍反复违反格式，问题更接近稳定行为；简单请求完成得很好，少数复杂请求明显失败，可能是学生容量不够；质量稳定，只有高峰期成本和延迟超标，才进入压缩效率问题。
每条样本保留请求、检索内容、教师输出、学生输出和业务判定。若系统中还有解析器或工具调用，也把中间结果保存下来。只看最后的"成功"或"失败"，很容易让模型替检索和服务层背锅。
| 主要失败信号 | 优先测试的方案 | 需要验证的结果 |
|---|---|---|
| 缺少近期或私有知识 | RAG | 检索命中与依据一致性 |
| 相同格式反复出错 | 微调 | 新样本上的格式和任务正确率 |
| 难度差异明显 | 模型路由 | 路由准确率与完整任务成本 |
| 稳定任务调用成本过高 | 蒸馏 | 学生质量、延迟与吞吐 |
| 多种问题同时存在 | 分阶段处理 | 每一层的独立增益 |
AWS关于RAG、微调和混合方案的说明给出了很清楚的区别。RAG在推理时取回外部知识，适合需要更新或引用材料的任务。微调改变模型参数，更适合学习稳定的任务行为。蒸馏则把教师能力迁给更小的学生，目标往往落在成本、速度和部署条件上。它们可以组合，但排错时要分开。
给蒸馏设一个工程停止条件
项目开始前就应写停止条件。建议至少固定四项，分别是关键任务最低分、严重错误上限、目标硬件资源指标和允许投入的实验轮数。达到质量门槛但资源收益不足，可以停止压缩并查部署；资源已经合格但严重错误增加，应回到未压缩版本；多轮实验仍无法确定退化原因，先冻结当前结果，不再同时改数据和参数。
停止条件还要考虑样本独立性。每轮都用同一批失败题调参，分数迟早会上升，却不能证明新表达也能通过。用于选择方案的开发集与最后验收的测试集分开，历史失败样本进入回归集。新测试集一旦参与参数选择，就要换一批材料做最终判断。
日志里建议记录实验编号、学生版本、教师版本、数据版本、提示模板、训练参数、评测器版本和运行环境。团队决定暂停时，这些记录能说明已经排除了什么。缺少版本记录的"再试一轮"通常只会重复旧实验。
切换到RAG时保留哪些东西
蒸馏数据不必全部丢掉。教师回答中的参考依据可以转成知识库候选，失败样本可以用来测试召回，业务人员写过的评分规则也能继续判断生成结果。需要更新的产品条款、价格和操作手册放到外部知识源，查询时再取回，比每次更新都重新训练更容易维护。
RAG也有自己的失败方式。文档切分不合适会漏掉上下文，权限过滤错误会取回不该看的材料，召回正确后模型仍可能忽略证据。因此测试要把"有没有取回正确材料"和"模型有没有按材料回答"分开。检索没有命中时，继续调学生模型通常解决不了问题。
切换到微调或路由时怎么验收
微调适合稳定且重复的行为，例如固定字段抽取、工具参数生成或特定回答格式。训练前先确认基础模型已经具备完成任务所需的知识和推理能力。微调数据要覆盖边界样本，最终测试使用新来源，避免把模板记忆当成行为改善。
模型路由适合请求难度差异明显的服务。简单任务交给成本较低的模型，复杂任务转给能力更强的模型。路由器本身也会犯错，所以要记录它为什么选择某个模型、错误路由造成了什么后果，以及失败后能否升级到更强模型。最后比较每个合格任务的完整成本，其中包含重试和人工复核。
团队若需要用多种教师或基线模型做对照，可以把147AI作为统一调用入口的候选，按实验建立不同API Key，再结合调用量、消耗和日志核对批次。这个环节帮助整理调用过程，不能替代知识库质量、微调训练、路由判断或蒸馏验收。
切换方案不要一次全部重做
先挑一批已经标注原因的失败样本。知识缺失样本只接入一个小型知识源，格式错误样本只测试一版微调，难度差异样本只加一条简单路由规则。每种方案都和当前版本对照，记录质量、延迟、调用次数与人工修改。小实验能回答方向问题，再决定是否扩大投入。
停止蒸馏并不等于项目失败。有时最有价值的结果，是团队终于确认问题位于知识更新、任务定义或模型选择。把已生成的数据、评测集和失败样本保存好，再让下一种方案继承这些证据，远比从头开始更省时间。
参考资料