AI 可观测性核心原理：非确定性输出下的监控挑战

传统的监控建立在一个没人明说但人人皆知的假设之上：同样的输入会得到同样的输出。出了问题，重放请求，观察它再次出错，然后修复它。

现在把同样的请求发给模型两次。你得到两个不同的答案，而且它们都没有抛出任何错误。

AI 可观测性（AI Observability）是一种实践——在每次请求中记录 AI 系统内部发生了什么：prompt、模型版本、token 数量、成本、延迟、工具调用，以及对输出质量的评判。监控告诉你服务在运行；可观测性告诉你它为什么那样回答。

这个差距就是全部。

为什么你现有的监控栈完全漏掉了这些

你现有的设置在监视崩溃。状态码、错误率、p99 延迟、内存。所有这些都是为一个理念设计的：坏掉的东西看起来就是坏的。

但 AI 功能失败看起来完全不是这样。它返回 HTTP 200，耗时 900ms，输出的散文语法完美——只是内容是错的，或者悄悄忽略了你为它检索的文档，或者在用户只问了一个问题时调用了退款工具。

你的仪表盘看到的是一个健康的服务，因为按照它拥有的所有指标，这个服务确实是健康的。

而且有一整类失败是你的栈完全没有字段来记录的。它没有办法存储"这条回答花了 14 美分"，或者"上周二模型版本在我们不知情的情况下变了"，或者"检索到的上下文是垃圾"。这些不是基础设施层面的事实，标准遥测从来就不是为承载它们而构建的。

必须要有什么东西来存放这些字段，这就是这类工具存在的全部原因。我的团队使用 Bifrost，所以我会用它作为贯穿本文的例子。它是一个来自 Maxim 的开源 AI gateway，所以关于它每次请求记录了什么，你都可以去一行一行地核实。大多数工具把它们的遥测能力放在营销页面上就到此为止了。

当你追踪一条 AI 请求时，它实际上长什么样

这是让我真正理解的部分，所以让我走过一个真实的形态。

在 Keploy，我用向量嵌入在他们文档上构建了一个检索增强聊天机器人，这样开发者就可以提问题而不是在页面中翻找。像这样的一个问题不是一次操作。它是一个链，而一次追踪（trace）就是这条链的书面记录。

一次请求会拆分成多个 span，一个 span 是带有自己起止时间、输入和输出的一步：

• 用户的问题进来，打开根 span。
• 问题被嵌入成向量。这是一个 span，有自己的模型和自己的成本。
• 向量搜索运行并返回，比如五块文档内容。这是一个 span，重要的地方在于它记录了返回来的是哪五块。
• 这些块被塞进一个 prompt 模板，加上聊天历史。
• 模型调用发出。这个 span 携带模型名称和版本、温度、prompt token 数量、completion token 数量、美元成本、总延迟，以及首个 token 的时间。
• 如果模型调用了工具，每一个工具调用也都有自己的子 span。

现在说为什么有人愿意花这么多功夫来做这些。

当机器人给了一个糟糕的回答，你不需要猜测。你打开追踪，看第 3 步。如果向量搜索拉回来的是五个不相关的块，问题在分块或嵌入上，模型没有做错任何事。如果搜索拉回来的恰好是正确文档而模型仍然凭空回答，问题在 prompt。

两种完全不同的修复方案，但没有追踪你无法区分它们。你有的只是"机器人说了句蠢话"，这是世界上最没用的 bug 报告。

每次调用都值得捕获的内容

你会注意到我没有把这一节叫做"可观测性的三大支柱"。其他写这个话题的人都是这么叫的，而我故意弃用了，因为日志、指标和追踪是针对确定性系统建立的框架，它根本没有"回答质量好吗"这个插槽。

所以这里是真列表：

• 完整的 prompt 和响应，以它们真正在网络上传输的样子，在每个模板和系统消息组装完成之后。不是模板本身，是最终的文本。
• 模型、版本和参数。提供商静默更新。如果你说不出是哪精确版本回答了一个请求，你就无法解释上个月的回归。
• 输入 token 数、输出 token 数，以及每次请求的美元成本，归因到用户或功能。
• 延迟，拆分为总时间和首个 token 时间。对用户来说这两个数字体验完全不同，一个可能变差而另一个变好。
• 工具调用、重试和降级。尝试了哪个 key、什么失败了、降级到了什么。
• 一个 trace ID，把整条链串在一起，最好还有一个 session 或用户标识符，这样你可以重建完整对话。
• 一个质量分数，事后附加。这一点下一节详述。

我今年早些时候自己做过其中一个，是一个合同角色中的内部工具，捕获一个 AI 产品的日志并把它们转化成延迟和可能慢点的报告（故意保持模糊，不能多说）。诚实的收获不是这个工具多精巧。而是团队可以凭感觉闷头开发好几个月，而一旦有人把每次请求的数字放到屏幕上，之前没人有词汇去描述的问题突然就有词汇了。

当没有标准答案时，如何衡量质量？

好吧，你不能用单元测试的方式来衡量它，因为没有可比较的预期字符串。

业界基本达成了三个重叠的方案。LLM-as-judge——把输入和输出发给第二个模型，带一个评分规则，让它打相关度、忠实度或语气分。它不完美，但比什么都没有好得多。人类在样本上做标注，慢、贵，但仍然是所有其他方案的校准基准。还有隐式用户信号，比如点赞、编辑和重试，嘈杂但是免费的。

