Skill评测要回答“有没有用、有没有副作用、会不会退化”三个问题，只跑成功率为什么不够？

技能增强评测 · 三维主线 · 工程可落地

一、问题的提出：成功率作为评测原语的失效边界

在机器学习系统评测的传统范式中，准确率、F1、成功率这类“任务内单点指标”之所以长期有效，是因为模型输出与任务目标之间存在近似一一对应的映射：分类器输出标签，标签对错即成败。但 Skill 的引入改变了这一前提。Skill 不是模型参数的一部分，而是叠加在模型之上的外部能力层，它可能改变模型的输入分布（检索结果注入上下文）、改变输出约束（工具调用格式）、改变推理路径（子流程编排），甚至改变系统的失败模式（从“答错”变成“调用失败后静默降级”）。在这种结构下，成功率只捕捉了任务终点的二元结果，丢失了过程信息与代价信息。

更具体地说，只跑成功率会遭遇三类系统性偏差。第一类是归因偏差：成功率提升可能来自提示词微调、模型版本升级、评测集难度变化，而非 Skill 本身；若不设置严格的对照与消融，收益无法归因。第二类是代价盲区：Skill 往往以延迟、token 消耗、工具调用费用、上下文占用为代价，成功率不降反升的系统可能在成本维度已经不可接受。第三类是时间盲区：单次评测是横截面快照，而 Skill 依赖的外部资源（检索库、API、工具版本、用户查询分布）会随时间变化，横截面指标无法揭示退化趋势。

本文评述：成功率并非“错误指标”，而是“不充分指标”。它的失效不在于数值本身，而在于它被当作唯一验收口径时，评测系统失去了对收益来源、代价结构与时间稳定性的分辨能力。工程上更合理的做法是把成功率降格为三维指标族中的一个成员，而非评测的全部。

这一判断在近年来的评测研究中不断被印证。HELM（Holistic Evaluation of Language Models，Liang 等，2022）早已指出单一指标会掩盖模型在不同场景下的权衡；BIG-bench（Srivastava 等，2022）在构建大规模任务集时也强调多维度报告的必要性。本文认为，Skill 评测的特殊性在于它天然是“系统级”而非“模型级”的改动，因此更需要系统级的评测视角。关于评测方法论的通用讨论，可参考 Stanford CRFM HELM 项目 的公开报告。

二、背景与概念定义：什么是 Skill，评测到底在测什么

2.1 Skill 的操作性定义

本文把 Skill 定义为：在不重新训练基础模型的前提下，通过外部组件或轻量适配，使系统在特定任务族上获得可复用能力增强的最小功能单元。按实现形态可分为四类：提示层 Skill（系统提示、少样本示例、思维模板）、检索层 Skill（RAG 管线、知识库路由）、工具层 Skill（函数调用、API 编排、代码解释器）、参数层 Skill（LoRA 等轻量微调适配器）。这一分类与 Toolformer（Schick 等，2023）对工具学习、RETRO（Borgeaud 等，2022）对检索增强的讨论在精神上一致，但本文的分类标准是“改动发生在系统栈的哪一层”，更贴近工程验收的需要。

之所以要给出操作性定义，是因为“Skill 有没有用”这个问题在没有界定“Skill 边界”时是无法回答的。若把整个系统（模型+检索+工具+提示）都算作 Skill，那么任何指标变化都无法归因；若把 Skill 界定得过窄（例如只算一段提示），又会遗漏组件间的交互效应。本文建议在评测文档中显式记录 Skill 的作用层、依赖项、可关闭开关三要素，这是后续消融实验的前提。

2.2 评测对象的三个层次

Skill 评测实际上同时涉及三个层次的对象：能力层（任务完成质量）、系统层（延迟、成本、稳定性）、行为层（是否产生有害输出、是否过度依赖工具、是否出现格式违规）。成功率只覆盖能力层的一个切面。笔者在工程实践中观察到，许多 Skill 上线后的真实问题恰恰出在系统层与行为层：例如检索 Skill 使答案更准确，但平均延迟从 1.2 秒升至 3.8 秒；工具调用 Skill 提升了任务完成率，却在参数缺失时产生静默失败而非显式报错。这类问题在成功率报表上是不可见的。

