LLM 评估指标：终极 LLM 评估指南

尽管评估大型语言模型 （LLM） 的输出对于任何希望交付强大的 LLM 应用程序的人来说都是必不可少的，但 LLM 评估对许多人来说仍然是一项具有挑战性的任务。无论您是通过微调来改进模型的准确性，还是增强检索增强生成 （RAG） 系统的上下文相关性，了解如何为您的用例开发和决定适当的 LLM 评估指标集对于构建无懈可击的 LLM 评估管道至关重要。

本文将教您需要了解的有关 LLM 评估指标的所有信息，包括代码示例。我们将深入研究：

• 什么是 LLM 评估指标，它们如何用于评估 LLM 系统，常见的陷阱，以及是什么使出色的 LLM 评估指标变得出色。
• 对 LLM 评估指标进行评分的所有不同方法**，**以及为什么 LLM as-a-judge 是 LLM 评估的最佳选择。
• 如何使用 LLM-as-a-judge 构建确定性的、基于决策的 LLM 指标。
• 如何根据您的用例和 LLM 系统实施选择指标集
• 如何使用 DeepEval （⭐https://github.com/confident-ai/deepeval） 实现和决定在代码中使用的适当 LLM 评估指标集。

您准备好迎接长长的名单了吗？让我们开始吧。

什么是 LLM 评估指标？

LLM 评估指标（例如答案正确性、语义相似性和幻觉）是根据您关心的标准对 LLM 系统的输出进行评分的指标。它们对 LLM 评估至关重要，因为它们有助于量化不同 LLM 系统的性能，这些系统可以只是 LLM 本身。

LLM 评估指标架构

以下是在将 LLM 系统启动到生产环境之前可能需要的最重要和最常见的指标：

1. **答案相关性：**确定 LLM 输出是否能够以信息丰富且简洁的方式处理给定的输入。
2. **任务完成情况：**确定 LLM 代理是否能够完成它所设置的任务。
3. **正确性：**根据一些基本事实确定 LLM 输出是否真实正确。
4. **幻觉：**确定 LLM 输出是否包含虚假信息或虚构信息。
5. 工具正确性： 确定 LLM 代理是否能够为给定任务调用正确的工具。
6. **上下文相关性：**确定基于 RAG 的 LLM 系统中的检索器是否能够提取与您的 LLM 最相关的信息作为上下文。
7. **负责任的指标：**包括偏差和毒性等指标，这些指标确定 LLM 输出是否包含（通常）有害和冒犯性内容。
8. **特定于任务的指标：**包括摘要等指标，其中通常包含自定义标准，具体取决于用例。

虽然大多数指标都是通用的，而且是必要的，但它们不足以针对特定的使用案例。这就是为什么您需要至少一个特定于任务的自定义指标来使您的 LLM 评估管道生产准备就绪（如您稍后在 G-Eval 和 DAG 部分看到的那样）。例如，如果您的 LLM 应用程序旨在汇总新闻文章的页面，您将需要一个自定义的 LLM 评估指标，该指标的评分基于：

1. 摘要是否包含来自原始文本的足够信息。
2. 摘要是否包含与原文的任何矛盾或幻觉。

此外，如果您的 LLM 应用程序具有基于 RAG 的架构，您可能还需要对检索上下文的质量进行评分。关键是，LLM 评估指标根据 LLM 应用程序的设计任务来评估 LLM 应用程序。（请注意，LLM 应用程序可以简单地是 LLM 本身！

这给我们带来了最重要的一点 - 您选择的 LLM 评估指标应同时涵盖 LLM 用例和 LLM 系统架构的评估标准：

• **LLM 用例：**特定于任务的自定义指标，在不同实施中保持一致。
• **LLM 系统架构：**通用指标（例如，RAG 的忠实度、代理的任务完成度），具体取决于系统的构建方式。

如果您决定明天针对相同的 LLM 使用案例完全更改 LLM 系统，则您的自定义指标根本不应该更改，反之亦然。我们稍后将详细讨论选择指标的最佳策略（剧透：您不希望拥有超过 5 个指标），但在此之前，让我们先了解一下是什么让出色的指标变得出色。

出色的评估指标包括：

1. **定量的。**在评估手头的任务时，指标应始终计算分数。这种方法使您能够设置最小通过阈值，以确定您的 LLM 应用程序是否“足够好”，并允许您在迭代和改进实施时监控这些分数如何随时间变化。
2. **可靠。**尽管 LLM 输出可能不可预测，但您最不希望的就是 LLM 评估指标同样不稳定。因此，尽管使用 LLM（又名。LLM-as-a-judge 或 LLM-Evals），例如 G-Eval，尤其是 DAG，比传统的评分方法更准确，但它们往往不一致，这是大多数 LLM-Evals 的不足之处。
3. **准确。**如果可靠的分数不能真正代表 LLM 应用程序的性能，那么它们就毫无意义。事实上，使一个好的 LLM 评估指标变得伟大的秘诀是使其尽可能地符合人类的期望。

