当你的模型偶尔出错时，99.9% 的可用性意味着什么

一家电信公司发布了一款 AI 客服聊天机器人，拥有 99.99% 的可用性和低于 200ms 的响应时间 —— 每一个传统的 SLA 指标都显示为绿色。然而，在 35% 的账单查询中，它的回答都是错误的。没有任何合同条款涵盖这一点。没有任何警报触发。客户只是悄然流失。

这就是 AI 的“西瓜效应”：系统表面看起来很健康，内部却在悄悄腐烂。传统的可靠性 SLA —— 可用性、错误率、延迟 —— 是为确定性系统构建的。它们衡量的是你的服务是否回答了问题，而不是回答得好不好。在传统的 SLA 下发布 AI 功能，就像保证你的支持团队发送的每封邮件都能送达，却不对回复内容是否合理做任何承诺。

这种差距至关重要，因为 AI 功能在 B2B 产品中正承担着越来越重的职责。当 AI 系统生成发票摘要、分类合同条款或起草合规检查清单时，“返回了 HTTP 200”并不是一个有用的成功标准。客户关心的是输出是否正确，他们会为此追究你的责任 —— 即使你的合同里没写。

为什么传统的 SLA 对 AI 失效

传统的 SLA 适用于确定性系统，因为成功是二元的且可观察的。数据库要么返回一行数据，要么不返回。API 要么在 300ms 内响应，要么不响应。你可以测量它，记录它，并据此报警。SLA 反映的是基本事实。

AI 的输出质量则完全不同。同一个提示词（prompt）可能会根据措辞、上下文窗口状态、模型版本、温度（temperature）以及其他数十个变量，产生从优秀到事实错误的各种响应。成功是一种分布，而不是一个单一事件。关键在于，检测失败通常需要人工参与 —— 或第二次 AI 评估 —— 因为系统会带着幻觉答案返回一个听起来很自信的 200 状态码。

还存在二阶问题。可用性 SLA 衡量的是在线状态，而不是质量退化。模型提供商可能会发布一个新版本，在保持 p99 延迟不变的情况下，将你特定任务的准确度降低 15%。仪表盘上全是绿色；你的产品却在悄悄变差。综合基准测试加剧了这一问题 —— 一个在通用基准测试中表现良好的模型，在你特定的任务分布上可能表现得差得多，而你无法仅通过供应商的 SLA 指标发现这一点。

法律风险加剧了工程问题。法院已经开始将 AI 生成的内容视为其交付背景下的事实陈述。如果你提供的 AI 工具生成了客户依赖的财务摘要，幻觉就不再仅仅是质量问题 —— 它们可能构成违约或虚假陈述。而且 88% 的 AI 供应商将其赔偿责任限制在月度订阅费内，这意味着下游风险最终由你承担。

诚实的 AI 质量承诺长什么样

答案不是承诺完美的输出。而是定义对于特定任务来说“足够好”意味着什么，并使这一承诺明确且可衡量。

一个诚实的 AI 质量承诺的基本结构包含三个部分：

任务范围定义。 质量底线适用于具有定义输入的指定任务，而非泛指模型。“在标准发票格式下，系统将以 ≥ 95% 的准确度正确提取发票日期、供应商名称和总金额”是一个可辩护的承诺。“AI 将是准确的”则不是。

衡量协议。 你如何知道底线何时被突破？基于抽样的评估，由人工或 LLM 作为评判者，并按定义的节奏进行（例如每周对 1% 的生产流量进行抽检），为你提供了一种可重复的衡量方法。随机的内部评估则不行。

补救触发条件。 当质量跌破底线时会发生什么？升级到人工审核、回滚到之前的模型版本、通知客户 —— 这些需要预先定义，而不是在客户投诉后才进行协商。

对于内部 SLO，框架类似，但重点转向使团队能够在客户发现之前检测到质量退化。

设计真正能捕捉质量失效的内部 SLO

大多数为 AI 功能采用 SLO 的工程团队都会犯同一个错误：他们衡量延迟和错误率，因为这些很容易检测，并且他们假设质量是别人的问题。

一个有用的质量 SLO 具有三个属性。首先，它衡量的是与任务成功相关的东西，而不仅仅是请求的完成情况。对于提取任务，这可能是针对基准事实（ground truth）评估的样本字段级准确度。对于摘要任务，它可能是来自 LLM 评判者的相关性评分，并定期进行人工校准以验证评判者是否符合现实。对于分类任务，它是对保留测试集（held-out test set）的精确率（precision）和召回率（recall），该测试集会随着输入分布的偏移而每季度更新。

其次，它使用错误预算（error budget）而非硬性阈值。错误预算将质量余量视为一种有限的资源。如果你的质量底线是发票提取准确率为 92%，而你过去 30 天的抽样结果是 94%，那么你在突破承诺之前，有 2 个百分点的预算可以用于实验、模型发布和边缘案例处理。当预算较低时，你停止实验并进行稳定。当预算较高时，你就有冒险的空间。这与 SRE 团队处理可用性的框架相同 —— 它在不要求零容忍失败的前提下对齐了激励机制。

