研究提案

[WIP] [v2] EverBench：能力维度稳定的动态评测体系

一个以「能力维度不变、题目持续更新」为核心设计原则的 LLM 评测框架，系统性解决 benchmark 污染与饱和问题，并作为训练数据改动效果的早期信号层。

2026年3月30日 benchmark LLM评测动态评测能力维度数据工程科研推理

EverBench：能力维度稳定的动态评测体系

题目是消耗品，能力维度才是标准。

一、定位与问题

1.1 我们在做什么

EverBench 是一个「能力维度稳定、题目持续动态更新」的 LLM 评测体系。

它不是一个静态题库，也不是一个简单换题的爬虫。它的核心设计哲学是：将评测标准（能力维度）和评测载体（题目）彻底分离。能力维度作为长期稳定的坐标轴，题目则是可被消费、替换、淘汰的实例。每一道题都只是某个能力维度的一次具体采样，题目退役不代表能力被放弃，而是用新的采样替代旧的采样。

1.2 两个根本问题

当前主流 benchmark 面临两个系统性失效机制，且二者相互加速：

① 污染（Contamination）

题目一旦公开，就会进入预训练语料。无论是爬虫直接抓取，还是社区讨论间接传播，最终都会造成模型”见过题”而非”真的会做”。MMLU 的题目在 Common Crawl 中大量出现已是共识；LiveBench 虽然每月更新题目，但其更新节奏（月级）在快速迭代的训练周期面前仍然脆弱。

② 饱和（Saturation）

当足够多的模型在某个维度上达到 90%+ 通过率，这个维度就丧失了区分度。MMLU 的高中数学、常识推理等子集已经对顶级模型几乎没有区分力。饱和不是能力真的被掌握——更可能是污染的滞后结果。

EverBench 的回应是：题目本身是消耗品。当一道题失去区分度（无论因为污染还是饱和），它应该被自动退役，由新题接替。而背后的能力维度坐标轴始终不变，确保跨时间的可比性。

1.3 与现有框架的一句话区别

框架	核心问题
MMLU	静态题库，污染严重，饱和加速
LiveBench	只更新题，没有能力维度框架，横向比较困难
MMLU-Pro	加大难度，但仍静态，治标不治本
BenchBuilder	自动生成题目，但质量验证薄弱，无生命周期管理
EverBench	维度稳定 + 题目动态 + 生命周期管理 + 污染检测闭环

二、能力维度设计

2.1 设计原则

测推理过程，不测知识点：每题考察的是模型能否在给定信息下完成推断，而非是否记住了某个事实
每题绑定 skill_id：所有题目必须标注对应的能力维度 ID，作为评分归因和生命周期管理的基础
维度粒度适中：过粗（如”数学推理”）区分度低，过细（如”二阶偏微分方程”）覆盖度不足；以「可被一类操作描述」为粒度标准

2.2 能力维度列表（数据工程 + 科研推理示例）

数据工程能力维度

维度 ID	能力描述	评测形式
`DE-01`	SQL 多表关联查询推理	给定 schema + 业务问题，要求写出正确 SQL；含子查询、窗口函数
`DE-02`	数据 Pipeline 故障根因分析	给定 DAG + 运行日志 + 异常输出，推断哪个节点出错及原因
`DE-03`	Schema 演化兼容性判断	给定旧 schema + 变更描述，判断是否破坏下游消费者；选择题 + 理由
`DE-04`	数据质量规则推导	给定一批脏数据样本，推导出最可能的隐含业务约束规则
`DE-05`	分布式存储读写语义	给定并发操作序列，判断最终状态；涉及 CAP、幂等性、事务隔离
`DE-06`	指标口径歧义消解	给定两份指标定义 + 计算结果差异，定位口径分歧点

科研推理能力维度

维度 ID	能力描述	评测形式
`SR-01`	实验设计缺陷识别	给定论文实验设计，识别 confound、无效对照、数据泄露等问题
`SR-02`	方法论声明可证伪性判断	给定一个方法声明，判断是否可被实验证伪，并说明验证方案
`SR-03`	结论与数据一致性核查	给定图表数据 + 作者结论，判断结论是否被数据支撑
`SR-04`	跨论文方法比较推理	给定两篇论文的方法描述，判断在特定条件下哪种更优及原因
`SR-05`	消融实验结果解读	给定消融表格，推断每个组件的贡献方向和量级
`SR-06`	统计显著性误读识别	给定统计结果 + 作者解读，判断是否存在 p-hacking 或过度声明

