评估集与验收门槛

目录

第5章　评估集与验收门槛

第4章把“核对太花时间”之类的说法写成指标定义，并说明怎样测量现状基线；合众通信案例中的结果仍待现场测量。业务指标用于判断流程是否改善，却不足以说明某个系统版本是否满足任务要求。本章把客户认可的要求写成可反复执行的评估集与评分规则，再确定验收门槛，依次回答四个问题：什么算成功，哪些错误可以接受，哪些情形必须交给人，改动之后怎样回归。三种评估各有分工：本章建立标准，第20章用它把关发布，第21章用它持续抽检。读完本章，FDE小组应能交付评估集v1，以及经客户认可的评分规则与验收门槛。

5.1　评估与规格

5.1.1　验收争议的来源

AI项目的验收争议，常常始于对“准”的理解不同。需求会上，Tom希望系统准一点，Alice希望它别漏掉快要超时的工单，小组表示认可，三方却未必指向同一项要求。生成式AI系统的输出可能带有随机性，又无法穷举所有输入，验收通常需要抽样，因此抽取哪些样本、由谁判定对错、不同的错误怎样处置，都是验收标准的一部分。

设想小组在第一次内部演示后向Tom报告：系统在自己抽查的50张工单上提醒正确率为92%。Tom当场追问了三件事：这50张是谁挑的，对错是谁认定的，剩下的4张里有没有已经超时的。Alice又从上周的工单里翻出一张没被提醒的，说系统漏了。小组回答，这一张不在抽查的样本里。这个答复没有回应漏报问题，双方也缺少共同认可的判定依据。

Tom的三个追问，分别涉及样本选择、评分依据和错误处置。任何一项没有事先写清并经客户认可，“92%”就只是小组在特定口径下得到的结果，不足以作为双方共同认可的验收依据。没有写清的要求，工程团队只能自行解释，解释的偏差往往到交付时才暴露。建设评估集，是为了让双方在开发之前就把这些要求写成可以检查的样本与规则。

本章的立场由此而来：评估集和评分规则是规格的一部分，首版应在系统开发前形成，并随需求按规则完善、由客户参与写下，并在开发全程保持可以执行。

5.1.2　评估集与规格的关系

把评估集看作规格的一部分，意味着模型、提示和检索配置属于实现，评估集与评分规则则是检验实现的依据。实现可以多次迭代，验收依据不能为配合某个版本的结果而改变；需求变化、标签纠错和样本更新，应按约定另建版本。传统规格用文字描述输入、输出与约束，评估集用具体样本和期望行为补充这些描述。表5-1从几个方面对比二者。

表5-1　传统规格说明书与评估集的对照

这几项差别里，有两点值得展开。第一，先区分两种基本要求。一种是比例条款，规定在代表性样本上做对的比例不低于多少；另一种是禁止条款，规定某类错误一次也不许出现，比如引用一条并不存在的记录来支持自己的结论。对概率性的系统，如果把二者合在一个“准确率”里，一次严重的错误就会淹没在九十九次正确之中。评分规则把这类错误列为硬失败项，验收门槛据此规定零出现条款。

第二，用样本表达规格有一个局限：样本可以列举情形，却不能穷举所有情形，因此必须与评分规则合用。规则说明为什么这些输出算对，也为未见过的情形提供判定依据。只有样本而没有规则，不同的人可能读出不同结论；只有抽象规则而没有样本，又不容易发现执行中的歧义。二者相互补充，仍不能替代权限、性能等其他规格与检查。

评估集不创造新的业务要求。凡是标签依赖合同条款的地方，比如响应时限，条款才是权威，样本只记录依据哪个版本的条款判定。条款修订后，受影响的标签就要复审，而不是让评估集去修改合同。

5.1.3　评估的四个问题与认定责任

评估集的建设要围绕一个决定展开：这一版能不能交给客户使用。围绕这个决定，评估要回答四个问题。表5-2列出每个问题要写清的内容、通常由谁认定、不回答的后果，以及本章哪一节回答。后文按这个顺序展开。

表5-2　评估要回答的四个问题

成功标准应具体、可测，并与业务目标相关，还要能由不同的人按同一判据执行。“表现不错”不是标准；“对每张工单，判断是否在等备件，并引用支持判断的记录”则可进一步写成评分规则。规则仍需明确记录矛盾、信息缺失及允许的表达方式，并通过试标检查两位专家能否一致判定，不能仅凭句子具体就认定已经没有歧义。

第二个问题的关键，是错误有不同方向和代价。漏报一张即将超过响应时限的工单，可能影响合同履行；误报一张，通常会增加值班主管的核对工作。若只用准确率汇总，两种错误会被等量计数，无法反映代价差异。哪些错误可以接受、可以接受多少，应由结果责任人会同承担后果的一线人员认定。小组负责提供选项、证据和代价估计，在查看候选版本结果之前约定标准。

第三个问题常被当作兜底，其实是设计的一部分。系统在证据不足时说“无法判定，请人工核对”，是一种正确的行为，评估集应当为它设样本、给分。如果评估只奖励作答，系统就会在没有依据时也编出一个答案，某些宽松评分可能因此给出偏高的成绩；反过来，如果转人工不受约束，系统又会把难题全推给值班主管，省时间的目标便落了空。转人工既要在该转的时候转，也要有总量的限度。

第四个问题把评估集变成长期资产。系统的每一次改动，提示、模型、检索配置，甚至上游数据口径的变化，都可能让以前做对的事重新出错。回归的前提是评估可以原样重跑，并且评估本身不变。评估集的版本、评分器的版本和系统的版本要分别记录，才能区分分数的变化来自系统还是来自尺子。评分器指按评分规则给输出打分的一方，可以是程序、裁判模型或人工，5.3节展开。

四个问题的答案要在看到候选版本的结果之前写下，并经客户认可。否则标准会不知不觉地向结果靠拢：成绩差一点，就说那类样本其实不重要；成绩好一点，又把门槛上调以显示严格。科学研究里预先登记研究方案，防的是同一类问题；阶段门的判据在项目开始时写入章程，也是这个道理。

5.1.4　评估的适用范围与局限

本章的评估集主要检验任务行为：答案是否正确、证据是否可核查、应转人工时是否转交、格式是否符合约定。权限、性能和持续可用性也可以测试，但需要相应环境、负载和故障条件，不能只靠这一套任务样本得出结论。表5-3列出任务评估与专项检查的分工。

表5-3　评估集能检验与不能检验的要求

权限不能仅靠评估集保证。抽样可以发现越权实例，但在一批样本上没有观察到越权，不等于系统在其他输入下也不会越权。权限应由模型之外的认证与授权机制强制执行，再用针对性的负面测试核查。任务评估可以记录访问违规，但不能替代这套机制；二者应分别给出检查结论。

同样的道理决定了不能把“评估通过”说成“验收通过”。合同里的验收往往包含权限、可用性和响应时间，只通过了评估集就宣布验收完成，争议只是推迟了。较稳妥的做法，是在章程里把验收分成两层：任务层面的验收，由本章建立的标准承担；发布层面的门禁，由第20章承担，报告里两层分开写，各自给出结论。线上监控、用户反馈和对照实验各有所长：线上数据能看到评估集里没有的真实分布，对照实验回答业务指标有没有改善；评估集的长处是发布之前就能运行、可以重复、成本可控，短处是覆盖有限。

评估集也不直接度量业务改善。第4章的三项核心指标主要衡量流程效率与及时性，受值班安排、人员和故障构成等因素影响；要判断改造效果，需要用上线后的测量与基线比较，并处理归因问题。评估集检验的是系统在受控样本上的行为，运行较快，也便于重复比较；在其他条件固定时，可以把评分变化与系统改动联系起来。它仍是间接证据：只有“系统做对这些事”确实有助于“流程指标改善”，评估结果才有业务意义。表5-4把三项指标转换为系统应完成的任务，并列出评估集v1对应的材料。

表5-4　三项业务指标与系统要做对的事

图5-1把整条链路画在一起。从左到右是五个环节：业务指标定出要改善什么，系统要做对的事把它翻译成系统的行为，评估集把行为落到样本上，评分规则规定每条样本怎样判分、哪些错误一票否决，验收门槛规定达到什么程度才算可用。上游是第4章的成果，下游是发布前把关和上线后抽检两种评估。

图5-1　从业务指标到评估集与验收门槛

图中每个箭头其实都是一个假设。选错了要做对的事，评分再高，指标也不会动；样本不能代表真实的工作，评估结果就难以推广到现场；规则没有抓住客户在意的差别，评分就答非所问；达到门槛的表现，客户在现场未必真能接受。链条上任何一环断了，评估通过都不代表业务变好。写评估集的过程，就是逐环检查这些假设是否站得住。

