摘要

评估和比较大语言模型 (LLMs) 是一项艰巨的任务。我们 RLHF 团队在一年前就意识到了这一点,当时他们试图复现和比较多个已发布模型的结果。这几乎是不可能完成的任务:论文或营销发布中的得分缺乏可复现的代码,有时令人怀疑,大多数情况下只是通过优化的提示或评估设置来尽量提升模型表现。因此,他们决定创建一个地方,在完全相同的设置(同样的问题,按相同的顺序提问等)下评估参考模型,从而收集完全可复现和可比较的结果;Open LLM Leaderboard 就这样的背景下发布啦!

在一系列高调的模型发布后,它成为了机器学习社区及更广泛领域内的广泛资源,过去 10 个月中有超过 200 万的独立访问者。

每月约有 30 万社区成员通过提交和讨论使用这个平台,通常是为了:

  • 寻找最先进的开源发布,因为排行榜提供了可复现的得分,区分了营销炒作与实际进展。
  • 评估他们的工作,无论是预训练还是微调,公开比较方法并与最佳现有模型进行比较,并获得公众认可。

然而,随着排行榜的成功以及模型性能的不断提升,也带来了挑战。经过一年多的激烈使用和大量社区反馈后,我们认为是时候进行升级了!因此,我们推出了 Open LLM Leaderboard v2!

以下是我们认为需要新排行榜的原因

为什么需要更具挑战性的排行榜

在过去的一年里,我们使用的基准测试已经被过度使用和饱和:

  1. 它们对模型来说变得太容易。例如,模型现在在 HellaSwag、MMLU 和 ARC 上达到了人类基准性能,这种现象被称为饱和。
  2. 一些较新的模型也表现出污染的迹象。这意味着这些模型可能在基准数据或与基准数据非常相似的数据上进行训练。因此,一些得分不再反映模型的一般性能,而是开始在某些评估数据集上过拟合,而不是反映所测试任务的一般性能。特别是 GSM8K 和 TruthfulQA,已包含在一些指令微调集中。
  3. 一些基准测试包含错误。例如,最近多个研究团队对 MMLU 进行了深入调查(见 MMLU-ReduxMMLU-Pro),发现了其响应中的错误并提出了新版本。另一个例子是 GSM8K 使用了特定的生成结束标记(:),这不公平地降低了许多冗长模型的表现。

因此,我们决定完全更换 Open LLM Leaderboard v2 的评估!

重新选择我们的评估标准

我们开始寻找具有未污染、高质量数据集,使用可靠指标并测量模型关键能力的新基准测试。

我们决定涵盖以下一般任务:知识测试()、短期和长期上下文推理()、复杂数学能力以及与人类偏好高度相关的任务(),如指令遵循。

我们使用六个基准测试来涵盖这些任务。让我们简要介绍它们:

MMLU-Pro(大规模多任务语言理解 - 专业版,论文)。MMLU-Pro 是 MMLU 数据集的改进版本。MMLU 一直是多选知识数据集的参考。然而,最近的研究表明它既包含噪音(一些问题无法回答),又太容易(通过模型能力的进化和污染的增加)。MMLU-Pro 向模型提供十个选择而不是四个,要求在更多问题上进行推理,并经过专家审查以减少噪音量。它比原版质量更高且更难。

GPQA(研究生级别的谷歌问答基准,论文)。GPQA 是一个极其困难的知识数据集,其中问题由领域专家(生物学、物理学、化学等领域的博士水平)设计,使得外行人难以回答但专家相对容易。问题经过多轮验证,以确保难度和准确性。数据集也只能通过网关机制访问,这减少了污染风险。(这也是为什么我们不提供来自此数据集的纯文本示例的原因,正如论文作者要求的那样)。

MuSR(多步软推理,论文)。MuSR 是一个非常有趣的新数据集,由算法生成的复杂问题组成,长度约为1000字。问题包括谋杀之谜、物体放置问题或团队分配优化。为了解决这些问题,模型必须结合推理和非常长的上下文解析。很少有模型得分高于随机水平。

