这次我们来看一个偏研究向但和工程评测强相关的话题论文标题是《Toward Skill-Native LLMs: Skill Entropy for Benchmarking and Training Long-Horizon Reasoning》。它解决的问题非常具体大语言模型在长程推理Long-Horizon Reasoning场景下怎么评测才算真正“会”怎么训练才能不靠刷题刷出高分。现在主流评测方式本质上是把一堆数学题、代码题、Agent 任务丢给模型看最终的答案正确率。这种方式有两个明显缺陷。第一正确率只关心终点不关心过程模型是稳定地一步步推理还是中途反复切换思路、频繁试错、跑偏又拉回来这些信息全部丢掉了。第二数据污染严重模型可能已经见过同类型题目最后的分数根本没有反映真实推理能力。Skill Entropy技能熵这个指标的出发点就是去度量模型在解决长程任务时对“技能”的使用分布是稳定调用正确的技能组合还是技能选择混乱、东一榔头西一棒子。这篇文章会围绕三件事展开。第一解释 Skill Entropy 大概是什么、在当前研究语境下可以怎么理解。第二给出一个可落地的 Benchmarking 流程包括用 Python 计算技能熵的示例代码和一套本地评测验证步骤。第三讨论它怎么接入训练环节以及在复现过程中最容易踩的坑。如果你在做 LLM 评测、Agent 链路设计、或者强化学习训练数据筛选这篇文章可以直接收藏。1. 研究方向速览先把这张表放在最前面方便快速判断这个方向和你有没有关系。项目类型大语言模型评测与训练方法研究核心指标Skill Entropy技能熵目标能力Long-Horizon Reasoning长程推理应用环节Benchmarking评测 Training训练核心主张让模型成为 Skill-Native即真正内化技能而非记忆题目适合读者LLM 算法工程师、评测工程师、Agent 研究者、RLHF/RLVR 训练工程师复现硬件小规模评测可用单张 24G 显存显卡或云端 API完整训练实验需要多卡集群是否开源以论文正式公开版本和官方代码仓库为准批量任务评测流程天然支持批量样本跑批主要风险技能标注主观性、评测集污染、训练收益不稳定需要说明的是这里没有“实测显存 8G 能跑”之类的结论因为这是一个研究方法方向不是开箱即用的一键包。本文给的是理解框架、计算方法和验证流程具体效果要以论文原版和你的实验数据为准。2. 研究背景长程推理评测为什么需要新指标长程推理和单步问答最大的区别是模型必须在一段很长的轨迹上保持目标一致。写代码可能要跨几十个函数调用跑 Agent 任务可能要经历规划、检索、调用工具、验证结果、修正再继续的过程。任何一个环节技能选择出错最终答案都可能崩掉。传统评测指标在这里有四个明显问题。第一正确率是稀疏反馈。一条 20 步的推理轨迹只有最后一步给 0 或 1 的分数。中间哪个技能用错了哪一步开始跑偏完全看不见。这导致你无法判断模型是“推理能力强”还是“运气好蒙对了”。第二结果指标容易被数据污染。如果测试题和训练集高度相似模型完全可以通过记忆作答不需要真正调动推理技能。这种情况下评测分数虚高上线后一旦遇到新题型能力立刻跳水。第三多任务混在一起无法定位问题。一个 benchmark 往往包含多个子任务和多种技能。总分下降时你不知道是规划能力退化还是计算技能不稳定还是长上下文跟随能力出了问题。第四过程行为没有被约束。部分模型在推理时会频繁切换思路、重复尝试、甚至在同一类操作上反复横跳。从结果看可能对了但这不是我们希望模型学到的行为。Skill Entropy 这类过程指标正是冲着这些问题来的。它的基本想法是把一条推理轨迹拆成带技能标签的步骤序列然后统计技能使用的分布和切换模式用熵来量化“模型对自己在用什么技能”这件事的确定性。3. Skill Entropy 概念解读如何度量“技能原生”3.1 从信息熵到技能熵信息论里的香农熵衡量的是一个概率分布的不确定性。公式是H - Σ p_i * log(p_i)其中 p_i 是第 i 个事件发生的概率。熵越低分布越集中熵越高分布越分散。Skill Entropy 的做法是把“技能”当作事件。给定一条推理轨迹每个步骤都可以被标注为某个技能比如“理解问题”“规划”“检索”“计算”“验证”“总结”。统计整条轨迹中这些技能出现的频率就能得到一个技能分布然后计算熵。这里有一个关键点熵本身没有好坏需要结合任务来看。对一条结构良好的长程推理轨迹技能分布应该是有序的、集中的熵相对低。如果模型在每一步都犹豫不决、频繁尝试不同技能技能样本会非常分散熵就很高。3.2 技能熵的三种计算口径从标题和当前研究趋势看技能熵可能有三层含义它们在论文里可能对应不同的实验设计。第一种是轨迹技能分布熵。把一条完整轨迹中所有步骤的技能标签汇总计算频率分布和香农熵。这是最直接的版本实现最简单。第二种是决策点技能不确定性。在每个决策点模型要在候选技能中做选择通过对数概率或分类头的输出分布计算当前决策的不确定度。这个口径更细但需要模型能输出技能层面的概率分布实现成本更高。第三种是技能转移熵。统计相邻步骤之间技能转移的分布比如“规划 - 检索”出现了几次“计算 - 规划”出现了几次再对转移分布计算熵。这个口径能捕捉技能切换的紊乱程度。实际做实验时建议三种口径都算一遍看哪个和任务正确率的相关性更强。不同任务里最有区分度的口径可能不一样。3.3 低熵和高熵的模型行为差异低技能熵的模型行为上是“知道自己该干什么”先理解问题再规划然后按计划检索和计算最后验证。每一步之间技能切换清楚即使某一步失败修正也很精准。高技能熵的模型行为上是“什么都试一下”规划两下又跑去检索检索完还没总结又去计算然后发现不对再切回规划。最终可能成功也可能失败但整个过程资源消耗大、可解释性差。从训练角度看我们希望模型在正确的任务阶段集中使用正确的技能而不是均匀地乱试。所以“技能原生”Skill-Native这个说法指向的是让技能成为模型内在的行为习惯而不是表面上的答题技巧。4. Benchmarking如何建设“技能熵”评测基准4.1 评测流程总览要把技能熵真正用起来评测流程需要从“只看最终答案”改成“记录轨迹 标注技能 计算指标”。上线一个技能熵评测基准完整流程是这样定义任务集选择需要长程推理的任务类型比如多步数学题、代码修复、Agent 工具调用任务。定义技能标签体系提前列出该任务会用到哪些技能例如理解、规划、检索、计算、验证、总结。跑模型推理记录完整轨迹包括每步的输入输出、工具调用记录、中间结果。给轨迹打技能标签可以用人工标注也可以用规则或小模型自动标注。计算技能熵按轨迹级别聚合计算分布熵、切换次数、转移熵。关联正确率把技能熵和最终正确率做相关性分析检验指标是否有效。4.2 一个可运行的技能熵计算脚本下面这段 Python 代码可以直接复制到本地跑通技能熵的计算逻辑。它为每条轨迹生成一组技能标签样本然后计算分布熵和技能切换次数。import math from collections import Counter def shannon_entropy(skills): 计算一条轨迹的技能分布香农熵。 total len(skills) if total 0: return 0.0 counter Counter(skills) entropy 0.0 for count in counter.values(): p count / total entropy - p * math.log2(p) return entropy def skill_switch_count(skills): 统计相邻步骤之间技能发生切换的次数。 switches 0 for prev, curr in zip(skills, skills[1:]): if prev ! curr: switches 1 return switches # 示例两条长程推理轨迹的技能标签序列 trajectory_a [ 理解问题, 规划, 检索, 计算, 计算, 验证, 总结 ] trajectory_b [ 规划, 检索, 检索, 规划, 检索, 计算, 规划, 计算, 验证, 检索, 总结 ] for name, traj in [(轨迹A, trajectory_a), (轨迹B, trajectory_b)]: print(f{name}: 步骤数{len(traj)}) print(f 技能分布{dict(Counter(traj))}) print(f 技能熵{shannon_entropy(traj):.4f} bit) print(f 技能切换次数{skill_switch_count(traj)})运行后可以看到轨迹 A 技能集中熵较低轨迹 B 技能分散且反复切换熵较高。这种差异就是技能熵用于评测的基础。4.3 技能标签怎么来技能标注是整个流程里最主观、最容易出问题的一步。有三种做法。人工标注最准但成本高适合小样本。规则标注适合那种步骤结构固定的任务比如 Agent 调用工具时可以按工具类型自动映射技能。模型标注成本低但需要先验证标注模型的准确率否则噪声会直接污染技能熵的计算。无论用哪种方式都要先出一份标注规范明确“什么动作算规划”“什么动作算检索”并且做标注一致性检查。如果两个人标同一条轨迹的一致性很低那技能熵算出来也不可信。4.4 从轨迹数据到技能熵实际批量评测时模型的推理输出一般不是干净的技能标签你需要先解析轨迹。以 Agent 任务为例轨迹通常是一串“思考 工具调用 观察”的记录。可以用一个简单的解析函数来提取技能标签序列。def extract_skills_from_trajectory(trajectory_entries, tool_to_skill): 把轨迹条目映射为技能标签序列。 trajectory_entries: 列表每个元素是 {type: thought|tool, content: ...} tool_to_skill: 字典工具名到技能名的映射 skills [] for entry in trajectory_entries: if entry[type] thought: content entry[content] if 公式 in content or 数值 in content: skills.append(计算) elif 计划 in content or 步骤 in content: skills.append(规划) else: skills.append(思考) elif entry[type] tool: tool_name entry[content] skills.append(tool_to_skill.get(tool_name, 未知技能)) return skills # 这是示例配置实际按你的工具列表调整 tool_to_skill { search: 检索, calculator: 计算, code_interpreter: 计算, file_reader: 检索, } sample_trajectory [ {type: thought, content: 我先制定一个三步计划}, {type: tool, content: search}, {type: thought, content: 把搜索到的数值代入公式}, {type: tool, content: calculator}, ] print(extract_skills_from_trajectory(sample_trajectory, tool_to_skill))这个解析逻辑是通用的你可以替换成自己的任务结构。核心思路是不管是思维链文本还是工具调用记录只要能稳定映射成技能标签序列就能接入熵计算。5. Skill Entropy 如何进入训练流程评测指标和训练指标是两回事。技能熵如果只在评测时使用那它只是一个分析工具。真正有价值的地方是把它接入训练让模型在训练阶段就朝着“技能原生”的方向优化。从当前主流训练范式看技能熵可以从三个位置接入。5.1 数据侧技能标签作为训练信号第一种做法是在 SFT 数据构造时给每条轨迹打技能标签让模型显式学习“在什么状态下调用什么技能”。具体来说可以在系统提示词里注入当前任务阶段的技能提示或者在数据中保留技能切换的中间监督。这种方法的落地成本中等但效果直接。它相当于把长程推理拆成了“技能粒度”的监督学习模型更容易学到稳定的行为模式。5.2 奖励侧技能熵作为 Reward Shaping第二种做法是在强化学习阶段把技能熵作为奖励塑形项。长程推理的最终奖励稀疏模型很难通过探索学到稳定策略。技能熵可以作为过程奖励惩罚混乱的技能切换奖励集中的、有序的技能使用。一个常见的 reward 设计思路是def compute_reward(final_correct, skill_sequence, lambda_e0.1): 最终正确率 技能熵惩罚的混合奖励示例。 entropy shannon_entropy(skill_sequence) switch_count skill_switch_count(skill_sequence) # 最终结果奖励正确为 1错误为 0 result_reward 1.0 if final_correct else 0.0 # 过程奖励熵和切换次数越低越好 process_penalty lambda_e * (entropy 0.1 * switch_count) return result_reward - process_penalty # 示例同样最终正确一个轨迹有序一个轨迹混乱 traj_orderly [理解问题, 规划, 检索, 计算, 验证, 总结] traj_messy [规划, 检索, 规划, 检索, 计算, 规划, 计算, 验证, 总结] print(compute_reward(True, traj_orderly)) print(compute_reward(True, traj_messy))这样的奖励设计会让模型在探索时更倾向于走稳定的技能路径。需要注意权重 lambda_e 不能太大否则模型会为了“熵低”而拒绝必要的技能尝试反而损害最终效果。5.3 课程侧按技能复杂度组织训练第三种做法是把技能熵用在课程学习里。先训练单技能任务让模型掌握基础能力再训练多技能组合任务最后训练需要频繁技能切换的长程任务。每一阶段的技能熵可以作为该阶段模型是否学稳的判断依据如果某个阶段模型在验证集上的技能熵持续下降且稳定就可以进入下一阶段。从工程角度说训练实验的成本远高于评测实验。接入技能熵训练时建议先在小模型、小数据上做几组对比确认收益后再放大规模。不要一上来就在千亿参数模型上做完整 RL 实验那会非常烧钱。6. 本地复现评测实验的验证流程完整复现论文需要作者的官方代码和超参配置。在拿到官方实现之前你可以先做一套简化版实验来验证“技能熵是否有区分度”。下面给出验证流程。6.1 环境准备复现评测实验需要的环境包括操作系统Linux 优先macOS 和 Windows 也可以但麻烦一些。Python 3.10 或更高版本。深度学习推理框架例如 Hugging Face Transformers 或 vLLM。CUDA 环境和 GPU 驱动用于本地推理。如果是 7B 左右的模型权重文件在 fp16 下接近 14GB实际部署还需要叠加推理缓存建议先用 24GB 显存的显卡测试。如果本地显卡不够直接用云端推理 API 也可以评测逻辑不受影响。依赖安装建议用一个独立虚拟环境避免污染已有环境。python -m venv .venv source .venv/bin/activate pip install torch transformers vllm pandas numpy6.2 定义简单的长程推理任务先不要追求复杂 Agent 场景。从一个技能拆解明确的任务开始比如多步数学应用题。任务是先读题、列公式、代入数值、计算中间结果、最后验证。每一步的技能标签可以由规则生成出现“设”“列式”算规划出现“代入”算计算出现“检查”“验证”算验证。6.3 跑一批模型做对比选两个能力差距明显的开源模型保证能跑出差异化结果。每个模型跑 50 到 100 条样本记录完整推理轨迹同时记录最终正确率。然后对每条轨迹计算技能熵、切换次数和转移熵最后一起分析。关键验证点有三个。第一技能熵低的模型最终正确率是否更高。第二技能熵是否能在最终答案正确的情况下区分出过程质量不同的轨迹。第三技能熵和人工审计的轨迹质量评分是否一致。6.4 判断实验结果是否有效如果技能熵和正确率高度相关说明这个指标在你这套任务上是有效的。如果两者完全不相关可以从这几个方向排查技能标签体系是不是定得太粗解析规则是不是漏掉了很多关键步骤样本量是不是太少导致统计不稳定。这里要特别强调技能熵是统计量不要用一两条轨迹下结论。至少要聚合 30 到 50 条轨迹才能看到稳定趋势。7. 资源占用与性能观察长程推理评测比单步问答的成本高一个量级这个要在实验设计时提前估算。首先是 token 消耗。长程推理的单条轨迹产出 token 往往是单步问答的 5 到 20 倍具体取决于任务复杂度和模型是否喜欢长篇思考。评测时建议按条数估算总 token再结合你的 API 或本地推理吞吐量预估时间。其次是显存占用。本地推理时显存主要由模型权重和 KV Cache 决定。上下文越长KV Cache 越大。长程任务天然产生长上下文所以显存压力比普通对话任务大。如果 OOM优先做这几件事减小最大生成长度。使用量化版本模型比如 8bit 或 4bit。降低 batch size。换长上下文优化更好的推理后端。然后是批量评测的并发控制。如果走 API必须做限速和失败重试。如果本地推理建议先跑 5 条样本确认吞吐量和显存稳定再放开批量。最后是性能观察的落地方式。评测脚本里要加好日志每条轨迹记录样本 ID、模型名、轨迹长度、技能标签序列、技能熵、切换次数、最终答案、是否正确。这些字段全部落成表格后续分析和画图都方便。8. 常见问题与排查方法问题现象可能原因排查方式解决方案技能熵和正确率完全无关技能标签体系太粗或解析规则丢步骤抽查 10 条轨迹的人工标签对比解析结果细化技能标签补全解析规则同一条轨迹不同人标注不一致标注规范模糊做标注一致性计算定义更明确的标注标准出示例说明模型输出过长导致 OOM长上下文导致 KV Cache 过大查看推理日志里的显存使用降低 max tokens、量化模型、减小 batch sizeAPI 批量评测频繁报错触发速率限制查看返回的状态码和错误信息加指数退避重试降低并发技能熵区分度低所有轨迹都很高技能标签粒度过细查看技能分布统计合并相近技能减少标签类别训练接入奖励后正确率反而下降熵惩罚权重过大对比有/无奖励塑形的训练曲线调低 lambda_e或只在训练中期启用评测集分数高但线上效果差评测集与训练数据高度相似做数据污染分析查重换新生成任务或定期更新评测集轨迹解析出现大量“未知技能”工具调用类型不在映射表里统计未知技能占比补全映射表增加默认技能9. 最佳实践与使用建议这个方向能不能落地很多时候不取决于指标本身而取决于工程细节。整理几条经验建议。第一技能标签体系要在项目早期定好并且和你的下游任务强相关。不要照搬论文的标签要按你自己的任务类型调整。标签太粗没区分度太细噪声大要先做一轮小样本验证。第二熵是统计指标必须按任务和模型聚合后再看。单条轨迹的熵波动很大直接看没有意义。建议每个模型在每个任务上至少跑 50 条样本。第三评测集要防污染。长程推理基准一旦发布很快会进训练数据。如果你要持续跟踪模型能力建议保留一部分内部新题或者用程序生成新任务。第四训练侧接入技能熵要先做小规模 A/B。奖励塑形可能改变模型的行为分布不一定总是正向。先在小模型、小数据集上验证收益再扩大规模。第五全程做好日志和版本记录。技能标签体系、解析脚本、熵计算版本、模型版本、评测集版本全部要记录下来。研究类项目最怕的就是改了个规则后结果全变但根本说不清哪里变了。第六合规问题不能忽略。如果你用私有数据或版权内容构建评测集要确认授权。模型输出和评测数据如果涉及个人信息匿名化和访问控制都要做好。涉及商业应用时最终效果要人工复核后再上线。10. 总结与下一步Skill Entropy 这个方向最值得关注的是它把评测视角从“答案是否正确”扩展到了“过程是否合理”。对长程推理这种状态空间大、反馈稀疏的场景过程指标有不可替代的价值。如果你想快速验证这个思路第一步不是训练而是评测。先在本地搭一套轨迹记录和技能熵计算流程拿两个不同能力的模型跑一组长程任务看看技能熵和正确率是否相关。这一步成本最低收获最直接。最容易踩的坑是技能标注。标注规范不清晰、解析规则太简单都会让技能熵变成噪声。建议花时间先做 20 条轨迹的标注试点确认一致率后再全量铺开。下一步可以继续往两个方向深入一是把技能熵扩展成更细粒度的过程指标比如结合每一步的工具调用收益来定义“技能有效性”二是把技能熵和强化学习奖励结合起来训练真正具备“技能原生”行为的长程推理模型。论文正式公开后建议优先看它的实验设置和消融结果那才是判断这个方法能否推广的关键。建议收藏备用。后续如果要复现论文的实验可以从这篇的技术路径入手会省不少试错时间。