AI 监控，最怕不报错的故障

最近在琢磨怎么给一个 AI 系统做监控，越想越觉得，过去那套经验基本套不上。

传统监控那套很熟，盯的就是基础设施那点事：机器和进程还在不在，接口的错误率和延迟有没有异常。一张大盘，红了就告警。

可放到 AI 上，连第一步都不对——你甚至不太确定，该往这张大盘上放什么指标。

先是指标对不上。传统监控默认一次请求是原子的，一个延迟数字就够了。但 LLM 是一个 token 一个 token 流式吐出来的，「延迟」这一个数字根本不够用。你得拆开看：首 token 多久才出来（TTFT），出来之后每个 token 多快（TPOT），整条请求端到端多久（E2E）。再加上 token 数、缓存命中、finish_reason、模型版本，这些传统监控里压根没有。

指标集换了一套。 不过这层还好，至少改改采集就能看见。

真正麻烦的是再往上一层。

接口返回 200，延迟正常，成本也正常，模型规规矩矩给了你一段话——所有指标都绿，但这段话是错的。客服回复把退款政策讲反了，合同摘要漏了关键条款，工单分类分错了类目。

这种故障没有错误码。 你盯着传统大盘，什么都看不出来。

所以 AI 监控这套，不能照着传统监控来。它得回答一个传统监控从来不问的问题：当系统「一切正常」的时候，它到底有没有在好好干活。

想下来其实就一句话：

没有一条贯穿全链路的 trace_id，AI 监控平台最后会变成几块互不相认的看板。

该按什么分层

先说一个最容易踩的坑：按团队或者按工具分层。

监控平台很容易长成这样——网络团队一块看板，推理团队一块看板，算法团队一块看板，安全团队再一块。每块单看都对，合起来却没人能回答「这次调用到底哪儿出了问题」。因为故障会跨团队跑，看板不会。

我后来想清楚，分层不该按谁负责分，该按故障从能不能跑通、到跑得好不好这条线分。

一次 AI 调用，从下往上其实是三个完全不同的问题：

能不能连上、跑得动？
连上了，有没有真的吐出能用的内容？
内容拿到了，它对不对、好不好？

能连上、有内容、内容对，是三件事。 我把这三档叫症状阶梯。

【配图待补：第一张图——三档症状阶梯，trace_id 竖线贯穿，右侧两条竖切轴】

L3  质量层    内容好不好、符不符合要求       无声
L2  有效层    有没有真的返回可用内容         半有声
L1  连通层    连得上、跑得动吗               有声

越往下，故障越「有声」，有错误码、有延迟突增，传统监控还能看见个大概。越往上越「无声」，到 L3 几乎一点动静都没有。

那 Prompt 用了哪版、RAG 召回了什么、调了哪个工具、模型是哪个版本，这些放哪层？

我一开始也想给它们单独立一层，后来发现不对。它们不是症状，是根因。 召回变差、模型偷偷换版，本身不会报警，它是用来解释「上面那层为什么红」的。把根因塞进症状阶梯，层就乱了。

所以它们是另外一条线，竖着切下来，顺着 trace_id 挂到每一次调用上。安全审计也一样，是竖切的。

这张图于是就清楚了：三档症状阶梯看「哪一档红了」，两条竖切轴解释「为什么红」和「合不合规」。 中间靠 trace_id 把所有东西串成一条。

L1 连通层，接口 200 不代表跑得动

最底下这层，回答最朴素的问题：模型服务到底能不能干活。

传统探活就是发个请求看返回 200 没有、进程还在不在。对 AI 不够。一个 endpoint 可以稳稳返回 200，但背后推理节点排队很深，配额快打满，GPU 显存爆了之后吞吐掉了一半。接口活着，用户体感已经很差。

AI 的探活不能只问「接口在不在」，得问「能不能在合理时间里吐出第一个 token」。

跑起来之后，这层盯的是一次调用本身的体检：

{
  "trace_id": "trc_123",
  "http_status": 200,
  "ttft_ms": 480,
  "tpot_ms": 28,
  "retry_count": 1,
  "fallback_path": ["anthropic", "openai"],
  "cost": 0.012
}