第4章区分现状测量与改善目标，本章进一步约定任务要求和验收门槛。现状反映的是既有流程在特定条件下的表现，不能直接抄作目标；人工差错率和返工率也只是参照，且须等实际测量后才能使用。评估通过，只表示候选版本在约定样本和评分条件下满足条款，不说明业务指标必然改善。实际效果要在上线后按第4章口径重测并处理归因，这是第23章的任务；系统是否被采用，则由第24章讨论。

5.2　评估集的建立

本节回答第一个问题的前半：什么算成功，先要有一批写下来、双方认可的真实样本。产出是评估集v1，标签由Alice与Bob认定，其中规则性的定义由Tom签认。评估集的质量取决于一连串环节：样本从哪里来，记录成什么样子，规模多大、难易怎样分布，由谁来标、标得对不对，哪些样本要留着不让调试时看到，建成之后怎样维护。每个环节都会往评估集里带入一种偏差，需要逐项识别并控制，说明它对结论的影响。本节以合众通信的评估集v1为例，它包含约100条故障工单和30份历史复盘报告。

5.2.1　样本来源

评估应优先使用与任务相符的真实记录。合成样本可能过于整齐，遗漏现场缩写、旧备注、矛盾字段或少见异常，因此不能用其成绩替代真实数据上的表现。它仍可用于启动开发、构造对抗情形或补足少见类别，但要标明来源、单独汇报，不计入估计日常表现的代表性样本。

每个来源都只是观察真实工作的一扇窗，而不是真实工作本身，所以要问每扇窗能看到什么、看不到什么。表5-5列出评估集v1的四个来源，各自能代表什么，会带来什么偏差，以及怎样应对。

表5-5　评估集v1四类来源的代表性、偏差与对策

表中第一行的“决策时点”需要特别说明。系统要回答“今天早上哪些工单在等备件”，就只能使用当时已经存在的记录。若直接使用工单最终状态，后补的处理结果、备件到货记录和关闭备注就会提前泄露给系统，使评估高估实际能力。因此，样本输入必须还原到决策时点：有状态变更历史的，按历史还原；没有历史记录的，应寻找当时的导出文件或快照。无法可靠还原的记录，不宜用于该时点任务的验收，可改作其他用途并注明局限，不能用较晚的更新记录冒充当时输入。

人工核对曾出错的工单有助于发现边界情形，但不一定都是系统最难处理的样本。重新打开的工单可以作为查找线索，仍须核实重开原因是否确为核对错误；也可请Alice和Bob提供实例后找回原始记录。这类来源只包含已被发现的错误，不能按其人为提高的占比估计日常通过率，应归入定向样本单独分析。

取样是一次生产数据访问，受章程中访问清单的约束：由David批准，只取评估所需字段，工单正文中的个人信息脱敏后才进入评估集，字段口径见第9章。建成后，评估集仍按受控数据管理：不擅自复制到共享位置，访问留痕；留出集及其答案不得作为调试提示或示例使用。开发集样本可在授权范围内用于调试，但使用方式也要记录。用于估计日常表现的样本应贴近真实流量，不能只挑能展示系统长处的记录。

5.2.2　样本记录的结构

样本不是一段文字，而是一条结构化的记录。结构决定后面能做什么：能不能按事件切分，合同条款修订时能不能找到受影响的样本，能不能把高风险的样本单独汇报。表5-6列出评估集v1每条样本的字段。

表5-6　评估集v1的样本记录字段

以一张工单为例。工单TT-2026000517的描述写着“基带板卡故障，需更换”，备件行P-30218的状态是“已到库”，同时有一条预留记录显示这个备件已预留给另一张工单，原因不明。按评估集v1的约定，这张工单的期望行为既不是提醒，也不是不提醒，而是转人工；判定依据记下备件行与预留记录两处记录及其版本；风险等级为高；两位标注者的标签都写成“记录矛盾，无法判定”，不确定性一栏注明业务事实尚待核实，但转人工标签已明确。它在表5-6里每个字段各有一个值，合起来就是一条样本。这张工单在后面几节还会出现：5.3.1看它怎样被评分，5.4.1看为什么不能给确定结论，5.5.2看哪条规则把它转给人。

这样记录有三点设计考虑。第一，记录的是期望行为，不是答案文字。同一张工单，系统可以用许多种措辞指出“在等备件”，若仅以字符串是否相同来判断标准答案，措辞稍变就会被误判；记录成“应当指出在等备件，并引用某条备件记录”，评分才能检查行为本身。第二，判定依据带版本：合同条款修订后，依据旧条款作出的标签可能不再成立，这个字段让它们可以被找出来复审。第三，标注、裁定和不确定性都是记录，不是口头约定，半年以后仍能追溯一个标签为什么是这样。数据文件按行存放，与评分规则放在同一个受版本控制的目录里。

5.2.3　规模与分布

第一版评估集该有多大，各种实践文章的建议并不一致。有的主张从真实失败里取二十到五十个任务就可以起步，理由是早期系统的每次改动效应很大，小样本也看得出差别。有的主张对真实记录做错误分析，取一百条左右，分析到新的样本不再暴露新的失败类型为止。有的建议第一版取一百到数百条，不要一开始就做上万条，因为标注昂贵，迭代周期被拖长，团队难以及时分析结果。这些主张并不是对同一个问题给出了不同的答案，而是在回答不同的问题。判断样本量，先要问想下什么结论，大致有三种。

1）发现问题。初期可以从几十条有诊断价值的失败入手，识别主要失败机制。暂时没有出现新类型，可以作为阶段性停止的依据，但不能说明所有失败模式已经覆盖。

2）比较版本，判断新版本是否比旧版本好。差异小于抽样的波动就无法分辨，需要的样本多得多。

3）验收声明。先区分“这批样本中未出现某类错误”和“总体发生率低于某值”。前者是样本事实，后者需有适当抽样与足够证据支持；零次观测不能证明总体概率为零。

在独立、代表性抽样且判定规则固定的前提下，100条样本均无失败时，失败率的单侧95%置信上界约为3%；100条中90条通过时，Wilson双侧95%置信区间约为83%至95%。区间用于说明估计的不确定性，不能解释为本次区间以95%的概率包含固定真值。小样本通常难以稳定区分几个百分点的差异，配对比较还需检查两个方向的分歧计数。同一故障下的工单可能相关，报告时应同时写明工单数和事件数，必要时按事件分组估计区间。

合众通信的评估集v1包含约100条工单和30份复盘报告。首版规模受领域专家的标注时间约束：按每张工单5分钟、每份报告30分钟的示意用时，两位专家各标一遍，共需约47个专家小时，即每人约三个工作日，另须预留试标、裁定和复审时间。v1主要用于发现常见失败类型、检验已知高风险情形，不能支持很窄的统计区间。新增线上案例时，应保留原有代表性样本的统计口径，把定向收集的失败单列；不能仅因样本增加，就声称估计更接近真实流量。

样本分两部分汇报，回答两个不同的问题。代表性样本（representative samples）按真实工作里的分布抽取，回答“日常表现怎么样”；定向样本（targeted samples）专门覆盖少见而代价高的情形，回答“这类风险有没有被挡住”。把两者合成一个总分，得到的数字既不代表日常，也不代表风险：总分会随两类样本的占比摆动，而配比由收集方式和测试目的决定。定向样本各类只有十条左右，可以报告通过条数，但不把通过比例解释为线上发生率，重点报告检出的失败：它们是探针，任何一个失败都值得追查，但没有失败不等于没有风险。

代表性样本应尽量保留真实工作中的难易分布。难度可由领域专家依据可观察特征判断，例如是否需要查询第二个系统、判定耗时是否明显较长、两位标注者是否容易发生分歧。若为诊断问题而提高困难样本的占比，应将其作为定向样本单列，或在已知抽样概率的前提下加权估计日常表现；不能把人为调整后的配比直接当作线上分布。合众通信的故障工单分属无线基站设备、传输设备、动力与空调设备三类网元，不同类别在备件和处理流程上差别很大，分层抽取时每类都要保证足够的条数，目的是不遗漏，而不是估出各类的通过率。

两部分都应覆盖正例与反例，但不必机械地各占一半。若评估集全是临近超时的工单，一个对所有工单都发提醒的系统也可能得到高分，所以既要有该提醒的，也要有不该提醒的，还要有记录不足、正确做法是转人工的样本。表5-7列出评估集v1的样本类型与示意配比。

表5-7　评估集v1的样本类型与示意配比

5.2.4　标注指南、双人标注与裁定

标注是把专家脑子里的隐性判断变成数据的过程。没有统一的指南，两位专家各凭经验判断，标注结果就会混入个人习惯，使系统评分难以解释。所以动手标注之前，先写标注指南（annotation guideline）：每个类别的定义，边界情形的判定规则，每类至少一个正例和一个反例，不确定时怎么办（“无法判定”本身是一个合法的标签），以及指南的版本号。

