非确定性 AI 功能的 SLO：当“错误”具有概率性时，如何设置错误预算

你的 AI 功能处于 "up" 状态。延迟正常。错误率为 0.2%。仪表盘显示一片绿色。但在过去的两周里，摘要质量在悄然下降 —— 输出在技术上是连贯的，但事实深度变浅了，始终漏掉用户关心的关键细节。没有人提交 Bug。没有触发告警。直到下一次季度审查、留存数据出来时，你才会意识到这一点。

这是传统 SLO 无法察觉的故障模式。可用性和延迟衡量的是你的服务是否在响应 —— 而不是它是否响应得 好。对于确定性系统，这两者几乎是等价的。对于 LLM 功能，它们可能会在数周内无声无息地分道详镳。

解决方案不是放弃 SLO，而是扩展它们。行为质量 SLO 赋予你同样的错误预算纪律 —— 拥有明确的燃烧率（burn rates）、告警阈值和回滚触发器 —— 并将其应用于对 AI 功能真正重要的维度：随时间变化的输出质量。

为什么基础设施 SLO 无法直接迁移

传统 SLO 假设一个清晰的二元对立：一个请求要么成功，要么失败。分母是请求总数；分子是“好”的请求。对于 Web 服务，“好”意味着状态码为 200 且响应在你的延迟预算内。故障是可观测的，且通常是即时的。

LLM 系统从三个方面打破了这一模型。

首先，故障是无声的。一个产生事实幻觉、截断摘要或生成语气不当的客户响应的 LLM 不会返回错误代码。请求成功完成。HTTP 200，延迟标称，错误预算不受影响 —— 而用户得到的却是一个错误的答案。

其次，质量是连续的，而非二进制的。响应并非简单的正确或错误；它存在于一个光谱上，从优秀到微妙的误导，再到一本正经地胡说八道。二进制的错误率无法表达一个偶尔表现糟糕的系统与一个持续平庸的系统之间的区别。

第三，退化是渐进的。基础设施故障通常会突发：你在几秒钟内从 99.9% 掉到 40%，告警立即触发。而质量退化是漂移的：随着模型更新略微改变了输出分布，或者随着用户群逐渐转向你的提示词（prompts）未针对其优化的输入模式，你在三周内从 91% 的良好响应下降到 83%。当人类能肉眼察觉时，你已经深陷泥潭了。

最后一点正是陷阱所在。SRE 实践学会了害怕“缓慢燃烧”（slow burns），正是因为它们在不触发告警的情况下侵蚀错误预算。同样的动态也适用于 AI 质量 —— 你只是需要不同的工具来检测它。

行为质量 SLO 的三大支柱

行为质量 SLO 需要回答与传统 SLO 相同的问题：“在过去的 30 天里，有多大比例的请求是足够好的？”不同之处在于你如何定义“足够好”。

支柱 1：语义回归阈值 (Semantic Regression Thresholds)

最直接的行为 SLO 是语义正确率：在自动化评估器中得分高于阈值的采样输出比例。评估器可以是基于规则的（输出是否包含必填字段？）、基于嵌入的（相对于参考答案的 BERTScore 是否高于 0.85？），或者是 LLM-as-judge（评分模型是否认为该响应令人满意？）。

每种评估器类型都有不同的成本-准确度权衡。基于规则的检查是确定性且廉价的 —— 可以对 100% 的流量运行。嵌入相似度能捕捉到精确匹配错过的语义漂移，且每个请求的成本较低。LLM-as-judge 最为敏感，但会引入其自身的非确定性和成本；请在 5-10% 的采样或由廉价信号标记出的流量上使用它。

SLO 目标变为：“在 28 天的滚动窗口内，95% 的采样响应在质量量规（rubric）上评分 ≥ 4.0”。错误预算就是那 5% 的容忍度。当质量率消耗该预算的速度快于预期时，你会收到一个有意义的告警 —— 一个针对输出退化而非基础设施故障触发的告警。

