6.8 AI 评估与测试

概述与动机

测试普通软件建立在一个令人安心的假设之上：给定相同的输入，程序会返回相同的输出，你可以精确断言这个输出应该是什么。人工智能打破了这个假设。同一个模型可以用两种不同的方式回答同一个问题，而两种方式都是可以接受的。它可以在「错误」到「出色」的谱系上被打分，而不是简单的通过或不通过。而且往往没有单一的正确答案可供断言。因此，评估（evaluation）这门学科（）衡量一个模型在许多具有代表性的用例中表现如何，而不是把一个输出与一个预期值作比对（）就成为任何值得信赖的 AI 系统的支柱。当团队发布的 AI 功能让自己难堪时，根本原因几乎总是他们在发布前没有一套认真的方法来衡量质量。

对大型团队而言，评估是让变更变得安全的东西。你会更换模型、重写提示词、调整检索、添加工具，而这些变更中的任何一个，都可能悄悄地让你以为稳固的行为退化。如果没有一种可重复的方式来衡量质量，每一次变更都是一场赌博，每一次退化都要由用户来发现。本章是构建类章节的度量配套篇：生成式 AI 与 LLM 应用（第 6.3 章）、AI 智能体与智能体系统（第 6.7 章），以及机器学习工程与 MLOps（第 6.2 章）。它把你通用的测试策略（第 2.4 章）延伸进了概率的世界。

企业和政府场景进一步抬高了风险。一家运行着数十个 AI 功能的企业，需要一个共享的评估平台，避免每个团队都从零开始重新发明打分方式。一个政府机构需要的评估必须是有文档记录、可审计的，因为「我们测试过了」必须变成「这是证据、数据集、指标和签核记录」。评估是负责任和值得信赖的 AI（第 6.5 章）不再只是一句价值宣言，而成为能够向监管者展示的东西的地方。

关键原则

把评估当作一等产品来对待，而不是在发布前临时粘贴上去的事后补充。
用能反映真实使用情况的代表性数据来度量，而不是用讨好模型的玩具示例。
把用于快速迭代的离线评估，与用于获取真实情况的在线评估结合起来。
以人类判断作为你的锚点，并对照它校准每一个自动化评分器。
保护你的评估集不受污染，否则你的数字会对你撒谎。
把评估接入持续集成作为关卡，让质量不能悄悄退化。
在生产环境中持续测量，因为即使代码不变，质量也会漂移。

建议

采用评估驱动开发

在调整提示词或挑选模型之前，先写好评估。这与测试驱动开发的思路一致：你先用可度量的方式定义「好」意味着什么，然后朝着这个方向构建。这里的评估，指的是一个输入数据集，配以一种打分方法，能为每个输出返回一个数字或等级。从小处开始。二十个经过精心挑选、能反映真实用户意图的用例，胜过一千个随机用例。随着你了解系统在哪里失败而扩展这个集合，把每一次生产环境中的失败都作为一个永久性用例添加回去，这样同样的错误就不会悄无声息地再次发生。

评估驱动开发会改变团队的行为方式。当「好」的定义被写下来并且可以运行时，关于某项变更是否有帮助的争论，就从品味问题变成了可核查的问题。把评估集当作一个经过评审的制品，放在版本控制中，就在它所度量的提示词和代码旁边。

区分离线评估和在线评估，两者都要用

离线评估在受控环境中，用一个固定数据集跑一遍你的系统，速度快、成本低、可重复，因此你可以在任何东西发布之前比较不同版本。在线评估通过任务完成率、升级处理率、点赞/点踩反馈和下游业务结果等指标，用真实用户来度量线上系统。离线评估告诉你一项变更大概率是否安全；在线评估告诉你它是否真的奏效。你两者都需要，因为离线数据集永远无法完全捕捉现实，而在线信号又来得太迟，不能作为你唯一的护栏。

