技能熵：破解LLM长时程推理评测失真的新指标

如果你正在做 LLM 应用，一定见过这种场景：单轮问答里模型表现得像个专家，一旦让它连续完成数据分析、多表查询、代码修改、异常恢复这类需要十几步决策的任务，能力就开始波动。排行榜上的分数不低，可放在真实业务里一跑，经常卡在某个不起眼的中间步骤上。问题不在模型不够聪明，而在我们评测它的方式太粗了。

最近有一篇论文标题值得关注：Toward Skill-Native LLMs: Skill Entropy for Benchmarking and Training Long-Horizon Reasoning。它把“技能熵”（Skill Entropy）这个概念引入大模型的评测与训练，试图回答一个本质问题：模型的高分，到底是来自对技能的真正掌握，还是来自对训练数据里某些固定路径的记忆？我的判断是，这是大模型评测从“任务正确率”走向“技能原生能力”的一个明确信号。看完这篇文章，你会理解技能熵到底在测什么、怎么算、怎么用于训练数据与评测集分析，以及团队落地时最容易踩的坑。

1. 为什么长时程推理场景下，评测分数会“失真”

1.1 长时程推理在哪里最难做

长时程推理（Long-Horizon Reasoning）指的是模型需要在较长步骤内保持规划、执行和纠错能力的任务。它和单轮问答最大的区别是：每一步都可能影响后续所有结果。比如让 Agent 完成“从订单库中筛选异常交易，回溯用户历史行为，生成归因报告并发送告警”，这个流程不是一次生成能搞定的，模型必须先拆解目标、调用工具、读取中间结果、判断条件、修正方向，最后汇总输出。

难点在于，这类任务的中间状态是不可预测的。模型在第一步选择错误的 API，后面所有步骤都会跟着错，而且错误不会像选择题那样在最后一步统一暴露。很多团队都有过类似体验：模型在测试集上能把任务跑通，但换一个数据分布、换一套业务字段，立刻就找不到北。这说明模型可能并没有真正学会“如何做”，只是在复现训练数据里某些成功轨迹的局部特征。

1.2 传统评测指标的三层盲区

当前主流 benchmark 最常用的指标是任务成功率、准确率、pass@k 这类结果导向指标。它们当然有参考价值，但用于长时程推理时存在三层盲区：

第一，只看最终结果，无法判断过程是否合理。两个模型同样把代码写通了，一个按正常架构设计，另一个靠硬编码绕过测试，分数上完全一样，但后者的工程价值几乎为零。

第二，指标对随机试错不敏感。长时程任务搜索空间极大，模型如果依靠多次采样、暴力试错偶尔成功一次，pass@k 也会很高。它隐藏了“成功率不稳定”的问题。

第三，看不到技能覆盖范围。一个模型如果只在训练数据里高频见过的几种操作上很强，遇到低频场景就崩，传统分数很难反映这种偏科现象。你会发现它“平均分能看”，但“方差极大”。

这三点结合起来，就会形成一个普遍现象：排行榜分数在涨，业务落地的体感却没跟着涨。技能熵的出发点，正是为了补上这些盲区里最重要的一块——模型在推理过程中到底使用了哪些技能，以及这些技能的使用是否均衡。

2. Skill-Native LLMs 与技能熵：两个核心概念

2.1 从任务到技能：评测粒度的一次迁移

理解技能熵之前，先理解“任务”和“技能”的区别。任务是用户给出的一个具体目标，比如“写一个爬虫抓取新闻”；技能则是完成任务过程中可复用的能力单元，比如“发现网页结构并定位列表”“处理请求失败并重试”“解析 HTML 并提取正文”。一个任务由多个技能组合而成，而一个技能可以横跨多个任务复用。

