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

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

我在上个季度交流过的一个团队花了六周时间追踪其智能体（agent）平台上的内存压力报警。这些智能体的运行成本很低——每次运行只需几美分。但追踪（trace）却不是。他们的遥测流水线消耗的预算是其所监测的 LLM 调用预算的三倍，而且大部分支出都花在了几个月没人看过的字段上：每个 span 上存储的完整 prompt 正文、在父级和子级追踪中重复出现的工具输出，以及一个在每次捕获的追踪上重新支付推理费用的 LLM-judge 评估器。

这是 AI 可观测性成本危机的缩影。一份 2026 年的行业报告模拟了一个拥有 10,000 个对话且每个对话有五轮互动的客户服务机器人——这相当于每天 200,000 次 LLM 调用、4 亿个 token，以及大约 100 万个追踪 span。Datadog 用户广泛报告，在处理其 REST API 的相同后端上监测 AI 工作负载后，可观测性账单飙升了 40-200%。流水线在为同样的 token 支付两次费用：一次是为了生成它们，一次是为了记住它们。

解决方法不是“减少日志”。解决方法是将 AI 系统的可观测性视为一种具有自身单位经济效益的工作负载，与传统服务发出的请求-响应遥测分开处理。传统日志是你可以压缩并遗忘的结构化字段；AI 日志则是无限制的文本正文，每当有人读取它们时，就会重新计入推理预算。这种区别就是“Token 感知日志”的含义。

你的 AI 评估测试集（eval suite）有 800 个测试用例。你又增加了 200 个。现在你的模型在评估中得分 94%，你满怀信心地发布了。三天后，一名用户发现了一个回归（regression）问题，而你那 1000 个测试用例中没有一个捕获到它。

这不是运气不好 —— 而是结构性问题。回归问题的存在恰恰是因为你扩充测试集的方式，而不是尽管你扩充了测试集才存在。当出现故障时增加更多评估指标（evals）的本能在理论上是正确的，但在实践中却适得其反。更多的测试并不自动意味着对重要事项的覆盖率更高。它们意味着对那些易于测试的事项有了更好的覆盖，而这完全是两回事。

当你的 AI 功能输出错误答案时，第一个问题总是：“是模型的问题吗？”大多数工程师会进行模型评估，运行几个测试提示词，并得出模型看起来没问题的结论。他们通常是对的。模型没问题。故障发生在其他地方——在你的组件相互通信的那些无形接缝处。

这一结论的证据是一致的。对生产环境 RAG 部署的分析显示，73% 的故障是检索故障，而不是生成故障。在多智能体系统中，最常见的故障模式是消息顺序冲突、状态同步间隙和 schema 不匹配——这些都不会出现在任何单组件健康检查中。GPT-4 在处理复杂的提取任务时，产生无效响应的比例接近 12%，这不是因为模型坏了，而是因为模型与下游解析器之间的输出格式契约从未被强制执行。

模型背了锅，边界才是元凶。

你共享驱动器上那份签署了 14 个月的 AI 供应商合同是根据 SaaS 模板起草的。它保证了正常运行时间，指定了安全联系人，并将责任上限设定为 12 个月的费用。但对于你的提示词是否会被喂进下一次训练运行，当你依赖的模型被悄悄换成更小的变体时会发生什么，或者当监管机构询问时你的推理日志存放在哪个地区，它却只字未提。起草它的律师利用他们掌握的词汇量完成了一项称职的工作。但这些词汇量比现在的覆盖范围落后了一个世代。

采购团队仍在为错误的合同进行优化。标准的 MSA（主服务协议）打的是 2010 年代的战争——停机补偿、漏洞通知窗口、进入源代码仓库的知识产权赔偿。AI 供应商关系有着不同的攻击面，而最重要的条款往往在现有模板中连个标题都没有。如果一个团队任由去年的采购指南来处理今年的供应商技术栈，那么他们正在签字放弃一年内就会需要的筹码。

我在上个季度交谈过的一个团队发布了一个微调模型，该模型在内部评估中比基础模型高出 4 分，但在接下来的 6 周内，他们却眼睁睁地看着排名前三的客户流失。评估结果没问题。聚合指标没问题。微调模型只是恰好在中位数用户（即询问简短事实性问题的小型企业买家）身上表现出色，而在企业法律客群中悄悄退化了，而后者那些长篇、包含大量引证的查询才是真正的营收驱动力。没有人按照客户等级对评估进行切片分析，因为建模端的人并不知道客户等级至关重要。

大多数关于微调的讨论都处于两个极端之一。一端是“一个微调统治所有”的方法，它在所有客户数据的混合体上训练单个专业化模型，并冲刷掉了原本在基础模型中区分各细分市场的特定客群行为。另一端是“单客户微调”方法，它为每个租户训练一个单独的适配器（adapter），这在客户数量少于 100 个时在运维上是可以忍受的，但在达到几百个左右时就会崩溃。一个有趣的中间地带——由少数几个客群感知微调模型来服务细分的客群——在大多数生产实践手册中是缺失的。

AI 功能上线后的 Bug 数量并非质量问题。它是一个发现序列——一个非常可预测的序列，以至于你可以在发布公告发布之前，在白板上逐周、逐个工单地勾勒出来，并且在仪表盘数据跟上时，你会发现自己预测得惊人地准确。每个上线 AI 功能的团队都会经历这个序列。唯一的选择是，你是带着操作手册（runbook）去执行，还是通过一系列临时的紧急会议来应对。

我已经观察了足够多的发布，足以相信这个序列实际上与工程质量无关。它关乎信息差。发布前，团队拥有合成流量组合、精选的评测集（eval set）、理想路径的演示和董事会演示文稿。发布后，真实用户带着合成流量从未模拟过的意图蜂拥而至，市场团队开展了工程团队仅略有耳闻的营销活动，模型提供商发布了未经团队授权的更改，而隐私审查员在功能上线时正在休假。下面的序列就是当这两个世界碰撞时产生的摩擦。

我的团队第一次发现我们依赖的模型即将退役时，是从客户那里得知的。弃用通知邮件躺在一个被三名工程师退订了的共享收件箱里。提供商的状态页上挂着横幅。Webhook 事件发射到了虚空中，因为我们从未配置过接收端。60 天的预警时间，被我们浪费成了 0 天，最终以一场停机事故和塞满“紧急迁移”同步会的日程表收场。

我交流过的大多数团队目前都处于这种状态，只是他们自己并不知道。每个主流 LLM 提供商都在悄悄构建通知层面 —— 针对故障的 Webhook、变更日志中的弃用事件、通过电子邮件发送的账户警告、账单异常提醒、区域故障转移信号 —— 而大多数团队要么禁用了这些功能，要么将其路由到了一个没人看的邮件列表。提供商一直在提前告诉你坏消息。是你选择不去听。