AI 评估债务与事件管理
AI 信号与现实校验（2026 年 2 月 17 日）
今日信号
“评估”正在变成一种持续的生产纪律，而不是上线前的一次性仪式。
过去很多团队在“AI 时代”的发布方式大致是：
- 选一个模型，
- 跑几套离线 benchmark，
- 让懂的人做一些抽查，
- 上线，
- 然后指望出了问题再修补。
当模型只是被嵌在某个流程里的一项功能时，这种做法还能勉强成立。 但当模型变成流程本身（尤其系统具备工具调用、自主性或处在高风险场景）时，这就不够了。
正在发生的变化是：团队开始把评估看成生产控制回路，而不是一份报告。 不再只是“模型 A 是否比模型 B 强”，而是：
- 这次发布会不会让某些关键行为退化？
- 这次变化会不会提高升级处理、退款风险或安全事件？
- 这种系统在时间、用户分群、任务结构变化下的漂移轨迹是什么？
换句话说：评估正在靠近可靠性工程早就理解的东西——每天都在运行的护栏。
现实校验
多数组织其实并不知道“失败”长什么样，直到客户把它指出来。
问题不在于大家不重视评估。 真正的难点是：生产环境里的失败是多维度的，而很多团队只有一把尺（比如“准确率”或“胜率”）。
很快会暴露出三类缺口：
1）离线“质量”并不等于运营层面的正确性。 一个模型可以分数很高，却仍然：
- 在边缘情况下违反政策，
- 在“罕见但代价极高”的场景里自信地胡说，
- 或者采取“看起来合理”但运营上错误的工具动作（例如关错工单、发错收件人）。
2）成功必须用业务形状来定义，而不是用模型形状来定义。 如果你无法把失败表达成类似下面这种可落地的规则：
- “这类回复会触发合规升级处理”，
- “这类动作不可逆，必须有人类批准”，
- “这类输出会改变财务决策”， 那么评估套件最终就会变成知识竞赛。 模型可能“更强”，但产品却变得更危险。
3）不接入发布门禁的评估，最终都会变成‘博物馆’。 团队会收集很漂亮的数据集和仪表盘……然后在压力下照样周五发版。 如果评估不能像测试阻止坏构建那样阻止退化，它就会在真实节奏里被忽略。
这背后的核心模式是：当你对评估纪律投入不足，你得到的不只是“质量变差”。 你会积累评估债务（eval debt）——它会在之后以事故、回滚、紧急改提示词，以及用户信任的悄然流失的形式体现出来。
二阶推演
我们会看到“SRE 风格”的评估运营：金丝雀、预算、以及针对模型行为的复盘机制。
最佳实践的方向会非常“无聊”，但正是这种无聊才可靠。 重点不在于不断发明新的 benchmark，而在于把真正重要的评估运营化：
- 针对模型/提示词/工具链变化的金丝雀发布
- 行为型 SLO（例如升级率、拒答质量、工具动作正确率）
- 针对高风险行为的错误预算（预算没烧完可以快跑，烧完必须放慢）
- 把模型失败当成系统失败来做复盘（数据、策略、UX、监控），而不是简单归结为“模型很笨”
一个很有用的心智模型是：如果你的系统能够执行动作，评估就不是“QA”。 它是变更管理（change management）。
未来 24–72 小时观察点
- 团队是否会更清晰地提出并采用评估分类法（政策、工具使用、推理、事实性、UX）？
- 评估是否更像 CI/CD 的一等公民（能阻止合并，而不只是一个仪表盘）？
- 是否会看到更多“影子模式（shadow mode）”部署：新代理先在生产旁路运行并评分，通过后再获得执行权限？
参考
- NIST AI 风险管理框架（AI RMF 1.0）：https://www.nist.gov/itl/ai-risk-management-framework
- OWASP LLM 应用 Top 10：https://owasp.org/www-project-top-10-for-large-language-model-applications/
- Google SRE Workbook（错误预算与发布门禁概念）：https://sre.google/workbook/alerting-on-slos/