“Skill-Native LLMs”在论文标题里直译是“技能原生的大模型”，意思是模型的能力结构应当以技能为底层单元，而不是以任务样例为底层单元。任务样例背得再多，换一种组合方式就失效；技能掌握得扎实，遇到新任务时才能真正迁移。这个区分在评测上尤其重要：我们真正想测的，是模型面对未知任务时能不能像“熟练工”一样调用技能，而不是它有没有背过类似题目。

2.2 技能熵的计算直觉

熵在信息论里用来衡量一个系统的不确定性。技能熵（Skill Entropy）在这里被用来衡量模型在一次或多次推理过程中使用技能的分布情况。假设模型执行某类任务 100 次，我们统计它在所有轨迹中使用的技能种类和次数，得到每个技能的使用概率 p(s)，那么技能熵就可以用标准香农熵公式计算：

H = - Σ p(s) * log2 p(s)

结果是越高还是越低，取决于技能分布。如果一个模型反复只用“搜索 API”和“格式化输出”两种技能，概率各占一半，熵就是 1.0 bit；如果它在 20 种技能上接近均匀分布，熵就会明显更高。所以技能熵的本质是：模型的行为在技能层上有多“分散”。

不过这里要特别强调一个容易被误解的点：技能熵不等于文本多样性，也不等于“疯狂试错”。文本熵衡量 token 层面生成的新颖程度，技能熵衡量的是抽象行为层面对技能库的使用结构。一个模型可以输出完全不同的文字，却始终只用同一个技能；也可以每次操作都很规范，但技能覆盖很广。技能熵关注的是后者。

2.3 技能熵不是越高越好

如果只看到“高熵=技能丰富”，容易得出一个错误结论：让模型尽可能多地尝试各种技能。实际情况比这复杂。

技能熵高但成功率低，说明模型在“乱开枪”：遇到问题随机切换技能，行为足够多样，但没有形成稳定的正确路径。技能熵低但成功率高，可能说明任务本身简单，两三个技能就够用，也可能说明模型存在技能塌缩（skill collapse），只会用少数几种惯性技能应付所有问题。因此更合理的做法，是把技能熵和“条件成功率”一起看，也就是“在使用技能 S 的情况下，任务完成率是多少”。当某个技能使用率很低、但条件成功率很高时，说明模型有潜力但缺少主动调用；当某个技能使用率很高、条件成功率很低时，说明模型在用它填充路径，实际上没有掌握。

把技能熵理解为“评测的一个维度”而不是“唯一的越好指标”，后续做训练设计和工程落地时才不会跑偏。

3. 技能熵进入评测体系后，给 Benchmark 带来什么改变

3.1 任务级、步骤级、技能级三个指标层

传统评测几乎都停在任务级指标：模型最终输出对不对，对比答案算一个分。技能熵的引入，实际上是逼着评测体系往更深的两层走。

步骤级指标关注的是轨迹中每一步是否正确，比如工具调用是否选对了参数、中间结果是否被正确处理。技能级指标关注的是轨迹中出现的技能种类、分布和条件成功率。这三层指标合在一起，才能回答三个递进的问题：任务是否完成？过程是否合理？模型是否具备稳定的技能基础？

如果只做任务级评测，你只能知道模型“行不行”；加上技能级指标后，你能知道模型“为什么行”“为什么不行”。对技术团队来说，后者直接决定改进方向：是补充数据，还是调整奖励，还是换评测集。

3.2 技能熵如何帮助发现“背题模型”

这里可以举一个教学场景中的理想化例子。假设两个模型 A 和 B 在同一 benchmark 上任务准确率都是 75%，表面看起来难分伯仲。我们用技能标签分析它们的轨迹，发现模型 A 的有效能力高度集中在三个高频技能上，技能熵很低；模型 B 在十二个技能上分布相对均匀，技能熵明显更高。

换到真实业务场景，模型 A 一旦遇到第四个技能的需求，比如“跨系统鉴权失败后的恢复流程”，很可能直接崩溃；模型 B 虽然单项技能都不是最顶尖，但遇到新组合时更容易迁移。传统指标不会告诉我们这个差异，技能熵会。这也是为什么它特别适合用来排查“高分低能”模型。

