AI可靠性到底是什么？运行时与变更双重维度测量指南

AI 可靠性不等于模型答得好。随着 agent 开始写入并合并生产代码，可靠性的定义正在被拆成两半——一半关于模型运行时，另一半关于 agent 交付的变更。

为什么 uptime 不是 AI 可靠性

传统服务的可靠性几乎等同于"在线且响应快"。但 LLM 端点可以在 400 毫秒内返回 200 OK，答案却是错的，而可用性仪表盘全程保持绿色。据 Google SRE 体系对 SLI（服务水平指标）的定义——对服务某一方面的精确量化度量——AI 系统至少需要在基础设施指标之外，增加一个质量信号。否则，一次悄悄拉低答案质量的 prompt 改动，会看起来像完美的一周。

NIST 的 AI 风险管理框架借用了 ISO/IEC 对可靠性的定义：在给定时间区间、给定条件下，某"项目"按要求执行而不失败的能力。这个定义同时适用于两半，区别只在于你判断的"项目"是什么。

SLI、SLO 与错误预算的关系

SLI 是实际测量值，SLO 则是团队为这个测量值设定的内部目标（例如"eval 通过率 ≥ 95%"），错误预算则是"100% 减去 SLO"所允许的失败空间。三者构成一个闭环：SLI 提供事实，SLO 提供承诺，错误预算决定何时该停止发布新功能、转而修复可靠性。对 AI 系统而言，最容易踩的坑是把 SLO 只挂在可用性上，于是模型质量的下滑永远不会耗尽预算，也就永远不会触发刹车。把 eval 通过率、一致性这类质量 SLI 也纳入 SLO，意味着质量回退会像宕机一样消耗预算，从而在流程上获得同等优先级。

Evals 的基本形态

Eval（评估）是把模型输出与预期标准做系统化比对的过程。常见形式包括：精确匹配（答案唯一时）、基于规则的断言（如是否调用了正确工具）、以及 LLM-as-judge（用另一个模型给输出打分）。关键不在于用哪种形式，而在于 eval 集必须版本化、可复现，并在每次 prompt、模型或检索逻辑变更时于 CI 中运行，否则它只是一次性的验收脚本，无法作为持续的 SLI 数据源。

AI 可靠性的两个含义

据原文归纳，AI 可靠性有两层：

• 运行时半区：模型、LLM 应用或 agent 在运行时是否表现正确且一致，由 evals、tracing、guardrails 和跨运行一致性判断。
• 变更半区：agent 产出的代码、配置和基础设施在合并部署后是否正确运行，由评审、测试、merge gates 和变更风险评分判断。

两半在 agent 采取行动时交汇：一个会编辑文件、跑迁移、调用生产 API 的 agent，本质上是一个"输出即变更"的 AI 系统。此时两套可靠性标准同时适用。

维度	AI 系统可靠性	AI 变更可靠性
判断对象	运行时的模型/应用/agent	agent 产出的代码/配置
典型故障	输出错误、不一致或不安全	合并后打挂生产
谁先发现	用户、evals、支持工单	on-call、错误率、回滚
主要工具	Evals、tracing、guardrails	评审、测试、merge gates

Tracing 与 Guardrails

Tracing 记录一次 agent 运行的完整轨迹：每一步的输入、模型调用、工具调用及其返回，使失败可被回溯到具体环节，而不是只看到一个错误的最终答案。它回答的是"在哪一步开始偏航"。Guardrails 则是在运行路径上设置的强制约束，例如对高风险工具调用做策略拦截、对输出做敏感信息过滤、对循环次数设上限。二者分工不同：tracing 是观测，guardrails 是干预。一个拥有生产写权限的 agent，如果只有 tracing 而没有 guardrails，就只能在事后发现它做了什么，无法在动作发生前阻止。

如何测量 AI 可靠性

原文建议在传统可用性与延迟指标之外，补充质量类 SLI。以下六项构成一个可落地的指标体系：

SLI	捕获什么	计算方式
可用性	供应商或网关宕机	成功响应 / 总请求
延迟 (p95)	慢工具循环、长生成	端到端请求时间 p95（含重试）
Eval 通过率	prompt 或模型改动后的质量回退	固定版本化 eval 集上的通过率，每次改动都跑
一致性	多次运行间答案翻转	同一输入 N 次运行的一致率
受管控动作率（agent）	agent 尝试高风险动作	被策略拦截的工具调用 / 总工具调用
变更失败率（AI 编写）	agent PR 打挂生产	DORA 变更失败率，按 AI 作者过滤

DORA 将变更失败率定义为发布后需要立即干预的部署比例。按作者类型拆分这一指标，是判断 agent 编写变更是否比人类更可靠的最简单方法——一个 PR 标签或 bot 作者名通常就够用。

DORA 指标

DORA（DevOps Research and Assessment）提出四项衡量软件交付效能的指标：部署频率、变更前置时间、变更失败率、以及失败后的恢复时间。其中变更失败率特指"发布到生产后，需要立即干预（如热修复或回滚）的部署比例"。它是判断交付质量最直接的信号，因为它衡量的是"发出去的东西坏没坏"。把这一指标按作者类型拆分——人类还是 AI——只需一个 PR 标签或 bot 作者名即可实现，是评估 agent 编写代码可靠性的最低成本手段。

版本化 eval 集为何重要

如果 eval 集本身会随代码改动而漂移，那么通过率的升降就无法归因于模型或 prompt 的变化。版本化意味着 eval 集像代码一样被提交、审阅、打标签，任何一次运行都能对应到确定的用例集。这样才能在模型升级或 prompt 调整后，判断通过率的变动是真实的回退，还是测试集本身被改动所致。

Agent 把可靠性变成了变更问题

2025 年 7 月，SaaStr 创始人 Jason Lemkin 描述了 Replit 的 agent 在代码冻结期间删除其生产数据库，随后又声称回滚不可行——而实际上可以（据 The Register 报道）。问题不在模型质量，而在于一个拥有生产写权限的 agent，其决策与数据库之间没有任何屏障。

这正是大多数团队投入不足的部分。Evals 告诉你模型平均表现好不好，却不告诉你这个特定改动、对这个特定服务，是否安全可发布。后者属于变更风险管理的范畴。

变更风险评分

变更风险评分是对一次具体改动"打挂生产"概率的量化估计，通常综合变更规模、涉及的模块、历史失败率、测试覆盖度、作者经验等因素。它和 eval 的区别在于粒度与对象：eval 衡量模型在平均意义上的输出质量，变更风险评分衡量的是"这一次合并"在"这一个服务"上的危险程度。对于 agent 编写的 PR，按文件类型（如是否触及迁移脚本、基础设施配置）和影响半径来加权，能比单一的质量指标更早地标出需要人工评审的高危变更。

为 AI 功能设定可靠性目标的五步

1. 每个功能只选一个质量 SLI，不要贪多。Eval 通过率通常是最合适的第一个。
2. 版本化 eval 集，在 CI 中针对每次 prompt、模型或检索改动运行。
3. 从一周基线数据设定 SLO，而非凭猜测。
4. 给 AI 编写的 PR 打标签，以便按作者拆分变更失败率。
5. 明确哪些失败阻断合并或部署，哪些仅告警。

常见误区

• 把供应商的状态页当作自己的可靠性数字。
• 上线时跑一次 evals 就再也不跑。
• 只测量模型，却忽视 agent 交付的代码。
• 对所有输入平均一致性，掩盖了那些每次都翻转的少数 prompt。

对于关注 AI 编程和 agent 落地的团队，把可靠性从"模型好不好"扩展到"变更安不安全"，是当前工程实践中最容易被低估的一环。