108 篇博文 含有标签「llm-ops」

你运行了职业生涯中最干净的一次 A/B 测试。流量分配是 50/50，哈希函数看起来没问题，指标流水线没有造假，留存样本（holdout）得到了保留，经过三周的分析，得出了一个明确的胜者：变体 B 将任务完成率提升了 4 个点，统计团队对 p 值也没有异议。你将其 100% 发布了。发布两周后，你启动时所依据的核心指标却漂回了基准线，而且没人能解释原因。

这就是那个花了一些时间才看清的部分。两个变体都在向同一个长期记忆库写入并从中读取。变体 A 中的用户写入了一条记忆，比如 “该客户更喜欢直截了当的总结”，第二天，当同一个用户恰好处于变体 B 时，变体 B 的 Agent 加载了该记忆并将其读入其提示词（prompt）中。反向的情况也在另一个方向发生。实验并不是在比较提示词 A 与提示词 B。它是在比较 “读取提示词 B 形状记忆的提示词 A” 与 “读取提示词 A 形状记忆的提示词 B”。结果是受污染的联合分布的平均值，而发布则是回归到了同一曲面上的另一个点。

你与模型提供商签订了合同。你的运行手册（runbook）处理了该提供商降级的情况。当他们的仪表板变黄时，你的状态页订阅会向你发送告警。你觉得万无一失。然后，在某个周三下午，你提供商运行的基础云区域开始出现局部降级，你提供商的故障转移区域也受到了影响，因为他们为了控制单位经济效益而整合了容量。由于签署合同时上游两层的供应商决策，你的产品在 90 分钟内处于半瘫痪状态。

第二天早上，客户的事后分析（postmortem）请求出现在你的收件箱里。他们想要找到根本原因。根本原因存在于你的状态页无法看到的层级，也是你的合同无法约束的层级。这一层级正是所谓的第四方风险——它不是一个采购复选框，而是一个无形的依赖层，它会向上层传导故障，只会衰减而不会被吸收。

你停用了公司门户上的搜索栏，因为智能体（Agent）表现得更好。以简单的英语输入问题，获得带引用的回答，通过追问进行优化。试点项目的满意度指标爆表。上线邮件写道：“弃用旧版搜索，两周内全量切换。”两周过去了。旧索引被停用。查询框被聊天输入框取代。

六个月后，在某个周二的早晨，三件事同时发生。由于某人的批处理作业耗尽了共享配额，你的推理服务商对公司账号进行了限流。向量嵌入（Embedding）服务出现了区域性局部故障。一次配置推送清空了 Prompt 缓存。公司里每一位习惯在搜索栏输入“VPN 设置”或“报销政策”的工程师，现在都盯着加载动画转了 40 秒，然后收到一条无法理解其问题的拒绝信息，或者更糟——一条指向不存在的 Wiki 页面的言之凿凿的引用。员工互助的 Slack 频道消息炸了。IT 部门的收件箱里塞满了“搜索是不是坏了？”

你取代的搜索栏在过去 10 年的微小改进中保持了三个九（99.9%）的可用性。取而代之的智能体有着完全不同的故障形态——是变慢而非宕机，是出错而非空白，是昂贵而非缓存——而你的 SRE 文化尚未针对此进行校准。

当你的服务商故障转移（failover）第一次在生产环境中真正触发时，你会发现你真正构建的是什么。网关在几秒钟内完成了流量切换 —— 这一部分运行正常。接着，一种不同类型的事故开始了：12% 的响应中出现了格式错误的 JSON，之前从未被拒绝过的提示词开始遭到拒绝，延迟破坏了你的下游超时设置，面向客户的输出读起来就像是另一个产品。主服务商在 90 分钟后恢复了。而这次“成功”的故障转移留下了一个耗时 48 小时的事故复盘。

这是架构演示稿中最便宜的那一行所产生的账单：“备用服务商以实现韧性”。演示稿中从未提到，备用服务商需要专门的提示词、专门的评估套件（evals）、经过压力测试的容量，以及独立的值班手册。演示稿只说你不会宕机。在这点上它是对的，但在其他所有方面都错了。

