以LLM为评委的规模化LLM评测权威指南

2025-08-12   出处： Confident AI  作/译者：Jeffrey Ip/Yilia

​​

最近，我听到“LLM as a Judge”这个术语的频率比以往任何时候都高。虽然这可能是因为我从事LLM评测领域的工作，但LLM评委正在接管，因为很明显，与速度慢、成本高且劳动密集型的人类评测者相比，它是LLM评测的更好替代方案。

然而，LLM 评委确实存在局限，不加谨慎地使用只会带来挫败。本文将分享我目前所知的关于利用 LLM 评委进行 LLM（系统）评测的一切要点，包括：

  • 什么是作为评委的 LLM，以及它为何如此受欢迎。
  • 作为评判备选方案，以及它们为何不尽如人意。
  • 评委的局限性及其应对方法。
  • 通过 DeepEval（ https://github.com/confident-ai/deepeval）在LLM评测指标中使用LLM评委进行LLM评测。

等不及了？我也是。

（更新：你现在还可以在 DeepEval 中使用LLM-as-a-judge 进行确定性LLM指标评测！）

“LLM 作为评委”具体是什么意思？

LLM-as-a-Judge 是一个强大的解决方案，它利用 LLMs 根据你选择的任何特定标准来评测 LLM 的响应，这意味着使用 LLMs 执行 LLM（系统）评测。正如“使用 MT-Bench 和 Chatbot Arena 评判LLM-as-a-Judge”论文中所介绍的那样，作为昂贵且耗时的人工评测的替代方案，三种类型的LLM作为评委包括：

  • 单输出评分（无参考）：向评委LLM提供评分标准作为评判依据，并提示其根据多种因素为LLM的响应分配分数，这些因素包括输入到LLM系统的内容、RAG 管道中的检索上下文等。
  • 单输出评分（带参考）：与上述相同，但有时LLM评委可能会不稳定。提供一个参考、理想或预期输出有助于评委LLM返回一致的分数。
  • 成对比较：给定两个LLM生成的输出，评委LLM将根据输入选择哪一个生成结果更好。这还需要一个自定义标准来确定什么是“更好”。

概念很简单：为LLM提供一个评测标准，让它为你完成评分工作。但具体如何以及在何处使用LLMs来评判LLM的回应呢？

​​

使用LLM 评委作为指标评分者

“LLM 作为评委”可用于增强LLM评测，方法是将其作为LLM评测指标的评分者。要开始使用，只需为你选择的LLM提供一个清晰简洁的评测标准或评分细则，并利用它根据各种参数（如你的LLM的输入和生成输出）计算一个范围在 0 到 1 之间的指标分数。以下是一个向LLM评委评测摘要连贯性的示例提示：

prompt = """
You will be given one summary (LLM output) written for a news article. 
Your task is to rate the summary on how coherent it is to the original text (input). 

Original Text:
{input}

Summary:
{llm_output}

Score:
"""

通过收集这些指标分数，你可以创建一套全面的LLM评测结果，用于基准测试、评测甚至回归测试LLM（系统）。

使用LLMs作为评分器来评测其他LLMs的LLM评价指标趋势日益增长，因为替代方案根本无法胜任。LLM评测对于量化和识别改进LLM系统性能的领域至关重要，但人工评测速度缓慢，而 BERT 和 ROUGE 等传统评测方法因忽视LLM生成文本中的深层语义而未能达标。试想，我们怎能期待传统且规模小得多的 NLP 模型不仅能有效评判开放式生成文本的段落，还能处理 Markdown 或 JSON 等格式的内容呢？

真的有效吗？

简而言之，是的，关于LLM作为评委的研究（参见上述论文）表明，它与人类判断的一致性甚至超过了人类彼此之间的一致性。而且不，你并不需要你的评测模型比你用于应用程序的那个更好。

一开始，使用LLM来评测另一个LLM生成的文本可能看起来有违直觉。如果模型正在产生输出，为什么它会更擅长评判或发现错误呢？

关键在于任务的分离。我们不再要求LLM重新执行其工作，而是使用不同的提示——甚至完全不同的模型——专门用于评测。这种方法能激活独特的能力，通常将任务简化为一个分类问题：评测质量、连贯性或正确性。发现问题往往比一开始就避免问题更容易，因为评测比生成更简单——LLM评委只需评测已产生的内容，比如检查相关性而无需改进答案。

