Eval：判断 AI 效果好不好

1. Eval 是什么#

Eval 可以理解成 AI 系统的测试和评估体系。

传统软件测试通常检查：

• 接口是否返回 200
• 字段类型是否正确
• 页面按钮是否可点击
• 数据库是否写入成功
• 单元测试是否通过

AI 系统还需要额外检查：

• 回答是否正确
• 回答是否完整
• 回答是否基于资料
• 输出格式是否稳定
• 工具是否调用成功
• 是否出现无依据内容
• 成本是否可接受
• 延迟是否可接受
• 改动后效果是否退化

Eval 的作用，就是把这些质量问题变成可以检查、可以记录、可以对比的评估项。

一个基础 Eval 流程如下：

1
准备测试问题
2
  ↓
3
运行 AI 系统
4
  ↓
5
收集输出、工具调用、引用来源、耗时和成本
6
  ↓
7
按照评分规则评估结果
8
  ↓
9
统计通过率、准确率、失败原因
10
  ↓
11
对比不同 Prompt、模型或策略

有了 Eval，AI 系统才具备持续优化的基础。

2. 为什么需要 Eval#

AI 输出有一个明显特点：结果会受 Prompt、模型、上下文、检索结果、工具返回、采样参数影响。同一个任务，在不同时间、不同输入、不同模型下，结果可能有差异。

如果没有 Eval，很容易出现这些问题：

• 改 Prompt 后不知道效果有没有提升
• 换模型后不知道哪些能力退化
• RAG 检索调参后只看个别示例
• 工具调用偶发失败但没人统计
• 上线前只做人工体验，缺少覆盖面
• 用户反馈问题后无法复现
• 成本和延迟逐渐变高但没有告警

Eval 能带来几个直接收益：

• 用数据判断质量
• 发现稳定性问题
• 复现用户反馈
• 对比不同方案
• 防止版本退化
• 支撑上线决策
• 帮助团队形成统一质量标准

AI 功能越接近真实业务，Eval 越重要。

3. Eval 的基本对象#

不同 AI 能力需要评估不同对象。

常见评估对象包括：

• Prompt
• Structured Output
• Tool Calling
• RAG
• Agent
• 模型
• 工作流
• 安全策略
• 成本和延迟

4. 测试集设计#

测试集是 Eval 的基础。

一个 AI 测试集通常由多条测试样例组成，每条样例至少包含：

• 输入问题
• 输入材料
• 期望结果
• 评分标准
• 任务类型
• 难度
• 标签

示例：

1
{
2
  "id": "rag-auth-001",
3
  "task_type": "rag_qa",
4
  "question": "登录接口密码错误时返回什么错误码？",
5
  "context": "docs/api-login.md",
6
  "expected_answer": "返回 401，错误码为 INVALID_PASSWORD。",
7
  "expected_sources": ["docs/api-login.md"],
8
  "rubric": [
9
    "必须包含 401",
10
    "必须包含 INVALID_PASSWORD",
11
    "必须引用 docs/api-login.md",
12
    "不能补充资料中没有出现的错误码"
13
  ],
14
  "difficulty": "easy",
15
  "tags": ["auth", "api", "error_code"]
16
}

测试集要尽量覆盖真实业务问题，避免只放简单示例。

5. 测试集覆盖范围#

一个可用测试集需要覆盖不同类型问题。

建议包含：

• 正常场景
• 边界场景
• 异常场景
• 信息不足场景
• 多资料合并场景
• 资料冲突场景
• 格式约束场景
• 工具失败场景
• 权限限制场景
• 高成本长上下文场景

以 RAG 系统为例，测试集可以这样设计：

测试集越贴近真实用户问题，Eval 结果越有参考价值。

6. 标准答案设计#

标准答案用于判断 AI 输出是否正确。

常见标准答案形式包括：

• 精确答案
• 关键词列表
• 期望来源
• 评分规则
• JSON schema
• 正则表达式
• 人工参考答案

1
{
2
  "question": "登录接口密码错误时返回什么 HTTP 状态码？",
3
  "expected_answer": "401"
4
}

1
{
2
  "required_keywords": ["401", "INVALID_PASSWORD"],
3
  "forbidden_keywords": ["403", "ACCOUNT_DISABLED"]
4
}

1
{
2
  "expected_sources": [
3
    "docs/api-login.md",
4
    "tests/auth/login-cases.md"
5
  ]
6
}

1
满分 5 分：
2
1 分：指出核心问题
3
1 分：解释影响
4
1 分：给出可执行修复建议
5
1 分：说明验证方法
6
1 分：避免无依据推断

7. 人工评分#

人工评分适合开放式任务和高风险场景。

常见人工评分维度包括：

• 正确性
• 完整性
• 相关性
• 可执行性
• 格式规范
• 引用准确性
• 安全性
• 表达清晰度

示例评分表：

人工评分的优点：

