评测：证明它真的有效

这个阶段为了什么，又会怎样失败

“划定范围”一章收尾时，留下了一个用发起人的话写成的阈值，以及一个归客户所有的留出集。那是一个承诺。这个阶段让它能跑起来：一批案例，每个案例配一个评分器，再加上一个无论谁来跑都得出同样结果的数字。这样，关于智能体够不够好的争论，就变成了关于评测的争论，而后者是可以了结的。

对这个想法最有力的表述来自供应商一侧。负责 OpenAI 前线部署工程的 Colin Jarvis 讲过他团队的规矩：一段模型写的代码，“在你有一套验证其有效性的评测之前，基本上就不算完成”（Altimeter 访谈，2025 年 11 月；T4，供应商的信条，引自视频的自动生成字幕）。OpenAI 的企业指南把“从评测开始”列为第一条经验，并描述了摩根士丹利最早的三项评测：翻译、摘要，以及“人类训练师”，后者把模型的回答与资深顾问的回答相比较（OpenAI，AI in the Enterprise；T2，供应商描述自己的客户）。

证据很单薄。关于交付中的评测，公开材料几乎都是 T2（供应商谈自己的工作）或 T4（从业者谈自己的工作）；没有独立研究表明哪些做法能预示通过。下文是这些叙述一致认同的做法：值得照做，但未经证实。

评测在交付中会以三种方式失败。

供应商给自己的工作打分。FDE 写案例、定标注、报分数，于是每一次通过都只是供应商的说法。划定范围阶段已经定下了解法：由客户标注并保管留出集。本章讲的是，在三个月里顶住要求你变通的压力，让这一点始终成立。

指标是通用的。团队采用了一个现成的忠实度分数，只因为工具里正好有。教授评测实践的 Hamel Husain 对此说得很直白：通用评测“当你把它们当作质量度量时，只会浪费时间，制造虚假的信心”（Husain，LLM Evals FAQ，2026 年 9 月；T4）。客户同意的不是忠实度分数，而是“至少和我的资深理赔员一样准”。

早期的数字被当成了终点线。智能体在头几周就达到 80%，大家松了一口气，结果剩下的那段距离才是大部分工作。9.6 节讲的就是这段爬坡。

合成案例：五个案例，然后是停滞

评测在智能体之前就开始了，出自设定标杆的那些人之手，并随着真实的失败不断扩充。第 4 周的坏消息带着一个计划而来，所以它换来了一份合同，而不是丢掉一份。

从五个开始，出自他们的专家

第一个评测集很小，而且来自客户。Jarvis 描述 OpenAI 与一家欧洲半导体公司做验证工作的第一步，是“和客户的专家一起，基本上就是定一组五个”（Altimeter 访谈，T4）。五个不是样本，而是一场对话：在任何人有原型要辩护之前，用专家自己的话把“对”写下来。

要那种能区分专家和新手的案例。“给我一个简单的”换来的是模型已经能答对的案例。“给我一个新员工会弄错的，并告诉我为什么”换来的是智能体必须复现的推理，而且常常会挖出一条没人写下来的规则。在合成案例里，埋在邮件往来中的律师函就是这样的案例：没有哪本手册提到它，而每位资深理赔员都知道。

每个案例写成四行：文档、正确的队列、专家的一句话理由，以及这条理由隐含的规则。规则这一栏，就是你那份“应写进代码而不是提示词”的检查清单的开端；下一章会把它们构建出来。

每个案例都必须是专家意见一致的。Anthropic 关于智能体评测的工程指南把这条检验说得很好：“一个好的任务，是两位领域专家各自独立判断时会得出相同通过/不通过结论的任务”（Anthropic，Demystifying evals for AI agents，2026 年 1 月；T4，供应商指南）。如果客户的两位专家对某个案例意见不一，它暂时就不该进评测，而应该进一份留给阈值负责人的问题清单，因为这种分歧是政策问题，不是模型问题。

在这五个之前，还有一个更便宜的检查值得做。Jarvis 描述过先用手工试一遍来检验一个用例到底可不可行，“N 取 10”，并得出结论：如果它“成功七八次，那么也许这个在生产中能行”（T4）。它告诉你的是该不该开始，而不是做没做完。可行性检查悄悄变成了验收测试，团队就是这样凭十个例子上线的。

