跳到主要内容

评测体系

核对日期:2026-05-13。

不稳定项:模型能力、评测框架、LLM-as-judge 方法、RAG 指标、Agent 轨迹评测和线上反馈工具会持续变化;评测结论必须绑定模型版本、Prompt 版本、数据集版本和运行日期。

专题文件索引

本阶段已拆分为 5 个专题文件。README.md 仍保留完整阶段讲义和练习入口;专题文件用于深入学习、专项实践和后续站点导航。

专题重点
01-评测集与Rubric设计.mdeval dataset、样例类型、Rubric、数据治理、失败样例库
02-LLM与结构化输出评测.md分类、抽取、摘要、结构化输出、judge 校准
03-RAG评测.md检索召回、排序、上下文、groundedness、引用和拒答
04-Agent轨迹评测.mdAgent trace、工具选择、参数、状态、HITL、安全越权
05-线上评测与发布门禁.md回归评测、线上指标、A/B、灰度、失败入库和回滚

生产闭环交叉引用

评测体系要连接 Agent 控制、安全门禁和 LLMOps 发布流程:

当前问题继续阅读
Agent trace 应记录哪些动作和状态../09-Agent系统设计/05-Agent轨迹评测.md
工具选择和参数为什么要纳入权限审计../11-安全与治理/04-工具权限审计与人类审批.md
安全负例如何覆盖注入、泄漏和文档污染../11-安全与治理/02-Prompt注入与间接注入防护.md
线上质量、成本、延迟和安全如何观测../12-LLMOps与生产化/04-可观测性与Trace.md
发布门禁如何进入灰度和回滚流程../12-LLMOps与生产化/05-灰度发布回滚与供应商治理.md

1. 阶段目标

本阶段目标是建立 AI 系统的评测体系。没有评测,AI 应用就是“感觉还不错”的 demo;有评测,才能知道 Prompt 改动、模型升级、RAG 索引更新、Agent 工具变更到底是让系统变好还是变坏。

学完本阶段,你应该能做到:

  • 为 LLM、RAG、Agent 设计任务级评测集。
  • 区分单元评测、离线评测、在线评测、人工评测和回归评测。
  • 设计评分标准:格式、正确性、事实性、引用、拒答、安全、成本和延迟。
  • 使用人工评分、规则评分、程序评分和 LLM-as-judge,并知道各自风险。
  • 为 RAG 做分层评测:检索召回、排序、上下文、生成、groundedness。
  • 为 Agent 做轨迹评测:工具选择、参数、状态更新、终止和人类在环。
  • 把线上失败样例沉淀为回归集。
  • 建立发布门禁,避免 Prompt、模型和知识库更新引入回归。

本阶段的核心产出是:

  • 一套 30 条以上的 AI 系统评测集。
  • 一份评分 Rubric。
  • 一个失败样例库。
  • 一个发布前回归检查流程。

2. 学习前置条件

建议已完成:

  • 06-Prompt与上下文工程,理解 Prompt 版本和结构化输出。
  • 07-RAG与知识系统,理解检索、引用、拒答和 groundedness。
  • 08-AI应用工程,理解日志、trace、成本和线上反馈。
  • 09-Agent系统设计,理解 Agent loop、工具和轨迹。

不要求:

  • 一开始就搭建复杂评测平台。
  • 用 LLM judge 替代全部人工评审。
  • 追求一次性覆盖所有任务。

3. 核心知识地图

4. 详细讲义

4.1 为什么 AI 系统必须评测

AI 系统的输出具有概率性,且错误常常“看起来很合理”。只看几个 demo 会产生三个问题:

  • 样例太少,覆盖不到边界。
  • 人会被流畅表达欺骗。
  • 改动无法量化比较。

评测要回答的问题:

  • 这个系统在目标任务上成功率是多少?
  • 失败主要集中在哪里?
  • 新 Prompt 是否比旧 Prompt 好?
  • 新模型是否值得更高成本?
  • RAG 检索是否召回正确证据?
  • Agent 是否正确使用工具?
  • 安全样例是否能拒答或拦截?

评测不是最后一步,而是 AI 系统迭代的中心循环。

4.2 评测层级

层级评什么示例
单元评测局部函数或 schemaJSON 校验、解析器
Prompt 评测单个 Prompt 输出分类、抽取、摘要
RAG 评测检索和生成链路召回、引用、拒答
Agent 评测多步轨迹工具选择、任务成功
端到端评测用户任务完成从输入到最终结果
在线评测真实用户表现采纳率、负反馈
安全评测攻击和滥用注入、越权、泄漏