在你的可观测性栈里某个角落,躺着一张表,记录了上个季度用户向你 AI 功能输入的每一条 prompt。如果你团队跟大多数团队差不多,这张表只被用于三件事:成本归因、滥用检测,以及偶尔在客户投诉答非所问时拿来 debug。产品团队没人打开过它。研究团队没人对它做过聚类。负责 AI 路线图的那位 PM 一行都没读过。

这是你产品组织里最昂贵的一次疏忽。用户输入的那些 prompt——尤其是你的功能没有处理好的那些——是你这辈子能收集到的"用户希望这个产品能做什么"的最高分辨率形式。你正在实时支付推理成本来产生这份信号,然后把它扔掉,只因为没人决定这本该是谁的工作。

某家保险公司用一整年的客服对话记录微调了一个支持模型。上线不到一周,合规审查员就发现了怪事:这个机器人一直把 "deductible"(免赔额)写成 "deductable"。不是偶尔出错——而是每八条出现该词的消息里,大约都会有一条这样写。模型并没有自己发明这个拼写错误。它继承了这个错误。一小撮一线客服两年来一直这么打字,而语料库忠实地反映了他们打的内容,不是字典里的内容。

这就是在运营数据上做监督式微调最令人不安的地方:模型并不是在学习你的领域,它是在学习你的语料库。这两者有重叠,但并不等同,而那道缝隙正是每一个本可预防的行为缺陷藏身的地方。训练数据里的频率并不是正确性的信号,它只是一个信号——告诉你你的团队恰好做某件事做得够多,多到模型愿意模仿。

错别字是最容易识别的情形。难的是那些没人愿意写成规则的部分,因为大家都默认模型会学到工作的"专业"版本,而不是工作被实际执行的样子。

发布标志运作完美。你在它后面发布了 AI 摘要生成器，在两周内将其比例从 1% 提高到 10%、50%，最后达到 100%，紧盯仪表盘，一切正常。季度末，平台团队的标志清理机器人发起了一个 PR，删除了这个已经多余的入口。你批准了。该 PR 与其他过期标志清理工作一起合并，代码库精简了 200 行。六周后的凌晨 2 点，供应商滚动更新了一个新的模型快照，你的摘要生成器开始信誓旦旦地在法律文件中编造条款，而你的值班工程师发现没有快速关闭它的手段 —— 只能重新部署。

标志完成了它的工作。但标志是错误的保留产物。发布标志回答的是“这条新代码路径是否应该是可达的？”一旦大家达成共识，删除它就是正确的清理举动。而紧急开关（Kill switch）回答的是“上游模型今天表现正常吗？” —— 这个问题永远不会过期，因为上游模型永远在变化。将它们放在一起清理，就像把烟雾报警器当作建筑许可证一样，是范畴错误：建筑物建成后，许可证会被归档，但报警器的接线必须永远保持连接，因为由于它所监控的情况仍然可能发生。

你的状态页显示为绿色。你的错误率为零。你的 p95 延迟看起来比上周略好。而在上周二，eval-on-traffic 指标在悄无声息中下降了四个点，整整九天都没人发现原因。因为当质量回退最终突破告警阈值时，已经有四个交织在一起的根因叠加在一起，团队已经无法分辨是哪一个最先引发了下滑。

这是 2026 年成熟智能体系统的主要故障模式，它不是任何单一组件的 bug。它是团队刻意构建的防御栈——那些出于好心、一个接一个添加的安全网——所产生的累积效应。主模型返回了垃圾内容；重试成功了。重试失败了；更便宜的回退（fallback）模型给出了答案。回退模型的输出格式错误；包装器（wrapper）将其重写为看起来合理的形状。包装器记录了一个软告警（soft warning）。没有人针对软告警设置告警。用户收到一个看似正确、交付流畅，但实际上比系统设计初衷要差的答案。

鲁棒层起作用了。质量表现却崩塌了。而告警机制是为鲁棒层存在之前的世界构建的。

