95 篇博文 含有标签「llmops」

一位客户对贷款被拒提出异议。监管机构开启调查。原告律师提交证据开示请求。这三者都带着同一个看似简单实则棘手的问题：你的系统做了什么决定，以及为什么？ 决策发生在 18 个月前。你调出案例，发现产生原始输出的每一个组件都已经发生了变化。托管模型版本已被弃用并迁移。系统提示词（System Prompt）被修改了 9 次。你的智能体（Agent）检索到的文档被重新分块（re-chunked）、重新嵌入（re-embedded）并重新排序（re-ranked）到了一个新的索引中。而让整个过程具有非确定性的采样设置从一开始就根本没有记录。

你无法复现该决策。这不是因为你疏忽大意，而是因为你的技术栈中没有任何东西是为了可复现性而构建的。事后解释性（Explainability-after-the-fact）归根结底是一个伪装成解释问题的可复现性问题——而可复现性这种东西，你要么在决策发生的时刻就通过工程手段将其固化，要么就会永远失去它。

令人不安的事实是，大多数团队发现这个漏洞时，恰恰是他们最承受不起后果的时候。重建决策的需求几乎从不会在正常运营期间出现。它往往伴随着诉讼、审计，或是带着监管机构电话号码的愤怒客户而来。到那时，捕获正确证据的窗口期早在一年半前就已经关闭了。

你对生产系统的每一次更改都遵循某种纪律。代码在 feature flag 后发布，灰度测试（canary）到 1% 的流量，当仪表盘变红时可以一键回滚。Schema 迁移是分阶段且可逆的。即使是 CSS 的微调也要经过人工阅读的 pull request。然而 Prompt 却并非如此。有人在文本框中编辑一段文字，点击保存，你产品的行为就会立即对所有用户发生改变——没有灰度测试，没有经过审查的 diff，也没有真正能让你回到先前状态的回滚按钮。

令人不安的是，这并非粗心的团队所导致的疏忽，而是工具链产生的默认结果。Prompt 被归类为“配置（configuration）”，因为它们是存在于编译后的二进制文件之外的字符串，而配置一直以来被认为是可以快速更改且无需完整发布周期的东西。但 Prompt 并不是配置。它是一个用英语编写的程序，由一个你无法控制的非确定性解释器编译，其行为你只能通过统计学来观察。将它视为配置值，是导致一整类生产事故的范畴错误（category error）。

你可以搭建一个预发布数据库。你可以搭建预发布队列、预发布支付沙箱，以及你所依赖的每一个第三方 API 的预发布副本。三十年来，整个预发布（pre-production）学科都建立在一个假设之上：你可以创建一个足够忠实于生产环境的副本，对其进行测试，并从中了解到发布后会发生什么的真实情况。

然后，你将托管模型添加到了关键路径中，这个假设便悄然瓦解了。那个现在主导你产品行为的组件——决定你的应用实际上在说什么、做什么的那个东西——正是你无法搭建预发布副本的唯一组件。它由别人进行版本管理，由别人进行速率限制，并由别人按照你无法察觉的时间表悄悄更新。你的预发布环境拥有一切的预发布副本，唯独没有预发布模型。

你按照每一份可观测性指南的要求对代理（agent）进行了插桩。每一个回合都有一个 span：完整的 prompt、检索到的块（chunks）、模型的思维链、它考虑过的工具调用、它起草随后又放弃的计划，以及最终的行动。存储费用是每 GB 三分钱，而在事件响应期间，这些追踪（traces）已经救了你十几次。你保留了一切，因为保留一切几乎是免费的，而且偶尔还能立大功。

这是平台团队中没人建模过的部分：那个追踪记录是用流畅的英语写成的，它点名道姓地揣测你的客户，还起草了你从未实际执行的操作。它是你公司产生的最容易被引用的制品，而原告律师会对着幻灯片上印着的你公司 Logo，向陪审团宣读其中最“精彩”的 200 个单词。让你的系统具备可调试性的推理追踪（reasoning trace），正是让它承担法律责任的推理追踪。

