AI 系统监控

AI 系统监控

flowchart LR
  A["AI 系统监控"]
  A --> B["分类：工程与生产"]
  A --> C["关键词：AI"]
  A --> D["关键词：监控"]
  A --> E["关键词：可观测性"]
  A --> F["关键词：Trace"]

AI 系统的可观测性，不只是“接口有没有挂”，而是要回答另一类更难的问题：为什么这次回答突然变差了，为什么某类请求开始乱用工具了，为什么 Prompt 明明没改、效果却漂了。传统 APM 仍然重要，但对 AI 系统来说，它只覆盖了问题的一部分。

---

延伸阅读：

• LangSmith —— LangChain / agent 可观测性与评估平台
• Langfuse —— 开源 LLM 可观测性
• OpenTelemetry —— 通用可观测性基础设施

---

这篇文章会讲什么

传统监控会告诉你：

• 服务挂了没有
• 延迟升高没有
• 错误率是不是超阈值
• 哪个实例 CPU 打满了

但 AI 系统更常见的问题是：

• 模型没有报错，但回答质量下降了
• 某个 Prompt 版本上线后，JSON 格式成功率变差
• 某类请求的输出 token 突然暴涨，成本开始失控
• 同一个工具在某些问题上被反复误调用
• RAG 没召回、召回错、还是模型没用好上下文，根本分不清
• Agent 能跑完流程，但步数突然变多、变慢、变贵

这些问题如果只靠状态码、错误堆栈和平均延迟，是看不出来的。

OpenTelemetry 官方文档把可观测性定义为 traces、metrics 和 logs 的统一遥测体系，这当然仍然是底座。(OpenTelemetry) (OpenTelemetry) 但在 AI 系统里，你还需要把 Prompt、模型调用、工具调用、token、成本、质量评分、会话上下文 这些对象纳入可观测范围，才谈得上真正可调试、可定位、可治理。LangSmith 官方文档把 tracing、evaluation、prompt engineering 和 deployment 放在同一平台能力里；Langfuse 官方文档则明确把 tracing、latency、cost、debugging 与 evaluation 放在同一体系中。(LangSmith) (Langfuse) (LangChain 文档)

所以这篇文章讨论的不是“AI 监控工具清单”，而是一个更实用的问题：

AI 系统到底该监控什么，怎么监控，哪些信号能帮你真正定位问题，哪些只是看起来热闹。

---

1. AI 可观测性 vs 传统 APM：多出来的不是几个字段，而是一类新的调试对象

一句话概括：

传统 APM 关注系统是否可用；AI 可观测性还要关注系统是否“在业务上可接受”。

这两者不是替代关系，而是叠加关系。

1.1 传统 APM 主要回答“系统有没有挂”

例如：

• 请求成功率
• 服务延迟
• 错误堆栈
• 资源占用
• 数据库慢查询
• 外部依赖可用性

这些对 AI 系统仍然重要。因为无论系统多智能，只要 API 经常超时、推理服务不稳定、队列积压，用户一样用不起来。

1.2 AI 可观测性要额外回答“系统为什么看起来成功，却在业务上失败”

这是 AI 系统真正麻烦的地方。常见的“伪成功”包括：

• HTTP 200，但回答事实错误
• JSON 能 parse，但字段语义错了
• 工具调用成功，但调用了不该调的工具
• 模型给了答案，但拒绝率异常升高
• 结果看起来还行，但输出 token 突然变长，成本翻倍
• Agent 完成了任务，但走了 12 步，本来 3 步就够

这类问题如果只看传统 APM，通常会被误判为“系统正常”。

1.3 AI 可观测性真正新增的观测对象

你需要开始观测的不只是“请求”，还包括：

• Prompt 版本
• 模型版本
• 输入 / 输出 token
• 缓存命中与否
• 工具调用路径
• 检索上下文
• Session / Thread
• 质量评分
• 人工反馈
• 每一步的成本与延迟

