第 3 章 评估设计

学习目标

• 构建既能代表真实使用分布，又单独涵盖边界案例和罕见高风险案例的评估集。
• 比较代码评分、LLM 评分和人工评分的优缺点，并为每项标准选择合适的评分方式。
• 对照人工评分校准 LLM 评分器，甄别分数的提升是否属于真正的改进。
• 区分能力评估与回归评估、离线评估与在线指标的作用，并进行协同设计。
• 按类型解读评估结果，并结合依据在发布、有条件发布和搁置之间做出决断。

引言

某团队在部署咨询机器人的新提示词时这样说道：“我们测试了十个示例，效果明显变好了。”一周后，却发现机器人唯独在涉及海外订单咨询时会提供错误的运费指引。而在那十个示例中，根本没有包含任何海外订单。OpenAI 将这种方式称为“凭感觉评估（vibe-based evals）”，并将其列为典型的失败模式之一。

评估是通过数字确认 AI 功能质量的唯一方法，而这些数字正是判断是否发布的依据。因此，评估设计绝非只是开发人员的事。明确了何为成功（第 2 章）的产品经理，还必须负责明确用什么样的数据和评分方式来验证这种成功。OpenAI 提倡尽早、频繁开展评估的“评估驱动开发”，并指出评估不是一蹴而就的任务，而是一个持续推进的过程。

本章从如何构建评估集切入，探讨三种评分方式及其选择顺序，以及如何让 LLM 评分器变得值得信赖。接着区分能力评估与回归评估、离线评估与在线指标，最后介绍如何解读评估结果并做出发布判断。

核心概念

什么是评估

评估（eval）是衡量模型或功能表现的结构化测试。OpenAI 的定义也是如此。评估由三部分组成：相当于考题的评估集、用于判卷的评分方式，以及相当于及格线的成功标准。

打个比方，评估就像驾照考试。考试路线（评估集）必须贴近真实路况，考官（评分方式）必须保持一致，及格线（成功标准）必须预先设定。如果考试路线只有停车场，那么即便通过考试，上了路也会发生事故；如果考官全凭心情打分，同样的水平就会得到截然不同的评价。

评估流程的五个阶段

OpenAI 将评估流程分为五个阶段：

1. 定义评估目标。 想要验证什么？这源自第 2 章中的成功标准。
2. 收集数据。 验证该目标需要哪些数据？
3. 定义指标。 如何确认成功标准是否达成？
4. 运行与对比。 运行评估并对比不同版本。
5. 持续评估。 每次发生变更时都重新运行评估。

前一阶段的产出即为下一阶段的输入。若没有目标就去收集数据，便无从知晓该收集什么；若没有数据就设定指标，便无从知晓指标该依附于何处。若缺失最后一步，评估就会沦为发布前走过场的一次性活动，之后的变更又将重回凭感觉判断的老路。

评估集的代表性

Claude 文档中的首要评估设计原则是“贴合任务”。这意味着评估必须反映真实任务的分布。OpenAI 同样将未能真实复现线上流量模式的评估集列为名为“有偏设计”的失败模式。

确认代表性最简单的方法是使用对比表。

若在这样的表格中发现巨大偏差，评估得分便无法体现真实表现。团队成员凭空构思的问题往往多为表达规范的完整句子，而真实用户提问时则充斥着缩略语、错别字以及多种语言混杂的表达。评估集的基石必须是从真实请求中随机抽取的样本。

边界案例与罕见高风险案例

仅有代表性样本是远远不够的。Claude 文档指出评估中务必加入边界案例，并列举了四种典型情形：无关或不存在的输入、过长的输入、针对聊天场景的劣质、有害或无关的用户输入，以及连人工判断都会产生分歧的模糊案例。OpenAI 也建议在评估数据中同时囊括典型案例、边界案例与对抗性案例。

人们往往容易出于“评分不一致”的借口而想将模糊案例剔除。然而，在实际运行中最容易出错的恰恰就是这类案例。切勿将其剔除，而应打上独立标记纳入其中，单独观察该分组的结果。

那些虽然发生概率低但潜在损失巨大的案例（紧急诉求、安全相关提问、大额交易），在随机样本中往往只会零星出现几次。发生率为 0.4% 的类型，在包含 1,000 条样本的集合中大概仅有 4 条左右，根本无法据此判定该类型的表现。这类案例需要专门收集并整理成数量充足的独立分组，与总分分开独立判定是否合格。

