108 篇博文 含有标签「llm-ops」

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

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

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

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

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

一个在你的评估集（eval set）上得分 92%，但在真实生产流量中得分 60% 的提示词（prompt），并不是一个有 bug 的提示词。它是一个评估集在结构上无法发现 bug 的提示词。这种差距并非噪声，而是针对那些与提示词设计意图共享语域（register）、长度分布、语言和礼貌程度的示例进行优化的结果——而这些示例正是由编写评估案例的同一个意图所创作的。

真实用户不会配合你的设计意图。他们会发送三个词的片段、十二个段落的文章、作为问题粘贴的代码块、省略冠词的非正式语域、添加敬语的正式语域，以及你的 few-shot 示例从未涉及的语言查询。这些都不是攻击性的，这只是输入分布（input distribution）。如果你的评估集是由编写提示词的同一个人策划的，那么它几乎肯定与这种分布毫无相似之处。

缩小这一差距的学科不是“更多评估”，而是一种不同类型的评估——一个压力矩阵（stress matrix），它刻意改变你策划的集合中保持不变的维度，并对退化曲线（degradation curves）进行评分，而不是单一的准确率数字。称之为提示词卧推（prompt bench press）：你不是在测试提示词能否完成工作，而是在测试随着输入变得更难，它是如何失败的。

一个工具调用返回了 142 KB 的 JSON 数据块。你的智能体框架丢弃了 8,192 字节之后的所有内容，将前缀交给模型，而模型根据一个它从未意识到是不完整片段的内容写出了一个自信的答案。三周后，一名客户升级了投诉。你翻看追踪记录（trace），看到“工具返回成功”，随后的复盘变成了寻找哪一步“忽略”了证据——然而没有哪一步忽略了它。证据在到达推理引擎之前就被裁剪掉了。

这并非假设。Codex 将工具输出截断硬编码为 10 KiB 或 256 行。Claude Code 的工具结果默认为 25,000 个 token，并且带有一个单独的显示层限制，曾在 2025 年短暂地将 MCP 响应裁剪到 700 个字符左右。OpenAI 的工具输出提交上限为 512 KB。每个框架都选择了一个看起来安全的数字，对于短工具调用确实如此。当单步输出越界时，故障模式就出现了——悄无声息地，没有异常，也没有模型可见的标记。

一名 PM 用英文写了一份功能规范 (feature spec)。一名工程师将其翻译成带有惯用 LLM 模式的系统提示词 (system prompt) —— 思维链 (CoT) 脚手架、输出格式强制，以及一些涵盖规范中从未提到的失败模式的避险条款。一位评估 (eval) 作者打开同一份规范，冷读一遍，并根据自己的理解编写 JSON 测试用例。三周后，这三个产物各不相同，没人能说清楚一个回归到底是提示词的 bug、规范与实现的差异，还是从第一天就写错的评估。

这就是规范翻译税 (specification translation tax)。传统软件也有这种问题 —— PRD 与代码之间、代码与测试之间的差距 —— 但编译器和类型系统缩小了这种差距。AI 功能没有这种兜底保障。提示词是系统实际阅读的文档。评估是没人签署的合同。规范是没人执行的意图描述。每一项都是将同一意图翻译成不同的媒介，如果没有双向的一致性，行为就会通过那个最容易编辑的产物泄露进来。

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

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

一个回归错误流入了生产环境。团队选取了导致失败的输入，针对上周的提示词进行回放，却得到了不同的输出。现在他们必须查明原因——而答案埋藏在 3 MB 大小的文本差异、分歧的工具调用序列以及被打乱的检索块中，人类根本无法有效地进行比对（diff）。于是，他们将两份记录粘贴到左右分栏的查看器中，滚动查看了二十分钟，得出结论“模型今天感觉不太一样”，然后发布了一个并没有解决根本原因的热修复，因为他们从未找到真正的原因。

这就是 Agent 状态差异问题，也是通用工程工具在处理 Agent 系统时失效的首要环节。传统的回归二分查找（bisect）针对的是确定性代码：相同的输入产生相同的输出，git bisect 遍历历史记录，直到你找到破坏代码的提交。但 Agent 的运行不是确定性的，输入也不仅仅是一个字符串，其“历史”是一个多轴的包（envelope）——模型快照、采样配置、检索到的上下文、工具目录、框架标志——其中任何一个变量都可以独立地改变行为。

在上个季度的某个时候，你团队的一名工程师在 Slack 上发了一个帖子，开头是“模型变慢了”。他们展示了一张图表：你的助手功能的 p95 延迟从早上 7 点开始稳步攀升，在东部时间上午 10 点左右达到顶峰，午餐期间处于平台期，并在下午 5 点后悄然恢复。这种形态在第二天、第三天不断重复。团队追溯了他们的部署记录，指责了分词器（tokenizer）的更改，接着是上下文长度的退化，最后发现没什么是特别确定的。修复方案从未落地，因为 Bug 根本不在你的代码里。

