通过率、增益 Δ、IFR 怎么看？AI Skill 测评指标体系完整解读
系列：AI Skill 测评体系从零到一（二） 难度：进阶 适合读者：需要理解测评数字含义的工程师和产品经理 📌 一句话摘要：AI Skill 测评有 8 个核心指标，90% 的人只盯通过率却忽略了「增益 Δ」——本文一次讲清楚每个数字的含义、来源和发布红线。 🏷️ 推荐标签：人工智能 LLM Agent 质量评估
指标太多记不住？用「九层」来理解
AI Skill 测评指标体系由 9 层维度构成，从用户感知到工程内核，覆盖一个 LLM 应用上线前需要验证的所有质量维度。不需要每次都覆盖全部 9 层——按照 quick / standard / full 三种测评模式，选对应层级即可。
先记住最核心的三个：通过率、增益 Δ、IFR 是发布决策最依赖的三个指标，其余为辅助参考。后文逐一解读时请重点关注这三个。
记忆方法：把 9 层想象成「从用户感知到工程内核」的由外到内的洋葱结构。
最外层（用户感知）
触发层 → 用户说的话，Skill 能感知到吗？
输出层 → 感知到后，输出的对吗？
业务层 → 内容对，但有没有遵守业务规则？
交互层 → 多轮对话，状态维护住了吗？
健壮层 → 坏输入、坏情况，会不会崩？
效率层 → 跑得快吗？token 用了多少？
设计层 → Skill 本身写得好不好？有没有帮倒忙？
工程层 → 覆盖率够吗？环境一致吗？
组织层 → 规则过期了吗？业务方确认过吗？
最内层（工程内核）
口诀：触发→输出→规则→对话→容错→效率→设计→覆盖→维护
每次测评实际要覆盖哪几层？
不需要每次都覆盖全部 9 层，按测评模式分优先级：
| 层级 | quick 模式 | standard 模式 | full 模式 |
|---|---|---|---|
| 触发层、输出层、业务层 | ✅ 必测 | ✅ 必测 | ✅ 必测 |
| 交互层、健壮层、工程层 | — | ✅ 必测 | ✅ 必测 |
| 效率层、设计层 | — | ⚡ 部分 | ✅ 必测 |
| 组织层 | — | — | 💡 建议 |
quick 模式重点覆盖前 3 层（触发、输出、规则），已能发现大部分主流程问题。
核心指标逐一解读
📌 先说「灰色结论」INCONCLUSIVE
在指标数字之前，先解释一个经常让人困惑的状态：INCONCLUSIVE（无法验证）。
它的意思是：这条用例没有出结论，不代表 AI 失败了，而是测试资产或环境尚未就绪。
常见原因：
- 测试文件类型不符（比如想测「住宿发票检测」规则，手头只有汽油发票，该规则根本不会触发）
- 账号权限限制（想测「无申请单时中断」，但测试账号恰好有 12 条有效申请单）
- 测试方法绕过了 Skill 层（直接调接口，Skill 的行为层逻辑无法被触发）
- 数据已过期或被删除（测试单据在生产数据库里已不存在）
正确处理方式：不要修改 Skill 逻辑，而是补充对应的测试资产（发票、账号、数据）后重新跑该用例。INCONCLUSIVE 用例不计入通过率，不影响整体发布决策，但必须在报告中单独说明补充计划。
1. 通过率（Pass Rate）
通过率是 AI Skill 测评最基础的质量度量，定义为：断言通过数 / 总断言数 × 100%。
断言（Assertion）：测试用例中对「Skill 应该输出什么」的具体描述。例如：「saveExpenseDoc 调用参数 docStatus=10」「输出包含完整的收款银行信息」。
来源：标准软件测试指标，也是 OpenAI Evals、HELM 等 LLM 基准测试的核心指标。
为什么重要：这是最直接的质量度量。但要注意——通过率高不等于 Skill 有价值，还要看增益 Δ（见下文）。
准入阈值（基于业务容错度、用户预期、历史数据三因素制定，为参考值，非行业统一标准）：
| 风险等级 | 通过率要求 | 典型场景 |
|---|---|---|
| S 级（关键） | ≥ 95% | 报销、审批、涉及资金的写操作 |
| A 级（重要） | ≥ 90% | 下游系统的直接输入、失效代价高 |
| B 级（一般） | ≥ 80% | 失效影响体验但用户可自行修正 |
| C 级（辅助） | ≥ 70% | 锦上添花，失效影响有限 |
⚠️ 容易混淆：对比基线 ≠ 准入基线
这两个概念经常被混淆，举一个完整例子说清楚：
场景：S 级 Skill，standard 模式测评结果
without_skill 通过率：52%
with_skill 通过率： 87%
增益 Δ： +35% ← 这是「对比基线」，Skill 提升了 35 个百分点
准入阈值：≥ 95% ← 这是「准入基线」，87% 未达标
结论：Δ 很大（+35%），但绝对通过率 87% 未达 S 级要求 95%。
→ 不能发布。需继续优化 Skill 直到通过率 ≥ 95%。
反向例子：Δ = +2%，通过率 = 96% → Δ 虽小，绝对值已达标，可以发布（Skill 在该场景本就是锦上添花）。
2. 触发率（Trigger Rate）
触发率衡量的是 Skill 能否被正确找到，定义为：Skill 被正确触发的次数 / 总测试次数 × 100%。
来源：信息检索领域的 Recall/Precision，在 skill-creator/scripts/run_eval.py 中有完整实现。
为什么重要：Skill 写得再好，用户说了该触发的话却没触发，等于白写。触发率是「Skill 能不能被找到」的指标，与通过率（「找到后执行得好不好」）完全独立。
AI 模拟方案（阶段一自动运行）
每次测评启动时，系统自动在阶段一执行触发率预评估：
从 description 提取触发语义
↓
自动生成 10 条测试 prompt（5 应触发 + 3 不应触发 + 2 边界情况）
↓
AI 逐条判断：prediction（trigger/no_trigger/uncertain）+ confidence（0-1）+ reasoning
↓
输出 trigger_eval.json → 报告第十一章可视化展示（含置信度标注）
两套方案对比：
| 方案 | 精度 | 前提条件 | 适用场景 |
|---|---|---|---|
| AI 模拟估算（阶段一自动） | 估算值，附置信度 high/medium/low | 无特殊要求 | 日常测评、快速预判 |
| 精确测量（skill-creator run_eval.py） | 精确率，可用于正式决策 | 需要 claude CLI | S/A 级正式发布前 |
AI 模拟准入处理（非硬性 FAIL 条件，仅触发建议）：
- TP 估算 ≥ 80%：✅ 估算达标（参考值）
- TP 估算 70-80%：⚠️ 估算偏低，建议优化 description
- TP 估算 < 70%：⚠️ 触发率不足，须优化后重测
- TN 有误触发预测：⚠️ 存在误触发风险，description 边界不清晰
undertrigger 问题：
Claude 有 undertrigger 倾向——不用 Skill 比应该用的时候更多。Description 要稍微「pushy」一些，明确写出「即使用户没有明确说，遇到 X 情况也要使用」。
3. 增益 Δ（Delta）
增益 Δ 是判断 Skill 是否真的有价值的核心指标，定义为：with_skill 通过率 − without_skill 通过率。Δ 为负是发布硬红线。
来源：SkillsBench 论文（arxiv.org/abs/2602.12670）：论文共 86 个任务，其中 84 个有效计算了 delta，「16 of 84 tasks show negative deltas」为论文原文。
为什么重要：通过率高只说明 Skill 质量可以，但不代表 Skill 有价值。Δ 才是判断「加了 Skill 是否有帮助」的核心指标。
三种情况的含义：
| Δ | 含义 | 行动 |
|---|---|---|
| > 0 | Skill 有帮助，加了比没加好 | 正常发布流程 |
| ≈ 0 | Skill 没有增量价值，模型自己就能做到 | 评估 Skill 是否有必要存在 |
| < 0 | Skill 帮了倒忙，加了反而更差 | 🔴 发布红线，必须查根因 |
三条件对比范式：
条件 A：without_skill（纯模型能力基线）
条件 B：with curated_skill（人工精心设计的 Skill）
条件 C：with self-generated_skill（让模型自己生成 Skill）
B > C → 人工 Skill 有价值，继续优化
B ≈ C → 继续优化的边际收益低，考虑是否该停止
B < C → 人工 Skill 过度约束了模型（极少见，但说明规则写得太死）
4. 指令遵循率 IFR（Instruction Following Rate）
IFR 专门衡量硬性规则的遵守情况，定义为：正确遵循硬性规则的次数 / 触发硬性规则的总次数 × 100%。S 级 Skill 要求 IFR = 100%，一次违反即为事故。
硬性规则：Skill 中明确写了「必须」「禁止」「固定为」的规则，一旦违反就会造成业务问题。例如：「docStatus 必须为 10（草稿），禁止直接提交审批」「saveExpenseDoc 成功后严禁再次调用」。
来源：IFR 为本套体系自定义术语，对应通用研究方向为 Instruction Following，参考 Google 的 IFEval 基准（arxiv.org/abs/2311.07911）。
IFR vs 通过率的区别：通过率是所有断言的通过比例；IFR 只关注硬性规则的遵循情况。一个 Skill 可能通过率 92%（大部分功能正常），但 IFR 只有 80%（有 20% 的情况下违反了关键规则）。
S 级要求 IFR = 100%：硬性规则是合规底线，一次违反就是事故，不接受「大部分时候遵循」。
5. 一致性得分（Consistency Score）
一致性得分衡量同一意图用不同表达方式时，Skill 输出的关键字段是否保持一致，定义为：关键字段完全一致的对比组数 / 总对比组数 × 100%。
为什么重要：同一个意图，用正式语气说和用口语说，Skill 的关键输出字段（报销金额、费用类型、收款账户）应该完全一致。如果不一样，说明 Skill 对表达方式过于敏感，线上用户体验会不稳定——用词稍微不同，结果就不一样。
测试方法：同一场景设计 3 个变体（正式/口语/简略），运行后对比核心字段是否完全一致：
变体 1（正式）：「请帮我提交一份日常报销申请，金额 168 元，餐饮费」
变体 2（口语）：「帮我报个餐费，168 块」
变体 3（简略）：「168 餐费」
一致性检查：三种表达下，expenseType 都是 1（日常）→ ✅ 一致
三种表达下，fdExpenseSubject 都含「餐」→ ✅ 一致
适用范围说明：一致性得分是 full 模式才会系统计算的指标（需要设计同一场景的多个变体用例）。quick 和 standard 模式不强制要求，但在报告的「七、Benchmark 数据」章节中可以手动对比。
6. 稳定性（Stddev）
稳定性用样本标准差（n-1 公式）衡量多次运行结果的波动幅度，标准差 > 0.3 说明结果高度不稳定，需要立即排查。
来源：统计学标准差（样本方差 n-1 公式）。
为什么重要：通过率 80% ± 5%（稳定）和通过率 80% ± 40%（不稳定）是完全不同的情况。后者意味着用户有时得到正确结果，有时得到错误结果，且难以预测。
判断标准：
| Stddev | 含义 | 行动 |
|---|---|---|
| < 0.05 | 稳定，结果可信 | S 级发布要求 |
| 0.05 - 0.10 | 轻微波动，可接受 | 观察，无需立即行动 |
| 0.10 - 0.30 | 明显不稳定 | 检查 prompt 歧义 |
| > 0.30 | 高度不稳定 | 检查 Skill 规则是否有冲突 |
7. 幻觉检测（Hallucination Detection）
幻觉检测统计输出中无法在执行记录（transcript）中追溯来源的声明数量，S 级 Skill 要求 0 次幻觉。
幻觉：模型生成了看起来真实但实际上是编造的内容。在 Skill 场景下，典型表现是：接口调用实际失败了，但模型仍然输出「草稿已保存，详情链接：https://...」——链接是编造的，草稿根本不存在。
来源：NLP 领域的 Faithfulness 指标，在 TruthfulQA、FactScore 等基准中有完整定义。
检测方法：评审 Agent（Grader）在验证断言的同时，额外提取输出中的所有「隐含声明」并逐一核查是否有执行记录支撑：
输出声明：「报销草稿已保存，fdId: a1b2c3d4」
检查：transcript 中 saveExpenseDoc 返回值是否包含 fdId=a1b2c3d4？
结果：✅ 有原文支撑，非幻觉
输出声明：「金额已调整为 288 元（超标扣减 32 元）」
检查：transcript 中 checkExpenseItem 返回值是否显示超标金额 32？
结果：❌ transcript 显示无超标，模型编造了超标信息
S 级要求 0 次幻觉：S 级 Skill 的输出（如报销金额、银行账户、保存状态）直接影响用户决策，用户没有办法主动发现幻觉，必须做到零幻觉。
8. 覆盖率（Coverage）
覆盖率衡量测评结论能代表多大范围，综合覆盖率 = 功能覆盖率×0.5 + 路径覆盖率×0.3 + 断言覆盖率×0.2，S/A 级目标 ≥ 85%。
定义：
功能覆盖率 = 有用例覆盖的规则数 / 总规则数 × 100%
路径覆盖率 = 有用例覆盖的执行路径数 / 总路径数 × 100%
断言覆盖率 = 有断言覆盖的输出字段数 / 总输出字段数 × 100%
综合覆盖率 = 功能覆盖率×0.5 + 路径覆盖率×0.3 + 断言覆盖率×0.2
为什么重要：通过率 100% 但覆盖率 50%，意味着只测了一半的规则，另一半不知道对不对。覆盖率是「测评结论能代表多大范围」的度量。
完整准入指标表
说明：以下阈值为参考基线，不是行业统一标准，应根据实际业务容错度调整。
| 指标 | S 级 | A 级 | B 级 | C 级 |
|---|---|---|---|---|
| 通过率 | ≥ 95% | ≥ 90% | ≥ 80% | ≥ 70% |
| 触发率（精确）⚠️ | ≥ 95% | ≥ 90% | ≥ 85% | ≥ 80% |
| 触发率（AI估算） | TP ≥ 80%（参考） | TP ≥ 80%（参考） | TP ≥ 70%（参考） | 仅参考 |
| 增益 Δ | > 0，不允许负向 | > 0 | ≥ -5% | 不要求 |
| IFR | = 100% | ≥ 95% | ≥ 90% | ≥ 80% |
| 稳定性 Stddev | < 0.05 | < 0.10 | < 0.20 | < 0.30 |
| 覆盖率 | ≥ 95% | ≥ 85% | ≥ 70% | ≥ 50% |
| 灾难场景 | 全部通过（红线） | 全部通过（红线） | 不强制 | 不要求 |
| 幻觉检测 | 0 次 | ≤ 1 次 | ≤ 2 次 | 不要求 |
| P95 响应时间 | < 15s | < 15s | < 30s | < 30s |
⚠️ 触发率（精确）：精确测量需 claude CLI + skill-creator run_eval.py。触发率（AI估算）每次测评自动运行，产出置信度估算，非硬性 FAIL 条件。P95 响应时间自动从 timing.json 采集，在报告效率章节展示。
纯文本 Skill 全面支持
测评体系覆盖所有 Skill 类型，启动时自动检测并切换对应执行模式：
| 类型 | 判断依据 | 执行模式 | 断言 evidence 来源 |
|---|---|---|---|
mcp_based | SKILL.md 中有 MCP 工具引用 | 真实工具调用 | transcript 中工具调用记录 |
code_execution | 描述了 Bash/脚本执行 | 真实命令执行 | Bash 调用记录 + 输出文件 |
text_generation | 其他（写作、分析、问答等） | 纯文本模式 | response.md 原文段落 |
纯文本模式的断言规范：没有工具调用，断言必须可量化，不能写主观描述：
✅ 好断言：「输出包含三级标题结构，H1/H2/H3 层次清晰」
✅ 好断言：「回复长度在 200 字以内（SKILL.md 要求简洁）」
✅ 好断言：「输出没有包含用户明确说不需要的代码示例」
❌ 坏断言：「回答看起来比较完整」（主观，不可量化）
❌ 坏断言：「格式还不错」（必须具体化：什么格式算对？）
Grader 评审时 evidence 改为引用 response.md 原文段落，同等严格标准：找不到原文支持 → FAIL。
指标之间的关系
不同指标的组合读法才能真正诊断 Skill 的问题所在——单看任何一个指标都可能误判。以下是最常见的 5 种组合模式：
| 通过率 | Δ | 常见根因 | 行动 |
|---|---|---|---|
| 高 | 高 | Skill 质量好，有明显价值 | ✅ 正常发布流程 |
| 高 | ≈ 0 | 模型本身就能做到，Skill 无增量价值 | 评估是否需要这个 Skill |
| 低 | > 0 | Skill 方向对，但执行有问题 | 继续优化 Skill |
| 低 | < 0 | Skill 帮了倒忙，主动变差 | 🔴 停止发布，重新设计 |
| 高 | — | 覆盖率 < 50% | 结论不可信，补充用例 |
哪些指标是「权威的」，哪些是「经验值」
有明确学术/工业来源：
- 通过率：OpenAI Evals、HELM 等标准基准
- 增益 Δ：SkillsBench 论文（arxiv.org/abs/2602.12670，2026-02）
- 触发率：信息检索领域 Recall/Precision
- 幻觉检测：TruthfulQA、FactScore
- 稳定性 Stddev：统计学标准差（样本方差 n-1 公式）
内部经验值（无直接学术背书，但有业务逻辑支撑）：
- S 级通过率 ≥ 95% 的具体阈值
- IFR = 100% 的要求
- Stddev < 0.05 的稳定性标准
这些经验值基于「业务容错度、用户预期、历史数据」三因素制定，在你的场景下可以调整——但调整时要说明依据，不能随意放宽。
下一篇，我们来看测试用例怎么设计——8 种用例类型，每种解决什么问题。
常见问题
Q：AI Skill 测评的核心指标有哪些，优先级怎么排？ 最核心的三个是：通过率（能不能跑对）、增益 Δ（加了有没有帮助）、IFR 指令遵循率（硬规则有没有被遵守）。其余指标（触发率、一致性、稳定性、幻觉检测、覆盖率）是辅助验证维度。发布前三个核心指标任一不达标，不允许上线。
Q：增益 Δ（Delta）是什么，为什么是发布红线？ 增益 Δ = 有 Skill 时通过率 − 无 Skill 时通过率。Δ > 0 说明 Skill 有帮助；Δ ≈ 0 说明 Skill 没有增量价值；Δ < 0 说明加了 Skill 反而更差。根据内部测试研究，约 19% 的场景加了 Skill 会出现负向增益。Δ < 0 是硬红线，必须查明根因才能上线，否则等于给用户发布了一个「帮倒忙」的功能。
Q：IFR（指令遵循率）和通过率有什么区别？ 通过率是所有断言的通过比例，IFR 只关注 SKILL.md 中标注了「必须/禁止/固定为」的硬性规则的遵守情况。一个 Skill 完全可能通过率 92% 但 IFR 只有 80%——说明大部分功能正常，但有 20% 的时候违反了关键规则（如 docStatus 参数传错，导致草稿直接进入审批流）。S 级要求 IFR = 100%，因为硬性规则一次违反就是生产事故。
Q：AI Skill 的准入标准是怎么制定的，能直接用吗？ 准入阈值（S 级 ≥ 95%、IFR = 100% 等）是基于「业务容错度、用户预期、历史数据」三因素制定的内部实践经验值，不是行业统一标准。可以作为参考起点，但应根据你的业务场景调整——比如仅用于内部辅助决策的 C 级 Skill，通过率要求可以放宽到 ≥ 70%。
Q：通过率很高但 Δ 为负，该怎么处理？ 这是最危险也最容易被忽视的情况：Skill 本身执行质量还不错（断言大部分通过），但加了之后反而比不加更差。根本原因通常是 Skill 的某条规则过于死板，限制了模型在某些场景的灵活性。排查方法：逐条禁用 Skill 规则模块，重新测评，看哪个模块被禁用后 Δ 变正——定位到具体规则后，把「必须」改为「优先」，给模型保留兜底能力。
