主题
为什么要评估 RAG 和代理？
到目前为止，我们构建了智能客服系统（第 10 章）、代码分析助手（第 11 章）和数据分析 Agent（第 12 章）。每个项目完成后，我们都在 CLI 里手动测试了几个例子，看到输出结果觉得"还行"，然后就进入了下一章。
但在真实的生产环境中，这种**"手动试几个 case，感觉没问题就上线"**的做法是极其危险的。本章要解决的核心问题是：如何系统化地衡量一个 LLM 应用是否真正好用？
"感觉不错"的陷阱
先看一个真实的案例。某团队上线了一个基于 RAG 的内部知识库问答系统。开发阶段他们手动测试了 20 个问题，回答都挺靠谱，于是信心满满地部署到了全公司。两周后收到的反馈却让他们傻眼了：
- 30% 的用户反馈："问的问题它答非所问"
- 15% 的用户反馈："给的答案看起来对，但实际是错的"
- 客服团队投诉："它经常编造不存在的功能"
- 技术团队发现：某些类型的问题准确率只有 40%
为什么会这样？因为手动测试的样本量太小、覆盖面太窄、主观性太强。你挑的 20 个问题恰好都是系统擅长的场景——但真实用户的提问分布完全不同。
一个具体的对比
假设你的 RAG 系统有三种表现模式：
| 问题类型 | 占比 | 手动测试时你选的 | 真实用户分布 |
|---|---|---|---|
| 简单事实查询（定价/功能列表） | 60% | 选了 18 个 (90%) | 60% |
| 需要多文档关联的复杂问题 | 25% | 选了 2 个 (10%) | 25% |
| 知识库中没有答案的问题 | 15% | 选了 0 个 (0%) | 15% |
如果你只测了自己选的那 20 个问题，准确率 = 19/20 = 95%。但如果按真实用户分布来算：
- 简单问题：95% × 60% = 57%
- 复杂问题：50% × 25% = 12.5%
- 无答案问题：0%（系统乱猜）× 15% = 0%
- 加权实际准确率 ≈ 69.5%
从 95% 到 69.5%，这就是"感觉不错"和"真实表现"之间的鸿沟。
RAG 应用为什么特别难评估
传统的软件测试有明确的输入和输出预期：f(2, 3) 应该返回 5，如果返回 6 就是 bug。但 LLM 应用的输出是开放式的自然语言——同一个问题可以有多个合理的回答方式。
以我们的客服 RAG 为例：
Q: "免费版支持几个人？"
参考答案 A: "免费版最多支持5名团队成员。" ← 精确
参考答案 B: "免费版限制为5人。" ← 可接受
参考答案 C: "免费版可以最多5个人同时使用。" ← 可接受
参考答案 D: "免费版没有人数限制。" ← ❌ 错误
参考答案 E: "免费版支持5个人，专业版无限制..." ← 正确但冗余这五个答案中，哪些算"正确"？A 肯定算，D 肯定不算，B/C/E 呢？这需要定义模糊的正确性标准——这正是 RAG 评估的核心难点。
RAG 的三层评估维度
一个完整的 RAG 回答质量需要从三个层面衡量：
用户问题: "专业版的 API 调用次数限制是多少？"
┌─────────────────────────────┐
│ 第一层：检索质量 │
│ 检索到的文档是否相关？是否充分？│
│ → 忠实度 (Faithfulness) │
├─────────────────────────────┤
│ 第二层：生成质量 │
│ 回答是否基于检索内容？有无幻觉？│
│ → 准确率 (Accuracy) │
├─────────────────────────────┤
│ 第三层：端到端效果 │
│ 回答是否解决了用户的问题？ │
│ → 相关性 (Relevance) │
└─────────────────────────────┘- 第一层（检索）：系统找到的文档片段是否真的包含了答案？如果检索阶段就漏掉了关键信息，后面生成再好也是空中楼阁。
- 第二层（生成）：LLM 生成的回答是否忠实于检索到的内容？有没有"自作主张"地添加知识库中没有的信息？
- 第三层（端到端）：综合来看，这个回答对用户是否有用？回答是否流畅、格式是否合理？
Agent 应用为什么更难评估
如果说 RAG 的评估已经够复杂了，那 Agent 的评估就是难上加难。原因在于：
不确定性更高
同样的输入，Agent 可能走完全不同的路径：
输入: "帮我查一下订单 CS-20241088 的状态"
运行 1:
Thought: 直接查订单 → Action: order_query("CS-20241088") → 已发货
运行 2:
Thought: 先验证订单号格式 → Action: validate_id(...) → 再查询 → 已发货
运行 3:
Thought: 这个订单号看起来不像我们的格式 → Action: 问用户确认...三次运行的最终答案可能相同或不同，但中间过程完全不同。评估不仅要看输出，还要看推理过程是否合理。
工具调用难以判定
对于 Agent 的工具调用，什么算"正确的决策"？
python
# 用户问: "退款流程是什么？"
# Agent 选择调用了 search_knowledge_base() → 返回退款政策 → 正确 ✅
# 用户问: "我的订单 CS-100 能退货吗？"
# Agent A: 调用了 search_knowledge_base() → 返回通用政策 → 不够好 ⚠️
# Agent B: 调用了 query_order("CS-100") + search_knowledge_base() → 综合回答 → 更好 ✅
# Agent C: 直接说"可以退" → 错误 ❌（没查订单状态）Agent B 比 Agent A 好——因为它多查了一步订单状态再给建议。但这种**"策略优劣"**的判断比简单的对错判断复杂得多。
多步推理的错误传播
Agent 是多步执行的，一步出错可能导致后续全部错误：
Step 1: 意图识别错误（把"退款"识别成了"产品咨询"）
↓
Step 2: 走了错误的处理分支（RAG 而不是退款流程）
↓
Step 3: 返回了产品介绍而不是退款指引
↓
Step 4: 用户不满意，继续追问
↓
Step 5: 上下文已混乱，后续回答越来越偏评估系统需要能够定位到具体哪一步出了问题，而不是只看最终输出。
评估体系的四个层次
根据投入成本和精细程度，我们可以把评估分为四个层次：
| 层次 | 方法 | 成本 | 适用阶段 |
|---|---|---|---|
| L1: 人工抽查 | 团队成员随机抽样检查 | 低 | 开发初期 / 快速验证 |
| L2: 规则自动化 | 预定义规则自动打分 | 低 | 上线后持续监控 |
| L3: LLM-as-Judge | 用强模型评估弱模型输出 | 中 | 迭代优化阶段 |
| L4: 人类标注基准 | 专业标注员建立黄金数据集 | 高 | 发布前的正式评估 |
大多数项目应该至少做到 L1 + L2，有条件的团队应该追求 L3。L4 是最理想但成本最高的方案，通常只在关键版本发布前执行。
各层次的典型做法
L1 人工抽查：每天随机抽取 50 条对话记录，由产品/运营人员标注"满意/一般/不满意"。简单粗暴但有效——能快速发现严重问题。
L2 规则自动化：编写自动检测脚本，例如：
- 回答中是否包含"抱歉""无法回答"等拒绝关键词？（可能表示检索失败）
- 回答长度是否异常短（<20 字）或异常长（>2000 字）？
- 是否触发了 Handoff？（转人工率高说明 AI 解决能力不足）
- Token 使用量是否突增？（可能意味着 prompt 注入攻击）
LLM-as-Judge：用 GPT-4o 作为"裁判"，给它一套评分标准和待评估的 Q&A 对，让它按照 1-5 分打分并给出理由。这是目前性价比最高的自动化评估方案，我们会在下一节详细展开。
L4 黄金基准集：聘请领域专家针对 200-500 个精心设计的问题编写标准答案，作为不可动摇的"ground truth"。每次模型更新后跑一遍完整测试集，确保没有回归。这是大厂（如 OpenAI、Anthropic）的标准做法。
什么时候需要做评估
不是所有阶段都需要同等力度的评估。以下是一个务实的评估时间表：
开发阶段 (MVP)
├── L1: 手动测试 20-30 个典型案例
├── 关注点: 核心流程能不能跑通
└── 频率: 每天一次
内测阶段 (Beta)
├── L1 + L2: 人工抽查 + 自动规则监控
├── 关注点: 边界情况、异常输入的处理
└── 频率: 每次代码变更后
公测阶段 (GA)
├── L1 + L2 + L3: 增加 LLM-as-Judge 自动评分
├── 关注点: 全面的质量指标、性能基线
└── 频度: 每日自动运行 + 每周人工 review
成熟阶段 (Production)
├── 全部 L1-L4: 建立完善的回归测试套件
├── 关注点: 模型升级后的回归检测、长期质量趋势
└── 频率: 持续集成 (CI) 中自动触发评估的常见误区
误区一：只用准确率一个指标。准确率只能告诉你"有多少比例的回答是对的"，但无法区分"完全正确""部分正确但有帮助""部分正确但误导"这些细微差别。一个好的评估体系应该是多维度的。
误区二：评估一次就不管了。LLM 的行为会随着模型版本更新、prompt 微调、知识库变更而变化。今天评估通过的 case，下个月可能就失败了。评估应该是持续的、自动化的、纳入 CI/CD 流程的。
误区三：只评估"好的情况"。很多人倾向于选择系统能够正确回答的问题来做评估——这是一种自我欺骗。好的评估集应该包含正常问题、边界问题、对抗性问题、无答案问题等各种类型，比例尽量接近真实分布。
误区四：忽略成本维度。一个准确率 90% 但每次调用花费 $0.10 的方案，未必优于准确率 85% 但每次只花 $0.02 的方案。评估体系应该把质量、速度、成本三者放在一起权衡。