LLM基准测试入门

想象一下，LLMs的参数规模从 70 亿到超过 1000 亿不等，一代更比一代强。其中包括巨头级模型：Mistral 70 亿、Mixtral 8x70 亿、Llama 700 亿，以及庞大的 Falcon 1800 亿。同时也有像 Phi1、Phi1.5 和 Falcon 1B 这样的模型，仅以 10 亿到 40 亿的轻量级架构追求相近的性能。无论规模大小，所有模型都怀揣共同目标：掌握语言艺术，在文本摘要、问答和命名实体识别等任务中表现出色。

但所有大语言模型(LLMs)普遍存在一些严重缺陷行为：

某些提示会导致LLMs产生无意义输出，这种现象被称为"越狱提示"。
LLMs并不总是事实准确，这种现象也被称为‘幻觉’。
LLMs可能表现出消费者使用时不安全的意外行为。

显然，仅仅训练LLMs是不够的。因此，问题来了：我们如何能自信地断言拥有‘n’个参数的LLM‘A’优于拥有‘m’个参数的LLM‘B’？或者说，基于可量化、合理的观察，LLM‘A’是否比LLM‘B’更可靠？

需要有一个标准来对LLMs进行基准测试，确保它们在伦理上可靠且事实表现良好。尽管关于基准测试已有大量研究，但仅进行研究对于生产用例的鲁棒、定制化基准测试也是不够的。

本文概述了当前关于LLM评测的研究现状，并介绍了该领域一些优秀的开源实现。通过这篇博客，你将了解到：

场景、任务、基准数据集和LLM评测指标
当前关于LLM基准测试的研究及其现存问题
LLM基准测试/评测的最佳实践
使用 DeepEval 强制执行评测最佳实践

场景、任务、基准数据集与评测指标

“场景”、“任务”、“基准数据集”和“指标”是评测领域中一些常用术语，因此在继续之前理解它们的含义至关重要。

场景

场景是指评测或测试LLM性能时所涉及的一系列广泛背景/环境或条件。例如：

问题回答
推理
机器翻译
文本生成与自然语言处理。

在LLMs领域已有多个流行基准测试，例如 MMLU、HellaSwag 和 BIG-Bench Hard。

任务

尽管听起来简单，但任务可视为场景的更细化形式。它更具体地说明了LLM的评测依据。一个任务可以由许多子任务组合（或分组）而成。

例如，算术可被视为一项任务。其中明确指出它通过算术问题评测LLMs。在此之下，可以有许多子任务，如算术一级、二级等。本例中，所有算术子任务（从一级到五级）共同构成了算术任务。

同样，我们可以将多项选择作为一项任务。在此之下，我们可以有关于历史、代数等的多项选择作为所有子任务。事实上，MMLU 完全基于多项选择题。

指标

指标可定义为用于评测语言模型在特定任务/场景下表现的定性度量。指标可以是简单的：

确定性统计/数学函数（例如：准确率）
或由神经网络或机器学习模型生成的评分（例如：BERT 分数）
或借助LLMs自身生成的评分（例如：G-Eval）

这里先简要概述一下：

图 1：LLM评测中使用的不同指标的简化分类法

上述图表试图简化用于LLM评测的不同类型指标分类的体系结构。一个指标也可以由不同的原子/细粒度指标组合而成。一个非常简单的例子是 F1 分数，它是精确率和召回率的调和平均数。

同样在自然语言处理（NLP）中，BLEU（双语评测替补）分数由精确度、简短惩罚和 N-gram 匹配组成。如果你愿意，也可以将不同的指标组合起来，形成一个新的指标。

基准数据集

基准数据集是一种标准化的测试集集合，用于评测LLMs在特定任务或场景下的表现。以下是一些例子：

在后续章节展示的大多数案例中，你会发现一个场景往往包含大量基准数据集。一项任务可能由多个子任务构成，而每个子任务又可能包含一系列数据集。当然，也可能只是某个任务下直接包含若干基准数据集的情况。

当前用于评测LLMs的研究框架

图 2：流行的LLM基准测试框架

在本节中，我们将探讨各种基准测试框架及其提供的功能。请注意：目前命名规范尚未统一，初次接触时可能会感到非常困惑，请耐心跟随我的讲解。

语言模型评测工具链（由 EleutherAI 开发）

语言模型评测工具链提供了一个统一框架，用于在大量评测任务中对LLMs进行基准测试。我特意强调了“任务”一词，因为工具链中并不存在“场景”的概念（后文将用“工具链”代指“语言模型评测工具链”）。

在 Harness 平台下，我们可以看到众多任务，这些任务包含不同的子任务。每个任务或一组子任务会针对不同领域（如生成能力、多领域推理等）评测一个LLM。

每个任务下的子任务（有时甚至是任务本身）都配有基准数据集，且这些任务通常与评测领域的重要研究相关联。Harness 致力于将所有这些数据集、配置及评测策略（如评测基准数据集的相关指标）统一结构化，并集中管理。

不仅如此，Harness 还支持多种LLM后端（例如：VLLM、GGUF 等），提供了高度可定制化的提示词修改与实验功能。

