我们来谈谈LLM评估

由于我的团队在Hugging Face负责评估和排行榜，在ICLR 2024（两周前）大会上，很多人想就这个话题向我请教（这出乎意料，非常感谢所有感兴趣的人）。

通过这些讨论，我意识到我理所当然认为的一些评估方面的观点：1）并未广泛传播，2）显然很有趣。

所以，让我们更广泛地分享这些对话吧！

我们如何进行LLM评估？

首先，让我们统一一些定义。据我所知，目前有三种主要的评估方法：自动化基准测试、使用人类作为评判者和使用模型作为评判者。每种方法都有其存在的理由、用途和局限性。

基准测试

自动化基准测试通常是这样运作的：你想知道你的模型在某个方面表现如何。这个“某个方面”可以是一个定义明确的具体**任务**，例如*我的模型对垃圾邮件的分类效果如何？*，也可以是一个更抽象和广义的**能力**，例如*我的模型在数学方面表现如何？*。

由此，你构建一个评估，通常由两部分组成：

• 一系列*样本*，作为输入提供给模型，以观察其输出，有时还会附带一个参考（称为黄金标准）进行比较。样本通常旨在模拟你想要测试模型的能力：例如，如果你在进行电子邮件分类，你会创建一个包含垃圾邮件和非垃圾邮件的数据集，并尝试包含一些难以处理的边缘情况等。对于大型语言模型（LLMs），两个主要任务是生成评估（将生成的文本与标准化后的参考文本进行比较），或多项选择（比较提示后可能延续的相对对数概率）。
• 一个*指标*，用于计算模型的得分。例如，你的模型分类垃圾邮件的准确率（正确分类的样本得分为1，错误分类的为0）。

在不包含在模型训练集中的数据上进行此操作会更有趣，因为您想测试它是否**泛化**得好。您不希望模型只能分类它已经“见过”的电子邮件，那将毫无用处！

注意：一个只能在其训练数据上良好预测（并且没有潜在地学习到更高级别的通用模式）的模型被称为**过拟合**。在不那么极端的情况下，您仍然希望测试您的模型是否能够泛化到训练集分布中不存在的数据模式（例如，在只见过关于虚假银行的垃圾邮件后，分类关于“健康”产品的垃圾邮件）。

这对于那些表现“容易”评估和衡量的、定义非常明确的任务来说效果很好：当你实际测试你的模型在垃圾邮件分类上的表现时，你可以说“模型正确分类了n%的这些样本”。对于LLM基准测试，可能会出现一些问题，例如模型在多项选择评估中可能偏爱特定顺序的选项，以及生成式评估依赖的标准化方法如果设计不当可能会不公平，但总的来说，它们仍然能在任务层面上提供信号。

然而，对于能力而言，很难将其分解为定义明确且精确的任务：“擅长数学”意味着什么？擅长算术？擅长逻辑？能够对数学概念进行推理？

在这种情况下，人们倾向于进行更“整体”的评估，不将能力分解为具体的任务，而是假设在一般样本上的表现将是衡量我们目标的**良好替代品**。例如，GSM8K由实际高中数学问题组成，解决这些问题需要一整套能力。这也意味着失败和成功都很难解释。有些能力或主题，例如“这个模型擅长写诗吗？”或“模型的输出有用吗？”甚至更难通过自动指标进行评估——同时，模型现在似乎具有越来越多的**通用**能力，因此我们需要以更广泛的方式评估它们的能力。（例如，科学界曾就LLM是否能画独角兽展开过辩论。目前很可能不行，但这显然是一个值得研究的重要问题。）

自动化基准测试还有另一个问题：一旦它们以纯文本形式公开发布，它们很可能会（通常是意外地）进入模型的训练数据集。一些基准测试的创建者，如BigBench的作者，试图通过添加一个“金丝雀字符串”（一种非常特定的字符组合）来缓解这个问题，让人们去查找并从训练集中删除，但并非所有人都了解这个机制，也并非所有人都尝试进行这种删除。此外，基准测试的数量相当可观，因此在数据中寻找所有这些意外副本的成本很高。其他选项包括以加密形式或通过门控系统提供基准测试。然而，在评估黑盒API后面的闭源模型时，无法保证提供的数据以后不会在内部用于训练或微调。

评估数据集最终进入训练集的情况称为**数据污染**，受污染的模型将具有很高的基准性能，但其性能无法很好地泛化到其基础任务（有关数据污染的详细描述可此处找到，这里有一种有趣的方式来检测它）。解决数据污染的一种方法是运行**动态基准测试**（对定期更新的数据集进行评估，以系统地提供未见过的新数据上的分数），但这种方法从长远来看成本较高。

人类作为评判者

解决数据污染和更开放式评估的一个方法是让人类来评估模型输出。

这通常通过以下方式实现：首先让人类对模型进行提示，然后根据指导原则对模型回答进行评分或对多个输出进行排名。使用人类作为评判者可以研究更复杂的任务，并且比自动化指标更具灵活性。它还可以防止大多数污染情况，因为（希望如此）编写的提示是全新的。最后，它与人类偏好高度相关，因为这正是评估的内容！