2.3 维度扩展路径

EverBench 的维度集合本身也应演化，但变化频率远低于题目（以季度为单位）。新增维度需满足：① 有足够的题目来源，② 有明确的评分标准，③ 与现有维度无重叠。废弃维度需在历史评分中保留快照。

🔄 [v2 改进]

能力维度的分类学依据（补充）

原方案直接列出 12 条能力维度，但未说明其来源。这是整个体系的基础，缺乏依据会让外部审阅者质疑维度设计的合理性。以下补充维度设计依据：

参考的已有分类体系：

MMLU 学科分类（57 个学科）：涵盖 STEM、人文、社科等，用于检查 EverBench 维度是否与常见学科能力对齐

BIG-Bench 能力分类（200+ 任务）：提供细粒度能力标签，尤其是推理类任务的细分（类比推理、逻辑推理、因果推理等）

AgentBench 任务分类：针对 Agent 场景的能力划分，对 DE 系列维度设计有参考价值

维度正交性验证（必须执行）：

取 BIG-Bench 中已有的题目样本，让评标员将每题同时映射到 EverBench 的多个维度

计算维度间的共现相关系数（Jaccard similarity），目标：任意两个维度的相关系数 < 0.3

若两个维度相关系数 > 0.3，说明它们在测同一件事，应合并或重新定义边界

当前 12 个维度中，DE-04（数据质量规则推导）与 DE-02（Pipeline 故障根因分析）存在潜在重叠，需要验证

维度完备性检验（覆盖率测试）：

取 MMLU、BIG-Bench Hard、MATH、HumanEval 各随机抽取 100 题

尝试将每题归类到 EverBench 的某个维度

目标：归类覆盖率 > 80%（20% 可以是「不在 EverBench 覆盖范围内」）

若某类题目集中出现在无法归类的 20% 中，说明需要新增维度

各维度的现有 benchmark 支撑情况：

维度 ID 现有 Benchmark 支撑备注
DE-01 Spider、BIRD（SQL）有充分先验
DE-02 无直接对应新提出，需从头构建题目
DE-03 无直接对应新提出
DE-04 部分 BIRD 子任务弱支撑
DE-05 Jepsen 测试集（非公开）工业来源，需重新构造
DE-06 无直接对应新提出，风险最高
SR-01 MLRC（机器学习可重复性）弱支撑
SR-02 ~ SR-06 无直接对应均为新提出维度

这张表的意义在于：有现有 benchmark 支撑的维度可以快速起步；无支撑的新维度需要额外的题目构建投入，是执行风险最高的部分。

维度 ID	现有 Benchmark 支撑	备注
`DE-01`	Spider、BIRD（SQL）	有充分先验
`DE-02`	无直接对应	新提出，需从头构建题目
`DE-03`	无直接对应	新提出
`DE-04`	部分 BIRD 子任务	弱支撑
`DE-05`	Jepsen 测试集（非公开）	工业来源，需重新构造
`DE-06`	无直接对应	新提出，风险最高
`SR-01`	MLRC（机器学习可重复性）	弱支撑
`SR-02` ~ `SR-06`	无直接对应	均为新提出维度

三、题目生命周期

每道题从生成到退役，经历完整的生命周期管理。

3.1 四个阶段

[候选] → [活跃] → [老化] → [退役]
  ↑                           ↓
  └─────── 新题生成 ←──────────┘

候选（Candidate）：通过质量验证但尚未正式纳入评测集，处于沙盒观察期（通常 2-4 周，收集早期通过率数据）
活跃（Active）：正式纳入评测，参与所有模型评分
老化（Aging）：通过率超过阈值或健康度下降到警戒线，进入监控期，不再纳入新的评测批次
退役（Retired）：从评测集中移除，归档至历史库，保留元数据供分析

3.2 退役触发条件

满足以下任一条件即触发退役流程：

饱和退役：最近 30 天内，参评模型的平均通过率 > 90%，且 top-5 与 bottom-5 模型通过率差距 < 10%（区分度丧失）
污染退役：污染检测模块报告该题与已知公开数据集的语义相似度 > 0.85
覆盖替代：同一 skill_id 下存在更优题目（健康度更高），且当前题目健康度低于维度平均值 20% 以上
手动退役：人工审核发现题目存在歧义、错误答案或不当内容