那么问题就变成了，LLM 评估指标如何计算可靠和准确的分数？

计算指标分数的不同方法

在我之前的一篇文章中，我谈到了 LLM 产出是出了名的难以评估。幸运的是，有许多成熟的方法可用于计算指标分数——有些利用神经网络，包括嵌入模型和 LLM，而另一些则完全基于统计分析。

指标评分器的类型

在本节结束时，我们将介绍每种方法并讨论最佳方法，因此请继续阅读以找出答案！

统计评分员

在我们开始之前，我想先说，在我看来，统计评分方法并不是必须学习的，所以如果你赶时间，请随时直接跳到“G-Eval”部分。这是因为每当需要推理时，统计方法的表现都很差，这使得它作为大多数 LLM 评估标准的评分器太不准确了。

要快速浏览它们，请执行以下作：

• **BLEU（双语评估替补）**评分员根据带注释的真实情况（或预期输出）评估 LLM 申请的输出。它计算 LLM 输出和预期输出之间每个匹配的 n-gram（n 个连续单词）的精度，以计算它们的几何平均值，并在需要时应用简洁性惩罚。
• ROUGE （Recall-Oriented Understudy for Gisting Evaluation） 评分器主要用于评估 NLP 模型的文本摘要，并通过比较 LLM 输出和预期输出之间 n 元语法的重叠来计算召回率。它确定参考文献中 LLM 输出中存在的 n-gram 的比例 （0–1）。
• **METEOR（Metric for Evaluation of Translation with Explicit Ordering）**评分器更全面，因为它通过评估精度（n 元语法匹配）和召回率（n 元语法重叠）来计算分数，并根据 LLM 输出和预期输出之间的词序差异进行调整。它还利用外部语言数据库（如 WordNet）来解释同义词。最终分数是精确率和召回率的调和平均值，对排序差异进行处罚。
• 编辑距离（或编辑距离，您可能认为这是一个 LeetCode 硬 DP 问题）评分器计算将一个单词或文本字符串更改为另一个单词或文本字符串所需的最小单字符编辑（插入、删除或替换）次数，这对于评估拼写更正或其他字符精确对齐至关重要的任务很有用。

由于纯粹的统计评分器几乎不考虑任何语义并且推理能力极其有限，因此它们对于评估通常冗长而复杂的 LLM 输出不够准确。但是，也有例外。例如，您稍后将了解到，评估 LLM 代理的工具调用准确性的工具正确性指标（向下滚动到底部的“代理指标”部分）使用带有一些条件逻辑的精确匹配，但这种情况很少见，不应被视为 LLM 评估的标准。

基于模型的评分器

纯粹统计的评分器是可靠的，但不准确，因为它们很难考虑语义。在本节中，情况恰恰相反 — 纯粹依赖 NLP 模型的评分器相对来说更准确，但由于它们的概率性质，它也更不可靠。

这应该不足为奇，但是，不是基于 LLM 的评分员的表现比 LLM 作为裁判的表现更差，这也是由于统计评分员的原因相同。非 LLM 评分员包括：

• NLI 评分器，它使用自然语言推理模型（这是一种 NLP 分类模型）对 LLM 输出对给定参考文本在逻辑上是否一致（蕴涵）、矛盾或不相关（中立）进行分类。分数通常介于蕴涵（值为 1）和矛盾（值为 0）之间，提供逻辑连贯性的度量。
• BLEURT （Bilingual Evaluation Understudy with Representations from Transformers） 评分器，它使用 BERT 等预训练模型对一些预期输出的 LLM 输出进行评分。

除了不一致的分数外，现实情况是这些方法还存在几个缺点。例如，NLI 评分器在处理长文本时也可能难以提高准确性，而 BLEURT 则受到其训练数据的质量和代表性的限制。

所以，我们开始吧，让我们来谈谈 LLM 评委。

G-评估

G-Eval 是最近开发的一个框架，来自一篇题为“使用 GPT-4 进行 NLG 评估与更好的人工对齐”的论文，该论文使用 LLM 来评估 LLM 输出（又名。LLM-Evals），并且是创建特定于任务的指标的最佳方法之一。

G-Eval 算法

G-Eval（此处为文档）首先使用思维链 （CoT） 生成一系列评估步骤，然后使用生成的步骤通过表单填写范式确定最终分数（这只是一种花哨的说法，即 G-Eval 需要几条信息才能工作）。例如，使用 G-Eval 评估 LLM 输出一致性涉及构建一个提示，其中包含要评估的标准和文本以生成评估步骤，然后使用 LLM 根据这些步骤输出 1 到 5 的分数。