MATH(数学启发式测试,5级子集,论文)。MATH 是一个由多个来源收集的高中级别竞赛问题的汇编,使用 Latex 一致地格式化方程和 Asymptote 格式化图形。生成的答案必须严格遵循特定的输出格式。我们只保留最难的问题。

IFEval(指令遵循评估,论文)。IFEval 是一个相当有趣的数据集,测试模型清晰遵循明确指令的能力,例如“包括关键词 x”或“使用格式 y”。模型被测试是否能够严格遵循格式指令,而不是实际生成的内容,从而可以使用严格的指标。

BBH(大基准测试难题,论文)。BBH 是 BigBench 数据集中 23 个具有挑战性的任务的子集,其中 1)使用客观指标,2)难度高,测量为语言模型未能超越人类基线,3)包含足够多的样本以具有统计显著性。它们包含多步算术和算法推理(理解布尔表达式、几何图形的 SVG 等)、语言理解(讽刺检测、名称消歧等)和一些世界知识。BBH 的表现平均与人类偏好高度相关。我们期望这个数据集能够提供对特定能力的有趣见解,吸引人们的兴趣。

为什么我们选择这些子集?

总的来说,我们的选择标准是:

  1. 评估质量:
  • 数据集的人工审查:MMLU-Pro 和 GPQA
  • 学术界和开源社区的广泛使用:BBH、IFEval、MATH
  1. 指标的可靠性和公平性:
  • 多选评估在模型之间通常是公平的。
  • 生成性评估应严格限制格式(如 MATH),或使用非常明确的指标(如 IFEval)或后处理(如 BBH)来提取正确答案。
  1. 模型污染的一般缺失:
  • 网关机制:GPQA
  • “年轻”:MuSR、MMLU-Pro
  1. 测量社区感兴趣的模型技能:
  • 与人类偏好相关:BBH、IFEval
  • 评估我们感兴趣的特定能力:MATH、MuSR

选择新的基准测试并不是全部。我们还对排行榜进行了几项其他改进,现在我们将简要介绍。

报告更公平的排名平均值:使用标准化分数

我们决定改变模型的最终得分。我们没有将每个基准输出得分相加,而是将这些得分标准化在随机基线(0 分)和最大可能得分(100 分)之间。然后我们平均所有标准化分数以获得最终平均得分并计算最终排名。例如,在一个每个问题包含两个选择的基准测试中,随机基线将获得 50 分(满分 100 分)。如果使用随机数生成器,您可能会在此评估中获得约 50 分。这意味着得分始终在 50(如果基准不是对抗性的最低合理得分)和 100 之间。因此,我们更改范围,使得 50 的原始分数为 0 的标准化分数。这对生成性评估如 IFEval 或 MATH 没有影响。

这个变化比看起来更重要,因为它可以看作是改变了每个基准在最终平均分中的权重。

在上图中,我们绘制了评估的平均得分,左侧为标准化得分,右侧为原始得分。如果看右侧,您会得出 MATH 5 级和 MMLU-Pro 是最难的基准(原始平均值最低)。然而,我们的两个最难评估实际上是 MATH 5 级和 GPQA,它们难得多(博士水平的问题!)——今天的大多数模型在它上面接近随机性能,因此在未标准化得分和标准化得分之间存在巨大差异,随机数基线得分为零分!

因此,这个变化也影响了整体模型排名。假设我们有两个非常难的评估,一个生成性和一个多选题,有两个选项样本。模型 A 在生成性评估中得 0 分,在多选题中得 52 分,模型 B 在生成性评估中得 10 分,在多选题中得 40 分。看原始平均值,您可能会得出模型 A 更好的结论,平均得分为 26,而模型 B 的平均得分为 25。然而,对于多选题基准,他们实际上都同样差(!):52 几乎是多选题评估中的随机分数,40 是不幸的随机分数。当取标准化得分时,A 得 0 分,而 B 得约 1 分。然而,在生成性评估中,模型 B 比 A 高出 10 分!如果我们取标准化平均值,B 的得分为 5,而 A 几乎为 0,因此排名非常不同。

