LLM 评估指标详解：如何客观对比 LLaMA-3 与 GPT-4 能力

在基准评估中，为了公平对比，必须使用相同的配置才有参考价值。然而部分评估中并未清晰的列出对应的配置，导致部分指标无法对齐。例如 Qwen1.5 和 Yi-1.5 模型的各种指标展示中，很多都没有明确指出对应的 shot 数或是否包含 CoT，这使得横向对比变得困难。

2.4 Base 模型 & Instruction 模型

现在有很多开源的 LLM 都会提供 Base 模型和 Instruction 模型，两者的评估指标可能会有比较大的区别：

• Base 模型：是在大量未标注的通用文本数据上进行无监督训练，适用于需要广泛自然语言理解和生成的场景。
• Instruction 模型：通常是在 Base 模型基础上，使用经过人工标注或筛选的指令数据通过有监督微调训练而来，更适合需要特定指令进行操作的场景。

我们在收集数据的时候发现很多地方会混淆两个模型的指标。例如 LMSys Chatbot Arena Leaderboard 中就混淆了 Qwen1.5-110B 以及 Qwen1.5-72B 的 Base 模型和 Instruction 模型。参考 Qwen-1.5 的官方博客，MT-bench 指标确实是 Chat 模型，但 MMLU 对应的是 Base 模型。这种混用会导致对模型能力的误判。

2.5 不同模型版本

早期的 LLM 通常都会发布详细的技术报告，包括具体版本和性能指标的说明。然而，最近的很多 LLM 仅以简单的博客页面形式发布，甚至缺乏对模型及其评估指标的详细介绍，特别是一些闭源模型。这种变化为不同模型之间的横向对比带来了很大的挑战。例如 LMSys Chatbot Arena Leaderboard 榜单中，排名前 12 的模型中，GPT-4 就有 4 个版本，Gemini-1.5 也有三个版本，区分这些细微差别非常关键。

2.6 评估工具差异

很多公司都有自己的评估工具，其有些时候不会和开源社区的评估方式完全对齐，导致评估指标的差异。比如在 DeepSeek-V2 中，作者使用了内部评估工具，导致有些结果和我们从 Qwen1.5 72B、Mixtral 8x22B 和 LLaMA3 70B 官方报告中看到的结果不太一致。在浪潮的源 2.0-M32 中，作者也提供了 Qwen1.5-72B Chat 的结果，但是看着是直接引用了其他模型的结果，并没有说明自己使用的评估工具。这提醒我们在阅读技术报告时，需关注其评估环境的透明度。

2.7 数据污染

数据污染问题在大模型训练中非常常见，没有经过仔细的数据清理过程，很可能会在训练集中混入部分基准评估数据。比如，OpenAI 的 GPT-4 Paper 中提到，其发现训练集中不小心混入了 BIG-Bench 数据，所以 GPT-4 Paper 中并未提供 BIG-Bench Hard 的评估结果。

最近 Scale AI 的研究员研究了 GSM-8K 数据泄漏问题。作者通过人工标注方式构建了 GSM-1K 数据集，其难度与 GSM-8K 类似。作者使用该数据集对一些开源和闭源 LLM 进行了基准测试，发现部分模型在 GSM-1K 上的性能甚至比 GSM-8K 低 10% 以上，比如 math-shepherd-mistral-7b-rl 指标低了将近 13%；而 Claude 3 和 GPT-4 模型指标没有下降。这说明头部模型可能具备更强的泛化能力，或者其训练数据清洗更为严格。

三、MMLU 深度解析

MMLU 评估集是为了衡量文本模型的多任务准确性，其涵盖人文科学、社会科学、自然科学等领域的 57 个子任务，比如小学数学、美国历史、计算机科学、法律等。题目都是多项选择题，通过测试语言模型在不同领域的知识和推理能力来评估其综合性能。

与其他语言理解评估集（如 GLUE、SuperGLUE 等）相比，MMLU 的任务种类更多，覆盖面更广，能够更加全面地评估大规模语言模型的能力。这使得 MMLU 成为当前评估大规模预训练语言模型的一个重要工具。几乎每个 LLM 都会评估并对比其在 MMLU 基准上的能力，而且绝大部分都是评估 5-shot 能力，少量模型会评估 5-shot+CoT 能力。

MMLU 指标相对比较统一，基本不会有太多歧义。然而，在 Massive Multitask Language Understanding on HELM 中，作者发现很多模型声称的 MMLU 指标和 Helm 中评估出来的有较大差距。这可能是因为不同的预处理方式、温度设置或采样策略导致的。在进行模型选型时，建议优先参考 Helm 或 Harness 等第三方权威机构的复现结果。

四、GSM-8K 评估陷阱

各种模型基本都会提供 GSM-8K 评估结果，但对应的评估结果比较混乱。比如，有些是 0-shot+CoT 结果，有些是 8-shot+CoT，有些是 5-shot+CoT，甚至有些是 11-shot。Google Gemini 之前被吐槽的一个点就是拿 GSM-8K 11-shot 的结果和其他模型 8-shot，5-shot 的结果对比，这在学术上是不公平的。