支柱 2：输出分布漂移检测 (Output Distribution Drift Detection)

质量阈值可以捕捉绝对退化，但会漏掉相对漂移 —— 即输出在技术上仍然“及格”，但特征发生了用户会察觉的变化。响应长度分布的偏移、对冲语言的增加、主题覆盖范围的缩小：这些模式可以在质量阈值以下持续存在，同时显著恶化用户体验。

输出分布监控跟踪输出随时间变化的统计属性。在最简单的层面上，这意味着跟踪响应长度、置信度信号或类别标签（用于分类任务）的分布。在更复杂的层面上，这意味着使用 Wasserstein 距离或最大平均差异（MMD）监控输出嵌入相对于参考窗口的分布，并在分布偏移超过阈值时发出标记。

这里的 SLO 制定更为微妙：你衡量的不是质量率，而是分布的稳定性。“本周输出嵌入与参考窗口之间的 Wasserstein 距离不得超过 0.15。”当超过时，不一定发生了质量事件 —— 但这是一个需要调查的信号。

支柱 3：相对于基准的偏好胜率 (Preference Win-Rate Against a Baseline)

语义阈值和漂移指标能告诉你系统是否发生了变化。胜率则告诉你相对于你信任的基准，它是变好了还是变坏了。

这个想法很简单：定期抽取成对的响应（当前模型 vs. 基准模型），将它们路由到评分系统（人工标注员、LLM-as-judge 或专门的奖励模型），并衡量用户或评分者在多大比例的时间里偏好当前的输出。胜率高于 50% 意味着你正在改进；低于 50% 意味着你发生了回归。

这是三种信号中最昂贵的，但它与实际的用户偏好最一致。它还为你提供了一个自然的回滚标准：如果相对于上周模型的胜率降至 45% 以下并持续 48 小时，这就是触发模型版本自动回滚的开关。

将行为 SLO 接入事件响应

拥有行为 SLO 只有在它们被接入你的运维流程时才有用 —— 而不是仅仅躺在某人每月检查一次的仪表板上。

质量 SLO 的告警设计与基础设施告警在一个关键点上有所不同：你需要的是燃烧率告警 (burn rate alerts)，而非阈值告警 (threshold alerts)。针对 “质量率 < 90%” 的阈值告警一旦触发就会一直处于触发状态，从而产生噪音。而燃烧率告警在质量率消耗错误预算的速度超过允许范围时触发 —— 它在趋势变差时触发，而不只是在某个点估计值跨过红线时触发。

具体来说：如果你的月度错误预算是 5%（即 95% 的质量目标），而当预算允许每天消耗 0.17% 时，你每天实际消耗 0.5%，那么你在 10 天内就会耗尽预算。3 倍于正常燃烧率的告警会在第一天触发。这就是模型 —— 直接从 Google 的 SRE 手册中借鉴并将其应用到质量指标上。

针对质量的事件运行手册 (Runbooks) 需要自己的分类法。对于 LLM 系统而言，重要的事件类别与基础设施截然不同：

• 质量退化 (Quality degradation)：质量率下降或胜率回退，来源不明
• 分布偏移 (Distribution shift)：输出特征已改变，但尚未突破质量阈值
• 模型漂移 (Model drift)：提供商的模型更新改变了行为（可通过行为指纹识别检测）
• 数据漂移 (Data drift)：传入的请求分布已偏离训练/评估分布

每一类都有不同的排查路径。质量退化从 “我们是否发布了提示词变更？” 开始。分布偏移从 “输入模式是否改变？” 开始。模型漂移则从 “供应商是否推送了静默更新？” 开始。运行手册需要引导值班人员 (on-call) 走完每一个决策树，而不仅仅是告诉他们 “调查质量”。

成本熔断机制 (Cost circuit breakers) 也属于这种架构。LLM 评估是需要成本的：大规模对每个请求运行 LLM-as-judge 非常昂贵。设计你的监控流水线，在稳态流量下进行激进的采样，然后当廉价信号（如基于规则的检查、分布漂移）表明可能发生事件时，自动增加采样率。将你的评估预算花在最重要的地方。

