160 篇博文 含有标签「evaluation」

你的智能体仪表盘显示任务完成率为 94%。领导层很满意。路线图获得了资金支持。然而，支持工单却在不断增加，核心用户变得沉默寡言，而那个负责观察追踪记录（traces）的工程师则一直在嘀咕情况不对劲。这两件事同时都是事实：智能体确实在完成任务；但它也为了完成一个两步就能搞定的工作，耗费了 12 分钟和 4000 个 token，反复回溯了三次，并要求用户确认一个它本可以从第一条消息中推断出来的实情。

任务完成率是一个隐藏了分布情况的二元指标。“智能体完成了任务”并不能告诉你它达成目标所走的路径，而路径才是用户实际体验的核心。完成率仪表盘在结构上无法察觉到一个缓慢、昂贵且令人恼火的智能体。它会一直保持绿色，直到用户流失。

这并不是一个可以通过更好的提示词来修补的测量差距，而是你选择测量什么而导致的“范畴错误”。完成率是最容易衡量的指标，但却是人们付费买单中最微不足道的部分。

AI 领域的每个人都知道基准测试污染（benchmark contamination）的警示故事：模型厂商抓取公开网络，GSM8K 和 MMLU 最终出现在预训练语料库中，导致报告的分数衡量的是召回而非推理。这通常被视为别人的过错——是基础模型实验室的问题，是你继承下来的瑕疵。因此，你构建了自己的留存评估集，将其存放在私有仓库中，并认为自己是清白的。

你可能并不清白。在生产级 AI 系统中，最具破坏性的污染很少是继承来的，而是由心怀好意的工程师遵循看似合理的流程在内部制造出来的。你的评估集通过你自己建造的大门泄露到了训练流水线中，而且这种泄露是无声的：就在你的基准测试停止衡量任何真实事物的瞬间，每个仪表盘都会变成绿色。

这就是你亲手造成的污染。它比你继承的那种污染更值得关注，因为你是唯一能够检测到它的人——而几乎没有人会为此进行审计。

财务团队指出，本季度的 LLM 账单上涨了 18%。一名工程师调出使用情况仪表板，发现 70% 的流量现在流向了经济型模型（budget model）而非前沿模型（frontier model），他感到有些困惑：路由更改本应是为了削减开支。每 token 价格确实如电子表格预测的那样下降了。但账单还是上涨了。

这不是计费错误。这是成本优化在悄无声息中发生逆转的最常见方式。证明降级合理的电子表格衡量的是一件事——token——而生产系统支付的是完全不同的另一件事：完成的任务。较弱的模型不仅仅是产生更便宜的 token。它还会改变其周围每个组件的行为，而这些二阶效应最终都会反映在同一张发票上。

这个陷阱非常诱人，因为一阶数学逻辑确实是正确的。经济型模型的每 token 价格可能比前沿模型便宜 10 到 30 倍，且对于大部分流量，它返回的答案在质量上是难以区分的。错误不在于路由决策。错误在于在错误的边界衡量路由决策。

AI 功能的上线决策会议（go/no-go meeting）表面上是一个数据驱动的仪式。工程团队会带来一系列评估数字——评测专家分数变化（judge score deltas）、切片准确率（slice accuracies）、相对于基线的回归百分比（regression-against-baseline percentages）——然后由与会者做出决定。这看起来非常严谨。但通常并非如此。

一句话概括这种失败模式：有能力解读评估切片权重的人没有决策权，而有决策权的人看不懂切片。产品经理（PM）主导发布决策。工程师掌握数字背后的含义。在这两者之间存在着翻译鸿沟，谁在会议上表现得最自信，谁就能填补这个鸿沟。

问题的征兆在于，“87% 准确率就发布”和“87% 准确率不发布”都可以基于同一份评分卡找到依据，这取决于你更看重哪个切片。当同一份数据集支持截然相反的结论，且决定性因素是辞令上的自信而非证据时，你拥有的就不是一个数据驱动的流程，而是一场以电子表格为背景的辩论。

一个工程师花了一个下午钻研一个问题：智能体 (agent) 能否根据合同条款核对客户的发票？他们编写了一个简单的提示词，在五份真实发票上运行，结果三份是正确的。另外两份的错误方式他们还没完全搞清楚——于是他们关上电脑，继续做别的事。在第二天早上的站会上，他们说：“是的，发票核对基本上能用了。”房间里的 PM 记下了这一点。两周后，它成了 Q3 路线图上的一个项目。一个月后，一位销售代表在续约电话中向一家大客户承诺了这项功能。