第三，它能捕捉版本漂移（version drift）。模型提供商更新他们的模型，有时甚至不打招呼。提示词的行为会发生变化。随着用户群的增长，输入分布也会改变。仅在发布时运行的质量 SLO 无法捕捉到数月内发生的缓慢退化。影子评估（shadow evaluation）—— 将一小部分生产流量路由到根据你的质量标准对输出进行评分的评估管道 —— 可以持续监测你的质量底线是否仍然达标，而不受供应商端指标的影响。

测量窗口问题

在实践中，有一个细微之处会让团队吃亏：质量 SLO 的测量窗口与延迟 SLO 的测量窗口在本质上是不同的。

延迟 SLO 可以在每次请求时进行评估。而基于人工评估的质量 SLO 在现实中只能以抽样方式进行，且具有滞后性。如果你的评估频率是每周一次，那么你可能在质量回退运行了 5 天后才察觉。这并不是 SLO 设计的失败——它真实地反映了测量成本。在设计上的启示是，你需要触发速度更快的前瞻性指标：对 100% 的输出进行自动化的 LLM-judge 评分，并将人工评估作为校准层，以确认评审员的评分仍然与你的实际质量标准保持相关。

另一个测量窗口问题是突发性故障与持续性故障。传统的基于窗口的 SLO 将 2 分钟的降级与 2 小时的降级同等对待，只要两者都占据了一个窗口。对于 AI 质量而言，突发性故障的影响比看起来更大——一个 60% 输出错误的 10 分钟窗口，比一个 8% 输出错误的 48 小时窗口对客户造成的伤害更大。你的 SLO 设计应该区分低于底线的持续降级和突发性准确率事件，并且两者的修复触发机制应该有所不同。

真正有效的 B2B 合同语言

当 AI 功能成为 B2B 合同的一部分时，质量承诺需要是明确且有界的。模糊的语言——“系统将提供准确的回复”——会产生双方都无法评估的开放式责任。

以下是经得起推敲的模式：

定义明确的任务范围，并划定范围外的情况。 承诺涵盖确定的任务类型（例如发票提取，而非通用的文档问答）。分布外（Out-of-distribution）的输入被明确排除在质量保证之外。这可以防止客户测试那些从未包含在范围内的边缘案例，然后声称违反了 SLA。

基于测量的质量底线。 “在根据客户提供的真值（Ground truth）评估的样本上，每月测量的字段级准确率 ≥ 92%”是可审计的。而“高准确率”则不是。合同应指明由谁进行评估、如何建立真值以及什么构成有效样本。

升级触发机制和修复时间线。 如果测量的准确率低于底线，修复的 SLA 是什么？一个合理的结构是：在发现后的 48 小时内通知客户，在 5 个工作日内提供根因分析，并在 14 天内实施修复或回滚。如果没有明确的时间线，“我们正在处理”就会成为默认状态。

明确的模型变更通知。 如果你使用的是第三方模型，该模型的更改可能会影响你的质量承诺。你的合同应要求你在主要模型版本变更前通知客户，并在切换前针对其任务分布重新验证质量。

这些条款的共同点是它们使质量承诺变得具体、可测量且有时间限制——这些属性正是使可用性 SLA 具有强制执行力的原因。目标不是承诺完美；而是给客户一些他们可以评估的具象东西，并给你的团队一些他们可以努力实现的具象目标。

构建内部基础设施

如果没有支撑它的基础设施，这一切都无法运转。交付具有质量承诺的 AI 功能的团队所需的最简技术栈：

评估数据集。 一组包含经过人工验证的真值的输入/输出对，能够代表你的生产任务分布，并至少每季度更新一次。这是最难构建的部分，也是团队最先跳过的部分。没有它，你无法计算准确率——你只能计算 Token 数量。

自动化评分流水线。 一个根据你的质量标准评估生产输出样本并将结果写入仪表板的系统。对于可以获取真值的任务，这是直接对比。对于无法获取真值的任务（如摘要生成、草拟），这需要使用 LLM-judge，并在子集上进行人工校准。

偏移告警。 在自动化评分上设置一个阈值，当观察到的质量跌至预警水平以下时触发——例如，当你的底线是 92% 时，预警水平设为 94%。预警水平让你有时间在违反合同承诺之前进行调查。

模型变更操作手册（Runbook）。 在任何模型版本变更上线生产之前，针对你的任务分布评估质量的文档化流程。这应该像处理数据库模式迁移（Schema migration）一样严谨。

心态转变

深层次的变化并非技术层面的——而是关于工程团队在交付 AI 功能时，如何看待他们所做出的承诺。

对于确定性系统，交付意味着系统可以工作。对于概率性系统，交付意味着系统对于一组定义的输入，运行得足够好，且频率足够高。“足够好”和“足够高”需要在你向客户做出承诺之前量化，而不是在他们投诉之后。

这可能会让人感到不适，因为它迫使你明确承认你的系统有时会出错。但另一种选择——在模糊的质量承诺下交付并随手处理失败——则更糟。签署了明确质量底线协议的客户知道他们买到了什么。而那些因含糊的准确率承诺而感到被误导的客户，才是那些会流失和起诉的人。

在 2026 年交付持久 AI 产品的团队，是那些从一开始就将质量承诺视为一等工程问题的团队：在发布日期之前设计好测量基础设施，在客户要求之前协商好合同语言，并在第一次模型版本变更之前就将错误预算（Error budget）纳入发布流程。这种纪律并不是交付 AI 功能的约束——它正是使 AI 功能变得可交付的关键所在。