非确定性系统的 SLO：当每次响应都不同时如何定义可靠性

你的 AI 功能返回 HTTP 200，在 180ms 内完成，生成了有效的 JSON。按照所有传统 SLI 指标，这个请求是成功的。但答案是错的——一个编造的产品规格、一条捏造的法律引用、一个微妙错误的计算。你的监控一片绿色，用户却怒火中烧。

这就是 SRE 在 AI 系统上失效的根本性断裂。传统可靠性工程假设成功的执行会产生正确的结果。非确定性系统在每一个请求上都违反了这个假设。同样的提示、同样的上下文、同样的模型版本，每次都可能产生不同的——且错误方式各异的——答案。

2025 年麦肯锡的一项调查发现，51% 使用 AI 的组织经历了负面后果，其中近三分之一将问题归因于不准确。不是宕机，不是延迟，是不准确。系统运行完美，却在产生错误答案。

如果你在生产环境中运营 AI 功能，你需要一类全新的可靠性目标——衡量系统是否正确，而不仅仅是衡量它是否在运行。

为什么传统 SLI 无法捕捉主要故障模式

标准 SRE 工具箱——可用性、延迟百分位数、错误率——是为确定性系统设计的。数据库查询要么返回正确的行，要么抛出错误。支付 API 要么处理了扣款，要么返回一个状态码失败。成功和正确是同一件事。

对于 LLM 驱动的功能，二者完全背离。考虑一下传统 SLI 无法检测到的故障模式：

• 幻觉：模型以高置信度编造事实。HTTP 200，有效的 schema，完全错误的内容。
• 语义漂移：模型更新微妙地改变了语气或推理风格。没有错误，但用户注意到产品"感觉不同了"。
• 相关性衰减：检索层返回过时的文档，模型自信地综合出一个过时的答案。
• 安全违规：模型产生有害或违反策略的内容。结构完美，语义灾难。

你可以拥有 99.99% 的可用性和 50ms 的 p99 延迟，同时你的 AI 功能正在积极损害用户信任。传统 SLI 永远不会为此给你发告警。

定义语义 SLI

解决方案是引入第二个维度的指标，直接衡量输出质量。这些就是语义 SLI——评估系统说了什么的指标，而不是它说得多快。

正确率。 有多大比例的响应通过了自动语义评估？这需要构建或采用能够根据真实标准或评分规则对输出进行评分的评估框架。建设成本高昂，但在生产 AI 中不可妥协。

幻觉率。 有多大比例的响应包含编造的声明？这可以通过接地检查来衡量——验证输出中的断言是否可以追溯到源文档或已知事实。

策略合规率。 模型多久会违反内容策略、泄露 PII 或无视安全护栏？这可以通过基于规则的分类器来衡量，通常是最容易实现的语义 SLI。

Schema 有效输出率。 对于结构化生成任务，有多大比例的输出符合预期的 schema？一个可以解析但在必填字段处包含 null 的 JSON 响应，即使结构有效，在语义上也是无效的。

工作流完成率。 对于智能体系统，有多大比例的多步骤工作流成功完成或显式升级，而不是在中途静默失败？一个 10 步智能体管道在每步 90% 的成功率下，端到端完成率只有约 35%——用一位从业者的话说，这是"原型领域"。

关键洞察：这些指标本质上是概率性的。你不能期望非确定性系统 100% 正确。这正是你需要围绕它们制定正式 SLO 的原因。

当基线是 85% 而非 99.9% 时如何设置错误预算

这是传统 SRE 文化与 AI 现实冲突最激烈的地方。在经典 SRE 中，0.1% 的错误预算感觉很宽裕。对于 AI 系统，你的基线准确率可能是 85%，提升到 90% 可能就是一项重大工程投入。

这需要从第一性原理重新思考错误预算。

从你的实际基线开始。 在设定任何目标之前，先对代表性样本测量当前性能。如果你的 RAG 管道目前正确回答 82% 的查询，那么 95% 的 SLO 就是理想化的空谈，而非有用的可靠性目标。

按故障类别设置预算。 不是所有故障都同等重要。编造法律引用是灾难性的，略显冗长的回复是外观问题。定义单独的错误预算：

• 事实准确性：5% 错误预算（95% 正确）
• 安全违规：0.1% 错误预算（99.9% 合规）
• Schema 有效性：1% 错误预算（99% 有效）
• 相关性评分：10% 错误预算（90% 相关）

使用滑动窗口基线。 生产 LLM 性能自然会波动。固定阈值要么在正常波动期间频繁触发，要么在真实退化期间保持沉默。将当前性能与滚动 7 天或 30 天窗口进行比较。当均值偏移超过两个标准差时做出反应，而不是当它越过任意一条线时。