3.3 题目健康度公式

每道活跃题目每周计算一次健康度分数 $H$ ：

H = \alpha \cdot D + \beta \cdot F + \gamma \cdot C

其中：

$D$ （Discriminability，区分度）： $D = \frac{\text{pass\_rate}_{p75} - \text{pass\_rate}_{p25}}{\text{pass\_rate}_{p75} + \epsilon}$ 衡量强弱模型在这道题上的分差。 $D$ 越高说明题目仍能区分模型能力。
$F$ （Freshness，新鲜度）： $F = e^{-\lambda \cdot t}$ $t$ 为题目发布天数， $\lambda$ 为衰减系数（建议 $\lambda = 0.005$ ，约 140 天后降至 50%）。用于对抗慢性污染积累。
$C$ （Coverage，覆盖度）： $C = 1 - \max_{j \neq i} \text{sim}(\text{embedding}_i, \text{embedding}_j)$ 衡量该题与同一 skill_id 内其他题的语义差异度。防止题目堆叠在能力空间的同一角落。

推荐权重： $\alpha = 0.5, \beta = 0.3, \gamma = 0.2$ ，可按维度调整。 $H < 0.4$ 进入老化阶段， $H < 0.25$ 触发退役评审。

🔄 [v2 改进]

H 公式权重确定方法（补充）

原方案直接给出 α=0.5, β=0.3, γ=0.2 作为推荐权重，但未说明这三个值是如何得出的。权重确定方法是整个健康度评估能否客观运作的关键——如果权重是拍脑袋的，H 值就是伪精确。以下给出两种确定权重的具体方法：

方法 A：专家调查（Expert Survey）

收集 10-20 位评测领域专家（需同时理解 benchmark 设计和 LLM 评估）

设计成对比较问卷：「在其他条件相同时，区分度高 vs. 新鲜度高，哪道题更有价值？」

用 Analytic Hierarchy Process（AHP）将成对比较转化为权重向量

检验一致性比率（CR < 0.1 则接受结果）

方法 B：数据驱动（Data-Driven Calibration）

选取公认的高质量 benchmark（如 MATH、HumanEval 的出题规范）

分析这些 benchmark 中题目的 D/F/C 分布特征（高质量题的 D/F/C 分布是什么）

用逻辑回归：以「题目是否被该 benchmark 主动保留」作为标签，以 D/F/C 作为特征，反推权重

建议初始值（供参考，需验证）：

α = 0.4（区分度最重要：没有区分度的题没有价值）

β = 0.35（新鲜度其次：防止慢性污染积累）

γ = 0.25（覆盖度第三：防止重复，但优先级低于前两者）

注意：原方案推荐 α=0.5, β=0.3, γ=0.2，与上述建议初始值略有差异。两组值的差异主要在新鲜度和覆盖度的权衡——建议通过方法 A 或 B 验证后再确定。

权重维护机制：

每季度回顾一次权重的合理性：检查过去一个季度内，H 值高的题目是否确实对模型区分度贡献更大

如果发现 H 值高的题目大量集中在某一类（例如全是超长文本题），说明权重存在偏差，需要调整

建议将权重版本化管理（v1.0、v1.1 等），以便追溯历史评分的权重背景

四、新题生成——三条来源

4.1 从失败案例生成变体

核心洞察：模型失败的地方，正是能力短板所在，也是最有价值的出题区域。

五步流程：

收集失败：定期扫描评测日志，提取所有模型失败记录（pass_rate < 40% 或存在明显推理错误的题目）
分类根因：对失败原因进行标注——是推理跳步、概念混淆、边界条件遗漏，还是指令理解偏差？每类根因对应不同的变体生成策略
生成变体：以原题的推理结构（骨架）为模板，变换表面场景、数值、实体名称，或针对根因刻意强化：例如根因是”边界条件”则新题专门构造临界情况
质量过滤：变体题进入自动化 QA 流程（见第五部分），过滤掉与原题语义重叠过高（ $C < 0.3$ ）或难度异常的题目
发布候选：通过过滤的变体题进入候选池，标注 source: failure_variant，保留原题关联 ID 用于溯源分析

4.2 从 ArXiv 新论文提取