除了评测提示从根本上不同之外，还有许多技术可以提高LLM作为评委的准确性，比如思维链提示（CoT prompting）和小样本学习（few-shot learning），我们稍后会详细讨论。我们还发现，将LLM评委的输出限制在极端值上，能使度量分数高度确定性。在 DeepEval 中，我们允许用户构建决策树——建模为有向无环图（DAG），其中节点是LLM评委，边代表决策——以创建高度确定性的评测指标，精确符合他们的标准。你可以在“DAG”部分了解更多相关内容。

（小插曲：在构建 DeepEval 的过程中，我实际上是通过艰难的方式才了解到，作为评判标准的LLM效果要好得多。最初，我依赖的是传统的非LLM指标，如 ROUGE 和 BLEU，它们基于词汇重叠来比较文本。但我很快发现用户抱怨这些分数即使对简单句子也缺乏准确性。更不用说其解释性的缺失了。）

LLM评判标准的替代方案

这一部分本不该存在，但以下是两种不使用LLMs进行LLM评测的流行替代方案，以及我个人认为它们被错误偏好的常见原因：

  • 人工评测：常被视为黄金标准，因其能理解上下文和细微差别。然而，这种方法耗时、昂贵，且可能因主观解读而不一致。现实中的LLM应用每月生成约 10 万条响应并不罕见。我不知道你怎么想，但我平均需要 45 秒来阅读几段文字并做出判断。这样算下来，每月大约需要 450 万秒，即连续约 52 天——不包含午餐休息时间——来评测每一条生成的LLM响应。
  • 传统自然语言处理评测方法：诸如 BERT 和 ROUGE 等传统评分工具确实出色——它们快速、经济且可靠。然而，正如我在之前一篇比较各类LLM评测指标评分工具的文章中指出的，这些方法存在两大致命缺陷：它们必须依赖参考文本来对比生成的LLM输出结果，并且由于忽视了LLM生成输出中的语义（这些语义常带有主观解读且呈现形式多样复杂，如 JSON 格式），其准确性极低。考虑到生产环境中的LLM输出往往是开放式的、无参考文本的，传统评测方法几乎难以胜任。

（此外，无论是人工还是传统的自然语言处理评测方法，都缺乏可解释性，即无法说明其给出的评分依据。）

因此，LLM 作为评委是目前最佳的选择。它们具有可扩展性，可以通过微调或提示工程来减少偏见，相对快速且成本低廉（尽管这取决于你对比的评测方法），最重要的是，能够理解极其复杂的生成文本，无论内容本身及其格式如何。考虑到这一点，让我们来看看LLM评委的有效性及其在LLM评测中的优缺点。

LLMs，比你想象的更爱评判

那么问题来了，LLM评委的准确性如何？毕竟LLMs是概率模型，仍然容易产生幻觉，对吧？

GPT-4 在成对和单输出评分上的一致性表明其拥有相对稳定的内部评测标准，这种稳定性还能通过思维链（CoT）提示进一步得到提升。

G-Eval

G-Eval 是一个利用 CoT 提示框架来稳定并使LLM评委在指标分数计算上更可靠和准确的系统（向下滚动了解更多关于 CoT 的信息）。

​​

G-Eval 算法

G-Eval 首先根据原始评测标准生成一系列评测步骤，并通过填表范式（这不过是 G-Eval 需要多条信息才能工作的另一种说法）利用这些生成的步骤来确定最终分数。例如，使用 G-Eval 评测LLM输出的连贯性时，需构建一个包含待评测文本及标准的提示来生成评测步骤，随后借助LLM基于这些步骤输出 1 至 5 分的评分（LLM Evaluation Metrics: The Ultimate LLM Evaluation Guide - Confident AI）。

正如你稍后将了解到的，G-Eval 中提出的技术实际上与我们用于改进LLM判断的各种技术相吻合。你可以通过 DeepEval（开源LLM评测框架）立即用几行代码实现 G-Eval。

pip install deepeval

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, coherence_metric.reason)
有向无环图（DAG）

