假设排行榜告诉我：

模型 A 的能力是 95 分。

于是我把它接进一个 AI 客服系统。

结果真正上线以后却发现：

用户问退款，它经常错误调用“查询物流”；

用户问会员权益，它检索出过期资料；

需要查询订单时，它偶尔忘记调用数据库；

回答虽然看起来很自然，但会编造不存在的优惠政策。

这时候你会发现：

模型本身的 95 分，已经没有那么重要了。

因为用户用的不是“模型”。

用户用的是：

Prompt + RAG + Router + Tool + LLM + Agent + 一整套业务逻辑。

AI Engineer World's Fair 2024 的《LLM Evals That Work IRL》就专门强调了这个区别：

Model Benchmark 和 Application Eval 不是一回事。

模型 Benchmark 可以告诉你一个模型大致有多强，但真正做产品时，需要知道整个应用有没有完成自己的任务。

所以我现在更愿意把 Evals 理解成：

AI 产品的测试系统。

传统软件开发有 Unit Test、Integration Test。

AI 产品同样需要测试。

只不过 AI 最大的麻烦在于：

它的答案不是固定的。

传统程序很好测试。

比如：

1 + 1

正确答案只能是：

2

所以测试程序可以直接写：

输出 == 2

通过就是通过，失败就是失败。

但现在换成一个 AI：

请礼貌地拒绝用户的退款请求，并解释原因。

模型可能回答：

“非常抱歉，根据我们的退款政策……”

也可能回答：

“很遗憾，目前该订单已经超过退款期限……”

甚至还可能有第三种、第四种完全不同的表达。

它们文字完全不同，却都可能是正确答案。

于是以前那种：

Expected Output = Actual Output

的测试方式就不够用了。

我们需要判断：

这个回答是不是礼貌？

有没有解释原因？

有没有违反退款政策？

有没有编造信息？

有没有解决用户的问题？

这就是 Evals 开始出现的地方。

AI Engineer 的《Evals 101》给了一个非常好理解的结构：

一个 Eval 最基本就是：

Task + Dataset + Scorer

也就是：

任务 + 测试题 + 评分方法。

举个例子。

我要测试一个 AI 客服。

Task

让 AI 回答：

我的订单已经发货了，我现在还能修改地址吗？

Dataset

我准备 100 个真实用户曾经问过的问题：

退款；

修改地址；

物流；

优惠券；

会员；

发票；

售后……

这 100 道题就是我的测试集。

Scorer

然后我要规定：

什么叫回答得好？

比如：

政策正确性       40%
问题是否解决     30%
是否出现幻觉     20%
表达是否清晰     10%

跑完之后，我可能发现：

版本 A：83 分
版本 B：91 分

于是我终于可以比较：

我这次改 Prompt，到底是真的变好了，还是只是我感觉变好了。

这就是 Eval 最朴素的意义。

这是我认为理解 Evals 最关键的地方。

很多 AI 产品最早的开发过程其实是这样的：

改一下 Prompt。

跑一次。

看起来不错。

再改一下。

再问几个问题。

“好像比刚才好了。”

继续上线。

这个过程有一个非常形象的名字：

Vibe Check。

也就是：

凭感觉检查。

早期做 Demo，这完全没问题。

但真正开始做产品以后，问题就出现了。

假设昨天：

System Prompt v17

今天改成：

System Prompt v18

你怎么知道它真的更好了？

也许它解决了一个问题，却制造了另外三个问题。

比如：

以前回答太啰嗦。

你把 Prompt 改得更简洁。

现在回答确实短了。

但它开始漏掉重要信息。

如果没有 Eval，你可能根本不会发现。

所以 Hamel Husain 在 AI Engineer World's Fair 的分享里非常强调一件事情：

当一个团队已经无法判断自己的修改到底是在进步还是退步时，就需要建立 Evaluation Workflow。

于是开发流程从：

修改
↓
看起来不错
↓
上线

变成：

修改
↓
跑 Evals
↓
比较结果
↓
发现失败案例
↓
继续修改
↓
再次 Eval

这才开始形成真正的工程闭环。

这马上又会产生一个问题。

数学题很好办。

答案是 42。

不是 42 就错了。

但：

“这篇文章总结得好不好？”

“这个客服回答够不够礼貌？”

“这个研究报告有没有真正回答问题？”

谁来判断？

目前常见的办法大概有三种。

第一种：代码直接判断

能确定的东西，尽量不要交给 AI。

比如要求返回 JSON：

{
  "model": "gpt-5",
  "reason": "complex reasoning"
}

那完全可以直接检查：

字段有没有缺失；

JSON 能不能解析；

model 是否属于允许模型；

响应时间有没有超过 3 秒。

这种 Eval 最稳定。

第二种：人工评价

比如请真正的客服专家判断：

这个回答到底符不符合公司政策。

人的判断通常非常重要。

因为很多时候：

连开发者自己一开始都不知道“好答案”到底应该是什么。