这是一个简单示例，展示如何轻松评测 Mistral 模型在 HellaSwag 任务（用于评判LLM常识能力的任务）上的表现。

lm_eval --model hf \
    --model_args pretrained=mistralai/Mistral-7B-v0.1 \
    --tasks hellaswag \
    --device cuda:0 \
    --batch_size 8

受 LM 评测工具包的启发，BigCode 项目推出了另一个名为 BigCode 评测工具包的框架，旨在为代码生成任务中的LLMs提供类似的 API 和 CLI 评测方法。

斯坦福 HELM

HELM（语言模型整体评测）通过“场景”描述语言模型的应用领域，并通过“指标”明确在基准测试中期望LLMs完成的任务。一个场景包含以下要素：

一项（与场景相匹配的）任务
一个领域（包括文本所属的体裁、作者及其创作年代）
语言（即任务所使用的语言）

HELM 随后尝试根据社会相关性（例如考虑面向用户应用的可靠性场景）、覆盖范围（多语言性）及可行性（即选择计算得出的任务最优显著子集进行评测，而非逐一运行所有数据点）来确定场景和指标的优先子集。

图 3：HELM 的评测分类结构

不仅如此，这个 HELM 框架还试图覆盖几乎所有场景下的 7 项指标（准确性、校准性、鲁棒性、公平性、偏见性、毒性及效率），因为仅凭准确性无法为LLM的性能提供最高可靠性的保证。

PromptBench（微软出品）

PromptBench 是另一个用于评测LLMs的统一库。与 HELM 和 Harness 极为相似，它支持多种LLM框架（例如 Hugging Face、VLLM 等）。其与众不同之处在于，除了评测任务外，它还支持评测不同的提示工程方法，并对LLMs在提示层面的对抗性攻击进行评测。我们还能构建不同评测的流水线，这使得生产级用例的实现更为便捷。

ChatArena（由 LMSys 开发）

与以往的基准测试框架不同，该框架尝试以独特方式解决基准测试问题。此平台特点在于针对特定提示进行匿名随机化的LLMs对战，并通过用户投票LLM（保持匿名性）来评判哪方表现更优。

如上图所示，你可以输入提示词并与两个匿名LLMs（模型 A 和 B）互动。两个模型分别生成回答后，由你选择表现更优者。操作极其简单直观，却出色地实现了LLM性能量化。比较的量化是通过最大似然估计 Elo（MLE-Elo）评分（又称 Bradley-Terry 模型）完成的。

LmSys 还提供了一个排行榜，基于 MLE-Elo 评分对不同的主要LLMs进行排名。你可以在这里查看。

然而，关于LLMs的基准测试问题依然存在

到目前为止，我们已经深入研究了一些出色的研究及其各种实现方式。我们了解到：

框架（如 Harness 和 HELM）如何提出不同的分类法来构建评测任务的结构。
开源平台如 Chatbot Arena 如何简化对LLMs的基准测试。
像 PromptBench 这样的实现更侧重于生产场景（如提示注入攻击或对抗性攻击）。

然而，这些系统由许多不同的动态组件组成，如向量数据库、不同LLM工作负载（又称代理）的编排、提示工程、微调数据等，管理起来非常麻烦。

我们面临的另一个问题是研究与生产评测之间的差异。快速构建和微调LLMs并投入生产并非易事，且不考虑成本和推理优化，生产级评测基础设施是另一个重要瓶颈。让我详细解释一下。

正如我们都能认同的那样，测试是传统快速软件开发中不可或缺的重要组成部分（例如在 Python 中，PyTest 在测试环节扮演着关键角色），它也被应用于 CI/CD 流程中，在软件发布新更新前进行验证，从而使开发流程更加顺畅可靠。

然而，我们目前缺乏针对LLMs的类似 Pytest 的测试框架。即便存在此类工具，由于LLMs本质上是概率性机器，这使得定义确定性测试用例变得不够充分。实时的全面测试与压力测试（红队演练）同样重要，但目前这类大规模实践尚未普及，阻碍了生产级生成式 AI 产品的开发进程。

由于LLMs需要持续微调（例如基于 RAG 的系统开发LLM时），这就要求基础设施具备以下能力：

在微调过程中进行同步评测
预生产/生产环境下的评测测试用例
大规模对LLMs和LLM系统进行红队测试/压力测试及 A/B 测试。
对将用于LLMs的数据进行评测与校正。

此刻若你认为 Harness 或 HELM 工具非常实用，那么你既对也错。尽管 HELM 和 Harness 为用户评测LLMs提供了巨大便利，但这些库均存在影子接口（文档未明确说明的 API 接口），且主要依赖命令行操作，不利于模型的快速原型开发。

最后，我们可能需要非常特定领域的评测，这超出了当前这些基准测试框架的范围。编写这些评测应该像为 PyTest 编写测试用例一样简单，对于LLMs的基准测试也是如此，而这些框架目前并不支持。

基准测试LLMs的最佳实践

