67 篇博文 含有标签「llmops」

当你的 AI 账单月额度首次突破七位数时，预算会议的形式就会发生变化。在那之前，问题是“我们能否负担得起”。在那之后，问题变成了“谁能分到多少”——而大多数工程团队会实时发现，他们根本没有应对这一问题的政策框架。那个发布了最响亮演示的团队会意外地获得最高配额。财务部门则在推行扁平的人均上限，这让那些从事最高杠杆工作的团队陷入困境。安全部门则完全被排除在对话之外，直到有人发现评估团队过去六个月一直在通过个人 Token 额度拉取生产流量。

这种对话之所以总是感觉像是在争论云成本，是因为它确实接近云成本，但不完全是。在云端，浪费的单位是一个被遗忘的 EC2 实例，最坏的情况是账单翻三倍。而对于 Token 配额，浪费的单位是一个失控的 Agent 循环，而准入的单位则是面向用户的功能：谁掌握了预算，谁就能发布功能。后一种特性使得 Token 分配更接近基于能力的安全性（Capability-based security），而不是云 FinOps。配额不仅仅是一个支出上限。它是执行一类推理的权利。

大多数团队都在契约的错误一端设置了漂移监控（drift monitoring）。他们盯着模型——当供应商发布新的 checkpoint 时发生的性能偏移、提示词重写后的输出分布变化，或是预示着安全过滤器重新调整的拒绝率激增。仪表板非常详尽，告警已接入 PagerDuty，团队也准备好了针对“模型变了”的运维手册。然而，当模型没变而仪表板依然报红时，这些都无济于事，因为真正发生偏移的是你的用户。

用户侧概念漂移是几乎所有评估流水线（eval pipeline）都会忽略的一种问题。你的提示词、模型和工具与发布当天完全一致。你的黄金测试集（golden test set）依然保持 91% 的通过率。但在第一周达到 91% 的提示词，在第三十周的实际效果可能只有 78%，因为底层的输入分布已经发生了变化——用户了解了产品并改变了提问方式、词汇发生了演变、出现了季节性的任务类型、竞争对手重新定义了品类，或者某个热门帖子教给用户一种表达相同意图的新方式。模型和提示词稳住了，契约也稳住了，但契约所针对的那个世界变了。

打开你团队用来发布提示词（prompt）变更的配置仓库。看看最近的 30 个 commit。其中有多少个经过了代码审查（code review）？有多少个在 CI 中设置了评估门禁（eval gate）？有多少个你能——肯定地——归因为对看到它们的用户的生产环境行为产生了可衡量的变化？如果你的答案是“绝大多数”，那你是个例外。对于其他人来说，这些 commit 此刻正在生产环境中运行，而读取它们的系统所做的事情与特性标志（feature-flag）服务完全一致：热加载一个值，分发给用户，改变产品行为。区别在于，你的特性标志服务拥有审计日志、曝光追踪、熔断开关（kill switches）以及针对特定分群的定向投放。而你的提示词发布流水线只有 git push。

这并非隐喻。这是对你团队正在运行的生产系统的准确描述。提示词配置仓库、你的 worker 轮询的 S3 存储桶、数据库中的 “prompts” 集合、你的应用在启动时获取的 LangSmith/PromptLayer/Braintrust 资产——这些全都是特性标志服务。它们具有相同的运行时形态：一个存在于二进制文件之外的值，二进制文件在热路径（hot path）上读取它，更改该值即可在无需部署的情况下改变真实用户的行为。唯一缺少的，是你的 SRE 团队在批准“真正的”特性标志服务之前所要求的所有控制措施。

这是一个周二早晨的对话，你的 AI 团队中没人为此做好了准备。新模型以影子模式（shadow mode）上线。不到一小时，评估仪表盘亮起：它对 4% 退款申请的分类与你上一季度运行的模型不同。大多数这类决策翻转看起来都是新模型是对的。房间里的一位成员——通常是汇报线中律师最多的那位——提出了一个让庆祝戛然而止的问题：那么，对于旧模型已经交付的 90 天决策，我们要怎么处理？

