67 篇博文 含有标签「llmops」

你公司最昂贵的评测集 (eval set) 并不在你的代码仓库里。它藏在销售工程师六个月前整理的一份幻灯片里，外加三个以你前五大客户命名的演示账号，以及一段半记不清的脚本，上面写着“点击这里，让智能体总结上个季度，见证奇迹的时刻”。它每周运行一两次，面向价值六位数或七位数的潜在客户。AI 团队里没有人曾为它完整跑过一次。

接着，你在某个周二发布了模型迁移。周四下午 4 点，销售工程师在值班频道发消息：摘要输出现在以“当然可以！这是摘要……”开头，而不是直接进入要点；数字被拼写成了单词而非阿拉伯数字；而潜在客户 —— 一位在四周前就预约了这次会议的财富 500 强 CFO —— 刚刚询问该产品是否一直这么啰嗦。发布说明称这是一次 1.2 个百分点的评测提升 (eval lift)。

评估集（eval set）是你的 AI 团队产出的阅读量最高的工件，而你几乎肯定不知道谁在阅读它。代码库是私有的，CI 任务是内部的，文件就在 prompts/ 目录的上一级——然而，上个季度一名销售工程师为了演示抓取了六个案例，一名市场分析师将三个失败案例放进了“看看我们的系统有多健壮”的幻灯片中，客户成功部门在续约电话中逐字引用了评估通过率，而产品部门则将该文件视为 AI 团队不愿分享的隐藏规范。阅读这些案例文件的人比阅读生成它们的代码的人还要多，而 AI 团队中却没人在意。

这不仅仅是权限管理的失效。评估集与代码库的其他部分位于同一个 Git 服务器上，拥有与其他工程产物相同的访问控制。问题在于，AI 团队是唯一将评估集视为代码的群体。其他所有人都会将其视为文档、营销材料、产品规范或客户投诉日志——而这些解读中的每一项都会从同一个文件中提取不同的片段，针对不同的受众进行包装，并将其发送到 AI 团队观察不到的地方。

在最近一次 prompt 变更后，你的综合评估分数上升了 1.2 个点。但在同一周，法语查询的 CSAT（客户满意度）下降了 4 个点。这两个数字都是正确的。它们之所以不一致，是因为评估集（eval set）中 88% 是英语，6% 是西班牙语，其余的是长尾语言，其中任何一种语言的流量都不足以触动汇总数据的变化。法语的性能回归就在你的数据中 —— 它只是恰好位于顶级指标（top-line metric）噪声基底以下三个小数点位。

这是我在生产级 AI 系统中看到的最常见的区域漂移（locale drift）形式：不是突然的崩溃，也不是翻译字符串的 bug，而是一种被汇总数据掩盖、并最终在支持队列中浮现的持续性能差距。当巴黎办公室的人转发一张截图时，你已经在那个回归之上又发布了两个 prompt 变更，而二分查找（bisect）的成本需要耗费三个工程师工作日。

一位资深工程师向 planner 提示词（prompt）提交了一个只有四个单词的修改——“if uncertain, ask first”（如果不确定，先询问）。Planner 自身的评估集（用于评分计划是否合理）提升了 0.5 分。他们合并了代码。两周后，verifier 的评估显示通过率出现了 3 个百分点的回归，且没人能复现。根本原因在于：planner 现在会提出更多澄清性问题，executor 在第二轮收到的任务描述变短了，而 verifier 的评分准则（rubric）是针对之前 executor 较长的输出进行隐式调优的。一个没人标记为高风险的修改，一次性改变了下游的三个分布。

当你把智能体（agent）内部的提示词看作一个扁平的文件文件夹，而不是一个带有“边”（edges）的图（graph）时，就会发生这种情况。提示词有负责人，但它们之间的“边”却无人看管。

