研究提案

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

三、题目生命周期

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

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$ 触发退役评审。

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

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 个变体，避免过度稀释。

五、质量验证层

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 更可信。它扮演的是「数据飞轮的传感器」角色——帮助团队在训练决策的早期就获得反馈，而不是等到大规模部署后才发现问题。

七、与现有工作的对比

7.1 现有工作的局限

MMLU：固定题库，2020 年发布后从未更新核心题目。已被证明大量题目存在于训练数据中；顶级模型在多个子集接近满分，区分度几近为零。

MMLU-Pro：在 MMLU 基础上增加选项数量、提升难度，但仍是静态设计，只是将饱和时间推后而非解决根本问题。

LiveBench：每月更新一批新题，是目前最接近动态评测的工作。但局限在于：① 没有能力维度框架，无法做跨时间的能力级别比较；② 题目来源主要依赖新闻/比赛，领域覆盖不均衡；③ 缺乏系统性的题目健康度管理和退役机制。

BenchBuilder：通过 LLM 自动生成 benchmark 题目，降低了人工成本。但质量验证和污染检测机制薄弱，生成题目的能力覆盖分布难以控制，也没有动态更新的生命周期设计。

7.2 EverBench 的差异化定位

EverBench 不是对上述工作的竞争，而是提供了一个系统性框架，可以整合不同的题目来源（包括 LiveBench 的新题、BenchBuilder 的自动生成）并赋予它们生命周期管理能力。

核心差异化在三点：

维度-题目分离原则：这是架构层面的设计，不是工程实现细节
题目健康度量化：将题目的「好坏」从主观判断变成可计算指标，使退役决策自动化
内部信号价值：作为训练数据飞轮的传感器，这是对外发布的 benchmark 不会主动优化的方向

八、下一步

本提案目前处于 [WIP] 阶段，待补充和验证的方向包括：

能力维度的完整列表（扩展到代码推理、多步规划、安全对齐等领域）
健康度公式的参数校准实验（ $\alpha, \beta, \gamma, \lambda$ 的最优取值）
ArXiv 提取 pipeline 的实现与论文转题质量评估
与 LiveBench 评分的相关性分析（验证 EverBench 的区分度确实优于现有方案）
内部应用：选择一个具体的训练数据实验，用 EverBench 验证信号有效性

EverBench 的名字来自 “Ever-evolving Benchmark”——不是因为它追求永恒，而是因为它承认评测标准和模型能力都在演化，并把这种演化纳入设计本身。