LangSmith 官方文档强调每个请求都会生成一个 trace，其中包含单独的 runs，用来记录 LLM 调用、检索步骤等具体执行操作。(LangSmith tracing quickstart) (docs.langchain.org.cn) Langfuse 文档则把 trace 定义为顶层容器，并支持把 spans、generations、events 聚合到同一个 trace 或 session 中。(Langfuse Trace) (Langfuse Sessions) (Hexdocs)

这意味着，AI 可观测性最核心的变化不是“多记几个日志字段”，而是：

要把原本不可见的模型行为链路，变成可以被追踪、比较、评分和告警的对象。

---

2. AI 可观测性的三支柱：Trace、指标、评估

如果要把 AI 监控体系压缩成最有用的框架，我更建议用这三个支柱来理解：

支柱	解决什么问题	典型内容
Trace	这一条请求到底发生了什么	Prompt、模型调用、检索、工具、输出、耗时
指标	系统整体趋势是否在变坏	TTFT、P95、错误率、token、成本、拒绝率
评估	输出质量是否在退化	格式合规、相关性、事实性、任务完成率

这三者缺一不可。

2.1 Trace：解决“怎么复现”和“哪一步出问题”

调试时最常见的第一需求不是看 dashboard，而是：

• 把这条出问题的请求完整拉出来
• 看它到底经历了什么
• 具体是在哪一步跑偏

所以 Trace 往往是 AI 可观测性的第一入口。

2.2 指标：解决“这是偶发问题，还是系统性趋势”

一条 trace 能帮你定位单个问题，但它回答不了这些问题：

• 最近一周 TTFT 为什么在升高
• 哪个模型的错误率突然上升
• 哪个租户的成本开始异常增长
• 哪个 Prompt 版本的输出 token 突然变长

这就需要指标层。

2.3 评估：解决“看起来成功的输出，到底好不好”

Trace 和指标可以告诉你：

• 调用了哪个模型
• 花了多少 token
• 用了几秒
• 有没有报错

但它们不能直接回答：

• 这个回答是否相关
• 这个 JSON 是否语义正确
• 这个 RAG 回答是否忠于上下文
• 这个 Agent 是否真的完成了目标

这就是评估层的职责。

Phoenix 官方文档明确区分了 tracing 与 evaluations：trace 告诉你发生了什么，但并不能告诉你输出是否好；evaluation 用来对 traces、datasets 或任意数据源进行一致、可重复的打分。(Phoenix get started evaluations) (Phoenix LLM evals) (Arize AI)

这也是 AI 可观测性和传统 APM 最本质的差异之一：

AI 系统的监控，最终一定会和评估体系打通。

---

3. Trace：先把“这条请求发生了什么”完整还原出来

先看定义：没有 trace，你只能猜；有了 trace，你至少能看到系统到底是在哪一层开始偏。

3.1 一条 AI Trace 至少应该包含什么

典型的一次 AI 请求，常常不只是一个模型调用，而是一条链路：

Request
  ├── 鉴权 / 路由
  ├── Prompt 组装
  ├── 检索 / 重排
  ├── Model Call #1
  ├── Tool Call #1
  ├── Model Call #2
  ├── 输出后处理 / 结构化解析
  ├── 安全检查 / 规则校验
  └── Final Response

每个节点最好都记录：

• 开始 / 结束时间
• 输入摘要
• 输出摘要
• token 数
• 成本
• 模型或工具名称
• 错误与重试信息
• 标签与元数据

LangSmith 文档明确支持 tracing 任意 Python / JS 代码、记录 token count、计算 token-based cost、记录 retriever trace、多模态 trace，并支持 dashboards、alerts、online evals。(LangSmith observability guides) (LangSmith) Phoenix 文档也把 trace 定义为单次运行记录，并拆成 spans 来表示 agent、task、tool 等步骤。(Phoenix tracing) (Arize AI)

3.2 Trace 里最容易漏掉，但最有用的几个字段

