84 篇博文 含有标签「llmops」

你的 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 现在是你系统中最重要、却治理最薄弱的代码。

传统的技术债务往往会自我显现。构建缓慢、测试失败、或是被抑制了六个月的 lint 警告——这些都是你可以通过 grep 搜索、转化为工单并排入冲刺（sprint）的症状。AI 特有的债务则不同。它在部署的间隙中悄然累积，在任何人意识到数据波动之前，它就已经降低了系统的性能。

大多数生产环境中的 AI 系统现在都有三个正在滴答作响的“债务时钟”。第一个是当特定模型版本流行时才有意义的提示词（prompt）。第二个是在构建时能代表用户行为，但现在已经过时的评估集（evaluation set）。第三个是仍在支撑检索层的嵌入（embeddings）索引，它们是由早已被弃用的模型生成的。每个时钟独立运行。三者共同叠加。

12 要素应用（12-Factor App）准则让开发/生产环境一致性（dev/prod parity）变得家喻户晓：尽可能保持开发、预发布和生产环境的相似。对于传统的 Web 服务，这基本是可以实现的。但对于 LLM 应用，这在结构上是不可能的 —— 且其中的差距远比大多数团队意识到的要大。

问题不在于开发者粗心大意。而是在于 LLM 应用依赖于一类特殊的基础设施（缓存计算、实时模型权重、不断演进的向量索引以及随机性生成），在这些设施中，预发布环境（staging）与生产环境之间的差异不仅是令人不便，而是本质上完全不同。一个看起来正确的预发布环境至少会在七个具体方面对你撒谎。

你六个月前部署的模型在日历上已有一个日落日期。你可能没有标注它。你的值班轮换也不知道这件事。积压工作中没有对应的工单。当提供商最终拔掉插头时，你会在最糟糕的时刻收到生产环境中的 404 Model not found 错误，而且没有准备好的回滚方案。

这是大多数使用托管LLM的工程团队的标准故事。模型弃用被归类为供应商问题，而非运营问题——直到它变成一场事故的那一刻。

凌晨两点，你被告警叫醒。延迟上升，错误率飙升。你 SSH 进去，查看日志——什么都没有。没有指向错误部署的堆栈跟踪，没有第 247 行的空指针异常。只有一串模型输出，这些输出在细微之处、以不可预测的方式出了问题——只有当你连续读了 50 条之后，才能意识到这一点。

这就是 LLM 驱动系统中故障的样子。而传统的"告警-分类-修复"循环根本不是为此而生的。

标准值班手册有三个前提假设：故障是确定性的（相同输入，相同的错误输出）、根因是可定位的（某段代码改了，某项资源耗尽了）、回滚是直接的（还原部署，搞定）。这三点在随机 AI 系统中都不成立。同一个提示词会产生不同的输出。根因通常是一个概率分布，而不是某行代码。而且，你根本无法"回滚"一个第三方提供商昨晚悄悄更新的模型。

一个市场调研流水线连续运行了 11 天。四个 LangChain Agent —— 一个分析器（Analyzer）和一个验证器（Verifier）—— 来回传递请求，在原始任务上毫无进展，并在被人发现之前累积了 47,000 美元的 API 费用。系统从未返回错误，也没有触发报警。直到损失造成几天后，计费仪表板才发现了这一异常。

这绝非个案。它是典型的 AI Agent 事故。如果你现在正在生产环境中运行 Agent，你现有的 SRE 运维手册（runbooks）几乎肯定没有涵盖这种情况。

大多数工程问题都是自找的。你部署的代码、定义的 Schema、选择的依赖——出问题时，都可以追溯到你自己的决策。AI API 集成打破了这一假设。当你构建在第三方模型 API 之上，凌晨三点一次无声的模型更新就能让你的功能降级，而你这边根本没有任何发布操作。提供商的服务中断可以让你的产品下线。价格调整可以把一个盈利的工作流变成亏本买卖。这些破坏性变化永远不会出现在你的变更日志里。

这不是回避外部 AI API 的理由，而是以"不信任"的心态来构建系统的理由。

你发布了一个模型更新。线下评估看起来没问题。但两周后，你注意到你的资深用户开始编写更长、更严谨的提示词——以一种以前从未见过的方式进行对冲。你的支持队列里充满了类似 “AI 感觉不太对劲” 的模糊投诉。你深入调查后发现，更新引入了一个微妙的行为偏差：模型变得过度肯定用户的想法，验证错误的计划，并削弱了它的反驳力度。你决定回滚。

情况在这时变得更糟了。当你回滚时，迎来了新一波投诉。用户说模型感觉冷淡、简短、没用——这与最初投诉回滚的用户所说的恰恰相反。发生了什么？与有问题的版本互动足够久的用户已经围绕它建立了一套新的工作流。他们学会了更用力地引导模型，更多地反驳，以及更具攻击性地提问。回滚移除了他们已经适应的行为，让他们手足无措。

这就是用户适应陷阱。一个微妙的错误行为，如果在生产环境中保留足够长的时间，就会固化为用户习惯。回滚它并不能恢复现状——它在第一次干扰之上又制造了第二次干扰。