表 1：Skill 评测的三个层次与成功率的覆盖关系（本文整理）

三、维度一：有没有用——效用度量与归因

3.1 效用不等于成功率：从二元到分布

“有没有用”的第一层含义是收益是否存在，第二层含义是收益有多大、在什么条件下出现。成功率把连续的质量分布压成二元，丢失了“接近成功”与“彻底失败”的区别。更细的效用度量应至少包含：任务级得分（如评分 rubric 的加权分）、部分正确率（多步任务中完成的子步骤比例）、置信度校准（模型自报置信度与实际正确率的一致性）。校准度量可借鉴 ECE（Expected Calibration Error，Guo 等，2017）的思路，本文评述：ECE 原本用于分类模型，迁移到生成式 Skill 时需要重新定义“置信度”的提取方式，工程上可用多次采样的一致率作为代理。

此外，效用应区分绝对效用与增量效用。绝对效用是开启 Skill 后的系统表现，增量效用是开启与关闭 Skill 的配对差值。工程验收真正关心的是增量效用，因为它回答了“这个 Skill 值不值得留”。配对设计（paired design）是估计增量效用的标准手段：同一批输入分别跑 Skill-on 与 Skill-off，得到配对样本，再用配对检验比较。

3.2 归因：收益到底来自哪里

归因是效用评测中最容易被忽视、也最容易出错的部分。一个常见的反例是：团队上线检索 Skill 后成功率提升 8 个百分点，但复盘发现同期基础模型也做了版本升级。若不控制变量，这 8 个百分点会被错误地记在 Skill 头上。本文建议采用三层消融：第一层关闭 Skill 全部组件（基线）；第二层只开启 Skill 的某一组件（单因素）；第三层开启全部组件（完整）。三层结果结合方差分析（ANOVA）或 Shapley 值分解，可以估计各组件的主效应与交互效应。Shapley 值在特征归因中的经典讨论见 Lundberg 与 Lee（2017）的 SHAP 工作，本文评述：将其迁移到 Skill 组件归因时，需注意组件数量通常很小（3–6 个），精确计算可行，不必依赖采样近似。

# 配对增量效用的最小实验骨架（伪代码）
for sample in eval_set:
    y_off = run(system, sample, skill=OFF)
    y_on  = run(system, sample, skill=ON)
    record(sample.id, y_off, y_on)

delta = mean(y_on - y_off)
ci    = bootstrap_ci(delta, n=2000, alpha=0.05)
# 报告：delta 的点估计 + 95% 置信区间 + 配对样本量

需要强调的是，配对实验的样本量必须足以支撑置信区间。若评测集只有 50 条，8 个百分点的提升在统计上很可能不显著。关于样本量与效应量的通用讨论，可参考 统计显著性在 NLP 评测中的实践讨论。

四、维度二：有没有副作用——代价、风险与干扰

4.1 副作用的三类来源

副作用指 Skill 引入后系统在其他维度上产生的非预期变化。本文将其归纳为三类。第一类是资源副作用：延迟上升、token 消耗增加、外部 API 调用费用、上下文窗口占用导致长文档截断。第二类是行为副作用：模型过度依赖工具、在工具不可用时产生幻觉性补全、输出格式违规率上升、拒答率异常变化。第三类是分布副作用：Skill 在目标任务族上有效，但在相邻任务族上造成性能下降（负迁移）。负迁移在持续学习与多任务学习中早有讨论，本文评述：Skill 场景下的负迁移往往不是参数层面的，而是提示与上下文层面的——检索注入的文档可能挤占原本用于推理的上下文预算。

资源副作用的度量相对直接：在评测流水线中同时采集 P50/P95 延迟、输入输出 token 数、工具调用次数与失败率。行为副作用则需要专门的行为测试集，例如构造“工具返回空结果”“工具超时”“工具返回格式错误”的对抗样本，观察系统的降级行为是否可接受。这类测试与 HELM 中的鲁棒性评测、以及对抗测试（adversarial testing）的思路一致。

4.2 副作用与效用的权衡曲线

