跳到主要内容

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

· 阅读需 11 分钟
Tian Pan
Software Engineer

一家电信公司发布了一款 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)—— 将一小部分生产流量路由到根据你的质量标准对输出进行评分的评估管道 —— 可以持续监测你的质量底线是否仍然达标,而不受供应商端指标的影响。

加载中…
References:Let's stay in touch and Follow me for more thoughts and updates