很多团队会记录“prompt 和 response”，但真正调试起来，最有用的往往还包括：

• Prompt 版本 / 模板 ID
• 模型版本
• session / thread ID
• 租户 / 用户标签
• 检索文档 IDs
• 工具参数
• 是否命中缓存
• 是否发生 fallback
• 当前实验桶 / 路由策略版本

因为线上问题往往不是“模型突然变笨”，而是：

• 某个 prompt 版本误发布了
• 某类请求被路由到了错误模型
• 某个租户进入了错误的实验桶
• 缓存把旧答案复用了
• 检索结果变了，导致上下文质量下降

3.3 Trace 设计最重要的一条：信息要足够复现，但不能为了复现把所有敏感数据都裸记下来

这是 AI 日志和 trace 最常见的工程张力之一：

• 不记够 → 无法定位问题
• 记太多 → 隐私、合规、日志成本都失控

更成熟的做法通常是：

• 记录可复现所需的最小充分上下文
• 对输入 / 输出做脱敏
• 对长上下文保留摘要、哈希、引用 ID，而不是全量明文
• 对高敏感字段做红线过滤
• 允许对特定高风险项目启用更严格的日志策略

LangSmith 官方文档也专门提供“防止在追踪中记录敏感数据”的能力说明。(LangSmith observability guides) (LangSmith)

---

4. 关键指标：AI 系统里该盯的，不只是错误率和平均延迟

先看定义：AI 监控的指标体系，至少要同时覆盖性能、成本、行为、质量四类信号。

4.1 性能指标：先把延迟拆开，而不是只看一个总耗时

最常见也是最有价值的拆法包括：

• TTFT（Time to First Token）
• 总延迟
• P95 / P99
• 排队时间
• 工具调用耗时
• 检索耗时
• tokens per second

这很重要，因为同样是“慢”，根因可能完全不同：

• 模型排队严重
• Prompt 太长导致 prefill 慢
• 工具接口慢
• Agent 走了过多步骤
• 生成速度下降
• 网络层抖动

如果不拆延迟，只看一个 end-to-end latency，排障效率会很低。

4.2 成本指标：很多线上事故首先表现为“账单不对劲”

至少要长期盯住这些：

• 每请求 input / output token
• 每请求成本
• 按模型的成本分布
• 按租户 / 功能的成本分布
• 缓存命中率
• fallback 比例
• 输出 token 长尾分布

因为 AI 系统很多质量问题，会以成本异常的方式先暴露出来：

• 某个 Prompt 改坏了，输出突然变长
• 某个工具循环开始反复调用
• 某类请求突然都升级到了更贵模型
• 某个检索策略让输入上下文暴涨

4.3 行为指标：AI 系统里很多问题是“行为漂移”，不是硬错误

这类指标往往比错误率更早预警：

• 拒绝率
• 工具调用率
• 平均步数
• 结构化解析失败率
• 转人工率
• 追问率
• 会话中断率

例如：

• 拒绝率突然升高，可能是模型行为变了
• 工具调用率突然下降，可能是工具描述或路由出问题
• 平均步数增加，可能是 agent 在绕路
• JSON parse 失败率上升，可能是 prompt 或模型格式稳定性变差

4.4 质量指标：这是 AI 系统和传统 APM 分界最明显的地方

质量指标不一定都能实时算，但关键场景至少应该持续跟踪：

• 格式合规率
• 相关性评分
• 忠实度 / hallucination 风险
• 引用正确率
• 任务完成率
• 用户反馈分数
• LLM-as-judge 分数趋势

Langfuse 文档明确支持把 scores 加到 traces、observations、sessions 和 dataset runs 上，并提供 score analytics 来看分布、趋势和不同评分方法之间的一致性。(Langfuse scores via SDK) (Langfuse score analytics) (Langfuse)

这说明一个越来越主流的实践是：

把质量信号直接挂到 trace 和 session 上，而不是把评估和监控分成两个完全割裂的系统。