预算消耗速率比绝对水平更重要。 88% 准确率的系统令人担忧。在 48 小时内从 92% 降到 88% 的系统就是一个事故。追踪错误预算消耗的速度，而不仅仅是当前水平。在预算消耗 50%、75% 和 90% 时设置告警阈值。

非确定性系统的告警架构

传统告警基于二元信号触发：错误率超过 1%，延迟突破 p99 阈值。对于 AI 系统，你需要一种能区分真实退化和正常波动的告警架构。

第一层：基础设施告警（传统 SLI）。 这些仍然重要。如果模型 API 返回 500 或延迟飙升，你现有的监控就能处理。保持原样即可。

第二层：质量回归告警。 针对黄金测试集——一组精心策划的具有已知正确输出的输入——运行持续评估。当这个测试集上的分数下降超过一个阈值（比如 100 分制上下降 5 分），触发告警。这能捕捉不产生任何基础设施信号的模型侧回归。

第三层：分布偏移告警。 监控模型输出的统计分布：置信度分数、token 概率、输出长度分布、嵌入空间聚类。这些分布的变化通常先于可衡量的质量下降出现。一个不太自信或不太一致的模型，往往是它遇到了陌生模式的最早信号。

第四层：业务指标关联。 将你的 AI 质量指标与下游业务信号关联起来。如果你的 AI 客服机器人的解决率下降，或者你的 AI 搜索功能的点击率下降，这些是滞后指标，用来确认你的先行指标本应捕捉到的问题。

关键设计原则：你的值班团队不应该在凌晨 3 点在没有运维手册的情况下调试 prompt。每个告警都需要配套的操作手册——检查什么、如何验证，以及当 AI 功能需要优雅降级时确定性的回退方案是什么。

检测静默退化

AI 系统中最危险的故障模式是静默退化——模型逐渐变差，却不触发任何基于阈值的告警。单个响应看起来合理。整体质量在侵蚀。

检测需要将评估视为持续服务，而不是一次性测试。

金丝雀评估管道。 维护一个回归测试套件，包括黄金对话、特定领域的问答对、安全红队 prompt 和关键业务工作流。按计划运行这个套件——至少每天一次，关键系统每小时一次。将结果与基线进行比较。

影子评分。 对于新模型版本或 prompt 变更，在完全上线前将新版本与当前版本并行运行并比较语义输出。这是 AI 版的金丝雀部署，但你比较的是含义，而不仅仅是错误率。

人工覆盖率追踪。 如果有人在审查 AI 输出，他们拒绝或大幅修改 AI 答案的比率是你最有价值的 SLI 之一。覆盖率上升是质量退化的高保真信号，是任何自动化指标都无法匹敌的。

审计节奏。 每季度至少对一个关键 LLM 工作流进行语义指标检测。审查模型和数据供应链——嵌入模型是否更新了？检索语料库是否改变了？供应商侧的模型更新是否在未通知的情况下上线了？这些供应链变更是静默退化最常见的根本原因。

使其可运营

定义语义 SLO 是容易的部分。运营它们才是团队卡壳的地方。以下是一个实用的实施序列：

第 1 周：检测。 选择你最有价值的 AI 功能。添加捕获完整输入输出对的日志，而不仅仅是元数据。没有实际内容，你就无法评估质量。

第 2 周：建立基线。 通过人工或 LLM-as-judge 管道对生产输出的代表性样本进行评分。确定你当前的准确率、幻觉率和相关性分数。这是你的起点，不是目标。

第 3 周：自动化评估。 构建一个针对抽样生产流量运行的自动评分管道。从简单的启发式规则开始（响应长度、schema 验证、关键词存在），然后叠加语义评估（嵌入相似度、LLM-as-judge 评分）。

第 4 周：设置 SLO 并告警。 根据你的基线，设定合理的 SLO 和适当的错误预算。配置基于预算消耗速率的告警。为每个告警编写运维手册。

持续进行：闭环。 当事故发生时，将失败案例添加到你的黄金测试集中。你的评估套件应该从真实的生产故障中增长，使同类故障越来越难以不被发现地再次发生。

那些做对了的组织，不是拥有最复杂 AI 模型的组织。他们是那些用对待正常运行时间一样的严谨态度来对待 AI 输出质量的组织——有可衡量的目标、有意义的预算，以及让团队在用户注意到之前就能做出响应的运营手册。

非确定性系统在可靠性上没有豁免权。它们只是要求我们重新定义可靠性的含义。