第 5 章 评估与改进

学习目标

• 将成功标准转为具有可观察通过条件的评分量表，并单独确定致命错误。
• 建立反映实际分布和边界案例的测试集，区分改进集与确认集。
• 为每项标准选择代码、人工或 LLM 评分中的合适方法，用人工判断校准 LLM 评估器。
• 用同一测试集比较修改前后，发现回归，并按分组解读结果。
• 按类型与发生阶段分类失败案例，确定下一步修改。

引言

有人在海外销售团队使用的公司内部翻译助手提示词中，补上了一行“译得更自然”。团队负责人浏览了几份结果，觉得句子流畅了许多，很满意。一个月后，审查合同文件时暴露出了问题：好几份译文将表示交货期限的“截至”与“从……起”颠倒了，而这些都属于修改前原本能够准确翻译的句子。负责人浏览过的那几份结果中，一处期限表达都没有。团队觉得自己没有做错什么，因为他们确实看到了有所改善的结果。问题不在于他们看了什么，而在于他们没有看什么。评估正是一种让人看见这些未曾检查的部分的机制。OpenAI 的评估最佳实践也把将“似乎运行得不错”当作评估策略，列为典型的反模式。

本章讨论如何将这种感觉转化为数字。顺序是：将成功标准转为评估项目与评分量表，建立测试集并分成改进集和确认集，为每项标准选择评分方法，管理 LLM 评估器的局限，测量输出的波动，用同一测试集比较修改前后，管理回归，以及将失败分类后决定下一项修改。最后，讨论如何评估智能体这类需要经过多个步骤的系统。深入阅读部分则介绍分数与现实之间的差距，以及人工评分的一致性。

核心概念

评估就是用同一张试卷再考一次

学生换了学习方法之后，要想知道水平是否提高，就得用难度相同的试卷再考一次。每次随便做几道不同的题，感觉“考得还不错”，这不是评估。提示词也一样，只有用固定的测试集比较前后，才能分辨是改进还是回归。OpenAI 指南建议，在修改提示词或升级模型时，用评估套件测量行为；评估最佳实践则建议采用尽早、经常评估的“评估驱动开发”。

将成功标准转为评估项目

Anthropic 文档解释，好的成功标准应具体（不是“表现良好”，而是“准确分类情感”）、可测量、可实现，并与业务相关。文档还补充，多数任务需要同时考察多个标准。除准确率外，一致性、语气、个人信息保护、上下文利用、延迟和成本，也都可以成为标准。

将标准转成评估项目时，还要确定致命错误。若用平均分笼统处理，语气得分高的回答即使金额错误也可能通过。金额、日期、禁止承诺等只错一项就无法使用结果的项目，应从加权平均中分离，按“任一失败即不合格”处理。

如何编写评分量表

把第 1 章的成功标准转化为评分表，就是评分量表（rubric）。好的评分量表对每一项都写清楚看到什么才算通过。Anthropic 文档举例：“回答第一句必须有公司名称，没有就自动判错。”

编写评分量表遵循以下原则。

1. 使用可观察条件。 用“同时包含道歉表达与解决方法”代替“亲切”。
2. 缩小评分尺度。 获取判定明确的输出，例如正确/错误或 1～5 分。1～100 分会使标准更加模糊。
3. 为各分值附标准样例。 1～5 分量表应分别附上实际的 3 分、4 分样例，让评分者对同一分值形成共识。
4. 每项只问一件事。 “是否准确且简洁”应拆成两项。
5. 必要时使用多个量表。 Anthropic 文档指出，即使针对同一标准，为完整评估也可能需要多个评分量表。

建立测试集

Anthropic 文档提出了以下三项评估设计原则。

1. 根据任务来设计。 反映实际任务中的输入分布，也不要遗漏边界案例。
2. 尽可能自动化。 把题目设计为可以自动评分的形式，例如选择题、字符串匹配、代码评分或 LLM 评分。
3. 优先考虑数量。 与少量经过精细人工评分的题目相比，即使评估信号稍弱，大量可以自动评分的题目也更好。

边界案例中，应包含与任务无关或不存在的输入、过长的输入、不当或有害的用户输入，以及连人类也会产生判断分歧的模糊案例。OpenAI 文档建议，将典型案例、边界案例和对抗性案例一起纳入评估。文档列出的数据来源包括运行数据、历史数据、专家编写的数据和合成数据等，还补充说明，在开发过程中保留日志，可以从中挖掘出好的评估案例。