这就是智能体回填（agent backfill）问题。当一个更智能的模型开始产生比之前模型更正确的输出时，之前模型做出的每一个持久化决策都会变成一个有争议的记录。你本无意指责过去，但新模型在第一次对比追踪（traces）时就自动为你这么做了。现在你面临一个工程问题（我们能重演历史吗？）、一个法律问题（我们必须披露修正后的结果吗？）以及一个产品问题（用户会看到追溯性的变化吗？），这些问题发生了碰撞。

你上线了新模型。综合评估通过率从 91% 提升到了 96%。产品团队在全体员工大会上宣布这是一次重大胜利。六周后，可靠性团队却迎来了有史以来最糟糕的一个季度——并不是因为故障变多了，而是因为现在每一个故障都需要三名工程师花上两天时间才能解决。

这就是智能体能力悬崖 (agent capability cliff)，它是生产环境 AI 中最反直觉的失败模式之一。模型升级并不会均匀地提升所有任务的表现。它们将增益集中在大部分流量上——即那些旧模型原本就能在大部分时间内处理正确的简单和中等案例——而长尾中真正困难的输入却只看到了微乎其微的改进。你的失败面缩小了，但剩下的每一次失败都是能力边界案例，这些案例旧模型也处理不了，而且简单的提示词工程 (prompt engineering) 也无法修复。

这个“悬崖”并不是新模型的缺陷。它是我们衡量模型改进的方式（混合难度评估集的平均通过率）与值班排班中实际遇到的问题（最难流量的残差集，现在已经没有了以前占据主导地位的简单故障的缓冲）之间的不匹配。

我在陷入困境的 AI 团队中看到的最显著模式，是他们复杂的模型栈与原始的运营水平之间的差距。一个团队可能在生产环境中运行三个前沿模型，背后是自定义路由逻辑、包含八个检索阶段的 RAG 流水线，以及一个调用二十个工具的智能体。但与此同时，他们没有轮值制度、没有 SLO、没有运行手册，甚至只有一个 #incidents Slack 频道，在那里的提示词是由当时刚好醒着的某个人进行实时热修复。该产品运行在 2026 年的模型基础设施和 2012 年的运维基础设施之上，而这种差距每周都会导致另一次故障。

当问题出现时，本能反应是去拨动模型杠杆。质量下降了？试试新版本。延迟激增了？换个供应商。生产环境中出现幻觉？再加一个护栏提示词。这些都无法解决根本问题，即没有人将系统的可靠性作为一种专业规范来负责。这些团队真正需要的——通常在他们需要另一位应用科学家之前——是他们的第一位 SRE。

Agent 以“全部搞定——如果需要任何修改请告诉我！”结束它的回合，而你的编排器必须决定是将工单标记为已解决、启动下一次交接，还是重试。这句话不是一个返回码。它只是一个训练出来的、为了在聊天结束时听起来很贴心的礼貌语，而它下游的每一行自动化代码都继承了这种模糊性。那些将此视为解析问题的团队会编写捕获 \b(done|complete|finished)\b 的正则并收工。而那些在生产环境中运行 Agent 的团队最终会明白，完成是一个事件，而不是一种情绪。

失败模式通常是双峰且枯燥的。要么是 Agent 在未完成时宣布完成——过早终止——而编排器愉快地在一个半成品产物上推进工作流。要么是 Agent 确实完成了，但表述方式与检测器不匹配（“我已经落地了更改，尽管边界情况的测试仍然不稳定”），编排器于是发起重试，导致重复工作、产生重复的副作用，有时甚至会推翻成功的第一次尝试。这两种模式都会静默地退化。在有人阅读 Trace 并注意到 Agent 说了“我想这些就是全部了”而计费系统将其视为一次提交（commit）之前，任何仪表盘都不会显示异常。

解决方法不是更智能的解析。而是给 Agent 一个结构化的终止方式——一个具有枚举状态、原因代码和你的流水线可以路由的句柄（handle）的“完成工具（done-tool）”——并将编排器改为等待该事件，而不是监听聊天流。

