143 篇博文 含有标签「evals」

当你团队中的初级工程师第一次输入 --update-snapshots 并推送到 main 分支时，你的测试套件就不再是测试套件了，它变成了一份记录稿。虽然 Diff 依然显示为红绿颜色，CI 徽章依然会变为通过，但信号已经悄然反转：测试套件不再告诉你代码是否正确，而是告诉你是否有人费心看过输出。对于确定性的代码，这种风险尚在可接受范围内，因为大多数 Diff 确实是符合预期的。但当网络调用的另一端是一个随机模型时，同样的流程会让每一个 PR 变成一场硬币投掷，让每一位评审者变成一个橡皮图章。

快照测试曾是确定性世界里的一个美妙构想。你记录下上周二 render(<Button />) 的生成结果，断言本周二它会生成相同的字符串。从定义上讲，任何 Diff 都是值得人工核查的行为变更。这种模式在 Jest、Vitest、Pytest、整个 React 生态系统以及一代又一代的 UI 快照扩展中得以幸存，是因为底层契约依然成立：相同的输入加上相同的代码等于相同的输出。但这个契约对 LLM 调用并不奏效。相同的输入、相同的代码加上相同的提示词（Prompt），却会产生不同的字符串——而且这种差异并非 Bug，而是产品按设计正常运行的结果。

在你的 AI 团队中，被低估最严重的资产是每周一小时，由三个人坐在房间里阅读你的产品实际对用户说了什么。不是综合评分。不是移动平均值。不是仪表盘。而是实际的对话记录。逐字逐句的输出。模型悄然形成的懒散措辞。你的分类体系中未涵盖的意图。用户尝试了三次，用三种不同的方式表达需求，而你的评估准则（eval rubric）却将这三次对话都评为“满意”。

将这一小时制度化的团队，能够建立起仪表盘永远无法呈现的 AI 功能心理模型。跳过这一步的团队，会根据看起来不错的指标发布六个月的产品，然后在下一次季度业务回顾（QBR）中发现，在无人察觉时，中位数体验已经漂移到了令人遗憾的境地。

智能体最糟糕的两种失败模式看起来截然相反，但它们其实源于同一种失效的策略（Policy）。第一种智能体在执行任何操作前都会先问四个后续问题，这让它的用户因为繁琐而最终放弃使用。第二种智能体从不提问，它自信地生成用户不得不推倒重做的输出，这让它的用户对其产生不信任感。同样的策略，只是一个缺失参数的不同设置：即提问的成本相对于错误答案成本的比例。

大多数智能体根本没有任何策略。模型只是被要求“提供帮助”，然后被留下来独自应对模糊性。因为下一个 Token 预测（next-token prediction）机制奖励对答案的确定性，所以智能体倾向于猜测。又因为 RLHF 奖励礼貌，智能体偶尔会为了安全而过度纠偏并提出问题。其结果就是一种毫无原则的行为，这种行为在不同会话之间波动不定，团队层面也无法直观地判断智能体何时会暂停、何时会盲目推进。

澄清预算（Clarification budget）正是那个缺失的参数。它是针对每个任务制定的、允许智能体施加摩擦力的配额，并配有一套判断何时值得花费预算去提问的决策规则。你可以把它看作是对话领域的“延迟预算（latency budget）”——每个产品都有一个，即使没人把它写下来；而那些把它写下来的团队，就能停止交付那种让人困惑的智能体。

许多自称“有评估（evals）”的团队，其实际情况是：有一个仪表板，某人每周运行一次测试套件，然后将数据粘贴到没人看的 Slack 频道。评审人员批准提示词（prompt）更改时，甚至根本没看过它是否影响了测试套件，而回归问题（regression）两周后才在客户反馈单中显现。评估确实存在，但评估并未进入开发循环。

解决办法在于结构，而非意愿。只有当评估存在于变更发生的地方——即 Pull Request（PR）评论中，紧挨着代码差异（diff），并带有单个 PR 的增量变化和评审员无法忽视的回归提醒时，评估才能真正起到质量把关的作用。在其他任何地方，它们都只是表演性的产物：投入了大量精力构建，却什么也拦截不到。

