一个助手说“活动信息已核对并更新”，最终页面却仍是旧地点。另一套助手没有漂亮的长回答，却给出新公告、修改后的页面和核验时间。哪一个真正完成了任务？
第23章讨论一个模型分数能支持什么结论。本章把被测对象扩大到整个系统：从用户提出目标，到资料获取、模型判断、工具执行和结果确认。模型答对，是其中一个环节；用户得到正确、及时且没有越权的结果，才是端到端评测关心的事情。
1．先定义任务的终点
沿用前几章的海报核对任务。如果用户只要求检查，成功意味着四项信息均有适用证据，差异和无法确认项表达准确，且没有擅自修改。如果用户明确要求并授权修正地点，成功还要求目标页面确实改变，其他内容没有误改，并提供可核查回执。
同一句“已完成”，在这两个任务中需要不同证据。评测应在运行前写明输入、获准动作、终止条件与评分规则，不能运行后把“输出了文字”临时改成成功标准。
设N是进入评测的有效任务总数，S是满足预定全部要求的任务数。端到端成功率就是S/N。这里的斜线表示除法。分母不能只挑模型愿意回答、没有超时或成功走到最后的任务，否则困难任务会从账上消失。
受阻、取消、拒绝与失败也要按预先规则区分。面对未授权请求，正确拒绝可以是该安全测试的成功；面对本来可完成的正常请求，无理由拒绝则不是成功。测试目标不同，不能靠改标签把两者混为一谈。
2．五步都很准，为什么整体还会明显下降
假设一次任务有五个必要环节：需求理解、资料获取、判断与生成、工具执行、结果核验。只有五步都成功，任务才成功。先作一个很强的教学假设：每一步成功率都是95%，各步是否成功相互独立，没有重试，也没有后续步骤替前面的错误补救。
整体成功率于是等于：
0.95⁵＝0.95×0.95×0.95×0.95×0.95＝0.7737809375，约77.4%
上标5表示把0.95相乘五次，不是乘以5。直觉上，第一步留下95%的任务，第二步从这批里再留下95%，依次缩小。第二步后剩90.25%，第五步后剩77.37809375%。这些是概率与比例，不是一次100项实测中出现了小数个成功任务。
但“每步95%”本身并不足以支持连乘。若五步总在同一批5%的困难任务上一起失败，整体可以是95%；若每步各失败于不同的5%任务，五批完全不重叠，整体便是75%。两个例子各步的单独成功率都一样，失败落在哪些任务上却不同。
图1｜上半部按同一概率刻度画出五次留存，独立假设下最终为77.37809375%；下半部用100项的教学分组说明，同样每步边际成功95%，整体可以是95%或75%。连乘条件概率与假设独立的关系见下文。
更一般的连乘方法不要求独立。用p₁表示第一步成功的概率；p₂表示已经知道第一步成功以后，第二步成功的概率；p₃表示前三步中的前两步都成功以后，第三步成功的概率，后面以此类推。整体概率仍是p₁×p₂×p₃×p₄×p₅。
这里的p₂到p₅是条件概率，条件必须包含此前各步都成功。如果这些条件概率均为95%，同样得到77.4%，无须额外假设独立。独立性的作用，是允许把在全部任务上测到的各步单独成功率直接代入。只知道流程“走到了第二步”，也不一定知道第一步实际上正确，因为错误可能尚未被发现。
3．用一百张任务卡，算出三个不同的成绩
下面另做一组虚构的任务账本，不把它当成前面概率公式的实测验证。100张任务卡中，80张首次运行就完成；余下20张在安全允许的条件下各重试一次，其中12张恢复成功。剩下8张中，5张由人工接管并最终完成，3张仍未完成。
首次成功率是80/100＝80%。允许一次重试后的自动完成率是92/100＝92%。把已经完成的人工接管也计入，整个服务的最终完成率是97/100＝97%。这三个数回答不同问题，应该并列报告。
不能把“已转交人工”直接算作完成。人工尚未处理时，状态仍是等待；最终成功需要人工处理后的证据。也不能报告97%却隐去5%的任务需要人来收尾，让读者误以为系统具备同等自动化能力。
若特别关注重试效果，恢复率可以写作12/20＝60%，分母是首次未成功且进入本次重试的20项。它不是全体任务的60%，也不保证换一批故障还会恢复六成。超时、缺资料、错误参数和权限不足，本来就可能需要不同处理。
4．成功也有总成本
令C是这批任务全部运行成本，包含失败尝试和必要人工处理。每个最终成功任务分摊的成本是C/S。S为零时，这个比值没有可用的有限结果，应直接报告没有成功任务与总投入。
给刚才的教学账本规定一种虚构成本单位：每次自动尝试花1单位，每项人工处理花4单位。100次首次尝试用100单位，20次重试用20单位，5项人工处理用20单位，总成本为140。最终成功97项，每成功任务成本为140/97，约1.44单位。
如果只把成功路径的费用加起来，失败越多的方案反而可能显得越便宜。系统比较需要保留全部资源总账，也分别列出自动调用和人工投入，避免把人的时间藏成零成本。
图2把100项的去向和140单位投入放在一起。沿成功出口计数时，仍要把通向失败出口的投入留在总成本里。
图2｜虚构账本中80项首次成功、12项重试恢复、5项人工完成、3项未完成，四类合计100。全部投入为100＋20＋20＝140单位；自动完成率92%，含人工的最终完成率97%，每最终成功成本140/97约1.44。
真实账本还可能包括模型输入输出、检索、外部工具、存储和运行机器。不同服务的计价方式不一样，不能只用输出字数换算费用；本章的“1单位”也不是任何供应商的报价。比较时应固定工作量、计价口径和观察时段。
5．平均很快，不代表大家都等得起
端到端延迟从系统接收任务开始，直到获得规定的完成证据，包含排队、模型生成、工具等待和重试。流式输出的首字很快出现，只能说明用户较早看见内容，不能替代整项任务完成时间。
平均值容易掩盖少量长等待。另取20项虚构任务，18项各用4秒，另两项分别用20秒和60秒。平均耗时是（18×4＋20＋60）/20＝7.6秒；但有用户等了整整一分钟。
P95是一种尾部延迟指标，大致表示95%的记录不超过的时间。为避免小样本算法歧义，这里采用“排序后取向上取整的第0.95×N项”。N为20，取第19项，得到20秒。别的软件可能使用插值算法，所以报告中应说明计算方法。
图3每一个点代表一条已完成任务记录，按耗时从小到大排列。先数到第19项，再看它的高度；平均线与第19项的高度，回答的是不同问题。
图3｜20个可数点对应18个4秒、1个20秒和1个60秒。纵轴按真实秒数绘制；平均7.6秒用虚线标注，最近秩定义的P95取第19项20秒，而不是最大值60秒。本例20项均已完成，不包含被删去的超时记录。
仅20项不能稳定估计真实服务的尾部。超时任务也不能删除后再宣称系统很快，应单列超时率、截止时间和仍未完成的状态。重试若提高成功率却把P95推过用户可接受的期限，仍可能不适合该任务。
6．追踪记录让失败可以定位
一次运行的追踪记录，至少应能连接任务编号、模型和配置版本、关键输入来源、工具请求、实际返回、时间、状态变化与最后评分。这里记录的是可观察事件和证据，不需要把模型内部思考当作真相依据。
假设最终地点错了，追踪可以区分几种原因：没有召回新公告；拿到了新公告却用了旧地点；生成了正确修改参数但工具失败；工具成功却改到了另一张海报。它们的最终分数都可能是失败，修复位置却完全不同。
局部评分服务于诊断，最终评分服务于用户目标。检索命中率提高但完成率没有提高，可能说明瓶颈在后面；工具格式合格率很高但经常改错对象，则需要检查对象匹配和权限，不能继续只优化JSON格式。
日志也有成本和隐私边界。保存必要的来源标识、状态和脱敏信息，比无差别记录全部私人内容更合理；保留期限与查看权限同样属于系统设计。可追踪不能成为额外泄露信息的理由。
接着把其中一种失败走完。以下全部是受控纸笔实验，不是真实系统测试报告。追踪显示：先取到同一活动的新版公告v2“南厅”，随后读到历史存档v1“北厅”；内部合并按到达顺序覆盖地点，最后报告北厅。新公告的召回是成功的，错误发生在状态合并，继续增加搜索次数不对准根因。
这次只修改“选择适用版本”的规则，模型、提示、工具和评分不变。已确认是同一活动、且v2明确替代v1时，后来读到v1也不能覆盖v2；无法建立修订关系则保留冲突。原来的失败样例连同新旧顺序反转、版本关系缺失的变体进入回归集，用来检查这处错误是否重现。通过这些题，只能说明已知问题被覆盖。
随后在一份未参与修改的40题留出集上比较两个版本，给每题最多4次读取，每批总读取上限160，失败与超时仍计入40题分母。设教学结果为：旧版32题成功，新版35题成功；其中5题从错变对，2题从对变错，因此净增3题，而不是“只修好了3题”。对应成功率从80%变为87.5%，未成功数从8变为5。
如果两道新错误里有一道把同名活动公告并入了错误对象，整体上升仍不足以支持采用。它暴露的是活动身份检查的缺口，不能靠更高平均分抵消。成本和延迟也必须据实际记录另算：相同预算上限并不保证两版用掉相同资源，更不能从35题成功推导C/S或P95。
图4｜同一教学失败先由追踪定位到“旧版本覆盖”，再只改版本合并规则。已知失败与变体进入回归，40题未参与修复的留出集另行评价；5题改善、2题退步对应32→35。图中明确保留新错误，避免把局部修复写成系统已经可靠。
这是回归测试与留出评测各自的作用：前者守住已知行为，后者提供未用来修补该错误的新证据。若再根据这40题修改，它们就成为下一轮开发证据，不能继续当作完全未见的测试来夸大效果。
也可以借用软件测试的层次定位问题。单元测试先固定状态与输入，检查合并函数是否拒绝旧版本覆盖、预算是否准确扣减；集成测试接上受控读取工具，让它返回超时或旧页面，检查错误、来源与版本能否穿过接口完整传到状态；端到端评测再判断用户目标有没有达成。回归描述的是“改动后重查已知行为”，可以发生在这三层中的任一层，不是只放在最后的一种测试。
这些联系不要求把LLM当作确定程序。字段校验与计数可以逐项断言，模型选择的动作和措辞却可能随运行变化；两个文字不同的报告也可能同样正确。应按事实证据、允许动作、完成条件与实际副作用评分，对有随机性的部分重复运行并记录波动。一次样例通过不能证明以后必然通过，单纯逐字比对也会把等义答案误判为失败。评测设计实践
7．重试之前，先检查结果证据与幂等契约
对于只读请求的暂时超时，有限次数重试可能有效；对于参数错误，重复同一参数通常只会重复失败；权限不足需要停下，不能通过换接口绕过限制。总次数、总时间和资源上限应共同约束重试。
最危险的情况是动作已经提交，却没有收到回执。此时状态应写“未知”，不能直接写“未执行”。例如已获准的页面更新可能已经生效，再发一遍可能造成重复记录或覆盖后来的修改。
接下来要分清两种条件。若没有明确且仍有效的幂等保证，应先查询同一操作标识或目标当前状态；确认已完成，就核验结果并补上回执；只有确认未执行、原请求也不会迟到后再生效，且授权、预算与目标版本仍适用时，才受控重试。若仍无法确定，又可能产生副作用，就停止自动重发并交给人工判断。一次查询“暂未看到修改”不等于证明原请求没有执行或不会再执行。
若服务端已经提供明确且仍有效的幂等契约，则不必一律等到“确认未执行”才能重试：同一key、相同参数、同一作用域，并且仍在服务承诺的有效期内，可以按契约受控重试。已处理的请求应由服务去重，并返回已有操作的结果或状态；尚未处理的请求按契约执行。取回的状态若仍是处理中，不能当成完成；拿到成功回执后，仍按原任务的完成标准核验。不能临时换key、改参数、换作用域或把过期记录当作仍受保护。授权、预算和必要的目标版本约束也仍要满足；若重试后仍无可靠结果，就保留未知并有限查证或人工接管。
图5｜回执丢失先记为结果未知。有明确、仍有效的服务端幂等契约，可在同key、同参、同作用域和有效期内受控重试，以取回结果或按契约执行；无此保证则先查证，仍未知且可能有副作用时停止并接管。确认未执行还须排除原请求迟到生效；所有重试都受授权、预算与必要的目标版本约束。
关键保证来自执行端，而不是客户端给请求起了编号。RFC 9110区分可安全重复的幂等语义与非幂等请求：不能仅因没有收到响应，就推断一次有副作用的操作可以重发；而在已知幂等语义下，原响应丢失并不自动禁止重试。幂等要求预期作用不因重复而增加，也不保证每次响应的字节完全一样。RFC 9110 §9.2.2
具体契约要具体读。AWS EC2的说明要求检查client token、参数以及区域或可用区作用域；同一token换到另一个作用域可能创建另一个资源。AWS的工程说明还讨论去重记录的保留期限与重复请求的语义等价响应。这些例子支持“先核实契约条件”，不是“凡带key的请求都可以随便重试”。EC2幂等条件 幂等重试的服务端契约
去重与防覆盖也是两件事。幂等契约防止同一意图被重复处理；目标版本条件防止当前操作覆盖别人后来的修改。检查结果与重试之间也可能有新变化，不能用前者替代后者。
回滚适用于能够可靠撤销的操作；补偿则是用新动作尽量纠正已发生的影响。已发送的信息即使补发更正，也不能保证别人从未看到。恢复评测需要检查副作用和授权，不能只看最终页面是不是对了。
8．把官方实践变成自己的测试方案
OpenAI的Agent评测指南把运行追踪用于定位工具选择、移交、安全边界和流程变化，再用固定数据集及评测运行检查改动能否重复产生效果。这体现了“先定位，再验证”的关系，不限定每个系统必须使用同一个SDK或页面字段。Agent工作流评测
其评测实践说明还强调任务特定测试、持续评估，以及用人工判断校准自动评分。把这些原则用在海报助手上，就应同时保留正常公告、旧版本冲突、链接超时、错误对象和注入内容等样例。评测设计实践
先在虚构数据与受控工具中注入故障：让一次读取超时，让一次写操作执行后丢回执，让一个旧页面混入检索。再检查系统有没有正确分类、遵守预算、保留未确认状态并安全恢复。故障测试不是拿真实用户资料去冒险。
比较新旧系统时，应使用同一批任务和明确的版本，保留简单基线；调试用过的失败例可以进入回归集，但仍要留出没参与调试的测试样本。关键指标既看总体，也按任务类型分组，防止常见简单任务掩盖少数高风险失败。
还应预先写出什么变化值得发布。新版本即使平均成绩略升，若在高影响任务上新增越权或重复执行，就不应靠平均分把风险抵消。可以先在受控范围比较，再逐步扩大使用；一旦关键指标恶化，应有停止或退回已验证版本的路径。退回版本也要检查资料与外部状态兼容，不能假设软件回退会撤销已经发生的外部动作。
本章练习
题目
问题1｜五个95%的分母
五步都必须成功。情景A给出每步在全部任务上的单独成功率95%，没有说明依赖关系；情景B给出第一步成功率95%，以后各步在“此前都成功”条件下的成功率也为95%。哪种情景可以直接连乘？写出整体结果，并说明另一种情景缺少什么。
问题2｜成功率与全部成本
100项中80项首次成功；20项各重试一次，其中12项成功；剩余8项里5项由人工完成、3项仍未完成。自动尝试每次1单位，人工每项4单位。求自动完成率、最终完成率、总成本及每最终成功成本；已转交但未完成的任务能计入最终成功吗？
问题3｜找到尾部位置
20项已完成任务中18项4秒、1项20秒、1项60秒。计算平均延迟；按最近秩法求P95，并说明为什么不是60秒。如果另有超时任务，应怎样报告？
问题4｜未知回执与验证改进
写操作超时后，分别在“没有有效幂等保证”和“有明确且仍有效的服务端幂等契约”两种情景下说明恢复路径与重试条件。再看正文的版本修复：新公告已经取到却输出旧地点，应先改哪个环节；40题从32成功变35成功，为何仍不足以断言系统可采用？
思考提示
提示1｜对应问题1
比较边际概率与条件概率。流程走到了下一步，不等于此前实际正确。
提示2｜对应问题2
把任务数和尝试次数分账，失败尝试也消耗成本。
提示3｜对应问题3
先排序，再计算向上取整的0.95×20位置；保留超时自己的状态和分母。
提示4｜对应问题4
前半先区分执行证据与服务端契约，核对key、参数、作用域和有效期；后半问定位、改动变量和未参与修复的检查。
参考答案与解析
答案1｜对应问题1
B可以直接按条件概率链连乘，得到0.95⁵＝0.7737809375，约77.4%，无须再假设独立。A还缺依赖关系；若另外假设各步独立，也可得77.4%，但共同失败时可为95%，五组失败互不重叠时可为75%。
答案2｜对应问题2
自动完成率（80＋12）/100＝92%；含人工最终完成率（80＋12＋5）/100＝97%。总成本100×1＋20×1＋5×4＝140单位；每最终成功成本140/97≈1.44单位。仅转交未完成不能计成功，必须有完成证据。
答案3｜对应问题3
平均（18×4＋20＋60）/20＝7.6秒。最近秩取第ceil(19)＝19项，对应20秒；60秒是第20项和最大值。本题所有20项均已完成。若另有超时，应单列超时数量或率、截止时间和未完成状态，不能静默删除后把这20项的完成延迟代表全部任务；须明确延迟统计的覆盖范围。
答案4｜对应问题4
超时只能说明结果未知。没有有效幂等保证时，先查询同一操作或目标状态：已完成则核验；确认未执行且排除原请求迟到生效，再检查授权、预算、版本条件，才可受控重试；仍未知又可能有副作用则停止自动重发并接管。有明确且仍有效的服务端幂等契约时，可在同key、同参、同作用域和有效期内受控重试，取回已有结果或按契约执行；授权、预算与必要的目标版本约束仍须满足，不能靠换key绕过去重。重试仍无结果，也不能宣称成功。
版本例应先修状态合并的适用版本判断，而非盲目加检索。40题的35成功包含5改善与2退步；新错误、成本、延迟及样本与运行波动仍需检查，关键的对象混淆也不能用平均分抵消。
下一章
判断系统是否更好，要把成功证据、全部成本、完成延迟和失败后果放在一起。更高的局部模型分数，可能在不可靠工具、错误权限或无限重试里被抵消。
最后一章把这些判断带回模型报告：看到架构、参数量、推理预算和榜单时，怎样区分已经知道、仍然未知，以及必须用自己的任务来验证的部分？