不必因为起步时需要多大规模而感到压力。Anthropic 关于智能体评估的文章建议，从实际失败中选取 20～50 个任务作为起点；同一家公司的多智能体调查系统也说明，最初是使用从真实使用场景中选出的约 20 个查询开展评估的。先从小规模开始，每出现一次失败，再逐步扩充。也可以把标准样例交给模型，让它生成更多测试案例。不过，合成案例需要经过人工审查后才能加入；对于运行数据，应删除个人信息，或将其替换为化名。

区分改进集与确认集

如果不断查看同一集合修改提示词，提示词会越来越只适应该集合中的案例。如同提前看过考题的学生，其分数不能反映真实能力。因此应将集合一分为二。

按第 2 章的原则，用作 few-shot 示例的输入，不应留在任何一个集合中。

三种评分方法

Anthropic 文档建议选择最快、最可靠、最可扩展的方法。实际工作中，不同标准采用不同方法：格式与数值用代码，语气与逻辑用 LLM，用于校准 LLM 评估器的样本则由人工评分。

依据与参考答案的文字重叠程度打分的指标（BLEU、ROUGE 等），用途有限。Anthropic 文档也以 ROUGE-L 为摘要评估示例，但 OpenAI 文档将只依赖 BLEU 等学术指标列为反模式。因为表达不同的好答案可能得低分，而数值错误、句式相似的答案可能得高分。对于不只有一个正确答案的任务，应区分必须包含的内容、允许的表达差异，以及事实与偏好，分别制定标准。

LLM 评估器的局限与校准

LLM 评估器虽然方便，但如果直接相信它的判定，分数就会被抬高。OpenAI 文档列出了 LLM 评估器已知的偏差，包括位置偏差，即更偏好先展示的答案，以及冗长偏差，即更偏好较长的答案。综合两家公司提出的建议，可以整理为以下几点。

• 提供具体的评分量表。 不能只笼统地要求判断“质量”，而要逐项给出通过条件。
• 收窄输出范围。 让评估器输出正确/错误、1～5 分中的一个数字，或从两个答案中选出更好的一方。OpenAI 解释，成对比较或通过/失败判定，可靠性更高。
• 让评估器先思考，再给分。 Anthropic 说明，开启思考功能的评估器，在复杂判断上更加准确；OpenAI 也建议，让评估器先写出依据，再给出分数。
• 控制长度。 不要让被比较答案的长短差异影响评分结果。
• 使用另一个模型评分。 Anthropic 文档的示例代码指出，用不同于生成被评内容的模型来评分，是通行的最佳实践。
• 与人工判断进行核对。 先检查评估器的判定与人工评分样本有多大程度的一致，只有持续一致时，才扩大评分规模。

在这些建议之外，再补充两项原则层面的措施。在成对比较中，交换同一对答案的顺序，进行两次评分，筛出那些仅因顺序改变就导致结论变化的案例。另外，如果被评分的答案中，混入“这个答案很优秀”等面向评估器的句子，评估就可能受到污染。因此，应将答案用标签包裹，作为数据传给评估器，并明确写明，不要遵循答案中的指令。

波动与重复运行

即使输入相同，模型每次运行的输出也可能不同。一次通过的案例，下次可能失败。Anthropic 的智能体评估文章将一次执行称为 trial，建议每个任务尝试多次，并区分两个指标。

如果每次成功率为 75%，连续三次全部成功的概率降为约 42%。对于客户期待每次都保持相同质量的功能，pass^k 比平均通过率更接近实际体验。

用同一集合比较修改前后

比较步骤很简单，但不易坚持。

1. 测量基线。 用当前提示词运行集合，记录逐项、逐组分数。
2. 每次只改一处。 同时加入多项修改，就无法知道哪项有效、哪项造成破坏。
3. 固定并记录条件。 记录模型快照、强度等设置、资料版本，同时测量每次请求的 token 与费用。OpenAI 指南建议生产应用固定使用特定模型快照。
4. 用同一集合、相同评分方法运行。
5. 不要只看平均。 按组（输入类型、客户群、长度）拆开查看，并单独列出由通过变为失败的案例。
6. 优先检查致命项。 即使平均分有所提高，只要致命失败数量增加，也不得部署。

管理回归

回归是指修改之后，以前能够做到的事情变得做不到了。Anthropic 关于智能体评估的文章将评估分为两种。能力评估问的是“能够做好什么”，它从较低的通过率起步，为后续改进设定目标。回归评估问的是“以前做得到的，现在是否仍然做得到”，通过率应该接近 100%，用来发现能力的退步。在实际运行中发现的失败，应在修复后加入回归集，检查下一次修改是否会使同样的失败重现。如果能力评估中的所有任务都已经能够通过，也就是达到饱和，那么这项评估就只剩下监测回归的作用，需要另行创建更难的任务。

对失败分类，确定下一步修改