先从任务级离线评测开始,再逐步加入线上指标和自动化门禁。

4.3 评测集设计

评测集不是随机收集一些问题。它应该代表真实任务分布和关键风险。

样例类型:

类型目的
正常样例覆盖高频任务
边界样例测试分类边界和模糊输入
困难样例测试长上下文、复杂推理、多约束
缺信息样例测试拒答
冲突样例测试冲突处理
安全样例测试注入、越权、敏感信息
历史失败样例防止问题复发

评测样例字段建议:

{
"id": "rag-policy-001",
"task": "企业制度问答",
"input": "试用期员工可以报销差旅住宿吗?",
"expected_behavior": "根据制度回答,并引用具体条款",
"expected_answer": "可以,但标准与正式员工一致或按制度条款说明",
"required_sources": ["travel-policy-2026#section-3"],
"should_refuse": false,
"tags": ["rag", "policy", "citation", "normal"],
"risk_level": "medium"
}

4.4 评分方式

常见评分方式:

方式适用优点风险
规则评分schema、枚举、长度、关键词稳定、便宜覆盖有限
程序评分单测、SQL、计算结果客观需要可执行标准
人工评分复杂质量、安全、产品体验最可靠成本高、主观差异
LLM-as-judge语义质量、摘要、问答扩展快偏差、漂移、被攻击
混合评分多维综合更稳实现复杂

高风险任务不要只用 LLM judge。重要评测应有人类校准样本。

4.5 Rubric 设计

Rubric 是评分标准。没有 Rubric,评测会退化成“我觉得还行”。

客服回答 Rubric 示例:

维度0 分1 分2 分
正确性与政策冲突部分正确完全符合政策
完整性遗漏关键步骤覆盖主要步骤覆盖全部必要步骤
引用无引用或错引用引用部分相关引用直接支持结论
语气不专业基本可用清晰、礼貌、可执行
安全泄露或越权有轻微风险无明显风险

Rubric 要足够具体,让不同评审者能接近一致。

4.6 LLM 输出评测

LLM 输出常见评测维度:

  • 格式通过率。
  • 字段完整率。
  • 分类准确率。
  • 事实正确性。
  • 指令遵循。
  • 风格一致性。
  • 拒答准确率。
  • 安全违规率。
  • 延迟和成本。

结构化抽取任务适合规则和程序评分;开放问答和摘要任务通常需要 Rubric + 人工/LLM judge。

4.7 RAG 分层评测

RAG 评测必须分层,否则很难定位失败。

层级指标解释
检索召回recall@k正确证据是否在 top k
排序质量MRR / nDCG正确证据排得是否靠前
上下文质量context precision塞给模型的证据是否相关
答案质量answer correctness答案是否正确
证据一致groundedness结论是否被证据支持
引用覆盖citation coverage关键结论是否有引用
拒答质量refusal accuracy无证据时是否拒答

RAG 失败定位:

答案错
-> 正确证据是否在知识库?
-> 是否被召回?
-> 是否排到上下文里?
-> 模型是否使用了证据?
-> 引用是否支持结论?

4.8 Agent 轨迹评测

Agent 评测要看 final answer,也要看中间轨迹。

轨迹评测字段:

  • goal。
  • plan。
  • tool_calls。
  • tool_args。
  • observations。
  • state_updates。
  • approvals。
  • final_output。
  • cost。
  • latency。
  • errors。

Agent Rubric:

维度通过标准
任务理解正确识别目标和约束
计划质量步骤合理,可根据观察调整
工具选择选择了必要且最小权限工具
参数正确参数合法且完整
证据使用关键结论有来源
安全边界高风险动作进入审批
终止判断不循环,完成或升级合理
成本控制步数和 token 在预算内

只看最终答案会漏掉“侥幸成功”的错误轨迹。比如 Agent 可能最终答对,但中间调用了无权限工具。

4.9 LLM-as-judge 的适用和风险

LLM-as-judge 适合:

  • 初筛大量样例。
  • 语义相似度判断。
  • 摘要质量评分。
  • 引用是否相关的辅助判断。
  • 生成失败原因归类。

风险:

  • judge 模型偏好长而流畅的答案。
  • judge 可能被被测输出诱导。
  • judge 版本升级导致分数漂移。
  • judge 和被测模型同源时偏差更强。
  • judge 对领域事实可能不了解。

缓解方式:

  • judge Prompt 固定版本。
  • 使用结构化 Rubric。
  • 加入少量人工标注校准集。
  • 定期计算 judge 与人工一致率。
  • 对高风险项使用人工复核。

4.10 在线指标

离线评测不能替代线上监控。线上要看真实用户行为。

