Hugging Face 深入排查 Open LLM Leaderboard 的 DROP 评测异常

最近，三个新的基准测试被添加到了Open LLM Leaderboard中：Winogrande、GSM8k 和 DROP，使用的是在EleutherAI Harness中复现的原始实现。粗略查看 DROP 的分数后发现了一些奇怪的现象，绝大多数模型的 f1-score 都低于 10 分（满分 100 分）！我们进行了深入调查以了解发生了什么，跟随我们一起来看看我们的发现吧！

初步观察

DROP（Discrete Reasoning Over Paragraphs，段落离散推理）是一项评估任务，模型必须从英文文本段落中提取相关信息，然后对其执行离散推理步骤（例如，对项目进行排序或计数以得出正确答案，参见下表示例）。使用的指标是自定义的 f1 和精确匹配分数。

我们三周前将其添加到 Open LLM Leaderboard 中，并观察到预训练模型的 f1-score 呈现出一种意外的趋势：当我们将 DROP 分数与排行榜原始平均值（ARC、HellaSwag、TruthfulQA 和 MMLU 的平均值，这是模型整体性能的合理代理指标）进行绘图时，我们预期 DROP 分数与其相关（更好的模型应该有更好的表现）。然而，这只适用于少数模型，所有其他模型的 DROP f1-score 都非常低，低于 10。

归一化的疑问

在我们对这些令人惊讶的行为进行第一次深入调查时，我们观察到归一化步骤可能没有按预期工作：在某些情况下，当归一化后的正确答案直接后跟一个非空格的空白字符（例如换行符）时，该归一化会忽略它。 让我们看一个例子，生成结果为 10\n\nPassage: The 2011 census recorded a population of 1,001,360，标准答案为 10。

归一化分几个步骤进行，对生成结果和标准答案都是如此：

1. 按分隔符拆分 |、- 或 生成结果的起始序列 10\n\nPassage: 不包含此类分隔符，因此在此步骤后被视为单个实体。
2. 标点符号移除 第一个 token 随后变为 10\n\nPassage（: 被移除）
3. 数字同质化 每个可以转换为 float 的字符串都被视为数字并转换为 float，然后再转换回字符串。10\n\nPassage 保持不变，因为它无法转换为 float，而标准答案 10 变为 10.0。
4. 其他步骤 随后进行了许多其他归一化步骤（移除冠词、移除其他空白字符等），我们最初的例子变成了 10 passage 2011.0 census recorded population of 1001360.0。

然而，总体分数不是基于字符串计算的，而是基于从字符串中提取的词袋（BOW）计算的，这里是 {'recorded', 'population', 'passage', 'census', '2011.0', '1001360.0', '10'}，将其与标准答案的 BOW（同样以上述方式归一化）{10.0} 进行比较。如你所见，它们没有交集，即使模型预测了正确的输出！

总之，如果一个数字后面跟着任何非简单空格的空白字符，它就不会经过数字归一化，因此如果标准答案也是数字，就永远不会匹配！这第一个问题很可能会对分数造成相当大的影响，但显然这不是导致 DROP 分数如此低的唯一因素。我们决定进一步调查。

深入分析结果

为了进一步探究，我们在 Zeno 的朋友加入了我们，并对结果进行了更为彻底的探索，研究了5个代表我们在DROP分数中注意到的问题的模型：falcon-180B和mistral-7B的表现低于我们的预期，Yi-34B和tigerbot-70B在DROP上的表现非常好，与其平均分数相关，而facebook/xglm-7.5B则处于中间位置。

如果你想尝试分析结果，可以在Zeno项目中这里进行！

Zeno团队发现了两个更令人担忧的特点：

1. 没有一个模型在浮点答案上得到正确结果
2. 生成长答案的高质量模型实际上具有较低的f1分数

此时，我们认为这两个失败案例实际上都是由同一个根本因素引起的：使用.作为停止词标记（以结束生成）：

1. 浮点答案在生成完成之前被系统性地中断
2. 更高质量的模型，试图匹配少样本提示格式，会生成Answer\n\nPlausible prompt for the next question.，并且只在第一个.上的实际答案之后的合理提示延续期间停止，因此生成了太多单词并获得了糟糕的f1分数。

我们假设这两个问题都可以通过使用\n而不是.作为生成结束停止词来解决。

更改生成结束标记

所以我们尝试了一下！我们研究了在可用结果上使用\n作为生成结束标记。我们将生成的答案在其包含的第一个\n处分割，如果存在的话，并重新计算分数。 请注意，这只是正确结果的近似，因为它不会修复在.上过早截断的答案（例如浮点答案）——但它也不会给任何模型带来不公平的优势，因为所有模型都受到了这个问题的影响。 然而，这是我们不重新运行模型所能做的最好的（因为我们想尽快让社区了解情况）。

我们得到的结果如下——在\n上分割与其他分数以及整体表现高度相关。

那么接下来呢？

快速计算表明，重新运行所有模型的完整评估将相当昂贵（完整更新耗时8年的GPU时间，其中大部分被DROP占用），我们估算了仅重新运行失败示例的成本。

在10%的情况下，黄金答案是浮点数（例如12.25），模型预测以正确的开头开始（对于我们的例子，12），但在.处被截断——如果生成继续，这些预测很可能实际上是正确的。我们肯定需要重新运行它们！ 我们的估计没有计算以可能被中断的数字结尾的生成句子（其他生成的40%），也没有计算任何因归一化而搞乱的预测。

因此，为了得到正确的结果，我们需要重新运行超过50%的示例，这是一个巨大的GPU时间量！我们需要确保这次我们将运行的实现是正确的。

在与出色的 EleutherAI 团队（在 GitHub 上和内部）讨论后，他们指导我们了解了代码并帮助了我们的调查，很明显，LM Eval Harness 的实现非常严格地遵循了“官方 DROP”代码：因此需要开发这个基准评估的新版本！ 因此，我们决定从 Open LLM Leaderboard 中移除 DROP，直到新版本出现。

这次调查的一个收获是，让社区的众多眼睛协作调查一个基准以发现以前遗漏的错误的价值。这里再次体现了开源、社区和公开开发的力量，它允许透明地调查一个已经存在了几年的基准问题的根本原因。

我们希望社区中感兴趣的成员能与从事 DROP 评估的学者联手，修复其评分和归一化。我们很希望它能再次可用，因为数据集本身真的相当有趣和酷。我们鼓励你就我们应该如何评估 DROP 在这个问题上提供反馈。

感谢许多社区成员指出了 DROP 分数的问题，也非常感谢 EleutherAI Harness 和 Zeno 团队在这个问题上的大力帮助。