LLM 评测集按任务难度分层的构建方法

我在比较不同 LLM 时，最先遇到的问题往往不是“哪个模型总分更高”，而是总分为什么突然变化：可能只是这一轮抽到了更多短问答，也可能是某个模型刚好擅长常见任务。把所有题目混成一条平均分，难度差异和能力差异就会互相遮住。

更稳的做法是给评测集增加一层“任务难度架构”：先把题目拆成可说明的能力维度，再用约束数量、推理步骤、干扰信息、输出格式等信号建立候选层级，最后用小样本试测校准边界，并按层抽样。这里的 easy、medium、hard 不是模型分数的简单切片，而是可以复盘、可以维护的数据设计。

官方资料地址：https://huggingface.co/docs/evaluate

核心判断：评测集的难度分层服务于解释和比较，不是给每道题贴一个永远不变的“绝对难度”标签。

先看总分为什么会掩盖难度差异

一套题同时包含短事实问答、多步推理、严格格式输出和带干扰信息的长上下文任务时，平均分只告诉你“这一篮子题答对了多少”。它没有告诉你：模型是在基础任务上退步，还是在高约束任务上进步；也没有告诉你两次评测的题型比例是否相同。

因此，分层不是为了制造更好看的图，而是为了把一个不可解释的平均值拆成几个可以追问的切片。每个切片都应有明确的进入理由、样本数量和覆盖范围。

模式：先定义能力轴，再定义难度层

我通常把“能力轴”和“难度层”分成两张表。能力轴回答题目测什么，例如信息抽取、规划、代码修复、数学推理或遵循格式；难度层回答同一能力上的任务压力有多大。这样可以避免把“代码题”直接等同于“难题”，也避免用题目长度代替真正的任务压力。

一个可操作的任务元数据可以先保持小而明确：

{
  "id": "plan-017",
  "task_type": "规划",
  "skills": ["约束满足", "步骤排序"],
  "difficulty_signals": {
    "reasoning_steps": 3,
    "hard_constraints": 2,
    "distractor_count": 1,
    "output_format": "json"
  },
  "split": "candidate"
}

这是严格 JSON，所以不在代码块里加入注释；字段含义紧跟在正文中解释。skills 用于能力覆盖，difficulty_signals 用于候选分层，split 则明确它还没有进入最终测试集。

把难度变成可观察的信号

难度信号最好来自任务本身，而不是来自一次模型运行结果。常用信号包括需要串联的推理步骤、同时满足的硬约束数量、无关信息数量、输入长度、输出格式严格程度、需要调用的工具数量，以及答案是否需要跨段整合。

这些信号不是越多越好。信号太多会让标注人无法解释，权重也容易变成拍脑袋。我的经验是先选三到五个可以在数据审查时复述的信号，再为每个信号设置有限档位。例如把推理步骤分为 1、2–3、4+，把硬约束分为 0、1–2、3+，而不是一开始就做复杂的连续评分。

可以用一个透明的初始规则生成候选层，之后再试测：

def candidate_level(item):
    # 只用任务元数据生成候选层，方便审查每个题目为何被分到这里。
    score = 0
    score += min(item["reasoning_steps"], 4)
    score += min(item["hard_constraints"], 3)
    score += min(item["distractor_count"], 2)
    if item["output_format"] in {"json", "table"}:
        # 结构化输出增加了可检查的约束，但不等于任务一定更难。
        score += 1

    if score 

这个函数的价值不在于得到“正确分数”，而在于提供一条能被人检查的起点。对于开放式创作题、跨语言题或需要外部工具的题目，应该增加独立标签，而不是把所有差异硬塞进一个数字。

用小样本试测校准 easy、medium、hard 的边界

规则分层完成后，不要马上把它当作定稿。每一层先抽取少量、覆盖不同任务类型的题，使用相同的提示词、解码设置和评分规则进行试测。试测的目标不是把模型淘汰，而是找出三类问题：规则认为很难但实际没有区分度的题、规则认为简单但经常失败的题，以及同一层内部差异过大的题。