需要说明的是，这个例子是用于说明指标价值的简化推演，真实评估时要结合任务难度和技能定义来解读。不能只看熵值高低就下结论，必须结合技能全集、任务类型和成功率一起判断。

3.3 评测集自身的技能熵也值得检查

技能熵不仅用来测模型，也可以用来测评测集。一个 benchmark 如果自身技能覆盖很窄，长期只在少数几种技能上出题，模型只要刷熟这些技能就能拿高分，benchmark 很快就会失效。这也是很多公开榜单“分数饱和”的原因之一——不是模型到达能力天花板，而是题目里的技能组合已经无法区分模型差异。

所以在设计或选型评测集时，可以先对评测样本做技能标签标注，再统计整个评测集的技能熵和技能覆盖率。如果一个长时程推理 benchmark 的技能熵很低，说明它对模型技能广度的区分能力有限，做横向对比时要格外谨慎。

4. 技能熵参与训练：数据配比、奖励信号与课程顺序

4.1 直接用熵做损失函数，方向对但不要贪心

很多人看到“技能熵用于训练”，第一反应是把它加进损失函数，让模型优化技能熵。理论上这可行，但从工程实践看，直接当作反向传播目标非常难控制，容易出现两个问题：一是模型为了提升熵而刻意增加无意义技能切换，破坏任务完成度；二是技能标签往往是离散的、带噪声的，直接优化一个噪声很大的中间变量，梯度不稳定。

更务实的思路是把技能熵当作训练过程的设计信号，在数据层、奖励层、课程层三个地方间接使用。这也符合论文标题中“for Benchmarking and Training”的定位：它既可以作为评测指标，也可以作为训练流程的指导原则。

4.2 数据层：按技能稀有度重采样

训练数据里的技能分布通常天然不均衡。面向安全合规的“权限校验”技能出现频率低，而“格式化输出”可能到处都是。模型长期在这种数据上训练，会倾向于把高频技能练得很好，低频技能则被忽略。

解决思路是给训练样本打上技能标签，然后按技能的稀有程度调整采样权重。一个样本如果包含多个低频技能，它的采样概率就应该相应提高。这样模型接触到的技能分布会更均衡，训练完成后技能熵也更容易保持在合理水平。实际操作中要注意别把权重放大得太夸张，否则会过拟合少量稀有样本，反而降低整体泛化能力。

4.3 奖励层：任务成功率 + 技能多样性联合判断

在 RLHF 或基于规则奖励的强化学习流程里，奖励模型通常只关心任务最终是否成功。这会让模型学会“找到一条能到终点的路径就行”，而不是“掌握一组可迁移的技能”。如果能在奖励信号中加入对技能使用质量的评估，例如任务完成的基础上，给“使用了合理范围的技能”一定的正向奖励，对“仅靠重试和乱试成功”的轨迹做抑制，模型的行为分布会更接近真实工程场景。

这里的难点在于如何定义“合理”。稳妥的方案是先统计人类专家轨迹的技能熵分布，再设定一个可接受区间，避免纯熵奖励带来的副作用。不追求熵最大，追求熵落在专家区间附近，同时成功率不下降。

4.4 课程层：原子技能先过关，复合技能再组合

长时程推理需要对技能进行组合。模型如果连“调用搜索接口并解析结果”这个原子技能都不稳，直接让它完成“搜索竞品信息并生成对比报告”，失败率会非常高。按技能依赖关系设计课程顺序，是工程上更容易落地的训练优化方式：先保证每个原子技能的条件成功率达标，再在训练数据中逐步引入需要多技能协同的复合任务。

技能熵在这个流程里可以当“阶段考成绩”。每个阶段跑一批轨迹，统计模型是已经均衡掌握当前阶段技能，还是只靠少数技能蒙混过关。如果技能熵显著低于上一阶段，说明模型可能出现了技能塌缩，这时不应该急着进入下一阶段课程，而应补充对应技能的训练数据。