把两者连成一个闭环。当在线指标下滑，或用户标记出一个糟糕的回答时，把这个用例捕获下来、打上标签，纳入离线数据集中。把实验纳入你用于任何产品变更的同一套受控比较流程，这正是产品分析与实验（第 7.4 章）的范畴。一次显示新模型提升了任务成功率的 A/B 测试，比任何离线分数都更有价值，然而正是离线分数让你敢于运行这个测试。

构建有代表性的评估集，并防范污染

你的评估，其诚实程度取决于其数据。构建黄金数据集（golden dataset）（）由经过审核的、带有预期输出或评分标准的输入组成的精选集合（）使其反映用户实际提问的真实分布：常见用例、罕见但关键的用例、对抗性用例，以及你的系统目前会答错的用例。对它们进行分层，这样你就能按细分维度读出质量，而不是让一个表现糟糕的类别隐藏在一个尚可的平均分之下。让领域专家审核预期答案，因为一个建立在错误答案之上的黄金数据集，比没有数据集还要糟糕。

然后要保护这份数据不受污染。当你的评估用例泄漏进模型的训练数据、或泄漏进提示词本身时，就会发生测试集污染（test-set contamination），这样模型看起来表现很好，只是因为它实际上已经见过答案。这就是为什么一个模型可以在公开基准测试上得分出色，却在你真实的流量上磕磕绊绊。把一部分评估数据保持私有，绝不要发送给你无法信任的第三方。随时间推移刷新数据集。警惕那种更隐蔽的泄漏：开发者针对评估集反复手动调优提示词，直到分数变得毫无意义，这是一种对测试本身的过拟合，而不是真正的改进。留出一份你只偶尔查看的新鲜留存集。

选择适合任务的指标

让你的度量方式与输出的形态相匹配。对于分类和抽取任务，那里存在一个正确标签，经典指标适用：精确率与召回率（在你标记出的条目中有多少是对的，以及在所有正确条目中你找到了多少）、平衡两者的 F 值，以及精确匹配准确率。对于任何自信概率很重要的场景，要度量校准度，即声称的 80% 置信度，是否真的在大约 80% 的时候是对的，因为一个校准良好、知道自己何时不确定的模型，远比一个过度自信的模型更安全。

生成式输出更难处理。像 BLEU 和 ROUGE 这样基于参照文本的指标，最初是为机器翻译和摘要任务构建的，它们通过统计重叠的词语和短语，把生成文本与参照文本作比较。它们成本低、可重复，但同时也是质量的弱代理指标：它们奖励表面上的重叠，却惩罚那些措辞与参照文本不同的正确答案。把它们当作粗略的回归信号来使用，而不是把它们当作「好」的定义。对于开放式任务，基于评分标准（rubric）的打分效果更好：定义明确的标准（是否有依据、是否完整、是否安全、格式是否正确），并逐项打分。评分标准让主观质量变得清晰可辨、可供评审。

使用 LLM 作为评判者，但要对照人类进行校准

靠人工逐一为生成式输出打分是无法规模化的，因此团队越来越多地使用一个强大的大语言模型作为自动化评判者，向它输入输入内容、输出内容和一份评分标准，让它给出评分。这种「LLM 作为评判者（LLM-as-a-judge）」的方法速度快、能力也出人意料地强，但它也携带着必须加以管理的真实偏见。评判者往往偏好更长的答案，在成对比较中偏爱先出现的选项（位置偏见），偏好与自己写作风格相似的内容，并且可能被流畅但错误的推理所左右。如果不加约束，一个有偏见的评判者会给你自信、精确、却错误的数字。

要对照人类标签校准这个评判者。让人来给一个样本打分，然后检查模型评判者与人类的一致程度有多高，并持续调整评判者的提示词，直到一致程度高到可以信赖为止。有意识地减少已知偏见：随机化选项顺序，控制长度因素，要求给出带理由的、锚定在评分标准上的分数，而不是一个孤零零的数字。把这个评判者当作一个需要定期重新校准的测量仪器，而不是一个固定不变的神谕。在构建这个评判者时，默认选用现有能力最强的模型，因为一个弱的评判者就是一把不准的尺子。