G-Eval 存在一个问题，因为它不是确定性的。这意味着对于使用LLM作为评判指标的基准测试，你不能完全信任它。这并不是说 G-Eval 没有用处；事实上，它在需要主观判断的任务上表现出色，比如连贯性、相似性、答案相关性等。但当你有一个明确的标准时，比如文本摘要用例的格式正确性，你就需要确定性。

你可以通过将评测构建为有向无环图（DAG）来利用LLMs实现这一点。在这种方法中，每个节点代表一个LLM判断处理特定决策，而边则定义了决策间的逻辑流向。通过将LLM交互分解为更细粒度的原子单元，你减少了模糊性并确保与期望保持一致。分解得越细致，错位的风险就越小。

​​

DAG 架构

对于上述评测会议摘要用例的 DAG 图，以下是 DeepEval 中的对应代码（可在此处找到 DAG 的文档）：

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

correct_order_node = NonBinaryJudgementNode(
    criteria="Are the summary headings in the correct order: 'intro' => 'body' => 'conclusion'?",
    children=[
        VerdictNode(verdict="Yes", score=10),
        VerdictNode(verdict="Two are out of order", score=4),
        VerdictNode(verdict="All out of order", score=2),
    ],
)

correct_headings_node = BinaryJudgementNode(
    criteria="Does the summary headings contain all three: 'intro', 'body', and 'conclusion'?",
    children=[
        VerdictNode(verdict=False, score=0),
        VerdictNode(verdict=True, child=correct_order_node),
    ],
)

extract_headings_node = TaskNode(
    instructions="Extract all headings in `actual_output`",
    evaluation_params=[LLMTestCaseParams.ACTUAL_OUTPUT],
    output_label="Summary headings",
    children=[correct_headings_node, correct_order_node],
)

# create the DAG
dag = DeepAcyclicGraph(root_nodes=[extract_headings_node])

# create the metric
format_correctness = DAGMetric(name="Format Correctness", dag=dag)

# create a test case
test_case = LLMTestCase(input="your-original-text", actual_output="your-summary")

# evaluate
format_correctness.measure(test_case)
print(format_correctness.score, format_correctness.reason)

不过，我并不建议一开始就使用 DAG，仅仅因为它使用起来较为困难，而 G-Eval 几乎无需任何设置时间。你应该先尝试 G-Eval，再逐步迁移到像 DAG 这样更精细的技术。实际上，如果你想在运行 G-Eval 之前用 DAG 筛选出某些特定要求（如格式正确性），也是可以做到的。本文末尾有一个完整示例，其中我们将 G-Eval 作为叶节点使用，而非返回一个硬编码的分数。

LLMs 也并非完美无缺

  • 无法下定决心：他们的评分是非确定性的，这意味着对于正在评测的给定LLM输出，分数可能会因一天中的不同时间而有所变化。如果你想完全依赖这些评分，就需要一种像 DAG 这样的好方法来使它们变得确定。
  • 自恋偏差：研究表明，大型语言模型可能更倾向于青睐自身生成的答案。使用“可能”一词是因为研究发现，尽管 GPT-4 和 Claude-v1 分别以 10%和 25%更高的胜率偏爱自身输出，它们也会偏好其他模型，而 GPT-3.5 则未表现出自我偏好。
  • 多即是多：人类都熟知“少即是多”的说法，但LLM评委们往往偏好更冗长的文本而非简洁的表达。这在LLM评测中成为问题，因为LLM计算得出的评分可能无法准确反映LLM生成文本的质量。
  • 不太精细的评分标准：LLMs在做出高层次决策时可以是可靠的评委，例如判断二元事实正确性或在简单的 1-5 分制上对生成文本进行评分。然而，随着评分尺度变得更加详细，间隔更细，LLMs更可能产生随意分数，使其判断的可靠性降低，更容易受到随机性的影响。
  • 位置偏差：当使用LLM评委进行成对比较时，研究表明LLMs如 GPT-4 通常更倾向于第一个生成的LLM输出而非第二个。

此外，还有其他一些普遍考虑因素，例如LLM幻觉问题。但这并不意味着这些问题无法解决。在下一节中，我们将探讨一些技术方法来缓解这些限制。

提升LLM判断质量

思维链提示