评估集的来源与规模

评估数据可来源于多种渠道。OpenAI 列举了运行日志、领域专家创建的数据、合成数据以及采购的数据，并建议在开发过程中保留日志以挖掘优质的评估案例。

关于规模，需要兼顾“多多益善”与“从小处着手”。Claude 文档指出，如果能够进行自动评分，即便单次评分的精度略低，题目数量多的方案也胜过由人工手动评分的少数高质量评估。Anthropic 关于智能体评估的文章指出，从实际失败中提炼出 20~50 个简单任务就是一个良好的开端。从小规模起步，依靠线上运行中发现的失败案例不断扩充，才是一条切合实际的路径。

留出集与过拟合

如果对着同一套评估集反复修改几十次提示词，提示词就会特化迎合该集合，导致得分虚高于真实性能。这就像提前看过考题后去复习的学生，其成绩无法说明真实水平一样。

Google PAIR 指南解释道，测试集必须保留模型从未见过的数据，才能获知其真实运行效果如何；Claude 文档中的基准示例也是在留出测试集（held-out test set）上判定性能的。在实际工作中，评估集通常一分为二：修改时参考的开发集，以及修改时不看、仅用于最终判定的留出集。如果开发集的分数大幅上升，而留出集的分数却原地踏步，那么这种提升极有可能只是迎合特定数据集的结果。

三种评分方式

Claude 文档将评分方式分为三类：

Anthropic 关于智能体评估的文章也做了类似的总结：代码评分快速、便宜、客观且可复现，但在面对与标准答案语义相同仅表述不同的正确回答时表现脆弱；模型评分的结果可能每次略有差异，因而需要与人工评分进行校准；人工评分虽然堪称金标准（gold standard），却既昂贵又迟缓。

评分方式的选择顺序

Claude 文档的原则是“选择最快、最可靠且最具扩展性的方法”。针对每项标准，按以下顺序进行考量：

1. 是否有预设的标准答案可供比对？ → 代码评分。
2. 是否需要判断，但能够写出评分标准（rubric）？ → LLM 评分（与人工对照验证可靠性后使用）。
3. 是否尚未建立评分标准，或需要专业判断？ → 由人工对代表性样本进行评分，从而建立基准（评分标准与基准数据）。若是难以转化为明确标准的专业质量维度，则直接将专家的双盲对比本身作为发布前的评估手段。

即便在同一项功能内部，不同的标准所适用的方式也不尽相同。以退款指引回复为例，“金额是否与订单系统数值一致”由代码评分负责；“政策解读是否正确”和“语气是否契合规范”则交给提供了评分标准的 LLM 评分器；而评分器的校准以及模糊案例则交由人工处理。若企图用单一方式去评判所有标准，势必会在成本或可靠性之中痛失其一。

让 LLM 评分器变得值得信赖

Claude 文档列举了 LLM 评分的三大诀窍：提供详尽且清晰的评分标准（rubric）；要求具体的输出格式，如“正确/错误”或“1~5分”；要求在给出分数前先进行推理。该文档的示例代码中还说明，通常建议使用与生成结果的模型不同的另一模型来进行评估。

[评分标准示例：退款指引回复的政策解读]
正确(correct)：根据下单日期、商品状态和支付方式，准确告知了退款可行性及退款期限。
错误(incorrect)：退款可行性或退款期限与政策不符，或额外添加了政策中不存在的条件。
若难以判定，则判定为“unsure”。
输出要求：先用一两句话写明判断依据，最后一行仅输出 correct / incorrect / unsure 中的一项。

单凭评分标准还不够。OpenAI 提出，应通过人工评估来校准自动评分，并且只有当 LLM 评分器在保持更快、更便宜的同时，能够与人工判断持续保持高度一致时，再扩大应用规模。具体步骤如下：首先由人工对照评分标准对代表性样本进行评分；接着使用 LLM 评分器对相同样本进行评分并查看一致性；针对存在分歧的标准修订评分标准；当一致性超过目标值后推广至全量样本使用，但仍须定期抽样与人工重新对照。

