eval-metrics

name	eval-metrics
description	当你要定义"什么算成功"、选择评估指标口径（能力上限 vs 业务可靠性）、建立过程指标和安全鲁棒性指标时使用；当需要区分"技术奇观"与"稳定可靠"时使用。不适用于评估数据集设计（见 eval-dataset）或评分方法（见 eval-llm-judge）。

评估指标体系（Evaluation Metrics）

角色与读者

面向 Agent 开发者与决策者。本 Skill 服务的目标：在搭环境、写数据集之前先明确"成功"究竟意味着什么。核心认识：指标口径不同，评估结论和工程决策可能完全相反。

核心原则（配正例/反例）

1. Pass@k（能力上限）vs Pass^k（业务可靠性），两个指标可能给出相反结论

   • Pass@k = 跑 k 次至少成功一次（Best@k 取最好得分），适合科研发现、漏洞挖掘、开放式创作。
   • Pass^k = 连续 k 次每次都成功且不触发一票否决项，适合支付、退款、权限变更、生产部署。
   • 数学关系：Pass@k = 1−(1−p)^k，Pass^k = p^k。例 p=0.6、k=5：Pass@5≈99%（看似"几乎总能成功一次"），Pass consecutive@5≈7.8%（连续五次不出错仍难）。
   • 报告必须写清 k 次口径（独立采样 vs 连续 k 个任务）；有副作用操作在沙盒/可回滚环境采样，每次失败都记入可靠性指标。

2. 过程指标：从黑盒到白盒（不只最终结果）

   • 行动合法率（有效且合法操作比例）、工具调用正确率（参数语义合理）、路径效率（步数/冗余动作/回退次数，需人类专家基线）、检索覆盖率（是否充分探索信息空间）、成本与延迟（区分输入/输出/缓存 token）。

3. 安全与合规：零容忍 + 一票否决

   • 敏感操作（删数据/改权限/对外通信）、数据外泄（日志打印密码/私密文档发外部 API）、违规内容——一次严重违规即否决整体评价，不因其他维度优秀而豁免。

4. 轨迹（trajectory）与结果（outcome）双重覆盖

   • Agent"说订票完成"是轨迹层面，数据库真生成订单才是结果层面。只看轨迹漏"说了没做到"；只看结果看不出中间走歪。两类都测。
   • 例：机票 Agent 发现政策漏洞找到更便宜方案——按预设路径打分判失败，按最终结果用户拿到更好方案。

5. 鲁棒性与人工抽检

   • 鲁棒性：随机种子敏感性、页面变化适应性、API 抖动容忍度、长时记忆干扰。
   • 人工抽检 + 评判者校准：先用人工金标集测评判模型与人类一致率（Cohen's kappa>0.7）才放量使用。

执行流程（SOP 检查清单）

1. 明确任务类型：探索性（Pass@k）还是关键操作（Pass^k）。
2. 建立过程指标（合法率、正确率、效率、覆盖率、成本）。
3. 设安全/合规零容忍项（一票否决）。
4. 轨迹与结果双重覆盖设计。
5. 建人工金标集校准评判模型（kappa 阈值）。

禁止清单（写清合法例外）

• 禁止用 Pass@k 衡量关键操作可靠性（99% 的"至少成功一次"掩盖 7.8% 的"连续五次不出错"）。例外：探索性任务用 Pass@k，关键操作用 Pass^k。
• 禁止只看最终结果不看过程。例外：结果可自动验证的简单任务可只验结果，但仍需过程指标防 reward hacking。
• 禁止把幻觉当分级评分维度（与质量正交，应一票否决）。例外：流畅详尽但含虚假信息的回答伤害远大于简短准确。
• 禁止有副作用的操作"重试直到成功"。例外：沙盒/可回滚环境采样，每次失败记入可靠性指标。
• 禁止不加校准直接用 LLM 评判分数。例外：金标集上 kappa 达标后才大规模使用。

参考资料

• 本书第 7.2 节《评估指标体系》（Pass@k/Pass^k、过程指标、安全鲁棒性轨迹覆盖、人工抽检对抗式评审）。
• 笔记 07-Agent的评估.md 第 7.1-7.2 节。