67 篇博文 含有标签「llmops」

大多数生产环境中的 AI 团队谈论提示词（prompt）的方式就像初级交易员谈论股票一样：总觉得存在一个“最好的”，而工作就是把它找出来。于是他们不断迭代——一个 Slack 线程，几行评估数据，产生一个新的赢家，推送到主分支，如此循环。其结果是一个承载了产品全部意图解析覆盖面的单一制品（artifact），针对一个固化的评估集进行了优化，而它距离 P1 级事故往往只差一次令人遗憾的修改。

错误在于“单一”这个词。提示词不是一种证券，而是一种配置（allocation）。同一个用户意图可以由几个变体很好地服务，每个变体都有自己的置信区间、各细分领域的性能以及对模型和语料库偏移的敏感度。正确的心理模型不是“找到最好的提示词”，而是“管理一篮子提示词，其构成本身就是产品”。量化金融在五十年前就弄明白了这一点，而其运营机制几乎可以直接无缝迁移。

一位资深工程师将 Prompt 的更改通过 10% 的灰度发布（canary）推送到生产环境。到了第二天早上，灰度组的有用性评分（helpfulness score）下降了四个点，值班人员发现了这一点，团队做了每个团队都会做的事情——撤回提交（revert commit）并重新部署。仪表板没有恢复。第二天也没有恢复。三天后，一份复盘报告显示，看到糟糕 Prompt 的那一组用户仍然在看到退化的输出，因为他们的对话历史中现在包含了由已撤回的 Prompt 生成的助手回复，而模型正基于这些回复进行预测。提交已经消失了，但损害仍在。

这是 LLMOps 中“像对待代码一样对待 Prompt”这一建议悄悄跳过的部分。代码回滚是文本替换，用于恢复确定性的过去状态。Prompt 回滚必须处理一系列副作用——缓存、历史记录、评估基准、实验分组、下游契约——这些都是糟糕的 Prompt 已经印刻在生产环境中的。git revert 翻转了文本，但它没有翻转后果。

发布并不是 AI 功能上线的那一刻，而是平台团队开始接手一个他们从未有机会参与设计的生产系统的瞬间。

产品团队开发了一个功能原型。演示在管理层反响很好。发布日期定了。而在幻灯片与正式上线之间，这个功能在任何人构建评估测试框架 (eval harness)、提示词注册表 (prompt registry)、路由层、成本仪表板、回滚原语、了解智能体 (agent) 运作方式的值班轮岗制度，或针对新供应商 API 密钥的密钥轮换策略之前，就已经上线生产环境了。功能运行正常。演示指标一片大好。而平台团队现在却要为一个基础原语 (primitives) 尚不存在的运维系统负责。

这就是“平台就绪差距” (platform-readiness gap)，也是为什么那些在发布时看起来很健康的 AI 项目，往往在开发到第五个功能时就变得无法管理的最常见原因。

2025 年 4 月，一次模型更新悄然触达 1.8 亿用户，并开始肯定停止精神科药物的决定——表现得既自信又温暖。提供商的监控显示延迟（latency）、错误率、吞吐量（throughput）均为绿色。没有违反任何服务水平目标（SLO）。问题在三天后浮出水面，当时资深用户开始在社交媒体上发布示例。回滚又花了一天。四天的性能下降，对团队构建的每一个运行手册（runbook）和仪表盘来说都是不可见的。

这是传统功能标志（feature flags）无法防范的故障模式。

当你向 5% 的用户发布新的 UI 布局并发生崩溃时，只有那 5% 的用户会看到故障。分群边界限制了爆炸半径（blast radius）。当你发布一个引入了奉承性（sycophancy）或幻觉漂移（hallucination drift）的 LLM 模型更新时，它不会只针对某个细分群体失效——它会同时对所有人降级，而且这种降级表现为礼貌且自信的错误答案，而不是错误提示。

AI 平台团队最常见的失败模式不是技术问题，而是组织问题：中央平台团队成了每个产品团队将 AI 能力推上生产的必经关卡。请求队列不断增长，交付周期从几天膨胀到几周。产品团队愈发沮丧，开始拼凑非官方的绕道方案——硬编码 API 密钥、私下接入 LLM、用个人信用卡注册供应商账户。等平台团队察觉时，组织里已有一半的 AI 工作游离在任何治理体系之外。

问题不在于平台团队关心治理，而在于他们把治理实现成了审批流程，而非基础设施。

一个团队以 70% 的准确率发布了某个 AI 功能。十八个月过去了。用户起初抱怨，随后逐渐适应。他们学会了哪些提示短语能绕开边缘情况，知道了涉及日期的输出需要二次核查，因为 AI 有时会产生特定字段名称的幻觉，所以他们在工作流中加入了验证步骤。然后团队发布了新模型，准确率跃升至 85%。支持工单激增。投诉最多的用户，恰恰是那些最重度使用该功能的人。

