本文深入探讨了复现大模型评估结果时可能遇到的各种挑战，并提供了详细的解决方案。文章首先强调了代码库一致性的重要性，指出不同代码实现可能导致结果差异。接着，文章分析了随机种子、评估指标、归一化方式和Prompt等因素对结果的微妙影响。此外，文章还讨论了系统Prompt、聊天模板、少样本Prompt以及生成参数等因素对评估结果的影响。最后，文章指出了模型加载过程中硬件、代码库、Batch size和模型加载精度等差异可能带来的影响。总的来说，本文旨在帮助读者理解复现大模型评估结果的复杂性，并提供相应的指导。

🔑代码库差异：复现评估结果的首要任务是确保使用与原论文或报告一致的代码库。代码实现上的细微差别，如评估代码的来源或Hugging Face的Open LLM Leaderboard，都可能导致结果的显著差异。

⚙️评估细节影响：即使代码库相同，随机种子、评估指标的定义（例如精确匹配的不同计算方式）、归一化方式（如去除标点符号）以及Prompt的不同（包括格式、任务描述等），都可能导致结果出现微妙差异。

💬Prompt的强大影响：Prompt的格式、任务描述、系统Prompt和聊天模板等都可能显著影响最终得分。模型可能过拟合Prompt和标准回答的格式，导致对其他格式的Prompt适应能力差。

🔢生成参数与模型加载：生成式评估时，确保句子终止token、生成token数、采样种子和温度系数的一致性至关重要。此外，硬件、代码库、Batch size和模型加载精度等因素的不同，也会影响结果的复现。

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

关于推理关于 $\LaTeX$ 公式解析关于可复现性

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

代码库不同

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

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

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

注：正因如此，Hugging Face 团队决定推出 Open LLM Leaderboard，以便统一规范，使得在排行榜上的模型得分之间的对比更加公正。

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

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

随机种子不同
一般来说，推理阶段受随机种子影响的程度要比训练阶段小得多。不过种子对 CUDA 运算 (可以参考 PyTorch 的 reproducibility 页面) 会产生一些影响从而改变预测结果，尤其是基于非贪心算法生成的时候。另外如果使用 few-shot 的方式推理，随机种子还可能影响 prompt、前后处理函数。-> 有时候微小的差距可能导致评估结果好几分的差异。
评估指标不同。在实践中，哪怕是指标的名字相同，也可能代表不同的含义，比如:
对于 精确匹配 任务，如果原作者使用 对数似然 (计算不同答案的对数概率) 计算评估得分，而你采用 生成式 (只比较贪心生成结果与参考答案)，那你们计算出的指标就会不同。我们还发现，有一些评估代码库虽然定义为 精确匹配，但实际计算的却是 前缀精确匹配 (只比较生成结果与参考答案的开头部分)，或者 后缀精确匹配 (与前缀相反)，亦或是 准精确匹配 (归一化的精确匹配)。-> 因此，不能仅仅依赖于指标名称来判断实际评估方式，还是需要查看具体代码实现。
归一化方式不同
还以 精确匹配 为例，在 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 分) 以及 论文 阅读发现，都得出了类似的结论。

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

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

我们在 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 分。

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

生成参数不同

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

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

模型加载不同

我们观察到的差异点有:

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

---

英文原文: github.com/huggingface…

原文作者: Nathan Habib

译者: SuSung-boy

审校: Adeena