你的 CI 通过了。你的评估（evals）看起来没问题。你切换了流量开关，然后继续工作。三天后，一位客户提交了一个工单，称生成的每一份报告都不再包含 summary 字段。你翻阅日志发现，新模型开始稳定地生成 exec_summary —— 这是一个隐蔽的键名重命名，由于你忘记将其添加到发布门禁（rollout gates）中，你的 JSON schema 验证从未捕获到这一点。根本原因是模型升级。检测滞后时间为 72 小时。

这并非假设。在那些拥有复杂应用代码部署流水线，却将 LLM 版本升级视为基本“免费” —— 仅是配置更换而非部署 —— 的公司里，这种情况屡见不鲜。这种思维模型是错误的，由此导致的失败模式极其难以捕捉。

你手写的 ETL 管道处理了 95% 的记录。那些边界情况——带有逗号的货币字符串、格式不一致的日期、不统一的国家代码——流向了你的数据仓库，并悄悄地破坏了你的仪表板。直到季度报告看起来不对劲时，才有人注意到。你又在管道中添加了一个特殊情况。循环往复。

LLM 可以解决这个问题。它们能从原始样本中推断模式（schema），处理任何工程师都预料不到的杂乱边界情况，并能以极短的开发时间将非结构化文档转换为结构化记录。已经有几个团队推出了这种方案。其中一些团队也经历过 LLM 悄无声息地将 "$1,200,000" 转换成 1200 而不是 1200000，在结构完全有效的情况下将严重程度分数从 "high" 切换到 "low"，以及以通过了所有模式检查的方式连接了错误的业务外键。

问题不在于 LLM 不擅长数据工程。而在于它们的失败模式对 ETL 来说恰恰是完全错误的：高置信度、不报错、且输出结构有效。

一家运行生产级 AI 分诊助手的医疗保健公司收到了一封令所有团队都心生畏惧的邮件：他们的推理服务商将在 90 天后停用他们正在使用的模型。他们更新了模型字符串，进行了快速的手动冒烟测试，然后发布了替代版本。三周后，新模型开始主动提供未经请求的诊断意见。Token 使用量暴增了 5 倍。整个 Prompt 模板由于新模型对指令表述的解读不同而失效。由于输出 Schema 发生了偏移，JSON 解析也宣告失败。

这并非个案。如果你仅仅将模型停用视为一种配置变更，而不是一次系统迁移，那么这就是你在模型停用周期中的常态体验。

当 OpenAI 在其较新的模型中弃用 max_tokens 而改用 max_completion_tokens 时，已经稳定运行了数月的应用程序开始返回 400 错误。没有任何公告触发警报，你的代码中也没有错误。模型改变了，但你的假设没有变。这是将模型升级视为破坏性变更（Breaking Change）的典型案例 —— 只不过大多数变更更加隐蔽，因此更难被发现。

基础模型的更新并不遵循与库发布相同的“社会契约”。Git 提交中没有 BREAKING CHANGE: 前缀。没有语义化版本（SemVer）的提升来告知你的 CI 流程去报错。输出格式变窄、语调偏移、JSON 结构重组、推理路径缩短 —— 下游消费者是通过逐渐恶化的用户体验和混乱的数据分析慢慢发现这些问题的，而不是通过抛出的异常。

三个词差点毁掉一个生产功能。一个团队在例行的文案优化中，向一个面向客户的 prompt 添加了"请简洁回答"。四小时内，结构化输出错误率急剧攀升，下游解析崩溃，创收工作流陷入停滞。修复方案很简单——回退变更。噩梦在于他们根本不知道是哪次变更导致了问题，因为这个 prompt 以硬编码字符串常量的形式存在，没有版本历史，没有测试，也没有回滚机制。这个事故本可以通过大多数团队至今仍未构建的基础设施来预防。

Prompt 现在是你系统中最重要、却治理最薄弱的代码。