跳转至

09 · 评测：怎样知道系统真的学会做事

演示里，政策助手引用了一份文件，还回复“工单已创建”。点开引用却是旧制度，后台也没有工单。如果评测只看回答是否流畅，这次运行甚至可能拿到高分；检查办法需要能看到这些具体失败。

本章从可接受终态出发，学习定义任务成功条件，把检索错误、决策错误与执行错误分开，再手算指标。读完应能解释一个分数的分母、适用范围，以及它还没检查什么。建议先读 RAG和规划与协作，熟悉被评测的执行过程。

先定义成功，再看演示

继续使用内部政策助手：员工问某项报销是否符合当前规则，证据不足时创建人工工单。检查一次运行，需要同时看回答内容和环境实际结果，评测模型、工具与运行时共同组成的系统。先固定任务及其成功条件，再记录每次尝试，由评分器判断相应证据；这几项分开保存，才能重新检查一次“通过”是怎么判出的。一手依据：Anthropic 的评测术语与终态定义

先为各类请求定义验收合同：

请求 可接受终态 不可接受行为
有权限、政策有效、证据充分 回答符合政策，引用可定位的有效段落 引用过期政策或把推测说成规定
找不到足够证据 说明缺什么；按流程澄清或转人工 编出政策细节
需要创建工单且获批准 后端存在一个对应意图的工单 只输出成功文字，或重复创建
没有文档权限 不返回受限正文与可泄漏内容 先交给模型再要求它保密

可接受拒答比例应结合实际需求定义，不能一概追求最低。

把系统拆成可定位的指标

最终正确率下降时，先找错误首次发生的位置：文档是否已入库、查询者能否访问、候选是否包含证据、重排是否保留证据、模型是否正确使用证据、工具是否执行成功。

层次 记录什么 能解释什么
检索 query、文档版本、相关性标注、排名 有没有把需要的证据带回来
决策与参数 允许的动作、实际动作、校验结果 有没有选错工具或传错对象
执行与终态 操作 ID、尝试次数、后端对象 声称完成与真实完成是否一致
回答 关键主张、引用、支持关系 证据有没有被误读或夸大

Trace 应记录可观察事件和状态，排错不要求获取模型隐藏的思维过程。保留版本与关联 ID，并控制日志正文的敏感信息范围。Trace 的 span/关联概念见 OpenTelemetry 官方说明。

走一遍检索指标

假设一个查询的完整相关文档集合是 {A,C,D}，返回排名是 [B,A,C]，取前 3 条。标注按文档计数，返回列表无重复。

  1. 前三条命中 A、C，共 2 条。Precision@3 = 2/3，分母是返回槽位数 3。
  2. 共有 3 条相关文档，只找到 2 条。Recall@3 = 2/3，分母是标注相关文档总数。
  3. 第一条相关文档在第 2 位。单题 RR@3 = 1/2。若另一题前三条没有相关文档，其 RR 为 0；两题 MRR@3 = (1/2+0)/2 = 1/4。
  4. 采用二值 gain（相关为 1，否则 0）与 log2(rank+1) 折扣：DCG@3 = 0 + 1/log2(3) + 1/log2(4)。理想前三位全相关，IDCG@3 = 1 + 1/log2(3) + 1/log2(4)，因此 nDCG@3 ≈ 0.530721。

拿着同一份结果表，各指标会看不同位置：RR 找首个命中，之后漏掉 D 也不影响这个数；Recall 数找回了多少相关文档，不关心 A 和 C 谁在前；nDCG 则同时考虑相关性与排名。算完以后用一句话说出它在检查什么，比只记缩写更有用。

它们可以类比成同一张检查单上的不同栏：一栏查首个有效结果，一栏查覆盖量，一栏查排序；某一栏好看，其他栏仍可能有问题。这个类比只帮助选择指标，各栏的数值不能随意互换。本章明确使用二值 gain，不能与分级相关性或不同 gain 的实验直接比较；折扣和理想排序归一化可对照 scikit-learn 官方说明。

如果某题没有任何相关文档，Recall 和 nDCG 的分母问题需要单独处理。本仓库算例返回 null，再由评测设计声明汇总方法；随手填满分会改变汇总含义。无答案问题仍有可验收行为，例如正确拒答，不能因为检索指标无法照常计算就跳过它。

相关性标注本身也要检查是否完整。漏标了相关文档时，算出的 Recall 只反映当前标注集合，不能据此声称找全了所有真实相关材料。

运行并核对输出：

python3 examples/foundations/math_lab.py --section metrics

完成率、成本与延迟也要写清口径

假设 100 个任务中，80 个可答、20 个不可答；可答中 64 个答对，不可答中 14 个正确拒答，所有样本都有已判定终态。则可答正确率 64/80=80%、不可答正确拒答率 14/20=70%、总体决策正确率 (64+14)/100=78%。若遗漏超时任务，成功率就会被高估。

“每个成功任务成本”可定义为整个集合所有尝试的总费用除以成功任务数；费用包含最终失败的调用与重试。没有成功任务时不可除以零，应报告成本和零成功状态。实际费用按供应商当时的输入、输出、缓存与工具收费分别计算。

延迟应说明从何时开始、到首字还是到终态、是否包含排队与重试。本章若使用 nearest-rank 分位数，20 个已排序耗时的 p95 是第 ceil(20×0.95)=19 个值；其他统计库可能插值。20 次小实验不足以稳定刻画真实长尾，更不能把本地脚本毫秒数当线上 SLO。

数据集与评分器怎样不骗自己

开发集用于调提示、工具与规则；保留集在策略确定后检查泛化，不逐题调答案。近重复问题、同源改写按组划分，避免相同信息泄漏到两边。真实模型有随机性时，记录每题重复尝试与波动；脚本确定性测试则主要检查实现合同。

对象数量、引用 ID 是否存在、参数类型是否合格，可以先用程序检查。开放式回答可让模型按明确 rubric 辅助评分，再对照人工标注校准；评分器也要接受检查。

例如候选回答只换了展示顺序，Judge 的偏好是否跟着变化？这类测试能帮助发现评分偏差，分数本身仍不能直接解释为正确概率。原研究观察到位置、冗长和自我偏好等偏差，具体适用范围应按实验判断。MT-Bench / Chatbot Arena 原研究

动手验证

自己标注 6 个政策查询：2 个可答、2 个无证据、2 个无权限。每条写输入、允许证据、正确终态和禁止副作用。给其中一个检索结果故意漏掉相关文档，再分别检查检索指标和回答。验收：能指出失败层，不用一个总分解释所有错误；数字注明是这 6 个教学样本。

自检与参考答案

1. Recall@5 提高，最终答案一定更好吗？

不一定。增加的候选可能被错误重排、占满上下文、包含冲突材料，或生成阶段误读。需同时检查证据有效性和最终回答。

2. 一次运行打印“已创建”，可以把任务判为成功吗？

不可以仅凭文字判定。应在与该业务意图对应的后端终态检查对象是否存在、内容是否正确及是否重复。

3. 自动测试全绿，等于课程知识和真实 LLM 都正确吗？

不等于。代码测试只验证覆盖到的实现与算例；知识还需来源审阅；模型能力与线上行为还需要相应任务、环境与实测。

参考资料 · 上一章 · 下一章 · 课程目录

配套面试练习

先合上正文讲一分钟，再用追问和案例检查理解。每题都可以跳回对应学习内容。

展开本章相关面试题