AI 功能上线后，如何发现质量退化

AI 功能上线时通过验收，只能证明它在那批测试数据上可用。输入模板变了、产品加了字段、供应商更新了模型，原先的质量就可能守不住。原文给出的办法是：围绕输入、人工复核、回归测试和运行成本，建立一套持续监控。

这套建议适合已经接入 AI 分类、审核或答案生成的团队。它没有复杂的平台方案，也没有效果对照数据，但指出了一个容易漏掉的问题：没人看过的自动处理结果，才最可能藏着静默错误。

输入变了，质量告警就该提前响

作者把输入监控放在最前面，因为这是成本最低的预警。每天处理多少条、平均多长、语言占比如何、空值和格式错误占多少、各类别怎么分布，都应该和上线基线比较。

这些变化未必由模型造成。新产品上线、模板调整、上游数据源出错，都可能让模型接到不熟悉的数据。

下面这段代码用于检查各项指标相对基线的变化是否超过容忍范围：

def drift_alert(today, baseline, tol=0.25):
    return {k: abs(today[k] - baseline[k]) / max(baseline[k], 1e-9) > tol
            for k in baseline}

要看的是 tol=0.25，也就是相对变化超过 25% 时返回告警标记；1e-9 用来避免除以零。这只是一个简易检查，原文没有解释基线应取多长时间，也没有处理工作日与周末等周期差异。

人工接管少了，不一定是模型变好了

如果系统按置信度阈值决定是否自动处理，就要监控分数分布。置信度可以理解为系统给出的「有多确定」，但它未必等于答对的概率。

阈值以上的结果变少，人工接管就会增加，原来的成本估算可能失效。反过来，高分结果变多，却没有其他质量指标同步改善，也可能是模型变得过度自信。

作者建议每天记录转人工比例，并观察每周趋势。它应当大致稳定在试点阶段测到的水平，向任一方向偏移几个百分点都应关注。不过，「几个百分点」并不是经过验证的通用阈值。

另一个直接信号是人工改写率：审核人员多常修改模型提出的答案。要按类别拆开看，否则某个弱项很容易被总体平均值盖住。

转人工比例反映工作如何分配，人工改写率才更接近被审核结果的质量。

但这两项都有盲区：自动放行的结果没有经过审核。作者因此建议，每周从自动处理路径随机抽取 20 到 50 条，对照正确答案检查，记录结果并画出趋势。抽样必须随机，不能只挑用户投诉或看起来可疑的案例。

固定测试集和运行指标，要一起盯

黄金测试集（golden set）是一批固定、带有正确答案的样本，用来观察系统改动前后的表现。作者建议定期重跑，并在模型版本、prompt、阈值或上游数据发生变化时重跑，保存各版本得分。

如果输入没有变化，而固定测试集表现下降，就可以优先排查模型或 prompt。它帮助缩小排查范围，但单次掉分还不足以直接确认原因。

运行状态也属于质量监控：延迟、错误率、超时、队列等待时长、单条成本，以及 API 支出距离限额还有多少，都要跟踪。prompt 修改后 token 用量翻倍，即使答案质量没变，也是一种回退。

作者还安排了每月一次、每次 30 分钟的复盘：对照上线基线看趋势，检查抽样和审核队列中最差的 10 条结果，向黄金集补充 10 到 20 条新样本，再根据新标注决定是否调整阈值，并记录供应商与数据变化。

用户和审核人员也需要方便的反馈入口。反馈不适合直接估算错误率，却能暴露预先没想到的失败类型。每条告警还必须写清负责人和触发后的动作，否则它只是一条日志。

我的判断

我认同这套方案把「自动路径抽查」放进日常工作。只看人工审核记录，会漏掉系统最自信、也最少被人检查的那部分结果。

但原文是一份监控建议，没有给出团队实测结果或对照数据。每周 20 到 50 条抽样能帮助发现问题，未必足以估算低错误率任务的真实表现；按类别拆分后，样本还会更少。置信度从哪里来、是否经过校准，原文也没说清。

相比只看固定测试集，这套做法补上了线上输入和自动结果的变化。不过，固定黄金集与持续补充新样本之间需要版本管理：保留原有集合用于比较，再单独观察新增案例，否则得分变化可能只是题目变了。

能拿来做什么

• 给已有 AI 功能建立上线基线，先记录输入分布、转人工比例和人工改写率，并按业务类别查看。
• 每周从自动放行结果中随机抽取 20 到 50 条复核，保留抽样记录和判断依据，持续观察错误类型与趋势。
• 修改模型、prompt、阈值或上游数据时重跑固定测试集，同时核对 token 用量、单条成本和延迟。
• 把每项告警写成可执行约定，明确谁处理、先检查什么，并用每月 30 分钟复盘决定后续调整。