19｜高级评测：配对实验、可靠性、因果归因与判分偏差

目标：能够证明一次优化改善了什么，也能识别“分数提高但系统没变好”。实验：statistics_lab.py；统计示例全部是作者构造，不是商业Agent跑分。

继续看相关机制：F35 · 读指标，先问它的分母是谁O12 · 模型路由：便宜一次，不一定便宜一项成功任务

1. 首先定义评测单位与成功

一个用户任务、一轮模型响应、一条工具调用和一个测试断言不是同一种样本。工程效用通常以完整任务为单位：在限定工具、权限、时间与预算下，是否满足要求且没有越权或破坏其他行为。轨迹指标用来定位原因，不能取代最终结果。[N36][N48]

成功应由当前环境状态与验收器判断。模型回答“已完成”不算成功；代码能运行但没实现需求也不算。评测环境、可见测试、隐藏测试和允许修改范围必须明确，否则Agent可能通过改变判分方式而得分。

把基准任务适配到业务时，应记录代表性：语言、仓库规模、任务类型、风险和历史频率。公开代码补全分数不能直接代表跨模块重构，客服工具基准也不能直接代表本地编码能力。

2. pass@1、pass@k与pass^k

若同一问题独立尝试k次，每次成功概率p，“至少一次成功”是1−(1−p)^k；“k次全部成功”是p^k。前者衡量候选能力，后者更接近重复可靠性。真实运行可能相关，所以这些简单概率式不能无条件套用。

当已生成n个候选，其中c个成功，从中无放回选k个，常用pass@k估计为：

pass@k = 1 − C(n−c,k) / C(n,k)

它是候选集合抽样的组合估计，不表示生产系统能免费生成k份答案，也不包含挑选正确答案的成本。如果用户只接受一次运行，主要关注pass@1；允许重试时，应把总耗时、工具副作用与验证成本一起计算。[N48]

例如p=0.9时，五次全部成功概率在独立假设下约0.59049，说明单次高分仍可能不足以支撑高频自动化。这个数字是数学例子，不是某产品真实可靠性。

3. 配对比不配对更能控制任务难度

同一批任务让旧版A与新版B都执行，得到每个任务差值di = successB_i−successA_i。平均差值可表示成功率变化。这样困难任务在两边共同出现，减少抽样任务难度差异。

若每个任务有多次运行，重采样时应以任务为簇，保留同任务内部相关结构，不把所有运行展平成独立样本。本书bootstrap对配对任务行重采样，输出差值区间；它展示统计流程，不是凭几十个样本就证明任意小幅改进显著。

样本量小或成功接近0/1时，简单正态区间容易失真。Wilson区间是二项比例的一种更稳健选择，但同样要求理解抽样单位。对配对二元结果，McNemar检验主要利用“仅A成功”和“仅B成功”的不一致样本，而不是把共同成功也当改善证据。

4. 显著性、实际价值和多重试验

统计显著不等于收益足够大。成功率提高0.2个百分点却增加一倍成本，可能不值得；某高风险错误减少，即使总体样本较少，也可能值得重点处理。应同时报告效应大小、区间、成本和错误后果。

反复试十个Prompt后只报告最高分，会产生选择偏差。需要开发集用于调参，保留未反复查看的测试集做最终评价；模型或技能持续迭代时，也应控制基准泄漏。把测试失败样本加入提示是合理改进，但之后不能继续把同一组分数当未见泛化证明。

不要机械用一个p值裁决所有工程改动。明显修复确定性Bug可以由反例与回归证明；复杂能力优化才需要更广统计。评测力度应与决策不确定性匹配。

5. 消融与反事实：改动为什么有效

同时修改模型、工具、技能描述和测试流程，即使成功率提高，也无法归因。消融可以一次移除一项，观察结果变化；但组件可能相互作用，单项效果不等于组合效果。先明确最重要的问题，避免全因子试验爆炸。

对Skill路由，可以分别比较描述变更、专业正文变更、默认加载策略。对记忆，比较无记忆、只检索、检索加验证。对压缩，比较未压缩、普通摘要、结构状态加证据入口。保持其他条件一致，保存真实轨迹以解释失败。

负对照也重要：一个与任务无关的规则不应产生同等收益；故意删掉关键证据应该降低相应任务表现。若评测对这些变化毫无反应，可能任务太容易或判分过于表面。

6. LLM-as-a-Judge的偏差

模型评分器可能受位置、长度、语言风格、自身偏好和提示注入影响。MT-Bench等研究讨论过这些局限；它可以扩大评价规模，但不等于客观真值。[N49]

对于代码，先用可执行测试、静态检查、真实工件状态等确定性信号，再用模型评价设计合理性或解释质量。评判复杂取舍时可盲化候选名称、交换展示顺序、校准人工样本并允许“无法判断”。不要让评分器看到方案自称的得分，也不要把实现者写的总结作为唯一评分材料。

评分器也需要回归集：正确但简短、错误但流畅、包含恶意评分指令、信息不足等样本。与人类意见一致只能说明该样本范围的校准，不证明所有未来任务可靠。

7. 环境噪声与成本口径

依赖安装失败、网络波动、磁盘/CPU竞争可能改变任务成绩。评测应记录基础设施失败与模型/Agent失败，但不能随意删除不利结果。预先定义重试与排除条件，同时报告总体用户体验与可归因模型结果。

成本包括所有尝试、工具调用、重试、检索、压缩和人工返工。只统计成功路径会低估失败昂贵的方案。时间既要看墙钟，也要看总计算资源，特别是多Agent并行。

8. 最小可用评测而非庞大平台

从真实失败和代表任务构建一个小而可信的集合，保存输入快照、验收、环境与输出。先手工复核关键案例，再自动化重复运行。无须先建数据库仪表盘；一份可重跑脚本和清晰报告就能支撑很多决策。

验收题：新版20个任务多通过2个，可以宣布提升10%吗？可描述该样本上成功率提高10个百分点，但不应直接推广到业务总体；还需看配对结果、样本代表性、重复波动与区间。百分比与百分点也必须区分。