无真值情况下的智能体 SLO：为无法实时评分的输出建立错误预算

你的智能体平台连续一年每季度都达到了 99.9% 的“响应成功率”SLO。但工单量增加了 40%。受智能体引导的用户群体的留存率却在下降。轮值运维感到无聊，产品经理在恐慌，而管理层评审一直在问，为什么仪表盘显示一切正常，而支持队列却显示情况一团糟。仪表盘没有撒谎。它只是衡量了错误的东西 —— 因为编写 SLO 的 SRE 将成功定义为“模型 API 返回了 200”，而这正是遥测系统最初唯一能表达的成功定义。

这是智能体可靠性工程的核心问题：成功的信号不是状态码。它是一种关于智能体是否针对特定任务做了正确事情的判断，而这种判断在请求时是无法获得的，通常在会话时也无法获得，有时只有在几天后，当用户提交工单、修改输出或悄无声息地流失时，才能揭晓。你无法在一个尚不存在的列上标记“200 对比 500”的布尔值。

常见的反应是等待获得基准真相（ground truth）后再宣布 SLO。这是错误的。可靠性工作不会在你构建标注流水线时暂停。正确的做法是针对你明知不完美的代理指标（proxies）编写错误预算，将它们命名为代理指标，设定团队在指标触发时的响应策略，并在产生基准真相后将其回填到计算中。这篇文章将探讨如何在不自欺欺人的情况下做到这一点。

为什么延迟 SLO 的策略失效了

经典的 SRE 框架假设你衡量的 SLI 与你真正关心的用户满意度之间存在紧密循环。延迟是一个典型的例子：一个耗时 800ms 而非 200ms 的请求会让用户不高兴，这一点你可以在请求时、在同一个遥测流中确认，无需任何标注。SLI 不是用户满意度的代理指标 —— 对于延迟敏感型系统，它几乎就是同一个变量。

智能体功能在各个维度上都违背了这一假设。用户希望从智能体那里得到的是正确、有用、符合上下文的任务完成结果。而你的平台能观察到的是一系列工具调用、令牌（token）流和 HTTP 状态码。这些都不是正确性。模型可能返回 200 状态码但给出一个自信的错误答案；它可能工具调用失败，但优雅地恢复并给出一个有用的响应；它可能在正确的情况下（好事）或错误的情况下（坏事）转给人工处理，而仪表盘将这两种情况都记录为“升级（escalations）”。

更深层次的问题在于时机。延迟在请求内部是可观察的。工具错误在会话内部是可观察的。智能体是否做了正确的事，有时只有在用户明天回来修改产出物，或者根本不回来时才能判定。一个基准真相有 24 小时到 30 天滞后的 SLO，在结构上与基准真相位于响应头中的 SLO 完全不同。假装它们相同，正是导致团队出现仪表盘与工单数据背离的原因。

你可以实时衡量的代理 SLI

代理 SLI 是一个与真实成功相关的变量，你可以在已有的遥测流中观察到它。这些都不是真相。但如果将其中每一个都纳入组织公认的代表可接受降级的预算中，它们就足以支撑发布。

适用于大多数智能体产品的代理指标：

• 升级率 (Escalation rate) — 智能体会话转人工的百分比。上升的升级率很少是好消息，但下降的也不一定是好事。过度谨慎的阈值会导致一切都升级；太宽松的阈值则会让错误答案通过。跟踪这个比率，并同时跟踪“升级原因的分布”。
• 重试率 (Retry rate) — 用户在短时间内重新发送或重新组织提示词的会话百分比。重新提示是用户在告诉你上一次回答没对；这是你在无需标注的情况下，能收集到的最清晰的会话内不满信号之一。
• 放弃率 (Abandonment) — 没有明确结束动作（购买、保存、发送、接受）就结束的会话百分比。放弃率比重试率噪音更大 —— 用户放弃的原因可能与质量无关 —— 但与基准线相比的持续偏差是有意义的。
• 产出物的编辑距离 (Edit-distance on artifacts) — 当智能体生成用户可以修改的东西（草稿、配置、查询）时，用户随后修改的大小是衡量初稿偏差程度的量化代理指标。零编辑意味着接受；90% 的编辑意味着用户想要件外套，智能体却给了个衣架。
• 工具调用失败聚合率 (Tool-call failure cluster rate) — 不仅是工具调用是否失败，还包括它们是否以智能体无法恢复的模式失败。健康的重试是循环的一部分；无限制的重试风暴则是可靠性事件。

对这些指标最诚实的描述是：“超过此预算将警示与用户不满相关的回退（regression），尽管我们仅凭此信号无法确定我们捕捉到了真实错误中的多少比例。”这句话应该出现在 SLO 文档中。否则，下一季度的评审员会将代理指标视为基准真相，并得出系统运行良好的结论。

黄金样本集：异步真值如何实现闭环

代理指标会告诉你出了问题。但它们不会告诉你智能体响应中到底有多少比例是错误的。为了弥补这一差距，你需要一个黄金样本集（gold cohort）：以已知速率提取的生产流量样本，根据符合你真实成功标准的准则进行异步评分——然后反向传播到 SLO 计算中，这样你就能引用真实的错误率，而不仅仅是代理指标。

关键机制：

• 以生产规模采样，而非以便利性规模。 从内部演示或测试用户中提取的黄金样本集，几乎无法告诉你系统在面对真实提示词的长尾分布时表现如何。生产可观测性的标准做法是，对高流量提取 1–10% 进行在线评分，对高频率采用低成本检查，对低频率采用昂贵的 LLM 裁判评估。根据你的评估预算来选择采样率，而不是根据你的愿望。
• 在请求路径之外进行异步评分。 同步运行的裁判会让你的延迟和推理账单翻倍。在后台针对日志追踪（traces）运行的裁判，不会产生用户感知的成本，并能产生一个持续的质量信号，你可以将其展示在仪表盘上。
• 在信任裁判之前，先针对人工进行校准。 LLM 作为裁判是人工评分的一种可扩展且可行的替代方案，但前提是你已经衡量了裁判与人工审核员在留出集（held-out set）上的一致率。如果你的裁判与人工的一致率为 70%，那么你的“真实”错误率其实也是一个代理指标——只是它比重试率更好。每季度重新校准一次；模型升级会改变裁判的行为，这种改变看起来像质量偏移，但其实不是。

加载中…