Eval / 测评体系：让 Agent 质量”有数可证”
一句话：Eval 是给 AI 系统做体检的整套办法——没有它，“我的 Agent 变好了”只是感觉；有了它，“变好了 8.3%“是事实。Eval 是 Agent 工程的命根子，是数据飞轮的方向盘，也是 Agent 架构师最容易被忽略的硬技能。
目录
- 0. 为什么 Eval 是 Agent 工程的命根子
- 1. Eval 是什么
- 2. 四大类 Eval
- 3. Eval 数据集怎么构建
- 4. 关键指标
- 5. 实战工具
- 6. Eval 在数据飞轮里的位置
- 7. Eval 在 Agent 架构里的位置
- 8. 经典误区与陷阱
- 9. 落地路径：小白怎么开始
- 10. 与本知识库其他章节的关联
0. 为什么 Eval 是 Agent 工程的命根子
0.1 没有 Eval 的真实痛苦
设想你做了一个 AI 客服 Agent，已经上线 3 个月。今天你想：
- 把模型从 GPT-4 换成 Claude Haiku（省钱）
- 调一下 system prompt（让它更礼貌）
- 加一个新工具（订单查询）
没有 Eval 的世界：
“感觉好像变好了？” “有用户投诉，但不知道是这次改动导致的还是别的原因” “上线一周后回滚——但回滚到哪个版本？记不清了”
有 Eval 的世界：
跑一遍 200 题的测评集 → 准确率从 87% → 91% ✅ 客服满意度模拟得分 4.2 → 4.5 ✅ 平均响应延迟 2.1s → 1.8s ✅ 数据说话，不用猜
0.2 三个直击灵魂的事实
🔥 没有 Eval，所有 prompt 调优都是玄学——你不知道改完是更好还是更差。
🔥 没有 Eval，数据飞轮根本转不起来——飞轮的核心是”知道自己变好了多少”。
🔥 没有 Eval，没法谈 SLA、谈交付、谈商业化——客户问”准确率多少”你只能说”挺好的”。
1. Eval 是什么
1.1 一句话定义
Eval（Evaluation，评测）= 用一套固定的”考题”，给 AI 系统打分。
1.2 三个生活类比
| 类比 | 对应到 AI |
|---|---|
| 体检 | 一套固定项目（血压、血脂、肝功能）→ 报告 → 知道哪里不对 |
| 期末考试 | 一套固定题（不是临时编的）→ 全班同一份 → 公平比较 |
| 车辆碰撞测试 | NCAP 五星标准 → 全行业可比 → 用户能选 |
1.3 Eval 的三件套
1. 测评集（Eval Set）—— 一组固定的"题目"
2. 评判标准（Metric）—— 怎么算"答对"
3. 测评流程（Pipeline）—— 怎么自动跑、出报告
2. 四大类 Eval
按”谁来评判”和”何时跑”两个维度，可以分成四大类：
离线（开发/迭代时） 在线（生产环境）
┌──────────────────────┬──────────────────────┐
人 来评 │ 人工评测（贵但准） │ 用户反馈（👍/👎） │
├──────────────────────┼──────────────────────┤
机器评 │ 离线 Eval（黄金集） │ 在线 A/B 测试 │
│ + LLM-as-Judge │ │
└──────────────────────┴──────────────────────┘
2.1 离线评测（Offline Eval）
怎么做：开发时跑一组固定测评集，看准确率/分数。
典型场景：
- 改了 prompt → 跑 eval set → 看分数有没有跌
- 换了模型 → 跑 eval set → 对比新旧
- 上线前最后一道闸——分数低于阈值就不让发布（CI 集成）
类比：高考前反复刷历年真题，刷分稳定了再上考场。
优势：快、便宜、可重复 痛点：只能反映 eval set 上的能力，不一定代表真实场景
2.2 在线 A/B 测试
怎么做：把流量按 50:50 分给新版本和旧版本，统计真实用户指标。
典型指标：
- 用户点 👍 / 👎 比例
- 用户复用率
- 任务完成率
- 用户流失率
类比：两家餐厅同条街开张，看哪家半年后还开着。
优势：真实场景、真实用户、真实数据 痛点：要等（一般要跑几天到几周才统计显著）、要用户量
2.3 LLM-as-Judge（用 AI 当裁判）
怎么做：让一个**强大的 AI（如 GPT-4 / Claude Opus）**给被测系统的输出打分。
经典场景：
- 被测系统：用便宜的 Haiku 回答客户问题
- 裁判 AI：用贵的 Opus 评判”回答是否准确、礼貌、相关”
为什么管用：
- 比人工便宜 100 倍
- 比单纯字符串匹配灵活得多（能理解语义）
- 在很多任务上和人类标注员一致率 > 80%
类比：找一个博士当家教给小学生改作文——不是最准的，但比”对答案”灵活，比”请专业作家”便宜。
陷阱：
- 裁判 AI 自身的偏见会被放大
- 裁判可能”喜欢”和它风格相似的回答（自我偏好）
- 复杂主观任务上还是要人工兜底
2.4 人工评测
怎么做：找标注员（或自己）对每个回答打分。
啥时候必用：
- 涉及法律、医疗、伦理的高风险场景
- 主观审美（写作、诗歌、设计）
- 验证 LLM-as-Judge 的可靠性（先用人工标 200 条做”金标”）
优势：最准、最贴近用户感受 痛点：贵、慢、一致性差（不同人标不一样）
3. Eval 数据集怎么构建
3.1 不是”随便挑 100 条”——而是分三类
┌────────────────────────────────────────────┐
│ ① 黄金集（Golden Set） │
│ 20~100 条最高质量、最具代表性的样本 │
│ 人工精挑细选，不能改 │
│ │
│ ② 困难集（Hard Set） │
│ 从用户日志里捞出"失败案例"、"边角问题" │
│ 专门考模型的弱点 │
│ │
│ ③ 回归集（Regression Set） │
│ 已经修复过的 bug 对应的样本 │
│ 防止改新 bug 时把老 bug 改回来 │
└────────────────────────────────────────────┘
3.2 每条数据的标准格式
{
"id": "eval-001",
"input": "用户问题：北京今天天气？",
"expected_output": "调用 weather 工具 → 返回当天数据",
"tags": ["工具调用", "天气"],
"difficulty": "easy",
"criteria": [
"是否调用了 weather 工具",
"答案是否包含温度",
"是否有当日日期"
]
}3.3 几个建数据集的实用法则
| 法则 | 说明 |
|---|---|
| 先小后大 | 第一版 20 条就行，别一开始就 1000 条 |
| 真实优先 | 用户日志 > 你脑补的题 |
| 覆盖场景 | 简单 / 困难 / 边角各占 1/3 |
| 持续生长 | 用户每报一个 bug，就新增一条 eval |
| 版本管理 | eval set 也要 git 提交，每条都有创建日期 |
4. 关键指标
4.1 通用指标
| 指标 | 含义 | 例子 |
|---|---|---|
| Accuracy（准确率） | 答对的比例 | 100 题对 87 题 → 87% |
| Pass Rate（通过率） | 通过验收标准的比例 | 代码题：能跑通测试用例的比例 |
| F1 Score | 精确率与召回率的调和平均 | 分类任务常用 |
| Latency（延迟） | 响应时间 | p50 / p95 / p99 都要看 |
| Cost（成本） | 平均每次调用消耗 | $/请求、Token/请求 |
4.2 RAG 系统专属指标
RAG = 检索增强生成。它的 Eval 必须分两段评：检索质量 + 生成质量。
| 指标 | 含义 |
|---|---|
| Context Precision（上下文精度） | 检索回的内容有多少是相关的 |
| Context Recall（上下文召回） | 该被检索回的内容有多少被检索到了 |
| Faithfulness（忠实度） | 生成的答案是否只基于检索到的内容（不胡编） |
| Answer Relevance（答案相关性） | 答案是否切题 |
📖 RAG Eval 的细节，可与 RAG 学习笔记 配合阅读。
4.3 生成任务指标
| 指标 | 含义 | 用途 |
|---|---|---|
| BLEU / ROUGE | 生成文本与参考答案的字面相似度 | 翻译、摘要 |
| BERTScore | 语义相似度 | 比 BLEU 更智能 |
| Hallucination Rate（幻觉率） | 生成内容含错误事实的比例 | 知识问答 |
| Toxicity（毒性） | 生成内容是否有害 | 安全合规（深入见 Agent 安全攻防） |
4.4 Agent 任务专属指标
Agent 不是一问一答——它要多轮规划、调工具、出最终结果。Eval 也得多维。
| 指标 | 含义 |
|---|---|
| Task Success Rate | 整个任务最终是否完成 |
| Tool Call Accuracy | 工具调用是否选对了、参数对不对 |
| Steps to Complete | 完成任务用了几步（越少越好） |
| Recovery Rate | 出错后能否自己恢复 |
| Cost per Task | 完成一次任务花多少钱 |
💡 Agent 评测最大的特点是”过程也要看，不只看结果”——同一个最终答案，用 3 步走完和用 30 步走完，工程意义天差地别。
5. 实战工具
5.1 开源工具
| 工具 | 主要用途 | 特点 |
|---|---|---|
| Promptfoo | Prompt 比较 / 回归测试 | YAML 配置、CI 友好、轻量 |
| Ragas | RAG 系统评测 | 专门针对 RAG 的 4 大指标 |
| DeepEval | 类 Pytest 写法 | Python 开发者友好 |
| OpenAI Evals | OpenAI 官方框架 | 数据集格式标准化 |
| lm-evaluation-harness | 学术 benchmark 跑分 | MMLU / HellaSwag 等 |
5.2 商用 / 托管平台
| 工具 | 主要用途 |
|---|---|
| LangSmith | LangChain 全家桶配套，trace + eval |
| Braintrust | 团队协作、生产监控 |
| Humanloop | Prompt 版本管理 + Eval |
| Anthropic Console Evals | Claude 官方 eval 平台 |
5.3 选择建议
小项目 / 个人 → Promptfoo（YAML 一把梭）
RAG 项目 → Ragas
Python 团队 → DeepEval（写法熟悉）
LangChain 用户 → LangSmith（无缝集成）
企业级生产 → Braintrust 或自建
6. Eval 在数据飞轮里的位置
Eval 是飞轮的方向盘和刹车——没有它，飞轮越转越歪也没人发现。
┌────────────────────┐
│ 用户使用 Agent │
└─────────┬──────────┘
↓ 真实数据
┌────────────────────┐
│ 数据收集 / 标注 │
└─────────┬──────────┘
↓
┌────────────────────┐
│ Eval 评测 ⭐ │ ← 这里检查"有没有变好"
│ (离线 + 在线 A/B) │ "哪个版本更好"
└─────────┬──────────┘
↓
┌────────────────────┐
│ 改进决策（基于数据）│
│ - 改 prompt │
│ - SFT / RLHF │
│ - 蒸馏 │
└─────────┬──────────┘
↓
┌────────────────────┐
│ 部署新版本 │
└─────────┬──────────┘
↓
┌────────────────────┐
│ Eval 守门 ⭐ │ ← 这里阻止"变更糟"上线
│ (回归测试 + CI) │
└─────────┬──────────┘
↓
（回到顶部，飞轮转一圈）
📖 数据飞轮的完整概念见 Agent 发展轨迹四阶段 § 10.7.2。
7. Eval 在 Agent 架构里的位置
回顾 Agent 五层解剖图：
┌────────────────────────────────┐
│ 编排层 │
├────────┬───────────┬───────────┤
│ 记忆层 │ 大模型 │ 执行层 │
├────────┴───────────┴───────────┤
│ 反馈层 ⭐ ←—— Eval 在这里 │
└────────────────────────────────┘
反馈层（Sensors）= Eval 在 Agent 内部的实时化版本。
7.1 两种时间尺度的 Eval
| 时间尺度 | 名字 | 在哪 | 触发时机 |
|---|---|---|---|
| 微秒级 | Sensors（实时反馈） | Agent 运行时 | 工具调用失败、lint 报错 → Agent 自修复 |
| 小时/天级 | 离线 Eval | CI / 训练流水线 | 改了 prompt / 模型后跑 |
| 天/周级 | 在线 A/B | 生产环境 | 灰度发布新版本 |
7.2 Eval 与回归测试
回归测试 = 软件工程的 Eval。
每修一个 bug：
- 把这个 bug 抽象成一条 eval 样本
- 加进 Eval 回归集
- 以后每次改动都跑——确保老 bug 不会复活
这个习惯一旦养成，Agent 的稳定性会指数级提升。
8. 经典误区与陷阱
8.1 ⚠️ 过拟合 Eval Set
现象：你的 prompt 在 eval set 上准确率 99%，上线却拉胯。
原因：你不停看 eval set、改 prompt、再看 eval set——本质上是在 eval set 上”训练”了 prompt。
对策：
- 留一个从来不看的私藏集（Holdout Set）
- 定期换新数据进 eval set
- Eval set 不能比真实分布偏太远
8.2 ⚠️ Goodhart’s Law（古德哈特定律）
“当一个指标变成目标，它就不再是个好指标。”
现象：你把”答案长度”当作质量指标 → 模型学会写长答案 → 长但啰嗦。
对策：
- 用多个互相制衡的指标（准确率 + 简洁度 + 用户满意度）
- 永远保留一个”无量化人工抽查”的兜底
8.3 ⚠️ 只看总分不看切片
现象：总准确率 87% 看着不错，但拆开看——
- 简单任务 99% ✅
- 困难任务 30% ❌
- 边角任务 10% ❌
总分被简单任务”掩盖”了真实问题。
对策：
- 永远按 任务类型 / 难度 / 用户群 切片看
- Dashboard 优先看最低分的切片
8.4 ⚠️ LLM-as-Judge 的隐藏偏见
| 偏见 | 表现 |
|---|---|
| 位置偏见 | 让裁判选 A 或 B，它倾向选第一个 |
| 冗长偏见 | 长答案默认被认为质量高 |
| 自我偏好 | 裁判 AI 倾向于自己风格的回答 |
对策：
- 让裁判 AI 评同一对答案两次（A vs B 和 B vs A），取一致结果
- 设定明确评分维度（不让它笼统打分）
- 用人工标 200 条做”金标”，校准 Judge 的可靠度
8.5 ⚠️ “我先把功能做完，最后再做 Eval”
现实：项目永远做不完，Eval 永远排不上。等你想做时，已经积累了 50 个版本，每个都不知道好坏。
对策：
- Day 1 就建 eval set（10 条就够）
- 每加一个新功能，先加 5 条 eval
- 把跑 Eval 加进 Git pre-commit / CI
9. 落地路径：小白怎么开始
9.1 第一周：手搓 10 题
1. 打开 Excel / Markdown 表格
2. 写下 10 个"我希望 Agent 能正确处理"的真实问题
3. 给每个问题写"标准答案"或"成功标准"
4. 手动跑一遍，记录得分
5. 改 prompt，再跑一遍，对比分数
这就是你的 v0 Eval。有比没有强 100 倍。
9.2 第一月：自动化 + 切片
1. 把 Excel 转成 YAML / JSON
2. 用 Promptfoo 跑（10 行配置就够）
3. 把题目按"类型"打标签（工具调用 / 写作 / 数学）
4. 每次出报告时按标签切片看
5. 把 Eval 跑加到 Git pre-commit
9.3 持续：飞轮启动
1. 用户每报一个 bug → 加一条 eval
2. 每周一花 30 分钟看 Eval 趋势
3. 准确率开始下降时立刻定位（哪个切片在跌）
4. 发版前必跑 eval，分数低于阈值就阻止上线
9.4 进阶：LLM-as-Judge + A/B
1. 选一个强模型当裁判（GPT-4 / Claude Opus）
2. 给它写明确的评分 rubric
3. 用人工标 200 条做校准
4. 上线后跑在线 A/B 测试
10. 与本知识库其他章节的关联
| 关联点 | 文档 | 关系 |
|---|---|---|
| Agent 反馈层 | Harness工程与Agent解剖 § 4 | Eval 是反馈层在”开发/上线时”的版本 |
| 数据飞轮 | Agent发展轨迹四阶段 § 10.7.2 | Eval 是飞轮的方向盘和刹车 |
| Agent 架构师硬技能 | Agent发展轨迹四阶段 § 10.4 | Eval 是 PPT 漏掉、本库特别强调的核心硬技能 |
| 训练技术 | 模型训练技术速查 | RFT 等训练方法严重依赖 Eval（用 Eval 当筛子） |
| RAG 系统 | RAG 学习笔记 | RAG 的 4 大评测指标（§ 4.2） |
| Token 经济 | 上下文窗口与Token计费 | Cost 指标的物理基础 |
| Multi-Agent 中的 Eval 角色 | Multi-Agent 工程实战与 Persona 设计 | 7 人团队中的”复盘官”实际上就是在跑 LLM-as-Judge + 离线 Eval,可对照本文的四大类 Eval 看真实工程实现 |
| LLM 失败模式与 Goodhart’s Law 的具象 | LLM 典型失败模式 | 本文讲”度量层”问题，该文讲”度量对象本身”会因 Goodhart’s Law 表演性完成；两者必须搭配阅读 |
附：术语速查
| 术语 | 含义 |
|---|---|
| Eval Set | 测评数据集 |
| Golden Set | 黄金集，最高质量的核心样本 |
| Hard Set | 困难集，专门考弱点的样本 |
| Holdout Set | 私藏集，永远不让模型/开发者看到 |
| Regression Set | 回归集，已修 bug 对应的样本 |
| LLM-as-Judge | 用 AI 当裁判 |
| Faithfulness | 忠实度（生成内容是否基于检索内容） |
| Hallucination | 幻觉（生成虚假事实） |
| Goodhart’s Law | 指标一旦变成目标就不再是好指标 |
| Rubric | 评分细则 |
| Holdout | 留作最终验证的私有数据集 |
创建时间: 2026-05-04