用户打开你的聊天窗口，提了一个问题，得到一个评估套件打分为 4.6（满分 5 分）的回答。接着，他们换了一种说法问了同样的问题。同样的回答，同样的分数。他们又试了一次，这次用了人们在怀疑机器没在听时常用的套话——“我实际上想做的是……”——然后他们关闭了标签页。从模型的视角来看，这是三个干净的问答轮次。从仪表盘的视角来看，这是一个活跃的会话。但从用户的视角来看，这是一个连续三次失败的产品，而且以后再也不会打开了。

这就是“单轮评估”（per-turn evaluation）无法察觉的失效模式。孤立来看，每一轮对话似乎都是正确的。裁判（Judge）给了赞。幻觉检测器保持沉默。相关性评分很高。然而，整个对话作为整体并没有解决任何问题——而这正是用户真正评估你的单位。

想要发现你的 AI 团队缺乏评测纪律，最快的方法就是分别在 Slack 私聊中询问三名工程师：“你上次的提示词（prompt）修改提升了质量吗？”——然后看着他们三个人都回答“是”，但给出的却是三个不同的数字，针对的是三个不同的切片（slice），在三台不同的笔记本电脑上运行，而且团队中没有其他人能复现这些结果。从教科书式的定义来看，这不单纯是评测问题。教科书会说你没有评测。而现实情况更糟：你有 太多 的评测，每个评测都是私有的，每个都能衡量一些真实的东西，但没有一个能汇总成组织可以据此制定计划的单一指标。

这就是“影子评测（shadow eval）”反模式，大多数 AI 团队在承认这一点之前，这种状态持续的时间比他们愿意承认的要长。它看起来效率很高——每个工程师都有一个 notebook，每个 PR 都附带一张通过率的截图，每次站会都会提到“在长尾切片上取得了胜利”——而且它能在季度评审中幸存下来，因为“我们做评测”的门槛太低了，只要运行任何内容都算。但组织得不到任何信号。领导层无法判断上个月的三次提示词修改是推动了产品进步还是原地踏步，因为三名工程师是根据三个私有切片进行衡量的，而且在切换文件的那一刻就停止了对之前基准（baseline）的追踪。

打开任何已经上线超过九个月的 AI 功能的系统 Prompt。向下滚动，越过角色描述，越过格式规则，越过安全护栏。停在标题为 <examples> 或 ## Examples 的块，或者是你的团队在某人把前三个好用的 Slack 线程复制到代码块的那天给它起的任何名字。读一读它们。有 60% 的可能性，其中至少有一个引用了已经更名的功能、一个已不存在的按钮，或者产品经理在两个季度前悄悄砍掉的工作流。

这种衰退从评测（eval）仪表盘上是看不出来的。评测得分是绿色的。它们已经绿了好几个月了。它们之所以是绿色的，是因为评测集是针对 Few-shot 示例所引用的同一个产品界面编写的，两者已经同步老化。模型正在完美地模仿去年的产品，而在一个以此标准打分的测试集上，它是合格的，然而真实用户在与今年的产品互动，并默默忍受由此产生的幻觉（confabulations）。这就是没有人写进 LLMOps 路线图的半衰期。

PR 审查仪表盘连续六周显示绿色。机器人捕获率、评论量、开发者的“点赞”反应——一切都很稳定。然后生产环境发生了一起安全事故，事后分析指向一个缺失的空值检查（null-check），而这个检查机器人以前是能捕获到的，大约在两个月前悄然停止了。没有人更改机器人。没有人降级模型。仪表盘从未变动。但标准变了。

这是自动化代码审查在任何产品演示中都不会出现的失效模式。团队采用 LLM 审查器是为了获得一致性——每个 PR 都遵循相同的检查清单，没有资深工程师因“心情不好”而产生的波动，初级贡献者的周转速度也很快——这种一致性在最初的一个季度确实存在。然后系统提示词（system prompt）演变了，模型升级了，few-shot 库积累了，机器人开始使用不同于团队验证时的模型，根据不同的准则来审查不同的代码库。团队对“机器人能捕获什么”的心理模型衰退成了“机器人上周捕获了什么”。