让人类留在闭环中，提供真实基准

人类评估仍然是每一个自动化指标据以校准的锚点，因此值得投入精力把它做好。撰写清晰的标注指南，培训你的标注员，并度量标注者间一致性（inter-annotator agreement），即独立评审者对同一用例给出相同评分的程度。一致性低通常意味着你的评分标准存在歧义，而不是你的评审者粗心大意，因此要修正评分标准本身。对于高风险领域，使用合格的专家，而不是缺乏足够背景来判断法律或医疗答案的众包工作者。

进行红队测试以保障安全性和对抗鲁棒性

标准评估集衡量的是系统在合理输入下是否做对了事情。红队测试（）刻意攻击自己的系统，找出它出问题的地方（）衡量的是系统在压力下会发生什么。探测提示注入、越狱、不安全内容、隐私泄漏和带偏见的输出。把它做成一套可重复的测试套件，而不是一次性演练：把每一次成功的攻击都变成一个永久性的回归用例，这样一个已修复的漏洞就能保持已修复的状态。这项工作与负责任和值得信赖的 AI（第 6.5 章）直接相关，在受监管的场景中，它往往就是能够通过安全评审的证据。

通过端到端任务成功率来评估智能体

那些需要规划并执行多个步骤的智能体，不能逐一输出地去评判。真正重要的是整个任务是否成功：智能体是否正确且安全地预订了会议、解决了工单，或完成了整个工作流程。在一个沙盒环境中构建任务级别的评估，让智能体针对逼真但安全的测试夹具执行操作，并同时为最终结果和轨迹（trajectory，即它为达成结果所走过的步骤和工具调用序列）打分。一个通过危险或浪费的路径得出的正确答案，依然是一个问题。这对 AI 智能体与智能体系统（第 6.7 章）至关重要，在那里，一次错误的动作可能带来真实的后果。

把评估接入 CI，并监控生产环境

让评估自动化。在每一次提示词、模型或检索方式发生变更时，都在持续集成（CI）中运行你的离线测试套件，并像对单元测试设关卡一样，对合并设关卡，这一做法根植于你更广泛的测试策略（第 2.4 章）。由于分数存在噪声，应基于阈值和趋势来设关卡，而不是要求一次完美的运行，当关键指标跌破底线或退化超过设定的幅度时，就让构建失败。然后持续监控生产环境：监控质量信号、输出分布和输入漂移，这样你才能捕捉到离线测试会漏掉的缓慢退化，这与机器学习工程与 MLOps（第 6.2 章）的可观测性实践相衔接。一个在发布时准确的模型，会随着它所描述的世界在其底层发生变化而逐渐退化。

权衡：优点与缺点

评估方法	优点	缺点	最适用场景
人类评估	保真度最高，能捕捉细微差别	速度慢、成本高、难以规模化	获取真实基准、高风险场景、校准评判者
LLM 作为评判者	速度快、成本低，可扩展到大规模数据集	存在偏见，需要校准	对生成式输出进行频繁的离线运行
基于参照的指标（BLEU、ROUGE）	成本低、确定性、可重复	对真实质量的代理性弱	粗略的回归信号，而非最终定论
经典指标（精确率、召回率、F 值）	客观、被广泛理解	只适用于有正确标签的任务	分类、抽取、检索
公开基准测试	可跨模型比较，无需搭建	存在污染，与你的任务契合度差	早期模型初筛，而非发布关卡
在线评估（A/B 测试、反馈）	反映真实用户和结果	速度慢，在暴露之后才出现	确认一项变更确实起到了作用

