233 篇博文 含有标签「observability」

你的 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 崩溃。团队的单工具可靠性指标永远看不到这一点，因为按各自的标准来看，每个工具都运行良好。

你的 LLM 供应商声称 99.95% 的可用性。你的状态页显示绿色。你的延迟仪表盘在 SLO 范围内。但你的产品依然坏了 —— 助手在今天早晨开始拒绝常规请求，支撑下游解析器的 JSON 输出从紧凑变得啰嗦，而且你用模型分拣的支持工单中有三分之一返回了 “我无法提供帮助”。所有这些响应都在 800ms 内返回了 200 OK。它们都没有违反 SLA。这个 SLA 覆盖的是你实际上并没有遇到的故障模式。

这是采购谈判中没人预估到的差距。供应商出售的是 可用性（availability） —— 一种请求层面的承诺，即 API 及时响应了；而产品团队消费的是 能力（capability） —— 一种请求层面的承诺，即答案是可用的。这两者不是同一个指标，而混淆它们的团队离发现其中的区别只差一次静默的模型升级。

每个智能体（agent）功能都有一个“后门”。有的团队称之为“转人工支持”，有的称之为“路由至人工审核员”，还有的则使用模板化的回复：“我无法处理此事——让我为你联系能提供帮助的人。”无论标签是什么，每个生产环境中的智能体都有一条放弃用户请求并将其移交给人工的路径。而生产流量采取该路径的比例，是少数几个不依赖标注员、评审员或手动构建测试集的信号之一。这是系统在生产环境中告诉你，模型无法处理用户实际发送的请求。

这个信号几乎总是被错误的团队读取。在大多数公司中，转人工率（Escalation rate）是一个劳动力规划指标：它决定了下一季度排队系统需要多少人工客服。它存在于运营团队审查的仪表板上，其审查频率与 AI 团队读取评估分数（eval scores）的频率完全不同。30% 的周环比转人工增长在周一的运营审查中表现为一个人员配备问题，而 AI 团队的评估套件依然显示绿色，领导层的报告也显示功能状态良好。两个团队看着同一个生产系统，却得出了截然相反的结论：运营团队认为他们需要更多人手，而 AI 团队认为模型运行良好。

一年前，你的评估套件（eval suite）表现得非常出色。候选模型的得分分布在 60 到 80 分之间，排名结果能为你提供有效的参考。新的微调模型比基准模型高出 6 分；更廉价的模型则低了 3 分。决策依据这些数字而产生。而今天，在同样的评估套件下，每个候选模型的得分都是 95、96 或 97 分，得分差距已经缩小成了噪音。你的团队仍在运行评估，仍在阅读报告，仍在利用它为迁移亮绿灯——但这份报告已经不再包含任何有效信息。

这不是基准测试污染（benchmark contamination），也不是世界漂移引起的衰减（world-drift decay）。这是一个测量工具的问题：你的测试用例是针对平台已经超越的难度水平而校准的。尺子没有坏；而是你正在测量的东西已经超出了它的量程。那些没有意识到这一点的团队，仍然在使用一个辨别范围与所比较的候选模型不再重叠的工具来进行模型决策。

在生产级 LLM 评估中存在一种悄无声息的失败模式，这是任何排行榜都无法捕捉到的：你的测试集是基于留存用户构建的，因此它永远不会提出那些让其他用户离开的问题。季度复季度，评估分数攀升，仪表板一片绿，但净留存率（net retention）依然在下滑。团队在追问“评估是否可被操纵？”，而真正的故事更简单也更残酷：评估分布向幸存者偏移了，而幸存者恰恰是你最不需要其反馈的人群。

这是换了装束的二战轰炸机装甲问题。Abraham Wald 观察了返回的飞机，注意到弹孔聚集在哪里，并指出你应该加固的地方是那些没回来的飞机上的弹孔。把轰炸机换成用户，把弹孔换成失败的交互轮次，你就得到了从生产追踪（production traces）中提取评估集的中心病理。

仪表盘显示 0.5% 的请求触发了回退（fallback）。仪表盘这么显示已经持续六个月了。直到有人从头重新运行遥测数据（telemetry），发现次级模型正承载着 38% 的流量，而预设回复（canned-response）层级则处理了另外 9% 的流量。团队在路线图评审中一直讨论的尖端模型“主路径”，实际上已沦为少数派体验。没有人注意到这一点，因为没有任何警报被触发 —— 每次降级都是一个小规模的、理由充分的、局部正确的决定，而累积的偏差从未超过任何人事先设定的阈值。

这就是我想要定义的失效模式：成了默认项的回退机制。这不是故障，也不是单个组件的回归。它是产品表面的缓慢轮转，退而求其次的路径不再是安全网，而成了核心体验。团队的心理模型与生产现实渐行渐远，而这种差距是隐形的，因为现有的度量指标（meters）旨在检测失败，而非检测组合（mix）。

我要提出一个更强有力的观点：如果你的 AI 功能拥有两个以上的服务层级，那么你的层级组合（tier mix）本身就是一个 SLO。如果你没有测量它，你其实并不知道你发布了什么。

一名客服代理告诉用户“根据我们截至今天的最新定价”，并引用了上季度的价格表。系统提示词正确地注入了 today is {current_date}。检索层提取了具有最高时效性评分（freshness score）的文档。模型回答得信心十足。每个组件都严格执行了其规定的任务，但用户得到了一个错误的答案，而值班工程师却无法复现这个问题，因为当他们在晚上 9 点回溯追踪记录（trace）时，“今天”已经变成了不同的一天。

这并不是一个罕见的 Bug。这是一种几乎存在于每一个生产级 LLM 流水线中的失效模式，因为“现在”隐式地存在于提示词的五个不同层级中，而这些层级是由不同的人在不同时间、针对不同的“现在”定义编写的。只要请求是从前端用户会话同步运行的，这些层级通常能达成一致。一旦请求被重放用于调试、在夜间进行批处理、在固定于 3 月的评估框架（eval harness）中运行，或者被排队并在一个小时后消费，各层级就开始产生分歧——模型产生了一个在提示词内部逻辑自洽但在外部环境中错误的答案。