5. 工程示例：用 Python 计算推理轨迹的技能熵

5.1 先定义技能标签

技能熵的计算前提是轨迹带有技能标签。真实场景中，技能标签可以由三种方式生成：人工标注、工具调用日志映射、模型自动聚类。这里用一个最小示例演示核心逻辑，不依赖任何论文代码库，读者可以直接复制到本地跑通。

我们定义五个简单技能：代码定位、API 调用、异常处理、日志分析、数据格式化。为了演示，先用字符串匹配从文本轨迹中粗粒度解析技能。真实项目中建议替换为工具调用钩子或结构化的推理日志。

# skill_entropy.py import math from collections import Counter from typing import Dict, List SKILLS = ["代码定位", "API调用", "异常处理", "日志分析", "数据格式化"] def parse_skills(trace: str) -> List[str]: """从推理轨迹中解析技能标签，这里使用简化的关键词匹配。""" skills = [] trace_lower = trace.lower() if "locate" in trace_lower or "定位" in trace_lower: skills.append("代码定位") if "api" in trace_lower or "调用" in trace_lower: skills.append("API调用") if "exception" in trace_lower or "异常" in trace_lower: skills.append("异常处理") if "log" in trace_lower or "日志" in trace_lower: skills.append("日志分析") if "json" in trace_lower or "格式化" in trace_lower: skills.append("数据格式化") return skills def skill_entropy(traces: List[str]) -> Dict[str, float]: counter = Counter() for trace in traces: counter.update(parse_skills(trace)) total = sum(counter.values()) if total == 0: return {"entropy": 0.0, "coverage": 0.0, "distribution": {}} probs = {skill: count / total for skill, count in counter.items()} entropy = -sum(p * math.log2(p) for p in probs.values()) coverage = len(counter) / len(SKILLS) return { "entropy": entropy, "coverage": coverage, "distribution": probs, } if __name__ == "__main__": sample_traces = [ "locate function then call api and handle exception", "解析日志后调用 api，将结果格式化为 json", "call api with retry, then format json", "定位代码问题，查看日志并格式化输出", ] result = skill_entropy(sample_traces) print(result)

代码逻辑比较简单：先用parse_skills把每条文本轨迹解析成技能列表，再用Counter汇总技能出现次数，最后按香农熵公式计算熵，同时输出技能覆盖率。这里用了 Python 标准库，Python 3.8 及以上都能运行。

运行上面的脚本，会看到类似输出：

{'entropy': 1.8464393446710154, 'coverage': 1.0, 'distribution': {'API调用': 0.4, '数据格式化': 0.3, '异常处理': 0.1, '代码定位': 0.2, '日志分析': 0.2}}

讲解：示例轨迹覆盖了全部五个技能，因此覆盖率为 1.0；熵值在 0 到 log2(5) 约 2.32 之间，当前 1.85 表示分布相对分散。覆盖率低、熵也低，往往说明这套轨迹过于单一。

5.2 命令行化：从文件读取轨迹

进入真实工作流，轨迹不会写在代码里，而是以文件或数据库形式存在。可以做一个支持命令行的版本，从 JSON 文件读取轨迹，并指定技能全集。

# skill_entropy_cli.py import argparse import json import math from collections import Counter def load_json(path): with open(path, "r", encoding="utf-8") as f: return json.load(f) def compute_entropy(traces, skills): counter = Counter(s for trace in traces for s in set(trace)) total = sum(counter.values()) if total == 0: return 0.0 return -sum((c / total) * math.log2(c / total) for c in counter.values()) def main(): parser = argparse.ArgumentParser(description="计算推理轨迹的技能熵") parser.add_argument("--traces", required=True, help="轨迹文件，JSON 列表，元素是技能字符串列表") parser.add_argument("--skills", required=True, help="技能全集，JSON 数组") args = parser.parse_args() traces = load_json(args.traces) skills = load_json(args.skills) entropy = compute_entropy(traces, skills) coverage = len({s for trace in traces for s in set(trace)}) / len(skills) print(json.dumps({"entropy": entropy, "coverage": coverage}, ensure_ascii=False, indent=2)) if __name__ == "__main__": main()

