233 篇博文 含有标签「observability」

你团队每个周一盯着看的调试语料库并不是生产环境的代表性样本。它具有明显的偏差，而且偏差的方向完全错误。1% 的头部采样在保留一个罕见的灾难性轨迹之前，会先保留一百次中位数请求——大多数团队只有在某种静默循环了数月的失败模式最终导致退款或停机，并试图在追踪存储（trace store）中寻找示例却一无所获时，才会发现这一点。

这并不是什么罕见的边缘情况。这是所有专为无状态 Web 服务设计、随后又被用于长时程（long-horizon）Agent 的可观测性栈的默认行为。同样的采样算法在处理 HTTP 请求追踪时表现良好，但在处理 Agent 时却会系统性地抹除那些最重要的轨迹——因为在这里，每个“请求”都是一个包含三十个步骤的计划，可能会调用数十个工具，重新生成三个子计划，并在第 27 步发生细微错误之前消耗数万个 token。

解决方法不是“增加采样”。增加采样只会让账单爆炸，而不会改变偏差——你只会得到更多已经过剩的普通数据。解决方法是改变你采样的对象，以只有在轨迹结束后才能获知的预测结果为基准。这需要抛弃基于头部的默认设置，并围绕尾部信号、异常权重以及能在 Agent 执行的长尾效应中存续的有界蓄水池（bounded reservoirs）重新构建保留层。

你技术栈中最灵敏的泄露信号并不在 SIEM 中。它隐藏在财务人员月初打开的一份电子表格里。当攻击者窃取了 LLM API 密钥、利用提示词注入（prompt injection）窃取数据，或者通过被入侵的租户会话查询相邻客户的内存时，痕迹首先会表现为 Token 使用异常——这远在任何 DLP 规则触发、任何身份验证警报响起或任何终端代理察觉到异常之前。财务看到了，而安全部门却没看到。

这种差距并非理论上的。Sysdig 的威胁研究团队在观察到攻击者利用窃取的云凭据产生每日五位数的账单后，创造了“LLMjacking”一词。这一类别现已演变成一个有组织的犯罪产业，出现了每个账号 30 美元的交易市场，且有记录显示某些活动让受害者的损失每天超过 100,000 美元。OWASP 记录了一家初创公司因为密钥泄露，在 48 小时内产生了 200,000 美元的账单。斯坦福大学的一个研究小组由于在 Jupyter notebook 中遗忘了一个 Token，在 12 小时内烧掉了 9,200 美元。所有这些事件的共同点是：在安全团队察觉之前，账单图表就已经在几个小时甚至几天前揭示了真相。

调出过去一周的生产环境追踪记录，查看你的延迟仪表板。你几乎肯定在总请求延迟上设置了 p50 和 p99。你可能还有令牌吞吐量（token throughput）。你甚至可能有一张每秒令牌数（tokens-per-second）图表，因为某个供应商的基准测试说服你这么做了。但你几乎肯定没有的是按模型、按路由、按租户划分的**首字时间（time to first token, TTFT）**直方图 —— 这是决定你产品感知速度的核心指标。

这绝非一个小疏忽。对于任何流式界面 —— 聊天、代码补全、智能体侧边栏、语音 —— 用户感知的速度取决于在内容出现之前，他们盯着闪烁光标的时间。一旦第一个令牌（token）出现，用户就开始进入阅读状态；随后的令牌是在与他们的阅读速度竞争，而不是与他们的耐心竞争。总延迟（Total latency）对于吞吐量规划和成本预算很重要，而 TTFT 则决定了产品是否让人感觉“有生命力”。

这两个数字之间的差距正在拉大。推理模型（Reasoning models）产生的总延迟可能与其非推理兄弟模型完全相同，但却会将 TTFT 从 400 毫秒推高到 30 秒。一个“保持延迟持平”的路由更改，可能会悄无声息地将一个反应灵敏的助手变成一个卡死的窗口。如果你没有对 TTFT 进行图表化，你就是在发布连你自己都察觉不到的 UX 退化。

麦肯锡 2025 年的调查发现，75% 的业务负责人正以某种形式使用生成式 AI —— 但近一半的人已经遭遇过严重的负面后果。这种差距并非模型质量问题，而是信任问题。而缩小这一差距的最快路径不是更多的评估（evals）、更好的提示词（prompts）或新的前沿模型，而是向用户准确展示智能体（agent）做了什么。

大多数工程团队将审计追踪视为事后才考虑的事情 —— 就像你为了 GDPR 合规或 SOC 2 认证而临时接入的东西，然后将其锁在只有运维人员（ops）查看的内部仪表盘中。这是错误的做法。当用户能看到智能体调用了哪个工具、检索了哪些数据，以及哪条推理分支生成了答案时，会发生三件事：采用率上升，支持工单减少，并且模型错误能比任何后端警报提早数天显现。