让我们使用此示例来运行 G-Eval 算法。首先，要生成评估步骤：

1. 向您选择的 LLM 介绍一个评估任务（例如，根据连贯性将此输出从 1-5 分打分）
2. 为您的标准给出定义（例如。“连贯性 — 实际输出中所有句子的集体质量”）。

（请注意，在最初的 G-Eval 论文中，作者仅使用 GPT-3.5 和 GPT-4 进行实验，并且亲自为 G-Eval 尝试过不同的 LLM，我强烈建议您坚持使用这些模型。

生成一系列评估步骤后：

1. 通过将评估步骤与评估步骤中列出的所有参数连接起来来创建提示（例如，如果您希望评估 LLM 输出的连贯性，则 LLM 输出将是必需的参数）。
2. 在提示的末尾，要求它生成一个介于 1 到 5 之间的分数，其中 5 比 1 好。
3. （可选）从 LLM 中获取输出标记的概率以标准化分数，并将它们的加权总和作为最终结果。

第 3 步是可选的，因为要获得输出标记的概率，您需要访问原始模型嵌入，这并不能保证对所有模型接口都可用。然而，论文中引入了这一步，因为它提供了更细粒度的分数并最大限度地减少了 LLM 评分中的偏差（如论文所述，众所周知，3 在 1-5 范围内具有更高的标记概率）。

以下是该论文的结果，它显示了 G-Eval 如何优于本文前面提到的所有传统的非 LLM 评估：

较高的 Spearman 和 Kendall-Tau 相关性表示与人类判断的一致性较高。

G-Eval 很棒，因为作为 LLM-Eval，它能够考虑 LLM 输出的完整语义，使其更加准确。这很有意义 — 想想看，非 LLM 评估（它使用的能力远不如 LLM 的评分器）如何可能理解 LLM 生成的全部文本范围？

尽管与同类产品相比，G-Eval 与人类判断的相关性要大得多，但它仍然可能不可靠，因为要求 LLM 得出分数无疑是武断的。

话虽如此，考虑到 G-Eval 的评估标准非常灵活，我个人已将 G-Eval 作为 DeepEval 的指标，DeepEval 是我一直在研究的一个开源 LLM 评估框架（其中包括原始论文中的标准化技术）。

# Install
pip install deepeval
# Set OpenAI API key as env variable
export OPENAI_API_KEY="..."
from deepeval.test_case import LLMTestCase, LLMTestCaseParams
from deepeval.metrics import GEval

test_case = LLMTestCase(input="input to your LLM", actual_output="your LLM output")
coherence_metric = GEval(
    name="Coherence",
    criteria="Coherence - the collective quality of all sentences in the actual output",
    evaluation_params=[LLMTestCaseParams.ACTUAL_OUTPUT],
)

coherence_metric.measure(test_case)
print(coherence_metric.score)
print(coherence_metric.reason)

G-Eval 是创建 LLM 作为判断指标的最流行方法之一，因为它简单、容易且准确。如果您有兴趣，可以在此处了解有关 G-Eval 的所有信息。

DAG （深度无环图）

G-Eval 在涉及主观性的评估情况下非常有用。但是，当您有明确的成功标准时，您将需要使用基于决策的评分器。想象一下：您有一个文本摘要用例，您希望在医院环境中格式化患者的病史。您需要在摘要中以正确的顺序添加各种标题，并且只有在所有内容格式都正确的情况下才能为其分配满分。在这种情况下，对于特定约束组合，您希望的分数非常清楚，则 DAG 评分器是完美的。

顾名思义，DAG（深度无环图）评分器是由 LLM 作为法官提供支持的决策树，其中每个节点都是一个 LLM 判断，每条边都是一个决策。最后，根据所采用的评估路径，将返回最终的硬编码分数（尽管您也可以使用 G-Eval 作为叶节点来返回分数）。通过将评估分解为细粒度的步骤，我们可以确定性地实现。DAG 的另一个用例是，过滤掉 LLM 输出甚至不满足评估最低要求的边缘情况。回到我们的摘要示例，这意味着格式不正确，并且通常您会发现自己使用 G-Eval 作为叶节点，而不是硬编码的分数来返回。

您可以在此处阅读有关 DAG 为何工作的更多信息，在本文中我讨论了 LLM 作为裁判（强烈推荐），但以下是用于文本摘要的 DAG 示例架构：

DAG 评分器架构

以下是 DeepEval 中的相应代码（文档在这里）：

from deepeval.test_case import LLMTestCase
from deepeval.metrics.dag import (
    DeepAcyclicGraph,
    TaskNode,
    BinaryJudgementNode,
    NonBinaryJudgementNode,
    VerdictNode,
)
from