这里的输入不是原始文本，而是已经解析好的技能标签列表。compute_entropy使用set(trace)对同一条轨迹内的重复技能去重，避免某条长轨迹里反复出现同一个技能，导致分布失真。

对应的命令行测试如下：

cat > traces.json <<'EOF' [["SQL查询", "数据分析"], ["SQL查询", "异常处理"], ["数据分析", "告警文案生成"]] EOF python skill_entropy_cli.py --traces traces.json --skills '["SQL查询", "数据分析", "异常处理", "告警文案生成"]'

预期输出：

{ "entropy": 1.5, "coverage": 1.0 }

如果你的数据是原始文本轨迹，可以把trace先经过解析模块，再喂给 CLI。真实项目中建议把技能解析做成独立服务或离线 pipeline，便于统一维护和版本管理。

6. 评测集与训练集也要做“技能健康度”体检

6.1 带技能标签的评测样本长什么样

为了让技能熵可用，评测样本不能只有问题和答案，还需要附带技能元数据。下面是一个简化示例，表示评测样本中的“必需技能”：

{ "task_id": "task_0042", "description": "从订单表查询异常交易并生成告警摘要", "required_skills": ["SQL查询", "数据校验", "告警文案生成"], "trace": "模型推理轨迹或工具调用序列", "success": true }

有了这样的标注，评测集就可以被当作一个整体来分析。比如统计全部评测样本的必需技能分布，计算评测集的技能熵，判断当前评测是不是只覆盖少数几种能力。如果评测集技能熵很低，则说明它区分不了真正技能广博的模型和只会固定几招的模型。

另一个实用做法是统计每个技能在评测集中出现的频率，建立“技能—样本”倒排索引。当线上模型在某类任务失败时，可以通过技能标签快速定位到对应评测样本，分析是数据不足还是技能调用错误。

6.2 按稀有技能加权的训练数据采样

训练数据同样可以复用这套技能标签体系。下面这个示例演示了如何根据技能稀有度调整采样权重，让低频技能得到更多训练机会。

import random samples = [] # 已加载的带技能标签训练样本，每个样本有 required_skills 字段 skill_count = {} for sample in samples: for skill in sample["required_skills"]: skill_count[skill] = skill_count.get(skill, 0) + 1 if not skill_count: raise ValueError("samples 中没有技能标签") min_count = min(skill_count.values()) weights = [] for sample in samples: required = sample["required_skills"] avg_freq = sum(skill_count[s] for s in required) / len(required) weight = 1.0 + (min_count / avg_freq) weights.append(weight) selected = random.choices(samples, weights=weights, k=8)

代码的思路是：一个样本涉及的技能越稀有，min_count / avg_freq越大，权重越高。+1.0保证所有样本都有基础采样概率，不会让高频样本彻底消失。真实使用时，建议对权重做上限截断，避免某个极端稀有技能把采样分布拉偏。

这里需要强调，加权采样只是技能熵参与训练的最简单方式。如果团队已经在跑强化学习，可以把技能熵作为离线分析指标，对比不同训练阶段的模型是否出现技能塌缩。先诊断，再调整训练策略，比直接改奖励函数要稳得多。

7. 常见疑问与排查思路

7.1 常见问题表格

7.2 排查一个“高分低能”模型的建议路径

如果团队遇到“模型在 benchmark 上表现好，但业务上线效果差”的问题，可以按下面这条路径排查：