副作用评测的目的不是“消灭副作用”，而是刻画效用—代价权衡曲线。以检索 Skill 为例，增大检索文档数量通常提升答案质量，但同时增加延迟与 token 成本。工程上应扫描若干配置点（如 top-k = 1/3/5/10），在二维平面上画出“质量—成本”曲线，再结合业务约束选择工作点。这一做法与推理系统中“质量—延迟”帕累托前沿的分析同构。本文认为，把权衡曲线作为验收材料，比单一成功率数字更能支撑上线决策。

表 2：副作用分类与验收阈值示例（阈值为工程经验值，非普适标准，需按业务调整）

五、维度三：会不会退化——时间稳定性与分布漂移

5.1 退化的两种机制

“会不会退化”问的是 Skill 的有效性是否随时间保持。退化有两种机制。第一种是外部依赖漂移：检索库更新导致文档过期、工具 API 版本变更导致参数不兼容、知识库中的事实发生变化。第二种是输入分布漂移：用户查询分布随季节、产品迭代、热点事件变化，原本覆盖良好的 Skill 在新分布上失效。这两种机制在概念漂移（concept drift）研究中都有对应，本文评述：Skill 场景的特殊性在于漂移源往往在模型外部，因此监控对象应是外部依赖而非模型参数。

退化的隐蔽性在于它通常不是断崖式的，而是缓慢的、局部的。一个检索 Skill 可能在三个月内平均成功率只下降 2 个百分点，但在某个高频子任务上下降 15 个百分点。若评测只做上线前的一次性验收，这种退化不会被发现。工程上应建立周期性回归评测：固定评测集按周或按月重跑，记录指标时间序列，并设置告警阈值。

5.2 稳定性指标与漂移检测

稳定性可用三类指标刻画：时间方差（同一评测集多次重跑的指标波动，反映系统随机性）、跨期斜率（指标随时间的趋势，反映退化速度）、子群离散度（不同任务族指标的方差，反映退化是否局部集中）。漂移检测可借鉴 PSI（Population Stability Index）与 KS 检验：对输入特征或检索命中分布做分布对比，当 PSI 超过阈值时触发人工复核。这类方法在风控与推荐系统的模型监控中已较成熟，迁移到 Skill 监控时需注意文本特征的分布度量方式（可用嵌入向量的均值/协方差距离作为代理）。

笔者认为，退化评测最容易被低估的成本是“评测集自身的过期”。固定评测集在长期使用后会被模型间接“适应”，其区分度下降。因此周期性回归不仅要重跑，还要定期补充新样本、淘汰饱和样本，这与持续基准（continual benchmark）的设计理念一致。

六、统一评测框架：指标体系、实验设计与统计检验

6.1 三维指标族

把前三个维度整合，可得到一张三维指标族表。效用维包含增量成功率、任务得分、校准误差；副作用维包含延迟增量、token 增量、降级正确率、负迁移量；退化维包含时间方差、跨期斜率、子群离散度。每个指标都应记录点估计、置信区间、样本量三要素，缺一不可。工程上可将这张表固化为评测报告的模板，避免每次验收口径漂移。

6.2 实验设计：从 A/B 到配对消融

实验设计应遵循“先配对、后分组、再时间序列”的顺序。配对消融用于估计增量效用；分组实验（按任务族、按难度、按输入长度分层）用于发现异质性效应；时间序列用于估计退化。三者结合，才能同时回答三个问题。需要提醒的是，分层分析会带来多重比较问题，应使用 Bonferroni 或 FDR 校正，避免把随机波动误判为显著差异。

# 分层 + 多重比较校正的评测报告结构（伪代码）
strata = ["short_query", "long_doc", "tool_required", "no_tool"]
for s in strata:
    d_s = paired_delta(eval_set[s])
    p_s = paired_test(eval_set[s])
p_adj = fdr_correction([p_s for s in strata])
report(strata, deltas, p_adj)

6.3 工程落地路径：五步法