核心洞察：最新论文的方法论声明天然具有时效性，不太可能出现在模型训练数据中。

流程：

每周扫描：监控 cs.AI、cs.LG、cs.DB、stat.ML 等分类下的新 paper，过滤摘要中含有可操作方法声明的论文
提取方法论声明：使用 LLM 从论文中提取结构化的方法声明，格式为 <条件, 操作, 预期结果>，例如「在 long-tail 分布数据上使用 focal loss 相比 CE loss 在 F1 上提升约 X%」
转化为推理题：将方法论声明转化为多选题或判断题，要求模型基于推理（而非记忆）选择正确答案——通常设计为「给定论文的实验前提，判断以下哪个结论与方法论一致」
用原文验证：用论文原文作为 ground truth，确保答案可被客观核验；同时这道题的答案在论文公开前不存在于任何训练数据，天然抗污染
标注 skill_id：根据论文主题自动映射到相关 skill 维度，并进入候选池

4.3 从现有题生成包装变体

核心洞察：题目 = 能力骨架（skill_id）+ 表面包装。换包装保骨架，可以批量扩充题库而不稀释能力覆盖。

分层模型：

┌─────────────────────────────────────┐
│  表面包装（Surface Wrapper）         │
│  - 场景名称（电商/医疗/金融）         │
│  - 实体名称（表名/字段名/公司名）     │
│  - 数值参数（行数/阈值/时间跨度）     │
├─────────────────────────────────────┤
│  能力骨架（Skill Skeleton）          │
│  - 推理步骤结构（固定）              │
│  - 关键约束和边界条件（固定）         │
│  - skill_id 绑定（固定）             │
└─────────────────────────────────────┘

生成时，骨架保持不变，表面包装从预定义的包装库中采样。相同骨架的变体之间设置最小语义距离阈值（ $C > 0.5$ ），防止包装变体过于雷同。每个骨架最多生成 3-5 个变体，避免过度稀释。

🔄 [v2 改进]

防止题目来源和被测对象的循环污染（补充）

原方案 4.2 中，从 arXiv 论文提取题目时声称「天然抗污染」，但这个结论过于乐观：大量 LLM 的训练数据截止日期晚于论文发布日期，模型可能已见过论文内容。用模型读过的论文出题，测的是「记忆」而非「推理」。

污染路径分析：

arXiv 论文在发布后数周至数月内会被各类爬虫抓取，进入训练语料

GPT-4 系列的训练截止日期约为 2023 年 4 月，Claude 3 系列约为 2023 年 8 月

如果论文发布于 2023 年 3 月，它很可能已经进入多数强模型的训练数据

防污染机制（新增）：

1. 题目发布延迟（Publication Delay Gate）

设置规则：论文在 arXiv 发布后，需等待至少 6 个月才能用于出题

原理：确保题目来源的论文发布时间晚于大多数被测模型的训练截止日期

代价：题目有一定的时间滞后性（6 个月），但对科研推理类题目影响不大

对于实时性要求高的场景（如评测最新 GPT-5），需要动态调整延迟时间

2. 记忆检测（Memory Probe）

每道候选题发布前，用 5-8 个已知的强模型（如 GPT-4、Claude 3.5、Gemini Ultra）进行预评测

判断标准：如果 >80% 的模型在第一次尝试时直接答对（无需推理过程），说明这道题很可能考的是记忆而非推理

处理策略：

通过率 >80%：大概率是记忆题，降低健康度初始值（F 初始值 × 0.5）或直接淘汰

通过率 60%-80%：灰色区域，进入候选期观察，若持续下降则退役

通过率 <60%：认为题目具有推理价值，正常发布

注意：「所有模型都答对」≠「题目太简单」，也可能是推理极清晰；需要同时检查模型的推理过程，是否有共同的「中间步骤」（有中间步骤 = 真推理，直接给答案 = 记忆）

3. 题目多样化来源（增加非 arXiv 来源占比）

arXiv 论文来源的题目应控制在总题库的 40% 以内

其余 60% 来自「失败案例变体」（4.1）和「包装变体」（4.3）——这两类来源本身就是内生生成，污染风险更低

五、质量验证层

5.1 发布前验证流程

所有候选题在正式纳入活跃池前，经过以下三道关：

格式合规检查：题目格式、选项数量、答案唯一性、skill_id 标注完整性
污染检测（见 5.2）
难度校准（见 5.3）