ttft_ms 是首 token 延迟，tpot_ms 是每个 token 的延迟，两个合起来才说得清「快不快」。retry_count 和 fallback_path 记录这次重试了几回、有没有从主模型掉到了备用模型。

这层的故障大多有声，会自己跳出来：429 限流变多，重试率上去，缓存失效之后成本悄悄上涨。

其中有一个最值得拎出来——fallback 率上升。表面看成功率没掉，请求都成功了，但其实一部分流量已经从你指定的模型，掉到了兜底的便宜模型上。质量在降级，大盘却还是绿的。

还有一种情况，这层会露出第一个破绽：endpoint 活着，HTTP 也 200，token 却迟迟不出来，或者干脆没出来。这就到了第二层。

L2 有效层，通了不等于吐出了能用的东西

这一层最容易被漏掉。

很多人默认，调用成功就等于拿到了结果。但「网络通」和「模型真的给了你能用的东西」，根本是两回事。

接口 200、延迟也正常，模型完全可能返回一段空内容，直接拒答，话说到一半被截断，或者被内容过滤拦下来。这些在 L1 看，全是正常请求。

所以这层专门盯一件事：这次调用到底有没有产出可用的内容。

最关键的字段是 finish_reason。正常结束是 stop；如果是 length，意味着输出被最大长度截断了，模型话没说完。除此之外还有空响应率、拒答率、内容过滤命中率。

这层的故障是「半有声」的，不一定报错，但只要你看 finish_reason 的分布、看空响应的比例，是能看出来的。

几个典型：

finish_reason=length 突然变多，多半是 prompt 变长把输出空间挤掉了，回答一段段被切。
某一类问题的拒答率升高，可能是模型换版后变保守，也可能是触发了新的安全策略。
上游内容过滤误杀，把正常请求也拦了。

这层绿了，只能说明你拿到了一段完整的、没被拒没被截的内容。它好不好，还没人回答。

L3 质量层，全是 200，结果却越来越差

到这层，所有传统指标都失灵了。系统全是 200，延迟正常，内容也完整，可结果就是越来越差。

AI 应用线上最常见的问题不是接口报错，是「还能用，但越来越不好用」。 这层的任务，就是把这种说不清的退化变成能看的数字。

它分两步看，先「合格」，再「好坏」。

合格是客观契约。一段客服回复，该有的金额、时效、凭证字段在不在，输出的 schema 对不对，业务规则有没有违反。这些能用规则直接判，非黑即白。

好坏是另一回事。字段全、格式对，不代表事实没写错、语气没跑偏。这部分得靠打分：事实性、相关性、风格，还有最诚实的一个信号——用户最后采纳了没有，是直接用了，还是大改了一遍，还是干脆丢掉重写。

用户开始大量改 AI 给的东西，比任何指标都先告诉你：质量在退化。

打分从哪来？规则、LLM judge、人工抽检、用户反馈，再加一套固定的回归测试集。这套东西上线前当发布门禁，上线后接着抽样监控。

几个典型：

Prompt 改了个版，开始零星漏字段。
换了个「更强」的模型，通用能力是强了，具体业务质量反而掉了。
召回引用了更多文档，看着更有依据，事实命中却更差。

这些在下面两层全都看不见。症状只会在最顶上这层先冒出来。

竖切轴一，症状在顶层，根因在底层

L3 红了，接下来的问题是：为什么。

光知道质量分掉了没用，你得能顺着这次调用，把它背后的东西全扒出来，这就是归因维度。它挂在每一条 trace_id 上：这次用的哪版 Prompt，RAG 召回了哪几篇文档、分数多少，调了什么工具，模型是哪个快照版本。

这条轴本身不报警。 召回变差、模型换版，不会有任何错误码。它的用处，是上面某层一红，你能马上回答「为什么」。

常见的根因就藏在这里：

向量库重建了一次，相似度分数的尺度跟着变了，你之前设的召回阈值悄悄失效。
知识库下架了几篇文档，某类问题直接召回为空。
context 太长，最关键的那篇文档被截掉了。
工具的 schema 改了，模型还按旧格式调，调用全失败。
同一个模型名，背后的版本被供应商换了。