从真实的失败中扩充

五个案例定义了“对”。它们说明不了智能体会怎样出错；要知道这一点，你需要让它在真实输入上跑起来，并且有人去读它做了什么。

各方在规模上意见一致，尽管全都是供应商或从业者的建议。Anthropic 说：“从真实失败中抽取 20 到 50 个简单任务，就是很好的开始”（T4）。Eugene Yan 在谈产品评测时写道：“我通常建议，在 200 个以上的样本中至少要有 50 到 100 个失败”，而且他偏爱自然发生的失败，而不是编造出来的：“我觉得这些合成的缺陷有问题”（Yan，Product Evals in Three Simple Steps，2025 年 11 月；T4）。Husain 建议至少审阅 100 条轨迹，每条标为通过或不通过，因为“二元评测迫使思路更清晰、标注更一致”（T4）。

在交付中，真实输入通常分两个阶段到来。拿到读取权限之前，你手里是数据接入那一章讲的脱敏导出和脱敏测试样本，它们适合用来构建，却很难暴露失败：没有人会在清洗数据时把那些古怪的案例留下来。权限一到，就跑一个影子运行：智能体处理实时的工作，输出不送给任何人，每个输出都与人工的实际处理相比对。每一处分歧都是一个候选失败。影子运行是你能得到的最好的评测来源，它所需的审查，安全那一章从第 1 天就已经启动。

然后去读这些失败，并给它们分类。团队常常跳过这一步，而时间恰恰花在这里。Husain 说，在过去的项目里，“我们把 60% 到 80% 的开发时间花在了错误分析和评测上”（T4）。他讲述的一个客户，一个名叫 Nurture Boss 的物业管理助手，说明了分类为什么值得。在那里，“仅仅三个问题就占了全部问题的 60% 以上”，而集中处理其中一个，即日期处理，把它的成功率“从 33% 提高到 95%”（Husain，A Field Guide to Rapidly Improving AI Products，2025 年 3 月；T4，一位顾问讲述自己的客户）。没有类别，每个修复都是猜测；有了类别，你就知道哪个修复最能推动数字。

谁来标注，和标注多少同样重要。Husain 主张由一位领域专家来主导，他称之为仁慈的独裁者：可以听取别人的意见，但“由他们来主导这个过程”（T4）。在交付中，这个人通常就是阈值负责人或他们指定的人。一个标注委员会产出的是委员会对“正确”的定义，而阈值负责人不会在上面签字。

三个集合，三种用途，以及可信的评分器

到第一个月结束时，你手里有三批案例。把它们的用途搞混，是评测失去意义最常见的方式。

• 留出验收集。在划定范围阶段由客户的专家标注，归客户所有，只在约定的日期用来对照阈值测量。你永远不针对它调优。如果你看了它的失败来决定修什么，它就变成了开发集，你需要一个新的留出集。
• 开发集。那五个案例，加上影子运行中的失败。这是你每天对着干活的集合。它的分数一开始应该很低；Anthropic 说能力评测“应当从较低的通过率起步”，这给了团队“一座可以攀登的山”（T4）。一个你轻松就能通过的开发集，什么也发现不了。
• 回归套件。你修好的每一个失败，留下来，确保它不会复发。Anthropic 的标准是，回归评测“应当有接近 100% 的通过率”（T4）。每次改动都要跑：改一句提示词、改一次检索、升级一次模型。

回归套件也是让一次交付得以扩展的东西。Jarvis 说，在 Klarna 的客服助手上，OpenAI 的团队给每个意图都包上了一套自己的评测，因此能够“从大概 20 条政策一路扩展到 400 条”（Altimeter 访谈，T2）。Sierra 把同样的机制做进了产品，承诺在平台升级时“为我们的每一个在线客户运行回归测试套件”（Sierra，2024 年 6 月；T4，供应商的承诺）。这套评测让下一次范围扩展变得安全，也是你在交接时留下的资产。

它也只和它测量的东西一样好：Klarna 后来承认，其 AI 优先的客服带来了“更低的质量”，这一反转在“当交付失败时”一章中有分析，而没有任何公开资料说明那些按意图划分的评测测的是问题解决，还是只是拦截率。

