lm-evaluation-harness评估结果与Open LLM Leaderboard差异解析
在评估大型语言模型性能时,研究人员经常使用lm-evaluation-harness工具包进行本地测试,但有时会发现本地评估结果与Open LLM Leaderboard公布的分数存在显著差异。本文将深入分析这种差异产生的原因,并提供正确的评估方法。
评估结果差异的核心原因
本地使用lm-evaluation-harness评估时,默认输出的是原始分数(raw score),而Open LLM Leaderboard第二版默认显示的是经过标准化处理后的分数(normalized score)。这是造成表面差异的主要原因。
标准化处理是Open LLM Leaderboard第二版引入的新特性,目的是使不同测试集之间的分数更具可比性。标准化过程会参考基线模型(如GPT-4)的表现,将原始分数转换为相对值。
正确比较评估结果的方法
当需要将本地评估结果与Open LLM Leaderboard进行对比时,应该:
- 在本地评估时使用
leaderboard_gpqa等特定任务名称,这些任务与Leaderboard的测试集对应 - 将本地结果与Leaderboard上的"raw score"而非默认显示的标准分进行比较
- 注意评估参数的设置,包括batch size、硬件环境等都可能影响最终结果
评估中的其他注意事项
除了分数类型的差异外,评估过程中还需注意以下因素:
-
评估版本一致性:不同版本的lm-evaluation-harness可能产生不同结果,特别是对于Leaderboard第一版的复现,需要使用特定commit版本的评估工具
-
评估稳定性:某些测试集(如HellaSwag)在小样本评估时(
--limit参数值较小)结果波动较大,建议使用完整测试集进行评估 -
模型加载配置:确保本地评估时的模型配置(如数据类型dtype)与预期一致,这会影响模型性能表现
-
评估任务选择:不同子任务(gpqa_main/gpqa_extended等)的难度和评分标准不同,需要明确比较的是哪个具体任务
实际评估案例解析
以Phi-3-mini-4k模型为例,本地评估得到的gpqa准确率约为32.97%,这与Leaderboard上该模型的gpqa raw score接近,但与标准化后显示的9.28%有显著差异。这种差异正是由于评分标准不同造成的,而非评估方法错误。
同样现象也出现在Qwen2-7B等模型上,本地评估结果与官方报告接近,但与Leaderboard标准化分数存在差距。这进一步验证了比较raw score的重要性。
结论
正确理解和使用评估工具对于LLM性能评估至关重要。研究人员应当:
- 明确区分原始分数和标准化分数
- 确保评估环境和参数设置的一致性
- 关注具体任务而非仅看综合得分
- 对于有疑问的结果,可以交叉验证不同评估方式
通过遵循这些原则,可以更准确地评估模型性能,并有效比较不同来源的评估结果。
atomcodeClaude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get StartedRust0191
cann-learning-hubCANN 学习中心仓,支持在线互动运行、边学边练,提供教程、示例与优化方案,一站式助力昇腾开发者快速上手。Jupyter Notebook0118
Step-3.7-FlashStep-3.7-Flash是一个拥有 1980 亿参数的稀疏混合专家(MoE)视觉语言模型,由 1960 亿参数的语言主干网络和 18 亿参数的视觉编码器组合而成,具备原生图像理解能力。Python00
JoyAI-EchoJoyAI-Echo,这是一个独立的、仅用于推理的版本,旨在实现分钟级多镜头音视频生成。它采用了经过蒸馏的DMD生成器、配对的跨模态记忆以及故事级别的一致性。其性能的核心在于,一个跨模态视听记忆库能够在长达五分钟的视频中保持角色外观和语音音色的一致性。同时,一个训练后处理流程将基于记忆的强化学习与分布匹配蒸馏相结合,实现了7.5倍的速度提升,显著增强了视觉质量和对齐效果。00
fun-rec推荐系统入门教程,在线阅读地址:https://datawhalechina.github.io/fun-rec/Python03
so-large-lm大模型基础: 一文了解大模型基础知识01