---

5. 质量监控：AI 系统真正难监控的，不是“会不会报错”，而是“会不会悄悄变差”

先看定义：很多最危险的 AI 问题，不会触发 500，也不会打爆 CPU，但会持续侵蚀用户体验、成本和业务结果。

5.1 先监控最容易自动化的质量信号

这类信号往往应该最早上线：

格式合规

例如：

• JSON 能否成功解析
• schema 是否满足
• 必填字段是否齐全
• 工具参数是否合法

这是最适合用规则做的质量监控，也是最容易工程化的第一层。

拒绝率

例如：

• 本不该拒绝的场景，拒绝突然升高
• 某模型版本上线后，对某类用户过度保守

这往往是行为漂移的重要信号。

引用 / 检索一致性

在 RAG 系统里，至少可以监控：

• 是否提供了引用
• 引用是否来自召回上下文
• 回答是否包含明显超出上下文的断言

这类指标不一定能完美判断 hallucination，但至少能建立早期警报。

5.2 再监控更“软”的质量趋势

例如：

• 回答相关性
• 助人性 / helpfulness
• 回答完整性
• 风格一致性
• Agent 目标完成度

这类指标通常要靠：

• LLM-as-judge
• 人工抽样
• 线上反馈
• 组合评分

Langfuse 官方文档明确支持 LLM-as-a-Judge、人审和自定义 evaluation workflows。(Langfuse evaluation overview) (Langfuse) Phoenix 也支持 deterministic evaluators 与 LLM-as-a-judge，并能在 traces 上运行 evals。(Phoenix LLM evals) (Phoenix traces evals) (Arize AI)

5.3 一个关键实践：质量监控最好做“趋势监控”，不要只盯绝对值

因为很多质量信号本来就有噪声。 真正值得告警的，常常不是“今天分数是 0.82”，而是：

• 相比过去 7 天下降了多少
• 某个 Prompt 版本后明显变差
• 某个租户、某个场景持续低于 baseline
• 某个模型切换后分布发生了明显漂移

这意味着，AI 质量监控更像统计监控，而不是传统硬阈值监控。

---

6. 日志最佳实践：不是“什么都记”，而是“记对排障真正有用的东西”

先看定义：日志要服务于复现、归因和治理，而不是满足一种“多记总没错”的心理安慰。

6.1 建议优先记录的内容

内容	为什么重要
Prompt 摘要 / 模板 ID / 版本	复现与回滚
Response 摘要 / 原文（按策略）	质量分析与投诉排查
模型、参数、路由策略	归因
Token、成本、延迟	性能与成本分析
Tool 调用名称、参数摘要、结果摘要	Agent / workflow 调试
Retriever 结果 ID	RAG 排障
Session / thread ID	还原用户全链路
用户 / 租户标签	定位特定人群问题

6.2 不建议直接裸记的内容

• 原始 PII
• 身份证号、银行卡号、手机号等敏感字段
• 高敏感业务数据
• 不必要的完整长上下文
• 与排障无关的冗长工具返回

更成熟的方案通常是：

• 哈希化 / 脱敏化
• 按字段级红线过滤
• 保留 ID 与引用，而不是全量明文
• 对大上下文做采样、截断或摘要化
• 给不同项目 / 租户设置不同留存策略

6.3 日志和 Trace 的关系

很多系统会把 trace 和日志混用。 但更清晰的理解通常是：

• Trace：这条请求的结构化执行路径
• 日志：对路径中关键节点的附加说明、异常信息和调试信息

如果 trace 做得足够好，日志的角色应该从“承担所有信息”降级为“补充上下文”。

---

7. 工具选型：不要只看“支持什么模型”，更要看“能不能接住你的工作流”

先看定义：AI 可观测性工具的差异，不只在功能多少，更在于它更偏 tracing、evaluation、production analytics，还是更偏某个框架生态。

7.1 LangSmith：更偏 agent / LLM app 全链路开发与运营

