~$ tenggouwa
← cd ../posts

Evals：怎么知道模型"真的变好了"而不是看起来变好了

2026-06-07
ai evals benchmark ai-series

AI 系列第 17 篇。这一篇讲一个最不性感、却最重要的话题——evals。 没有 evals，所有"模型变强了"的说法都是嘴炮。

0. 一个让所有 AI 团队尴尬的问题

你做了一个 RAG 系统，跑了 3 个月。老板问你：

老板: "上个季度模型从 Claude 3 升到 Claude 4 了。我们效果提升了多少？"
你:  "呃……感觉好很多……？"
老板: "感觉？"

没有 evals，你回答不了这个问题。

更糟的是——你也不知道有没有 regress。换 prompt、换模型、加新工具，每次改动都可能让某些 case 变好、某些变差。没有 evals 你就是在裸奔。

这一篇我们讲怎么不裸奔。

1. LLM 时代的 evals 比传统 ML 难得多

传统 ML 评估很简单：

分类: accuracy / F1
回归: RMSE / MAE
推荐: NDCG / MAP

输入 → 模型 → 输出。把输出和 ground truth 对比，算分。

LLM 评估根本不适用这套。原因：

  1. 输出是自由文本。"明天天气晴，22 度" vs "明日多云，温度 22℃" 都对，怎么自动判断？
  2. 任务多样。同一个模型既要写代码又要写诗又要做数学。一个指标盖不全。
  3. 没有唯一正确答案。诗、邮件、设计文档——好坏主观。
  4. 数据集会被污染。公开 benchmark 一旦发布，可能很快混进训练数据。

这些坑让 LLM 评估变成 AI 圈最难的工程问题之一。

2. 主流 Benchmark 巡礼

先看公开 benchmark。它们不能直接用于你的产品，但反映模型的"通用能力"。

MMLU（Massive Multitask Language Understanding）

57 个学科的多选题，从初等数学到法律到道德哲学。

GPT-3 (2020):       43%
GPT-4 (2023):       86%
Claude 3 Opus:      87%
GPT-4o (2024):      88%
Claude 4 (2025):    93%
人类专家:           90%

问题：基本被刷爆了。Top 模型差距已经 < 2%，区分度不够。

HumanEval

164 道 Python 函数题，看模型写代码能不能通过测试。

GPT-3.5:    48%
GPT-4:      67%
Claude 3.5: 92%
GPT-4o:     90%

问题：题目太简单（leetcode easy 难度），且早被刷爆。

MATH

5000 道数学竞赛题。

GPT-4:      53%
o1:         83%
o3:         96%

问题：reasoning 模型刷上来后，区分度也接近饱和。

GPQA Diamond

200 道博士级别问题（物理 / 化学 / 生物）。

GPT-4:      36%
Claude 3.5: 60%
o1:         77%
o3:         87%

问题：人类 PhD 也只能做到 60-70%，已经到天花板了。

SWE-bench / SWE-bench Verified

真实 GitHub issues。让模型读代码库、定位 bug、写补丁。

2023 GPT-4:        ~4%
2024 Claude 3.5:   ~30%
2025 Claude 4:     ~70%
2026 现在前沿:     ~80%

这是目前最能反映"AI agent 实际能力"的 benchmark。难度高、贴近真实。

LMSYS Chatbot Arena

人类盲测投票。两个模型给同一 prompt 输出，人选哪个更好。

2024 顶级:  GPT-4o, Claude 3.5
2025:       Claude 4, o3, Gemini 2
2026:       Claude Opus 4.7, GPT-5

优点：贴近真实用户体感。 缺点：投票偏向 sycophant（讨好的）回答。

3. 为什么 Leaderboard 越来越没用

2024 之后大家发现一个事实——leaderboard 分数和实际产品体感越来越脱钩。

原因：

原因 1：数据污染

公开 benchmark 一旦发布，几个月内就可能混进训练数据。模型不是"会做"，是"记得"。

Goodhart's Law 出现：当一个指标变成目标，它就不再是好指标。

原因 2：训练时针对性优化

各家实验室都对热门 benchmark 做 SFT / RL。结果：benchmark 分数刷高了，泛化能力没真的提升。

原因 3：任务分布偏

MMLU 是多选题，HumanEval 是简单函数。但真实 LLM 使用场景是：写复杂 prompt、修长代码、做多轮推理、用 tools。Benchmark 测不到这些。

原因 4：模型差异 > benchmark 差异

GPT-4o 和 Claude 3.5 在 MMLU 上差 2%——但在你的具体任务上，可能 Claude 强 30%，也可能 GPT-4o 强 30%。通用分数 ≠ 你任务上的分数。

一句你可以拿去吹的话： 2025 之后挑模型不能看 leaderboard。要自己跑 evals。

4. 生产级 Evals 怎么做

公开 benchmark 不靠谱，那怎么办？自己写 evals。

Step 1: 收集 eval 数据集