更容易的可复现性:更新评估套件

一年前,我们选择使用 EleutherAI 的 Harness(lm-eval)来进行我们的评估。它为多个任务提供了标准和稳定的实现。为了确保公平和可复现性,我们固定了所使用的版本。这使我们能够在完全相同的设置下比较所有模型,因为所有评估都是以完全相同的方式运行的,在相同的硬件上,使用相同的评估套件提交和参数。

然而随着lm-eval的更新,某些任务或指标的实现发生了变化,这导致 1)人们在更近期版本的 harness 上获得的评估结果和 2)我们使用固定版本的结果之间出现了差异。

对于新版的 Open LLM Leaderboard,我们与 EleutherAI 团队(尤其感谢 Hailey Schoelkopf)合作更新了 harness。

在功能方面,我们添加了对 delta 权重(LoRA 微调/模型适配)的支持、与排行榜兼容的日志系统以及高度请求的使用聊天模板进行评估。

在任务方面,我们花了几周时间手动检查所有实现和生成结果,修复了我们观察到的问题,如不一致的少样本样本、过于严格的句子结束标记等。我们为

排行榜任务实现创建了特定的配置文件,并正在添加一个测试套件,以确保评估结果随时间保持不变。

你可以在这里探索我们使用的可视化工具!

这将使我们能够保持版本的更新,以便将来添加新功能!

关于排行榜后端和指标已经说了很多。现在,让我们转向模型和模型选择/提交。

维护者推荐介绍

在过去的一年里,我们评估了超过 7500 个模型,观察到许多模型并没有被社区广泛使用。

最常用的通常是新的基础预训练模型,通常使用大量计算资源构建,社区可以随后进行微调以适应其用例(如 Meta 的 Llama3 或阿里巴巴的 Qwen2)。一些高质量的聊天或指令模型找到了一个庞大的用户社区,如 Cohere 的 Command + R,并成为社区实验的强大起点。️

然而,其他模型的故事可能不同,即使在排行榜上排名靠前。一些模型是实验性的,令人着迷且令人印象深刻的超过20个连续模型创建步骤的结合,通过微调或合并。

然而,这些模型提出了一些挑战:

  • 当堆叠如此多的步骤时,很容易丢失精确的模型配方和历史记录,因为一些父模型可能被删除,先前步骤的微调信息可能消失等。
  • 然后模型可能会意外污染

    去年发生了几次,从包含 TruthfulQA 或 GSM8K 信息的指令数据集微调的父模型派生的模型。
  • 模型可能会在基准测试上表现良好,但与其实际表现无关

    这可能发生在选择在相同基准上表现优异的模型进行合并时——这似乎选择性地提高了在这些基准上的表现,而与实际生活情况中的质量无关。(可能需要更多的研究)。

为了在排行榜中突出高质量模型并优先评估最有用的模型,我们决定引入一个类别,称为“维护者推荐”。

在这个列表中,您会发现来自各种来源的 LLM,由社区和 Hugging Face 团队手工挑选。我们包括像 Meta 或 Google 这样的公司,像 Cohere 或 Mistral 这样的初创公司,像 EleutherAI 或 NousResearch 这样的集体,以及许多其他用户发布的优秀模型。

该列表将根据社区建议和我们的观察不断发展,旨在尽可能包括最新的 SOTA LLM,并优先评估这些模型。

我们希望这也能使非机器学习用户更容易在排行榜上的众多模型中找到方向。

投票模型相关性

对于 Open LLM Leaderboard 的前一版本,评估通常以排队(“先提交,先评估”)的方式进行。随着用户有时一次提交许多 LLM 变体,Open LLM Leaderboard 在 Hugging Face 科学集群的空闲计算资源上运行,我们决定为提交的模型引入投票系统。社区将能够为模型投票,我们将优先运行票数最多的模型,将最受期待的模型排在优先队列的顶部。如果某个模型在集群满负荷时获得极高的票数,我们甚至可能考虑手动运行它而不是其他内部任务。

