一次成功请求背后的模型尝试

一个 AI 产品收到请求，尝试第一条路径，遇到错误，再切换到另一条路径，最终返回了有效结果。

从用户视角看，这次请求成功了。从基础设施视角看，系统可能已经开始退化。

如果我们只记录最终响应，这两个判断就会被压缩成同一个绿色数据点。产品看起来一切正常，直到 fallback 容量被耗尽、延迟变得无法接受，或者最后一条可用路径也开始失败。

这里缺失的观测单位，是一次独立的 模型尝试（model attempt）。

Request 与 Attempt 回答不同的问题

Request 描述的是用户结果：

用户最终是否拿到了结果？
完整体验耗时多久？
最终结果是否可用、是否可以结算？

Attempt 描述的是这次请求内部的一项执行决策：

系统选择了哪条路径？
这次尝试是否成功？
它占用了多久的执行资源？
发生了哪一类失败？
失败之后是否还有下一次尝试？

这两个单位不能互相替代。Request 指标告诉我们产品是否工作，Attempt 指标则解释它为什么能够工作、距离失败还有多远，以及系统的哪一部分需要处理。

Fallback 会把失败转化成隐藏债务

Fallback 是重要的可靠性机制，但它也很容易让 Dashboard 看起来比真实系统更健康。

假设第一条路径有三成概率失败，第二条路径能够稳定兜底。最终请求成功率仍然可能接近完美，但与此同时：

用户需要额外等待一次超时；
一个结果消耗了两份执行资源；
成本与延迟分布正在改变；
fallback 路径正在成为新的单点故障；
主路径可能已经坏了几天，却没有触发任何用户侧告警。

Fallback 完成了自己的工作，观测系统却没有展示它制造的债务。

因此，“请求最终成功”并不足以证明执行链路是健康的。

一条最小但有用的 Attempt 记录

Attempt 遥测不需要复制完整请求。更有价值的通常是一条紧凑记录：

所有尝试共享的 Request ID；
产品请求的模型或能力；
实际选择的执行路径；
Attempt Index 与候选路径数量；
成功或失败；
执行耗时；
规范化后的错误类型；
失败后是否仍有 fallback；
这次尝试是否决定了最终用户结果。

Attempt Status 与 Finality 的区别尤其重要。一次失败后被 fallback 救回，对基础设施分析来说仍然是一次真实失败。一次尝试成功，也不一定意味着用户最终成功，因为之后的校验仍可能拒绝它的输出。

记录应该保存能够支持运维决策的事实。原始 Prompt、生成内容、凭证与完整上游响应通常只会增加安全风险和数据基数，却不会让决策变得更好。

错误分类应该对应不同动作

只有一个统一的 failure 计数，几乎和没有 Attempt 遥测一样弱。

不同失败需要完全不同的处理：

Rate Limit 可能需要增加容量或临时调整路由；
Timeout 可能意味着系统饱和、Deadline 不合理，或者依赖已经不健康；
Invalid Request 通常指向 Contract 或参数问题，不应该盲目重试；
Policy Rejection 需要产品侧的专门处理，不能和可用性故障混在一起；
Network Error 可能是暂时的，但连续重试也可能放大故障；
Invalid Output 表示传输成功了，产品 Contract 却没有满足。

分类不必在理论上完美，但必须足够稳定：图表发生变化时，它应该引导我们进入不同的调查和处理路径。

分类也应该尽量发生在 Attempt 附近。一旦多次失败被压缩成一个最终错误，区分它们所需的信息通常已经丢失。

两个 Dashboard，两种真相

我更倾向于把用户结果与执行健康度明确分开。

产品视图回答：

Request Success Rate；
端到端延迟；
用户可见的错误分布；
完成与交付率。

基础设施视图回答：

不同能力与路径的 Attempt Success Rate；
fallback 发生频率；
First-attempt Success；
不同 Attempt Position 上的错误类型与延迟；
最终成功有多少次依赖了恢复机制。

如果把两者混成一个成功率，我们会得到一个很容易汇报、却很难采取行动的数字。

两个视图之间的关系，往往比任何一个单独指标更有价值。用户成功率稳定，但 First-attempt Success 持续下降，说明韧性机制正在替退化的基础设施兜底。Attempt 健康度稳定，但用户成功率下降，则问题可能发生在推理之后：校验、持久化、结算或交付。

不要过早让遥测自动接管路由

有了 Attempt 数据之后，下一个很自然的冲动，是让某种评分自动选择执行路径。

它可以成立，但近期成功率并不是完整的路由策略。小样本会剧烈波动，不同请求的难度并不相同，速度更快的路径可能输出质量更差，看起来更便宜的路径也可能触发更多重试，有些故障甚至会同时影响所有候选路径。

在让遥测直接控制生产决策之前，系统至少需要明确：

最小有效样本是多少；
使用怎样的时间窗口与新鲜度策略；
哪些错误类型应该计入可用性；
质量和成本如何进入判断；
哪些硬边界不受评分影响；
证据不足时路由如何退化。

观测系统首先应该让决策变得可读。只有当测量语义足够可信，自动化才应该跟进。

不只观测结果，也要观测恢复过程

可靠的 AI 产品不只是能够返回成功结果，它还理解这个结果经过了怎样的路径。

一次 fallback 可以保护用户，同时暴露严重的运行问题。一次 Attempt 可以失败，而不让整个产品失败。一次最终成功，也可能昂贵、缓慢，并且距离完全不可用只差一个依赖。

Request 指标描述我们向用户作出的承诺，Attempt 指标描述维持这份承诺的机器。

只有同时看见这两种真相，我们才能说系统是健康的。