✅ 来源:
  - 真实用户日志
  - 你的产品 use case
  - 故意构造的 edge case

✅ 数量:
  - 起步: 50-100 个
  - 成熟: 500-2000 个
  - 不需要上万——质量比数量重要

Step 2: 定义评分标准

这是最难的一步。三种主流方式：

方式 A：精确匹配 / Regex

适用：分类、提取、有明确答案的任务。

expected = "positive"
predicted = llm("分析情感: 我今天很开心")
score = (expected == predicted)

方式 B：执行测试

适用：代码生成。

code = llm("写一个 fibonacci 函数")
exec(code)
assert fibonacci(10) == 55

方式 C：LLM-as-judge

适用：开放性任务（写作、对话）。

judge_prompt = f"""
判断回答 A 和回答 B 哪个更好。
问题: {question}
A: {answer_a}
B: {answer_b}

按以下标准评分:
- 准确性 (1-5)
- 完整性 (1-5)
- 简洁度 (1-5)

输出 JSON: {{"winner": "A" | "B", "scores": ...}}
"""
result = judge_llm(judge_prompt)

LLM-as-judge 的坑：

  • 同模型评同模型 → 偏自己
  • 顺序偏好 → A/B 顺序换位置结果可能不同
  • 长回答偏好 → judge 倾向给长回答高分

对策：

  • 用更强的模型当 judge（评 GPT-4 用 Claude，反之）
  • 双向 A/B 测两次取平均
  • 显式告诉 judge "长度不是评分标准"

Step 3: 跑 baseline

把现有的 production 系统跑一遍，记下分数。这是你的 baseline。

Step 4: 改动 → 跑 evals → 对比

每次改 prompt / 换模型 / 调参数前，先跑 evals。改完再跑一次。

关键：差距 > 5% 才算真改善。1-2% 在噪声范围内。

Step 5: 持续维护数据集

- 每周从用户日志加 10 个新 case
- 修复发现的 bug 后，把这个 case 加进 regression set
- 定期 review 旧 case 是否还相关

5. Evals 框架

主流工具：

开源

  • DeepEval：Pytest 风格，结构化
  • Promptfoo：YAML 配置，CLI
  • Inspect AI (UK AISI)：科研级，最严谨
  • Ragas：专门评 RAG

商业

  • Braintrust：YC 出品，UI 好
  • LangSmith（LangChain）：和 LangChain 集成
  • HumanLoop：人工标注 + 自动评估

一个最小示例（DeepEval）

from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import AnswerRelevancyMetric

test_case = LLMTestCase(
    input="北京什么时候降温？",
    actual_output=my_rag.query("北京什么时候降温？"),
    retrieval_context=["北京一般 10 月开始降温..."],
)

metric = AnswerRelevancyMetric(threshold=0.7)
assert_test(test_case, [metric])

把 evals 当单元测试一样跑。CI 里每个 PR 都跑一遍。这是 LLM 时代的工程化。

6. 几种 evals 的反模式

反模式 1：只测整体不测拆解

❌ "我的 RAG 准确率 80%"
✅ "检索阶段 recall@5 = 90%; rerank precision = 85%; 生成阶段 faithfulness = 95%"

整体一个数掩盖了哪一步是瓶颈。

反模式 2：用同模型 self-eval

让 GPT-4 自己评 GPT-4 的输出。误差大。

反模式 3：没有 baseline

只看绝对分数，没有对照组。"准确率 75%" 意味什么？比上版好还是差？

反模式 4：N=10

10 个 case 跑出的分数噪声太大。最少 100 个，最好 500+。

反模式 5：evals 一次性写完

evals 数据集应该和产品一起持续演化。一次性写完跑半年的 evals，越用越脱节。

7. Evals 的真实价值不只是"分数"

写 evals 的过程，本身就是一次对产品的深度理解。

  • 你被迫定义 "什么是好回答"
  • 你被迫枚举 edge case
  • 你被迫想清楚 "用户真的关心什么"

很多团队跑了 evals 之后发现："原来 30% 的 case 我们的 prompt 完全没考虑到。" —— 这种发现比 benchmark 数字本身更有价值。

一句你可以拿去吹的话： 写 prompt 是写代码，写 evals 是写规格说明书。没规格的代码改 100 次还是不知道对不对。

8. 给你的小作业

  1. 挑一个你常用的 LLM 任务，写 10 个 eval case（输入 + 期望输出）。
  2. 用 LLM-as-judge 给这 10 个 case 打分，写一个 judge prompt。
  3. 解释为什么不该用同一个模型既做生成又做评判。

下一篇钩子：evals 让我们知道模型表现"好不好"。 但还有更深的问题：模型是不是"对人有用、对人无害、说真话"？ 这就是 alignment（对齐）——AI 工程里最有哲学味道、又最有工程紧迫性的话题。 下一篇我们看，怎么把"诚实、有用、无害"工程化。