134 篇博文 含有标签「evals」

太平洋时间凌晨 2 点，你的评估套件（eval suite）在平静的提供商环境下全绿通过。上线前一晚 11 点，QA 进行了冒烟测试。功能正式发布。到了周二上午 10 点（东部时间），你的 p95 延迟比你签字认可的仪表盘高出了 40%，你的智能体（agent）在一个包含六步的计划中丢掉了最后一个工具调用，而你的支持信箱塞满了听起来如出一辙的工单：“今天早上 AI 表现很奇怪。” 谁都没错。模型也没错。错的是评估集 —— 它从未见过饱和的提供商环境，因此对于当队列深度翻倍、截止时间预算（deadline budget）崩溃时功能会如何表现，它无法给出任何参考建议。

提供商负载不仅仅是一个伴随质量副作用的延迟问题。它是你的模型和智能体循环接收到的输入的一种分布偏移（distribution shift），而你所信任的每一个质量信号，都是建立在这个分布中错误的那一截之上的。解决办法不是换一个更快的区域或更好的模型。解决办法是停止假装你的评估框架是在与你用户相同的世界中进行采样。

在某个周二，一个全新的可选参数被添加到了工具描述中。这个改动很小——在 diff 中只有六行代码，没有破坏性的签名变更，没有更新调用者，也没有触及任何评估用例。PR 描述写着“为现有搜索工具添加了可选的 language 过滤器支持”。两名评审员批准了，随后上线。

一周后，成本仪表板显示，搜索工具的调用频率比之前的基准线增加了 18%。受影响的 agent 延迟也以大致相同的比例攀升。没人能指出哪一个评估用例失败了。新参数在使用时表现正常；在不使用时，也无关紧要。然而，planner 显然改变了它对何时使用该工具的看法——而评估套件（用于衡量工具的“正确性”）对于工具“频率”的变化却无话可说。

打开过去六个月内发布的任何 AI 功能的系统提示词（System Prompt），将其与授权该功能的 PRD 并排阅读。你会发现这两个文档在互相争吵。PRD 写道：“助手应该是提供帮助且专业的，避免胡编乱造，如果无法回答则体面地拒绝。”系统提示词则写道：“你是一个 AI 助手。保持简洁。如果不确定，说‘我不知道’。绝不捏造事实。”PRD 占了一整页。提示词只有九行。它们之间的鸿沟就是你本季度发布的所有行为 Bug 的所在地。

这种便利的虚构说法认为，提示词只是 PRD 的“实现细节”。实际关系恰恰相反。提示词是模型执行的契约；而 PRD 是由一个从未编译过它的作者用模型听不懂的语言编写的契约草案。每一个 AI 功能的 PRD 都是一个未经测试的提示词。那些承认这一点并在签字确认前通过评估（Eval）运行 PRD 的团队，发布的功能会少一个上线后产生意外的根源。

上个季度评分 92% 的评估集（eval set）现在评分达到了 94%，团队称之为进步。事实并非如此。该评估集中的标签是根据标注员脑海中早已模糊的准则（rubric）编写的。模型评分所针对的产品已经发生了变化。标准已经发生了变化。标注员自身的校准（calibration）也发生了变化。表面上 2% 的提升，实则是静态产物与动态产品之间无声的差距，且只要团队不更新，这种差距每周都会扩大。

标注漂移（Annotation drift）是成熟 LLM 评估方案中一种隐蔽的失效模式。它不会表现为回归（regression）——回归是简单的情况，因为数值会下降，从而触发人员调查。它表现为一个持续显示绿色的数字，而其原本衡量的内容在底层已经腐烂。已经建立了评估集、编写了准则并招募了标注员的团队面临的风险最大，因为他们信任自己构建的系统，从而停止了对基础的审计。

这是一个尴尬的事实，大多数 AI 团队在发现时往往已经晚了半年：一个精心设计的评估（eval）用例所耗费的工程精力通常比它要测试的功能本身还要多。修改一次提示词（prompt）只需要一个下午。而让你确信这次修改没有破坏原有功能的评估用例，则需要领域专家进行为期两天的标注，一个与裁判提示词（judge prompt）的校准循环，以及一场关于“正确”在当前用户界面下究竟意味着什么的讨论。功能可以在一个 Sprint 内交付，而让你能够安全交付后续十个功能的评估体系则需要一个季度才能成熟。

这种不对称性并非缺陷。它是评估工作的结构性形态。标注、边缘情况的策划、裁判校准和评分标准设计都是前置的固定成本，它们不随你交付功能的多少而扩展，而是随你想要验证的不同行为（behaviors）数量而扩展。与此同时，功能开发端不断产生看似廉价的边际输出：“又一次提示词迭代”、“为智能体增加了一个工具”、“更换模型”。每一个改动看起来都很微小。但每一个改动都在无声无息地增加评估集必须覆盖的范围。

演示进行得非常完美。全场鼓掌。两周后，同样的功能出现在公司内部使用的 Slack 中，到了周三，一位高级工程师发布了截图，配文是“有人测试过这个吗？”到了周五，频道变得寂静无声 —— 并不是因为 Bug 被修复了，而是因为那些本来会指出问题的人已经放弃了，回到了旧的工作流。发布计划仍在日程表上。没有人取消它。没有人拥有取消它的政治资本。