LLM 评分器存在已知的固有偏见。OpenAI 列举了 LLM 评分器因回复呈现顺序而产生的位置偏差（position bias），并推荐采用更可靠的成对对比（pairwise comparison）或合格/不合格判定方式。采用成对对比时，可以通过调换两个回复的顺序进行两次评分，以减轻位置偏差。此外，无论内容如何都倾向于认为长回复更好的倾向（长度偏差）也十分普遍。因此，当分数出现大幅跃升时，首先应当亲自阅读评分日志。Anthropic 指出，如果不亲自阅读多次尝试的日志与得分，就无法确认评分机制是否真正有效运作。

人工评分的定位

“能避免人工评分就尽量避免”并不意味着要彻底摒弃人工评分。在以下三个场景中，人工评分必不可少：初期制定评分标准并建立基准数据时、校准 LLM 评分器时，以及在没有固定标准答案且需要专业判断的发布前对比中。

人工评分同样需要管理其一致性。Google PAIR 指南解释说，发现人类在解读标签方式上的差异，有助于模型开发更好地应对现实世界的复杂性。可以让两名评估人员分别独立对相同样本进行评分并查看一致性，随后共同研读出现分歧的案例以完善评分标准。在对比两个版本时，采用评估人员不知晓各自对应哪个版本的并排双盲对比，能够有效减少偏见。

能力评估与回归评估

Anthropic 根据评估目的将其分为两类：

在能力评估中表现已足够优异的任务，可以“毕业”进入回归分组，通过持续运行来监控性能是否出现退化。对于通过了能力评估中所有可解任务、无法再体现出改进空间的状态，Anthropic 称之为“评估饱和”。饱和的评估会丧失区分度，因此需要用从线上运行中发现的新失败案例来补充高难度任务。

离线评估与在线指标

离线评估是利用预先准备的评估集，在不直接向用户提供服务的情况下衡量结果的评估方式。这种方式高效且可重复执行，但无法获知评估集未涵盖的情况以及真实的用户行为。在线指标则是在实际运行中衡量的指标，如重新生成点击、转接人工客服、流失、举报、购买转化等。

Anthropic 阐述道，最高效的团队往往会将多种方法结合使用：快速迭代使用自动评估，确认实际成效使用线上监控，在流量充足时验证重大变更使用 A/B 测试，针对自动评估遗漏的盲区使用用户反馈和日志审查，而校准则采用定期的人工审查。

若离线评分表现良好但在线指标未有起色，这便是一个信号：说明现实中存在评估集尚未覆盖的情况。此时应当阅读真实日志，找出被遗漏的情形并将其补充进评估集。

单次成功与每次成功

在对同一任务进行多次尝试时，统计成功的方式也会根据需求而有所不同。Anthropic 将在 $k$ 次尝试中至少成功一次的概率表述为 pass@k，而将 $k$ 次尝试全部成功的概率表述为 pass^k。如果每次尝试的成功概率均为 $p$ 且彼此独立，那么 pass^k 就是 $p$ 的 $k$ 次方。因此，即便单次成功率达到 90%，连续三次成功的概率也仅有约 73%。如果是人工从多个候选项中择一的功能（如文案候选建议），pass@k 更为适用；而如果是客户每次都必须获得同等质量回复的功能（如自动应答智能体），pass^k 才是合适的指标。即便得分相同，具体衡量的是什么也会直接影响发布判断。

基于评估结果判断是否发布

拿到评估结果后，在查看具体数值之前，首先需要确认三件事：

1. 评估集是否能代表真实情况。 如果缺乏代表性，即使分数再高也无法作为依据。
2. 评分是否可靠。 LLM 评分器是否与人工评分进行了对照？分数的提升是否是由回复长度等无关因素引起的？
3. 是否在留出集上进行了验证。 仅在开发集上上涨的分数可能属于过拟合。

通过这三项确认后，再按类型研读结果。即便总分超过了标准，也可能存在某些特定类型严重未达标的情况。此时通常有三种选择：

如果某项功能的核心价值（例如：缩减咨询处理时长）必须在发布前得以验证，就应将该标准纳入阻断标准，而非作为改进目标。NIST AI RMF 明确要求判断系统是否达成了预期的目的与目标，并据此决定是否推进开发或部署（MANAGE 1.1）。这一判断必须依据查看结果前已达成共识的标准来做出。如果在查看结果之后再去制定标准，往往会演变成为了迁就数字而修改标准。

