Appearance
Observability
很多 AI 系统刚上线时，最难受的一种状态不是直接报错，而是：
- 结果开始变差了
- 延迟开始波动了
- 成本开始升高了
- 但你第一时间看不出到底哪里不对
这类问题真正的起点，往往不是先去调 Prompt，而是把系统看见。
这就是 Observability 的意义。
1. Observability 到底是什么
Observability 直接看成可观测性。
放在 AI 系统里，它关心的是：
当系统正在运行时，你能不能及时看到关键状态、关键异常和关键变化。
它最常回答的问题通常是：
- 请求量是不是异常波动
- 成功率和错误率有没有下降
- Token 消耗是不是突然升高
- 哪个模型、哪个工具调用最慢
- 哪类请求最近最容易失败
2. 为什么 AI 系统比普通接口更需要它
因为 AI 链路天然更长，也更容易漂。
一条请求背后，可能已经经过：
- 上下文组装
- 检索召回
- 工具调用
- 多轮生成
- 结果校验
只要其中某一层开始出问题，用户最终看到的就可能只是：
- 回答不稳了
- 首字更慢了
- 成本更高了
- 偶尔会失败
如果没有可观测性，这些变化往往只能靠用户反馈倒逼发现。
3. 一套最小可观测链路怎么理解
mermaid
flowchart LR
A[用户请求] --> B[系统执行]
B --> C[记录指标]
C --> D[聚合监控面板]
D --> E[发现异常]这条线虽然简单，但已经说明了可观测性的核心：
- 把数据采出来
- 再把数据汇起来
- 最后让异常能够被及时看到
4. AI 场景里最常看的指标有哪些
更贴近工程一点，通常会重点看下面这些指标：
- 请求量
- 成功率 / 错误率
- 平均响应时间和 P95 / P99 延迟
- Token 输入输出量
- 工具调用次数和失败率
- 检索命中率或空召回比例
- 单请求平均成本
不同系统关注点会不一样，但这些通常是比较基础的一层。
5. Observability 不等于 Tracing
这两个词很容易混在一起。
可以这样分：
Observability更偏看整体状态和趋势Tracing更偏追单次请求走过的完整链路
也就是说：
- 可观测性更像告诉你“最近哪里不对”
- 链路追踪更像告诉你“这一次到底卡在哪”
所以它们通常是配合关系，不是替代关系。
6. 只做日志，为什么还是不够
因为日志更多是在记录事件，而可观测性更关注：
- 指标有没有持续异常
- 异常是不是成片出现
- 波动是不是集中在某个模型、工具或场景
没有指标和聚合视角，日志很容易变成“出了问题再去翻”，而不是平时就能看到系统状态。
7. 最容易踩的几个坑
7.1 只关心接口成不成功
AI 系统里，“成功返回”不代表体验和结果真的正常。
7.2 指标很多，但没有重点
不是所有指标都要一开始就堆满。更重要的是先抓最能反映系统健康度的那几项。
7.3 看到了波动，但没有继续接上追踪和评估
如果只有可观测性，没有 Tracing 和 Evaluation，你通常只能知道系统不对，却很难知道为什么不对、改完后有没有变好。
8. 一段更稳的总结
Observability 解决的是“系统运行时，你能不能及时看到异常和变化”这个问题。它让团队不用等用户来报错，自己就能先发现系统哪里开始飘。很多 AI 系统后面越跑越乱，不是没有优化能力，而是连最基本的系统状态都看不清。