为避免垃圾投票,用户必须连接到他们的 Hugging Face 帐户才能投票,我们将保存投票记录。这个系统将帮助我们优先考虑社区热衷的模型。

最后,我们一直在努力改进和简化排行榜界面本身。

更好和更简单的界面

如果您是我们的常规用户之一,您可能已经注意到我们前端从上个月开始变得更快了。

这得益于 Gradio 团队的工作,尤其是 Freddy Boulton,他开发了 Leaderboard gradio 组件!它特别在客户端加载数据,使任何列选择或搜索几乎即时!你也可以在你自己的排行榜中重用它!

我们还决定将 FAQ 和关于标签移到它们自己的专用文档页面!

新排行榜,新结果!

我们开始添加和评估“维护者推荐”部分的模型(见上文),并期待社区向新版排行榜提交他们的新模型!!

排名结果如何?

看看 Open LLM Leaderboard 之前版本的前 10 名模型,并与这个更新版本进行比较,一些模型的排名相对稳定(如下加粗):Qwen-2-72B instruct,Meta 的 Llama3-70B instruct,01-ai 的 Yi-1.5-34B chat,Cohere 的 Command R + model,以及最后来自 AbacusAI 的 Smaug-72B。

我们对 Qwen2-72B-Instruct 特别印象深刻,它比其他模型高出一大步,平均得分为 43.02(尤其得益于其在数学、长范围推理和知识方面的表现)。

目前的第二名模型,Llama-3-70B-Instruct(平均得分36.67),在 GPQA 上与其预训练版相比失去了 15 分(4.92 vs 19.67)!这引发了一个问题,即 Meta 团队对这个模型进行的广泛指令微调是否影响了一些专家/研究生级别的知识。

当然,这个排名只是排行榜的开始,我们期望它在更多模型得到评估后会很快改变。你可以查看队列状态,看看哪些模型正在运行!

排名 新排行榜排名
Qwen/Qwen2-72B-Instruct
2 meta-llama/Meta-Llama-3-70B-Instruct
3 microsoft/Phi-3-medium-4k-instruct
4 01-ai/Yi-1.5-34B-Chat
5 CohereForAI/c4ai-command-r-plus
6 abacusai/Smaug-72B-v0.1
7 Qwen/Qwen1.5-110B
8 Qwen/Qwen1.5-110B-Chat
9 microsoft/Phi-3-small-128k-instruct
10 01-ai/Yi-1.5-9B-Chat

以下是排名变化的细节:

让我们以一些来自维护者团队的建议结束这些思考。

你应该关注哪些评估?

根据你的实际使用情况,你应该关注排行榜的各个方面。总体排名会告诉你哪个模型平均更好,但你可能对特定能力更感兴趣。

特别是,我们观察到我们的不同评估结果并不总是相互关联,如以下相关矩阵所示:

如你所见,MMLU-Pro 和 BBH 相关性较高。正如其他团队所指出的,这些基准测试也与人类偏好高度相关(例如,它们倾向于与 LMSys 的聊天机器人竞技场中的人类判断一致)。

我们的另一个基准,IFEval,针对聊天能力。它调查模型是否能够遵循精确指令。然而,这个基准使用的格式倾向于有利于聊天和指令微调的模型,预训练模型难以达到高性能。

如果你特别关注模型知识而不是对齐或聊天能力,最相关的评估可能是 MMLU-Pro 和 GPQA。

让我们看看这些更新的基准测试上的表现与我们之前版本排行榜的评估相比如何。

如我们所见,MMLU-PRO(橙色)和 GPQA(黄色)得分与 Open LLM Leaderboard v1 的 MMLU 得分合理相关。然而,我们注意到得分总体上低得多,因为 GPQA 难得多。因此,模型有很大的改进空间——这是个好消息

MATH-Lvl5 显然对专注于数学能力的人很有趣。这个基准测试的结果通常与 GSM8K 的表现相关,除了某些异常值,如下图所示。

