38 篇博文 含有标签「llmops」

针对糟糕的代码部署，标准流程是在一分钟内完成回滚。针对错误的配置推送，标准流程是亚秒级的开关切换。而针对糟糕的模型升级，应对方案则是值班工程师在早上 09:14 临时想出的法子，而且通常需要耗时 7 小时才能完成。在这 7 小时内，性能倒退持续累积——错误的答案被发送给客户，支持工单堆积如山，而监控面板显示的只是缓慢的倾斜曲线，而非迅速回归绿色的断崖式好转。

差距之所以长达 7 小时，并非因为团队动作缓慢，而是因为模型升级的“回滚”与代码的“回滚”并非同一种原语。它更接近于数据库模式（schema）迁移：局部的、滞后的，且无法通过按下你希望存在的那个按钮来撤销。围绕“一个按钮”编写事故应对方案的团队，并不具备实际回滚所需的控制能力。

这篇文章将探讨这些控制能力具体是什么样的，为什么必须提前为此付出代价，以及当你第一次尝试在负载下回滚模型时，你会对你的平台有哪些新发现。

系统提示词（system prompt）上一个四个词的修改——用 "respond using clean JSON"（使用干净的 JSON 响应）替换 "output strictly valid JSON"（输出严格有效的 JSON）——在评估（eval）中一度没有引起任何波动。它在周四发布，却在周五凌晨 4 点被回滚，因为结构化输出的错误率从 0.3% 飙升到了 11%。提示词并没有变糟。它只是变得“不同”了，而下游解析器在无人察觉的情况下，已经固化（pinned）在了 "strictly valid" 这个词组上。

这是大多数提示词工程（prompt-engineering）团队尚未建立工具来应对的失效模式：提示词被视为作者拥有的文本，而实际上它是与作者从未见过的消费者之间的一份合约。这些消费者中，有些是逐字引用原句的其他提示词；有些是 JSON 模式（JSON schema）字段锚定在特定形容词上的工具描述；有些是其评分标准（rubrics）要求裁判（judge）检查“严格有效格式”的评估（evals）；还有一些是解析器——最脆弱的一类——其正则表达式是根据模型输出的精确前导语（preamble）进行校准的。

一次“小小的措辞清理”会悄无声息地破坏解析器、导致裁判校准偏移，并使数周的评估运行失效。这些失败都不会在 PR（拉取请求）中显示出来，而是在一周后作为“偏移”（drift）出现在仪表盘上。

智能体用 400 毫秒回答了一个简单的问题，然后因递归限制错误（recursion-limit error）崩溃。Trace 显示了 25 次工具调用。从上到下阅读 Trace，工程师会得出结论：智能体糊涂了 —— 以略有不同的顺序反复调用那几个工具，始终无法收敛。这个结论是错误的。智能体并没有糊涂。它陷入了一个死循环：工具 A 调用了模型，模型选择了工具 B，工具 B 的实现再次调用模型来格式化其输出，而格式化程序又选择了工具 A。Trace UI 将四个嵌套调用渲染为扁平列表中的四个兄弟调用，导致唯一能发现问题的开发者也无法察觉这个循环。

这就是工具重入（tool reentrancy），这是一种你的函数调用层几乎肯定没有建模的 Bug 类别。并发安全的代码对此已有数十年的原语支持：记录同一线程嵌套获取次数的重入互斥锁（reentrant mutexes）、语言层面的递归限制、堆栈检查 API，以及一种文化共识：任何回调运行时的函数都需要一个明确的契约，规定允许何种重入。工具调用层默认采用“发后即忘”（fire-and-forget）模式。运行时没有可供检查的调用栈，调度前没有循环检测器，工具定义上没有重入属性，Trace UI 的形式像日志而非图。结果就是，任何超过十几个条目的工具目录都会悄悄变成框架无法察觉的递归。

一个 AI 功能在周二出现了回归。评估（eval）CI 是绿色的。护栏（guardrail）仪表盘很干净。检索（retrieval）P95 指标正常。模型供应商没有任何故障。然而，支持队列中挤满了用户，他们反映助手“本周感觉变差了”。产品经理（PM）是房间里唯一能说出哪里回归的人，但即便是她也无法告诉你哪个仪表盘能捕获到这个回归。欢迎来到“接缝 Bug”（seam bug）的世界——这种故障中，每个单独的产出物负责人（artifact owner）都能证明自己的部分没问题，但集成后的体验依然是坏的。

