AI评估的本质：谁来定义"好"的标准

你们的团队上线了一个 AI 功能。那是一个周二，一切都很顺利。

六周后，Sales 的人说功能变差了。你找到工程团队，工程团队说他们那边什么都没改，而且他们说的是实话。你要看数据，有数据，但没有一条能回答这个问题。现在你被困在一场讨论功能是否变差了的会议里，没有办法得出结论，而且这个会下个月还会再开一次。

这场会议，就是 AI Evals 存在要防止的东西。而大多数团队没有 AI Evals 的原因，不在技术层面。

AI Eval 到底是什么

剥离开工具层面的东西，一个 Eval 就是三件事：

一组真实用户在你们产品上提问的样例。 对每个样例，什么是一个好答案的书面描述。 一个可重复的方式，用来检查你得到的答案是否符合描述。

就这么简单。其他的都是工程细节。有很多好的框架来做这个工程细节，deepeval 就是其中之一，选一个框架确实是最简单的部分。

难的部分是中间那个——得有人把"什么是好的"写下来，而这并不是一份工程文档。

Eval 里的四个决策，都是产品决策

什么算正确。 一个 Agent 准确回答了一个账单问题，但态度冷淡，而客户已经投诉过两次了。正确吗？这没有技术答案。只有产品答案，而如果没人给出答案，写检查逻辑的工程师会意外地自己填补一个。

一次失败要付出什么代价。 语气不对和退款金额不对，这不是同一种失败，它们不应该用同一个通过标准来衡量。得有人来说清楚每种错误会让业务付出什么代价。写测试的人不是做这个决定的人。

你在做哪种权衡。 每个 Eval 标准都是一种交易——得到什么，牺牲什么。把拒绝率往下压，你会得到更有用的答案，但也会得到更多错误答案。往上升则相反。这是一个披着百分比外衣的定位决策。

什么时候算可以发布了。 这个大家都会同意是产品决策，直到它变成仪表盘里的一个数字——然后它悄悄地变成了建仪表盘那个人的决策。

四个决策。无论有没有人主动做决定，这四个决定都会被做出来。这才是真正的风险：不是团队跳过了 Evals，而是团队做了 Evals，但里面的产品判断默认落在了文件最后打开的人身上。

产品拥有定义，工程拥有机制

在实践中，这意味着 PM 在任何东西做出来之前，用叙述性的文字写出"好的标准是什么"。不是功能的规格说明，而是一个答案的描述，要具体到两个人读它时对同一个输出给出相同的评分。如果你的两个同事读了你的定义后对某个答案是否通过意见不一致，那说明定义还没完成，而下游再多的工程工作也救不了它。

然后工程让它每天晚上跑起来。

这个分工听起来不光鲜，但它就是全部了。长期保持质量的团队，不是那些有最好框架的团队，而是有一个具名的人来对"什么是正确"这句话负责的团队，而且这个人是在产品侧的。

Evals 不会告诉你产品做得好。它只告诉你产品有没有变化，以及两个版本在你决定要测量的方面哪个更好。任何你没想过要描述的东西，对它们来说永远是看不见的。

这说明了一个道理：早点写出哪怕不完美的定义，也好过永远写不出完美的定义。前二十个定义比框架更有价值，而且你这周就能写出来，不需要找工程团队要任何东西。

所有这些所归属的更大的学科叫做 Harness Engineering。但决定它对你是否有用的部分不在工具里。是在产品侧愿意写出"什么是好的"并为之负责的那个人。