指南需要通过试标完善。抽象讨论“什么叫在等备件”时，专家可能认为已达成共识，面对具体工单才发现分歧。可先取十至二十条，由两位专家独立试标，逐条分析分歧，修订指南后再检验。停止条件应是关键判据稳定、主要分歧得到解释，并记录未解决的问题，而不是简单要求“不再增加条款”或完成固定轮数。图5-2给出从起草指南到入库的流程。

图5-2　标注指南的试标循环与验收样本的双人标注

指南由小组起草、领域专家修订，涉及业务规则的定义由Tom及相应责任人认定。试标样本进入开发集，不进入留出集，因为指南已利用这些样本形成，相关讨论也可能影响后续标注。标注界面应把原文、关联记录和标签选项放在一起，减少不必要的切换；小规模任务可以先用受控表格完成。

验收用的样本由两位专家独立标注，互不通气。合众通信的两位标注者是最熟悉值班流程的Alice和最熟悉外场处理的Bob，二人恰好代表使用系统输出的两端。两人的标签不同时，不能取平均，也不能由其中一人说服另一人，而要交给事先约定的裁定人（adjudicator）。裁定人由小组与Tom在开工前约定，不由标注者本人兼任，并把裁定的理由写下来。每个标签附三样东西：判断的理由，判断所依据的记录或规则的版本，以及值得记下的不确定之处。仍然含糊的样本，要么裁定，要么明确标为含糊，不能把分歧藏起来。

并不是人人都主张双人标注。另一种做法是指定一位对产品拥有最终发言权的领域专家，由他一人定标准、做标注，理由是这样一致、快、便宜，也避免了委员会式的折中。两种做法各有适用的阶段：迭代期速度要紧，由Alice一人拍板，指南和样本很快就能成形；到了验收期，标签将成为客户与小组之间的依据，一个人的习惯一旦写进标签就成了规格，双人独立标注多花的成本，用于识别单人判断中未被察觉的歧义。合众通信的做法是迭代期用单人，验收用的样本和留出集用双人。

分歧不是噪声，而是信息。若两位专家结论不同，应核查记录、判据和业务解释，而不是立即认定系统有错。归纳起来，分歧有三种来源，处理方式各不相同。

1）指南缺口。定义没有覆盖这种情形，处理办法是修改指南，受影响的样本重新标注。

2）样本缺陷。若是采集、关联或还原过程出错，应修正并留痕；若矛盾或缺失本就存在于当时的业务记录中，应保留，并按指南判断是否需要转人工，不能为让样本容易判定而补齐事后信息。

3）合理的多种解读。两种读法都站得住，需要结果责任人拍板选一种，或保留多个允许的结果，必要时细分标签。

第三种来源尤其重要：它说明“每个样本只有一个正确答案”的假定并不总成立。硬裁成一个，系统受到奖励的就成了揣摩裁定人的口味。试标后仍反复出现的同类分歧，应回到指南里解决，而不是每次靠裁定人解决。

衡量两位专家的标注一致性，不能只看一致条数所占的百分比。类别分布高度不均衡时，仅按各自的类别比例独立选择标签，也可能得到较高的一致率，所以要用扣除偶然一致的Cohen κ系数（Cohen’s kappa）；它也受类别比例影响，因此应同时报告标签交叉计数表、实际一致率、κ及分歧原因，不用单个系数代替质量判断。一致性之外，还要检查标注是否正确，因为两位专家可能共享同一种旧习惯，因而作出相同的错误判断。核查应包括：把标签理由追溯到原始记录；能按登记口径直接计算的标签交给程序，并用手算正反例检验程序；对双人一致的标签抽样请第三人复审。事后记录也可用于核查时间线是否自洽，但不能把决策时点之后才出现的信息加入输入，或据此要求系统当时就作出无法支持的判断。下面的案例说明百分比一致与一致性系数的差别。

案例　两位专家给同一张工单打出两个标签

FDE小组请Alice和Bob分别标注40张工单是否在等备件，两人有34张一致，实际一致率为85%。Alice标“在等”11张，Bob标“在等”7张，按两人的边际比例计算，偶然一致率为(11×7+29×33)/40²，约64.6%；因此κ=(0.85−0.64625)/(1−0.64625)，约为0.58。κ与85%衡量的内容不同，不能直接比较数值大小，还应分析6张分歧工单的原因。

6张分歧工单里有5张属于同一种情形：备件已到库房，外场班组还没有领出。Alice标“在等”，因为值班主管早上核对时，这样的工单仍然要盯着，直到备件交到班组手里；Bob标“不在等”，因为在外场的人看来，备件到库就意味着随时可以去领。两人都没有标错，是指南里的“等备件”一词原本同时装着两种情形。

小组没有让其中一人服从另一人，而是把标签拆成“备件未到库”和“备件已到库待领出”，各写一条判定规则和一个例子。拆开以后，系统能否区分这两种情形，也成了评估集可以检验的内容；再取一批工单让两人重标，分歧明显减少，剩下的集中在少数新的边界情形上。其余1张分歧是记录笔误，由事先约定的裁定人裁定，理由写进标签。本案例为虚构，数字为示意。

5.2.5　开发集与留出集

评估集不能全部拿来调试。改提示、换模型、调检索配置的人，本身就是一个以评估结果为目标的优化过程：每看一次失败样本，就把关于这批样本的信息写进了系统。看得多了，系统便不知不觉地适合了这批样本，分数不再反映它面对没有见过的工单时的表现。办法是把样本分成两份：开发集（development set）供日常迭代，可在授权范围内查看；留出集（holdout set）留作验收，调试时不看。

数据泄漏并不限于AI业务系统，公开机器学习基准中也可能存在训练样本与测试样本重复的问题。对现场评估而言，更直接的风险是同一次区域性故障产生多张内容相近的工单。若把它们随机分到开发集和留出集，系统可能依靠已经见过的事件细节得分，评估结果就会高估对新事件的适应能力。因此切分要做到下面三点。

1）按事件而不是按单张工单分组，同一事件的工单和复盘报告进入同一集。如果按张随机切分，近乎相同的工单会同时落在两边，开发集上调出来的效果直接在留出集上得分，造成泛化能力很强的错觉。

2）切分之前先去重，识别近似重复（near duplicate）样本并分组，必要时保留一个副本，比如同一站点、同一时间窗、同一故障码、正文高度相似的工单，不要仅凭相似度删除真实独立事件，处理依据应留痕。

3）留出集取较新的一段时间，更接近上线后会遇到的数据；同时避免只取某一个季节，或某一次大故障。

留出集需要防止四类泄漏。一是提示与示例：不能将留出标签、参考答案或事后结论加入调试提示。二是检索索引：排除直接泄漏留出答案的报告和重复案例；但任务本来允许查询、且在决策时点已经可用的原始记录，可以按同一访问规则提供，不能一概排除。30份历史复盘报告中属于留出集的那一部分，也不得进入知识库与检索索引。三是日志：开发者可见的日志不应暴露留出样本内容。四是微调数据：留出样本及其近似副本不得用于微调。是否构成泄漏，要以决策时点和任务约定为准。

每次打开留出集都要留痕。一旦有人看过它的失败样本并据此修改了系统，它就部分地变成了开发集，应当换一批新的留出集，并在版本记录里写明。换一批新的要花专家的时间，所以预算里要预先留出至少一次更换。更好的办法是用技术手段限制留出内容暴露：留出集的运行脚本只返回汇总结果和硬失败的条数，不返回样本内容；确实需要查看失败时，经评估负责人批准并留痕。

5.2.6　评估集的版本与维护

比较分数必须核对评估条件。增添容易样本、改动标签或评分规则，都可能让分数变化，而不是系统本身改善。因此，任何影响集合成员或判定的改动都应留下新版本，并保留旧版供复现。每次运行记录系统、评估集、评分规则及具体评分器配置；涉及放行时还须记录门槛版本，不能把规则与执行评分的模型或程序混作同一项。

每版附变更记录，写明内容、原因、批准人和影响样本。更新后，用新评估条件重评上一个已发布版本，形成桥接比较：新旧系统在同一套新条件下分别得分。它有助于区分系统变化和评估变化，但不能把不同集合上的历史分数直接拼成连续趋势。

评估集的变更来自三个方面。一是增长：线上遇到的失败回流成候选样本，走和其他样本相同的标注路径，先进入开发集，留出集则随新的事件整批更新。二是纠错：发现标签有误或指南有缺口时，修正并记录。三是规则变更：维保合同或手册修订以后，依据旧条款的标签可能不再成立，凭“判定依据”字段找出受影响的样本，复审后升版本。系统在开发集上全部通过时，该集合可能不足以区分进一步改进，应当从新的失败里补充更难的样本，而不是放低要求。