思维链（CoT）提示是一种方法，通过提示模型明确表达其推理过程，在将 CoT 应用于LLM评委时，它涉及在提示中包含详细的评测步骤，而非模糊、高层次的评判标准，以帮助评委LLM进行更准确可靠的评测。这也有助于LLMs更好地符合人类预期。

这实际上是 G-Eval 所采用的技术，他们称之为“自动思维链”（auto-CoT），当然，该技术已在 DeepEval 中实现，你可以这样使用它：

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, coherence_metric.reason)
少量样本提示

少量样本提示是一个简单的概念，它通过包含示例来更好地指导LLM的判断。虽然由于包含更多输入令牌而计算成本更高，但少量样本提示已显示能将 GPT-4 的一致性从 65.0%提升至 77.5%。

除此之外，这里没有太多需要详细说明的内容，如果你曾尝试过不同的提示模板，就会知道在提示中添加几个示例可能是引导LLM生成输出的最有效方法。

使用输出令牌的概率

为了使计算出的评测分数更具连续性，我们不要求评委LLM在更细粒度上输出分数（这可能引入评分标准的随意性），而是让LLM生成 20 个分数，并利用LLM输出令牌的概率，通过计算加权总和来归一化分数。这减少了LLM评分中的偏差，平滑了最终计算出的指标分数，使其在不牺牲准确性的前提下更加连续。

额外提示：这一方法同样在 DeepEval 的 G-Eval 实现中得到了应用。

参考引导的判断

相较于单一输出和无参考判断，提供一个预期输出作为理想答案，有助于评委LLM更好地与人类期望对齐。在提示中，这可以简单地通过将其作为少量示例提示的一部分来实现。

限制 LLM 判断

与其将整个生成的输出交给LLMs进行评测，不如考虑将其分解为更细粒度的评测。例如，可以利用LLM驱动问答生成（QAG），这是一种计算非任意性分数的强大技术。QAG 是一种基于对封闭式问题回答“是/否”来计算评测指标分数的有效方法。举例来说，若想根据给定输入计算LLM输出的答案相关性，可先提取LLM输出中的所有句子，并确定与输入相关的句子比例。最终答案相关性分数即为LLM输出中相关句子的占比。某种程度上，我们之前讨论的 DAG 也运用了 QAG（我知道，开始觉得这些-AG 有点滑稽），尤其是在需要二元判断的节点上。关于 QAG 更完整的示例，可阅读这篇文章，了解如何利用 QAG 为各种不同的 RAG 和文本摘要指标计算分数。

QAG 是一种强大的技术，因为它意味着LLM评分不再随意，而是可以归因于一个数学公式。将初始提示分解为仅包含句子而非整个LLM输出，也有助于对抗幻觉，因为现在需要分析的文本量减少了。

交换位置

这里没有高深的技术，我们只需简单调换位置即可解决成对LLM评审中的位置偏差问题，并且仅当答案在两种顺序下均被偏好时才宣布胜出。

微调

对于更特定领域的LLM评审员，你可以考虑对类似 Llama-3.1 这样的开源模型进行微调和定制。如果你希望缩短推理时间并降低与LLM评测相关的成本，这也是一个选择。

使用LLM Judges 在LLM Evaluation Metrics 中

最后，LLM 评委可以且目前最广泛地用于评测LLM 系统，方法是将其作为评分者纳入LLM 评测指标中：

​​

关于如何将LLM评委用作记分员的提醒

一个好的LLM评测指标实现会运用所有提到的技术来提升LLM评分器性能。例如在 DeepEval中，我们已采用 QAG 来限定 RAG 指标（如上下文精确度）中的LLM判断，或为自定义指标（如 G-Eval）应用 auto-CoTs 和输出令牌概率归一化，最重要的是对所有指标采用少样本提示以覆盖广泛边缘案例。查看可立即使用的完整指标列表，请点击此处。

在本文的最后，我将展示如何用几行代码利用 DeepEval 的指标。你也可以在 DeepEval 的 GitHub 上找到所有实现，它是免费且开源的。

连贯性

你可能已经多次见过这个，一个可以通过 G-Eval 实现的自定义指标：

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, coherence_metric.reason)

请注意，我们为 G-Eval 开启了 verbose_mode 。当在 DeepEval 中启用详细模式时，它会打印出LLM评判的内部运作过程，并允许你查看所有中间评判结果。

文本摘要