最后一条尤其阴。你的代码、Prompt 一个字没动，模型名也没变，但输出风格和质量变了，因为别名背后的快照换了。不记模型版本，这种问题永远查不到。

竖切轴二，安全审计不能事后捞日志

安全审计很容易被做成一块单独的看板，挂在另一个系统里，平时没人看，出事了才去翻日志。

我觉得这是错的。安全得竖切每一层，实时给每条调用打标签。

它消费的是全链路的数据：L1 的输入输出、归因维度里的召回文档和工具调用、L3 的业务动作。盯的其实是身份和权限——这次输入有没有敏感信息、有没有被注入，召回的文档和调用的工具这个用户够不够格碰，输出有没有把不该露的字段漏出去。最要紧的一条，是真出了事，能顺着 trace 查回到底是哪一步。

几个真会出事的场景：

用户在输入里塞了注入，把 system prompt 劫持了。
RAG 召回了这个用户本来无权访问的文档，敏感内容顺着回复漏出去。
Agent 被诱导，调用了高权限的工具。
出了事去追责，发现 trace 中间断了，根本查不回来是哪一步泄的。

安全要靠全链路 trace 打标签，等出事再捞日志就晚了。

一条 trace 怎么串起来

把上面这些放一起，看一条真实调用怎么走。拿客服工单自动回复举例。

【配图待补：串联流程图——一条 trace 从 L1 到 L3，两条竖切轴 join，底部一条倒查箭头】

正向走一遍：

L1 连通：网关选了个健康的 endpoint，配额够，首 token 正常吐出来。
L2 有效：finish_reason=stop，没截断、没拒答，拿到一段完整回复。
L3 质量：金额、时效、凭证字段都在，业务规则通过，质量分达标，客服没改直接发了。
归因维度：记下这次用的 Prompt v7、召回的 doc_18 和 doc_22、模型版本。
安全维度：输入里的订单号已脱敏，召回文档权限通过，审计链完整。

一切正常，这条 trace 就是一条干净的记录。

关键是出问题的时候。假设某天质量分开始掉，倒着查：

L3 看到事实性变差了，但 schema 和字段还全，所以普通业务校验一声没吭。
顺着 trace_id 翻归因维度，发现这几天召回的文档变了，模型版本也换了。
根因定位：要么知识库动过，要么模型别名背后换了快照。

症状在最顶上的质量层冒出来，根因却在底下的归因维度里。

症状常在顶层可见，根因常在底层发生。 这就是分层加 trace_id 的全部价值，让你能从「结果变差了」一路查到「因为什么变差」。

这套监控该长什么样

回到开头那个问题，AI 系统到底该怎么监控。

现在答案清楚了。三档症状阶梯——连得上、有内容、内容对；一条 trace_id 贯穿；归因和安全两条轴竖切下来。 看板按症状组织，排查靠竖切维度，中间用 trace 串起来。画成一张图，就是前面那个样子。

这张图最要紧的，是它逼你承认一件事：AI 系统最危险的故障，是那些不报错的。接口全绿，结果已经错了。传统监控天生看不见这一层，而这一层恰恰是 AI 应用最容易悄悄烂掉的地方。

这篇先把全路径立住。每一层往深里都还有很多东西，后面一篇篇拆：

L1 连通层：token、延迟、缓存、版本、成本、fallback 怎么细看。
L2 有效层：截断、拒答、内容过滤分别怎么监控。
L3 质量层：合格和好坏怎么量化，评估体系怎么搭。
归因维度：RAG 召回漂移和工具调用怎么观测。
安全审计：怎么真正竖切所有层。

你们的 AI 系统现在监控到哪一层了？是还停在看延迟和错误率，还是已经能看到质量在退化？

欢迎评论区聊聊。

我在攒一个企业 AI 基础设施的交流群，聊 AI Gateway、多模型管理、可观测、评估和安全审计这些真正落地的问题。感兴趣的话，留言或私信我。