版本号的写法可以很简单：v1是第一个经客户认可、冻结的版本；纠正笔误而不改判定的小改动记为v1.1；改变判定或成员的记为v2。评估与验收负责人（小组内的职能）提出变更，领域专家确认，凡影响验收的变更由结果责任人Tom签认。项目结束时，评估集连同指南和脚本一并移交给客户（第25章），因为它记录的是客户对“做对”的定义，是客户的业务资产。表5-8把本节各环节的偏差与对策汇总起来，可以当作评估集v1冻结之前的自查清单。

表5-8　评估集建设各环节的偏差与对策

到这里，评估集v1的样本和标签有了。每条样本该怎样判分，是下一节的任务。

5.3　评分规则

本节回答第一个问题的后半：对错由什么判定。样本有了，期望行为也写下来了，接下来要规定怎样把系统的一次输出与期望行为比较并得到判定。评分规则要做到的，是让两个人，或者一个人和一段程序，面对同一条输出给出同样的通过或失败。做不到这一点的规则不能写进验收，因为判据仍有歧义，应当先改规则。产出是评分规则r1，由小组起草，Tom认定。

5.3.1　评分项的拆分

评分优先检查任务结果，必要时也检查约定的过程约束。系统做同一件事常有多种合理的做法：智能体可以先查工单再查备件，也可以倒过来，只要结论正确、引用的记录站得住，就不该因为步骤顺序与事先设想的不同而扣分。规定唯一的路径，既会惩罚同样正确却走了别路的做法，也会把系统优化得只会走这一条路。例外是过程本身就是要求的地方：读取了访问清单之外的数据，答案再正确也是失败。因此评分项分两类，一类看输出的结果，一类看运行中不得发生的动作。

一次输出往往包含好几件事，不宜只打一个总分。备件提醒要判断工单是不是在等备件，要引用记录，要给出处理时限，记录不足时还要转人工。把它们拆成各自独立的评分项（criterion），每项只回答一个问题。拆开以后，失败的原因一目了然，不同的评分项也可以交给不同类型的评分器；多部分的任务按项给分，也避免了九项都对、一项严重出错，被平均成一个看上去不错的分数。

本章优先采用通过或不通过的二元判定，以便明确每项要求的边界。缺少分档锚点的一到五分量表，容易使不同专家对相邻档位产生分歧。需要细分要求时，可拆成若干二元评分项；确需评价程度时，也可以使用量表，但必须为各档提供可核查的定义和示例，并检验标注一致性。

需要语义理解的评分项，可由经校准的裁判模型或人工判定。裁判模型（LLM-as-judge）指让大模型依据评分规则评判系统输出，后文简称裁判。表5-9列出备件提醒任务的评分项、判定方式及条款类型；其中一般转人工要求与高风险硬失败要求分别计分。

表5-9　备件提醒任务的评分项

仍以工单TT-2026000517为例。它的期望行为是转人工，所以“结论一致”“处理时限正确”这两项不适用于它，要评的是“该转人工时转人工”：系统若输出转人工，这一项通过；若输出“备件已到库，无需提醒”，这一项失败，而且因为这是高风险样本，同时触发硬失败项。

表中“引用支持结论”没有直接定为硬失败项，是因为判定它需要语义理解，裁判本身可能误判。若把未经复核的裁判输出接到“一次也不许出现”的门槛上，误判就可能主导验收。例如，裁判对正确输出的误判率为5%，评判一千次正确输出时，误判次数的期望是五十次。因此，这类评分项若按硬失败项处理，裁判判出的每一次失败都应由专家确认后计数，同时还应抽查裁判判通过的输出，防止漏判。

5.3.2　评分器的类型与选择

评分器按判定方式分为三类：程序、裁判模型和人工。表5-10从擅长判定的内容、优点、局限和合众通信里的例子几个方面作了比较。

表5-10　三类评分器的比较

选择的原则是：先用程序处理可明确计算的要求；需要语义判断时，只有经校准达到要求的裁判才能替代部分人工。理由一是成本，二是可复现：固定程序版本和输入时，结果应可复现，裁判会有波动，人工既贵又因人而异。可靠性要靠测量，不能靠印象，裁判模型看上去什么都懂，不等于它在某个评分项上可靠。图5-3画出选择的流程。

图5-3　为一个评分项选择评分器

三类评分器常常分层使用。一条输出先过程序：格式不对、引用不存在、读了不该读的数据，这些由代码判定的失败就此定案，不再交给裁判；裁判只处理通过了代码检查、仍需要语义判断的评分项。这个次序有一个硬性的含义：裁判不能推翻程序判出的失败。否则口径宽松的裁判，会把程序抓到的越界悄悄改判成通过。

引用检查是分层的典型。第一层查引用的记录编号是否真的存在，由程序完成，而且必须做：系统编造一个看上去合理的编号，是最容易被裁判放过的错误，因为裁判见到格式齐全的引用，很容易觉得可信。第二层查所引记录的内容是否支持结论，要读懂记录，交给裁判，并由专家抽查。两层失败的原因不同，应当分别计数。

裁判的使用有三个决定要写进评分规则。第一，哪些评分项交给裁判：只交需要读懂语义、界线又能说清的评分项，v1只有“引用支持结论”一项。第二，谁认可校准结果：由Alice标注、小组校准，校准结果与适用范围经Tom认可之后，裁判才能参与验收。第三，什么时候必须重新校准：更换裁判模型（包括服务方在后台更新），修改裁判提示或评分项定义，被评系统的输出形态发生变化，客户修订判据。校准的做法、指标和案例放在5.8，那一节是选读，但这三个决定不是。

5.3.3　多次运行与结果汇总

同一条样本，系统每次运行的输出可能不同。重复运行可以检查稳定性，常见的两种汇总口径是至少一次通过（pass@k）和每次都通过（pass^k）。本章用每次都通过的口径检验重复运行的稳定性，同时保留单次通过率；这比一次运行的要求更严格，不能直接把它解释为现场单次成功率。至少一次通过适用于可以重试且能可靠选出正确结果的流程，不能只因允许重试就采用。

每条样本运行几次，需要权衡成本与识别波动的需要，本章以三次为示意。应固定运行次数和环境重置方式，同时记录每次结果。按“每次都通过”汇总时，一条样本最终只有一个通过或失败结论，统计区间以样本为单位；同一事件包含多条相关样本时，还须考虑事件内相关性。重复运行可以增加对模型波动的了解，但不能扩大业务情形的覆盖面。汇总时遵守下面四条。

1）硬失败项单独列出，不与其他项合并为平均得分，写明运行次数和出现次数。

2）比例条款按评分项分别给出通过比例和误差范围，不合成总分。

3）代表性样本与定向样本、开发集与留出集分开汇报，每个比例都写出分子与分母。

4）标注尚未裁定的样本不计入通过比例的分母，单独报告条数；记录不足但正确动作明确为转人工的样本仍须计分，不能一并剔除。

复盘材料按要素评分：时间线是否与原始记录一致，事实和引用是否可核查，结论是否超出已有证据。S2只整理材料草稿，根因由人认定；已有经确认根因时，系统应准确转述并注明依据，证据不足时不得补造根因。时间线、关键事实和证据出处等哪些要素必须全部通过，由专家与Tom在规则中明确，其余项单独报告，不用平均分抵消关键错误。

5.4　错误分级与硬失败项

本节回答第二个问题。评分规则能把错误量出来，却消除不了错误。系统会出错，值班主管和外场工程师也会出错，评估要回答的是另一个问题：哪些错误可以放过，哪些一次也不行，哪些根本不该由系统来下结论。三种处置要事先分开，否则验收时每遇到一个错误，就要把争论重来一遍。产出是错误与处置的对应表和硬失败项清单，由Tom与Alice认定。

5.4.1　错误的方向与代价

备件提醒有两类错误：应提醒却未提醒是漏报，不应提醒却提醒是误报。误报通常增加核对工作，也可能在持续出现时造成告警疲劳；漏报缺少显式信号，可能直到时限被突破后才暴露，但也可能由其他流程提前发现。两者应分开统计，并根据实际下游检查方式估计代价，不能假定误报总能被发现、漏报一定导致超时。

所以给错误定处置，除了看代价有多大，还要看三件事。一是可发现性：错误有没有机会在下游被人发现。二是可逆性：发现以后能不能撤回、补救。三是传播：这个错误会不会被下一个环节当作输入继续放大。系统引用了一条不存在的记录，值班主管不会逐条去核对编号，这条引用却可能被抄进复盘报告，一处错就处处错，三项都不利，应当比一次误报严重得多，尽管两者“看上去都只是错了一处”。同一个计算错误也因方向而异：时限算得偏早，等于误报；算得偏晚，等于漏报，两者要分开统计。

