MMLU-Pro-NoMath：高效评估语言模型知识与推理能力的新基准

1. MMLU-Pro-NoMath项目概述在大型语言模型LLM评估领域MMLUMassive 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 githttps://github.com/huggingface/transformers.git # 设置Hugging Face token huggingface-cli login --token mytoken export HF_HUB_ENABLE_HF_TRANSFER1 # 运行评估 lm_eval --model hf \ --model_args pretrainedgoogle/gemma-2-9b-it,device_mapauto,max_length4096,dtypebfloat16 \ --tasks mmlu-pro-nomath,mmlu-pro-nomath-sml \ --device auto --batch_size auto关键参数说明device_mapauto自动分配可用硬件资源max_length4096设置最大上下文长度dtypebfloat16使用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 githttps://github.com/vllm-project/vllm.git # 对于Gemma-2兼容性 export VLLM_ATTENTION_BACKENDFLASHINFER 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_eagerTrue参数性能优化调整--gpu_util参数控制GPU利用率批处理大小根据可用显存手动设置--batch_size4.3 使用llama.cpp的CPU部署方案对于没有高端GPU的环境llama.cpp提供了可行的替代方案# 编译llama.cpp git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp make LLAMA_CUDA1 # 启动模型服务后台运行 screen -S llama_server ./server -m gemma-2-9b-it-Q8_0.gguf --ctx-size 4096 --n-gpu-layers 200 --chat-template gemma2 # 按CtrlA, 然后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_CUDA1编译选项5. 结果解读与应用建议5.1 典型模型表现对比我们观察到不同规模模型在三个测试集上的典型表现模型MMLUMMLU-ProMMLU-Pro-NoMathQwen-2-72B82.364.468.1Gemma-2-9b-it62.148.753.4Llama3-8B66.251.355.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利用率调整并行度对于远程服务器检查网络延迟考虑使用更高效的评估框架如vLLM6.2 结果分析与解释问题NoMath得分与完整MMLU-Pro得分的差异意味着什么如果差异显著5%可能表明模型数学能力是明显短板模型在非数学题目上表现相对较好评估方法如logprobs vs CoT对数学题目影响更大问题如何比较不同评估方法的结果重要原则同一种评估方法内部比较才有意义Logprobs结果通常低于生成式结果CoT带来的提升幅度可以反映模型推理能力在实际项目中我们发现几个值得分享的经验对于初步筛选NoMathlogprobs组合效率最高当模型迭代到后期应该使用完整评估方案评估结果应该总是注明使用的具体测试集和方法不同规模的模型可能受数学题目影响程度不同通过MMLU-Pro-NoMath我们为社区提供了一个既能保留MMLU-Pro评估优势又更加高效灵活的替代方案。特别是在资源受限的研究场景中它能够支持更频繁的模型评估加速研究迭代周期。