一个团队负责摘要生成器。另一个团队负责摄取这些摘要的搜索排序器。第三个团队负责一个路由，根据排序器的置信度分数在不同的智能体人格之间进行选择。这些团队都没有共同的值班轮换，也没有人参加同一个站会，他们之间唯一的契约就是“上一个功能的输出是下一个功能的输入”。周二，摘要团队收紧了一个提示词，以修复销售演示中反馈的幻觉问题。六小时后，搜索排序器的质量骤降。到周三早上，路由开始将任务交给错误的智能体人格。复盘报告会将原因记录为“提示词变更”，但实际原因是团队的 AI 功能已经悄然组成了一个没人绘制过的有向图。

这是最常见的 AI 故障形式，它不会触发你为 AI 故障构建的任何警报。模型没有宕机。被修改功能的评估套件显示为绿色。Token 成本曲线很平稳。真正断裂的是两个功能之间的接口，你的依赖工具将其视为纯文本，因为在 API 边界它确实只是纯文本——并且将其视为惰性的，因为纯文本不携带版本、Schema 或弃用策略。

一个健康的评估集（eval set）本应是成熟的标志。但在任何一个周一，它也可能意味着排队等待的 1,000 个失败案例，而人工审核员只有 8 小时，且每个案例的处理效率大约是 50 个。这笔账很残酷：大约每 20 个失败案例中只有一个会被阅读。剩下的 19 个只能等待。至于哪 19 个在等，哪一个能被选中，完全取决于文件加载的顺序。

大多数团队将其称为“审核失败案例”。但它更像是一场按字母顺序加权的抽奖。一个影响 2% 生产流量且位于文件顶部的失败案例会得到关注。而一个影响 40% 生产流量但位于文件底部的失败案例，即便能被看上一眼，也要等到周五下午。团队在周二发布了针对小问题的修复方案，并在周四写了一份回顾（retro），纳闷为什么仪表盘上的指标毫无变化。

当一个多租户 SaaS 团队在其系统提示词（system prompt）中添加第三个 if tenant_industry == "healthcare" 分支时，那一刻他们其实已经在不经意间为自己聘请了一位编译器工程师。没有人申请过这个人头（headcount），也没有人事先规划过这项工作。团队以为自己在交付一个功能，实际上交付的是一套构建系统，而这套系统仅靠 f-strings 勉强维系。

任何试图将 AI 功能推广到具有哪怕轻微差异的客户群体的团队，最终都会撞上同一堵墙。租户 A 属于医疗行业，需要符合 HIPAA 标准的回答框架。租户 B 属于法律行业，需要严格的引用规范。租户 C 是购买了自定义安全准则的大型企业。租户 D 是免费层级用户，使用默认设置。最直觉的做法是用运行时条件语句（runtime conditionals）处理差异，这些条件不断嵌套，直到除了作者之外没人能读懂这个提示词。第二种直觉——也是大多数团队在撞墙后得出的方案——是提示词编译（prompt compilation）：规范的“提示词”不再是一个字符串，而是一个源码产物（source artifact），最终触达模型的则是编译后的输出。

一位工程负责人（Head of Engineering）在周一早晨打开了研发速率仪表盘。每周合并的 PR 数量：持平。完成的故事点：持平。改动的代码行数：低得可疑。图表显示，AI 团队在这个季度表现平平。而在两个楼层之外，那支团队在三周内重写了七次系统提示词（System Prompt），更换了一个让工具调用准确率翻倍的工具描述，增加了六个新的 few-shot 示例，并不断调整重排序（Rerank）指令，直到产品感觉像是一个完全不同的应用。所有这些工作都没有出现在 PR 图表中。但对用户来说，这些改变无处不在。

AI 团队所做的改动与工程仪表盘所测量的指标之间的不对称，已成为 2026 年最具影响力的误判。在重度依赖 AI 的产品中，行为的改变正日益与代码的改动解耦，而支配了软件组织十五年的指标——PR 吞吐量、提交量、涉及的代码行数——衡量的都是代码的改动。一个团队可能每周都在重塑线上响应的分布，但在领导层信任的每一张图表上，他们看起来却无所事事。