看了大量真实案例以后，标准才慢慢形成。

所以高质量 Eval 往往离不开领域专家。

第三种：LLM-as-a-Judge

这是现在非常有意思的一种方法。

既然人不可能每天检查几十万条 AI 输出，那能不能：

让另一个 LLM 来给这个 LLM 打分？

可以。

例如：

AI A 回答了一段内容。

然后把：

问题 + 标准答案 + AI A 的回答 + 评分规则

一起交给 AI B。

要求：

请从以下三个维度评分：

事实准确性：0-5
完整性：0-5
表达质量：0-5

AI B 就变成了：

Judge。

也就是“裁判模型”。

这就是所谓的：

LLM-as-a-Judge。

2023 年的 G-Eval 就系统研究了这种思路。论文使用 GPT-4 按照明确的评价步骤和标准判断生成文本，在摘要任务中，与人工评价取得了比此前多种自动指标更高的相关性。

不过这里千万不能得出一个错误结论：

“既然可以让 AI 判断 AI，那以后就完全不用人了。”

并不是。

LLM Judge 自己同样会犯错，而且可能存在偏好和偏差。

所以真正好的 Eval 系统往往是：

Code + LLM Judge + Human Review

三者组合。

拿我们之前聊过的 RAG 来看，就特别容易理解。

用户问：

公司今年的营业收入是多少？

RAG 系统首先从公司财报里检索资料，然后让 LLM 根据资料回答。

最后 AI 回答：

公司今年营业收入为 128 亿元。

那这个系统到底表现得好不好？

只看最终答案是不够的。

至少有三个问题。

1. 检索出来的资料对不对？

如果正确财报段落根本没被找到：

RAG 检索失败。

2. 模型有没有忠于资料？

资料明明写的是 128 亿；

模型却回答 182 亿：

生成失败。

3. 最后的答案有没有真正回答问题？

即使资料正确、数字正确，但回答了一大堆无关内容：

答案质量依然不好。

RAGAS 这篇很有代表性的论文，就是在解决这种问题。

它把 RAG 拆成多个评价维度，比如检索上下文的相关程度、回答是否忠于检索内容，以及最终答案的质量。

也就是说：

不要只给整个系统打一个总分，要知道到底是哪一个环节出了问题。

这件事情非常重要。

因为 AI 产品越来越复杂以后：

“答案错了”已经不是一个足够有用的信息。

我们真正想知道的是：

错在哪里。

Router 更是如此。

比如一个 Router 收到：

帮我解释一下什么是 Redis。

它选择了一个便宜的小模型。

回答很好。

这是一次成功路由。

然后用户问：

帮我分析下面这个复杂数学证明有没有问题。

Router 仍然把它交给那个小模型。

模型胡说八道。

这就是一次失败路由。

所以评价 Router，不能只问：

最终答案好不好？

还应该问：

Router 当时的决策到底对不对？

AI Engineer 的《LLM Evals That Work IRL》甚至专门提出：

Evaluate the route before the response。

也就是：

先评价路由决策，再评价最终回答。

例如我们可以记录：

1000 个真实问题跑完以后：

Route Accuracy = 87%

现在 Router 才第一次真正拥有一个：

可以优化的数字。

否则所谓：

“我们的 Router 会智能选择模型。”

很可能只是一个 Demo。

这几个东西很容易混在一起。

其实可以把它们想象成一次考试。

Benchmark：试卷

RouterBench、MMLU 之类的东西，本质上是在提供一套相对标准化的测试题。

Eval：考试过程

拿这些题去跑你的模型或者系统，并判断表现如何。

Metric：每一个具体成绩

例如：

Accuracy = 92%
Latency = 1.2 秒
Cost = $0.003
Hallucination Rate = 2.1%

这些都是 Metric。

Reward：你最终希望系统优化什么

例如：

其中：

• Q = Quality
• C = Cost
• L = Latency

Eval 帮你测出 Quality、Cost、Latency。

Reward 再告诉系统：

这些东西到底应该怎么权衡。

所以可以非常粗略地记成一句：

Benchmark 出题，Eval 考试，Metric 出成绩，Reward 决定什么成绩最重要。

这样它们就不会再混了。

如果 Evals 只是上线前考一次试，其实也没那么有意思。

真正重要的是：

它可以把生产环境里的失败不断变成新的测试题。

比如今天有个用户问：

我的年费会员是在英国购买的，现在回中国还能继续使用吗？

AI 回答错了。

传统做法是：

修掉这个 Bug。

结束。

Eval 思维则是：

第一步

把这次真实失败保存下来。

第二步

加入 Eval Dataset。

于是：

测试题数量：
1000 → 1001

第三步

修改 Prompt / RAG / Router。

第四步

重新跑全部 1001 道题。

不仅检查：

刚才那道题修好了吗？

还检查：

你有没有因为修这道题，把以前正确的东西搞坏。

这就是 Regression Eval。

