传统软件出问题会报错，你能立刻知道；AI 应用出问题往往是「答得不对」，而系统一切正常——没人报错，用户却在悄悄流失。AI 可观测性要解决的，就是让这种「无声的故障」变得可见：上线之后，你能不能回答「它现在好不好用、是从哪里开始变差的」。
该盯的四类信息
AI 应用的监控，通常分四类，缺一不可：
| 类别 | 盯什么 | 异常时的表现 |
|---|---|---|
| 质量 | 回答是否准确、有没有答非所问、是否编造 | 点踩率升高、用户反复追问同一问题 |
| 成本 | 每次调用的 token 消耗、总花费、异常高调用 | 单次调用费用突然翻倍 |
| 性能 | 响应时长、超时率、重试次数 | 延迟拉长、超时激增 |
| 安全 | 是否触发违规、是否被注入攻击 | 异常输入模式集中出现 |
四类里质量最难量化，成本最容易被忽略——很多人只盯「能不能用」，上线三个月才发现单次调用花费已经悄悄涨了一截。反过来，也有人只盯成本，把回答质量一路压低，用户流失了还浑然不知。
质量怎么衡量：三种做法组合
质量不像延迟那样有明确数字，通常靠三种手段组合：
- 用户反馈：点赞点踩、是否追问、是否转人工，最真实但滞后。
- 模型评估：用另一个模型给回答打分，速度快，但需要校准，避免「自己给自己打分」失真。
- 人工抽检：定期抽样人工看，准确度更高但成本高。
落地的组合是：模型评估做全量初筛，人工只复核被标为「可疑」的那批。这样既压住人工成本，又不会放过真正的问题。评判「回答对不对」这件事，本身就和 AI 对齐 里「怎么让模型行为和预期一致」的思路相通。
为什么要记录输入和输出
出问题时，没有原始记录就无从复盘。把每次调用的输入、输出、模型版本、耗时都存下来，才能在效果变差时回答两个关键问题：「从什么时候开始的」「是哪次改动引起的」。记录是观测的地基，没有它，前面所有指标都只是当下的一瞬间，事后追查无从谈起。当应用从单次问答升级成多步执行的智能体时，还要盯住执行过程本身，相关做法可看 Agent 可观测性。
告警怎么设才不吵人
指标有了，还要把它变成「该看的时候提醒你」。告警设置的核心是分层：点踩率这类质量指标波动大，适合看趋势，连续多个采样点恶化再报警，避免一次偶发就把人叫醒；延迟、超时率这类性能指标相对稳定，可以用固定阈值；成本则要盯「单次调用花费」的异常尖峰，因为它往往意味着某个版本或某类输入出了问题。告警的意义是帮你把有限的注意力，集中到真正需要介入的时刻，而不是让监控变成一台整天响个不停的闹钟。告警的粒度也要和团队规模匹配，小团队宁可少设几条关键的，也不铺开几十条没人看的。
监控本身也有边界
可观测性能告诉你「出事了」，但它不负责自动修好。它发现点踩率上升，却不能替你判断是模型版本问题、提示词改了、还是用户群体变了，这些要结合记录去排查；它也有盲区，很多「答得不对」只有懂业务的人看得出来，纯自动指标会漏；它本身还是成本，记录和评估都要花钱花存储。所以可观测性解决的是「看得见」，并非「自动好」。能读懂这些指标、判断异常是否重要，本身也需要团队具备一定的 AI 素养。还有一条不能省：记录输入输出涉及用户数据，必须做脱敏和权限控制，监控本身不能成为隐私泄露的入口。
速查：AI 可观测性四类指标
- 质量：准确性、编造、答非所问
- 成本：token 消耗、单次花费、异常调用
- 性能：延迟、超时率、重试
- 安全：违规、注入攻击