你的 AI 功能上线一切顺利。演示令人印象深刻，发布指标看起来很好，模型在测试集上的基准准确率达到了 88%。大约三个月后，一位客户成功经理转发了一张截图。AI 推荐结果毫无道理。你查看日志，进行快速评估，发现准确率已经漂移到 71%。没有任何警报触发，没有抛出任何错误。整个过程中基础设施监控面板一直显示绿色。

这种情况并非偶发。对 32 个生产数据集的研究发现，91% 的机器学习模型会随时间降级，而且大多数降级是悄无声息的。系统继续运行，代码没有变化，但随着现实世界不断演进而模型原地踏步，预测结果越来越差。

你的监控看板显示延迟升高，错误率小幅上升，然后归于平静。用户已经在 Slack 里投诉了。你的 AI 功能有四分之一的响应在产生幻觉，而这些幻觉在你的告警系统眼中看起来完全正常。等你找到原因——两小时前上线的一个提示词里改了六个字——一场你的 Runbook 从未预料到的慢燃事故已经结束了。

这就是在生产环境中运营 AI 系统的核心挑战。这些故障模式真实存在、危害显著，却对传统工具完全隐形。一个在悄悄产生幻觉的 LLM，从外部看和一个运行正常的 LLM 毫无区别。

一家航空公司的客服 AI 告诉一位旅客，他可以先购买全价机票，事后再申请丧亲优惠折扣。旅客信以为真，飞行后提交了申请，却遭到公司拒绝。仲裁庭最终判决公司须赔偿 650 美元——因为法律上并无区分人类员工与聊天机器人所给建议的规定。那个聊天机器人并未崩溃，没有任何告警触发，p99 延迟也未见异常。系统在「正常运行」。

这正是 AI 事故的典型特征：应用程序并未报错——它成功地、自信地、大规模地生成了错误输出。 而当你坐下来撰写事后分析报告时，经典的工具箱便彻底失灵了。

大多数AI产品团队上线一个点赞/点踩组件，就称之为满意度度量系统。他们确实在度量某些东西——只是那不是满意度。

一个因为函数签名错误而对Copilot建议点踩的开发者，和一个因为建议虽然优秀但当前不适用而点踩的开发者，产生的是完全相同的信号。与此同时，那个悄悄重新生成了四次最终放弃的开发者，根本没有产生任何显式信号。而那个缺失的信号，比评分组件捕获的任何东西都更能预测用户流失。

用户在使用AI产品时留下的隐式行为记录，比他们自愿输入或点击的任何内容都更丰富、更真实、更可操作。本文介绍该收集哪些信号、为何这些信号优于显式反馈，以及防止AI专项遥测污染通用产品分析的埋点方案。

某用户提交了一个支持工单："你们的 AI 助手告诉我合同续签截止日期是 3 月 15 日，实际上是 2 月 28 日，我们因此错过了截止日期。"你调出日志，响应已生成，模型没有报错，所有指标都是绿色。但你根本不知道它检索了哪份文档、模型读取了什么内容，也不知道那个日期究竟来自上下文还是完全被幻觉出来的。

这就是数据血缘的缺失。这不是监控问题，而是从一开始就埋下的架构问题。

大多数团队发现其 LLM 性能下降通常是在两周后，当时有人在 Slack 上发消息问：“嘿，有人注意到最近 AI 的输出似乎不太对劲吗？”到那时，损害已经造成：用户已经形成了负面印象，支持工单不断累积，而最初推动该功能的业务负责人也正在悄悄失去信心。

令人沮丧的是，你的基础设施在这段时间内一直非常健康。HTTP 200 状态码、180 毫秒的 p50 延迟、每次请求 0.04 美元的成本——仪表盘上的一切都显示为绿色。模型只是变得更安静、更模糊、更简短且更犹豫，而这些表现是基础设施监控无法察觉的。

这不是通过增加 Datadog 仪表盘就能弥补的监控漏洞。它需要一套完全不同类别的指标。

你的检索精度提升了。重排分数改善了。生成器的忠实度指标比上个季度更好。然而用户却在抱怨系统越来越差。

这是生产级 AI 工程中最令人困惑的故障模式之一，而且发生频率远超团队预期。当你构建一个复合 AI 系统——检索结果送入重排器，重排器送入生成器，生成器再送入验证器——你就继承了一个根本性的归因问题。端到端质量是唯一真正重要的指标，却也是最难付诸行动的。你无法修复"系统变差了"。你需要修复某个特定组件。而在一个四阶段流水线中，这件事出乎意料地困难。

当你的团队第一次启用提示缓存时，感觉就像凭空得到了钱。几小时之内，token成本下降了40–60%，延迟也随之缩短。工程师们欢欣鼓舞，然后继续前行。三个月后，有人注意到成本悄悄地爬回去了。从72%起步的缓存命中率现在只剩18%。没有人故意破坏它，没有人注意到。

这是生产LLM部署中最常见的轨迹：缓存只被启用一次，从不被监控，随着代码库的演进而悄然退化。缓存命中率是LLM技术栈中最具影响力的成本杠杆，但大多数团队把它当作一次性的设置任务，而非生产指标。