这就是从演示到内部试用（dogfooding）之间的鸿沟。MIT NANDA 计划去年对其进行了衡量，比例高达 95% —— 即在企业级生成式 AI 试点项目中，有 95% 未能产生可衡量的损益（P&L）影响，而几乎所有这些项目都有一个令人心动的演示。模型本身不是问题。演示与内部使用第一周之间的差距才是问题，每个发布过 AI 功能的团队都曾目睹过类似情形的上演。

一名高管发了一封只有一行字的邮件：“好消息——我们在下个冲刺周增加视觉能力。”产品经理将其解读为一星期的工作量：更换模型、开放图像参数、发布。评估（Eval）团队读了同样的邮件，脑子里已经开始起草一份尚未获批的四周计划。到了周五，这种认知脱节在站会上表现为一句含糊的“我们需要做一些评估工作”，然后大家一致同意以后再解决。

这种在“我们添加了视觉能力”与“我们可以安全发布视觉能力”之间的鸿沟，就是评估补填税（Eval Backfill Tax）。每当新的模型能力落地时——多模态输入、工具使用、更长上下文、推理轨迹、电脑使用——这项工作就会悄无声息地落在评估团队身上。因为历史测试案例是在一个模型不会以这些新方式失败的体系下构建的。测试套件依然显示绿色，头条基准测试分数在上升，但生产环境的发布却暴露出了没人写过测试的失效模式。

我最近合作的一个团队失去了一位资深机器学习工程师。两周后，每个 PR 的评估套件（eval suite）依然全绿——847 个案例全部通过，裁判一致性（judge agreement）达到 92%。六周后，一位客户发现了一个回归问题，而这个问题本该被“支持质量”桶里的第一个评估案例捕获。当团队进行调试时，没人能解释为什么要写那个案例，它本该捕获哪种失败模式，或者为什么裁判提示词（judge prompt）是按 1–4 分评分而不是二元评分。那个案例依然通过了，但它并没有测试任何有人能说清楚的东西。

这就是评估的公交车系数（eval bus factor）：一种无声的失败模式。在这里，决定 AI 功能“正确”含义的人，也是策划测试用例、校准裁判模型并吸收了大脑中每一个隐含标注权衡的人。当他们离职时，评估套件虽然依然保持绿灯，但却不再能产生可靠的发布/拒绝信号——因为没有其他人能扩展它、调试不稳定的裁判，或评估新的失败模式是否属于测试集。

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

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

打开一个成熟的生产系统提示词（system prompt）并搜索“not”这个词。在一个已经发布了三个季度并经历过几次事故的功能中，你几乎总能发现一个看起来像“遗憾清单”的章节——“不要提供医疗建议，不要生成匹配这些模式的代码，不要使用这个正则表达式生成内容，不要冒充这些竞争对手，不要使用这些短语。”每一行都可以追溯到一起特定的事故。每一行都是由一位满怀信心地说“这能解决问题”的工程师添加的。而这个列表，每一个季度都像博物馆增加展品一样不断增长。

极少数团队会公开承认的是，这个列表——提示词中最具防御性、经过最仔细审查的部分——对于错误的读者来说，也是整个功能中最有用的产物。一个决意提取系统提示词的用户，现在拥有一份经过策划、组织良好且模型可读的清单，其中包含了团队所担心的所有行为。禁止列表就是一份食谱。而团队亲手编写了这本烹饪书。

一个团队将自我批判循环（self-critique loop）投入生产，因为基准测试数据看起来令人无法拒绝：Self-Refine 报告称在七项任务中平均提升了 20% 的绝对性能，Chain-of-Verification 在问答任务中将幻觉减少了 50% 到 70%，而在一篇被广泛引用的论文中，反思提示词（reflection prompts）将数学方程的准确率提高了 34.7%。一个月后，财务审查揭示了账单。产品的单次请求成本大约增加了三倍，p99 延迟增加了三倍，而实际在生产流量中表现出的质量提升更接近 3% 而非 30%。自我批判循环确实做到了它宣传的效果，只是团队从未计算过它的代价。

这就是自我批判税：一种在 PPT 上看起来像是免费提升质量，但在发票上却表现为结构性成本增加的可靠性模式。模式本身是合理的——在某些实际情况下，“生成并验证”确实是正确答案。失败的原因在于将其作为默认配置而非经过校准的干预手段进行部署，并在季度的错误时间点发现“模型检查自己的工作”实际上是一项采购决策。

六个月的绿色 CI 掩盖了一个事实：大约 40% 的评估集（eval set）已不再代表用户在产品中的实际行为。测试套件仍在运行，裁判（judge）仍在打分，仪表盘依然闪烁着绿光。但这些案例是针对查询分布、语料库、工具界面和监管文本编写的，而这些内容早已发生了变化——现在的绿色运行意味着“昨天的产品在昨天的现实中依然有效”，而这并不是你付费让 CI 回答的问题。

这就是“快照评估退化”（snapshot eval decay），它是 AI 评估中最缓慢、最昂贵的失败模式。说它缓慢，是因为套件从未失败——陈旧性表现为无法区分模型优劣，而不是构建变红。说它昂贵，是因为当有人意识到评估通过的模型切换导致了生产环境回归时，团队已经建立了一年之久的“评估通过即发布”的肌肉记忆，而这一记忆是建立在一个早已悄然失效的资产之上的。