1. MMLU-Pro-NoMath项目概述
在大型语言模型（LLM）评估领域，MMLU（Massive Multitask Language Understanding）基准测试长期以来都是衡量模型多任务理解能力的黄金标准。但随着模型性能的快速提升，原始MMLU测试集开始出现"天花板效应"——顶级模型得分已经接近饱和，难以区分顶尖模型之间的细微差异。这就是MMLU-Pro诞生的背景，它通过增加选项数量（从4个增至10个）和题目难度，为评估提供了更大的区分空间。
然而，MMLU-Pro中43%的题目涉及多步数学计算，这使得评估过程变得复杂且耗时。更关键的是，数学能力成为了评估的"门槛"——即使模型具备出色的知识和推理能力，如果数学计算不过关，整体得分也会被拉低。这正是我们创建MMLU-Pro-NoMath子集的初衷：保留MMLU-Pro在知识和推理评估上的优势，同时去除数学计算的干扰，打造一个更纯粹、更高效的评估工具。
提示：MMLU-Pro-NoMath并非简单地删除数学相关类别，而是通过逐题筛选，保留了各类别中非数学的优质题目，确保评估的广度和深度不受影响。
2. NoMath子集的构建细节
2.1 题目筛选方法论
构建NoMath子集的核心挑战在于准确识别哪些题目真正依赖多步数学计算。我们采用了以下严谨的筛选流程：
AI辅助分类：使用Claude-3.5-sonnet模型对每个测试项进行三分类：
- "Y"：需要多步计算
- "N"：不需要数学计算
- "S"：仅需简单心算
包容性筛选策略：我们保留了"N"和"S"类题目，因为：
- 心算题目不会显著增加评估复杂度
- 许多"S"类题目仍能有效评估推理能力
- 这样可以最大化保留优质的非数学题目
题目长度优化：原始数据集中约1.5%的题目长度异常（1400-4700字符），这些超长题目会导致：
- 并行评估时内存溢出风险增加
- 评估速度显著下降
- 通过剔除这些异常值，我们确保了评估过程的稳定性和效率
2.2 数据集统计与特性
经过上述处理，我们得到了两个版本的子集：
- MMLU-Pro-NoMath：完整非数学题目集
- MMLU-Pro-NoMath-Sml：平衡各类题目数量的精简版
实测表明，使用Gemma-2-9b模型评估时：
- NoMath完整版耗时约20分钟
- NoMath-Sml版仅需7分钟
这种效率提升使得频繁的模型迭代评估变得可行，特别适合以下场景：
- 开发过程中的快速验证
- 资源有限的研究团队
- 需要大规模并行评估的情况
3. 评估方法深度解析
3.1 Logprobs评估原理
Logprobs（对数概率）评估是一种基于概率而非文本生成的评估方法，其核心流程如下：
概率计算：对于每个选择题选项，计算模型生成该选项的log概率
- 对选项中的每个token取log概率
- 对所有token的log概率求和
- 考虑选项长度的影响（通常进行长度归一化）
答案选择：比较各选项的log概率得分，选择最高分作为模型预测
优势分析：
- 速度：比生成式评估快5-10倍
- 一致性：不受prompt工程影响
- 稳定性：避免了解析生成文本的不确定性
注意：虽然logprobs评估效率高，但在需要展示推理过程（Chain-of-Thought）的题目上，其表现可能不如生成式方法。这也是我们去除多步数学题目的另一个原因——确保评估方法与被评估内容的最佳匹配。
3.2 生成式评估对比
当使用生成式评估（如CoT prompting）时，需要考虑以下额外因素：
- prompt设计：需要精心设计引导模型展示推理过程的prompt
- 结果解析：需要可靠的方法从生成文本中提取最终答案
- 计算成本：生成完整推理过程显著增加计算负担
我们的实验数据显示，同一模型在不同评估方法下的表现差异：
- Gemma-2-9b-it模型：
- Logprobs评估准确率：53.43%
- 生成式CoT评估准确率：59.08%
这种差异印证了评估方法选择的重要性，也说明了为什么需要针对不同评估方法优化测试集。
4. 实践指南：如何运行评估
4.1 使用Eleuther LM-Eval进行Logprobs评估
这是最快捷的评估方式，适合快速迭代：
# 克隆定制版评估工具 git clone https://github.com/sam-paech/lm-evaluation-harness.git -b mmlu-pro-irt cd lm-evaluation-harness # 安装依赖 pip install -e . pip install git+https://github.com/huggingface/transformers.git # 设置Hugging Face token huggingface-cli login --token <mytoken> export HF_HUB_ENABLE_HF_TRANSFER=1 # 运行评估 lm_eval --model hf \ --model_args pretrained=google/gemma-2-9b-it,device_map=auto,max_length=4096,dtype=bfloat16 \ --tasks mmlu-pro-nomath,mmlu-pro-nomath-sml \ --device auto --batch_size auto关键参数说明：
device_map=auto：自动分配可用硬件资源max_length=4096：设置最大上下文长度dtype=bfloat16：使用bfloat16精度平衡精度和内存使用
4.2 使用VLLM进行生成式评估
如果需要CoT评估，推荐使用VLLM方案：
git clone https://github.com/EQ-Bench/MMLU-Pro.git cd MMLU-Pro pip install -r requirements.txt pip install git+https://github.com/vllm-project/vllm.git # 对于Gemma-2兼容性 export VLLM_ATTENTION_BACKEND=FLASHINFER python evaluate_from_local.py \ --save_dir eval_results \ --model "google/gemma-2-9b-it" \ --gpu_util 0.94 \ --dataset sam-paech/mmlu-pro-nomath-sml常见问题处理：
- 内存不足：在
evaluate_from_local.py中为LLM初始化添加enforce_eager=True参数 - 性能优化：调整
--gpu_util参数控制GPU利用率 - 批处理大小：根据可用显存手动设置
--batch_size
4.3 使用llama.cpp的CPU部署方案
对于没有高端GPU的环境，llama.cpp提供了可行的替代方案：
# 编译llama.cpp git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp make LLAMA_CUDA=1 # 启动模型服务（后台运行） screen -S llama_server ./server -m gemma-2-9b-it-Q8_0.gguf --ctx-size 4096 --n-gpu-layers 200 --chat-template gemma2 # 按Ctrl+A, 然后D退出screen会话 # 运行评估 cd ~/MMLU-Pro python evaluate_from_llama.cpp.py --dataset sam-paech/mmlu-pro-nomath-sml性能提示：
- 使用量化模型（如Q8_0）可大幅减少内存占用
--n-gpu-layers参数控制使用GPU加速的层数- 对于纯CPU运行，移除
LLAMA_CUDA=1编译选项
5. 结果解读与应用建议
5.1 典型模型表现对比
我们观察到不同规模模型在三个测试集上的典型表现：
| 模型 | MMLU | MMLU-Pro | MMLU-Pro-NoMath |
|---|---|---|---|
| Qwen-2-72B | 82.3 | 64.4 | 68.1 |
| Gemma-2-9b-it | 62.1 | 48.7 | 53.4 |
| Llama3-8B | 66.2 | 51.3 | 55.8 |
关键发现：
- NoMath子集确实保留了MMLU-Pro相对于MMLU的难度优势
- 数学能力对整体得分的影响约为3-4个百分点
- 模型间的相对排名在不同测试集上保持稳定
5.2 使用场景建议
根据我们的实践经验，推荐以下使用策略：
适合使用NoMath子集的情况：
- 快速模型迭代开发阶段
- 主要关注知识和推理能力评估
- 资源有限或需要频繁评估
- 需要与其他研究进行logprobs评估结果对比
仍需使用完整MMLU-Pro的情况：
- 全面评估模型能力
- 特别关注数学推理能力
- 准备发布最终模型评估结果
- 研究数学能力与其他能力的相关性
6. 常见问题与解决方案
6.1 评估过程中的技术问题
问题1：评估时出现OOM（内存不足）错误
- 解决方案：
- 减小batch_size参数
- 使用更低精度的数据类型（如float16代替bfloat16）
- 尝试使用NoMath-Sml更小的子集
- 对于生成式评估，缩短max_new_tokens
问题2：评估速度远慢于预期
- 检查点：
- 确认使用了适当的硬件加速（如CUDA）
- 监控GPU利用率，调整并行度
- 对于远程服务器，检查网络延迟
- 考虑使用更高效的评估框架（如vLLM）
6.2 结果分析与解释
问题：NoMath得分与完整MMLU-Pro得分的差异意味着什么？
- 如果差异显著（>5%），可能表明：
- 模型数学能力是明显短板
- 模型在非数学题目上表现相对较好
- 评估方法（如logprobs vs CoT）对数学题目影响更大
问题：如何比较不同评估方法的结果？
- 重要原则：
- 同一种评估方法内部比较才有意义
- Logprobs结果通常低于生成式结果
- CoT带来的提升幅度可以反映模型推理能力
在实际项目中，我们发现几个值得分享的经验：
- 对于初步筛选，NoMath+logprobs组合效率最高
- 当模型迭代到后期，应该使用完整评估方案
- 评估结果应该总是注明使用的具体测试集和方法
- 不同规模的模型可能受数学题目影响程度不同
通过MMLU-Pro-NoMath，我们为社区提供了一个既能保留MMLU-Pro评估优势，又更加高效灵活的替代方案。特别是在资源受限的研究场景中，它能够支持更频繁的模型评估，加速研究迭代周期。