没有人撒谎。没有人孤立地做出错误决定。但团队现在已经在合同上承诺了一种行为，而这种行为的评估集 (eval set) 并不存在，其失败模式从未被记录，其可靠性预算是由一位看了演示并将其解读为正式合同的总监设定的。这是 AI 功能获取范围 (scope) 最常见的方式：不是通过规划会议，而是通过一个从未被明确提升地位的能力探索 (capability probe)。

行业对这种下游症状有一个称呼——“POC 炼狱” (POC purgatory)，即 70% 到 80% 的 AI 项目在可运行的沙盒和可交付的产品之间停滞不前的状态。但“炼狱”是一个错误的比喻，因为它暗示项目被困住了。它们并没有被困住。它们在移动——在有人检查它们是否准备好之前，它们就被承诺了，现在团队正试图将可靠性强行填补到一个承诺中。

你的 AI 团队所谓的“评估集”（eval set），在大多数发布 LLM 功能的公司中，其实是从生产日志中提取的真实客户对话集合。团队中没有人认为这是一个隐私事件。数据从未离开过集群。没有配置新系统。没有增加供应商。一名工程师写了一个查询，将几千条追踪记录（traces）导出到标注工具中，然后团队就开始根据这些记录对模型输出进行评分。法律团队从未听说过这件事，因为从内部来看，什么都没有改变——原本就存在于同一个数据库中的对话，现在只是被几名工程师和一个裁判模型（judge model）读取了而已。

这就是那个无人审查的隐私边界。客户向你发送消息是为了让你回答他们。他们并不是为了让你拿这些消息去衡量模型才把消息给你的。这两种用途在存储层看起来完全一样，在推理层感觉也一样，但在每一种现代隐私监管制度下，它们属于不同的处理目的——而两者之间的鸿沟，正是下一轮合规阵痛将要降临的地方。

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

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

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

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

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

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

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

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

每个智能体（agent）功能都有一个“后门”。有的团队称之为“转人工支持”，有的称之为“路由至人工审核员”，还有的则使用模板化的回复：“我无法处理此事——让我为你联系能提供帮助的人。”无论标签是什么，每个生产环境中的智能体都有一条放弃用户请求并将其移交给人工的路径。而生产流量采取该路径的比例，是少数几个不依赖标注员、评审员或手动构建测试集的信号之一。这是系统在生产环境中告诉你，模型无法处理用户实际发送的请求。

这个信号几乎总是被错误的团队读取。在大多数公司中，转人工率（Escalation rate）是一个劳动力规划指标：它决定了下一季度排队系统需要多少人工客服。它存在于运营团队审查的仪表板上，其审查频率与 AI 团队读取评估分数（eval scores）的频率完全不同。30% 的周环比转人工增长在周一的运营审查中表现为一个人员配备问题，而 AI 团队的评估套件依然显示绿色，领导层的报告也显示功能状态良好。两个团队看着同一个生产系统，却得出了截然相反的结论：运营团队认为他们需要更多人手，而 AI 团队认为模型运行良好。

我上季度合作的一个团队针对其支持智能体（support agent）运行了一套包含 240 个案例的评估集。连续六个月，测试结果全线飘绿。接着，他们更换了规划器提示词（planner prompt）中的一个句子——仅仅是一次语气调整——结果第二天生产环境的人工接管请求激增了 3 倍。而评估分数却纹丝不动。人工接管分支仅仅是开始在以往能在线解决的临界案例上触发，而评估集中没有一个案例属于这种临界类型。该分支存在于提示词中，存在于生产环境中，唯独不存在于评估集中。

这就是我想命名的失败模式：智能体分支覆盖率 (agent branch coverage)。代码覆盖率工具在过去的 40 年里一直是调试的基础，但智能体系统具有运行时控制流——规划器分支会选择工具、限定回复条件、升级到人工、拒绝执行、或尝试不同的策略重试——而评估集仅触及团队想到的那些案例。规划器 80% 的决策分支从未在测试下执行，于是，一份“全绿”的评估报告就成了一场披着回归测试外衣的冒烟测试。