“先创建后通知”的序列在开发阶段运行良好。而“先通知后创建”的序列则会为一个尚不存在的实体触发 webhook，导致消费者返回 404，接着你的团队会花上一周时间来调试这个看起来像是不稳定的集成测试。这种不稳定并非随机。它是确定性的，源于你的工具集拥有而你的规划器（planner）却不知晓的隐藏排序不变性。

这就是生产环境中 Agent 工具调用排序 bug 的常见形态：工具集在底层以偏序（partial order）方式组合——某些操作必须先于其他操作执行，而另一些则可以按任意顺序运行——但在规划器看来，它们只是一个无序的能力集合。模型选择了一个昨天行之有效的顺序。而明天，一次提示词修改、模型升级，甚至只是不同的 temperature 采样，都会选出另一个顺序。对于阅读追踪记录（trace）的人来说，这两种顺序看起来都很合理。但其中只有一个是正确的。

如果不声明顺序，团队交付的就是一个最终会被模型的提示词敏感性（prompt sensitivity）触发的 bug 隐患。

在 AI 工程领域流传着一个隐秘的神话：模型的一次“小幅”升级——比如 claude-x.6 到 claude-x.7，或者 gpt-y.0 到 gpt-y.1，甚至是按日期推进的补丁级快照更新——都应该是无缝替换的。厂商发布的更新日志里谈论着推理能力的提升、更低的延迟以及更好的工具调用。版本号轻轻跳动，没有任何迹象表明这些改动会破坏现有系统。

然后更新上线了。值班频道随即被各种警报点亮：摘要生成器莫名其妙多出了一段以前没有的话；JSON 提取器开始对以前不处理的 Unicode 字符进行转义；Agent 循环在以前只需三次调用就能完成的任务上，现在却触碰到了最大步数限制。从整体上看，评估得分似乎没什么问题，但用户可见的功能却在细微之处出了错。

浏览任何成熟工程团队的 PR 队列，你都会看到同样的现象：一个四行的 Bug 修复会引来三轮关于命名、错误处理和测试覆盖率缺失的评论；而对系统提示词（System Prompt）的四十行修改却能凭借一句 “LGTM, ship it” 轻松过关。作者对此不以为意，因为差异对比（diff）看起来就像文档；审查者也无所谓，因为他们对于那段英文块中什么是“好”没有心理模型。结果是，一个具有功能发布级别影响范围的提示词更改，却仅以修复拼写错误的门槛通过了审查。

这是每个在生产环境中使用 LLM 构建产品的团队所面临的隐秘质量危机。代码库拥有数十年积累的纪律——Linter、类型检查、代码所有者（Code Owners）、测试关卡、发布窗口。而真正引导模型的产物——系统提示词、评估准则（Eval Rubric）、工具描述、少样本示例（Few-shot Exemplars）——虽然存放在同一个仓库中，却通过为英文散文设计的审查流程进行发布。因此，提示词回归、评估准则漂移和工具模式（Schema）损坏，却能以团队永远不会接受的代码质量标准通过。

公平性审计曾是发布流水线中的一个绿色对勾。合规团队在 3 月签署通过了它。支持工单从 10 月开始涌现——来自一个模型从未被评估过的国家的的一组用户，得到的答案效用远低于其他人。模型本身没有任何改变。审计对模型的判断从未出错。它错在对世界的判断。

这是一个没人愿意大声说出来的失败模式：静态偏差评估只是已经发生漂移的数据流中公平性的一个快照。评估在运行时并没有撒谎。它告诉你的是一个关于不再存在的分布的真实情况。等到支持团队积攒了足够的工单并归纳出模式时，模型对该群体的处理不公已经持续了两个季度，而审计报告已经过时一年了。

你的 AI 路线图的瓶颈不是 GPU 容量、模型可用性或 Prompt 工程的品味。它是那一两个真正懂得如何构建能发现回归（regression）的评估（eval）的工程师的日程表。每个负责功能的产品经理都在他们的队列中。每一次模型升级都在他们的队列中。每一次群体漂移、每一次 Prompt 修改、每一个“这个评审模型（judge）是否仍然校准”的问题，最终都会进入同一个收件箱。而这位工程师在本季度已经说了三次“不，这还没准备好”，两次被否决，眼睁睁看着回归在生产环境中复合增长，现在正在更新他们的 LinkedIn。