LangSmith 官方文档把自己定义为 framework-agnostic 平台，可用于 trace requests、evaluate outputs、test prompts、manage deployments。(LangSmith) (LangChain 文档) 其 observability 文档也明确支持 dashboards、alerts、automation rules、online evaluations、human feedback，以及与 OpenTelemetry 的集成。(LangSmith observability guides) (LangSmith)

这意味着 LangSmith 的优势不只是“LangChain 官方”，而是：

• 从 tracing 到 evaluation、feedback、monitoring 一体化
• 对 agent / workflow 场景支持更自然
• 对 LangChain / LangGraph 用户尤其顺手
• 但也不是只能配 LangChain 用

7.2 Langfuse：更强调开源、自托管、通用 tracing + evaluation

Langfuse 官方文档明确强调：

• 开源 application tracing and observability for LLM apps
• 支持 traces、latency、cost、debugging
• 支持 scores、datasets、experiments、sessions 等评估与分析能力。(Langfuse observability) (Langfuse core concepts) (Langfuse)

它很适合这些团队：

• 希望更强的数据自主权
• 有自托管需求
• 不想被某个应用框架绑定
• 想把 tracing、session、score、experiment 放在同一开源体系里

7.3 Phoenix：更强调 traces、evals、feedback 的结合

Phoenix 官方文档把 tracing、evals、feedback、cost tracking 和 production traces 的评估放在同一产品路径里。(Phoenix user guide) (Phoenix tracing cost tracking) (Phoenix evals on traces) (Arize AI)

它更像是把“观察发生了什么”和“判断它好不好”尽量拉近。

7.4 Helicone：更轻量，偏代理式接入与 API 观测

Helicone 文档里明确有 sessions、user metrics、scores、evaluation 等能力，并强调在 agent / workflow 场景下把多次请求聚合为 unified view。(Helicone sessions) (Helicone user metrics) (Helicone eval scores) (docs.helicone.ai)

它比较适合：

• 想快速给 API 流量加观测层
• 想先从代理与请求分析入手
• 场景相对简单，想尽快看到 token、成本、session 级行为

7.5 一个更实用的选型标准

与其问“哪个工具最好”，不如问：

• 你更需要 tracing，还是 tracing + eval 一体化？
• 你是否需要自托管？
• 你是不是深在某个框架生态？
• 你是否要把生产 traces 和评估打通？
• 你是否要做 session / conversation / agent 级观测？
• 你是否希望和 OpenTelemetry 体系兼容？

工具差异很真实，但再好的工具也替代不了你自己定义：

• 哪些字段要打
• 哪些链路要采样
• 哪些质量分要持续跟踪
• 哪些场景必须出告警

---

8. 告警策略：别把 AI 告警做成“狼来了”

先看定义：AI 系统的告警既不能只有基础设施告警，也不能什么质量波动都报警；关键在于分层和分级。

8.1 至少分三层告警

第一层：基础可用性告警

典型如：

• 错误率飙升
• 请求大量超时
• 推理服务不可用
• 队列积压
• 工具服务挂掉

这类最接近传统 APM，通常应该是 P0。

第二层：性能 / 成本异常告警

例如：

• TTFT P99 翻倍
• 平均 output tokens 异常增长
• 单请求成本超过 baseline
• fallback 比例升高
• 某租户成本突增

这类通常是 P1 或 P2，但很值得尽早发现，因为它们常常是质量问题的前导信号。

第三层：质量趋势告警

例如：

• JSON parse success rate 持续下降
• 回答相关性评分低于过去 7 天基线
• 某模型版本上线后拒绝率明显升高
• 某 Agent 任务完成率下降
• 某类 trace 的 score 持续变差

这类告警常常更有业务价值，但也更容易产生噪声，所以更适合用趋势和统计阈值，而不是单点硬阈值。

8.2 AI 告警一定要避免的两个坑

1. 指标太多，没人看