• 能处理复杂判断
• 能发现细微质量问题
• 适合上线前评审

人工评分的缺点：

• 成本高
• 速度慢
• 不同评审人标准可能不一致

为了提升一致性，需要提前写清评分规则，并准备正例和反例。

8. 自动评分#

自动评分适合大规模、重复执行的 Eval。

常见自动评分方式包括：

• schema 校验
• 关键词匹配
• 正则匹配
• 来源匹配
• 工具调用日志检查
• 单元测试
• LLM-as-judge
• 规则评分脚本

1
import { z } from "zod";
2

3
const TestCaseSchema = z.object({
4
  title: z.string(),
5
  steps: z.array(z.string()).min(1),
6
  expected_result: z.string(),
7
  priority: z.enum(["P0", "P1", "P2", "P3"])
8
});
9

10
const result = TestCaseSchema.safeParse(aiOutput);
11

12
if (!result.success) {
13
  throw new Error("AI 输出未通过 schema 校验");
14
}

1
{
2
  "required_keywords": ["401", "INVALID_PASSWORD"],
3
  "forbidden_keywords": ["403"]
4
}

1
包含全部 required_keywords 得分
2
出现 forbidden_keywords 扣分

1
{
2
  "case_id": "tool-read-file-001",
3
  "expected_tool": "read_file",
4
  "expected_args": {
5
    "path": "package.json"
6
  },
7
  "actual_tool": "read_file",
8
  "actual_args": {
9
    "path": "package.json"
10
  },
11
  "success": true
12
}

1
你是一名 AI 输出评审员。
2

3
请根据评分规则评估候选回答。
4

5
评分规则：
6
1. 正确性：0-5 分
7
2. 完整性：0-5 分
8
3. 引用准确性：0-5 分
9
4. 是否包含无依据内容：有 / 无
10

11
请输出 JSON：
12
{
13
  "correctness": 0,
14
  "completeness": 0,
15
  "citation_accuracy": 0,
16
  "has_unsupported_claims": false,
17
  "reason": "简短说明"
18
}
19

20
问题：
21
...
22

23
参考资料：
24
...
25

26
候选回答：
27
...

9. 回归测试#

AI 系统也需要回归测试。

每次修改这些内容后，都应该跑 Eval：

• Prompt
• 模型
• temperature
• 工具描述
• tool schema
• RAG chunking
• embedding 模型
• rerank 策略
• 输出格式
• 安全规则

回归测试关注两个问题：

• 新版本是否提升了目标指标
• 新版本是否破坏了已有能力

示例对比：

如果新版本准确率提升，但延迟和成本明显上升，就需要结合业务目标判断是否值得上线。

10. Prompt A/B 测试#

Prompt A/B 测试用于比较两个 Prompt 版本。

示例：

1
Prompt A：请总结下面的需求。
2
Prompt B：请按业务目标、用户流程、功能点、异常场景、待确认问题总结下面的需求。

评估维度：

• 是否覆盖核心内容
• 是否结构清楚
• 是否减少遗漏
• 是否减少无依据补充
• 输出是否更稳定

A/B 测试流程：

1. 准备同一批测试样例
2. 分别用 Prompt A 和 Prompt B 运行
3. 用同一套评分规则评估
4. 统计每个维度得分
5. 分析新 Prompt 的收益和代价

示例结果：

如果 Prompt B 在关键指标上更好，成本和延迟也能接受，就可以作为新版本。

11. RAG Eval#

RAG Eval 需要分开看检索和回答。

1
{
2
  "question": "登录接口密码错误时返回什么错误码？",
3
  "expected_sources": ["docs/api-login.md"],
4
  "retrieved_sources": [
5
    "docs/api-login.md",
6
    "docs/register.md",
7
    "docs/session.md"
8
  ]
9
}

1
{
2
  "answer_correct": true,
3
  "source_supported": true,
4
  "has_unsupported_claims": false,
5
  "missing_key_points": [],
6
  "score": 5
7
}

12. Tool Calling Eval#

Tool Calling Eval 关注模型是否正确调用工具。

常见指标：

• 工具选择准确率
• 参数生成准确率
• schema 校验通过率
• 工具执行成功率
• 失败恢复成功率
• 人工确认触发准确率
• 危险工具误调用率

示例测试样例：

1
{
2
  "id": "tool-001",
3
  "user_input": "帮我读取 package.json 看项目脚本",
4
  "expected_tool": "read_file",
5
  "expected_arguments": {
6
    "path": "package.json"
7
  },
8
  "forbidden_tools": ["run_command", "delete_file"]
9
}

评分逻辑：

1
选对工具：1 分
2
参数正确：1 分
3
schema 通过：1 分
4
工具执行成功：1 分
5
没有调用禁止工具：1 分

工具调用 Eval 要保留调用日志。只看最终回答，可能看不出中间步骤是否有风险。

13. 幻觉率#

