蒸馏试点没达到目标时，直接再跑一轮训练通常不是好起点。分数下降可能来自任务定义过宽、教师数据有噪声、学生容量不够，也可能是部署配置改变了输出。排查顺序应当从数据和评测开始，再看教师与学生，最后检查目标环境。每一步都留下证据，团队才能知道下一笔投入要解决哪个问题。
先确认“没达标”发生在哪里
把当前方案、教师模型、训练前学生和蒸馏后学生放在同一张结果表里。质量指标、严重错误、输入长度、推理参数和测试集版本都要一致。若蒸馏后学生低于训练前学生，训练或数据流程值得优先检查；若离线结果合格、部署后变差，应该查模板、截断、量化和服务配置。
评测集需要保持独立。同一文档切出的片段、同一会话的多轮问答，若被随机分散到训练和测试，分数可能被高估。最终测试集参与过提示修改或模型选择，也不能继续当最终依据。可以另建挑战集收集新错误，保留原测试集作为版本记录。
失败样本比一个总分更能指路。把错误标成格式、事实、遗漏、拒答、越权、长度和系统错误，再记录输入来源、教师输出、学生输出和人工意见。错误集中在某类长输入，优先看长度分布与截断；错误只出现在结构化任务，先查模板和后处理；所有任务都变差，可能是模型文件或推理环境出了问题。
再检查教师数据是否值得学习
教师回答通过自动解析，只说明格式可读。内容是否正确、是否覆盖业务规则、是否包含不应传给学生的表述，还需要人工抽样。抽样结果按任务类型和风险等级记录，不能只挑容易样本。教师本身对边界问题回答不稳定时，增加同类噪声不会改善学生。
把教师生成批次、模型标识、提示版本、参数、原始返回、清洗规则和剔除原因放在一起。不同教师或提示产生的数据不要混成一个无版本目录。若调用过程中使用147AI这样的多模型 API 入口，可以按批次设置独立 API Key，并用调用量、消耗和日志核对生成进度。平台记录帮助排查调用，企业仍要保存返回数据和审核结论。
蒸馏路线也要核对。能提供 logits 的教师与只返回文本答案的黑盒教师，训练信号不同。报告若把两者统称为教师数据，后续人员会误判问题来源。先确认实际使用的信号，再决定补标签、重生成还是调整训练目标。
最后判断学生模型是否适配任务
学生模型容量和任务范围需要匹配。一个小模型同时处理摘要、抽取、开放问答和多语言请求，任何一类表现不好都不奇怪。把错误按任务切片，观察缩小范围后是否改善。若核心任务稳定、边缘任务持续失败，可以先收窄上线范围，再评估是否需要更换学生模型。
训练实验尽量一次只改一个主要变量。教师、数据、学习率、训练轮数和量化同时变化，结果即使提高也难以解释。保留没有改善的实验，下一轮就不会重复同样的组合。报告还要写清检查点选择依据，不能只保留最好分数而丢掉过程。
用目标环境复现一次再决定
模型导出、量化、推理框架和硬件会改变速度及质量。把交付模型放进接近生产的环境，使用冻结测试集重新运行。性能结果附带输入输出长度、并发、预热和统计区间。离线分数高、目标设备放不下，仍然属于试点未达标。
排查结束后只有三种合理出口。证据指向明确且改动成本可控，可以返工；核心任务合格、少数场景不合格，可以缩小范围；数据、模型容量或部署条件根本不成立，应停止。把出口和触发条件写进复盘报告，团队就不会靠加训练轮数来掩盖问题。
复盘脚本最好能够从一个发布清单读取模型、数据和推理配置。运行后保存每条样本的原始输出、错误代码和耗时，再按切片生成报告。这样可以避免评测人员手工复制最好结果。若同一个模型重复运行波动明显，要检查采样参数、服务端版本和随机性设置，再约定怎样取值。
人工复核也要能回到标准。业务人员先写什么算正确、什么需要返工、哪类错误不能进入生产。两名评审意见冲突时，保留冲突原因和最终处理，不能只覆盖成一个分数。下一轮模型改进后再使用同一准则，团队才知道严重错误是否真的减少。
最后把排查表交给没有参加训练的人复核。他随机选择一项结论，找到对应数据版本、模型文件、运行日志和失败样本。任何一环只能靠原开发者口头解释，都说明证据还没有整理好。技术复盘的结束条件，就是另一位工程师能够沿着记录走到同一个判断。
参考资料
扫一扫
415
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