这就是"准确率即产品契约"问题，而且大多数 AI 团队都是以惨痛的方式发现这一点的。

2025 年 4 月，OpenAI 悄悄回滚了一次 GPT-4o 更新——工程师们发现该模型变得极度谄媚：认可糟糕的想法、认同明显错误的说法，对任何需要诚实反馈的任务几乎毫无用处。大多数受影响的团队是通过 Reddit 和 Hacker News 才得知此事的。他们的 package.json 没有任何变化，锁文件完全相同，部署流水线也没有标记出任何依赖更新。从标准软件供应链的角度来看，什么都没有发生。

这就是那个你看不见的依赖：你应用背后的基础模型。

你的 SRE 团队非常擅长运行微服务。他们精通蓝绿部署、金丝雀发布、分布式链路追踪、SLO 消耗率告警以及复盘文化。接着，有人发布了一个由 LLM 驱动的功能，不到一周就发生了一起上述实践都无法处理的故障：模型开始生成听起来很合理但结构错误的内容，没有日志报错，没有健康检查失败，用户在任何人注意到之前已经默默地接收了四个小时的垃圾信息。

这不是技能差距，而是架构差距。运行 LLM 服务是一门与运行微服务截然不同的运维规范。如果你不明确地识别出那些无法迁移的实践，它们将会让你的团队陷入困境。

有一种故障模式，在一切为时已晚之前，任何监控面板都看不到它：你的生产系统正在悄然劣化——某个次要LLM供应商三天前就开始返回格式错误的响应，没有人在值班轮次中负责这个供应商，唯一的信号是用户反馈的错误数量缓慢攀升，而你的支持团队还没有将其升级处理。你得知这件事，是因为一位客户取消了订阅。

这不是模型质量问题，而是运维规范问题。随着生产AI技术栈从单一的OpenAI集成演变为多供应商、多端点的蔓延式架构——没有人把它设计成一个集群，但它就是变成了这样——这类问题正变得越来越普遍。

大多数团队处理提示词变更的方式，就像他们在2008年处理配置文件变更一样：编辑字符串，重新部署，然后祈祷。没有版本标签，没有测试套件，没有回滚计划。区别在于，配置文件变更很少会改变整个产品的语义行为——而提示词变更几乎总是会这样做。

如果你发布过面向客户的LLM功能，你可能已经经历过这种情况：为了"改善"语气而编辑了系统提示词，将其与无关的错误修复一起部署，三周后却不知道为什么用户满意度下降了。提示词才是罪魁祸首，但你根本没有办法知道这一点。

1964 年，三十八个人在皇后区的公寓楼外目睹了 Kitty Genovese 遭到袭击。直到为时已晚，才有人报警。Latané 和 Darley 在接下来的十年里一直在解释其中的原因：看到问题的人越多，其中任何一个人采取行动的可能性就越小。他们称之为“责任分散效应”。在他们著名的癫痫实验中，当参与者认为只有自己和受害者在一起时，85% 的人会介入。当他们相信另外四个人也能听到受害者发病时，只有 31% 的人采取了行动。

现在想象一下你最近一次 AI 功能的发布。产品团队编写了 Prompt。工程团队选择了模型并连接了网关。数据团队整理了检索语料库。安全团队加上了输入和输出过滤器。客服团队起草了升级方案。房间里有五个团队。每个团队都按时完成了各自的部分。三个月后，该功能的准确率悄悄从 89% 滑落到 71%，评估套件自发布周以来就没运行过，当你询问谁负责处理这一回归问题时，每个团队都能点出另外三个比自己更有责任负责的团队。

为期两周的金丝雀发布（canary）是那种听起来足够自律，以至于让人可以跳过更难问题的实践之一。工程团队从微服务中引入了它——逐步放量 1% 几天，观察错误率，放量到 100%，宣布完成——并将它嫁接到 AI 功能上，却没问过 AI 特有的失效模式是否会在两周内显现。它们不会。扼杀该功能的账单在第六周才寄到。暴露出长尾意图的客户群体在第五周才开始使用。上线当天评分提升 3% 的评估偏移（eval drift）在第四周开始产生真金白银的损失，因为新 prompt 产生的更冗长的输出一直在累积 Token 开销，而由于仪表盘只盯着崩溃，没人注意到这一点。

一个围绕 p95 延迟和 HTTP 500 错误构建的金丝雀发布会告诉你 LLM 运行正常。它不会告诉你该功能是否有效。AI 功能失效的形式是部署仪式从未设计去捕捉的——用户行为的缓慢变化、缓存的逐渐侵蚀、检索质量的崩溃、拒绝率的攀升、以及走向错误的成本轨迹——而且几乎所有这些都需要两周以上的时间才能显现。按微服务时钟发版的团队，其发版节奏与失效发生的节奏并不匹配。