顶尖模型提供商运行着共享的推理集群。当你的用户醒来时，北美其他地区也醒了，再加上欧洲的下午，以及每一家购买了相同 API 的公司的每一个内部工具。提供商端的队列深度翻倍，GPU 竞争加剧，你的 p95 延迟也随之翻倍——而你的代码库没发生一行代码变更。这是你技术栈中最可预测的生产事故，但几乎没有团队会为此建立仪表板。

你在九个月前编写的回退路径（fallback path）——那个用于捕获模型超时、切换到更便宜的供应商、并在两者都宕机时返回模板化消息的路径——实际上在过去的十二周里从未在生产环境中运行过。它仅在最初发布时被执行过一次，集成测试仍然能通过，操作指南（runbook）也仍在使用它。但这并不意味着它还能工作。第六周的一次重构改变了上游上下文对象的形状。第九周的一次依赖库升级悄悄移动了一个配置键。代码仍然可以编译。测试仍然能通过，因为它们是针对与代码相同的陈旧 Fixture 编写的。下次当你的主路径出现 504 错误时，你的“优雅降级”将会把一个 NullPointerException 甩在用户脸上，而复盘报告将会指出——这已经是今年第三次了——在上游契约变更后，回退路径从未被重新测试过。

这是 AI 系统韧性工程中一种隐性的失败模式。回退路径是你应用程序中专门为了被忽视而存在的部分。在一百天里，有九十九天生产流量都会绕过它。CI 从不执行它，因为没有任何测试与之关联。负责它的团队在两次事故之间会忘记它的存在。然后在第一百天，当主模型供应商出现区域性故障，你终于需要它时，这段代码却在付费客户面前发生了代码腐烂（bit-rots）。

周二还能用的提示词（prompt），到周四就返回了“我无法提供帮助”。CI 评估依然是绿色的。你配置中的模型名称没变。提示词在字节层面完全一致，在源码控制中也经过了哈希处理和固定。然而，一个围绕新出现的拒绝回答（refusal）的客户支持线程正在形成——AI 团队在两周内都不会察觉到这一点，因为它必须经过一级支持、分类，最后才落到能读取追踪信息（trace）的人手中。

这就是服务商侧的安全漂移（provider-side safety drift），它是当今生产环境 AI 中构建最不完善的监控缺口。前沿服务商会以不在你发布日程上的频率，在服务端调整安全过滤器、拒绝阈值和内容分类器。你的团队没有订阅这些变更，通常也没有发布说明。而且这种退化是具有非对称性的，以一种确实难以察觉的方式呈现：正当意图的拒绝率悄悄爬升，而你认为服务商会过滤的有害查询却开始悄悄溜过。边界在两端独立移动，且毫无预警。

用户报告 Agent 给出了错误答案。你打开 Trace。模型的推理过程看起来没问题。工具调用全部返回 200 OK。Harness 日志显示没有重试、没有截断、没有异常。然而，答案就是错的。于是你花了接下来的两个小时，将三个具有不同格式、不同时钟的独立日志流缝合在一起，最终发现某个工具针对特定的查询形状静默返回了 {"result": null}，模型将这个 null 合理化为一个听起来合乎逻辑的事实，而 Harness 则愉快地将这个幻觉转发给了用户。这三个层级中的任何一个都没有单独记录任何警报。故障发生在连接处。

这是生产级 Agent 系统中最主要的故障模式，而大多数团队都在使用单层工具进行调试。模型团队归咎于工具。工具团队归咎于模型。平台团队归咎于 Harness。每个人都部分正确，因为 Agent 故障几乎从来不是单一组件的 Bug —— 它是三个组件之间的失配，而每个组件都在不同的“步骤”心理模型上运行。在你的 Trace 基础设施反映这一现实之前，你将不断为披着不同外衣的同类事故买单。

三个团队正在查看同一个事件流，每个团队都有一个名为 session_id 的列，但每个团队对什么是“会话”都有不同的定义。计费（Billing）继承了来自认证库的 30 分钟空闲窗口。评估（Eval）从聊天机器人框架中继承了“直到用户说‘再见’或停止打字 10 分钟为止”的定义。记忆（Memory）则使用 UI 在用户点击“开启新聊天”时生成的线程 ID —— 而大多数用户从不点击这个按钮。三列数据，三种语义，一个汇总仪表盘，以及三个共用一个根因但互不相关的 Bug。

这就是会话边界问题（session boundary problem）。它看起来像是一个埋点琐事，但实际上是一个披着基础设施外衣的产品问题：一段对话在哪里结束？坦诚的回答是没有单一的标准答案 —— 计费会话、评估会话和记忆会话并不是同一种对象 —— 如果一个团队选择了一个默认定义并让另外两个团队继承它，那么他们交付的就是具有相同根因的计费纠纷、评估偏见和内存泄漏。