分数过关、用户却讨厌它的时候，问题往往就出在这里。一旦建议送到了用户手里，一个只提建议的智能体会替你把证据记下来：被推翻或被忽略的建议。从评测通过的某一周里抽几十条被推翻的建议，交给阈值负责人手下的专家标注。如果智能体是对的，问题出在信任或队列视图上，属于推广采用的范畴。如果智能体错的方式没有任何评分器在检查，就把这个维度加成一个新的评分器和一批新案例，并重新签署计划。永远不要拿评测分数去反驳一次推翻。

评分器。用能判对的最便宜的评分器。代码里的精确检查优先：案件有没有进到正确的队列，输出是否符合 schema，涉诉标记的案件有没有被挡在快速队列之外。让模型充当裁判，是为了代码检查不了的东西，而且在任何人信任它之前，要先用专家的标注对它做校准。Yan 的方法是在一部分标注数据上对齐裁判模型，“留出剩下的 25% 作为测试集”，并用 Cohen’s kappa 衡量一致程度，其中“高于 0.7 的都算优秀”（T4）。要做到“每个维度一个评测器”；对于让一个裁判同时给许多维度打分，他写道自己“从没见过这样做得好”。本 wiki 关于裁判校准的页面讲了具体方法。

一致性。同一个案例，这次跑能通过，下次跑可能就不通过。Anthropic 区分了 pass@k，即“智能体在 k 次尝试中至少得到一次正确解的可能性”，和 pass^k，即“全部 k 次试验都成功的概率”，并建议“对于一致性至关重要的智能体”使用 pass^k（T4）。理赔分派器正是这样的智能体：一位理赔员看到同一个案件被分到两个地方，就会两个都不再相信。每个留出案例跑几次，报告每次都通过的比例。

当数字看起来不对时，先怀疑评分器。Anthropic 提醒，在多次试验中通过率为零，“最常见的是任务本身坏了的信号，而不是智能体能力不行”。它还说：“除非你去读许多次试验的转录记录和评分，否则你不会知道评分器是否工作正常”（T4）；它自己的例子见下框。在交付中，最常见的坏评分器是错误的标注：专家匆忙标注的一个留出案例。在开发集上，报告一个类别之前，自己先读十个失败。在留出集上则不要这样做：把不通过的案例编号交给阈值负责人，让他们的专家复核标注，并记录每一次重新标注的理由和日期。供应商做的重新标注是在秤上动手脚；客户做出并签字的重新标注才是更正。

工程层面的内容，从在 CI 中运行评测套件，到在输入漂移时保持其时效，都在本 wiki 里：智能体评测、评测驱动开发与 CI，以及评测集维护。SDLC 一书关于测试与验证的章节，针对智能体编写的代码提出了相应的论点。

从 80% 开始的漫长爬坡

关于评测，记录最充分的事实，恰恰是交付计划最常忽视的那一个：最后一段路最耗时间。LinkedIn 的工程团队报告说，“团队在第一个月内就实现了我们想要提供的基础体验的 80%”，然后“又花了四个月，试图让完整体验的完成度超过 95%”。他们写道，早期的速度“制造了一种‘就快到了’的错觉”（LinkedIn Engineering，2024 年 4 月；T2，一手的工程叙述）。这只是一个团队，不是定律，但这里的每一份叙述都呈现出同样的走势。

摩根士丹利是这条规律在交付中的版本：按 Jarvis 的说法，技术问题花了几周，而在顾问们信任它之前的试点和评测花了几个月；这段建立信任的时期，“上线与交接”一章会接着讲（T2）。

反例是一段永远爬不完的坡。麦当劳和 IBM 在大约 100 家门店测试语音点餐；2022 年的一份分析师报告称，准确率处于“80% 出头的区间”，而目标是“95% 以上”，测试于 2024 年结束（Nation’s Restaurant News，2024 年 6 月；T3，准确率数字为二手）。“当交付失败时”一章把它当作失败案例来读。这里的要点更窄：没有人定下一个爬坡必须成功的期限。

对 FDE 来说，由此得出四点。

弄清上限。划定范围阶段测量了专家彼此之间的一致程度；没有哪个智能体能被证明超过这个水平。在合成案例中，资深理赔员的一致率在 90% 出头到 90% 中段，而“至少和我的资深理赔员一样准”意味着追平他们，而不是超过他们。把上限写进评测计划，放在阈值旁边，这样以后就不会有人引用一个连专家自己都达不到的目标。