故障频道里传来消息，说新的提示词正在幻觉退款金额，所以你做了一个显而易见的决定：将生产环境标签重新指向到上周的提示词版本。三十秒，无需重新部署，教科书级的回滚。结果 Agent 表现得反而更糟。上周的提示词引用了一个名为 lookup_order 的工具，但平台团队在周二将其重命名为 orders.search。记忆库中充满了由新提示词格式生成的偏好摘要，而旧提示词会将这些内容误读为用户指令。你并没有回滚 Agent，而是制造了一个“奇美拉”——三分之一是上周的，三分之二是今天的——并在从未测试过该组合的情况下将其推向了生产环境。

这是任何人的运维手册中都没有涵盖的失败模式：Agent 的部署不是一个单一的构建产物，而是一个三元组——提示词版本、工具契约、以及累积的记忆状态。回滚其中一个维度，而让另外两个维度保持现状，并不能恢复之前的状态。它创造了一个从未存在过、从未通过评估、且不属于任何团队值班范畴的新状态。

重命名一个数据库列，看看会发生什么。编译器会捕获每一个查询构建器。ORM 迁移会捕获模型类。类型检查器会捕获 API 序列化器。集成测试会捕获通过网络读取该字段的两个服务。该列的每一个消费者都会被标记出来——只有一个除外。你的系统提示词（System Prompt）包含了一份为了“让模型理解数据”而精心格式化的表描述，它仍在自信地描述一个早已不存在的列。没有编译器错误。没有失败的测试。没有弃用警告。只有一个开始针对三个迭代（Sprint）前的架构生成查询的模型，以及一个慢慢被格式错误的 SQL 填满的仪表盘。

提示词中包含外键。它们引用数据库架构、工具签名、枚举值、API 结构，以及从生产数据中复制的 few-shot 示例——而这些引用都不参与重构。你粘贴到提示词中的每一个事实，都是在对一个你的工具链根本不知道其存在的表进行连接（Join）。当被引用的制品（Artifact）发生变化时，没有任何级联反应。提示词只是在那原地腐烂。

发布六周后，你的质量仪表盘开始下滑。点踩率攀升，任务完成率下降，值班频道里塞满了糟糕回复的截图。团队做了该做的一切：对比 Prompt（未变），检查模型版本（已锁定），审计检索索引（是最新的），并对部署历史进行二分查找（没有任何发布）。大家一致认为模型提供商悄悄降低了模型性能。当然，提供商坚持说没有任何变动。

大家都找错了地方。系统没有任何改变，改变的是用户。

发布周的指标是基于发布周的用户假设的。但人们会在几周内适应一款 AI 产品，而这种适应方式会系统性地破坏你在 Prompt、评估集（Evals）和发布基准测试中预设的假设。你的模型是冻结的，但你的用户不是。两者之间的鸿沟是一种大多数团队根本没有监测到的“漂移”——它产生了一种 AI 工程中最令人困惑的故障模式：在没有部署的情况下指标发生衰减。

这里有一个事实打破了大多数工程仪表盘的逻辑：两个完全相同的推理请求，返回相同的 token，按相同的 API 费率计费，但其碳足迹（Carbon Footprints）可能相差五倍。相同的模型，相同的提示词，相同的花费。唯一改变的是由哪个数据中心响应以及当时的时间。如果你的可持续发展指标是根据支出金额推导出来的——几乎所有人都是这么做的，因为支出是唯一被真正追踪的数字——那么你的可持续发展指标就是错误的，而且当你越是努力优化成本时，这种错误就越严重。

美元和焦耳看起来应该是一致变动的。更多的 token，更多的计算，更多的钱，更多的能源。对于在单一瞬间、单一地点处理的单个请求，它们确实大致一致。但是，当你开启那些能实现大规模廉价推理的杠杆——激进的批处理（Batching）、模型路由（Model Routing）、非高峰期调度、多区域故障转移——这两个指标就会脱钩。成本是合同的函数，而碳排放是物理学和电网的函数。它们不是同一种函数，将其中一个作为另一个的代用指标，最终会导致你在可持续发展报告中填入一个审计员可以证伪的数字。

