企业 AI 上线之后：系统是怎么安静地退化的
企业 AI 项目最典型的失败，不是上线失败。
是上线成功，然后在三到六个月里安静地失去准确性，而没有任何人发现。
它不报错、不宕机、不告警。它只是答得越来越不对，直到某天有人说"这东西不好用了"——那时候已经没人知道是从什么时候开始的。
这篇讲清楚退化从哪来、怎么发现、以及一个够用的运营机制。
---
退化的四个来源
| 来源 | 怎么发生的 | 会不会报错 |
|---|---|---|
| 资料过期 | 业务变了，资料没跟着变 | 不会 |
| 问题分布漂移 | 用户问的东西和上线时不一样了 | 不会 |
| 依赖变更 | 上游系统改了字段、接口、格式 | 有时会 |
| 模型或服务变更 | 服务商更新了模型版本 | 不会 |
四个里有三个完全不报错。这就是为什么传统的系统监控（可用性、响应时间、错误率）在这里几乎没用——它监控的是"能不能用"，不是"答得对不对"。
---
第一个来源：资料过期（最常见）
业务在变，资料不变。
具体表现：一份三个月前的政策被当成现行的答出去，而它已经改了。
为什么发现不了：回答本身完全通顺，出处也真实存在——它只是过期了。除非提问的人恰好知道正确答案，否则没人会发现。
一个可以量出来的判据：每季度抽 20 份该场景用到的资料，逐份问业务方"这份现在还有效吗"。答不上来的超过三分之一，说明资料时效已经失控——此时系统的准确率一定在下滑，只是还没人察觉。
唯一有效的处理：
1. 每份资料必须有生效日期和负责人
2. 定期由业务方复核——不是全量，是抽样
3. 变更有推送机制——业务方改了制度，要能触发资料更新
第三条是根治，前两条是兜底。
---
第二个来源：问题分布漂移
上线时测的是那 200 道题，三个月后用户实际问的可能已经完全不同了。
具体表现：固定测试集上跑分依然很好，实际使用中却越来越多人说不准。
一个参考的观察窗口：上线后 3–6 个月，用户实际提问的分布通常已经和上线时的假设有明显差异。这不是异常，是常态——需求本来就在变。
为什么会这样：测试集反映的是设计时的假设，不是现在的现实。
处理方式：
- 定期从真实提问里抽样，补进测试集——建议每月 20–50 条
- 观察"未命中"的问题——用户问了但系统答不上来的，正是需求变化的信号
- 测试集要有版本——扩充后旧版结果要保留，否则分数没法比
一个容易踩的坑：只往测试集里加"答错的题"。那会让测试集越来越偏向难题，分数持续下降，看起来像系统在退化——其实是尺子变了。扩充测试集要按真实分布抽，不能只挑错的。
---
第三个来源：依赖变更
上游系统改了字段名、改了返回格式、换了接口版本。
这一类有时会报错，有时不会——最麻烦的是"不报错但值变了"：字段还在，含义变了。
处理方式：
- 对关键字段做取值范围和格式的校验，不只是"字段在不在"
- 变更通知机制——上游改东西要能通知到
- 定期跑一次端到端的实际查询，而不只是接口连通性检查
最后一条是关键。很多监控只查"接口通不通"，而接口通着、返回的数据已经没意义了，是最难发现的一类。
---
第四个来源：模型或服务变更
如果用的是外部服务，服务商更新模型版本时，同样的输入可能给出不同的输出。
处理方式：
- 固定测试集定期重跑，这是唯一能发现这类变化的手段
- 如果服务支持指定版本，在生产环境固定版本，升级要主动而不是被动
- 变更后要在固定测试集上对比新旧结果，不能默认"新版本更好"。实践中，模型版本更新导致某些特定类型问题表现下降的情况并不罕见——整体分数持平，某一类明显变差，只看总分会完全错过
---
一份够用的监控清单
不需要复杂的系统，四件事定期做：
| 频率 | 做什么 | 判据 |
|---|---|---|
| 每周 | 看未命中问题清单 | 有没有新出现的问题类型 |
| 每月 | 固定测试集重跑 | 四项指标（见下）有没有下滑 |
| 每月 | 抽样 20–50 条真实回答人工复核 | 有没有事实性错误 |
| 每季度 | 业务方抽查资料时效 | 抽 20 份，问"还有效吗" |
指标口径沿用开源评测框架 RAGAS（docs.ragas.io）：上下文召回率、上下文精确率、答案忠实度、答案相关性，四项分开量。
为什么必须分开：指标下滑时要知道该修哪里。忠实度掉了是模型在编；召回率掉了是资料或检索出了问题；精确率掉了是噪声变大。混在一起看，只知道"变差了"，不知道往哪修。
---
最便宜的预警信号：用户反馈
上面那些都要花人力。有一个几乎不花钱的信号：用户说答错了。
但它有个前提——用户得愿意说。
用户会停止反馈的原因只有一个：说了没用。
所以反馈机制必须闭环：
1. 有地方说——回答旁边一个按钮就够
2. 有人接——明确责任人，不是"提交到系统"
3. 有时限——比如三个工作日内处理
4. 修完要通知反馈的人
第四条决定了会不会有第二次反馈。没有它，反馈量会在几周内归零——而那时候你会以为"没人反馈说明系统很好"，实际上是失去了唯一免费的质量信号。
---
运营责任怎么定
四件事必须落到具体的人：
| 事项 | 谁负责 | 要求 |
|---|---|---|
| 资料更新 | 懂业务的人 | 必须是人名，不能写"IT 部门" |
| 测试集维护 | 项目负责人 | 每月扩充，保留版本 |
| 指标监控 | 技术方 | 每月出一次对比 |
| 反馈处理 | 明确的接口人 | 有时限，要闭环 |
第一行是最关键也最常出错的。
为什么不能写"IT 部门"：IT 不懂业务，判断不了哪份文档过期了。这是知识治理里最常见的责任错配，而它的后果是资料从此再没人更新。
---
一个务实的建议
把运营成本写进第一年的预算，不要当成"上线后再说"。
一个粗略的参考：运营的持续投入通常不小于建设投入的两三成（按年算），主要是人力——资料更新、测试集维护、反馈处理。
没有预留这部分的项目，通常会在半年后进入"没人管"的状态：系统还在跑，但资料是半年前的，没人重跑测试，反馈没人接。
这种状态比系统宕机更糟，因为它看起来还在正常工作。
---
相关阅读
- 企业知识库怎么做，才不会变成资料坟场
- 企业 AI 的数据治理：治什么、治到什么程度、谁来治
- 企业 AI 项目怎么验收：七层验收标准与证据要求
- 企业 AI 项目多少钱：把预算拆成四段再谈价
---
*本文说明的是方法与判断标准，不代表任何未公开项目的实施细节。文中引用的开源评测框架，出处已在正文标明，读者可自行核验。*