AI 产品为什么需要一架 eval 梯子，而不是一张总分表

很多 AI 产品在 demo 阶段很好看，上线后却不稳定。团队知道模型会犯错，却说不清应该测什么、何时能发布、版本升级后有没有退步。

问题往往不在于“没有测”，而在于所有问题都被塞进了同一种测试。

Madhu Guru 的完整观点

Meta AI 产品负责人 Madhu Guru 认为，企业做不好 AI 系统，一个主要原因是没有 eval strategy。每个产品都需要针对自己的使用场景建立一套分层 eval，在成本和真实性之间形成梯度。

她给出了四层：

1. Hill-climb long evals：持续推高产品上限，随着能力提升不断更新，用来改善质量、扩展功能边界。
2. Regression evals：检查团队向上爬时，有没有破坏今天已经能工作的产品。
3. Smoke test evals：守住安全、产品身份和绝对不能错的基本行为。题目不一定难，但失败代价很高。
4. Launch evals：尽量接近真实流量的在线测试，控制较少，却最接近用户实际使用。

查看 Madhu Guru 的原始动态

Matrix 的判断

Eval 不应该只是模型团队交付的一张成绩单，它更像 AI 产品的运行系统。

四层 eval 回答的是四个不同问题：我们还能做到什么、原有能力有没有坏、底线有没有失守、真实用户是否真的受益。把它们压成一个总分，团队就会用平均值掩盖严重失败，也会为了稳定而停止探索。

更重要的是，eval 不是上线前的一次考试。线上失败会改变 failure taxonomy，新模型会改变原有 prompt 和工具调用表现，用户也会把产品用到设计者没想过的地方。Eval 必须随产品一起生长。

一个最小可用的 eval 体系

不用先做一个大平台。可以从四个小集合开始：10 条绝不能错的 smoke case、30 条当前高频任务的 regression case、10 条团队暂时做不好的 frontier case，以及一小部分真实用户灰度流量。

每次版本变化后同时回答四件事：底线是否守住、旧能力是否退步、上限是否提高、真实任务是否更好。只有这样，“模型更强了”才会被翻译成“产品对用户更可靠了”。