这是 AI 功能人员分配方式的必然结果。纸面上的负责人名单看起来很合理：提示词作者负责系统提示词，评估负责人负责离线测试集和 CI 门禁，工具/检索负责人负责函数调用和搜索索引，护栏负责人负责审核和策略过滤器。此外，还有一个模型选择决策，通常游离在这四者之外——有时归属于平台团队，有时归属于最近提交采购单的那个工程师。五个负责人，却没人对“这个功能对用户是否有用”负责。

绿色 CI 并不意味着“这个提示词有效”。绿色 CI 的本质是“编写评测的工程师想不出这个提示词会如何出错”。这是两个截然不同的断言，而它们之间的差距正是生产事故的温床。一个评测套件并不是对模型的测量——它是对编写者的冰冷写照。他们的方言、领域知识、资历、偏好的失败模式，以及他们在编写测试用例时恰好使用的模型。根据构造，工程师没想到的测试内容统统未经测试。更糟糕的是：他们会从同一个视角不断扩展套件，因此随着套件的增长，盲点并不会缩小，反而会变得根深蒂固。

这就是评测作者单一化（eval-author monoculture）问题，也是当今 AI 工程中讨论最少、风险最高的可靠性问题。团队痴迷于裁判偏差、位置偏差、冗长偏差、泄漏和污染——但上游偏差其实是最初决定测试用例的人的偏见。其他任何评测误差来源都会被它放大。如果你的套件是由一个人编写的，那么你就拥有了一个带有性格的基准测试，而这种性格正是你的 CI 能够捕获风险的无形天花板。

工程主管们对“代码腐烂”这一概念已经习以为常。依赖项需要更新，基础设施有生命周期管理，证书会在无人质疑的日期过期。然而，提示词仓库（prompt repository）却往往被视为一种“一次编写，多次读取”的产物——尽管它定义了你的产品如何与一个每六周就发布一次行为变更的概率引擎进行对话。

六个月前针对当时主流模型调优的系统提示词，现在依然在生产环境中使用。针对早已变更的分词器（tokenizer）挑选的 Few-shot 示例，仍在每次调用时被注入。重排序提示词是针对供应商上季度已废弃的嵌入端点调优的。没有人安排审查。也没有人打算去安排。

这并非假设性的失效模式。当一个团队将其精心针对 GPT-4-32k 稳定化的提示词套件迁移到 GPT-4.1 和 GPT-4.5-preview 时，其回归测试的通过率分别仅为 95.1% 和 97.3%。在生产环境中，3-5% 的隐性质量退化绝非可以忽略的误差；在任何具有一定规模的场景下，这都是一种用户可见的退化，而团队中没人是有意发布这种退化的。而且，这些还是拥有回归测试套件的团队。中等水平团队的“回归测试”，不过是值班工程师在处理上一次事故时凭感觉形成的印象。

我们缺失的范畴是提示词资产折旧（prompt asset depreciation）：这是一种维护纪律，它将每个生产环境中的提示词视为具有已知寿命的折旧资产，而非一成不变的常数。

对共享系统提示词的第一次修改感觉就像是优秀的工程实践。三个团队都在各自智能体的顶部粘贴了相同的 18 行安全前导指令，有人注意到了这一点，内部平台团队说了一个显而易见的提议：让我们把它中心化吧。于是 prompts.common.safety_preamble@v1 出现在了注册仓库中。由于这是阻力最小的路径，加上安全团队很高兴能由一个团队统一负责措辞，30 个团队在短短一个季度内就采用了它。在接下来的两个季度里，这看起来就像是一个完美的 DRY (Don't Repeat Yourself) 胜利。

随后，安全团队需要对措辞进行微调。可能是新的合规条例收紧了助手可以主动提供的用户信息范围，也可能是红队发现需要向拒绝条款中增加一句话。平台团队完成了修改，发布了 v2 版本。不到一天，支持队列就充满了消费团队的消息：我们的评估 (eval) 下降了、我们的格式崩了、我们的工具调用率减半了、我们的语气变了、延迟增加了（因为模型开始进行更多推理）。每个团队都希望回退修改。而安全团队需要发布它。没有人能在不进行重新评估的情况下升级，但又没有人负责重新评估。欢迎来到共享提示词的“旗帜日 (flag day)”。

当你的 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) 也无法修复。

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