绿色点突出了在 GSM8K 上由于上述评估限制而之前得分为 0 但现在在新基准 MATH-Level5 上得分非常不错的模型。这些模型(主要来自 01-ai)在之前的格式中被严重惩罚。红色点显示了在 GSM8K 上得分高但在 MATH-Lvl5 上几乎为 0 的模型。

从我们目前对模型输出和行为的深入研究来看,基础模型的聊天版本有时在 MATH 上得分明显低于原始模型!这个观察似乎表明一些聊天微调程序可能会削弱数学能力(根据我们的观察,使模型过于冗长)。

MuSR,我们的最后一个评估,对长上下文模型特别有趣。我们观察到表现最好的模型具有 10K 及以上的上下文大小,并且它似乎足以特异性地区分长上下文推理。

让我们以对 Open LLM Leaderboard 未来的展望结束!

接下来是什么?

就像 Open LLM Leaderboard 的第一个版本在过去一年推动了

模型开发的社区方法一样,我们希望新的版本2将成为开放和可复现模型评估的里程碑。

因为向后兼容和开放知识很重要,你仍然可以在 Open LLM Leaderboard Archive 找到所有之前的结果存档!

回顾 Open LLM Leaderboard 中评估的所有7400个模型的演变,我们可以注意到该领域的一些更广泛的趋势!例如,我们看到一个强烈的趋势,从更大的(红点)模型转向更小的(黄点)模型,同时提高性能。

这是该领域的好消息,因为较小的模型更容易嵌入,更节能/内存/计算效率更高,我们希望在新版本的排行榜中看到类似的进展模式。鉴于我们更难的基准,我们的起点要低得多(黑点),所以让我们看看几个月后该领域会带我们到哪里

如果你读到了这里,非常感谢。我们希望你会喜欢新版的 Open LLM Leaderboard。愿开源之风推动我们的 LLM 之船在深度学习的大洋中远航。