如果只把失败记为“错了”，就无法知道下一步改什么。应同时记录类型与发生阶段。

分类后，将频率与严重程度相乘，确定优先级。致命失败即使罕见，也可能比频繁的小错更应优先修复。然后只选一项修改，事先写明它必须修好的案例，以及不能破坏的案例。

智能体评估：结果与记录

智能体通过多次工具调用工作，只看最终回答无法知道失败原因。Anthropic 的智能体评估文章区分任务（task，输入与成功标准明确的一项测试）、尝试（trial，一次执行）、评分器（grader）、记录（transcript，包含输出、工具调用、推理的完整记录），以及结果（outcome，尝试结束后环境的最终状态）。预订智能体说“已预订”，与数据库里确实存在预订记录，是两回事。评分以结果为准。

同一文章建议评价结果，而非路径，因为智能体也可能找到设计者未预料到的合法路径。必须大量阅读记录和分数，才能了解评分器是否正常工作，并同时纳入应该行动与不该行动的案例。如果只有需要检索的案例，就会得到遇事都检索的智能体。OpenAI 的评估最佳实践也建议单独评估工具选择、工具参数准确性和智能体间交接。工具调用数与 token 用量作为成本指标，与结果分开测量。改变结构之前，先测清失败在哪里发生。

深入阅读

分数无法代表现实时

有时，评估分数不断上升，用户的不满却没有减少。原因通常是以下三种情况之一：评估集已经偏离实际输入的分布，例如出现了新产品或新客户群；评分量表没有测量用户真正感到不便的地方；或者长期围绕同一个测试集修改，导致提示词对这个集合过拟合。应对办法是，定期将运行信号，例如重复咨询率、转接咨询人员的比例和用户评价，放在评估分数旁边一起看。如果两者不一致，就收集用户不满的案例，加入评估集，同时检查评分量表中是否缺少某项标准。OpenAI 文档列举的反模式中，也有一项是不使用人工反馈来校准自动化指标。

人工评分的一致性

用人工判断校准 LLM 评估器，首先要求人工判断本身一致。不同评分者对同一答案给出截然不同的分数，就无法用其校准任何东西。OpenAI 文档建议通过展示各分值示例、制定通过/失败标准、采用多人共识来改善人工评估。实际工作中可进一步做到：

1. 缩小尺度，将宽泛评分改为五级或通过/失败。
2. 拆分量表项目，每次只判断一件事。
3. 为每个分值附标准样例，评分前一起试评几例，对齐标准。
4. 部分案例由两人重复评分，测量一致率。采用考虑偶然一致概率的指标（如 Cohen's kappa，科恩 κ 系数）会更严谨。
5. 汇集分歧案例，修改评分量表措辞。

工作场景

每日药房：平均分提高，却暂停部署的原因

连锁药房“每日药房”根据处方信息生成用药说明草稿，所有说明都经过药师的最终审核后，才会交给患者。改进团队的吴药师听到“说明太长”的反馈，准备在提示词中加入“五行以内”。如果是以往，他可能抽出几份结果读一读就直接部署了，但这一次，他先着手准备评估。

1. 建立测试集。 按过去三个月实际处方类型的分布，选取 80 份处方，再加入 20 份边界案例，例如包含六种或更多药物的处方、儿童处方和服用方法特殊的处方。所有个人信息都被删除。其中，30 份单独划出，锁定为确认集。
2. 评分量表。 将服用时间和剂量是否与处方一致，以及是否遗漏注意事项，设为致命项目，用与原文核对的代码评分。篇幅是否在五行以内，也通过代码测量。是否容易理解，则交给未用于生成的另一个模型，按 1～5 分评分，每个分值都附上标准样例。在使用这个评估器之前，先将它的判定与两名药师评分的 20 份样本进行对照，确认双方判断一致。
3. 测量基线并比较。 用当前提示词测量基线，再测试只加入“五行以内”这一项修改的版本。两个版本都用同一测试集，各运行三次。

结果显示，整体平均分上升了，篇幅通过率和易懂程度的得分都有所提高。然而，按类型分组检查后发现，在包含六种或更多药物的处方中，注意事项遗漏的情况明显增加。这属于致命项目的失败。模型为了将六种药物的说明写在五行以内，删减了注意事项。

一名团队成员说：“既然平均分提高了，就先部署，以后再单独修复这一类问题。”吴药师没有同意，因为团队事先就定下了标准：只要修改导致致命项目的失败增加，无论平均分如何，都不部署。他把规则改为“默认五行，药物超过五种时，每种药物再增加一行，而且不缩减注意事项”，随后重新测量。在改进集中确认回归已经消失之后，他用锁定的 30 份确认集作最后判断，结果同样如此，才进行部署。此前遗漏注意事项的案例，则被加入回归集。