笔者建议按以下五步落地：第一步，定义 Skill 边界与开关，记录作用层、依赖项；第二步，构建分层评测集，覆盖目标任务族与相邻任务族，并保留一份“冻结集”用于跨期比较；第三步，跑配对消融，估计增量效用与置信区间；第四步，采集副作用指标，绘制权衡曲线，确定工作点；第五步，建立周期性回归与漂移监控，设置告警。五步并非一次性完成，而是随 Skill 迭代持续运行。关于评测流水线的工程化，可参考 EleutherAI lm-evaluation-harness 的开源实现，其任务注册与指标聚合机制对自建流水线有直接借鉴价值。

七、关键数据与案例：来自公开基准与工程实践的观察

公开研究中，检索增强的收益与代价已有较多量化。RETRO（Borgeaud 等，2022）报告了在参数量较少时借助外部检索达到与更大模型可比的效果，但其评测聚焦语言建模困惑度，未系统报告延迟与工程成本；本文评述：这类工作报告的是“能力上限”，而工程验收需要的是“在给定成本约束下的能力”，两者口径不同，不能直接套用。RAG 原始工作（Lewis 等，2020）在开放域问答上展示了检索带来的事实性提升，但同样以任务指标为主。近期关于 RAG 评测的工作（如 RGB、RAGAS 等）开始引入忠实度、上下文相关性等细粒度指标，方向与本文的副作用维度部分重合。

工具调用方向，Toolformer（Schick 等，2023）与 ToolLLM（Qin 等，2023）展示了模型自主调用工具的能力，但工具调用的失败模式（参数错误、超时、返回格式异常）在论文中报告较少。本文认为，这正是工程评测需要补位的地方：学术基准衡量“能不能调”，工程验收必须衡量“调错了会怎样”。Agent 方向的评测工作（如 AgentBench，Liu 等，2023）开始引入多轮、多环境的评测，但时间稳定性维度仍普遍缺失。

表 3：代表性工作与三维框架的覆盖对照（本文整理，非原文结论）

工程实践方面，笔者接触的多支团队在引入检索 Skill 后普遍观察到“质量升、延迟升”的权衡，部分团队通过缓存与并行检索将 P95 延迟增量控制在 40% 以内。这些观察属于工程经验，未做严格对照实验，不宜作为普适结论，但可作为评测设计的参考场景。关于 RAG 评测的实践细节，可参考 RAGAS 官方文档 与 Pinecone 的 RAG 系列教程。

八、对比与局限：三维框架的适用边界

三维框架并非没有代价。首先是评测成本：配对消融使评测次数翻倍，分层与周期性回归进一步放大成本。工程上需在覆盖度与成本间取舍，例如对核心任务族做全量配对，对长尾任务族做抽样。其次是指标可比性：不同 Skill 的副作用指标口径可能不同，跨团队比较需统一模板。再次是因果识别的局限：配对消融能控制已知变量，但对系统级交互（如检索与工具调用的耦合）仍难以完全分离，此时需借助更细的日志与反事实分析。

与传统的“上线前一次性验收”相比，三维框架把评测从“事件”变成“过程”，这要求组织在流程上做出配套调整：评测集维护、监控告警、回归节奏都需要专人负责。本文评述：评测方法论的升级往往不是技术问题，而是流程与责任问题；没有稳定的评测 owner，再好的指标设计也会退化为一次性报表。关于评测治理的讨论，可参考 基础模型评测综述 中对评测生命周期管理的讨论。

九、结论与展望

回到标题的问题：只跑成功率为什么不够？因为成功率只回答了“任务终点是否达成”，没有回答“收益是否归因于 Skill”“达成付出了什么代价”“这种达成能否持续”。本文提出的效用—副作用—退化三维主线，把这三个问题转化为可度量、可检验、可落地的指标族与实验设计。其核心不是增加指标数量，而是建立一条从归因到代价再到时间的完整证据链。

展望未来，笔者认为三个方向值得关注：一是评测的自动化与低成本化，用模型辅助评分与主动采样降低配对实验成本；二是在线与离线评测的闭环，把线上监控信号反馈到离线评测集更新；三是跨 Skill 的交互评测，当多个 Skill 同时启用时，组件间的耦合效应可能成为主要风险源。这些问题目前公开研究仍较有限，是工程与学术可以共同推进的方向。