幻觉率用于衡量 AI 输出中无依据内容的比例。

常见幻觉包括：

• 编造不存在的接口
• 编造不存在的文档来源
• 编造错误码
• 编造业务规则
• 编造文件路径
• 编造执行结果
• 把推测当成事实

评估方法：

• 检查关键结论是否有来源
• 检查引用是否真实存在
• 检查答案是否超出资料范围
• 检查代码或命令是否真实可执行
• 对高风险结论人工复核

示例记录：

1
{
2
  "case_id": "rag-015",
3
  "unsupported_claims": [
4
    "声称接口支持 reset_token 字段，但资料中没有出现"
5
  ],
6
  "hallucination": true
7
}

降低幻觉率的方法：

• Prompt 中要求只基于资料回答
• 资料不足时要求说明缺口
• 每个关键结论附来源
• 对引用做程序校验
• 对高风险答案加入人工审核
• 优化检索质量

幻觉率适合做上线门槛。例如：核心业务问答幻觉率必须低于 2%。

14. 成本、延迟、准确率对比#

AI 系统上线时，不能只看准确率，还要看成本和延迟。

常见指标：

• 输入 token 数
• 输出 token 数
• 单次调用成本
• 平均响应时间
• P95 响应时间
• 工具调用次数
• 检索耗时
• rerank 耗时
• 成功率
• 准确率

示例：

选择方案时，需要结合业务场景：

• 客服实时回复更看重延迟
• 代码审查更看重准确率
• 批量离线分析更能接受较高延迟
• 高频功能更需要控制成本
• 高风险决策更需要人工审核

Eval 的目标，是帮助你看清这些取舍。

15. 上线前评估表#

AI 功能上线前，可以准备一份评估表。

示例：

上线评估表可以让 AI 功能从“感觉不错”走向“有证据支撑”。

16. Eval 数据记录#

每次 Eval 都应该记录结果，方便后续对比。

建议记录：

• Eval 执行时间
• 测试集版本
• Prompt 版本
• 模型名称
• 模型参数
• 检索配置
• 工具版本
• 每条样例输入
• AI 输出
• 工具调用日志
• 检索结果
• 评分结果
• 成本
• 延迟
• 错误原因

示例：

1
{
2
  "eval_run_id": "eval-20260601-001",
3
  "dataset_version": "rag-v1.2",
4
  "prompt_version": "qa-v3",
5
  "model": "example-model",
6
  "case_count": 100,
7
  "answer_accuracy": 0.88,
8
  "citation_accuracy": 0.92,
9
  "hallucination_rate": 0.015,
10
  "average_latency_ms": 2100,
11
  "average_cost": 0.012
12
}

记录 Eval 数据后，团队才能追踪质量趋势。

17. 常见 Eval 问题#

18. Eval 实战练习#

可以按下面顺序练习：

1. 给 Prompt 做 A/B 测试
2. 给 Structured Output 设计 schema 校验
3. 给 RAG 系统设计 30 条测试问题
4. 统计 RAG 的 Recall@K 和引用准确率
5. 统计工具调用成功率
6. 统计危险工具误调用率
7. 比较不同模型的回答质量
8. 比较不同 chunk size 的检索效果
9. 记录每次调用的成本和延迟
10. 做一份 AI 功能上线前评估表

每个练习都可以检查三个问题：

• 评估标准是否清楚
• 评估结果是否可复现
• 评估结论是否能指导下一步优化

19. 阶段验收标准#

学完这一章，可以用下面的问题检查自己：

• 我能不能设计一批覆盖真实场景的测试问题？
• 我能不能为每条样例写清期望结果？
• 我能不能设计人工评分表？
• 我能不能用规则或脚本做自动评分？
• 我能不能评估 RAG 检索质量？
• 我能不能评估工具调用成功率？
• 我能不能统计幻觉率？
• 我能不能比较不同模型的成本、延迟和准确率？
• 我能不能用 Eval 结果判断改动是否值得上线？
• 我能不能保存 Eval 记录，支持后续回归对比？

如果这些问题大多数都能做到，说明 Eval 阶段已经基本合格。

20. 本章总结#

Eval 的核心是用测试集、评分规则和运行数据判断 AI 系统效果。

一套可用的 Eval 体系，建议至少包含：

• 测试集设计
• 标准答案设计
• 人工评分
• 自动评分
• 回归测试
• Prompt A/B 测试
• RAG 检索和回答评估
• Tool Calling 成功率评估
• 幻觉率统计
• 成本、延迟、准确率对比
• 上线前评估表
• Eval 结果记录

Eval 是 AI 工程化路线中的质量门槛。它让 AI 功能从主观体验走向数据判断，也让每一次 Prompt、模型、检索、工具和流程调整都有可对比依据。

这一章的目标很明确：用可复现的方式判断 AI 效果，知道哪里好、哪里差、哪里能上线、哪里还需要继续优化。