以后生产环境又发现新的失败：

1001
↓
1002
↓
1050
↓
2000
↓
10000

你的 Eval Dataset 实际上正在一点一点记录：

这个产品过去犯过的所有重要错误。

这时候 Evals 就不再只是测试系统。

它开始变成：

产品经验的积累系统。

AI Engineer 2024 的分享也非常强调从生产日志和真实失败中构建 Eval，并不断把这些数据送回开发循环。

现在回头看，会发现很多 AI Demo 都很容易做。

接一个 API。

写一个 Prompt。

加一个漂亮的聊天框。

几个小时就能出现一个看起来很聪明的产品。

真正困难的是下一步：

你怎么证明它越来越好？

不是：

“我感觉 GPT-5 比昨天那个模型厉害。”

不是：

“我们重新写了 Prompt，大家觉得不错。”

而是：

Task Success
84% → 91%

Hallucination
5.2% → 2.7%

Route Accuracy
87% → 93%

Average Cost
$0.021 → $0.014

现在我们终于可以说：

系统真的变好了。

所以我越来越理解为什么 AI Engineer 社区这些年会如此强调 Evals。

传统软件最大的确定性，很大程度上来自 Test。

而生成式 AI 天生就是一个概率系统。

输入相同的问题：

输出未必完全相同。

换一个 Prompt：

行为可能发生变化。

换一个模型：

又可能出现新的问题。

加一段 Context：

效果甚至可能变差。

因此 AI Engineering 需要给这种不确定性增加一个测量层。

这个测量层，就是：

Evals

它解决的其实是一个非常朴素的问题：

如果你连“好”是什么都无法定义，就不可能知道自己是不是真的在进步。

而一旦能够把“好”逐渐变成可以测量的东西，后面的 Reward、Bandit、Adaptive Router 才真正有了基础。

因为系统想要学习之前，

首先得知道：

什么叫做得好。

本文参考的 AI Engineer Talks

Dhinakaran, A. — LLM Evals That Work IRL, AI Engineer World's Fair 2024。 非常适合理解 Model Benchmark 与 Application Eval 的区别，以及为什么 Router、RAG 等组件应该分开评价。

Husain, H. and Sedgh, E. — How to construct domain-specific LLM evaluation systems, AI Engineer World's Fair 2024。 更偏实际产品，重点是如何从真实失败、日志和人工反馈逐渐构建自己的 Eval 系统。

Guthrie, D. — Evals 101: From a Baseline to Production Feedback, AI Engineer。 非常适合作为入门，核心框架就是本文提到的 Task + Dataset + Scorer。

Yan, E., Husain, H., Liu, J., Bischof, B., Frye, C. and Shankar, S. — What We Learned From A Year of Building With LLMs, AI Engineer World's Fair 2024。 核心观点之一是把 Evals 放进持续的产品改进循环，而不是把它当成最后一次考试。

代表性论文

1. LLM Evaluation 总览

Chang, Y., Wang, X., Wang, J., Wu, Y., Yang, L., Zhu, K. et al. (2024) ‘A Survey on Evaluation of Large Language Models’, ACM Transactions on Intelligent Systems and Technology, 15(3), Article 39, pp. 1–45. doi: 10.1145/3641289.

DOI: 10.1145/3641289

推荐理由： 如果只想系统读一篇“Evals 到底包括什么”的论文，这篇最合适。它把问题拆成 What to evaluate、Where to evaluate、How to evaluate。

2. LLM-as-a-Judge

Liu, Y., Iter, D., Xu, Y., Wang, S., Xu, R. and Zhu, C. (2023) ‘G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment’, Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, pp. 2511–2522. doi: 10.18653/v1/2023.emnlp-main.153.

DOI: 10.18653/v1/2023.emnlp-main.153

推荐理由： 理解“为什么可以让一个 LLM 给另一个 LLM 打分”的代表性论文。

3. RAG Evaluation

Es, S., James, J., Espinosa Anke, L. and Schockaert, S. (2024) ‘RAGAs: Automated Evaluation of Retrieval Augmented Generation’, Proceedings of the 18th Conference of the European Chapter of the Association for Computational Linguistics: System Demonstrations, pp. 150–158. doi: 10.18653/v1/2024.eacl-demo.16.

DOI: 10.18653/v1/2024.eacl-demo.16

推荐理由： 特别适合理解一个复杂 AI 系统为什么不能只看“最终答案对不对”，而要分别评价 Retrieval、Context 和 Generation。

4. Holistic Evaluation

Liang, P., Bommasani, R., Lee, T. et al. (2023) ‘Holistic Evaluation of Language Models’, Transactions on Machine Learning Research. doi: 10.48550/arXiv.2211.09110.

DOI: 10.48550/arXiv.2211.09110

推荐理由： HELM 的核心思想非常重要：不要只用 Accuracy 判断一个模型，而应该同时看准确性、鲁棒性、公平性、毒性、效率等多个维度。