存在不同的方法来评估带有人类参与的模型。

“**Vibes-checks**”是指社区中一些成员单独进行的、通常针对未公开提示的手动评估，旨在获得模型在许多用例（从编码到不雅内容的质量）上的整体“感觉”。（我也见过将“canary-testing”一词用于此，指的是煤矿中高信号金丝雀的方法）。这些评估常在Twitter和Reddit上分享，主要构成轶事证据，并且往往对确认偏误高度敏感（换句话说，人们倾向于找到他们正在寻找的东西）。然而，一些人一直在尝试进行更系统化的氛围检查评估；例如，用户*Wolfram Ravenwolf*通过博客非常系统地分享他的模型比较发现（可参考此处的示例）。

利用社区反馈建立大规模模型排名的方法我们称之为**竞技场**。一个广为人知的例子是LMSYS聊天机器人竞技场，社区用户被要求与模型聊天，直到他们发现一个比另一个更好。然后，投票被汇总到Elo排名（比赛排名）中，以选择“最佳”模型。这种方法的明显问题是高度主观性——很难强制许多社区成员使用宽泛的指导方针进行一致的评分，特别是注释者的偏好往往受文化影响（例如，不同的人偏爱不同的讨论主题）。人们可以希望这种影响通过投票的巨大规模，通过“群体智慧”效应得到平滑（这种效应是由统计学家高尔顿发现的，他观察到试图估计数值（如猪的重量）的个体答案可以被建模为以实际答案为中心的概率分布）。

最后一种方法是**系统化标注**，即向付费的指定标注员提供极其具体的指导方针，以尽可能消除主观偏见（这是ScaleAI以及大多数数据标注公司使用的方法）。然而，由于您必须为每个新要评估的模型持续进行非自动化评估，它会变得极其昂贵，并且仍然可能受到人为偏见的影响（这项研究表明，具有不同身份的人对模型答案毒性的评分差异很大）。

最近的研究也表明，人类评估者倾向于根据第一印象来估计答案质量，而不是实际的事实性或忠实性。众包标注者尤其对语气敏感，并低估了自信答案中事实或逻辑错误的数量。换句话说，如果模型以自信的语气说错话，人类评估者发现的可能性会大大降低，这可能会使评分偏向更自信的模型。（专家标注者不太可能受这些偏见的影响。）这种人类偏见在另一篇论文中得到了证实：人类最有可能偏爱符合其观点、或与其意见或错误一致的答案，而不是事实正确的答案。

这些偏见并非出乎意料，但必须考虑到：并非所有用例都应依赖于人类标注员，尤其是众包的非专业标注员——任何需要事实性（如代码编写、模型知识评估等）的任务都应包含另一种更可靠的评估类型来完善基准测试。

模型作为评判者

为了降低人工标注的成本，一些人开始研究使用模型或派生产物（最好与人类偏好保持一致）来评估模型的输出。这种方法并非新鲜事，早在2019年，您就可以找到从模型嵌入中测量摘要质量的技术。

目前有两种评分方法：使用通用、高能力模型，或使用经过偏好数据训练的小型专业模型。前一种方法的结果与人类偏好高度相关，但大多数足够强大的模型都是闭源的，因此其API可能会发生变化，且难以解释。

作为判断者的LLM有几个明显的局限性：它们在评分答案时倾向于偏爱自己的输出，在提供一致的评分范围方面表现不佳（尽管你可以通过要求模型在提供分数之前解释其推理来改善这一点），并且实际上与人类排名并不那么一致。

我个人对使用模型作为评判者的主要不满是，它们在答案选择中引入了非常微妙且难以解释的偏见。我觉得，就像基因学研究中过度杂交会导致动物或植物功能失调一样，通过使用LLM来选择和训练LLM，我们也很可能会引入微小的变化，而这些变化在未来几代中会产生更大的影响。我相信这种偏见在作为评判者的小型、更专业化的模型（例如毒性分类器）中不太可能发生，但这仍有待严格测试和证明。

我们为什么进行LLM评估？

现在我们已经了解了如何进行评估，那么它到底有什么用呢？

我坚信人们进行评估主要有三个原因，这些原因往往被混淆在一起，但实际上**非常不同**，每个原因都回答一个独立的问题。

1) 我的模型训练得好吗？我的训练方法可靠吗？ - 非回归测试

**非回归测试**是软件行业的一个概念，旨在确保微小的更改不会破坏整体方法。

其理念如下：当你向软件添加新功能，或修复代码库中的问题时，你是否破坏了其他东西？这就是非回归测试的目的：确保你的软件预期的、高层级的行为不会因一个（看似不相关的）更改而突然失效。

当您选择模型训练设置时，您想测试类似的东西，并确保您的更改（选择不同的训练数据、架构、参数等）没有“破坏”具有这些属性的模型的预期性能。

举个具体例子，您会期望一个7B的基础LLM在训练后MMLU（多项选择）得分在50到65之间，而另一方面，您也知道如果性能波动在20到30之间，则表明没有发生学习。

对于“非回归”评估，您需要关注 1) 评估分数的**轨迹**（性能是否比训练开始时更好），2) 评估分数的**范围**（性能是否在预期之内）。您实际上……并不关心具体的得分！

