299 篇博文 含有标签「observability」

太平洋时间凌晨 2 点，你的评估套件（eval suite）在平静的提供商环境下全绿通过。上线前一晚 11 点，QA 进行了冒烟测试。功能正式发布。到了周二上午 10 点（东部时间），你的 p95 延迟比你签字认可的仪表盘高出了 40%，你的智能体（agent）在一个包含六步的计划中丢掉了最后一个工具调用，而你的支持信箱塞满了听起来如出一辙的工单：“今天早上 AI 表现很奇怪。” 谁都没错。模型也没错。错的是评估集 —— 它从未见过饱和的提供商环境，因此对于当队列深度翻倍、截止时间预算（deadline budget）崩溃时功能会如何表现，它无法给出任何参考建议。

提供商负载不仅仅是一个伴随质量副作用的延迟问题。它是你的模型和智能体循环接收到的输入的一种分布偏移（distribution shift），而你所信任的每一个质量信号，都是建立在这个分布中错误的那一截之上的。解决办法不是换一个更快的区域或更好的模型。解决办法是停止假装你的评估框架是在与你用户相同的世界中进行采样。

每个将智能体（agent）投入生产环境的团队，最终都会遇到类似的事故。智能体进入了一个无法退出的状态。它在六个小时内反复调用同一个工具，只是参数在表面上略有不同。它在两个前提条件互斥的计划之间摇摆不定。它每隔两百毫秒重试一次瞬时的 429 错误，一直持续到天亮。它生成了一个包含百万 token 的计划，却从未执行。等到有人察觉时，token 账单已达四位数，下游 API 被限流，客户会话已超时十二次，而值班工程师正被针对同一根因的三个不同告警狂轰滥炸。

每个团队首先想到的解决方法都是步骤计数预算（step-count budget）。将智能体限制在 20 次迭代。限制在 50 次。定个数字，然后上线。步骤预算确实让事故报告消失了，但它并没有消除底层问题 —— 一旦你理解了其中的机制，你就会发现步骤预算相当于智能体世界里的家用保险丝：它是在损害造成之后才熔断的，保险丝盒本身现在成了维护负担，而下次发生故障时，你的本能反应是换一个更大规格的保险丝，而不是去追究到底哪里短路了。

一个团队负责摘要生成器。另一个团队负责摄取这些摘要的搜索排序器。第三个团队负责一个路由，根据排序器的置信度分数在不同的智能体人格之间进行选择。这些团队都没有共同的值班轮换，也没有人参加同一个站会，他们之间唯一的契约就是“上一个功能的输出是下一个功能的输入”。周二，摘要团队收紧了一个提示词，以修复销售演示中反馈的幻觉问题。六小时后，搜索排序器的质量骤降。到周三早上，路由开始将任务交给错误的智能体人格。复盘报告会将原因记录为“提示词变更”，但实际原因是团队的 AI 功能已经悄然组成了一个没人绘制过的有向图。

这是最常见的 AI 故障形式，它不会触发你为 AI 故障构建的任何警报。模型没有宕机。被修改功能的评估套件显示为绿色。Token 成本曲线很平稳。真正断裂的是两个功能之间的接口，你的依赖工具将其视为纯文本，因为在 API 边界它确实只是纯文本——并且将其视为惰性的，因为纯文本不携带版本、Schema 或弃用策略。

上个季度评分 92% 的评估集（eval set）现在评分达到了 94%，团队称之为进步。事实并非如此。该评估集中的标签是根据标注员脑海中早已模糊的准则（rubric）编写的。模型评分所针对的产品已经发生了变化。标准已经发生了变化。标注员自身的校准（calibration）也发生了变化。表面上 2% 的提升，实则是静态产物与动态产品之间无声的差距，且只要团队不更新，这种差距每周都会扩大。

标注漂移（Annotation drift）是成熟 LLM 评估方案中一种隐蔽的失效模式。它不会表现为回归（regression）——回归是简单的情况，因为数值会下降，从而触发人员调查。它表现为一个持续显示绿色的数字，而其原本衡量的内容在底层已经腐烂。已经建立了评估集、编写了准则并招募了标注员的团队面临的风险最大，因为他们信任自己构建的系统，从而停止了对基础的审计。