围绕爬坡来定商业条款。在一个难题上，30 天的试点很少能以高于阈值的成绩结束；假装能做到，等于让转化会议注定失败。合成案例的解法是：凭爬坡的证据转化，上线以达到阈值为前提。前提是发起人在汇报会之前就已经知道这段爬坡，而不是在会上才第一次听说。

数实验，而不是数功能。Husain 对这个阶段的规则是：“AI 路线图的关键指标不是上线了多少功能，而是跑了多少实验”（T4）。在停滞期间，一份每周简报就是爬坡正在进行的证据，即使总指标没有动。三行就够：“攻克：多车理赔，最大的类别。尝试：在分派之前按车辆拆分文档包。变化：该类别在开发集上的漏判大约减半；在约定日期于留出集上重新测量。”

在停滞之前写好停滞规则。在汇报会上，就数字不再变动时怎么办达成一致。一条可行的规则是：如果连续两次在留出集上重新测量都几乎没动，而剩下的漏判大多是专家自己也意见不一的案例，那么悬而未决的就是阈值的定义，而不是智能体。这个问题要以书面形式交给阈值负责人。如果专家对剩下的漏判意见一致，爬坡就继续，直到一个现在就定下的最后期限。没有事先商定的规则，停滞就会变成一场关于谁来担责的谈判。

传达坏消息

总有一天，你要告诉发起人智能体还不够好，而你怎么说，决定了这次交付能否继续。这方面没有研究；下文是实践经验。

先用他们的话，报对照阈值的数字。“分派准确率在 80% 出头；你的资深理赔员彼此之间的一致率在 90% 出头到 90% 中段；你定的标杆是追平他们。我们还没到。”不往上凑整，不说“差不多”，不换成一个好看点的指标。在这里把话说软了，后面的每个数字都会被打折扣。

然后展示通过了什么。在合成案例里，首次处理时间达到了目标，护栏在每个案例上都守住了。这不是安慰奖：它表明承诺中的哪些部分已经兑现，并把问题收窄到一个数字。

然后是计划。列出失败类别以及每类大致占漏判的比例、每类的修复和先后顺序。给出重新测量的日期，以及由谁来测。类别让计划可信，因为它们表明你知道智能体为什么失败。“我们会继续改进”不是计划。

然后是不变的东西。阈值不会因为你没达到就改变。降低阈值是阈值负责人的决定，要书面做出，而且永远不该由你提议。为迁就结果而改标杆，试点就会“成功”，然后在生产中被弃用。

最后，给发起人一个决定。有用的选项是具体的：按现有条款继续推进到重新测量的日期；把范围收窄到已经通过的类别；或者停止。推荐其中一个，并说明理由。拿到一个决定的发起人，会自己担起这个坏消息；只拿到坏消息的发起人，会去找人背锅。

先私下告诉阈值负责人。绝不能让他们在自己老板面前才得知结果，而且他们知道发起人会在意哪些类别。

模板：评测计划

评测计划与一页纸范围放在一起，让其中的指标能跑起来。把它放在客户看得到的地方，每当某个集合、某个评分器或阈值发生变化时，重新签字。

EVAL PLAN                                     version / date: ________

1. CONTRACT (from the one-page scope)
   Threshold, precise:         ___________________________________
   Threshold, sponsor's words: ___________________________________
   Ceiling (expert agreement): ___________________________________
   Guardrail (never):          ___________________________________
   Threshold owner:            ___________________________________

2. SETS            Source          Size     Owner      Used for
   held-out        _____________   ______   ________   readouts only
   development     _____________   ______   ________   daily work
   regression      fixed failures  grows    ________   every change
   Vendor tunes on or reads held-out failures: NO

3. LABELS
   Labelled by: ________________   Adjudicator: ________________
   Label form:  pass / fail per dimension, plus one-line reason
   Relabels: customer only; log case id, reason, date, initials

4. GRADERS (one per dimension)
   Dimension        Grader: code / judge / human   Calibrated (kappa)
   ______________   ____________________________   _________________
   ______________   ____________________________   _________________

