这是 大模型评估排障指南 系列文章的第三篇，敬请关注系列文章:

• 关于推理
• 关于   公式解析
• 关于可复现性

假设你读了一篇最近的新模型技术报告，然后心血来潮想要在本机复现他们的结果，却发现根本没法复现，这是为什么？ 让我们来探讨一下原因。

代码库不同

要想复现论文或报告的评估得分并精确到小数点，首先要确保使用的代码库一致。

一般情况下，你可以选择使用作者提供的默认评估代码，或者参考标准代码库实现，如 EleutherAI 的 lm_eval 或 HuggingFace 的 lighteval 等。但如果作者没有说明评估代码的来源，那很遗憾，基本上不太可能精确复现了。

如果你想知道为什么代码实现不一样会导致结果差异，可以参考这篇我们与 Hugging Face 评估团队共同撰写的 博客 (⭐)。博客中介绍了对 3 种常见 MMLU 评估代码 (lm_eval、helm、以及原作者实现) 的研究测试，重点解释了实现差异以及对模型得分的影响。 https://hf.co/blog/open-llm-leaderboard-mmlu

注：正因如此，Hugging Face 团队决定推出 Open LLM Leaderboard ，以便统一规范，使得在排行榜上的模型得分之间的对比更加公正。 https://hf.co/spaces/open-llm-leaderboard/open_llm_leaderboard

导致结果微妙差异的其他因素

即便使用的代码库相同，也会因为实现上的小细节不同而导致结果差异，可能因素有：

• 随机种子不同
• 一般来说，推理阶段受随机种子影响的程度要比训练阶段小得多。不过种子对 CUDA 运算 (可以参考 PyTorch 的 reproducibility 页面) 会产生一些影响从而改变预测结果，尤其是基于非贪心算法生成的时候。另外如果使用 few-shot 的方式推理，随机种子还可能影响 prompt、前后处理函数。-> 有时候微小的差距可能导致评估结果好几分的差异。 https://pytorch.org/docs/stable/notes/randomness.html
• 评估指标不同 。在实践中，哪怕是指标的名字相同，也可能代表不同的含义，比如:
• 对于  精确匹配  任务，如果原作者使用  对数似然  (计算不同答案的对数概率) 计算评估得分，而你采用  生成式  (只比较贪心生成结果与参考答案)，那你们计算出的指标就会不同。
• 我们还发现，有一些评估代码库虽然定义为  精确匹配 ，但实际计算的却是  前缀精确匹配  (只比较生成结果与参考答案的开头部分)，或者  后缀精确匹配  (与前缀相反)，亦或是  准精确匹配  (归一化的精确匹配)。-> 因此，不能仅仅依赖于指标名称来判断实际评估方式，还是需要查看具体代码实现。
• 归一化方式不同
• 还以  精确匹配  为例，在  lm_eval  库的 v1 版本中，有一些任务就被简单地命名为  生成式 精确匹配 ，如果不看代码，你可能觉得就是上文提到的那样，直接对比预测结果和参考答案，不过: 如果查看代码会发现，在做对比之前预测结果还多做了一步归一化 (去除标点符号、统一数字格式等)，这明显会改变对比得分。(现在  lm_eval  库的 v2 版本已经在多数指标中添加归一化名称了。) -> 这是最容易出错的地方，特别是对于那些需要大量归一化或答案后处理的任务，例如数学评估 (需要从生成解释中提取答案)。

Prompt 不同

Prompt 不同会导致模型输出和评分产生巨大的变化，主要包括 3 个类别:

Prompt 自身

Prompt 格式可能会显著影响最终得分。

例如在多选题评估中，呈现选项的 prompt 常见格式有以下几种:

问题: <问题文本>
选项:

| A. <Choice A> | (A) <Choice A> | <Choice A> | 
| B. <Choice B> | (B) <Choice B> | <Choice B> | 
| C. <Choice C> | (C) <Choice C> | <Choice C> | 
| D. <Choice D> | (D) <Choice D> | <Choice D> | 