持续运行这些，你就得到了漂移检测（drift detection），就是同一个分数随时间测量。当你的忠实度分数在两周内下降了 8 分而没有人部署任何东西，有什么东西在你下面动了，而那通常是模型提供商。

这是大多数团队跳过的那个半区，而且有数据支持。在 LangChain 的 2026 年 Agent 工程状态报告中，调查了 1300+ 从业者，89% 说他们的 agent 运行了可观测性，但只有 52% 在跑评估。所以大多数人在记录发生了什么，但仍然对好不好没有系统性的意见。

这也是为什么我一直在说，你不能用测试代码的方式测试 AI 功能。我在关于测试 AI 编码 agent 的文章里详细讲过这个失败模式。

AI 可观测性实际上在你的栈里处于什么位置

两个选择，而且你可以同时做。

你可以直接在应用层做插桩，在你自己的代码里包装每个模型调用。这样你能获得最丰富的上下文，因为你的代码知道用户在做什么。但这同时也意味着每种服务、每种语言和每个框架都得单独插桩，而且得有人来保持一致性。

或者你把它放在 gateway 层。如果你所有的模型流量已经通过一个代理，那个代理按定义就能看到每次请求和每次响应，而你得到的是你从未接触过的服务的遥测。

而之所以你能两者都做而不会加倍工作量的原因是，终于有了一个共享标准。OpenTelemetry GenAI 语义公约（semantic conventions）为这些定义了统一的属性名称，比如 gen_ai.request.model、gen_ai.usage.prompt_tokens 和 gen_ai.usage.cost。发出这些，你 AI 的 span 就和你系统其余部分的追踪插槽到同一个后端里了，不管你已经在用哪家。

Bifrost 在这里值得一看，因为它同时做了两层。它把每次调用的输入、输出、token、成本和状态记录到 SQLite 或 Postgres，加上仪表盘，并使用那些 GenAI 公约导出 OpenTelemetry span，以及原生 Prometheus 计数器如 bifrost_input_tokens_total 和 bifrost_cost_total。日志运行在后台 goroutine 中，这就是为什么它的文档把额外开销放在每次请求 0.1ms 以下。

无论你最终选哪个工具，最后这个细节是值得抄走的模式。遥测在热路径之外发出，在响应已经在返回给用户的路上之后。拖慢它正在观察的东西的可观测性，一周内就会被关掉。

同一个 gateway 的路由侧也值得了解，我在关于自适应负载均衡的文章里写过。

运行它的成本

现在是那个不舒服的部分，因为这些都不免费。

存储增长很快。你在存储完整的 prompt 和完整的响应，而 prompt 很长了。一个检索应用轻松可以达到每次调用 8000 token 的上下文。在真实流量下那是相当大的文本量，这就是采样的用武之地：保留 100% 的错误和慢请求，保留健康请求中的一小部分。

你的 prompt 里包含用户数据。每一次支持对话、每一份上传的文档、每一个用户粘贴进来的邮件。一旦你把它们全部记录下来，你的可观测性存储就成了一个持有个人数据的系统，带有所有相应的保留和访问规则。在捕获点脱敏，而不是之后。

而且得有人真的去看。这是悄悄扼杀整个努力的那一项。追踪被收集起来，仪表盘被搭好，没人打开，六个月后它成了一个非常昂贵的只写数据库。

常见问题

AI 可观测性和 LLM 监控是一回事吗？ 接近，而且监控是更窄的那个。监控追踪已知指标如正常运行时间、延迟和错误率，回答"它在工作吗"。可观测性保留足够多的每次请求细节，让你能够回答你还没想到的问题，比如"为什么这个用户得到了那个答案"。实际上大多数工具在同一个名字下卖两者。

我需要 OpenTelemetry 吗？ 不需要，但它是 2026 年的合理默认值。GenAI 语义公约意味着你的 AI span 在任何地方使用相同的属性名，所以你可以换供应商而不需要重新插桩，而且你的模型调用和你的数据库查询出现在同一个追踪里。注意规范的某些部分仍标记为实验性，所以锁定你的版本。

可观测性和评估的区别是什么？ 评估是测量，可观测性是管道。评估给输出打分是否好；可观测性捕获请求、上下文、成本和追踪，这样分数有东西可以附加。你可以在 CI 中用固定数据集离线跑评估，但只有当流量被记录下来时才能在真实流量上跑。

所以你实际上应该怎么做？

如果你现在生产环境里有一个 AI 功能，而你无法拿出上周二某次请求的确切 prompt、模型版本和成本，那就是差距所在，这值得你花一天时间。

从捕获开始，而不是从仪表盘开始。让每次请求都被记录——包含它的 prompt、响应、模型、token、成本和一个 trace ID，放到你已经在看数据的地方，给它两周。你会发现东西。每个人都是。质量评分、漂移警报和按功能的成本预算是后来值得加的，但它们每一个都建立在那层无聊的捕获层之上，所以先做它们没有意义。

如果你的模型调用已经通过了一个 gateway，打开它自带的遥测配置，在你自己去写任何这些之前。那是你在这里能花的时间里最高价值的那个小时，而且它大部分只是一个配置变更。

这是我的看法，你的设置可能和我的完全不同。如果你自己做过这种追踪，或者你的 AI 可观测性账单真的让你惊讶了，留在评论区，我想听听进展如何。

你可以在 X 上找到我，我会在上面发布我正在做的大部分东西，其余文章在 swapnoneel.site。