评估计划书

评估计划书通常浓缩为一页纸：

[评估计划书]
目标功能与版本：
成功标准（源自第 2 章）：阻断标准 / 改进目标
评估集：来源、规模、各类型构成（对比实际比例）、边界案例分组、高风险分组、从各分组中留出的留出集
评分：各标准对应的评分方式（代码/LLM/人工）、LLM 评分器校准方法与一致性目标
回归分组：构成、执行时机（每次变更时）、通过条件
在线指标：发布后关注的指标及告警标准
判定规则：发布 / 有条件发布 / 搁置的条件
进度安排与负责人：

深入阅读

分数上升就意味着变好了吗

当收到评估分数上升的汇报时，需要按顺序逐一排除四种可能性。第一，评分器可能奖励了无关的特征。回答变长导致 LLM 评分器分数上升是常见现象。需由人工直接抽检阅读日志样本进行确认。第二，可能只是针对同一测试集进行了针对性修改。需查看在保留集上是否同样有所提升。第三，评估集可能发生了变更。增删题目都会改变分数的含义，因此必须保留版本记录。第四，可能属于随机波动。需多次运行相同的评估，以掌握波动的幅度。

排除这四种可能性之后剩下的上升，才是真正的改进。遵循这一顺序的团队，遇到“分数上升了但客户抱怨依旧”这种情况的概率要低得多。

评估集的生命周期

评估集并不是创建一次就大功告成的资产。OpenAI 将评估称为一段历程而非终点，并建议随着时间的推移不断扩充评估集；Anthropic 则警告称，饱和的评估无法展现改进的空间。评估集的生命周期如下：

1. 从 20～50 个真实失败案例和代表性样本开始。
2. 将线上运营中发现的新失败案例添加到回归集中。
3. 将已经掌握良好的能力任务“毕业”转移至回归集中。
4. 当用户和输入的分布发生变化时，重新抽取代表性样本。
5. 保留版本记录，以便与以往的结果进行对比。

“一旦创建就不再更改”的原则虽然出于保持可比性的良好初衷，但却会导致在分布已经改变的世界里，继续拿着陈旧的试卷进行考试。可比性应通过版本管理来维持，而评估集则应持续扩充。

线上指标的归因问题

上线后指标向好，并不能直接断言是该功能的功劳。因为在同一时期内，季节、活动、其他功能的变更可能同时发生。Google SRE 指出，时间是改变观测指标的最大因素之一。上线前后的对比可能会将工作日与周末、活动期间与平时混在一起进行比较。

若要将效果归因于该功能，必须在同一时期内将用户随机分为能看到该功能的人群和看不到该功能的人群进行对比。因此，对业务指标的效果需要通过 A/B 实验来衡量。若流量不足，实验的统计功效就会不够，此时应结合运营指标、日志审查和用户访谈一并分析，并在汇报时降低结论的确定性。

工作场景

绿道单车的故障报修机器人

共享单车服务“绿道单车”开发了一个接收故障报修的对话机器人。开发团队使用团队成员编写的 200 条问题进行评估，并汇报了 95% 的准确率。产品经理在看数字之前先核实了三件事。

首先是代表性。查看实际报修日志后发现，有 35% 是一张照片加上诸如“这个不行”之类的简短语句，但评估集中完全没有这类报修。产品经理从过去两个月的报修记录中随机抽取了 400 件，重新构建了评估集。其次是高风险案例。刹车故障报修仅占总量的 1%，但必须对这类单车立即暂停运营。团队单独收集了 80 件刹车报修，将“遗漏停运指引为 0 件”设为单独的合格标准。

评分按标准进行了区分。故障部位分类通过代码与正确标签进行比对；引导语的亲和度则由给定评分量表的 LLM 评分器打分，但事先与维修组长评分的 100 件案例进行了比对校准。重新评估的结果是整体准确率为 88%，而在刹车测试集中有 3 件遗漏了停运指引。被否决的方案是“整体准确率超过了 85% 的基准，因此可以上线”。由于刹车测试集未能达到单独标准，团队加入了一条规则：一旦出现与刹车相关的表述，不再由机器人处理，而是立即转入停运流程；重新评估通过后才正式上线。

别册书斋的图书简介

