25 · 评估指标体系：Pass@k、Pass^k 与基准设计
「AI-Agent 面试深度指南」· 模块七 · 评估与优化 · 第 25 篇 / 共 32 篇
引言
"我们的 Agent 成功率 85%。"------这句话在面试里毫无信息量，除非你接着问三个问题：是哪个口径？几步任务？评测集从哪来的？
如果它是"10 步任务的单步成功率 85%"，那端到端成功率只有 0.85¹⁰ ≈ 20%；如果评测集是模型自己生成的，那这个数字可能完全没有意义。
评估是 Agent 工程中最容易被跳过、也最决定长期成败的一环。本文讲清成功率的四种口径、主流基准的设计思路，以及如何构建能支撑决策的自建评测集。
一、成功率的四种口径
1.1 pass@k：能力上限
定义 ：k 次独立尝试中至少有一次成功的概率。
含义：衡量"模型能不能做到"------能力上限。常用于代码生成（HumanEval 的 pass@1/10/100）与探索性任务。
无偏估计：不能简单用"跑了 k 次成了几次"。正确做法是采样 n 次（n ≥ k），用组合公式：
pass@k = 1 - C(n-c, k) / C(n, k)其中 n 是总采样数，c 是成功数。直接用 c/k 会系统性低估。
1.2 pass^k：可靠性
定义 ：k 次尝试全部成功的概率。
含义：衡量"用户每次用都能成吗"------可靠性。若单次成功率 90%，一个 5 步连续正确的任务 pass⁵ ≈ 59%，20 步只剩 12%。
这是生产环境真正该看的指标：用户只给你一次机会。
1.3 best@k：可验证前提下的最优表现
k 次尝试里挑最好的一次（通常有验证器或评委参与）。介于两者之间，衡量"在能验证的前提下，系统能达到的最好结果"。
1.4 为什么这个区别至关重要
做技术演示、探索能力边界 → 看 pass@k（可以多试几次）；
上生产、做客服/审批/运维 → 必须看 pass^k（用户只给一次机会）。
多步任务的幂律衰减是最重要的推论：整体成功率 ≈ 单步成功率^步数。这带来三条工程指导：
- 压缩路径：减少不必要的步骤（能用代码固化的就别让模型决策）；
- 提高单步可靠性：工具描述、参数校验、重试；
- 关键步骤加验证：验证通过才算这一步成功（Sidecar 模式）。
1.5 配套指标（只看成功率会掩盖问题）
- 平均轮数 / P90 轮数：反映效率与成本；
- 单任务成本与 P95 延迟：反映可用性；
- 工具错误率、重复调用率：反映接口质量；
- 人工介入率：反映业务可用性的真实底线。
二、评估环境与基准设计
2.1 评估环境的五个要素
- 任务定义：目标 + 初始状态；
- 可用工具集：能力边界；
- 验证器：如何判定成功（这是最核心也最难的）；
- 可控性：能否重置、是否确定性；
- 观测记录：轨迹是否完整保存（用于归因）。
2.2 两类环境
工具调用型：主要考察"调得对不对"，环境相对静态（给定 API，验证返回结果）。
人机交互型：需要与模拟用户多轮对话，考察澄清、追问、情绪处理与规则遵循。验证更复杂------不仅要看最终状态，还要看过程是否合规。
2.3 三个主流基准
BFCL（Berkeley Function Calling Leaderboard）：工具/函数调用能力。类别包括 simple（单调用）、multiple（多候选选一个）、parallel（并行调用）、irrelevance（不该调用时能否拒绝）。
评估用 AST 匹配 ：把调用解析成抽象语法树比对，能忽略参数顺序、识别等价表达式（1e3 = 1000），比字符串匹配智能得多。
GAIA：通用 AI 助手能力，466 个真实世界问题、三个难度级别，考察多步推理、工具使用、文件与多模态处理。特点是"对人简单、对 AI 难"。
τ²-bench 类：面向人机交互 + 工具调用的领域任务（如电信客服），要求 Agent 在与模拟用户对话的同时遵守领域规则并正确调用工具。
2.4 公开基准的正确用法
榜单看趋势，自建集做决策。 公开基准的问题是：会被针对性优化甚至污染，且分布与你的业务不同。
正确做法是三层：
- 通用基准：定期跑，看相对位置变化（换模型、大版本时）；
- 自建业务集：决定能否上线（这才是决策依据）；
- 生产回流：保持新鲜度（用户真实问题）。
三、自建评测集：怎么建才有用
3.1 三个来源
生产轨迹回流（最有价值）：真实用户问题 + 人工标注成功标准。它的分布最贴近实际，且能发现你想不到的边界情况。
人工构造边界：针对已知风险构造------缺失信息、歧义表述、诱导注入、超长输入、权限边界。
模型生成 + 人工校验 ：用强模型批量生成题目，人工抽检与修正。注意：不能直接用模型生成的答案当标准答案，必须人工或确定性验证器确认。
3.2 设计要点
难度分层：按步数、歧义程度、工具数量、是否需澄清、是否有干扰信息分档。这样你能看出"系统在哪个难度开始崩"。
验证器可自动化：每个任务都要能被程序判定（数据库终态、文件是否生成、API 返回匹配）。无法自动判定的任务要设计 Rubric（第 26 篇）。
防数据泄漏：评估集不能进训练数据，也不能被写进系统提示；定期轮换；监控"未见过变体"上的表现。
长期维护：标准会变（业务规则更新），需要版本化与定期重标；淘汰被"做烂"的题目；补充新发现的失败模式。
3.3 一个实用起步方案
不要一上来就建 1000 条。建议：
- 先收集 50 条真实高频问题（含标准答案或判定规则）；
- 加 30 条已知难例（曾经失败过的）；
- 加 20 条安全/边界用例（注入、越权、应拒答）；
- 每周从生产失败案例中补充 5--10 条。
100 条精标数据，比 1000 条自动生成的更有决策价值。
3.4 一个反模式
用模型生成评测集又用同一个模型评判------这是自我循环，可能完全无意义。至少要人工抽检 10%，并用确定性验证器覆盖可判定的部分。
四、从分数到决策
4.1 分数没有意义，除非能归因
"成功率下降 3%"本身不可执行。可执行的是"工具参数错误占比从 5% 升到 12%"。因此评估系统必须输出失败模式分布，而不只是一个数字。
4.2 统计显著性
A/B 结果必须看置信区间。二分类指标（成功/失败）用两比例检验或 bootstrap 估计差值区间；样本量不足时，"提升 5%"可能只是噪声。
经验做法：先估算所需样本量，跑够再下结论；同时看效应量（提升是否值得这点成本）。
4.3 评估驱动迭代的闭环
评测集 → 跑分 + 失败归因 → 形成假设 → 最小改动 → 重跑（边界集 + 保留集）→ 灰度 → 生产监控 → 新失败案例回流关键在最后一步：生产中的每一次失败都应该变成评测集里的一条用例。没有这个回流，评测集会逐渐失效。
五、面试考点与答题框架
5.1 高频真题
Q1：pass@k 和 pass^k 的区别，生产该看哪个？
答：pass@k 是"至少成功一次"（能力上限），pass^k 是"次次成功"（可靠性）。生产必须看 pass^k，因为用户只给一次机会。推论：多步任务的成功率是单步的幂次，因此减少步数比提高单步准确率更划算。
Q2：你们的评测集怎么来的？
答：三来源------生产轨迹回流（主力，分布真实）、人工构造边界（覆盖风险）、模型生成 + 人工校验（扩量）。关键是标准答案必须可自动判定或经人工确认，且持续从失败案例中补充。
Q3：公开榜单刷分有意义吗？
答：看趋势有意义，做决策没意义。榜单分布与业务不同且可能被污染；真正决定上线的是自建业务集。做法是"榜单体检 + 自建集决策 + 生产回流保鲜"。
5.2 加分点
- 能指出 pass@k 无偏估计要用组合公式；
- 能说出"多步成功率幂律衰减"及其工程推论（压缩路径）；
- 能说明"用模型生成又用模型评判"是反模式。
小结
评估的第一课是先定义成功 ：口径（pass@k 还是 pass^k）、来源（评测集怎么来的）、判定（验证器怎么写）。第二课是分数必须能归因 ------评估的产出不是数字，而是"下一步改什么"的可执行假设。记住那条闭环：生产失败 → 进入评测集 → 改进 → 回归验证 → 再上线。