有 eval 才算交付

我在 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 里悄无声 息地一路退化。然后它就听上去理所当然了。