先收集真实业务里的失败样例，为每条失败样例标注已使用的技能和应该使用但没有使用的技能。然后统计真实业务轨迹的技能熵，与评测集上的技能熵对比。如果真实业务轨迹中低频技能出现频率更高，而评测集技能覆盖太窄，说明评测集没有反映真实业务分布。接着检查失败轨迹中，模型是否反复停留在同一类技能上，如果是，大概率发生了技能塌缩。最后根据缺失技能补充训练数据，并重新评测。

这套路径的核心不是追求某个理想熵值，而是让评测、训练、真实业务三个场景的技能分布尽量对齐。技能熵在这里的作用是提供数字化依据，让团队沟通时不再靠感觉。

8. 落地时的工程化建议

8.1 技能体系怎么建

技能集合是技能熵的地基，地基不稳，后面所有指标都不可信。建议先面向具体业务定义 10 到 20 个粗粒度技能，而不是一开始就追求细到每行代码的标注。粗粒度技能更容易达成标注共识，统计结果也更容易理解。

技能可以分成三类：原子技能、组合技能、领域技能。原子技能是最小可复用的操作，比如“调用接口”“解析 JSON”“写入数据库”；组合技能是多个原子技能形成的固定套路，比如“先查询再校验最后写入”；领域技能则依赖特定业务知识，比如“识别高风险交易”。在计算技能熵时，最好把这三类分开统计，否则混在一起会让解释变得困难。

技能体系的版本管理也很重要。业务在变，技能集合也要跟着变。每次调整技能定义后，旧轨迹的标签需要重算一遍，否则历史对比就没有意义。

8.2 评测与训练流程怎么接

建议在评测流程中增加一个“技能健康度报告”，与正确率报告一起输出。报告至少包含四张表：全量轨迹技能分布、技能熵、技能覆盖率、每个技能的条件成功率。模型上线或训练迭代时，对比两次报告的差异，能很快定位能力回退来自哪个技能维度。

训练流程中，先不要急着改损失函数，优先做数据层干预。训练前对训练样本做技能标签化，统计分布；训练中定期采样轨迹，计算技能熵；训练结束后与基线模型对比技能覆盖变化。等到数据层方案稳定了，再考虑把技能熵作为奖励函数的一部分。

如果使用外部模型来做技能标签标注，需要注意标注模型本身的偏差。建议每批次随机抽取一部分轨迹做人工复核，用标注一致性来评估自动标签的质量。

8.3 安全与合规边界

技能熵的核心数据结构是推理轨迹，这会涉及用户数据和系统调用记录。处理这些数据时必须遵守最小权限原则：只采集安全评估、模型迭代所需的必要信息，避免把敏感数据写入保存痕迹过长的轨迹日志。评测模型的工具调用行为时，应当在隔离环境或沙箱中执行，防止模型在测试过程中访问到生产系统的权限。

使用技能标签对模型行为进行分类时，要避免针对用户身份、设备指纹等敏感维度的不当关联。技能分类只应对“技术能力范围”负责，不应扩展到用户画像或其他业务维度。在生产环境引入任何基于技能标签的训练或评测干预前，都应先在小范围数据集上验证，并保留回滚方案。

9. 总结与下一步实践方向

这篇论文标题背后，是评测范式的转变：大模型评测不能只看“答对没有”，还要看“会不会用技能”。技能熵提供了一个相对简单但又很关键的量化维度，让评测结果能解释模型为什么强、强在哪、弱在哪。把它和条件成功率放在一起，可以作为长时程推理任务的数据分析、评测集设计、训练策略调整的重要参考。

如果你想把这个思路落到实践，建议从一件小事开始：挑一个你们团队最头疼的长时程任务，拆出 10 个左右的关键技能，给 100 条真实轨迹打标签，用上面的脚本算出技能分布和技能熵，再对比两个候选模型。你很可能很快就会发现，分数接近的两个模型，在技能覆盖和技能使用偏好上的差距远比想象中大。这一步跑通后，再决定是否把技能熵纳入训练数据配比和奖励设计也不迟。