核心张力是速度与保真度之间的权衡。人类评估最值得信赖，也最难规模化；自动化打分则正好相反。解决方案是把它们分层使用：用快速、廉价的方法进行持续迭代，通过定期校准把这些方法锚定到人类判断上，并把完整的人工评审留给风险最高的决策，以及用来检查你的廉价指标是否仍然贴合现实。第二个张力是离线的便利性与在线的真实性之间的权衡。离线数据集让你能够快速前进，但永远无法完全反映生产环境，因此应把一个强劲的离线分数当作运行一次谨慎的在线测试的许可，而不是「已经完成」的证明。

与团队讨论的问题

我们对「足够好」的标准是什么，谁拥有那个定义这个标准的评估集？ 每一个 AI 功能都有一个隐含的质量门槛，而当它一直隐含不明时，每个工程师就会凭感觉自行设定标准，争议则由房间里资历最高的人来裁决。把这个标准写成一个可运行的评估集，并为每个细分维度设定目标分数，就能把这些争议变成可度量的问题。带上你当前对「成功」的定义、支撑它的数据，以及一份关于谁实际维护它的诚实说明，因为一个无人负责的评估集，会像任何无人打理的代码一样迅速腐烂。决定这个标准是否应按风险等级而不同，因为一个面向公众的法律回答，理应比一个内部头脑风暴辅助工具清过更高的门槛。这个答案应当告诉你，目前是否有人可以在没有任何度量挡在他们和用户之间的情况下，发布一项 AI 变更。
我们如何知道自己的评估数字是诚实的，而不是被污染或过拟合的？ 一个分数只有在能够预测真实世界质量时才有用，而它失去这一能力的方式有很多：基准数据泄漏进训练集、开发者针对测试集反复调优提示词直到数字变得毫无意义，或者一个建立在从未被核实过的答案之上的黄金数据集。带上关于你的评估数据来源的证据、其中有多少被保持私有，以及它多久刷新一次。讨论你是否保留一份很少查看的新鲜留存集，这样你至少有一个没有人针对它优化过的数字。如果你无法解释为什么你的分数在模型从未影响过的数据上依然成立，那么你度量的只是自己的倒影。
人类在哪些环节留在闭环中，我们如何让自动化评判者始终对齐人类的判断？ LLM 作为评判者以及基于参照的指标，让你能够进行规模化打分，而它们会以一种如果不检查就看不见的方式，逐渐偏离人类的判断。带上你目前自动化打分与人类评审之间的一致率、你上一次测量这个一致率是什么时候，以及你已经测试过哪些偏见（长度、位置、风格）。决定哪些决策无论成本如何都需要人类评分员，通常是风险最高的那些，以及用来重新校准自动化评判者的那些。也谈一谈标注质量，因为一个针对不一致的人类标签校准出来的评判者，会继承那份不一致。这个答案应当产出一份重新校准的日程安排，而不是一次性的祝福。
今天哪些 AI 变更被评估卡关，哪些仍仅凭某人的信心就抵达用户手中？ 一个只在部分变更上运行、而在另一些变更上不运行的关卡，给你的是一种安全的错觉，而真正的退化会从那条未设关卡的路径悄悄溜过：一次不起眼的提示词微调、一次检索调优、一次没有人觉得算作变更的模型版本升级。对大型团队而言，能接触提示词的人越多，这种危险就越大，因为每一条未设关卡的路径，都是一种发布出没有任何数据集见过的退化的方式。带上目前会触发持续集成中离线测试套件的变更类型清单、不会触发的类型清单，以及最近几起被追溯到未设关卡变更的事故。决定这个关卡应执行什么样的阈值和趋势判断，因为一个有噪声的分数需要一个底线和一个退化幅度限制，而不是要求一次完美的运行。在企业和政府场景中，把这个关卡与发布记录本身挂钩，这样「一项变更曾被测量过」的证据，就成为审计记录的一部分，而不是某人曾经截过的一张屏幕截图。
我们在评估上花了多少钱，这笔支出是否与每个功能的风险相匹配？ 评估不是免费的：标注人工、自动化评判者在每次运行中消耗的算力，以及持续维护黄金数据集代表性的日常工作，都要花真金白银，而一个从不说清这些成本的团队，往往要么在高风险功能上投入不足，要么在一个可有可无的功能上过度打磨。这里的竞争性拉力存在于保真度和预算之间，因为最值得信赖的方法（）专家人工评审（）也是最难规模化的，因此你无法在所有地方都负担得起它，必须决定它在哪里能挣回它的成本。带上目前每次评估运行的成本、每个功能的标注工时，以及每个系统的诚实风险等级，这样房间里的人就能看清钱花在了哪里，与危险实际存在于何处相比是否匹配。对企业而言，这是建立一个能在众多团队之间分摊标注和算力成本的共享评估平台的最有力论据；对政府机构而言，风险等级应当直接对应监督机构日后会要求的证据深度。
当一个更好的模型出现时，我们能多快证明它是否真的更好，谁有权作出切换的决定？ 一套评估体系的价值，在一个更强模型发布的那一天体现得最为鲜明，因为一个能在一个下午内，把自己的黄金数据集和红队测试套件跑在新模型上的团队，能够采用一些靠人工打分的团队会错过数月之久的改进。这里的张力在于速度与谨慎之间：你希望在一个更好的模型出现的当天就行动起来，同时又不能让一次切换悄悄地让某个类别的答案退化，而这退化又被你的平均分掩盖了。带上你目前完成一次针对新供应商的完整离线比较所需的时间、你的评估集在不同模型之间是否可移植，以及哪些细分领域一旦出现退化会最为要紧。在受监管和公共场景中，明确指出谁拥有批准模型变更的权限，以及他们要求什么样的文档证据，因为在一个面向公民的决策背后，未经记录地更换模型，正是审计者会要求你作出解释的那种变更。