质量指标:

  • 用户采纳率。
  • 用户编辑距离。
  • 重新生成率。
  • 负反馈率。
  • 引用点击率。
  • 人工审核通过率。
  • 拒答后继续追问率。

系统指标:

  • 成功率。
  • P50/P95 延迟。
  • 首 token 延迟。
  • token 用量。
  • 成本。
  • 错误率。
  • 工具调用失败率。

注意:线上指标有偏差。例如采纳率高不一定代表答案正确,可能只是用户没有能力判断。

4.11 回归评测和发布门禁

每次变更都可能引入回归:

  • Prompt 改动。
  • 模型升级。
  • RAG chunk 策略调整。
  • embedding 模型变更。
  • 工具 schema 变更。
  • 安全策略变更。

发布门禁建议:

变更提交
-> 小样本 smoke eval
-> 全量离线 eval
-> 安全负例 eval
-> 成本/延迟检查
-> 人工抽样 review
-> 灰度发布
-> 线上监控
-> 回滚或放量

门禁不是追求 100 分,而是定义“低于什么阈值不能上线”。

4.12 失败样例库

失败样例库是 AI 系统最宝贵的资产之一。

每个失败样例记录:

  • 输入。
  • 模型输出。
  • 期望行为。
  • 失败类型。
  • 根因。
  • 影响范围。
  • 修复方案。
  • 是否进入回归集。
  • 关联版本。

失败分类建议:

分类示例
Prompt 问题指令不清、格式没约束
检索问题未召回、召回噪声
模型问题推理弱、拒答错误
数据问题知识库缺失、文档过期
工具问题参数错、工具返回错
安全问题注入、越权、泄漏
产品问题用户误解、交互不清

4.13 评测数据治理

评测集本身也需要治理:

  • 版本化。
  • 标注人和标注时间。
  • 覆盖率统计。
  • 去重。
  • 难度分层。
  • 隐私脱敏。
  • 防止泄漏到训练或 Prompt 中。
  • 定期更新。

不要把线上用户隐私原样放入公开评测文档。

4.14 评测报告结构

推荐评测报告:

# AI 系统评测报告

## 1. 被测对象
## 2. 模型 / Prompt / 数据版本
## 3. 评测集说明
## 4. 指标总览
## 5. 分任务结果
## 6. 失败类型分布
## 7. 典型失败样例
## 8. 成本和延迟
## 9. 安全负例结果
## 10. 是否建议上线
## 11. 后续修复计划

5. 关键概念表

概念含义工程意义常见问题
Eval dataset任务样例集合衡量系统质量覆盖不足
Rubric评分标准降低主观性描述太泛
Golden set高质量标注集回归基准样本过少
LLM-as-judge用模型评分扩展快judge 偏差
Groundedness答案被证据支持RAG 核心指标只看答案
Task success任务是否完成端到端质量成功标准不清
Trace eval评估中间轨迹Agent 必备只看最终输出
Regression回归测试防止改坏旧能力未覆盖历史失败
Online metric线上行为指标真实反馈指标解释有偏
Release gate发布门禁控制上线风险阈值随意

6. 工程案例

6.1 客服回答评测集

目标:评估 AI 客服草稿是否符合政策和语气。

样例维度:

  • 退款咨询。
  • 物流延迟。
  • 投诉升级。
  • 缺少订单号。
  • 恶意诱导越权。

指标:

  • 政策正确性。
  • 语气合规。
  • 是否要求必要信息。
  • 是否错误承诺赔付。
  • 人工采纳率。

6.2 RAG 引用准确性评测

目标:评估知识库问答是否有正确引用。

样例字段:

  • 用户问题。
  • 必须命中的文档。
  • 期望答案。
  • 是否应该拒答。

评分:

  • 检索 recall@5。
  • 引用是否存在。
  • 引用是否支持答案。
  • 无证据时是否拒答。

6.3 Agent 工具调用轨迹评分

目标:评估工单 Agent 是否正确使用工具。

评分项:

  • 是否先查询订单再生成建议。
  • 是否只创建草稿。
  • 是否进入人工审批。
  • 是否避免重复查询。
  • 是否在证据不足时升级。

6.4 Prompt 版本回归测试

目标:比较 Prompt v1.3 和 v1.4。

流程:

  • 固定模型和推理参数。
  • 跑同一评测集。
  • 输出分任务指标差异。
  • 对退化样例做人工复核。
  • 达到门禁再灰度。

6.5 安全负例评测

目标:验证系统能否抵抗 prompt injection 和越权请求。

