AI Observability 是什么?大模型可观测性与链路追踪详解

AI Observability可观测性链路追踪

AI 可观测性指把模型调用、工具执行和智能体决策全过程记录成可查询的链路数据,用来回答「它当时为什么这么做」。传统监控只看服务是否正常,而 AI 应用的失败大多是「返回了 200 但答案是错的」

AI 可观测性指的是把一次 AI 请求的完整过程记录下来并变得可查询:用了哪个模型、输入是什么、消耗了多少 TokenAgent 决定调用哪个工具、工具返回了什么、最终为什么给出这个答案。目标是当有人说「昨天它给客户报错了价」时,你能把那一次的完整链路调出来看。

传统的服务监控关心的是可用性:接口是不是 200、延迟是不是超标、错误率有没有上升。AI 应用的麻烦在于——它几乎总是返回 200。调用成功了,延迟正常,但答案是错的、引用是编的、工具调错了参数。这类失败传统监控完全看不见。

先用一句话抓住它

可观测性回答的不是「服务挂没挂」,而是「它当时到底是怎么想的」。

打个比方。传统监控像餐厅门口的客流计数器,能告诉你今天来了多少人、有没有排长队。AI 可观测性更像厨房里的全程录像:这道菜用了哪些原料、火候多久、中间返工过几次。客人投诉时,前者只能告诉你那天很忙,后者能让你看到到底哪一步出了问题。

它记录哪些东西

一次用户请求(trace) Agent 运行 span 模型调用 span模型 · 输入输出 · token · 停止原因 工具执行 span参数 · 返回 · 耗时 · 是否报错 检索 span查询 · 命中片段 · 相关度 再一次模型调用… 最终回答 质量评分离线 evals · 线上抽检 · 用户反馈

结构上沿用了分布式追踪那一套:一次用户请求是一条 trace,里面嵌套着一个个 span——每次模型调用、每次工具执行、每次检索都是一个 span,带上各自的输入输出和耗时。

AI 特有的字段主要有几类:模型与参数(用了哪个模型、温度多少)、Token 用量(输入、输出、缓存命中,直接换算成钱)、停止原因(正常结束还是被截断还是要调工具)、以及可选的内容留存(提示词和回答原文)。

内容留存是这里最需要权衡的一项:不存就没法排查,存了就等于把用户输入长期保留在监控系统里,涉及隐私和合规。常见做法是默认脱敏、按采样率留存、并对敏感字段做遮蔽。

标准化:OpenTelemetry GenAI 语义约定

早期各家平台各记各的字段名,导致同一件事在不同工具里叫法不同,换供应商就得重做埋点。OpenTelemetry 的 GenAI 语义约定就是来统一这件事的:规定模型调用、工具执行、Agent 运行、检索这些操作各应该用什么 span 名和属性名,比如用 gen_ai.request.model 记模型、用 gen_ai.usage.input_tokensgen_ai.usage.output_tokens 记用量。

这样做的好处是埋点一次、后端可换:LangChain 里的一次 Agent 调用和裸调 API 的一次请求,在数据结构上长得一样。

需要注意的是,截至 2026 年,GenAI 相关的语义约定仍处于 Development 状态,属性名和结构仍可能变化,多智能体和 MCP 相关的约定还在制定中。规范提供了 OTEL_SEMCONV_STABILITY_OPT_IN 这类开关来过渡版本差异。实践上现在按它埋点是合理的,但要预留改名的余地。

和相邻概念的区别

和评估的关系:这两件事互为闭环。可观测性负责记录线上真实发生了什么,评估负责判断好不好。线上发现的失败案例应该被沉淀成评估集里的用例,改完之后再用同一套评估验证。只有可观测性没有评估,你只能事后救火;只有评估没有可观测性,你测的永远是自己想象出来的场景。

和传统 APM 的区别:指标体系不同。APM 关心 QPS、P99 延迟、错误率;AI 应用还要关心 Token 成本、缓存命中率、工具调用成功率、检索命中质量、以及回答的正确性——最后这一项没法自动判定,需要采样人工复核或用模型打分。

和护栏的区别护栏是运行时拦截,出问题当场阻止;可观测性是事后记录,用来分析和改进。二者共用很多信号,但作用时点不同。

和上下文工程的关系:可观测性提供了做上下文工程所需的事实依据。把一次调用的 Token 按来源拆开——系统提示占多少、工具定义占多少、历史占多少、检索结果占多少——才知道该优化哪一块。

容易误解的地方

「记了日志就是有可观测性」——散落的日志没法回答「这一次请求经过了哪些步骤」。关键是结构化和可关联:同一次请求的所有 span 要能串起来看,而不是在几个服务的日志里各翻一段。

「延迟正常就没问题」——AI 应用最典型的故障是「快速地给出错误答案」。质量指标必须和性能指标一起看。

「全量留存内容最稳妥」——全量留存意味着你的监控系统里存着大量用户原始输入,一旦被入侵就是重大泄露,而且很多合规要求里这属于需要单独说明的数据处理。默认脱敏 + 采样通常是更合理的起点。

「上了平台就自动有了」——工具能给你 trace,但决定看什么指标、把哪些失败沉淀成用例、按什么标准判定好坏,仍然是要自己想清楚的事。

从哪里开始

不必一步到位。最小可用的三件事是:给每次请求一个可追溯的 ID(能把用户反馈和具体那次调用对上)、记录模型、Token 用量和停止原因(成本和截断问题立刻可见)、记录工具调用的参数和返回(Agent 出错最常见的地方)。

这三项做完,多数线上问题已经能定位。之后再按需要加:检索命中质量、缓存命中率、按用户或按功能的成本拆分,以及把线上失败案例定期回流到评估集里。

资料来源