出版社“别册书斋”需要在用 AI 撰写新书简介功能的两个版本中二选一。该任务没有正确标签，简介写得好不好需要由编辑来判断。由于尚未上线，也无法推送给读者。

产品经理首先挑出了可以使用代码评分的部分。作者姓名、出版日期、页数是否与图书信息一致，通过代码进行核验。其余的“是否歪曲了图书的核心内容”和“能否激发阅读欲望”，则由三位编辑在不知道具体是哪个版本的情况下，对 60 本新书的两个版本进行并排盲测对比。每本书呈现的先后顺序都会轮换，以减少位置偏差。

编辑们在 60 本书中选择 B 版本更佳的有 41 本，而歪曲案例 A 版本有 7 件，B 版本有 2 件。团队最终选择了 B 版本，并将三位编辑的 180 次判定（60 本 × 3 人）整理为评分量表，决定今后在使用 LLM 评分器时先与该判定进行对照校准后再投入使用。被否决的方案是“通过读者点击率进行 A/B 实验”。因为当时尚未上线，而且点击率无法反映内容是否存在歪曲。团队决定在上线后将点击率作为单独的线上指标进行追踪。

易错点

1. “用几个示例确认一下就足够了。” 凭感觉进行评估是典型的失败模式。必须拥有能代表真实分布的评估集。
2. “排除模棱两可的案例，评分才干净利落。” 模棱两可的案例是现实中最常出错的边界案例。应做好标记并单独观察。
3. “整体准确率高，罕见类型就没问题。” 仅占 0.4% 的高风险类型会被淹没在整体分数中。必须设立单独的测试集和单独的标准。
4. “人工评分太贵，所以不用。” 人工评分只是不用在全量数据上，但在基准数据与评分器校准中是必不可少的。
5. “LLM 评分分数上升了，说明变好了。” 未经校准的评分器可能会奖励长度等无关特征。必须阅读日志并与人工评估进行比对。
6. “用同一个评估集不断修改就会更稳妥。” 这样只会导致对该测试集过拟合。最终判定必须使用保留集。
7. “评估集一旦创建就不再更改。” 可比性通过版本来维持，而评估集则要依靠运营中发现的失败案例来扩充。
8. “上线后指标变好，归功于该功能。” 若要剥离同一时期的其他因素，必须进行随机对照比较。

要点速览

查阅官方文档

• Claude Docs — Define success criteria and build evaluations：评估设计原则、边界案例、三种评分方式及 LLM 评分要诀。
• OpenAI — Evaluation best practices：评估流程五步骤、评估驱动开发、失败模式、人工校准、位置偏差。该页面虽同时注明 OpenAI 的 Evals 平台将于 2026 年 10 月 31 日转为只读、11 月 30 日停运，但其阐述的原则与具体平台无关。
• Anthropic — Demystifying evals for AI agents：能力评估与回归评估、pass@k 与 pass^k、评分方式的优缺点、评估饱和、方法的组合。
• Google PAIR Guidebook — Data Collection + Evaluation：测试集、代表性、标签解读的差异。
• Google SRE Workbook — Canarying Releases：对照组比较与时间因素。
• NIST AI RMF — Core：MANAGE 1.1（达成目标与是否推进部署的判定）、MEASURE 2.4（运行中的监控）。

自测

3-1. 请按顺序写出 OpenAI 阐述的评估流程五个步骤。

3-2. 请写出 Claude 文档建议纳入评估的四种边界案例。

3-3. 请分别用一句话写出代码评分、LLM 评分和人工评分的局限性。

3-4. 准备对图书借阅引导机器人的回答中的“归还截止日期”和“引导语气”进行评估。请分别选择符合这两项标准的评分方式并说明理由。

3-5. 请对比能力评估与回归评估的目的及预期通过率，并说明能力任务转移至回归集的时机。

3-6. 开发集分数从 70% 上升到 93%，但保留集分数仅从 71% 上升到 73%。此时应该怀疑什么？

3-7. 针对由人工从多个候选结果中挑选一个的功能，以及客户每次都必须获得同等质量回答的功能，请分别写出适合两者的成功率统计方式。

3-8. （设计题）请按照本章格式为您当前负责的一项 AI 功能编写评估计划书，并在每个成功标准（准入阻断标准与改进目标）后各附上一行评分方式及其理由。

实操练习