可以用每层的通过率分布、题目之间的错误重叠和评审意见一起看。单次通过率不应直接定义“题目难度”，因为它还会受到提示词、模型版本和评分器的影响；它更适合用来发现层间是否完全没有差别，或某几道题是否异常。

校准时我会给每道题保留一个简短的边界记录：

• 进入该层的任务压力是什么；
• 试测中出现了哪种错误或意外捷径；
• 是否需要移动到相邻层，或者从最终集剔除；
• 移动后是否破坏了任务类型和语言分布。

按层抽样，而不是只按难度排序取前几道

最终评测集要同时控制难度层和任务分布。假设 easy、medium、hard 各占三分之一，那么每层内部仍要检查规划、抽取、代码、工具调用等任务是否过度集中。否则得到的仍是一套偏科数据，只是多了三个颜色。

一个简单的构建过程是：先按难度层分桶，再按任务类型、语言、长度区间和来源做二次分组，最后使用固定随机种子抽样。固定种子只保证抽样可重现，不代表数据质量已经得到证明；抽样清单还要记录题目 ID 和版本。

from collections import defaultdict
import random

def stratified_sample(rows, per_level, seed=17):
    # 先按难度层分桶，再在每个桶内按 task_type 做稳定抽样。
    buckets = defaultdict(list)
    for row in rows:
        buckets[(row["level"], row["task_type"])].append(row)

    rng = random.Random(seed)
    selected = []
    for key in sorted(buckets):
        candidates = buckets[key]
        rng.shuffle(candidates)
        # 每个组合最多取 per_level，避免单一任务类型占满一层。
        selected.extend(candidates[:per_level])
    return selected

生产环境里还应加上去重、近重复检测和训练集污染检查。它们属于数据治理，不要混在“难度分层公式”里，否则一旦数据来源变化，整个分层逻辑都会难以解释。

反例：用一次模型准确率给题目永久定级

这是最容易落入的陷阱：让某个模型跑一遍，按正确率从高到低切成三段，然后宣布最难的一段就是 hard。这样做把模型能力、提示词、评分器和题目难度混成了一个变量。换模型、换温度或修正评分器后，层级很可能重新洗牌。

更稳的方式是让任务描述和结构信号承担主要解释责任，让模型试测承担校准和发现异常的责任。若确实需要基于通过率调整边界，就记录使用的模型、提示词、评分器、运行时间和版本，并把结果标记为“本轮试测证据”，而不是题目的永久属性。

冻结版本后，评测结果才有比较意义

Hugging Face 的官方文档把 Evaluate 定位为可复用的模型与数据集评测工具，并提供指标、评测器和结果记录相关能力；Datasets 文档则强调数据集的加载、处理、流式读取和共享。无论最终使用哪套工具，工程上都应把评测集本身当成有版本的数据产品来管理。

每次冻结至少记录：题目 ID、能力标签、候选难度信号、最终层级、数据来源、去重状态、评分规则、抽样种子、评测协议和变更原因。若使用 Lighteval 之类的工具执行多后端评测，还要把后端、模型配置和结果包一起保存，避免只剩一个不可复现的分数。

之后新增题目不要直接混入旧版本。先进入 candidate，完成分层和小样本试测，再生成新版本。旧版本保持只读，这样模型 A 与模型 B 的比较才不会因为题目悄悄变了而失去意义。

最后用一张判断清单收尾

如果只能先做一件事，我建议先把“能力轴”和“难度信号”写进题目元数据，再考虑更复杂的评分模型。可解释的三层评测集，通常比一个看似精确但无法复盘的难度分数更有长期价值。

相关问题

评测集难度一定要分成三层吗？

不一定。两层、四层或按任务家族分别分层都可以，关键是每层有足够样本、边界能解释，并且不会为了形式把差异很小的题强行拆开。

能不能只按输入长度划分难度？

不建议。长度只是压力信号之一，短题也可能包含多重约束，长题也可能只是背景信息较多。应结合推理步骤、约束、干扰和输出要求。

模型通过率可以用来做什么？

它适合发现异常题和校准层间差异，不适合单独成为题目的永久难度标签。使用时应同时记录模型、提示词、评分器和配置。