给 AI 幻觉设一个「错误预算」：Grafana 把 SRE 那套搬到了智能体上

线上服务的可用性有 SLO，告警阈值有错误预算，这套方法论支撑了云原生十年。现在有人问了一个更刁钻的问题：如果一个系统一直在线、响应很快、也不报错，但它的答案越来越不靠谱，你用什么指标发现它？

Grafana Labs 给出的答案是：把智能体的行为本身当成可测量的服务，用评估产出指标，用 SLO 设阈值，用错误预算做决策。

一分钟速览

• 问题：传统可观测性只能告诉你响应快不快、有没有报错、烧了多少 Token，说不清答案对不对、有没有依据、有没有用。
• 方法：先用评估（eval）把行为转成指标，再设 SLO，再按目标值到 100% 的差额算出错误预算。
• 典型设定：30 天内 95% 的对话被判定为完成用户请求，剩下 5% 就是明确可容忍的失败额度。
• 评估手段：可以用另一个语言模型当裁判，也可以用正则等确定性检查处理那些不需要 LLM 就能识别的行为。
• 最难的一步：不是建 SLO，而是决定“什么算可接受”——任务完成度该定 85%、95% 还是 99%，行业没有共识。

为什么不能只做一个“质量分数”

Grafana 明确反对把智能体质量压缩成单一分数。理由很实际：质量是多维的。一个智能体可能回答有据可依但成本高昂，可能有帮助却偶尔生成有毒内容，也可能准确但慢得没法用。把这些维度揉成一个数字，等于把最重要的故障类型藏在平均值里。

因此它主张把幻觉、任务完成度、毒性、成本、是否泄露个人信息、是否受到提示词注入影响，拆成彼此独立的指标，各自设目标。这一点和传统监控里“不要只看一个综合健康分”的经验完全一致——综合分会掩盖长尾故障。

错误预算这套机制，妙在把争论变成决策

真正有价值的不是 95% 这个数字，而是它带来的决策模型。

预算还充足的时候，团队可以放心试：改提示词、换模型、调检索、加工具。因为你知道自己还有容错空间。预算快耗尽的时候，重点就该从“再加点功能”切换到“先把质量修回来”。这和 SRE 团队多年来平衡可靠性与发布速度的取舍，是同一套逻辑。

这套机制尤其适合处理“渐进式退化”。传统告警擅长抓突然的失败请求激增，但智能体退化往往不是这样发生的：服务一切正常，答案却在慢慢变得不那么有用。换了个模型版本、改了一句系统提示、调整了检索的召回条数、用户提问方式发生变化——每天掉零点几个百分点，任何单次请求都看不出问题，一周之后体验已经明显变差。

错误预算把这种漂移变成了可见的消耗曲线。对于 30 天的目标，一次糟糕交互无关紧要，但持续下降会稳定地吃掉预算。这时团队要看的不再是“这一次执行有没有失败”，而是“系统整体行为有没有偏离约定的可靠性边界”。

落地时最容易踩的三个坑

第一个坑，把裁判模型当成标准答案。如果充当裁判的 LLM 持续误判，错误预算会带来一种虚假的精确感：数字很漂亮，结论是错的。所以评估器本身也要被评估——拿人工标注的样本定期回测，记录裁判与人工的一致率。

第二个坑，评估设计得太机械。一个只检查“回答里有没有出现关键词”的评估，会奖励那些技术上满足标准、实际没有解决用户意图的输出。模糊场景必须留人工复核通道，确定性检查要用在该用的地方。

第三个坑，目标值拍脑袋。可用性目标有几十年的运维经验可参考，但“任务完成度 95%”没有历史依据。Grafana 的建议是先通过评估建立基线，再用历史结果推荐目标，随着智能体成熟逐步收紧。先测再定，而不是先定再凑。

行业正在收敛到同一套分工

把 Grafana 的做法放到更大的图景里，会发现几种努力正在拼成一条完整的链路。

Anthropic 在智能体评估上走得更细：定义明确任务、重复试验、多个评分器，并特别区分 pass@k 与 pass^k——前者衡量多次尝试中是否至少成功一次，后者衡量是否每一次都成功。对生产环境的智能体来说，后者才是真正相关的指标，因为用户不会给你 k 次机会。

OpenTelemetry 则在另一层做标准化：为智能体遥测制定语义约定，让追踪、指标和日志在不同框架、不同供应商之间保持一致的语义。没有这层统一，跨平台的对比和质量归因都做不下去。

三者合起来的分工很清楚：评估负责判断行为对不对，可观测性负责提供证据，SLO 负责给出“这个行为是否可以接受”的运行阈值。少任何一环，闭环都合不上。

对正在上生产的团队意味着什么

如果你的智能体还停留在 demo 阶段，这套方法论暂时用不上——先跑通再说。但一旦它开始接触真实用户、真实数据、真实金额，就必须回答三个问题：我们怎么判断它今天比昨天差？差到什么程度要停止发布？谁来对“可接受”下定义？

这三个问题答不上来，所谓的“AI 上线”就只是一次没有仪表盘的飞行。Grafana 这次提的不是又一个 AI 指标，而是一句提醒：系统在线，不等于系统可信。