组织层面的难点

技术设计是较容易的一半。更难的一半是让 AI 团队将行为质量视为一项运维责任，而不是产品发布检查清单上的一个项目。

关于错误预算的沟通 通常是事情进展不下去的地方。传统的错误预算带有一种强制机制：当你耗尽预算时，你会停止发布新功能并专注于可靠性。这种痛苦足以激励对可靠性工作的投入。行为质量错误预算也需要同样的强制机制 —— 如果你的质量 SLO 耗尽，路线图就要暂停，直到质量工作完成 —— 但 AI 团队会抵制这一点，因为质量工作不如基础设施工作那样清晰可见。“提高响应质量” 没有明确的发布日期。

解决方法是让质量工作像基础设施工作一样清晰可见。每一个行为 SLO 都需要相应的投入：有人负责评测流水线，有人负责评分标准，有人每周审查评分样本以捕捉评估器漂移 (evaluator drift)。这些应该是定量的、指派的、可跟踪的 —— 而非愿景式的。

评估器信任度 (Evaluator trust) 是一个相关问题。团队会抵制他们不信任的 SLO。如果 LLM-as-judge 的评分不一致，如果语义阈值是随意设定的，如果胜率对比的噪音超出预期 —— 当 SLO 在不方便的时候触发时，它会被悄悄忽略。在使 SLO 进入运维状态之前，先投入精力进行评估器验证：衡量评分者间的一致性 (inter-rater agreement)，在代表性样本上将自动评分与人工评分进行对比，根据数据而非直觉设定阈值。

回归节奏 (Regression cadence) 也需要明确的规划。行为质量 SLO 的效果取决于你运行评估的频率。每周评估意味着事故可能会潜伏七天。对样本进行持续评估意味着事故会在几小时内浮出水面，但这需要一个像维护基础设施一样维护的生产评测流水线。正确的答案取决于你的应用对成本的敏感度 —— 但那些将评估视为季度性任务的团队并不是在运行 SLO，他们是在做周期性审计。

优先构建什么

如果你正从零开始，请抵制住一次性构建所有内容的冲动。一个行为质量 SLO 可以分三个阶段引导完成：

阶段 1：覆盖基线。 选择一种高流量、高风险的输出类型。为最明显的失败模式（缺失必填字段、跑题回复、过度套话）编写一个基于规则的评分器。在生产流量上运行两周并衡量基线率。先不要设定 SLO 目标 —— 只是为了确定 “正常” 是什么样的。

阶段 2：阈值与告警。 根据基线设定质量率目标（如果正常是 94%，则设定 92% 的目标，并将差距视为你的初始错误预算）。接入燃烧率告警。进行桌面演练：如果这个告警在周二早上触发，我们该怎么办？在需要它之前写好运行手册。

阶段 3：胜率回归测试。 增加每周一次的自动胜率评估，与上一周的模型进行对比。将此检查作为生产部署的卡点 (gate)：如果评测集上的胜率降至 48% 以下，则在发布前需要人工审查。这会让你的 SLO 从一个监控工具变成一个部署闸门 —— 这也是它从可选变为必选的关键点。

总结

让传统服务值得信赖的可靠性实践——错误预算、燃烧率告警、发布门禁、运维手册——同样可以迁移到 AI 功能中。它们只需要被应用在行为质量上，而非基础设施的可用性上。

挑战不在于技术的复杂程度，而在于组织的纪律性：能否像对待生产事故一样对待质量下降，能否以对待监控基础设施的严肃态度来投入评估基础设施，以及能否接受当你的用户正在与一个概率系统交互时，“仪表盘是绿色的”已不再是足够的保障。

错误预算之所以奏效，是因为它们将隐含的规则显性化了：你已经预先决定了何种程度的失败是可以接受的，并且承诺在超出该限度时停止新工作的开展。这种纪律正是 AI 功能所需要的——并将其应用在真正核心的指标上。