工单TT-2026000517的备件行与预留记录相互矛盾，现有记录不足以支持“无需提醒”的确定结论。这里首先发生的是未按约定转人工，而不能直接认定为漏报：只有进一步核实它确应提醒，才可归为漏报。因该样本已被标为高风险，系统擅自作答还会触发H3。强制转人工是为了让值班主管处理矛盾，而不是声称这张工单必然会超时。

表5-11把备件提醒任务里的六类错误按这几个角度排开，并给出处置。处置只有三种：计入比例条款，设上限或下限；列为硬失败项，一次也不许；交给人，系统不下结论。

表5-11　备件提醒任务的错误与处置

向业务方了解错误代价时，仅问“漏报和误报哪个更严重”通常不够。可以进一步问：为了少漏一张工单，愿意多接受多少张误报？Alice提供每张误报的核对用时，Emma说明突破响应时限可能产生的合同后果，再由Tom认定可用于初算的代价范围，例如一次漏报相当于十至三十次误报。这个换算并不表示损失始终与次数线性对应；应写明依据，并在整个合理范围内检查结论是否变化。下文以二十倍作示意，不作为实测值。业务条件变化时，应重新核查换算关系和门槛。

5.4.2　硬失败项的确定

硬失败项来自错误的代价。办法是把系统可能犯的错一类一类列出来，请Tom和Alice回答：这样的错出现一次，是不是就不该把系统交给值班主管使用？回答“是”的，才进入硬失败项。

能进入这张清单的错误，通常需要考虑三个方面。一是下游难以发现或补救：系统编造了一条引用，值班主管很难一眼看出来，错误就会带着可信的外表流向后面。二是可以明确判定，最好由程序判，至少由不含歧义的规则判，否则评分器的噪声会冲垮这条规则。三是清单应聚焦于高代价错误。硬失败项不是越多越稳妥：每多一项，评估集上通过的难度就加大一分，系统会为了躲开它们而变得保守，最典型的是什么都转人工。

据此，评估集v1暂定三项硬失败项：引用了输入里不存在的记录，读取了访问清单之外的数据，把应当转人工的高风险样本答成确定结论，后文依次记作H1、H2、H3。清单要在看到任何版本的结果之前，经Tom认可并冻结。

硬失败项先报告运行总数N和出现次数f。每条样本重复k次时，若需统计上界，应先把“k次中是否至少出现一次硬失败”汇总为样本级事件，再在独立、代表性抽样假设下计算该事件率的上界。这里的k是预设重复次数，与f不同；上界也不是单次运行失败率的直接估计。定向样本只报告测试结果，不据此估计线上发生率。

硬失败项出现后，应先核查是评分错误还是系统错误。评分错误按版本规则修正；系统错误则形成回归样本，纳入开发集或受控回归集。若样本来自留出集，应登记暴露情况，并补充新的留出样本，避免用已经参与调试的记录继续估计泛化表现。

5.5　转人工规则

本节回答第三个问题：哪些情形系统不应自行下结论，转多少合适，转到人手里以后复核本身会出什么问题。转人工与硬失败项相连：硬失败项规定哪些错误一次也不许出现，转人工则是让系统在那些情形下不去冒这个险。产出是转人工规则与总量限度，由Tom与Alice认定。

5.5.1　转人工的代价比较

转人工是一种合法输出。先用简化模型分析：设p为本次作答正确的概率，答错损失为c，人工复核成本为h，单位相同且c>0。若暂不计正确作答成本，并假设人工能够正确处理，则作答的期望代价为(1−p)c，转人工为h；仅当p>1−h/c时，作答更划算。人工仍可能出错，实际比较还要加入转交后的剩余损失和等待成本，不能把这个阈值直接当成完整策略。

代入一组示意值：人工复核一张转交工单约5分钟，一次误报约3分钟，一次漏报按二十倍折算约60分钟。若系统准备输出“不用提醒”，错误后果是漏报；在简化假设下，正确概率须大于1−5/60，即约91.7%，作答的期望代价才低于转人工。若准备输出“需要提醒”，错误后果是误报；其最高错误代价3分钟仍低于复核成本5分钟，按该模型，直接提醒比转交更便宜。这只是说明两种动作的阈值不同：不能据此规定所有不确定情况都提醒，尤其不能覆盖证据不足、高风险类别等强制转人工要求。实际策略还要考虑提醒总量、人工负荷以及模型置信度能否校准。

这个计算需要可信的p，但大模型口头给出的置信度并不天然经过校准，可能高估或低估实际正确率。不能未经验证就把自报百分数代入决策公式。更可行的起点是采用外部可观察的触发依据，在开发集上测量触发频度、错误识别效果和人工处理成本，再认定其适用范围。

5.5.2　三类触发依据

常用的触发依据有三类，表5-12逐类列出它们依据什么、合众通信里的例子，以及在评估里怎样检验。

表5-12　转人工的三类触发

三类触发依据中，规则触发最容易直接检验，但可靠性仍取决于字段质量、规则覆盖和执行路径。高风险类别若可由可信字段识别，应在模型之外强制转人工。证据触发检查现有记录是否足以支持结论。一致性触发则比较同一输入的多次输出，但一致不等于正确，重复结果也可能共享同一种错误；它会增加调用开销，宜先在开发集上检验其识别错误的效果，再决定适用范围。

工单TT-2026000517属于规则触发：备件行与预留记录相互矛盾，不需要模型判断，也不取决于模型有几成把握，由代码直接把这张工单转给值班主管，转交材料里列出两条记录及其状态。评估集里这条样本和同类的几条样本，用来检验这条规则是否真的生效。

触发规则也需评估。若目标是检出错误，可在隔离测试中保留触发前的候选输出，并由专家判定对错：被触发输出中真正有错的比例是查准率，全部有错输出中被触发的比例是查全率。若规则在模型作答之前就转人工，不存在候选答案，不能凭空统计“本来会答错多少”；应改用必须转人工的标签检查触发是否正确。两种评估对象需分开，同时记录单位、规则版本及处理成本。

5.5.3　转人工的总量限度

还要防止一种评分漏洞：如果转人工不受约束，全部转人工的系统可能没有已作答错误，却也没有完成自动处理任务。零作答时，已作答错误率没有定义，不能记成零。因此，评估应同时报告作答比例与已作答错误率。改变转人工规则，通常会在覆盖面和错误风险之间形成取舍，但这种关系需由数据检验，并不保证单调。把作答比例放在横轴、已作答错误率放在纵轴，每个点对应一种规则设置，就得到图5-4所示的风险—覆盖率曲线（risk–coverage curve）。

图5-4　作答比例与已作答错误率的取舍

图中可接受的区域由错误率和作答比例的约束共同决定。错误率上限由Tom与Alice结合代价认定；转人工率上限由可用复核容量推算。设每天约80张工单，当天共能安排两小时复核，每张约5分钟，则最多处理24张，占30%。若保留约六分之一的容量余量，转人工率上限可示意设为25%。这只是平均容量估计，高峰流量和复核质量还须另行检查。估计日常转人工率时，只使用具有代表性的样本；若代表性抽样自然遇到记录不足的工单，仍须计入，不能因为其正确动作是转人工就剔除。为检验风险而额外补入的定向样本另报。

按上述示意要求，可接受区域是作答比例不低于75%、已作答错误率不高于5%。若系统A有多个设置落在区域内，由Tom与Alice结合复核容量选择；较低覆盖率是否确实降低错误率，要看实测曲线。若系统B的所有设置都不满足两项要求，就不能仅靠调整转人工阈值达标，应改进系统或重新约定更窄的任务范围。5%的已作答错误率与表5-13中的C2不是同一个门槛：前者按运行计算单次错误，后者按样本检查三次结论是否均正确，二者必须分别定义和验证。

高风险样本只有两条时，即使均无失败，在独立抽样的假设下，失败率的单侧95%上界仍约为78%，不足以支持低风险声明；若两条是定向构造的，更不能据此推算线上发生率。对此不能只靠增加模型评估次数，而应把可识别高风险类别的转人工写成模型之外的规则。评估同时检查类别识别和规则执行，并用构造输入覆盖边界、缺失字段及异常路径。这能提高可检查性，但有限测试仍不构成规则绝不失效的证明。

5.5.4　转交材料与复核检验

转人工的价值，取决于转过去的是什么。系统只丢下一句“请人工处理”，值班主管还得把工单从头查一遍，就未必节省处理时间。转交材料应包括四项内容：原始输入和系统看到的记录；系统的初步判断，以及它依据哪几条记录；转交的原因，属于哪一类触发，缺什么；建议的下一步，需要谁补什么信息。“缺什么、谁能补”比一个没有来由的置信度百分比有用得多，复核的人看到的是一个可以动手的问题，而不是一个无从判断的数字。评估集v1先只评“该转时转没转”，转交材料够不够用，先由Alice抽查，等评分规则下一次升版，再作为评分项加入。