三关全部通过后，进入候选期（Candidate 阶段）。候选期结束后，若早期通过率在 20%-85% 之间（有合理区分度），正式激活。

5.2 污染检测方案

双轨检测：

语义相似度检测：将新题文本 embedding 与以下数据集做相似度扫描：MMLU、HellaSwag、BIG-Bench Hard、HumanEval、GSM8K 等主流公开集，以及历史退役题库。相似度阈值 0.85，超过则拒绝或要求人工审核。
短语精确匹配：提取题目中的关键短语，在 Common Crawl 样本和 GitHub 代码库中检索。命中率超过阈值（>3 处精确匹配）视为潜在污染。

持续监控：已活跃的题目每两周重新跑一次污染检测，以捕捉”题目公开后被爬入训练数据”的滞后污染。

5.3 难度校准

新题发布前，用 5-8 个覆盖能力档次的参考模型（从弱到强）进行预评测，生成通过率分布。

目标分布：均值通过率 40%-70%，标准差 > 15%（保证区分力）
异常处理：均值 > 85% → 题目太简单，退回修改；均值 < 20% → 可能题目有问题或边界条件过难，人工复核

六、横向比较与内部应用价值

6.1 题目变化下的横向比较

题目动态更新的最大挑战是：如何保证不同时间点的评分可比？

EverBench 的解法是维度级评分卡（Skill Scorecard），而非总分。每个模型在每个 skill_id 上维护一个滚动评分（基于最近 N 道活跃题的通过率加权均值），总分由各维度评分聚合得出。

由于维度坐标轴不变，不同时间点的维度评分是可比的；题目的换新只影响该维度评分的计算样本，不影响维度定义本身。模型 A 在 2025Q1 和 2025Q3 的 SR-03（结论数据一致性）评分，指向的是同一个能力维度，即使题目已完全不同。

6.2 作为训练数据改动的早期信号

这是 EverBench 的核心内部应用价值，也是它与通用 benchmark 最大的差异点。

场景：训练团队新加入了一批数据工程领域的高质量标注数据（如 SQL 分析场景）。评估这批数据是否真正提升了相关能力，传统方式需要跑完整的后训练流程，周期长、成本高。

EverBench 的价值：

将新数据映射到相关 skill_id（如 DE-01、DE-02）
在数据加入前后各跑一次对应维度的评测
如果维度评分有显著提升，说明数据有效；如果无变化或下降，需要分析原因

由于题目是动态更新的、刻意抗污染的，这个信号比传统静态 benchmark 更可信。它扮演的是「数据飞轮的传感器」角色——帮助团队在训练决策的早期就获得反馈，而不是等到大规模部署后才发现问题。

🔄 [v2 改进]

评估闭环：如何验证 EverBench 本身作为信号层的有效性

原方案描述了 EverBench 的信号价值，但没有说明如何验证「EverBench 的信号确实有效」——即 EverBench 评分变化与模型实际能力提升之间的相关性如何证明。

验证方案（三层递进）：

层 1：与现有 benchmark 的相关性验证（快速验证，2 周内）

选取 10 个已有准确排名的模型（GPT-4、Claude 3.5、Llama 3.1 等，业界公认排名）

跑 EverBench 的所有维度，计算 EverBench 排名与已知排名的 Spearman 相关系数

目标：相关系数 > 0.8（否则说明 EverBench 测的东西与业界认知的能力排名不一致）

诊断：若相关系数低，逐维度分析是哪个维度导致排名偏差，针对性调整题目质量

层 2：训练实验的因果验证（核心验证，1-2 个月）

设计受控实验：基础模型 + 加入 DE-01 相关训练数据 → 在 DE-01 维度上应有显著提升

正向验证：加了相关数据，对应维度评分提升 ≥ 5 个百分点（说明信号灵敏）

负向验证：加了无关数据（如故事写作数据），对应维度评分应保持稳定（说明信号不虚报）

若两个验证都通过，才能称 EverBench 为「有效的训练信号传感器」

层 3：与下游任务的因果链验证（长期验证）

选定 2-3 个真实下游任务（如代码生成中的 SQL 准确率、科研助手的文献分析准确率）

跟踪 EverBench 维度评分变化与下游任务性能变化的时序相关性

如果 EverBench 评分提前 2-4 周预示了下游任务的性能变化，说明它真的是早期信号