5. CONSISTENCY
   Trials per held-out case (k): ____   Report: pass^k

6. CADENCE
   Regression suite runs on: every prompt / model / retrieval change
   Held-out measured on:     ____________________ (agreed dates only)
   Stall rule: if ___ re-measures barely move, then ______________

7. FAILURE LOG     Share of misses   Fix               Owner
   ____________    _______________   _______________   ________
   ____________    _______________   _______________   ________

8. READOUT
   Date: ________   Threshold owner briefed first: ________
   Re-measure date: ________   Decision asked for: ______________

9. SIGN-OFF
   Threshold owner (cases and labels are right): _______ date: ____
   Vendor lead (we will measure as written):     _______ date: ____

下面是按合成案例在第 4 周汇报会时填好的版本。数字都是区间；真实的计划会写上测得的数字。

EVAL PLAN: auto FNOL triage                   version 3 / week 4

1. CONTRACT (from the one-page scope)
   Threshold, precise:         routing accuracy >= senior-adjuster
                               agreement on held-out; first action
                               same work day
   Threshold, sponsor's words: "at least as accurate as my senior
                               adjusters, and nobody waits a day"
   Ceiling (expert agreement): low-to-mid 90s
   Guardrail (never):          litigation-flagged claim to fast queue
   Threshold owner:            claims director

2. SETS            Source          Size     Owner      Used for
   held-out        week-1 sample   a few    claims     readouts only
                                   hundred  ops
   development     5 expert cases  dozens   FDE        daily work
                   + shadow misses
   regression      fixed failures  grows    FDE        every change
   Vendor tunes on or reads held-out failures: NO

3. LABELS
   Labelled by: 2 senior adjusters     Adjudicator: claims director
   Label form:  pass / fail per dimension, plus one-line reason
   Relabels: customer only; log case id, reason, date, initials

4. GRADERS (one per dimension)
   Dimension        Grader: code / judge / human   Calibrated (kappa)
   right queue      code: compare to label         n/a
   litigation flag  code: never in fast queue      n/a
   reason is sound  judge, checked by seniors      > 0.7 before use

5. CONSISTENCY
   Trials per held-out case (k): several   Report: pass^k

6. CADENCE
   Regression suite runs on: every prompt / model / retrieval change
   Held-out measured on:     week 4; then every two weeks to go-live
   Stall rule: if 2 re-measures barely move, and most misses are
               cases seniors split on, threshold owner restates
               the bar in writing

7. FAILURE LOG     Share of misses   Fix               Owner
   multi-vehicle   largest share     split packet      FDE
                                     per vehicle
   poor scans,     a sizeable share  OCR pass before   FDE
   handwriting                       routing
   wrong policy    a smaller share   policy lookup     FDE
                                     check in code
   label errors    a few             relabel, logged   seniors

8. READOUT
   Date: end of week 4   Threshold owner briefed first: yes
   Re-measure date: two weeks on   Decision asked for: sign annual
   contract, go-live gated on the threshold

9. SIGN-OFF
   Threshold owner (cases and labels are right): claims dir.  wk 4
   Vendor lead (we will measure as written):     the lead     wk 4

填好的版本里有两处容易被忽略。最后一个失败类别是标注，而不是智能体，而且在汇报会之前发现它，比在会上发现便宜。还有，签字一栏要求阈值负责人为案例担保，而不是为分数担保：分数是计划产出的东西，案例才是客户同意据以评判的东西。

失败信号

这些信号都会在汇报会之前出现，并且每一个都指向一个解法。

进入下一阶段

前五项打上勾，生产构建就可以开始。上线则要等六项全部完成：

• 阈值和护栏都以检查的形式运行，所用的留出集由客户标注并归客户所有。
• 开发集由真实的失败构成并已分类，回归套件在每次改动时运行。
• 每个基于模型的评分器都已对照专家的标注做过校准。
• 专家在留出集上的一致程度已经测出，并展示给了阈值负责人。
• 在任何汇报会之前，发起人已经从你这里听到了当前的数字、计划和重新测量的日期。
• 阈值已在留出集上达到，由客户的团队测量，并由阈值负责人签字。

合成案例在停滞期间并行推进构建。下一章“在客户的环境里构建”讲的就是这部分构建。