行业视角

初创企业。 构建你能做到的最小、最诚实的评估，让它随着产品一起成长。一个包含二十到四十个真实用例、每个都有经过审核的预期答案的电子表格，由一个脚本在每次合并前运行，胜过任何针对你这个细分领域的公开基准测试，且几乎不花钱。在人工打分真正开始带来痛苦之前，跳过共享平台和 LLM 评判者，但从第一天起，就把每一个用户报告的失败都折回到评估集中，因为正是这种反射动作，才能阻止同样的尴尬重演一次。

小型企业。 你大概没有专门的评估专家，你的 AI 能力是内嵌在你所购买的工具里的，因此你的工作是要求证据，而不是自己构建评估。问每个供应商他们是如何衡量质量的，他们是否在类似你这样的数据上测试过，以及在一次你没有选择的更新之后，你要如何察觉退化。保留一份小小的、由你自己的真实用例组成的私有数据集，自己去抽查这个工具，因为一个触及客户的错误自动化答案，代价远比这项检查所花的几分钟要高得多。

企业。 最大的收获是一个共享的评估平台，让十几个团队不必各自重新发明打分方式：一个存放黄金数据集的公共仓库、在持续集成中设关卡的离线测试套件、带有校准分数记录的 LLM 评判者提示词，以及按功能划分的在线指标。在此之上叠加治理层，用风险等级来设定发布前所需的门槛和签核，让一个高风险功能清过比一个内部辅助工具更高的关卡。这个平台把标注和算力成本分摊到各个团队之间，这正是搭建一个平台、而不是让每个团队自行摸索的最有力理由。

政府。 评估必须是可审计的，而不仅仅是「做过了」，因此要为每一次发布归档数据集版本、指标、评审者姓名和签核记录，作为问责证据。一套红队测试套件应当证明系统会拒绝在其来源资料之外，凭空编造政策或法律条文，而采购流程应当要求供应商披露他们是如何评估模型的，并授予你评估数据的可移植性。当一个监督机构问起你如何知道这个工具是安全的时，答案必须是一份有日期的记录，而不是一句安慰的话。

示例