如果你一口气把 30 个质量指标都接入告警，团队很快就会疲劳。 更好的做法是：

• 关键链路只保留少数北极星监控
• 其他指标进入 dashboard 观察，但不直接报警

2. 只对“坏结果”报警，不对“坏趋势”报警

AI 系统很多问题不是一次性爆炸，而是缓慢漂移。 如果等到“完全坏了”才报警，通常已经影响大量用户了。

所以更成熟的策略是：

• 把绝对阈值用于可用性事故
• 把相对变化和趋势用于质量 / 成本 / 行为漂移

---

9. 调试 AI 问题：真正有效的排查方式，通常是沿 Trace 分层拆

先看定义：AI 问题很少能靠一句“模型不稳定”解决。真正有效的排查，通常要按链路逐层拆。

一个更实用的顺序通常是：

第一步：先找到有代表性的坏样本

不是看平均指标，而是先把具体出问题的 trace 抓出来：

• 用户投诉样本
• 评分低样本
• 高成本异常样本
• 结构化失败样本
• Agent 步数异常样本

第二步：看 Prompt 和上下文是否已经错了

很多问题其实在模型调用之前就埋下了：

• system prompt 版本错了
• 检索上下文不相关
• 工具说明不完整
• 历史对话污染了当前任务
• 路由把请求送错模型了

第三步：再看模型输出和工具行为

例如：

• 模型是否拒绝过度
• 是否格式漂移
• 是否 hallucinate
• 工具参数是否错
• 工具结果是否被正确吸收

第四步：最后才判断是不是模型本身不适合

这一步很重要。 因为很多“模型问题”最后发现其实是：

• prompt 问题
• 检索问题
• 工具问题
• 缓存问题
• 路由问题
• 评估问题

Trace 的价值就在于，它能把这些层拆开，而不是让所有锅最后都归到“模型不稳定”。

---

10. 一个更成熟的视角：AI 可观测性最终会变成“运行时 + 质量 + 治理”的统一面板

做到后面你会发现，AI 监控不只是“调试方便”这么简单。它最终会服务于三类目标：

10.1 运行时目标

• 服务可用
• 延迟可控
• 成本可控
• 工具链稳定

10.2 质量目标

• 输出相关
• 格式稳定
• RAG 忠实
• Agent 可完成任务
• 安全风险可控

10.3 治理目标

• 哪个 Prompt / 模型版本在跑
• 哪个租户花了多少钱
• 哪类请求最常失败
• 哪些场景应该降级
• 哪些问题必须转人工

这也是为什么今天越来越多的 AI 可观测性工具，不再只做 tracing，而是在往：

• evaluations
• scores
• sessions
• dashboards
• alerts
• feedback
• datasets / experiments

这些能力延伸。因为单纯“看见请求”已经不够了，团队最终需要的是：

看见请求、理解趋势、判断质量、并对版本和策略做运营级决策。

---

小结

AI 系统监控的核心，不是把传统 APM 换个名字，而是在传统可用性监控之上，再长出一层真正面向模型行为的可观测体系：

• Trace 用来还原单条请求的完整路径，解决复现和定位
• 指标 用来观察性能、成本、行为和质量的整体趋势
• 评估 用来回答“输出到底好不好”，并把质量信号接入生产监控
• 日志 要服务于复现与归因，而不是无边界地堆数据
• 工具选型 要看 tracing、eval、session、self-hosting 和生态兼容，而不是只看名气
• 告警策略 要分层分级，优先抓住真正影响用户和业务的问题
• 调试方法 要沿 trace 分层拆，而不是把一切都归结为“模型不稳定”

如果要把这篇文章压缩成一句话，大概就是：

AI 可观测性不是看系统有没有跑，而是看系统为什么这样跑、是否值得这样跑、以及什么时候开始不该再这样跑。

没有这层能力，AI 系统一旦进入真实业务，出问题时就只能靠猜； 有了它，你才真正拥有了把模型系统化运维的起点。

---