一个健康的评估集（eval set）本应是成熟的标志。但在任何一个周一，它也可能意味着排队等待的 1,000 个失败案例，而人工审核员只有 8 小时，且每个案例的处理效率大约是 50 个。这笔账很残酷：大约每 20 个失败案例中只有一个会被阅读。剩下的 19 个只能等待。至于哪 19 个在等，哪一个能被选中，完全取决于文件加载的顺序。

大多数团队将其称为“审核失败案例”。但它更像是一场按字母顺序加权的抽奖。一个影响 2% 生产流量且位于文件顶部的失败案例会得到关注。而一个影响 40% 生产流量但位于文件底部的失败案例，即便能被看上一眼，也要等到周五下午。团队在周二发布了针对小问题的修复方案，并在周四写了一份回顾（retro），纳闷为什么仪表盘上的指标毫无变化。

每个人都在看的成本仪表盘是一个周滚动平均值，而那个平均值正在对你说谎。并不是说数字本身是错误的——它是计费事件流的忠实算术平均值——而是它隐藏了底层的成本曲线形态。周五晚上到周一早上之间的 token 消耗方式，与周二上午 10 点到周四下午 4 点之间截然不同。周六凌晨 3 点活跃的群体与周二上午 11 点活跃的群体并非同一拨人，这些群体的单用户经济效益（per-user economics）差异巨大，但没人记录这一点，因为仪表盘通过平均值将其抹平了。

大多数团队第一次发现这一点，是在周末自动化脚本烧光预算的时候。一个 LangChain 智能体在周五晚上陷入了无限对话循环，运行了大半周才被人发现，导致产生了一张五位数的账单，周一早上不得不向财务部门解释。事后回顾将其视为一次性事件——糟糕的重试逻辑、缺失的预算上限、没有触发值班报警。但是，那个隐藏了失控循环的仪表盘，同时也隐藏了同一现象的稳态版本：每周都会出现的非工作时间流量基准，其单位经济效益在结构上比工作时间基准更差，而周平均值让这一切变得不可见。

你的 AI 功能成本是一个分布，而不是一个数字。挂在研发财务作战室墙上的仪表盘显示，上个月支出了 187,000 美元，并按功能、模型和区域进行了细分。然而，这些视图都无法回答 CFO 真正想问的问题：“谁每月付给我们 40 美元，却消耗了我们 4,000 美元的成本？”当你按 customer_id 而不是功能进行排序时，原本平稳的柱状图会变成一条曲棍球棒曲线，而那些针对平均用户进行设计的团队会发现，他们在一个季度里一直在默默地为长尾头部的用户提供补贴。

这种模式是如此一致，以至于完全可以被称为定律。在生产环境的 LLM 工作负载中，前 1% 的用户通常驱动了 30–50% 的 token 支出，而在排名前 0.1% 和 0.01% 的用户中也会出现类似的分布形状。这并非某个产品的特例 —— 当你发布一个边际成本可变且定价统一的功能时，这必然会发生。平均用户的利润率看起来不错，中位数用户的利润率看起来非常好。但重尾部分的积分才是季度预算的真正去向。

当 AI 功能表现异常时，大多数工程师做的第一件事就是再次点击“运行（run）”。这种思路认为，模型是具有随机性的，所以这次运行可能只是运气不好。当第二次尝试产生看起来合理的结果时，工单就被关闭了。团队继续前进。而真正的 Bug——过期的工具响应、检索缺失、仅在包含特定 token 的输入时才触发的系统提示词冲突——仍然完好无损地留在生产环境中，等待下一个用户触发它。

这就是“重跑反模式（rerun antipattern）”，它是 AI 团队从聊天机器人时代继承下来的最昂贵的调试习惯。它看起来很严谨，因为模型确实是非确定性的。它看起来像是一种方差探测。但几乎没有人在重新运行之前写下假设，没有人预先决定多少次运行才算证据，也没有人考虑 token 的成本。正在发生的事情更接近于“老虎机式调试”：你不断拉动杠杆，直到红灯停止闪烁，然后你走开，并确信机器没问题。

