03. 指标、统计与可靠性
读完本章，你应该能：
本章回答：怎样选择指标，才能让 eval 结果对应你真正关心的产品问题。
学习目标
读完本章，你应该能：
- 正确区分 pass@1、pass@k 与 pass^k。
- 解释为什么 pass@k 与 pass^k 会随 k 朝相反方向变化。
- 用 TPR/TNR、precision/recall 校准二元 judge。
- 把成本、延迟、方差、置信区间和失败严重性纳入 eval 解释。
本章导读
指标最危险的地方，是它看起来比人的判断更客观。一个 91% 的通过率、一个 0.84 的 judge 分数、一个榜单排名，都会让人产生“事情已经被测量清楚了”的感觉。但指标只会回答它被设计来回答的问题。如果问题问错了，数字越精确，误导就越强。
比如 pass@k 和 pass^k 的区别，表面上只是符号差异，实质上却代表两种完全不同的产品世界。pass@k 说的是“多给几次机会，至少能不能做对一次”，这适合离线生成和候选筛选；pass^k 说的是“重复发生时，能不能每次都做对”，这才接近客服 agent、付款 agent 或代码自动修改工具的上线要求。一个系统可以在 pass@10 上接近完美，同时在 pass^10 上几乎不可用。
所以本章讨论指标时，会一直追问一个朴素问题：这个数字要帮谁做什么决定？如果它不能影响上线、回滚、修复优先级或风险判断，它可能只是一个漂亮但无用的装饰。
指标不是分数，而是问题
一个好指标必须回答一个明确问题。pass@k 回答的是“系统有没有能力在多次尝试中至少做对一次”，所以它适合代码候选生成、离线 rerank 和带人工筛选的工作流。pass^k 回答的是“同类任务重复发生时，系统是否每次都稳定成功”，所以它更接近客服、支付、订单、改签这类上线可靠性问题。TPR 回答的是“judge 会不会漏掉真实失败”，TNR 回答的是“judge 会不会误杀正常样本”。cost per successful task 回答的是“这次提升是否值得成本”，latency p95/p99 回答的是“最慢那批用户是否还能接受”。
这些问题看似简单，却决定了指标是否有用。假设两个差旅报销 agent 的 pass@5 都很高，其中一个需要反复生成草稿、重试政策检索、最后由人工挑一个结果；另一个在单次运行里就能稳定识别缺失项目编号、超预算说明和员工确认状态。它们在离线候选筛选里也许都不错，但在线上产品中完全不是同一种可靠性。再比如一个 judge 的 agreement 很高，但真实失败几乎都被漏掉，那么它对上线 gate 没有保护作用，反而会制造安全感。
因此，原先的指标要点仍然要保留，只是要把它们放回具体决策里理解：
- “模型有没有能力偶尔做对？”适合 pass@k。
- “用户每次来都能不能做对？”适合 pass^k 或 repeated success rate。
- “judge 会不会漏掉真实失败？”适合 TPR。
- “judge 会不会误杀正常样本？”适合 TNR。
- “这次提升是否值得成本？”适合 cost per successful task。
- “上线后用户是否会等太久？”适合 latency p95 / p99。
所以写 eval 报告时，不要先堆指标名，而要先写决策问题：这个数字要帮助谁决定什么？如果你不能说清楚一个指标会影响上线、回滚、修复优先级、人工审计还是成本预算，就不要把它放进主报告。指标越少、问题越清楚，团队越容易围绕它采取行动。
pass@1、pass@k 与 pass^k
pass@1：单次成功率
pass@1 是最直观的指标：每个任务只跑一次，成功为 1，失败为 0，最后取平均。它适合快速比较，但对随机性和可靠性不敏感。
pass@1 的优点是朴素，缺点也正来自朴素。它把每个任务的一次运行当作代表，这在 deterministic 系统里通常够用，但 LLM/agent 有采样随机性、工具波动和环境噪声。一个 agent 今天在某个 case 上成功，不代表明天同样输入仍会成功。对于关键任务，pass@1 更像初筛，而不是可靠性证明。
pass@k：k 次里至少成功一次
pass@k 回答：“如果给系统 k 次机会，只要有一次成功就算这个任务可被解决，那么成功概率是多少？”
这适合：
- 代码生成：生成多个候选，只要一个通过测试即可。
- 搜索/推理：best-of-k 或 reranking 可以挑一个答案。
- 有人工或 verifier 过滤的离线生成。
OpenAI HumanEval/Codex 采用了 pass@k 的无偏估计形式，而不是简单套 1 - (1 - p)^kChenCodex2021。当每题抽样数有限时，naive plug-in 会偏高。
pass@k 的直觉很符合“生成多个候选，再挑一个”的开发方式。代码生成就是典型例子：模型一次生成的补丁不一定对，但如果生成 10 个候选，再用测试筛选，至少有一个通过的概率会高很多。这时 pass@k 是合理的，因为产品流程本身包含候选选择。但如果用户只会看到第一次响应，或者系统没有安全的自动筛选器，pass@k 就会过于乐观。
pass^k：k 次必须全部成功
pass^k 回答：“同一个任务重复 k 次，是否每次都成功？”
这适合：
- 客服 agent。
- 自动改签/退款/付款 agent。
- 内部工作流 agent。
- 任何用户不会接受“多试几次总能成功”的产品场景。
tau-bench 用 pass^k 表达 agent 可靠性，因为 customer-service 类任务真正需要的是每次都遵守政策并完成正确状态变更TauBench2024。
pass^k 的残酷之处在于，它把偶发失败放大成产品现实。一个客服 agent 单次成功率 90% 看起来不错，但如果同一类任务在一周内发生 10 次，全部成功的概率只有 0.9^10，约等于 35%。这不是数学游戏，而是用户体验：一次错误退款、一次错误取消、一次隐私泄露，都可能让“总体上还不错”的系统不能上线。
一个数字例子
假设某 agent 单次成功率 p = 0.75。
| k | pass@k：至少一次成功 | pass^k：每次都成功 |
|---|---|---|
| 1 | 0.75 | 0.75 |
| 3 | 0.984 | 0.422 |
| 5 | 0.999 | 0.237 |
| 10 | 接近 1.0 | 0.056 |
这个表假设 p 是已知的真实单次成功概率，只用来说明 pass@k 和 pass^k 的方向差异。真正用有限样本报告 HumanEval 风格的 pass@k 时，仍应使用下面的无偏估计，而不是直接把样本通过率代入 1 - (1 - p)^k。
这就是很多 agent demo 的幻觉来源：如果你允许多试几次或人工挑选结果，系统看起来很强；如果你要求每次都成功，可靠性会迅速塌缩。Wolfe 也强调，pass@k 随 k 上升，pass^k 随 k 下降，它们描述的是相反的产品问题WolfeAgentEvals2026。
因此，报告这两个指标时要明确产品流程。如果你的系统确实会生成多个候选并由 verifier 自动选择，pass@k 可以进入主指标；如果你的系统直接替用户执行动作，pass^k 或 repeated success rate 才更接近上线风险。很多团队不是不会算指标，而是把离线研究指标拿去回答线上可靠性问题，这才是危险所在。
pass@k 的无偏估计
如果某题抽样 n 次，其中 c 次正确，HumanEval 常用估计为：
pass@k = 1 - C(n - c, k) / C(n, k)直觉是：从 n 个样本里抽 k 个候选，全错的概率是 C(n-c,k)/C(n,k)；至少一个正确就是 1 - 全错概率。实现时不要直接算巨大组合数，而要用稳定的乘积形式AwesomeEvalsPatterns2026。
注意：pass@k 依赖独立采样。如果你 temperature=0 或缓存导致多次输出高度相关，pass@k 会失真。
Judge 校准指标：不要只看 agreement
LLM judge 最常见的错误是报告“与人工标签一致率 90%”。如果真实失败只占 10%，一个永远预测 PASS 的 judge 也能有 90% agreement，但它抓不到任何失败。Hamel/Shreya 的 walkthrough 把这称为 agreement trapHamelShreya2026。
把“失败”定义为 positive，可以得到：
| 指标 | 问题 | 公式含义 |
|---|---|---|
| TPR / Recall | 真实失败中，judge 抓到了多少？ | TP / (TP + FN) |
| TNR / Specificity | 真实通过中，judge 放行了多少？ | TN / (TN + FP) |
| Precision | judge 判失败的样本里，多少真失败？ | TP / (TP + FP) |
| FPR | 真实通过中，被误杀多少？ | FP / (FP + TN) |
| FNR | 真实失败中，漏掉多少？ | FN / (FN + TP) |
上线时要分开看 TPR 和 TNR。安全、隐私、支付、越权等高危失败通常要求高 TPR；用户体验类 judge 也要控制误杀，否则团队会被 false alarm 淹没。
这里有一个常见取舍：高 TPR 往往意味着更愿意报警，可能带来更多 false positives；高 TNR 则意味着更少误杀，但可能漏掉真实失败。不同场景的容忍度不一样。隐私泄露 judge 可以接受更多误报，因为漏报代价太高；语气风格 judge 如果误报太多，会让团队疲于处理无意义告警。校准 judge 时，真正要定的不是“越高越好”，而是“这个业务场景愿意承担哪种错误”。
二元 judge 为什么优于 1 到 5 分
Eugene Yan、Hamel Husain 和多篇 LLM judge 实践都建议优先用 binary 或 pairwise 判断，而不是 1 到 5 Likert 分YanJudgeTalk2024HamelJudge2025。原因：
- 边界更清楚：PASS/FAIL 对应产品决策。
- 更容易校准：只需看真阳性和真阴性，不必解释 3 与 4 的差异。
- 更适合 CI：是否阻断 PR 是二元决策。
- 更容易转成 failure mode：一个 judge 对应一个窄问题。
这不代表连续分数永远没用。连续分数可用于探索、排序和弱信号监控，但不要直接把未校准连续分数当上线 gate。
连续分数最适合做探索。比如你想从一万条线上回答里挑出最可疑的 200 条给人看，一个粗略质量分可能很有帮助。但上线 gate 需要的是稳定边界：过还是不过，是否阻断发布，是否需要人工接管。把连续分数直接硬切成阈值，通常会把 judge 的不稳定性变成工程流程里的随机红灯。
Agent 可靠性指标
长时程 agent 的失败不只是“错/对”，还包括不稳定、循环、策略塌缩和成本失控。Khanal 等提出了一个长时程可靠性框架KhanalReliability2026：
| 指标 | 含义 | 适合观察 |
|---|---|---|
| Reliability Decay Curve (RDC) | 任务时长增加时 pass^k 如何下降 | 长任务可靠性衰减 |
| Variance Amplification Factor (VAF) | 任务变长是否放大随机失败 | run-to-run 不稳定 |
| Graceful Degradation Score (GDS) | 失败时是否至少部分完成 | 长任务部分信用 |
| Meltdown Onset Point (MOP) | 工具调用熵是否显示循环/崩溃 | agent thrashing、无进展循环 |
这些指标提醒我们：一个 agent 在短任务上 pass@1 高，不代表它能在 2 小时任务上稳定工作。
长时程 agent 的质量更像耐力测试，而不是短跑成绩。任务越长，记忆压缩、工具错误、上下文污染、重复尝试和策略漂移越容易积累。一个模型在 5 分钟任务中看起来聪明，到了 2 小时任务可能开始循环、忘记目标、或者为了推进而跳过确认步骤。可靠性指标的作用，就是把这种随时间累积的失败显性化。
这些指标也提醒我们不要把“长期可靠性”压成一个平均 pass rate。RDC 要求你按任务时长或步骤数分桶，看可靠性曲线在哪里开始下滑；VAF 关心同类任务重复运行时波动是否被放大；GDS 承认长任务里“失败到一半”和“几乎完成但最后一步失败”不是同一回事；MOP 则把工具调用序列的熵当作早期告警，帮助发现 agent 开始循环、乱试工具或失去推进方向。它们不是每个团队第一天都要实现的指标，但能防止你用短任务平均分替代长期部署判断。
成本与延迟是指标，不是备注
Kapoor 等在《AI Agents That Matter》中强调 cost 应是一等指标KapoorAgentsMatter2024。Agent eval 如果只报告 success rate，会漏掉三个关键问题：
- 一个模型成功率高 2 个点，但成本高 10 倍，是否值得？
- 一个 harness 通过率高，但 p95 延迟超过用户耐心，是否能上线？
- 一个 agent 多调用 50 次工具才成功，是否只是把成本转嫁给 infra？
建议至少报告：
- 平均成本和 p95 成本。
- 平均延迟和 p95/p99 延迟。
- token 用量、tool call 数量、重试次数。
- cost per success：总成本 / 成功任务数。
- 分场景成本：不要让简单任务掩盖复杂任务。
成本和延迟不是“附录里的工程细节”。它们会改变产品可用性，也会改变模型选择。一个成功率高 2 个百分点、成本高 10 倍的方案，也许适合高价值后台任务，却不适合高频客服入口。一个平均延迟很好、p99 极差的系统，可能让少数用户经历灾难性等待。eval 报告只有把质量、成本和延迟放在一起，才像一个真实产品决策文件。
方差、样本量与置信度
LLM eval 的结果会受样本量、随机 seed、采样温度、judge 漂移和任务分布影响。报告结果时要回答：
- 每个 case 跑了几次？
- 总样本数是多少？
- 是否使用同一个 seed 或多 seed？
- 置信区间或 bootstrap 区间多宽？
- 差异是否大于自然波动？
- 是否分组看结果，而不是只看平均分？
如果两个系统差距只有 1 个百分点，而 judge 误差、样本方差或 runtime noise 有 3 个百分点，你不能声称前者显著更好。
置信度的意义不是把报告写得更学术，而是防止团队被小数点牵着走。LLM eval 的噪声来源很多：同一个 case 多跑一次可能不同，judge model 更新可能不同，线上工具延迟可能不同，样本构成也可能不同。看到“提升 1.2pp”时，第一反应不应是庆祝，而应是问：样本够吗？区间多宽？失败样本长什么样？这个差异是否大到足以改变决策？
指标选择决策表
RAG 指标也应尽量对应具体关系，而不是只写“RAG score”。如果采用第 2 章的 Q/C/A 分解，retrieval recall 和 context relevance 更接近 C|Q，faithfulness 更接近 A|C，answer relevance 更接近 A|Q；当回答里有许多主张时，还要看上下文是否足以支撑这些主张，也就是 C|ALiuRAG2025。
| 场景 | 首选指标 | 辅助指标 |
|---|---|---|
| 单轮问答 | exact / semantic pass rate | calibration、cost、latency |
| RAG | context relevance、faithfulness、answer relevance、retrieval recall | support coverage、answerability、citation quality、unsupported claims |
| Coding task | tests pass、FAIL_TO_PASS/PASS_TO_PASS | patch size、cost、time |
| Customer-service agent | state success、pass^k | policy violation、handoff rate |
| Web/browser agent | outcome success、side effects、trajectory issue | loop rate、click count |
| Judge 校准 | TPR/TNR、precision/recall | confusion matrix、FP/FN examples |
| 线上监控 | failure rate by category | drift、latency、cost, alert volume |
常见误区
误区 1：把 pass@k 当可靠性。
pass@k 是“至少一次成功”，不是“每次成功”。上线 agent 通常更关心 pass^k。
误区 2：只报告平均分。
平均分会掩盖高危失败、长尾用户、成本暴涨和特定场景崩溃。
误区 3：judge agreement 高就上线。
必须分开看 TPR/TNR 或 precision/recall，尤其在失败样本稀少时。
误区 4：忽略成本。
agent 可能通过大量 token、工具调用和重试换来高分；这不一定是好产品。
误区 5：没有置信区间。
小样本上的 2 个点提升可能只是噪声。
本章练习
- 对一个单次成功率 0.8 的 agent，计算 k=3、5、10 时的 pass^k。
- 设计一个 judge 校准表，包含 TP、FP、TN、FN，并写出 TPR/TNR。
- 为一个 customer-service agent 选择 5 个指标，其中至少 1 个可靠性指标、1 个成本指标、1 个安全指标。
- 找一个你见过的 leaderboard 分数，说明它没有报告哪些部署关键指标。
- 为一个长时程 agent 设计 RDC 或 MOP 的最小观测方法。
延伸阅读
- ChenCodex2021：pass@k 无偏估计。
- TauBench2024：pass^k 用于 agent 可靠性。
- KhanalReliability2026：长时程 agent 可靠性框架。
- WolfeStats2025：LLM eval 的统计解释。