人拿到转交，不等于错误就被拦下了。复核本身是一项有质量、有负荷的任务。复核的人面对成批几乎相同的待复核项，可能加快确认、倾向于接受系统结论：既会漏掉系统没有指出的问题，也会照办系统的错误建议，经验丰富的人也不例外，培训和提醒不足以保证消除这种偏差。因此“经人复核”不能直接记作错误率为零，复核的效果也要量。

复核效果可以通过三项工作检验。第一，比较不同界面顺序，例如先展示记录与缺口、后展示系统建议，实测其是否改善错误发现率。第二，在隔离的演练队列中混入少量已知错误，统计发现比例；这些材料可从开发集失败改写，不使用留出集。第三，抽样复审已放行结果，估计其中不合格的比例，它不同于对全部错误的漏检率。还应记录耗时和退回原因；发现率下降或放行不合格比例超限时，优先调整工作量、连续复核时长和依据展示，不能直接归责于个人。

这类检验用的是人，事先要把规则讲明白：队列里会有植入的输出，结果用来改进流程，不用于评价个人。这与第4章的约定一脉相承，观察所得只评价流程和系统。转人工率的上限也因此不能只按“来得及处理”来定，要按“来得及认真处理”来定：转进来的越多，每一张分到的注意力就越少。错误的处置、转人工的总量和复核的质量定下来之后，剩下的工作，是把它们连同比例条款一起，写成可以逐条核对的验收门槛。

5.6　验收门槛

本节把前面各节的答案汇成验收门槛。评分规则回答每条样本怎样判，门槛回答有多少样本过关才算可用。门槛是整套评估里直接决定放不放行的文字，也是客户与小组之间最容易发生分歧的部分，所以要写得像条款：谁读都只有一种读法，事先写下，不随结果改动。产出是验收门槛t1，由Tom认定。

5.6.1　门槛条款的组成

验收门槛不是一个数字，而是一组条款，必须同时满足才能放行。若只用一个综合得分，某一项的优秀就能抵消另一项的不合格，一个编造引用的系统，可以靠其他项的高分过关；同时满足的写法不允许这样补偿。每条条款写清五件事：对象，即哪个评分项、在哪个集合上；度量，即分子是什么、分母是什么；数值；判定口径，是看点估计还是看区间；由谁认定。

按性质，条款分三类。比例条款规定某个评分项每次都通过的样本比例不低于多少；零出现条款对应硬失败项，规定在全部运行里一次也不许出现；总量条款规定作答比例、转人工率这类运行层面的量。表5-13是评估集v1的验收门槛t1，数值都是示意，在Tom认定之前不生效。

表5-13　合众通信验收门槛t1（示意）

注：任务验收在留出集上执行。C1至C6分别按约定样本或运行单位计算，代表性与定向样本分开报告；C5只用代表性部分估计日常转人工率。H1至H3在两部分的所有运行中检查。C7采用裁判校正或人工复核，方法与分母须事先固定；程序门槛由hezhong_ops/evals/gate.py按thresholds.yaml执行。

门槛数值有三个参照。第一是按第4章方法取得的人工差错率、返工率及其不确定性；案例中这些数仍待测。若采用“系统加人工复核”的流程，应直接检验组合后的质量，不能仅因安排了复核就降低系统要求。第二是错误代价与复核容量。第三是样本量能支持的统计结论。三者需共同考虑，不能直接把现状值抄作门槛。

门槛写成一个配置文件，与表5-13对应；本段只列程序执行的节选。文件里的版本号与评估集、评分规则一起冻结，改动按5.6.3的规则办理。C7经裁判校正后另行判定，此处从略。

# hezhong_ops/evals/thresholds.yaml（验收门槛t1，节选）

version: t1 # 门槛版本，与评估集v1、评分规则r1一起冻结

eval_set: v1

rubric: r1

clauses:

- {id: C1, metric: parse, kind: point_ge, value: 0.95}

- {id: C2, metric: conclusion, kind: point_ge, value: 0.85}

- {id: C3, metric: deadline, kind: point_ge, value: 0.85}

- {id: C4, metric: coverage, kind: point_ge, value: 0.75}

- {id: C5, metric: handoff_rate, kind: rate_le, value: 0.25}

- {id: C6, metric: handoff, kind: point_ge, value: 0.80}

- {id: H1, metric: citation_exists, kind: hard_zero}

- {id: H2, metric: access_ok, kind: hard_zero}

- {id: H3, metric: handoff_high, kind: hard_zero}

5.6.2　放行条件与保证强度

“通过率不低于90%”至少有两种判定方式。一是点估计法：留出集上的观测通过率不低于90%即满足条款。二是下界法：Wilson双侧95%置信区间的下界不低于90%才满足条款，本章取z=1.96；这不同于单侧95%下界。点估计法较宽松，样本少时可能放行实际未达标的系统；下界法较严格，也更容易拦住实际达标的系统。两者都存在误放与误拦风险，只是取舍不同，不能说风险完全由某一方承担。采用哪种口径应在验收前共同确定，不能由脚本默认值决定。

以下计算以相互独立的代表性样本和固定评分方法为前提，仅说明统计取舍，不是案例实测。以90%为门槛、Wilson双侧95%区间下界为判据时，40条须全部通过；真实通过概率为95%的系统，满足此要求的概率约13%。若只看点估计，40条中至少36条通过即可放行，真实通过概率为85%的系统也约有26%的概率通过。要使真实通过概率95%的系统有约80%的机会满足下界判据，大致需二百余条样本。这些数还取决于具体判据，不能用于互相关联或定向抽取的样本。

v1留出集只有约40条工单和十来份复盘材料，首版采用分级条件：试用级按点估计与必过清单判定，同时记录区间、样本来源、覆盖局限和人工复核安排；常规级若约定采用下界法，则须取得相应证据后重新评审。本章thresholds.yaml中的C1至C6是试用级示意，并不因安排了复核就消除误放风险。试用范围、复核责任、停止条件和升级要求须由Tom认定。扩大样本或取得线上抽检记录后可更新估计，但不同系统版本、分布或相关样本不能简单合并。分级发布见第20章。

零出现条款也要区分放行规则与统计证据。放行条件可以规定所有运行中均不得出现硬失败；估计上界时，则先按样本汇总“重复运行中是否至少出现一次失败”。在独立、代表性抽样假设下，40条样本均无这类事件，事件概率的单侧95%上界约为7.2%；两条样本均无事件，上界约为77.6%。上界描述证据的局限，不改变零出现的放行规则。重复运行不能当作新增的独立业务样本；定向样本也不能用于推算线上事件率。

5.6.3　门槛数值的确定与变更

第一版门槛应与使用范围、错误代价和人工复核能力相匹配，不能一概主张宽松或严格。若证据不足以支持常规使用，可以约定范围更窄、人工复核更充分的试用条件，并与常规验收门槛分开，5.6.2的两级安排就是这样做的。比例条款可随证据积累按规则调整；硬失败项一旦经双方认定，评估中出现一次就应阻止放行。不得为了让当前版本通过而倒推标准。

门槛变更应遵循章程中的权限与审批规则。无论收紧还是放宽，都要记录理由、适用范围、生效版本和双方责任；影响验收的变更须由Tom及相关责任人认定，小组不能仅凭通知单方面生效。已经看到结果后，不得为使该版本通过而追溯放宽标准。确因业务要求变化需要修改，应另建门槛版本，重新评审，并安排独立验证；只换一个系统版本号，不能消除已知结果带来的偏差。

系统、评估集、评分规则与具体评分器共同决定一个分数的含义，门槛则决定这个分数是否满足放行条件。因此，验收记录应列出系统版本、评估集版本、评分规则版本、评分器配置及门槛版本。程序评分器记录代码版本；裁判还要记录模型、提示和校准版本。不能只写“评估集v1”，就认为评分条件已经固定。

5.7　回归评估

本节回答第四个问题。第一次验收看绝对门槛，此后每次改动都要确认没有退步，而且评估本身要能原样重跑。产出是回归条款、评估脚本、对照系统自检和验收报告，由小组的评估与验收负责人维护，Tom签认。

5.7.1　绝对门槛与回归条款

门槛有两种用途。第一次验收看绝对门槛：系统是否达到约定的水平。此后每次改动，看的是回归：新版本不能比已验收的版本差。回归不能照搬绝对门槛来判，原因有两个。新版本每一项都过了门槛，仍可能比旧版本差几个点；而样本少的时候，有限样本可能不足以区分几个百分点的差异。

