学生模型上线后，离线测试集不会跟着真实业务一起变化。用户输入变长、任务比例改变、新文档格式出现，都会让原来的评测结论逐渐失去解释力。漂移监控要回答两个问题，线上输入和基准期相比发生了什么变化，这些变化是否已经影响质量、资源和回退。只看请求量或平均分，无法完成这项工作。
先建立可以比较的基准
上线前保存一段经过脱敏和分类的基准输入，记录任务类型、来源、长度区间、语言、风险等级和格式特征。字段应当服务于实际判断，不必一次收集所有信息。抽取任务可以重点看文档来源、字段数量和文本长度，分类任务可以看类别比例，高风险问答还要看时效要求和拒答类型。
基准必须绑定模型、路由、提示词和服务版本。若输入没变，模型版本却已经更新，质量变化就不能归因于数据漂移。监控记录中至少保留观察窗口、样本量和版本编号，小流量阶段的单日波动不要直接写成趋势。基准也不是永远固定，业务确认新分布已经稳定以后，可以建立新基准，同时保留旧基准供历史比较。
漂移指标要连到失败样本
输入长度、类别比例和来源分布可以用统计指标观察，但指标偏移本身不等于模型已经失效。某类长文档增加以后，学生可能仍然表现稳定。正确顺序是先发现分布变化，再从变化最大的分层抽取样本，检查严重错误、格式失败、回退和人工纠正。
线上质量不能只靠模型评审。结构化任务优先使用规则和参考字段，代码任务运行测试，开放式生成可以由模型辅助筛选，再让人工复核高风险样本。教师输出也不能直接充当真值。若学生与教师同时出错，应回到业务规则或人工答案确认。
把监控变成触发动作
每个漂移指标都要对应动作。轻微偏移可以增加抽样，连续多个窗口偏移且质量下降时，暂停扩大流量并缩小学生职责。若新来源已经成为稳定业务，可以补充独立测试集、更新训练数据，再进行版本评测。线上样本进入训练前需要脱敏、去重和人工或规则验收，不能把生产日志直接倒回训练集。
多模型比较阶段，147AI可以作为统一API候选入口，帮助记录教师调用和消耗。漂移计算、生产日志、样本脱敏和触发规则仍由项目方维护，平台调用记录不能代替输入分布监控，也不能自动判断模型是否需要重训。
定期复核监控本身
监控字段也会过时。业务新增任务后，旧的类别字段可能把新请求全部归入其他，指标看起来稳定，实际信息已经丢失。每个版本周期抽查一批原始样本，确认分类规则仍能解释输入。告警过多却没有实际质量问题，可以调整窗口或阈值；告警从不触发而人工问题持续增加，则要补充新的观察项。
一套有效的漂移监控，最后留下的是分布变化、失败样本、处理动作和验证结果。它不追求把所有变化压成一个分数，而是让团队知道什么时候继续观察，什么时候缩小范围，什么时候需要重新准备数据。
区分数据漂移与服务异常
线上质量下降时，输入分布变化只是候选原因。推理框架升级、路由规则修改、超时设置变化和日志采集缺失，也可能让同一批输入得到不同结果。排查时先固定一小批失败样本，用当前模型分别在离线环境和生产配置中重跑。如果离线结果稳定而线上失败集中，应该优先检查服务与路由，避免把系统问题错误归因给数据。
还可以保留一个不随业务更新的固定探针集。它不负责代表全部线上流量，只用于判断相同输入在不同版本中是否变化。固定探针稳定、近期样本退步，说明新分布值得重点检查；两组同时退步，则要回看模型、评测器和服务配置。两种证据并列，比只盯一条漂移曲线更容易定位问题。
误报也要复盘。某个来源比例变化很大，但抽样质量没有下降，可以继续观察，不必立即重训。若告警长期没有对应动作，应调整分层、窗口或阈值。监控的目标是减少错误决定，告警数量本身不代表治理做得更好。
工程上还要处理监控缺失。日志采集失败、任务标签为空或样本量突然下降时，仪表盘可能显示一切稳定。把数据完整度本身设为检查项，记录每个窗口实际收到多少请求、多少请求能成功分类。输入统计不完整时，质量结论标记为待确认，不能继续沿用上一窗口的判断。
漂移报告最好能回到请求级证据。汇总图负责提醒，样本编号负责解释。一次告警关闭前，写清抽查范围、是否影响业务、采取了什么动作以及何时再次复核。这样监控不会停留在看曲线，而会成为模型维护的工作入口。