AI 功能上线后效果漂移，排查与监控方案

AI 功能有个和传统软件不一样的地方：代码一行没改，效果自己会变。上个月还准得不像话的分类器，这个月开始间歇性犯浑，日志里一切正常，测试用例也全是绿的。这种漂移现象在企业用 AI 的场景里非常普遍，而多数团队对此没有任何准备。这篇给出漂移的成因归类和一套最小监控方案，都是可以直接落地的做法。

漂移从哪来

归成三类，排查方向完全不同。

输入漂移排第一。你的系统没变，用户的输入变了。新上了个活动，涌进来的问题就换了一批；业务部门改了个表单，字段格式全变了；客服团队换了话术模板，提交过来的工单文本都不一样了。模型本质是对输入模式做匹配的系统，输入分布一移，它的表现跟着移。

模型侧变化排第二。注意"同名模型"不等于"同一个模型"，服务方对模型版本做静默更新是行业内常见做法，参数没变，行为可能有细微变化。另外下游的推理参数（温度、top_p）被人悄悄改过、服务框架升级过，都是可能的原因。

数据和链路排第三。检索库更新了（知识库换了一批文档，向量检索的结果跟着变）、后处理规则改过（把某类合法输出误判成异常）、上游的预处理有 bug（日期解析在跨月那天集体出错）。这类问题的特征是影响面整齐，同一条件下的请求集中出错。

怎么发现：三层监控

没有监控的团队，发现漂移靠的是客户投诉，这条路径太慢。三层监控，从便宜到贵。

第一层是流量侧指标，成本近似为零，先上。输入长度分布、意图分类的分布、请求来源构成、按小时的量曲线。这些指标不直接反映效果，但它们的变化是漂移的先行信号，输入分布动了，效果大概率也要动。给每个指标设个基线和警戒带，偏离了先看一眼，多数时候能提前几天预警。

第二层是线上效果代理指标。没有人工标注也能测的东西：用户对结果的直接反馈（点赞/踩、是否追问、是否重新编辑）、流程层的信号（AI 的结果被下游采纳的比例、被人工修改的比例、重试率）。改稿率、追问率这类指标特别灵敏，它们从 5% 爬到 15%，比任何评测分数都早地告诉你"它变差了"。

第三层是定期回归评测，这层的量最准也最重。固定一批评测样本（从历史真实流量里分层抽，几百条），每周或每两周跑一次，打分记录入库画趋势线。有了这条线，"效果漂移"从感觉变成了曲线，而且能把环境因素排除掉，评测样本固定，只有模型和链路的变量在动，跑一次分数掉没掉，一目了然。

发现了之后怎么排查

按"输入—模型—链路"的顺序二分。先看输入侧监测，分布有没有动，动了就先处理业务侧的适配问题；输入没动，用同一批评测样本回放历史版本和当前版本，看是不是模型侧的变化，同时核对服务方的版本公告和推理参数记录；两者都没问题，再顺着链路的改动记录查，检索库最近更新过什么、后处理规则谁改的、上游预处理有没有发版。

这套二分顺序的价值在于，它把排查从"凭经验猜"变成"按层排除"，每次多花十分钟定位，就少一个小时翻代码。

最后

漂移监控这套东西，最好的建设时机是上线时，其次的时机是现在。最小可用的版本就是三层里的第一层加第三层：输入分布的监测，加上固定评测集的定期回归，一两个星期的工时，挡住的是最贵的那类静默退化。

另外给自己留个制度性的动作：把评测集和推理参数也纳入版本管理，像管代码一样管它们。漂移排查里最耗时间的，往往不是找不到原因，是说不清"原来是什么样"。