回归条款由三部分组成。第一，必过清单：历史上出过错并已修复的样本，以及硬失败项的探针样本，每次改动后都要检验。它是针对已知情形的检查，不要求先用样本推断总体，但对随机系统仍应按固定次数重复运行，不能称为确定性保证。第二，配对比较：在同一批样本上记录旧版对而新版错、旧版错而新版对的两个计数，逐条分析退步原因。第三，新出现的硬失败项一律阻止放行。发布前如何执行这些检查见第20章，本章只规定它们应当写成什么样。

5.7.2　交付物与评估脚本

表5-14列出评估集v1的交付物，每一项都有维护者和版本。

表5-14　评估集v1交付物清单

配套仓库的data/v1/目录提供一份虚构的示例数据，构成与表5-7相同：100条备件提醒工单（开发集60条、留出集40条）、30份复盘报告的要素标注、两位专家的标注与裁定记录，以及标注指南。数据由确定性的脚本生成，再逐条安排了边界、对抗和无法判定的情形，用来让读者在没有真实数据时练习评分、门槛和自检；它们不是合众通信的真实记录。教学用留出集随包提供，仅为便于练习；真实项目的验收留出集不得向调试者开放。

脚本的组织应使结果不依赖某一家评估平台。被评系统以“输入字典、输出字典”的接口调用，运行器另行记录可信的工具调用轨迹；评分不限定内部采用提示、检索还是规则。样本按行存放并记录版本，程序评分器对同样的输入给出同样结果；裁判评分器则需固定配置、记录版本并保留校准结果。系统崩溃或输出不可解析时记为失败，不中断整批评估；不得因提前返回而漏查已发生的访问违规。留出集入口只返回获准的汇总信息，每次运行记录系统、评估集、评分规则和门槛版本。

脚本按职责拆分：schema.py定义样本，graders.py评分，runner.py重复运行并记录可信轨迹，aggregate.py汇总，stats.py计算区间，gate.py判定门槛，report.py生成报告，judge_calib.py执行裁判校正。C2、C3以应作答且未在任何一次明确转人工的样本为分母；只要一次输出不可解析，该样本仍留在分母并计失败，不能因缺少字段跳过。C4另以全部应作答样本检查三次均有效作答的比例，约束选择性回避。任何条款分母为零均记为不可判定并阻止自动放行。C7按单次有效作答输出评估，不直接套用三次均通过的口径；缺失引用计失败，无效输出由格式和任务项另行计分。

5.7.3　对照系统与评估自检

评估集、评分规则和门槛也可能有缺陷，例如标签与规则矛盾、门槛遗漏、评分器总判通过。可用行为已知的对照系统检验：正确输出应满足规则，故意引入的各类缺陷应被相应条款检出。涉及访问违规的对照必须由运行器生成可信轨迹，不能只在输出中声明读过哪些表。

表5-15列出示意自检结果：合成样本共100条，其中留出40条、应转人工6条、高风险2条，仅用于检验评分与门槛逻辑。实际自检需固定数据版本、随机种子和运行次数，并保存结果。带噪声对照的理论期望不能保证某次有限样本运行必然放行或拦截；对其结果还须检查波动是否符合设计。

表5-15　对照系统与自检结果

表中有四点需要核查。第一，照抄标签的对照若不通过，应先检查标签、评分器和门槛是否矛盾。第二，高噪声对照若单次通过概率为92%，在独立运行假设下，三次全通过的概率约为78%；这是理论期望，不保证有限样本中的实际得分。第三，全部转人工应被作答比例和转人工率条款拦截；没有这类条款，仅检查已作答错误就会留下漏洞。第四，从不转人工应由C6与H3检出；H3仅覆盖高风险样本，不能代替一般转人工要求。

自检要在评估集冻结之前通过，之后每次修改评分规则、门槛或脚本都要重跑。它只说明评估在这些已知对照上符合预期，不能证明评分规则已覆盖所有缺陷。

5.7.4　验收报告与使用流程

每次验收按模板生成一份验收报告，由Tom签认。报告包含下面几项内容。

1）版本：系统、评估集、评分规则、门槛，以及评分器（裁判模型与提示）的版本。

2）结果：分子、分母、统计单位、区间及其前提、门槛与判定结果；分母为零或证据不足的，注明不可判定，不填入默认通过值。

3）转人工率与作答比例，注明只在代表性样本上估计日常比例；另报复核发现率及复审发现的不合格比例。

4）与上一个已验收版本的配对比较：两个方向的计数，以及新出现错误的逐条说明。

5）裁判评分的来源、校准数据、校正方法与不确定性。

6）评估没有覆盖什么：样本之外的设备型号，权限与安全测试，负载与成本，以及已知的局限。

开发阶段，工程师在开发集上运行并分析失败，结果不作为验收依据。验收阶段，由评估与验收负责人在留出集上运行，只返回获准的汇总与硬失败条数，并记录每次使用。即使只看汇总，反复据此调参也会使系统逐渐适应留出集，因此应预先约定使用频次与更新条件。确需查看失败样本时，须经批准并登记；已经用于调试的样本不再视作未见数据，按规则补充或更换。验收报告由Tom签认，连同版本和已知局限归档。

本章按四个问题建立任务验收依据：评估集与评分规则规定什么算成功；错误分级与硬失败项区分可容忍和不可接受的错误；转人工规则与容量限制约定保留判断的情形；回归条款与脚本检查改动造成的影响。门槛把这些要求写成可核对的条款，报告保留结果、版本和局限。后续章节用这套标准验证首个可运行版本、执行回归，并在第20章纳入发布检查。使用裁判的评分项还须完成校准；相关方法放在下一节选读，但采用裁判的项目不能跳过这项工作。

5.8　裁判模型的校准（选读）

裁判模型让需要读懂语义的评分项也能批量、反复地执行，代价是它自己成了一件需要校准的量具。5.3.2已经写明使用裁判的三个决定，本节补充裁判适合判什么、怎样设计、怎样用专家标签校准，以及投入使用之后怎样监控。不使用裁判的项目可以跳过本节。

5.8.1　裁判的适用范围与设计

在开放式对话的两两比较上，特定研究中的裁判与人类偏好一致率曾超过80%，与人和人之间的一致率相当。这个结果来自通用对话，比较的是两个回答的好坏；在运维工单上逐项判通过或不通过，是另一种任务，不能直接套用，必须在自己的数据上量。

裁判适合处理需要语义理解且判据明确的评分项，例如引用是否支持结论、摘要是否符合原始材料。可计算的要求优先用程序；专家仍有分歧的，先完善判据，不期待裁判自动消除歧义。硬失败项若由裁判发现，需按5.3.1的要求人工确认，并抽查可能的漏判。裁判结果是对专家口径的近似，报告中应标明来源、校准状态与适用范围。

裁判的提示可以这样写。优先逐项评分，减少多个判据之间的相互影响。输出二元的通过或失败，并要求先写依据，再下结论。把要核对的记录原文一并交给裁判，要求只依据这些记录判断，不凭它自己的知识。再留一个“无法判断”的出口，信息不足时让它说出来，这类输出转人工复核，比逼它在两个选项里硬选一个要好。判据用专家的话写，并附正例与反例。

裁判还有若干已知的偏差，表5-16列出它们的表现、在本任务里的影响和对策。

表5-16　裁判模型的常见偏差与对策

表中列出若干可能影响裁判的偏差，具体影响需要在本任务上测量。这些偏差不是弃用裁判的理由，而是校准集里要有意放进去的情形。既然有篇幅偏差，校准集里就应当有“写得很长、引用却不支持”的输出，否则测出来的失败识别率会偏乐观。

5.8.2　裁判的专家标签校准

校准的做法与校准任何量具一样：拿已知答案的东西去量，看它量得准不准，已知答案来自专家。要注意，这里要专家标注的是系统的输出，不是评估集里的输入。评估集v1里的标签说的是“这张工单应当怎样处理”，校准集里的标签说的是“这条输出对不对”，后者是另一轮标注。由对这件事最有发言权的一位专家（合众通信里是Alice）逐条给出通过或失败，并写下理由。专家在标注中也会修改自己的判据，看到输出才发现“支持”该怎么算。所以第一批标完之后，允许修订判据并重标所有受影响的输出；高风险判据还应由第二位专家复审，再冻结。

校准集需要同时覆盖通过和失败输出。随机抽取时失败可能太少，可以从旧版本在评估集开发集上的输出中补充，或由专家构造典型错误，但必须记录来源。每类几十条只能作为起点，是否够用要看识别率区间及错误类型覆盖。校准集分为裁判调试集和裁判检验集：前者用于修改提示，专家理由可作为示例；后者只用于冻结提示后的检验。这是与评估集的开发集、留出集不同的另一套划分，为避免混淆，本书在裁判一侧称“调试集”和“检验集”。针对同一条原始样本的输出和改写副本应分在同一侧，避免近似内容跨集。补入的失败若与实际失败类型分布不同，TNR可能偏移，不能只凭数量平衡就用于总体校正。校准材料来自评估集的开发集，不使用验收留出集，以免内容经裁判提示进入调试过程。图5-5给出这一流程。