接下来是摘要生成。我热衷于讨论摘要生成，因为它是用户通常对成功标准有清晰认知的用例之一。在文本摘要用例中，格式处理尤为重要。这里，我们将使用 DeepEval 的 DAG 指标，但稍作调整。不同于 DAG 章节中展示的代码实现，我们会先用 DAG 自动给不符合格式要求的摘要打 0 分，然后在 DAG 内部以 G-Eval 作为叶节点返回最终评分。这意味着最终分数并非硬编码，同时确保你的摘要满足特定要求。

首先，创建你的 DAG 结构：

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

g_eval_summarization = GEval(
    name="Summarization",
  criteria="Determine how good a summary the 'actual output' is to the 'input'",
  evaluation_params=[LLMTestCaseParams.INPUT, LLMTestCaseParams.ACTUAL_OUTPUT]
)

correct_order_node = NonBinaryJudgementNode(
    criteria="Are the summary headings in the correct order: 'intro' => 'body' => 'conclusion'?",
    children=[
        VerdictNode(verdict="Yes", g_eval=g_eval_summarization),
        VerdictNode(verdict="Two are out of order", score=0),
        VerdictNode(verdict="All out of order", score=0),
    ],
)

correct_headings_node = BinaryJudgementNode(
    criteria="Does the summary headings contain all three: 'intro', 'body', and 'conclusion'?",
    children=[
        VerdictNode(verdict=False, score=0),
        VerdictNode(verdict=True, child=correct_order_node),
    ],
)

extract_headings_node = TaskNode(
    instructions="Extract all headings in `actual_output`",
    evaluation_params=[LLMTestCaseParams.ACTUAL_OUTPUT],
    output_label="Summary headings",
    children=[correct_headings_node, correct_order_node],
)

# create the DAG
dag = DeepAcyclicGraph(root_nodes=[extract_headings_node])

然后，基于此 DAG 创建 DAG 指标并运行评测：

from deepeval.test_case import LLMTestCase
...

# create the metric
summarization = DAGMetric(name="Summarization", dag=dag)

# create a test case for summarization
test_case = LLMTestCase(input="your-original-text", actual_output="your-summary")

# evaluate
summarization.measure(test_case)
print(summarization.score, summarization.reason)

从 DAG 结构中可以看出，对于所有格式不正确的情况，我们返回 0 分，但之后会运行 G-Eval。你可以在此处找到 DAG 的文档。

上下文精确度

上下文精确度是一种 RAG 指标，用于确定 RAG 管道中检索到的节点是否按正确顺序排列。这一点很重要，因为LLMs往往会更多地考虑靠近提示末尾的节点（近因偏差）。上下文精确度通过 QAG 计算，其中每个节点的相关性由LLM评委根据输入内容判断。最终得分是一个加权累积精确度，完整解释可在此处查看。

from deepeval.metrics import ContextualPrecisionMetric
from deepeval.test_case import LLMTestCase

metric = ContextualPrecisionMetric()
test_case = LLMTestCase(
    input="...",
    actual_output="...",
    expected_output="...",
    retrieval_context=["...", "..."]
)

metric.measure(test_case)
print(metric.score, metric.reason)

结论

你成功了！这对LLM评委来说任务繁重，但至少我们现在了解了不同类型的LLM评委、他们在LLM评测中的角色、各自的优缺点，以及如何改进它们的方法。

LLM评测指标的主要目的是量化你的LLM（应用）性能，为此我们有不同的评分者，其中当前最佳的是LLM评委。当然，存在诸如LLMs在判断中表现出偏见等缺点，但这些可以通过思维链和少量示例提示进行工程优化。

‍

声明：本文为本站编辑转载，文章版权归原作者所有。文章内容为作者个人观点，本站只提供转载参考（依行业惯例严格标明出处和作译者），目的在于传递更多专业信息，普惠测试相关从业者，开源分享，推动行业交流和进步。 如涉及作品内容、版权和其它问题，请原作者及时与本站联系（QQ：1017718740），我们将第一时间进行处理。本站拥有对此声明的最终解释权！欢迎大家通过新浪微博（@测试窝）或微信公众号（测试窝）关注我们，与我们的编辑和其他窝友交流。
7° /77 人阅读/0 条评论 发表评论
请 登录 后发表评论
最新文章