误报率、漏报率、可复现性：校准一个判定类 AI 到底要盯哪几个数
把 AI 用在「判定」而不是「生成」上的团队越来越多：这条线索够不够资格、这张图能不能过审、这条日志算不算异常、这个工单属于哪一类。判定类任务的共同点是输出极短、调用极多、错误代价不对称，因此它需要的评测方法与写文章完全不同。这里给一套可落地的最小集。
一、先把两类错误分开
任何判定系统都有两种失败方式，而且它们的代价从来不对称：
- 误报（假阳性）：把不该拦的拦了。对用户体验损失大、投诉多，通常金额可控。
- 漏报（假阴性）：把该拦的放过了。单次损失小，但一旦被外部发现，代价可能是数量级的。
很多团队把这两者合成一个「准确率」看，这是最危险的简化。95% 的准确率在误报与漏报之间的分布，决定了系统能不能上线。只看准确率的团队，往往在第一次事故后才意识到两种错误需要分别定阈值。
二、必须同时建立的两套样本
- 黄金集（golden set）：人工标注的固定样本，用来防止回归。每次改提示词或换模型，都跑一遍。
- 困难集（hard set）：把历史上所有被判错的样本收集起来，持续追加。它的价值在于边界样本往往是分布的绝大多数，随机抽样很难覆盖到。
只建黄金集不建困难集，是常见的资源浪费——系统会在常规样本上表现很好，在真正难判的地方持续出错，而团队看不到。
三、可复现性要当成一等指标
判定类 AI 有一个生成类任务没有的问题：同一个输入，两次调用可能给出不同结论。这不是 bug，是大模型的本性。
因此除了准确率，还要测：
- 同输入重复调用的一致率（至少跑 5 次）。
- 轻微改写输入后的结论稳定性（换一个同义词，结论是否翻转）。
后者尤其重要。如果改一个无关的词就让判定翻转，说明模型抓住的是表层特征而不是业务实质，这样的系统在生产环境里会极不稳定。
四、阈值是业务决策，不是技术参数
判定类模型的原始输出通常是概率，把它变成「通过/拒绝」需要一个阈值。这个阈值不该由算法工程师单独决定。
一个实用的做法是画一条曲线：横轴是阈值，纵轴同时画出误报率与漏报率。然后把业务方拉进来，让他们在曲线上指出「这两个错误里，我们更怕哪一个，怕到什么程度」。这条曲线是唯一能把技术语言翻译成业务语言的工具。
五、上线后的持续动作
- 抽样人工复核：比例可以随稳定性提升而下降，但不要降到零。撤掉人工前，先确认困难集的失败率已经稳定。
- 分布漂移监控：输入的实际分布会随季节、活动、业务变化而变。输入变了，原本调好的阈值大概率失准。
- 版本对照跑：换模型时保留旧模型的判定结果，做双跑对照，不要一次性切换。这一步多花的时间，通常能省下一次事故。
一个最小的落地清单
如果你今天就要为一个判定类任务建评测，按这个顺序做：
- 收集 200 条真实样本，人工标注，作为第一版黄金集。
- 分别统计误报与漏报，不合并。
- 每个样本重复调用 3–5 次，记录一致率。
- 画出阈值—双错误率曲线，拉业务方定阈值。
- 上线后每周抽样复核 30 条，判错的样本全部进困难集。
这套流程不复杂，但它把「感觉还行」变成了「有据可依」。判定类任务的问题从来不是模型不够聪明，而是团队不知道自己到底错在哪。
参考来源
延伸阅读：TEE + 透明日志 + 可复现构建：Google 把「可验证的联邦学习」装进了 Gboard · WordPress 自动更新到底要不要开启? 怕更新后主题崩掉。