尽管整个领域还非常新，但我们正看到一个新兴趋势，即从业者主要将LLMs用于非常具体的用例，如文本摘要、内部知识库的问答以及数据提取。在大多数情况下，LLMs需要评测其忠实度，同时也需要评测它们在其部署领域中的准确性。

因此，一个典型的开发生命周期：

从现有的开源LLM或闭源LLM开始。
将你的LLM适配到目标用例。我们可以通过提示工程（如思维链或上下文学习）实现，或利用 RAG 中的向量数据库提供更多上下文。也可对LLM进行微调，并结合前述方法充分释放LLM的性能。
投入生产时需为LLMs添加额外防护措施，并连接后端服务器以获取数据作为输入。

上述流程可分为两个阶段。

预生产评测。
后期制作评测。

预生产评测

在初始探索阶段，我们可以尝试以下每种组合：

LLM + 提示工程（如思维链或上下文学习）。
LLM + 提示工程 + 检索增强生成（RAG）。
微调LLM + 提示工程 + 检索增强生成（RAG）等方案效果最佳。

由于与LLMs合作是一项成本高昂的业务，我们需要在成本和质量之间保持完美的平衡。因此，实验是这一过程中的重要部分。我们还需要建立适当的评测基础设施，该设施应具备以下特点：

能够评测LLMs在不同提示词下的表现，并提供一个平台来排名哪些提示词组合效果最佳。
能够评测基于 RAG 应用场景中的检索引擎（包含检索模型），以了解在将上下文输入LLM之前，所检索到的内容在事实准确性上的表现。
能够评测在微调LLMs过程中生成的不同检查点，并判断哪些检查点效果最优。
可以从 HELM 或 Harness 获取一些标准化评分（即来自其目标领域下的标准化基准数据集）。这一点很重要，这样我们就能拥有一份评测记分卡（非常类似于模型卡或数据集卡），它是通用的且正逐渐标准化。
可以评测一个自定义的领域特定私有基准数据集，这样我们就能完全确定LLM在与生产环境相似的数据上表现如何。
可以评测LLMs的可靠性（即LLMs不应具有毒性或不忠实，也不应能被提示劫持等）及其准确性（即LLM的事实正确性如何）。
可以评测不同的流水线（如上文提到的组合），以了解哪种流水线组合效果最佳。
在将LLMs投入生产之前，必须对其进行严格的红队测试（特别是针对基于聊天的模型）。

生产后评测

一旦LLMs部署完成，以下是一些在将LLM流水线投入生产后可采用的重要最佳实践：

持续监控LLMs。这非常重要，以便我们能够为LLM应用的不满意输出维护近乎实时的警报系统。这也有助于轻松理解问题所在并进行修复。
明确的反馈机制，如指示器（例如，用户点赞/点踩评分），用于向LLM的生成提供反馈。
支持对LLM（以及基于 RAG 应用中使用的嵌入模型）进行持续微调和持续部署，以保持以客户为中心的生成效果，否则应用程序可能会面临最终的数据漂移问题。

实施LLM基准测试的最佳实践

若想练习为LLMs构建测试框架，从零开始实现所有功能是个绝佳选择。但若想直接使用现有成熟的LLMs评测框架，DeepEval 会是理想之选——我们已替你完成了所有繁重工作。

DeepEval 是LLMs的开源评测基础设施，它使得遵循评测流程的最佳实践变得像在 PyTest 中编写测试用例一样简单。以下是它为解决当前LLMs基准测试问题所提供的功能：

深度集成 PyTest 框架，提供高度相似的接口和装饰器语法，让你能够编写针对LLMs的领域特定测试用例，覆盖现有基准测试框架未能触及的使用场景。
提供 14 种以上预定义指标来评测基于LLMs/RAG 的系统，这些指标可在本地机器或使用 GPT 模型上运行。用户还可自由编写自定义评测指标，所有指标均自动集成至 DeepEval 的评测生态系统中。
将评测结果推送到 Confident AI（DeepEval 托管的平台），该平台允许你跟踪评测实验、调试评测结果、集中管理用于评测的基准数据集，并通过不同的无参考指标跟踪生产事件以持续评测LLMs。

不仅如此，诸如 LM-Evaluation Harness 的集成、以及使用 HuggingFace 在微调期间进行并发评估等多项新功能即将推出。若想深入了解 DeepEval，请查看⭐ GitHub 仓库⭐GitHub - confident-ai/deepeval: The LLM Evaluation Framework

from deepeval import assert_test
from deepeval.metrics import HallucinationMetric
from deepeval.test_case import LLMTestCase

def test_hallucination():
  metric = HallucinationMetric(minimum_score=0.5)
  test_case = LLMTestcase(input="...", actual_output="...")
  assert_test(test_case, [metric])

结论

在本文中，我们了解了当前的评测范式，并掌握了LLM基准测试/评测的相关术语。同时，我们也学习了一些关于评测基准测试及在不同任务或场景下比较LLMs的重要研究。最后，我们探讨了在生产用例中评测LLMs时存在的现有问题，并介绍了一些最佳实践，这些实践能帮助我们克服常见的生产相关问题，从而安全且自信地部署LLMs。