因此，这项评估并非旨在告诉您任何关于模型实际能力的信息，而仅仅是为了确认您的训练方法与其它训练方法“一样可靠”，并且您的模型行为方式相似。我相信，即使是一些仅查看文本困惑度（概率）变化进行的评估，也足以满足此步骤的需求，但您通常会希望基准测试具有较高的“信噪比”，换句话说，您希望确保分数上的重大变化反映出模型发生了重大转变。

2) 哪个模型最好？我的模型比你的模型好吗？ - 排行榜和排名

评估的下一个作用是简单地对模型进行排序，以发现和选择整体最佳的架构和方法。如果有一个排行榜，取排名最高的模型，而它在你的用例中不起作用，那么下一个排名靠前的模型也不太可能起作用。在他们关于ImageNet时代基准测试和数据集设计的经验教训的论文中，作者认为，由于分数容易不稳定，评估模型的唯一稳健方法是通过排名，更具体地说，是通过找到提供一致和稳定排名的广泛评估组。

我相信，寻求排名稳定性确实是一种非常有趣的LLM基准测试方法，因为我们已经表明LLM在自动化基准测试上的*分数*极易受到提示细微变化的影响，而且人类评估的一致性也不高——而*排名*在使用稳健评估方法时实际上更稳定。

如果分数本身并不那么相关，那么模型之间的相对顺序能否告诉我们一些有价值的信息呢？

在相关的ICLR 2024评估全体会议上，Moritz Hardt 比较了在Open LLM Leaderboard（通过微小的分数修改，完全在分数范围内）和 Chatbot Arena（通过在竞技场中添加一个不好的竞争者，观察其对Elo排名的影响）上添加扰动的情况。目前，这些基准测试都不能提供稳定一致的排名。我们一定会探索 Open LLM Leaderboard 未来版本中的这一方面！

3) 作为一个领域，我们在模型能力方面处于什么位置？我的模型能做X吗？

“您如何判断模型是否能做X？”是一个经常出现的问题，我认为它非常有效。

然而，对于任何复杂的能力，**我们目前不能简单地说“这个模型在这方面是最好的”，而只能说“这个模型在这个任务上是最好的，我们希望这个任务能很好地代表这种能力，但不能提供任何保证”**。

我们目前严重缺乏关于机器学习模型能力（尤其是涉及推理和心智理论的能力）的良好定义和框架。然而，这并非机器学习独有！在人类和动物研究中，定义何为“能力”也相当困难，试图提供精确分数的指标（例如智商和情商）也因其合理性而备受争议。

我们也许可以借鉴社会科学来思考能力评估，因为在这些领域，人们习惯于认真思考数据收集和分析中的混杂因素。然而，我也认为很可能：1）我们根本无法定义这些广阔的能力，因为我们目前无法在人类和动物中定义它们；2）针对人类（或动物）构建的框架无法很好地迁移到模型中，因为其底层行为和假设不同。

结论

目前的LLM评估主要通过以下方式进行：使用自动化基准测试，受数据污染和“通用性”不足的影响（后者不一定是坏事，因为专门评估很有趣）；使用人工评估，这在小规模上往往缺乏可重复性，并且普遍存在心理偏见（例如偏爱逢迎的答案），尽管人们希望某些偏见在大规模上能被平滑掉；使用模型作为评判者，这在评估时存在非常微妙的偏见，可能不被注意但会在下游引入扰动。

然而，一切尚未绝望：评估在其局限性内，仍能提供一些信号，判断哪些新的训练方法或数据集前景光明，哪些不然。这既可以通过观察性能是否落在预期范围内（非回归测试），也可以通过观察模型的总体排名（使用足够稳定的评估）来实现。我们还可以希望，通过结合足够多的跨主题和任务的数据点，能为我们提供足够的信号，以了解模型的整体性能，但同时不假设任何关于更“通用”能力的信息。

与炒作相反，我们目前还无法真正评估“通用模型能力”，首先是因为我们还没有定义它意味着什么。然而，LLM评估作为一个研究领域，目前仍处于起步阶段，有大量工作等待完成，这非常令人兴奋！我们可以从许多领域汲取灵感，从机器学习的可解释性到社会学，以定义新的指标和任务。跨学科合作很可能会为该领域开辟全新的酷炫方向！

致谢

非常感谢所有在会议上对评估话题感兴趣并与我交流的优秀人士，包括但不限于 Summer Yue (Scale AI)、Moritz Hardt (Max Planck Institute)、Luca Soldaini 和 Ian Magnusson (Allen AI)、Ludwig Schmidt (Anthropic)、Max Bartolo (Cohere)、Maxime Labonne (Liquid AI)、François Charton (Meta)、Alan Cooney (UK AI Safety Institute) 和 Max Ryabinin (Together AI)。

也衷心感谢 Hugging Face 的 Yacine Jernite 和 Irene Solaiman 对本文提供的宝贵反馈。

最后但同样重要的是，感谢 Hugging Face 的评估和排行榜团队，特别是 Nathan Habib，感谢我们共同进行的讨论和工作！