299 篇博文 含有标签「observability」

我在上个季度交流过的一个团队花了六周时间追踪其智能体（agent）平台上的内存压力报警。这些智能体的运行成本很低——每次运行只需几美分。但追踪（trace）却不是。他们的遥测流水线消耗的预算是其所监测的 LLM 调用预算的三倍，而且大部分支出都花在了几个月没人看过的字段上：每个 span 上存储的完整 prompt 正文、在父级和子级追踪中重复出现的工具输出，以及一个在每次捕获的追踪上重新支付推理费用的 LLM-judge 评估器。

这是 AI 可观测性成本危机的缩影。一份 2026 年的行业报告模拟了一个拥有 10,000 个对话且每个对话有五轮互动的客户服务机器人——这相当于每天 200,000 次 LLM 调用、4 亿个 token，以及大约 100 万个追踪 span。Datadog 用户广泛报告，在处理其 REST API 的相同后端上监测 AI 工作负载后，可观测性账单飙升了 40-200%。流水线在为同样的 token 支付两次费用：一次是为了生成它们，一次是为了记住它们。

解决方法不是“减少日志”。解决方法是将 AI 系统的可观测性视为一种具有自身单位经济效益的工作负载，与传统服务发出的请求-响应遥测分开处理。传统日志是你可以压缩并遗忘的结构化字段；AI 日志则是无限制的文本正文，每当有人读取它们时，就会重新计入推理预算。这种区别就是“Token 感知日志”的含义。

一个欺诈检测模型的准确率在三周内悄无声息地下降了一半。延迟正常，错误率为零，所有基础设施仪表盘都显示绿色。工程师们在第一周审计数据管道，第二周比较模型权重，第三周重新审视工单，直到有人发现欺诈者只是改变了他们的语言模式。修复工作——用最近的样本重新训练——只花了两天。而误诊却花了三周。

这种模式在生产环境中的 AI 团队里不断重复：性能下降触发了笼统的“模型问题”警报，团队开始基于直觉而不是根本原因来调整参数。原因并不是缺乏监控纪律，而是大多数可观测性技术栈将三个结构上截然不同的问题混为一谈。模型漂移（Model drift）、数据漂移（Data drift）和提示词漂移（Prompt drift）具有不同的检测特征、不同的警报拓扑结构和不同的修复路径。将它们混淆，就会在错误的修复方案上浪费数周时间。

上季度，某推荐引擎推送了冒犯性内容，随后召开的事故复盘会议以一种我们再熟悉不过的方式收场：两小时的会议里，ML 工程师把矛头指向检索语料库，数据工程师把矛头指向提示词，产品工程师把矛头指向监控，基础设施团队把矛头指向没人记得何时升级的模型版本。最终产出了三条行动项，却没有一条落实到具体负责人。事故就此关闭。六周后，同样的故障模式再次上线。

这不是某一个团队的故事，而是大多数组织处理 AI 事故时的默认结局。AI 功能在生产环境中造成的后果，由足够多的参与方共同承担，导致标准的事故复盘根本无法锁定因果关系。那套在排查数据库超时时行之有效的"5 Why"分析法，面对"模型给出了错误答案"时便彻底失灵——因为下一步该追问什么，从来都不显而易见。

麦当劳得来速 AI 的失败，并非因为用户抱怨。它失败，是因为用户停止使用得来速。三年来，这套系统一直记录着"健康"的接受率，而病毒式传播的视频却显示顾客在苦苦哀求它从订单中删除 260 块鸡块。当合作关系终止时，官方给出的理由是技术"尚未成熟"。真正的信号其实一直隐藏在客流量数据里——无人阅读，无人量化，无人汇报。

这就是大多数 AI 功能在生产环境中失败的样子。用户不会关闭你的功能。他们不会提交工单。他们不会留下一星评价。他们悄悄地绕开它，而你的仪表板依然一片绿色。

你的团队刚刚花了三周时间优化推理。你们换成了量化模型，调整了批处理策略，成功缩短了 12% 的首字延迟 (TTFT)，然后上线了。接着你查看了实际的面向用户的延迟，发现几乎没有变化。

这就是“推理陷阱”。它是 LLM 应用中最常见的性能分析失效模式，其发生的原因是工程师们习惯于测量那些容易测量的指标——GPU 利用率、推理吞吐量、每秒 Token 数 (TPS)——而不是真正缓慢的部分。在一个典型的 RAG 流水线中，如果包含所有涉及 GPU 的环节，推理大约占延迟的 80%。但剩下的 20% 通常分布在六七个没人追踪的阶段中。孤立地看，每一项似乎都很小，但它们共同占据了主要的优化空间。

