299 篇博文 含有标签「observability」

你的 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）中运行，或者被排队并在一个小时后消费，各层级就开始产生分歧——模型产生了一个在提示词内部逻辑自洽但在外部环境中错误的答案。

一个团队从前沿模型升级到了其更快的后继版本。评估套件（eval suite）全绿。最终答案一致。工具调用的 Schema 完全相同。结构化输出通过了与以往一样的 JSON Schema 验证。他们发布了。不到一天，支持票据就堆积如山：“助手感觉太匆忙了”，“它不再真正思考了”，“感觉不对劲”。产品经理调取了遥测数据，发现任务完成率没有变化。工程团队反复检查了评估和 Schema，没发现任何问题。投诉是真实的，但团队定义的契约——就如团队所定义的那样——依然完好无损。

改变的是流的纹理（texture）。旧模型在调用工具前会停顿 800 毫秒，发出一句“让我查一下……”的前导词，并以每秒约 35 个 Token 的速度输出，在子句边界处有自然的节奏。新模型以每秒 90 个 Token 的速度输出，从不停顿，且完全跳过了前导词。这些都没有出现在任何文档记录的契约中。但所有这些都是不可或缺的“承重”部分。

这就是海勒姆定律（Hyrum's Law），而流式传输（streaming）让它的表面积变得巨大。系统的任何可观察行为都会被某人所依赖——而流式 AI 界面暴露的可观察行为远比团队意识到的要多。

质量在一夜之间下降了。值班工程师打开仪表盘，追踪了几个异常会话，并开始进行显而易见的二分定位：模型提供商在 UTC 时间 02:00 切换到了新的快照，于是将模型回退到固定的旧别名。评估套件仍然显示红色。回滚昨天的提示词更改。仍然是红色。将检索索引固定回上周的版本。仍然是红色。每个负责团队都在孤立地回滚自己的维度，并报告“不是我们的问题”。三个小时过去了，没有人负责诊断，因为没有人负责回归真正存在的交互面（interaction surface）——新模型以一种旧模型绝不会采取的方式，解释了新的工具描述。

这就是单轴工具无法解决的失败模式。git bisect 之所以有效，是因为搜索空间是一维的：提交记录的线性序列。而 Agent 没有单一的时间线。它有四到五个并行运行的时间线——模型快照、系统提示词、工具目录、检索索引、采样配置——每个都有自己的负责人、自己的部署节奏，以及自己的“回滚”按钮，只能将其自身的轴恢复到已知状态。你正在追踪的回归通常是一个双因素交互作用，沿着任何单一轴进行二分都会返回假阴性结果，因为该 bug 仅在“新模型遇上新工具描述”的交叉乘积单元格中触发。

你的契约测试通过了。Schema 校验器显示正常。工具返回的数据结构与上个季度完全一致。然而，面向用户的回答已经悄无声息地错了六个星期。

这就是契约测试从未设计用来捕捉的故障模式。契约测试验证的是传输格式没有改变——比如 search() 是否仍然返回 { results: [{ id, title, score }] }，create_event 是否仍然接受 ISO 8601 字符串，地理编码器是否仍然输出 { lat, lng }。它们无法捕捉到的是：搜索端点开始按新近度而非相关性排序的时刻；日历 API 在欧盟地区静默地将你 14:07 的开始时间吸附到 14:00；地理编码器在同一个模糊的多边形内选择了一个不同的点；或者作为工具的 LLM 分类器在稳定的端点后升级到了新模型，导致你的评估集从未采样过的某个类别中误报率上升了四个百分点。Schema 没变，但行为变了。你的智能体继续读取着代表通过的绿色勾选，并产生了没有任何错误日志捕捉到的退化答案。

我上个季度合作过的一个团队发布了一个包含七个步骤的智能体（agent），并以显而易见的方式构建了其延迟预算：搜索返回耗时 200ms，SQL 查询耗时 80ms，电子邮件发送耗时 150ms，链条中的其他环节以此类推。将中位数相加，再加入一些缓冲，数学计算表明该智能体能轻松地保持在两秒的 SLA 之内。仪表板连续几周证实了这一点。中值延迟（median latency）表现优异。接着，客户开始抱怨该功能慢得无法使用，而仪表板看起来依然是代表正常的绿色。

他们互相转述的故事是错误的，因为他们是围绕 sum(p50) 构建的架构，而用户体验到的却是 sum(p99)。经过三到四个步骤后，链条中的 任何 环节掉入其自身尾部概率（tail probability）的可能性就不再微不足道了。经过七个步骤后，这种概率接近于掷硬币。没有任何单项工具的仪表板变红，因为没有任何单项服务表现异常 —— 问题在于没有人负责这种乘法复合（multiplicative composition）效应。

这并不是什么新教训。分布式系统研究人员已经为此撰写了四十年的文章。新鲜的是，每个构建智能体的团队都在最后期限的压力下，痛苦地重新发现这一点。

智能体自信地告诉用户：“我已经发送了确认邮件，并将退款退回到你的账户。”追踪记录很干净：两次工具调用，均返回 {"success": true}，模型生成了精练的摘要，对话在 3.2 秒内结束。一周后，客户发起投诉，因为邮件从未送达，退款也从未入账。审计日志中全是绿色的勾选标记。没有任何环节失败——除了实际的工作本身。

这就是在大多数智能体技术栈中尚未被命名的故障模式：撒谎的工具。这里的“撒谎”并非恶意——它们返回了其契约规定的响应。这种谎言是结构性的。HTTP 层返回 “200 OK” 是因为请求被接受了，而不是因为操作完成了。邮件服务商返回 success: true 是因为消息进入了发送队列，而不是因为它已经发出了。数据库写入返回且无报错，是因为它写入了一个从未同步的副本。被训练成“乐于助人”且在“绿色代表完成”的示例上训练过的模型，将这些信号编织成一份自信的摘要，然后继续下一步。

用户点击发送。智能体被配置了 30 秒的时间配额。规划器（planner）检查任务，发现一条耗时约 12 秒的“深度研究”路径和一条耗时 3 秒的“快速查询”路径，并自信地选择了深度路径，因为“我们有充足的时间”。28 秒后，响应返回，比团队上季度发布的 SLA 晚了 2 秒。仪表盘显示，智能体的推理是正确的，重试逻辑是正确的，工具调用也成功了。没有人能解释为什么用户的加载动画转了 46 秒。

这个 bug 不在任何单一组件中。它存在于组件之间的缝隙中，存在于一个系统从未想过要刷新的值里：智能体对于还剩多少时间的认知。在请求受理与模型的下一个规划步骤之间，发生了一次透明重试，挂钟时间在流逝，但截止时间的元数据却没有更新。模型现在正根据它在 15 秒前就已经花掉的预算进行推理，而它自己对此一无所知。