# 有 eval 才算交付

为什么我拒绝在没有 holdout evaluation set 的情况下交付一个 agent，怎样的 eval 才有用，以及当团队跳过这一步时我反复见到的 failure mode。

- **Author:** Fedor Chishchin
- **Published:** 2026-05-10
- **Tags:** agents, eval, methodology
- **Source:** https://fedorthinks.com/zh/blog/evals-or-it-didnt-ship

---

我在 AI 项目里见到的最常见的 failure mode 是这样的：团队交付了一个 demo，demo
在团队盯了好几周的那些输入上跑得好好的，然后没有人知道这套系统从六月到八月之间
到底是变好了还是变差了。

修复方法毫不光鲜：一个 holdout 的 evaluation set，在每次合并前都跑一遍，而 agent
在开发过程中从来见不到它。

## 「holdout」在实践中意味着什么

如果你写了这个 agent，同时又看过 eval 的输入，那这个 eval 就被污染了。prompt 调整
同理：我碰过的每一个 prompt 都见过 development split。holdout split 锁在版本控制里，
由 CI 读取，只有当分数变动到值得调查时才由人来检视。就这么简单。

## 什么样的 eval 才有用

三条性质，按重要性排序：

1. **它反映 production 流量。** 别人构建的某个巧妙 benchmark，对跨系统比较有用，
   但它说不清你的用户到底需要什么。从 production log 里挖、采样、匿名化、整理。
   每季度重复一次。
2. **它评的是你真会据此采取行动的东西。**「有用度 4.2/5」无法落地。「78% 的场景
   通过了结构化输出契约」才可以。
3. **它跑起来便宜。** 如果跑一次 eval 要六个小时，没人会在 PR 上跑它。目标是
   smoke set 五分钟、完整 set 一小时。

## 一套好 eval suite 的形态

两层：

- 一个小的 smoke set（约 30 个场景），在每个 PR 上跑。能尽早抓到 regression。
- 一个更大的 holdout set（约 300 个场景），每周在 main 上跑。这就是 agent 在开发
  过程中从来见不到的那一套。

公开 benchmark 应当摆在它们旁边，而不是取而代之——它们在和其他团队交流时有用，
但真正要紧的那份契约，是和你自己的 production 流量之间的那一份。

## 我不再接受的东西

「测试时看起来挺好」不是我会允许 agent 带着进 production 的状态。如果 eval 不
存在，agent 就不交付。如果 eval 分数 regression 了，在我们搞清楚原因之前，合并
就不会发生。

这听上去很苛刻，直到你眼睁睁看着一套系统因为没人在度量、在六个 sprint 里悄无声
息地一路退化。然后它就听上去理所当然了。