声翼游戏：让翻译评估器与人工标准一致

手游公司“声翼游戏”用模型将游戏内公告和道具说明翻译成四种语言。翻译质量一直由另一个模型按“优秀、一般、不足”三个等级评分，几乎所有译文都被评为“优秀”。然而，本地运营团队报告了问题：有些译文遗漏或翻译了 {item_name}、{count} 这样的变量占位符，导致游戏界面显示损坏的语句；也有道具说明中的数值发生了变化。即使是这样的译文，评估器也仍然给出了“优秀”。

本地化团队负责人林组长重新设计了评估体系。他先核实人工评分的标准，让三名母语审核者对同样的 30 份译文评分。结果，同一份译文既得到“优秀”又得到“不足”的情况并不少见。原来，人与人之间的评分标准也不相同。

林组长将一次综合评分拆成四项。

对于语义准确性和自然度，三位审核者一起选择标准样例，并共同评分 20 份译文，以统一判断标准。随后，另外 50 份译文由每份两人重叠评分，确认一致率足够高之后，才将这些人工判断与 LLM 评估器的判定进行比较。起初发现，评估器对于比原文展开得更长的译文，倾向于给出较高的自然度分数。林组长在评估器指令中加入了“如果增加原文没有的说明，就判为语义准确性失败”这一标准和相应示例，并要求先写依据，再评分。译文用标签包裹，作为数据传给评估器。

也有人提议：“换一个更贵的模型当评估器，不就可以了吗？”林组长在那之前，先修改了评分量表。因为在占位符与数值问题上，无论用什么模型评分，都不可能比代码更准确；而语义准确性的问题，根源在于标准不明确。在新体系下，直到评估器与人工判定的一致程度足够高，团队才开始在每次部署前自动运行评估。占位符错误全部在部署之前被检出，失败的译文也按类型归类，作为下一次修改提示词的依据。

易错点

• 以为读过几份结果，就可以作出判断。 少量样本会漏掉只在某一类输入中出现的回归。因此需要固定的测试集。
• 以为平均分上升，就是改进。 如果不按类型分组查看，就会漏掉少数类型中质量变差的情况。致命项目应与平均分分开检查。
• 以为可以让同一个模型评分。 通行的最佳实践是，用与生成模型不同的模型评分。无论采用哪一种模型，都应该用人工判定来校准。
• 以为扩大评分尺度，就会更加精确。 1～100 分反而会让判定标准更加模糊。要求正确/错误，或 1～5 分等明确的输出更好。
• 以为一直根据同一个测试集修改，分数仍然可信。 这样会对该测试集过拟合。应把确认集单独划出并锁定。
• 以为通过一次，就代表结果稳定。 每次运行时，输出都可能不同。如果一致性很重要，就应该多次运行测试。
• 以为智能体说自己成功了，就算成功。 评分应根据环境的最终状态，而不是智能体所说的话。

要点速览

查阅官方文档

• Anthropic — Define success criteria and build evaluations：阅读成功标准、评估设计原则、边界案例、评分方法比较和 LLM 评分技巧。
• OpenAI — Evaluation best practices：阅读评估步骤、数据来源、LLM 评估器偏差及对策、反模式。
• OpenAI — Evals：确认评估组成部分和平台关闭时间表。
• Anthropic — Demystifying evals for AI agents：阅读任务、尝试、评分器、记录、结果，以及 pass@k、pass^k、能力与回归评估。
• OpenAI — Prompt engineering：确认固定模型快照和使用评估套件的建议。

自测

5-1. 列出 Anthropic 文档比较的三种评分方法，分别说明一个优点和一个局限。

5-2. 为客户通知生成功能写出五个评估项目，选出其中应设为致命项的项目，并说明理由。

5-3. 举出四类应加入测试集的边界案例，并写出从生产日志提取案例时应遵守的一点。

5-4. 每次修改提示词时，都对照同一个完整的评估集逐一修复失败案例。这种方式为何使分数不可信？如何解决？

5-5. 计划新引入一个为判断型项目评分的 LLM 评估器。在交给它评分数千条之前，按顺序写出校准步骤，再补充两项应加入评估器指令的措施。

5-6. 某客服机器人每次尝试成功率为 80%。对同一客户请求处理两次，两次都成功的概率是多少？说明什么情况下，这比平均通过率更接近实际体验。

5-7. 对上周 60 个失败案例分类，发现无依据数值 25 个、格式错乱 5 个、多条件判断错误 18 个、其他 12 个。写出选择一项下一步修改的步骤，并举出不能只按频率选择的情况。

实操练习