回答: 

预测格式：A/B/C/D 或 <Choice A/B/C/D>。

这些选项是 语义等价 的，虽然它们包含的内容完全相同，但仍然会导致评估得分差异。我们有一些 实验结果 (同一模型评估结果差异高达 7 分) 以及 论文 阅读发现，都得出了类似的结论。

• 实验结果 https://x.com/clefourrier/status/1777319187913875893/photo/1
• 论文 https://arxiv.org/abs/2310.11324

一些评估还会加入任务描述 prompt (例如: 以下问题都是关于 <主题> (The following questions are about <topic>))。同样地，这些 prompt 的存在与否也会影响评估得分。

这篇 优秀论文 ⭐ 阐述了这一问题: 许多模型在评估基准数据集上训练，过拟合了 prompt 和 标准回答的格式，才导致了对其他格式的 prompt 适应能力差。 https://arxiv.org/abs/2407.07890

我们在 Open LLM Leaderboard 2 上的 Llama3.1 系列模型也观察到了这一现象。它们在标准测试集 MATH-Hard 上预测的答案完全正确，但在 few-shot 简单模板测试中评估得分反而较低，很可能就是过拟合了 GSM8K 数据集 (另一个数学测试集) 的 prompt 和答案格式。

系统 prompt 和聊天模板

聊天模型的训练或微调方式通常是指令或偏好，也就是学习推理时遵循模板的能力。例如多轮对话中，模板一般以通用 prompt (也叫 system prompt) 开始，并以特殊 token (一般是 System: ) 作为前缀。通用 prompt 的作用是为模型提供高层次指令，如某个角色的描述或者通用的指令格式。对话中可能还需要在文本前缀添加关键词，如询问时添加 User，回答时添加 Assistant。

小样本 (few-shot) 评估时，需要决定这些样本是一次性提供 (在一个 prompt 中)，还是多轮分次提供 (模仿上一段中的 user/assistant 模式)。

如果不遵循模型推理的最佳模板格式，那么输出性能就会下降，因为会迫使输出偏离训练阶段收敛的概率空间。

少样本 prompt

使用少样本评估 (不熟悉少样本可以参考 General knowledge/Model inference) 时，需要注意两点:

显然，few-shot 示例数量应与参考任务相同。

此外，必须保证评估时输入不同模型的 少样本示例完全一致 (没错不用惊讶，不一致时也会影响结果差异，因为不同模型对不同样本的表现是不一样的)。甚至你还得保证输入的 少样本示例顺序完全一致。我们观察到 MMLU 子测试集上，有些模型因为示例输入顺序的变化导致的评估结果 (点击 这里 可以查看一些结果) 差异最高可达 3 分。 https://hf.co/blog/evaluation-structured-outputs

这里的随机种子同样重要。

生成参数不同

对于生成式评估的参数，需要注意:

• 确保使用的  句子终止 token 相同
• 确保模型评估的  生成 token 数相同
• 确保采样的  种子和温度系数相同

模型加载不同

我们观察到的差异点有:

• 硬件不同 Pytorch 库并不保证在不同硬件上进行非确定性操作时的可重现性
• 代码库不同 例如推理后端的库:  transformers  和  vllm ，它们对矩阵计算的管理方式就不尽相同。
• batch size 不同 许多评估代码库和模型后端已经记录了这个问题: 推理时使用的 batch size 不同会导致结果差异。如果你想要完全复现结果，必须固定 batch size (当然有时候会因为显存问题无法做到)。
• 模型加载精度不同 使用低精度加载模型 (实际上加载的是权重的不同版本) 可以减少内存占用和推理成本，但会导致计算结果改变。

英文原文: https://github.com/huggingface/evaluation-guidebook/blob/main/contents/troubleshooting/troubleshooting-reproducibility.md

原文作者: Nathan Habib

译者: SuSung-boy

审校: Adeena