GPT-4 Technical Report 中的关键结果显示，其 GSM-8K 的 92.0 为 5-shot+CoT 的结果，而 GPT-3.5 的 57.1 为 5-shot 的结果。阿里的通义千问 Qwen1.5 介绍中的官方评估结果，其并没有具体介绍 GSM8K 是 5-shot 还是 8-shot，不过从其开源的评估工具可以看出是 8-shot+CoT 的结果。但是对应的结果中 GPT-4 的 92.0 为 5-shot+CoT 结果，Mixtral-8x7B 的 74.4 确实为 8-shot+CoT 结果。这种配置的不一致直接影响了排名的可信度。

实际上 Mixtral 官方提供了相应 5-shot 和 8-shot 的结果，其 Mixtral 8x7B 的 5-shot 结果只有 58.4，远低于 8-shot 的结果。零一万物的 Yi 模型也存在同样的情况，论文中介绍的是 GSM-8K 的 8-shot 结果，但是 GPT-3.5 和 GPT-4 的是 5-shot 的结果。此外 Mistral 7B 的 GSM-8K 和 MATH 结果也比官方结果要低。在浪潮的源 2.0-M32 中作者同样将 8-shot 的 GSM-8K 结果与 5-shot 的 Mixtral-8x7B 进行比较，实际上两个模型对应的 8-shot 应该为 74.4 和 88.4。这再次强调了配置对齐的重要性。

五、MATH 与 GPQA

MATH 的评估相对比较统一，基本上都是 4-shot 的结果，但是 GPT-4o，GPT-4T 相关结果都是 0-shot 的。Claude 3 同时提供了 0-shot 和 4-shot 结果，这显示了不同模型在提示词工程上的差异。

GPQA 是一个比较新的评估集，是由生物、物理和化学领域的专家编写的多项选择题，问题的质量高且难度大。其全集 full(extended) 包含 546 个问题，main 和 diamond 是对应的两个子集。Meta 的 LLaMA-3 中，作者并未特别说明使用的哪个集合，只介绍其为 GPQA(0-shot)，不过在 llama3/eval_details.md 中提到是 Main 集合，并且没有说明使用 CoT。在 The Claude 3 Model Family 中，作者给出了 Claude 3 在 3 个集合上详细的评估结果。在 Gemini Pro 中，Google Gemini 提供了 main 集合下的评估结果。在阿里的通义千问 Qwen1.5-110B 中同样没有介绍 GPQA 对应的集合，甚至未介绍是否是 0-shot。这种信息的缺失使得跨模型对比变得极具挑战性。

六、其他常用指标

如下的几个指标相对比较统一，各个模型基本也都有相应的结果：

• HumanEval：通常都是采用 0-shot 评估，主要看代码能否通过测试用例。
• BIG-Bench Hard（BBH）：通常采用 3-shot+CoT 评估，涵盖逻辑推理、字符串操作等。
• HellaSwag：通常采用 10-shot 评估，侧重常识补全。
• ARC-C：通常采用 25-shot 评估，侧重科学常识。
• DROP：通常采用 3-shot 评估，侧重阅读理解。

七、AlpacaEval 2.0 与人类偏好

AlpacaEval 2.0 是一个指令遵循评估，它利用 LLM 来评估生成质量。在 AlpacaEval 中，会倾向于生成较长输出的模型。因此，在 AlpacaEval 2.0 中，作者引入了长度控制（Length-Controlled AlpacaEval），来缓解这种偏好。这反映了自动评估工具可能存在偏差，需要结合人类反馈。

八、LMSYS Chatbot Arena

国外社区经常会使用 Chatbot Arena 来评估 LLM 的能力。其相当于大模型的竞技场，都是通过真实用户打分结果来评估人类对模型的偏好，其更接近真实用户场景，也更加客观。这也是'零一万物 Yi-Large 在 LMSYS 中文榜单排名第一'的来源。按照 Arena Elo 排序的结果更能反映模型在实际对话中的体验。在 Chatbot Arena 中也提供了 MT-bench 和 MMLU 的相关指标，可以作为辅助参考。

九、最佳实践建议

为了更准确地评估和选择大模型，建议遵循以下最佳实践：

1. 统一评估环境：尽量使用开源的评估框架（如 lm-eval-harness）在本地复现关键指标，确保硬件、软件版本和参数配置一致。
2. 关注配置细节：在阅读技术报告时，务必确认 Shot 数量、是否开启 CoT、Temperature 设置等关键参数，避免被'最优配置'误导。
3. 警惕数据污染：对于数学和科学类任务，优先参考去重后的数据集（如 GSM-1K）结果，防止过拟合。
4. 综合多维度指标：不要只看单一分数，应结合 MMLU（知识）、HumanEval（代码）、MT-Bench（对话）等多维度指标综合判断。
5. 参考第三方榜单：关注 Helm、OpenCompass 等独立机构发布的榜单，减少厂商自证带来的偏差。

十、总结

大模型的评估是一个复杂且动态的过程。虽然现有的基准测试提供了一定的量化标准，但由于配置不透明、数据污染、评估工具差异等原因，直接对比不同厂商的公开数据往往存在偏差。国内大模型虽然在某些特定指标上取得了显著进步，但在通用推理、长上下文处理及复杂指令遵循方面，与顶级闭源模型仍存在一定差距。开发者在选型时应保持理性，结合业务场景进行实际测试，而非单纯依赖宣传数据。随着评估体系的不断完善，未来我们将能看到更客观、更透明的模型能力对比。