这就是评估瓶颈，大多数组织在被咬到之前都意识不到它的存在。到 2025 年为止，显而易见的工作重点是 AI 工程师——招聘 AI 工程师、发布 AI 功能、迭代 Prompt、更换模型。到了 2026 年第一季度，吞吐量问题下移了一层。将 AI 团队人数翻倍的团队发现，增加更多功能工程师并没有让功能发布得更快，因为每个功能仍然需要一个评估（eval），而负责评估的工程师还是那个人。

我曾合作过的一个团队拥有一套看起来很清爽的评估门禁（eval gate）：每个 prompt PR 都必须在黄金测试集（golden set）上获得 0.85 以上的评分，否则合并按钮就会保持灰色。他们为此感到自豪。但在六周后，平均质量已从 0.93 悄然滑落至 0.87 —— 每个 PR 都通过了门槛，每个 PR 都成功上线，而且没有任何一个改动需要为这种质量回退负责，因为它们都没有违反规则。这个门槛是根据上个季度的质量快照设定的，而不是根据上周的质量。

这就是绝对阈值评估门禁的失效模式：一个将评分从 0.92 降低到 0.86 的 PR 可以绿灯通过，而一个将评分从 0.80 提升到 0.84 的 PR 却会被挡在门外。团队学到的是“只要过线就能发布” —— 这是一个关于质量的故事。但你真正需要的信号是“如果这个改动在重要的切片（slices）上没有发生回退就发布” —— 这是一个关于回退检测的故事。

测试覆盖率工具在十年前就解决了这个问题。它们报告相对于父提交（parent commit）的差异，并将其细化到每个文件。评估门禁还没赶上这个进度。

在 1 月下旬的一个周一早上，仪表盘发出了第一次回归预警。支持助手的质量得分一夜之间下降了 3 分。周末没有发布 Prompt 变更。没有更换模型。评估套件——团队在 6 个月前构建的一个包含 800 行数据的精选黄金集 (gold set)——也没有任何变化。有人开了一个故障单 (incident)。

经过两天的二分定位 (bisecting) 之后，得到的答案平淡无奇且是结构性的。那是美国国税局 (IRS) 开启当年税务申报后的第一个工作周一。一半的入站查询已从“我的薪水到账了吗”变成了“我该如何申报来自支付 App 的 1099-K 表单”。在夏季采样的评估集对 1099-K 毫无头绪。模型并没有变差。是客户变了。评估标准是针对一个已经不存在的客户群进行校准的。

这种模式在每一个拥有季节性用户的产品中每季度都会重复出现——报税季的金融科技、季度末的销售工具、开学季的教育产品、退货季的电子商务、订票季的旅游产品、投保季的医疗保健。将“评估集视为固定资产”是一种舒适的抽象，但在一个无人更新的日程表上，这种做法是错误的。

我上个季度合作的一个团队在周二凌晨 2:14 向生产环境推送了一个回归错误。值班警报触发了，因为其摘要代理（summarization agent）下游的 JSON 解析器以“尾随逗号错误”拒绝了二十分之一的响应。模型没变。提示词（prompt）没变。评估套件在前一天晚上的通过率为 96.4%，稳稳高于 95% 的准入门槛。改变的只是 package.json 中的一行：模型提供商的 SDK 从 4.6.2 升级到了 4.6.3。补丁更新（Patch bump）。由依赖机器人自动合并。发布说明里写着“内部清理”。

所谓的“内部清理”是一个收紧的 JSON 模式解析器，它删除了一个宽容的后备路径，而这个路径此前一直在默默修复模型工具调用输出中反复出现的尾随逗号怪癖。模型的行为没有改变。但 SDK 对该行为的解释改变了。团队的评估套件从未发现这个回归，因为评估套件运行的 SDK 版本与依赖机器人刚刚推送的版本不同。

这就是 LLM SDK 升级税，它是当今生产环境 AI 中最隐蔽、代价最昂贵的故障模式之一。SDK 不是被动的传输工具。它是你提示词行为的积极参与者，而那些在没有评估的情况下升级 SDK 的团队，实际上是在进行一场伪装的模型发布。