你的状态页是一片绿色。你的错误率为零。你的运行时间仪表盘连续第七个月显示为 100%。然而，在周二上午 9:14，你的客户团队给你转来了一条来自一家财富 500 强客户的消息，上面写着：“我们的团队注意到这周助手的表现变差了。你能告诉我们发生了什么变化吗？”午饭前，你又收到了 12 条类似的反馈。现有的事故沟通手册（incident-comms playbook）无法回答其中任何一个问题，因为那套手册是为停机事故准备的，而现在没有任何东西崩溃。

这就是面向客户的 AI 复盘难题，也是我在将 LLM 功能交付给企业合约的团队中看到的最普遍的差距。可靠性的维度已经从“系统是否在线”转向了“系统是否和上周一样好”，而几乎没有任何沟通基础设施跟上了这一变化。状态页上没有相应的展示块。严重性等级标准（Severity rubrics）没有对其进行评分。支持服务的回复模版默认为“我们发现了一个问题并已解决”，这取决于客户当天的情绪，听起来要么是敷衍，要么是危言耸听。

针对付费用户群追踪数据进行模型优化的团队，其实是在一个“简单分布”上给自己打分。付费用户已经形成了一套工作流。他们之所以选择这款产品，是因为产品中的某些特质证明了刷信用卡付费的合理性，这意味着当他们进入评估集（eval set）时，已经学会了哪些提示词（prompts）有效，哪些功能给力，以及哪些“坑”不该踩。而免费层用户完全不是这样。他们是匿名的、探索性的，通常带有对抗性，且往往是非英语母语者，正在用第二语言对产品进行压力测试，他们触发了评估集从未涵盖的长尾失败模式。

这种不对称性正悄无声息地吞噬着每一个免费增值（freemium）AI 产品的转化漏斗。团队针对主要从付费追踪数据中提取的精选样本对模型进行评分。而免费层的那些“古怪”追踪数据——那些没有模板、用户正真诚地试图搞清楚产品能做什么的数据——从未被标注，从未进行回归测试，也从未为下一次提示词修改提供参考。模型在付费分布上变得越来越好，但在决定免费用户是否升级的分布上却慢慢变差。

每次模型升级都会被当作一种简单的“替换”推销给团队：一行配置更改、在延迟、成本或质量上可衡量的提升，以及几天用于吸收新模型怪癖的提示词微调。采购方案展示了每 token 的差值，工程工单列出了发布阶段，FP&A 团队预记了季度节省。接着，评估分值出炉，却没人认得出来。质量在理应提升的地方毫无波动。曾经达成一致的两个评分员现在分歧达 10 分之多。快照套件显示为红色，但差异看起来只是措辞调整。站会上有人提出了那个本应从迁移计划第一天就该出现的问题：模型到底是在针对什么评分？

这是第二张账单 —— 评估重锚税 (eval re-anchoring tax) —— 且它往往比第一张更昂贵。人工标注的参考分数锚定在旧模型的输出分布上。作为评委的 LLM 评分器针对旧模型的失败模式进行了校准。快照固定装置捕捉的是旧模型的措辞。团队对“优质输出”的直觉是基于旧模型的风格特征训练出来的。在模型替换中，这些都无法完好无损地保留下来。

我上个月交流过的一位 AI 初创公司 CTO 打开她的笔记本电脑，给我看了一个数字：47。那是目前在生产环境中运行的独立系统提示词（System Prompt）的数量，每个企业客户或每个逻辑分组各占一个。基础提示词在第四个月为一家需要更温和拒绝态度的医疗客户派生（Fork）了一次。然后为一家需要引用的法律客户又派生了一次。接着是为一家金融服务客户派生的，因为他们的合规团队有一份违禁词清单。当时，这些看起来都不是什么大事。每一个都是独立批准的小需求，让大客户经理团队能够顺利签下订单。

两年后，模型提供商宣布了她那些针对旧版本调优的提示词的切换截止日期。她的工程团队直觉反应是对新模型运行评估套件（Eval Suite）。评估套件仅针对基础提示词。基础提示词仍在为 0 号客户提供服务，该客户没有任何覆盖配置，且约占收入的 9%。