95 篇博文 含有标签「llmops」

你在 18 个月前编写了这套评估集（eval set）。那时它是一个非常有用的工具：低价模型的得分是 71%，更好的模型得分是 84%，而当出现回归（regression）时，分数会下降并被察觉。这套测试套件在 CI 中赢得了一席之地。于是你不再关注它了。

今天再运行它，每个候选模型的得分都是 96、97、98。新版本的得分与旧版本相同。你怀疑表现较差的模型与你认为更好的模型得分也一样。仪表盘上的数字依然显示为绿色，检查依然通过，但它实际上什么也没告诉你。你的评估集并没有坏。它只是变简单了——因为底层的模型变强了——而没人在意它失去区分度的那个瞬间。

这就是评估饱和（eval saturation），这不仅是你可能遇到的失效模式，更是任何静态测试套件在足够长的时间跨度下必然走向的终局。一个所有模型都能通过的测试，已经不再是测试了。

你的评测套件通过了。240 个案例全是绿色，和上周一样。你发布了代码。两天后，支持工单激增。当你阅读对话记录时，你发现了一种你的套件完全没有立场的失败模式——不是某个案例从通过变成了失败，而是用户开始问一些你的套件从未想到过要去问的问题。

这就是评测（evals）的无声失败。我们将“全绿”视作对现状的肯定：“系统运行正常”。实际上，它只是对过去的一种陈述——即编写这些评测案例的那一刻。六个月前编写的评测编码了当时的三样东西：产品的范围、模型的失败模式，以及真实用户表达请求的方式。而这三者都在变化。功能增加了新的界面，模型升级了两次。随着用户了解产品的功能，输入分布也发生了漂移。套件没有随之移动，因此全绿的运行结果越来越只是在证明一个不再存在的世界。

没有人注意到，因为没有东西崩溃。过时的评测不会报错。它会继续自信地通过，但衡量的关键内容却越来越少。

值班轮换制度是建立在一个承诺之上的：故障是可以复现的。警报触发，你重新运行请求，观察 Bug 发生，找到错误的提交 (commit)，然后回滚部署。这个循环的每一个环节都假设了确定性 (determinism)。同样的输入产生同样的输出，而输出要么是对的，要么是错的，其方式一目了然。

Agent 集群悄无声息地打破了这条链条上的每一个环节。故障发生了一次，其采样温度 (sampling temperature) 你无法重现，所处的上下文窗口 (context window) 也早已被垃圾回收。这里没有“错误的提交”，因为代码从未改变 —— 改变的是模型，或者是检索到的文档，再或者是用户措辞的方式超出了所有人的预料。你回滚了部署，但部署从来都不是问题所在。

于是警报发出了，一名工程师接手了。他们发现了在生产环境中运行 Agent 最令人不安的事实：他们拿到手的是一个无法单步执行 (single-step) 的系统，而摆在他们眼前的运行手册 (runbook) 却是为另一种完全不同的机器编写的。

按 token 付费的心智模型训练了一代工程师，让他们认为 AI 成本是使用量的函数。没有请求，就没有账单。这是一个令人慰藉的模型，对于 API 调用本身而言，这基本属实。但它只描述了生产级 AI 功能的一个层面，而并非那个悄悄吞噬预算的层面。

预置吞吐量、预留 GPU 容量、预热向量索引以及待机微调端点都是按时长计费，而不是按计数器计费。无论流量是否到来，它们都为你提供服务流量的权利而收费。即便周六没人碰某个功能，计费表依然在转动。在办公时间内由 12 个人使用的内部工具，每周 168 小时都在计费。你为了 3 月份发布而准备的资源预置，在 5 月份流量洪峰平息很久之后，依然占据着预留额度。

这就是闲置成本。它之所以野蛮生长，原因并非技术层面，而是组织层面：没有一个单一的角色能看到它，也没有一个单一的角色负责它。

你公司最昂贵的评测集 (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 库积累了，机器人开始使用不同于团队验证时的模型，根据不同的准则来审查不同的代码库。团队对“机器人能捕获什么”的心理模型衰退成了“机器人上周捕获了什么”。