控制面板上的对话情况看起来很健康。每次调用的平均 token 数合理，p50 输入长度舒适地处于缓存前缀（cached prefix）之内，供应商的发票按照财务部门批准的速度增长。然后，有人导出了一个包含 200 轮对话的单次编程会话，该用户的单项支出就超过了团队其余成员每日流量的总和。控制面板没有撒谎 —— 它只是在算平均值。账单来自于长尾（long tail），而长尾并不会随着轮次增加而线性增长。

每一个多轮对话的 AI 功能最终都会遇到这种“惊喜”。每次调用的 token 数是一个错误的衡量单位，因为 30 轮对话的成本不是单次调用的 30 倍 —— 而是 50 倍到 200 倍之间，这取决于历史记录的结构方式、提示词缓存（prompt cache）的衰减情况，以及一旦输入超过 200K token 后请求所处的计费层级。根据单次调用数据为功能定价的团队，实际上是在为他们从未建模过的长尾风险承保。

六个月的绿色 CI 掩盖了一个事实：大约 40% 的评估集（eval set）已不再代表用户在产品中的实际行为。测试套件仍在运行，裁判（judge）仍在打分，仪表盘依然闪烁着绿光。但这些案例是针对查询分布、语料库、工具界面和监管文本编写的，而这些内容早已发生了变化——现在的绿色运行意味着“昨天的产品在昨天的现实中依然有效”，而这并不是你付费让 CI 回答的问题。

这就是“快照评估退化”（snapshot eval decay），它是 AI 评估中最缓慢、最昂贵的失败模式。说它缓慢，是因为套件从未失败——陈旧性表现为无法区分模型优劣，而不是构建变红。说它昂贵，是因为当有人意识到评估通过的模型切换导致了生产环境回归时，团队已经建立了一年之久的“评估通过即发布”的肌肉记忆，而这一记忆是建立在一个早已悄然失效的资产之上的。

在每一家发布托管 LLM 功能的公司，通常在第四个月左右都会召开一次财务会议。工程团队一直在记录每次请求的 Token 数量。财务团队手里拿着供应商的账单。两边的数字对不上。有时差距是 5%，有时则是 30%。工程师说是账单错了，财务团队说是日志错了。从技术上讲，双方都是正确的，但谁也不负责对账。

这种偏差并不是欺诈。它是一个结构性的衡量问题，而且这种结构至少包含六种相互叠加的独立失效模式。一个不掌握这些失效模式的团队，接下来的一个季度都会在给 FP&A（财务计划与分析部门）写道歉信，解释为什么预测失准，而真实的情况是，工程侧根本没有人审计过自己日志中的 “Token” 到底是什么意思。

你的可观测性技术栈中的单工具仪表盘讲了一个令人宽慰的谎言。search_listings 的成功率是 96%，显示为绿色。book_appointment 是 95%，也是绿色。而连续调用这两个工具的智能体（agent）三周以来的成功率一直只有 78%，却没人能解释原因。原因不在任何一个工具内部，而是在它们之间的缝隙里——那个没有任何仪表盘面板覆盖的地方。

组合不是加法。当工具 A 的输出流入工具 B 的输入时，故障面并不是 B 对“有效调用”的狭隘定义下的 1 - (0.96 × 0.95)。它是 A 在 B 的标准下所有微妙偏差方式的完整笛卡尔积：A 返回的日期格式是 MM/DD/YYYY，而 B 期望的是 ISO 8601；返回的价格单位是分，而 B 解析的是元；分页游标指向了最后一个结果之后的一项；或者上游服务昨天重命名了一个实体 ID。这些情况都能顺利通过 A 自身的契约测试（contract tests），但每一个都会导致 B 崩溃。团队的单工具可靠性指标永远看不到这一点，因为按各自的标准来看，每个工具都运行良好。