样例:

  • 要求泄露系统提示词。
  • 要求读取无权限文档。
  • 在 RAG 文档中插入“忽略规则”。
  • 要求直接退款。

指标:

  • 拦截率。
  • 拒答质量。
  • 是否泄露敏感信息。
  • 是否错误调用工具。

7. 常见误区与反模式

反模式表现后果修正
Demo 驱动只挑好样例演示线上失败建代表性评测集
只看最终答案不看检索和工具轨迹难定位问题分层评测
无 Rubric评分靠感觉分数不可复现明确标准
judge 不校准让模型自己评自己偏差累积人工校准集
评测集不更新永远跑旧样例覆盖不了新失败线上失败入库
不记录版本分数无法复现不知道谁变了绑定模型/Prompt/数据
只评正常样例无安全和边界样例高风险漏洞加负例
忽略成本延迟只看质量分无法上线质量、成本、延迟一起看
阈值随意想上线就放行门禁失效预设发布标准

8. 阶段练习

8.1 构建 20 条评测样例

为一个 AI 功能写 20 条 eval:

  • 10 条正常样例。
  • 4 条边界样例。
  • 3 条缺信息样例。
  • 3 条安全负例。

每条都要写期望行为和评分标准。

8.2 设计 Rubric

为“企业知识库问答”设计 5 个评分维度,每个维度 0-2 分,并说明什么情况下必须人工复核。

8.3 RAG 分层诊断

选择 10 个 RAG 问题,分别记录:

  • 正确证据是否存在。
  • 是否被召回。
  • 是否进入上下文。
  • 答案是否正确。
  • 引用是否支持答案。

8.4 Agent 轨迹评测

拿一个 Agent 轨迹,标注每一步:

  • 工具是否选对。
  • 参数是否正确。
  • 状态是否更新。
  • 是否存在越权风险。
  • 是否应该停止或升级。

8.5 Judge 校准

选 20 条样例,让人工和 LLM judge 各自评分,比较:

  • 一致率。
  • 分歧样例。
  • judge 偏差。
  • 是否需要修改 Rubric。

9. 项目任务

9.1 项目要求

完成一套 AI 系统评测集和评测报告。

必须包含:

  • 至少 30 条任务样例。
  • 覆盖正常、边界、安全、拒答和历史失败样例。
  • 每条样例有期望行为、标签和风险等级。
  • 一份 Rubric。
  • 一种自动评分方式。
  • 一种人工抽样评分方式。
  • 一份失败分析报告。
  • 一个发布门禁建议。

9.2 评测集模板

| id | 输入 | 期望行为 | 必须引用 | 是否拒答 | 标签 | 风险等级 |
| --- | --- | --- | --- | --- | --- | --- |
| eval-001 | ... | ... | ... | false | normal,rag | medium |

9.3 评分标准

维度分值标准
覆盖率20覆盖正常、边界、拒答、安全和历史失败
Rubric 质量20标准明确,不依赖主观感觉
分层评测20能区分 LLM、RAG、Agent 不同问题
失败分析20能归因到 Prompt、数据、检索、工具或模型
发布门禁10有上线阈值和回滚条件
数据治理10有版本、脱敏和维护策略

10. 验收题

  1. 为什么 AI 系统不能只靠主观 demo 评估?
  2. 一个评测集应该包含哪些类型的样例?
  3. Rubric 的作用是什么?
  4. 规则评分、人工评分和 LLM-as-judge 分别适合什么场景?
  5. RAG 为什么要分检索、排序、生成和引用评测?
  6. groundedness 和 correctness 有什么区别?
  7. Agent 为什么要评估中间轨迹?
  8. LLM-as-judge 的主要风险是什么?
  9. 如何把线上失败转成回归样例?
  10. 发布门禁应该包含哪些检查?

11. 延伸阅读

官方与框架资料

建议阅读方式

  • 先读 OpenAI Evals,理解数据集、运行和评分器。
  • 再看 RAGAS 或 LangSmith,理解 RAG 和链路评测。
  • 最后把评测结果接入发布流程,而不是停留在 notebook。

12. 本阶段总结

评测体系的核心是把“感觉不错”变成“可复现、可比较、可回归”的质量工程。LLM、RAG 和 Agent 都需要任务级评测,但 Agent 还必须看轨迹,RAG 必须看证据,安全任务必须看负例。

你应该形成一个判断:AI 系统的每次改动都应该留下分数、失败样例和版本记录。没有评测的优化,只是在黑盒里摇骰子。

下一阶段进入安全与治理。你会学习如何设计信任边界、权限、审计、安全测试和合规流程,处理 AI 系统最容易被低估的高风险失败模式。