图5-5　裁判模型的校准与使用

以专家判断为参照时，不能只看一致率。若失败占5%，永远判通过的裁判也有95%一致率，却检不出任何失败。这里以“通过”为正类：通过识别率（TPR）为专家判通过的输出中裁判也判通过的比例，失败识别率（TNR）为专家判失败的输出中裁判也判失败的比例。两者均需报告样本数与区间。TNR低意味着更多失败被放过；TPR低则可能错误拦截合格输出，验收应结合两类代价判断。

裁判判通过的比例，也不能直接当作专家口径下的通过率。设后者为p，裁判判通过的比例为q，则q=p×TPR+(1−p)×(1−TNR)，可得p=(q+TNR−1)/(TPR+TNR−1)。例如TPR为0.90、TNR为0.80、q为0.70，校正估计约为0.71。这个换算要求校准数据与被评输出中的条件识别率保持一致；模型、错误类型或输出分布变化时，该条件可能失效。TPR与TNR之和接近1时，分母接近零，估计会极不稳定，应停止校正并改进裁判。校准集和评估输出都有抽样误差，区间需要通过联合重采样等方法估计，不能只把几个区间端点代入就称为95%置信区间。

# hezhong_ops/evals/judge_calib.py（裁判校正）

MIN_GAP = 0.5 # 区分力下限，示意取值，实际应结合置信区间设定

def corrected_pass_rate(q: float, tpr: float, tnr: float) -> float:

"""由裁判判通过比例q，估计专家口径下的通过率。"""

if not all(0 <= x <= 1 for x in (q, tpr, tnr)): raise ValueError("输入必须是[0, 1]内的有限概率") gap = tpr + tnr - 1

if gap < MIN_GAP:

raise ValueError("裁判区分力不足，先改进裁判，不做校正")

p = (q + tnr - 1) / gap

if not 0 <= p <= 1:

raise ValueError("校正估计越界，核查校准适用性")

return p

# 例：q=0.70, tpr=0.90, tnr=0.80 -> 约0.714

# 正式区间须联合估计q、TPR与TNR的不确定性；端点代入仅作敏感性分析。

函数只演示点估计，不计算区间；输入概率由函数检查是否为[0,1]内的有限值。校正针对总体比例，不会自动改判某条输出。估计越界时应报告并核查抽样误差与分布不匹配，不能静默截断后当作可靠结果。正式报告还须计算校准样本与评估输出共同造成的不确定性。下面用虚构案例说明。

案例　一致率86%的裁判为什么还不能直接用

FDE小组要用裁判模型判定“所引记录是否支持结论”。Alice对200条系统输出逐条判了通过或失败并写下理由，一半作裁判调试集，一半作裁判检验集。裁判检验集的100条里，Alice判通过60条，判失败40条，失败的一部分是用旧版本系统的输出补足的。

裁判提示的第一版在调试集上漏过了不少失败：许多输出引用的记录确实存在，却属于另一个站点，裁判见编号齐全就判了通过。小组把Alice在这些失败旁写的几条理由放进提示，改成第二版并冻结，才在裁判检验集上运行：Alice判通过的60条里，裁判判通过54条，TPR为0.90；Alice判失败的40条里，裁判判失败32条，TNR为0.80。两者一致的共86条，一致率86%。

小组没有就此认定裁判可直接用于验收，那8条漏过的失败仍需关注。在评估集开发集的200次运行输出上，裁判判通过的比例为0.70；若条件识别率适用，校正估计约为0.71，裁判判通过的140条中，估计约11条实际应判失败。这个结果是总体估计，不能指出具体哪11条有错。检验集的失败输出只有40条，识别率估计仍不稳定；把区间端点代入只能用于敏感性分析，不构成校正通过率的正式置信区间。小组因此保留专家抽查，并补充独立的失败输出重新检验裁判；用于修改提示的样本不再作为未见测试数据。本案例为虚构，数字为示意。

5.8.3　使用、监控与再校准

裁判投入使用后，每次评分的结果要与裁判模型的名称和版本、提示的版本、温度等设置一起记录。这些共同构成评分器的版本，与系统版本、评估集版本一起，决定一个分数能否被解释。

下面几种情形发生时必须重新校准：更换裁判模型，包括服务方在后台更新了模型；修改裁判提示或评分项的定义；被评系统的输出形态发生变化，比如换了新的复盘报告模板；客户修订了判据。即使没有这些变化，也应把冻结的裁判检验集定期重跑一遍，TPR与TNR的变化超过约定的幅度，就暂停使用并查明原因。此外保留一道人工抽查：裁判判通过的输出，按比例抽一部分请专家复核，高风险样本抽得多一些。这既是对校准结果的持续检验，也能发现校准集没有覆盖到的新型错误。

校准有成本。按每条输出约三分钟计，200条约十个专家小时（示意），不比标注评估集便宜多少。所以裁判不是用来省掉专家，而是把经核查的判据用于大批量输出：先用专家标注检验裁判，再让裁判去做专家没有时间做的重复劳动。裁判评分项的结果怎样进入验收，见表5-13中的C7。

习题

（1）概念辨析

某物流公司的单据核对系统（虚构情形，与合众通信无关）出现四类错误：（a）把一张应付款单据的金额识别错了一位数，系统据此自动安排了付款；（b）把供应商的简称写成了全称；（c）引用了合同里并不存在的条款编号；（d）遇到手写涂改的单据，仍然给出一个确定的金额。请判断各应归入三种处置中的哪一种：比例条款（允许少量出现，只要求整体通过比例不低于某个数）、硬失败项（一次也不许出现）、转人工（系统不自行作答，交给人判断）。并从可发现性、可逆性和传播三个角度说明理由。哪一类的归属可以有不同的合理答案？为什么？

（2）计算

某系统的一次复核要同事花4分钟，一次误报的代价约2分钟，一次漏报按30分钟折算。（a）在漏报方向上，作答的最低把握是多少？（b）在误报方向上，是否值得转人工？不确定时应当怎么做？（c）开发集有200条运行输出，系统错了40条；一条一致性触发规则触发了50条，其中30条确实出了错。求这条规则的查准率与查全率，并说明在什么条件下它仍然值得用。

（3）门槛与样本量

留出集有80条，门槛是“通过率不低于85%”。（a）观测到68条通过时，点估计法与下界法各自的结论是什么？（b）下界法至少要通过多少条？区间用Wilson方法，z取1.96，可以用hezhong_ops/evals/stats.py里的min_passes核对。（c）假如你是小组负责人，会向客户提出点估计法还是下界法，或者怎样把放行条件与保证强度分开写？说明理由。

（4）找错

下面是一段虚构的验收条款，请指出至少五处缺陷，并改写成表5-13那样的条款形式。“系统综合得分（各项平均）不低于90分，即视为验收通过。首次不达标的，可以在看过结果后调整各项权重。系统答不了的问题转人工即可，转人工率不设限。凡经值班主管复核的输出，视为错误率为零。引用错误偶有发生，由值班主管自行发现。”

（5）复核设计

值班主管每周要复核约120张转交的工单。请设计一次与生产操作隔离的植入检验：植入的比例与来源，怎样避免复核的人识别出规律，发现率低到什么程度就要改流程、先改什么，以及结果怎样使用才不会变成对个人的考核。

（6）对照系统

某客服系统的任务是给出退款建议，金额超过限额的必须转人工。请设计三个对照系统，说明每个应被哪一类条款拦住；若同时缺少转人工率上限和最低作答比例，哪一个可能钻过空子？

（7）场景判断

周四下午，Tom说周五要给客户演示，希望把C6（应转人工的样本中三次都转了的比例）的门槛从80%改成70%，因为本周的结果是72%。请写出你的答复，依据5.6.3的规则，并给出两个不改门槛也能推进演示的办法。

（8）综合作业

为合众通信起草你自己的验收门槛t1，并完成自检。（a）写出你对兑换比和复核容量的估计及依据，据此给出C2、C4、C5的数值。（b）在thresholds.yaml里实现这些条款，运行自检，确认现有对照系统的结果与表5-15一致，或说明不一致的原因。（c）新增一个你自己设计的对照系统，写出预期被哪条条款拦住，并验证。（d）构造一个点估计法放行而下界法拦住的小例子。（e）另附不超过800字的说明：哪些数值是示意，哪些必须由客户认定，留出集太小时你怎样处理。

本章交付物

本章交付物是评估集v1（约100条故障工单与30份历史复盘报告的标注，分开发集与留出集）、评分规则r1与验收门槛t1，以及评估脚本hezhong_ops/evals/（含对照系统自检与验收报告模板）。