成功率指标与 Pass@k

为什么单次成功率不足以判断系统是否可用？

• 例: 五条任务通过四条（0.8）本身无法判断可用性;
• 场景依赖: 若对应退款客服，意味着每五名用户中就有一人未拿到应得退款；若对应挖掘漏洞的安全 Agent，五次中命中四次已相当可观;
• 判据: 差别在业务场景对成功率有多高的要求，而不在这个数字本身;

“技术奇观” 阶段为什么用 Pass@k？

• 定义 Pass@k: 同一任务上运行 $k$ 次，只要至少有一次通过，任务就算通过;
• 定义 Best@k: 若输出是连续得分，则取最好的 $k$ 次结果;
• 含义: “奇观” 指在大量尝试、充足时间和人工筛选下展示出的能力上限——只要其中一次成功，就足以证明 “这件事原则上做得到”;
• 典型场景: 自主工作一周从头写出 C 编译器、持续探索直到找到重要数学猜想的反例、反复审查开源软件发现存在几十年的重大安全漏洞;
• 结算方式: 人类从 $k$ 条候选轨迹中挑出那一条最好的;
• 产品意义: Manus 的虚拟电脑、OpenClaw 的 “活人感”，早期成功率不高、token 成本非常高，但使用最强模型时复杂任务往往有较高的 Pass@k，技术奇观在社交网络上被大量分享;

业务可靠性为什么要看 Pass^k？

• 定义 Pass^k（Pass consecutive k）: 同一任务连续运行 $k$ 次，要求每一次都通过;
• 附加条件: 不能触发安全、合规或幻觉等一票否决项;
• 回答的问题: “Agent 能否稳定可靠地交付”，而不是 “能否偶尔创造奇迹”;
• 适用场景: 支付、退款、权限变更、生产部署等;
• 口径澄清: 必须写清 $k$ 次尝试是同一任务的 $k$ 次独立采样，还是生产流水线上连续 $k$ 个任务;
• 副作用约束: 会产生副作用的操作不能简单地 “重试直到成功”，而应在沙盒或可回滚环境中采样，并把每一次失败都记入可靠性指标;

两个指标之间的数学关系是什么？

• 假设: 每次运行相互独立、单次成功率为 $p$;
• 公式: $\mathrm{Pass@k}=1-(1-p)^k$，$\mathrm{Pass}^{k}=p^k$;
• 例（$p=0.6$、$k=5$）: Pass@5 $=1-0.4^5\approx99.0\%$，看起来几乎总能 “至少成功一次”；Pass^5 $=0.6^5\approx7.8\%$，说明连续五次都不出错仍然很难;
• 解读: 前一个数字适合衡量探索时的能力天花板，后一个数字才接近支付、退款、生产部署等场景的可靠性要求;

各指标的选用口径是什么？

• Pass@1: $k=1$ 的 Pass@k，即单次平均成功率;
• 日常场景: 看最常用的 Pass@1;
• 关键操作场景: 优先 Pass^k，盯的是 “每次都别出错” 的稳定性;
• 探索性任务: 优先 Pass@k 或 Best@k，看的是给足机会后的能力上限;
• 选型应用: 见 评估驱动的模型选型;