你的 RAG 系统存在一个不会抛出异常的 Bug。它不会拉高错误率，不会在延迟仪表盘上留下痕迹。相反，它会悄悄地给出听起来自信、合理却错误的答案——而没有人在数周内察觉。

这就是 RAG 中的数据契约问题：你的摄取管道是下游所有环节的事实来源，但它没有 Schema 校验、没有新鲜度保障，也没有在外部世界的形态悄然改变时发出告警。每当上游数据源新增字段、分块参数发生偏移，或者嵌入模型被更新，检索质量就会无声地退化。

80% 的企业级 RAG 项目在生产环境中会遭遇严重故障，而其中最隐蔽的那些故障从不宣告自身的存在。

你的仪表板显示全绿。延迟处于正常水平。错误率为 0.2%。本月正常运行时间为 99.97%。然而，你的 AI 助手正自信地向用户提供错误的信息，格式不对，长度是预期的两倍——而且这种情况已经持续了 11 天。

这就是 SLA 幻觉：基础设施合同保障的是管道，而不是其中流过的水。对于 AI 驱动的功能，“它是否有响应？”与“它的响应是否准确？”之间的差距，正是产品质量悄然崩塌的地方。

2025 年，自动化互联网流量同比增长了 23.5%，是人类流量增速的八倍。其中，agent 驱动的交互增长了 7851%。如果你的产品处理了相当体量的 API 流量，那你的最重度"用户"很可能根本不是人类。而令人不安的事实是：你的产品分析系统对此几乎一无所知。

这不是一个机器人检测问题，而是一个埋点架构问题。当 AI agent 预订差旅、提交费用报告、查询数据库或调用你的支付 API 时，它留下的行为特征与人类完全不同——而你的会话漏斗、NPS 问卷和队列留存图，正在悄悄对你撒谎。

一个客服 Agent 在 12% 的工单中生成了幻觉式的故障排查步骤。HTTP 日志全部显示 200 OK。延迟正常。错误率平稳。从每一项传统指标来看，系统都是健康的——但它却在大规模地悄悄捏造答案。

当工程师最终对决策层进行插桩后，根本原因在几分钟内便浮出水面：检索到的文档块相似度得分全部低于 0.4，对上下文的置信度为 0.28，而模型输出的置信度却显示为 0.91。这是一个巨大的不匹配——在传统日志中完全不可见，但在捕获了决策状态的追踪中一目了然。

这就是将传统日志应用于 LLM 系统时的根本问题。I/O 日志告诉你系统运行了。AI 原生日志告诉你它是否推理正确。

当你的AI功能上线时，你会制定延迟预算：模型调用需要多长时间、检索需要多长时间、完整请求的p99是多少。但你几乎可以肯定没有为那些在没有用户观察时发生的推理制定预算。

每个拥有持久化状态的AI产品都在后台运行不可见的工作。文档在上传时被预处理。长对话在会话边界处被重新摘要，以防下一个会话撑爆上下文窗口。主动建议按照没人刻意设定的计划表被生成。当有人更新模式时，嵌入向量被重新生成。这些都不会出现在你的延迟仪表盘上，通常也不在你的成本模型中，几乎从未被监控到。

这就是你AI产品的暗能量——那些解释了你的推理账单"应该是多少"与"实际是多少"之间差距的计算。

一个 AI 系统将某份求职申请标记为低优先级。候选人提出申诉。法务部门向工程团队询问："请展示模型当时看到的确切内容、检索的文档、触发的策略规则以及生成的置信度分数。"工程师打开日志，发现的是：时间戳、HTTP 200、响应体，以及延迟指标。其余的信息已经消失。

这不是日志记录的失败。按照所有传统标准，日志是完整的。问题在于，应用日志从来就不是为记录推理过程而设计的——而 AI 系统不只是在执行代码，它们做出的是依赖上下文的概率性决策，只有给定决策时刻存在的完整输入上下文，才能被理解。

你的 LLM API 调用在 P99 分位下于 500 毫秒内完成。但你的用户却在等待 12 秒。这两个数字都是准确的，谁都没有撒谎——它们只是在测量完全不同的东西。两者之间的差距正是大多数 Agent 系统性能无声流失的地方，而且大多数团队从未对其进行过监控（instrumentation）。

问题是结构性的：P99 LLM 延迟是一个应用于多步执行模型的单次调用指标。一个 ReAct Agent 进行五次连续的工具调用、重试一个幻觉化的函数、组装不断增长的上下文并生成 300 个 token 的推理链，这并不是一次 LLM 调用。这是一个分布式工作流，其中 LLM 只是一个节点，而其他每个节点都有其自身的延迟开销。