初创企业。 一家构建 AI 合同审查助手的四人公司，从一份包含四十个真实条款的电子表格开始，每个条款都由他们的内部律师标注上应当标记出的风险。每一次提示词变更在合并前都会针对这个集合跑一个脚本，分数会打印在合并请求（pull request）中。当用户标记出一个被遗漏的条款时，它会直接被加入表格，因此这个集合随着产品一起成长。随着量的增加，他们加入了一个 LLM 评判者来为解释质量打分，但只有在核实过它与律师的判断在一个样本上一致之后才这样做。低成本、私有且诚实，胜过任何针对他们这个细分领域的公开基准测试。

企业。 一家大型银行在客户支持、搜索和内部工具上运行着十几个 AI 功能，而每个团队之前的打分方式都各不相同。他们搭建了一个共享评估平台：一个存放黄金数据集的公共位置，在 CI 中运行离线测试套件，登记带有校准分数的 LLM 评判者提示词，并按功能追踪在线指标。治理层建在这之上，用风险等级来设定发布前所需的门槛和签核。一个新的反欺诈解释功能，直到其评估集经过评审、其红队测试套件通过、其负责人签核结果之后，才能发布。复用这个平台意味着团队争论的是各自的业务领域，而不是该如何度量。

政府。 一个公共卫生机构部署了一个助手，帮助工作人员根据经批准的指南回答福利相关问题。由于一个错误答案可能影响某人的资格认定，评估必须是可审计的。每一次发布都会运行一个有文档记录的评估集，涵盖常见问题、边缘用例和对抗性提示词，而结果、数据集版本、指标和评审者姓名都被归档作为问责证据。一套红队测试套件核查系统是否会拒绝在其来源资料之外凭空编造政策或法律条文。当一个监督机构问起该机构如何知道这个工具是安全的时，答案是一份有日期的记录，而不是一句安慰的话。

商业案例：动机、投资回报率与总拥有成本

评估让每一项其他的 AI 投资都变得更安全、更快，从而收回自身的成本。它的投资回报率（ROI）体现在更少的生产事故、因为团队能够放心地修改提示词和模型而带来的更快迭代速度，以及在更好的模型到来的当天就能采用它们的能力，因为你能够证明它们是否真的更好。衡量其价值最清楚的方式，是评估「缺席」时的代价：一次公开的幻觉、带偏见的输出或数据泄漏，其补救成本、信任损失和监管风险，远高于多年的评估基础设施投入。这就是在 CI 中免费发现一个退化，与在报纸上发现它之间的差别。

总拥有成本（TCO）是真实存在的，值得明确说出来。你要为标注人工付费，为自动化评判者消耗的算力付费，还要为随着使用方式变化而持续维护评估集代表性的日常工作付费。在企业规模上，一个共享平台可以把这些成本中的大部分分摊到众多团队之间，这正是搭建一个平台、而不是让每个团队自行摸索的最有力理由。要向领导层说明这一点，可以把一个具体风险（你所在领域中一个糟糕的公开答案的代价）与一项具体能力（安全采用每个新模型的速度）配对呈现，并把评估定位为那个能让组织快速前进而不至于鲁莽行事的控制手段。

反模式与陷阱

凭感觉发布。 通过手动尝试几个提示词来判断 AI 变更，没有数据集，也没有可重复的分数。
基准测试表演。 把一个亮眼的公开基准测试分数当作系统契合你任务的证明，而忽视了污染和分布不匹配的问题。
对评估集过拟合。 针对同一个固定集合反复调优提示词，直到数字很高却毫无意义，没有新鲜的留存集。
未经校准的评判者。 部署一个 LLM 评判者，并信任它的分数，却从未核查过它与人类评分员的一致程度。
指标崇拜。 把优化 BLEU 或 ROUGE 当成优化质量本身，发布那些恰好与参照文本重叠、实则更差的答案。
一次性红队测试。 在发布前攻击系统一次，此后从未把发现的问题变成永久性的回归测试。
只信离线分数。 相信一个好的离线分数就意味着这个功能能用，却从不在线上度量真实的结果。
无人认领的评估集。 没有人拥有的数据集，从不吸收生产环境中的失败案例，慢慢不再反映现实。