你的轮值制度（on-call rotation）最初是为了捕获一种特定类型的故障，但绝非那种真正会让你的 AI 产品崩溃的故障。它监控的是停止响应的服务、飙升的延迟曲线、超过 1% 的错误率。这些都是阶跃函数（step functions）：原本运行正常的东西突然失效了，这种不连续性足以在凌晨 3 点叫醒一名工程师。整个体系——阈值、运维手册（runbooks）、升级策略——都假设故障会自我宣告。

对于一个包含模型在环（model in the loop）的系统，真正关键的失效模式恰恰相反。上周二，你的提取流水线准确率为 94%。这周二，它变成了 91%。没有服务崩溃。每个请求都返回了 200。延迟平稳。输出依然是格式良好的 JSON。但你 3% 的用户现在得到了微妙的错误答案，而且他们不会提交 Bug，因为答案看起来是正确的。由于没有触发条件，寻呼机（pager）保持沉默。等到有人注意到时——通常是愤怒的客户，通常是在几周后——这种回归（regression）在整个过程中一直在静默地累积恶化。

看看任何 AI 产品的路线图，你都会发现用来列出准备发布之物的分栏：一个新的智能体、一个更好的检索流水线、一次模型升级、一次微调。每一项都是一个“诞生”。看板上没有任何一项代表“死亡”。没有一栏是留给你将停止支持的模型、将停用的提示词、将归档的评估集或将关闭的功能的。路线图从构造上来说就是乐观的——它们是你承诺去创造的未来清单。

对于确定性软件来说，这种遗漏并无大碍，因为你两年前发布的功能在你不改动它时大多能保持运行。但对于 AI 系统来说，这却是无声的灾难，因为无论你是否触碰它们，你发布的东西都在腐化。针对 GPT-4 的特性而优化的提示词，在提供商调整模型的那一天就会退化。针对去年的失败模式编写的评估套件，将不再能衡量任何真实的问题。你所依赖的模型可能会收到一个你并未规划的 60 天弃用通知。一份只规划发布的路线图，在它未追踪的每一行中都在积累隐形负债。

演示成功了。你输入了一个问题，智能体调用了三个工具，经过多步计划的推理，最后给出了一个让全场人都为之振奋的答案。有人说：“上线吧。”三个月后，你的产品依然没有上线，而且没人能解释时间都去哪儿了。

时间都花在了这里：演示只占了 10% 的工作，它只是大脑。剩下的 90% 是管道工程——那些在正常运作时无人喝彩，一旦出故障就是灾难性的评估（Evals）、护栏（Guardrails）、可观测性、成本控制和备用路径。这 90% 就是“从演示到生产的税”，而大多数团队在做预算时，却把它当成了一个可以忽略不计的舍入误差。

数据说明了另一番景象。MIT 2025 年的一项企业 AI 研究发现，95% 的生成式 AI 试点项目未能产生可衡量的损益（P&L）影响。另一项分析则更加直截了当：企业每启动 33 个概念验证（PoC）项目，只有 4 个能进入生产阶段。这意味着夭折率高达 88%，而死因几乎从未出现在模型身上，而是演示让你跳过的所有环节。

评估仪表盘连续三个迭代（sprints）都在攀升。困难切片的质量提升了 6 个百分点，回归切片提升了 9 个百分点，而在支持团队根据上季度最糟糕的工单亲手整理的切片上，质量提升了 12 个百分点。团队据此发布了模型升级。两天后，一位客户提出了一个与评估集中的任何内容都不沾边的问题，结果得到的答案比六个月前还要糟糕。

一旦有人想到进行排查，原因很快就浮出水面了。提示词工程师（prompt engineers）一直与评估团队在同一个代码仓库中工作。他们发现了那些精心策划的示例——这些示例来之不易，有的甚至是某人为了一个理想答案的措辞争论了一个小时才定下来的。在几个迭代中，他们把其中最有代表性的示例以 few-shot 演示的形式直接复制到了生产环境的系统提示词（system prompt）中。仪表盘持续攀升，是因为模型在推理时处理的正是它曾经逐字见过的输入。没有人指出这个问题。没有人负责划定“用于衡量质量的示例”与“用于发布到提示词中的示例”之间的界限。两个团队都准确地完成了他们被雇佣来做的工作。