更难、更好、更快、更强:LLM Leaderboard v2 现已发布的更多相关文章

  1. CPNDet:粗暴地给CenterNet加入two-stage精调,更快更强 | ECCV 2020

    本文为CenterNet作者发表的,论文提出anchor-free/two-stage目标检测算法CPN,使用关键点提取候选框再使用两阶段分类器进行预测.论文整体思路很简单,但CPN的准确率和推理速度 ...

  2. Microsoft Hyperlapse——让第一人称视频更快更流畅

    Hyperlapse--让第一人称视频更快更流畅" title="Microsoft Hyperlapse--让第一人称视频更快更流畅"> 职业摄影师Nick Di ...

  3. 51nod 更难的矩阵取数问题(动态规划)

    更难的矩阵取数问题 给定一个m行n列的矩阵,矩阵每个元素是一个正整数,你现在 在左上角(第一行第一列),你需要走到右下角(第m行,第n列),每次只能朝右或者下走到相邻的位置,不能走出矩阵.然后再从右下 ...

  4. vue3.0和2.0的区别,Vue-cli3.0于 8月11日正式发布,更快、更小、更易维护、更易于原生、让开发者更轻松

    vue3.0和2.0的区别Vue-cli3.0于 8月11日正式发布,看了下评论,兼容性不是很好,命令有不少变化,不是特别的乐观vue3.0 的发布与 vue2.0 相比,优势主要体现在:更快.更小. ...

  5. Mockplus更快更简单的原型设计

    更快更简单的原型设计 https://www.mockplus.cn/ Mockplus,更快更简单的原型设计工具.快速创建原型,一键拖拽创建交互,团队协作省事省力.微软.华为.东软.育碧.Oracl ...

  6. 微服务平台(Micro Service Platform : MSP)旨在提供一个集开发、测试、运维于一体的开发者专属平台,让开发者能快速构建或使用微服务,让开发更简单,让运维更高效。

    微服务平台(Micro Service Platform : MSP)旨在提供一个集开发.测试.运维于一体的开发者专属平台,让开发者能快速构建或使用微服务,让开发更简单,让运维更高效. MSP采用业界 ...

  7. 2020 倒计时 1 天,Python 工程师找工作更难了?

    Python 是最神奇的编程语言. 无意引战,我说的是"神奇",不是"最好",并不想去"撼动" PHP 的地位.               ...

  8. Grafana 系列文章(十一):Loki 中的标签如何使日志查询更快更方便

    ️URL: https://grafana.com/blog/2020/04/21/how-labels-in-loki-can-make-log-queries-faster-and-easier/ ...

  9. js 性能基准测试工具-告别可能、也许、大概这样更快更省

    平时写js经常遇到这样做是不是更快点?但又没有具体简单可测试的工具,最近也倒序看博客园司徒正美 js分类下的文章 [ps:去年灵光一闪,发现看博客园排名前100的博客.按照文章分类倒序看是学习最快的方 ...

  10. 安装好Windows 8后必做的几件事情,让你的Win8跑的更快更流畅。

    1.关闭家庭组,因为这功能会导致硬盘和CPU处于高负荷状态. 关闭方法:Win+C-设置-更改电脑设置-家庭组-离开 如果用不到家庭组可以直接把家庭组服务也给关闭了:控制面板-管理工具-服务-Home ...

随机推荐

  1. pandas:时间序列数据的周期转换

    时间序列数据是数据分析中经常遇到的类型,为了更多的挖掘出数据内部的信息,我们常常依据原始数据中的时间周期,将其转换成不同跨度的周期,然后再看数据是否会在新的周期上产生新的特性. 下面以模拟的K线数据为 ...

  2. 10、操作系统安全加固-Linux加固

    1.账号管理与认证授权 1.1.为不同的管理员分配不同的账号 目的:根据不同用途设置不同账户账号,提高安全层级 实施方法: 1.设置高风险文件为最小权限,如:passwd.shadow.group.s ...

  3. ERROR: Error installing mysql2: ERROR: Failed to build gem native extension [@Ubuntu 15.04]

    参考文章: https://blog.csdn.net/a60919820/article/details/101847890 安装mysql 参考:https://www.cnblogs.com/h ...

  4. GDB 中内存打印命令

    GDB 中使用 "x" 命令来打印内存的值,格式为 "x/nfu addr".含义为以 f 格式打印从 addr 开始的 n 个长度单元为 u 的内存值.参数具 ...

  5. 获取list集合中最大值、最小值及索引值

    一.获取最大最小值的同时,获取到最大/小值在list中的索引值 public static void main(String[] args) { List<Integer> numList ...

  6. Vue cli之项目打包

    在项目根目录中执行如下命令: npm run build 注:Vue脚手架打包的项目必须在服务器上运行,不能直接双击运行: 在打包之后项目中出现 dist 目录,dist 目录就是 Vue脚手架项目的 ...

  7. Android 13 - Media框架(19)- ACodec(一)

    关注公众号免费阅读全文,进入音视频开发技术分享群! 这一节我们将会一起了解 ACodec 的设计方式,在看具体的实现细节前我们要先了解它内部的状态转换机制,这也是ACodec的核心难点之一. 1.AH ...

  8. .NET周刊【5月第4期 2024-05-26】

    国内文章 开源低代码框架 ReZero API 正式版本发布 ,界面操作直接生成API https://www.cnblogs.com/sunkaixuan/p/18201175 ReZero是一款. ...

  9. golang errgroup 的超时检测

    errgroup 的超时检测通常是一种事后得到结果的方式. errgroup本身并不直接支持超时控制,而是依赖于与之关联的context.Context来实现超时和取消功能. 当context超时时, ...

  10. 给师妹写的《Java并发编程之线程池十八问》被表扬啦!

    写在开头     之前给一个大四正在找工作的学妹发了自己总结的关于Java并发中线程池的面试题集,总共18题,将之取名为<Java并发编程之线程池十八问>,今天聊天时受了学妹的夸赞,心里很 ...