成熟度模型

第 1 级，启动： AI 变更靠手工在几个示例上作出判断，被动地、只在有人碰巧担心时才进行。没有数据集、没有可重复的分数，也没有关卡。退化由用户发现，没有人能说清系统是比上个月更好还是更差。
第 2 级，发展： 一些团队保留着小型黄金数据集，在重大变更前手动运行它们，也存在一些经典指标或基于参照的分数。重要功能会经过人工评审，但打分方式在团队之间并不一致，评估没有被自动化或设关卡，各个团队各行其是。
第 3 级，标准化： 离线测试套件在每一次提示词、模型或检索方式变更时都在持续集成中运行，并给合并设关卡，遵循组织内统一的成文实践。LLM 评判者已针对人类标签进行了校准，红队测试是一套可重复的测试套件，数据集有专人负责、有版本控制，并由生产环境中的失败案例持续补充，污染被主动防范。
第 4 级，管理： 评估被以数据的方式度量和控制，并对照基线进行检验。评判者与人类的一致率、红队测试通过率、按细分维度划分的分数、在线任务成功率和漂移都被持续跟踪，合并的关卡基于阈值和退化幅度，而不是要求单次完美运行。标注成本和每次运行的算力开销按功能编列预算，重新校准按日程进行，每个结果都由一位负责人签核。
第 5 级，协同： 一个共享评估平台服务于整个组织，离线和在线评估构成一个与业务结果挂钩的持续闭环。新模型在到达的当天就能针对可移植的评估集得到验证，评估组合随使用情况和风险的变化而调整，评估证据对监管者和监督机构而言是可审计的，一个团队从失败中吸取的教训会流入到每个团队的数据集中。

供讨论的思路

你如何决定一个离线分数何时已经足够强，值得开展一次在线实验，何时还不够？
对你的风险画像而言，人类评估与自动化打分的合适比例是多少，应该多久重新审视一次？
当一个公开基准测试和你的私有评估集在哪个模型更好这件事上产生分歧时，你信哪一个，为什么？
你如何在用户行为发生变化时保持评估集的代表性，同时又不让它膨胀到在 CI 中跑不动？
对你所在领域而言，一套红队测试套件应当包含什么，谁有资格设计这些攻击？
你如何评估一个智能体的轨迹，而不只是它的最终答案，同时又不被给每一步打分的成本淹没？

关键要点

AI 评估与软件测试不同，因为输出是非确定性的，而且很少存在一个唯一正确的答案，所以你要在具有代表性的用例中度量质量，而不是断言精确的值。
践行评估驱动开发：先定义可度量的质量标准，再朝着它构建，并把每一次生产环境中的失败都折回到评估集中。
按速度和保真度分层使用方法：用廉价的自动化打分进行持续迭代，以人类判断为锚点，并通过校准让它们保持对齐。
防范污染和过拟合，否则你的数字会讨好你，而真实系统却在让用户失望。
把离线评估作为关卡接入 CI，并持续在生产环境中度量质量和漂移，因为一个在发布时表现良好的模型也可能会退化。

参考资料与延伸阅读

Chip Huyen, AI Engineering: Building Applications with Foundation Models.
Lianmin Zheng 等，Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.
Kishore Papineni 等，BLEU: A Method for Automatic Evaluation of Machine Translation.
Chin-Yew Lin, ROUGE: A Package for Automatic Evaluation of Summaries.
Percy Liang 等，Holistic Evaluation of Language Models (HELM).
Deep Ganguli 等，Red Teaming Language Models to Reduce Harms: Methods, Scaling Behaviors, and Lessons Learned.
OWASP Foundation, OWASP Top 10 for Large Language Model Applications.
National Institute of Standards and Technology, AI Risk Management Framework.