最近，“用LLM当裁判”（LLM as a Judge）这个说法越来越火了。
我从事LLM评估工作，对这方面比较关注，不过，这一概念的流行确实有其原因。和人工评估相比，用LLM当裁判来评估LLM，优势明显，人工评估速度慢、成本高，还特别耗费人力。但LLM裁判也有自己的短板，如果盲目使用，只会让你焦头烂额。今天这篇文章，我就把自己目前了解到的关于用LLM裁判评估LLM（系统）的知识全分享给大家，内容包括：
什么是“用LLM当裁判”，为什么它备受青睐。
除了用LLM当裁判，还有哪些替代方案，为什么它们不太行。
LLM裁判存在哪些局限，又该如何解决。
如何通过DeepEval，在LLM评估指标里使用LLM裁判来评估LLM。
话不多说，咱们开始吧。
（PS：现在还能用LLM裁判来计算DeepEval里的确定性LLM指标啦！）
到底什么是“用LLM当裁判”？
“用LLM当裁判”，简单来说，就是用LLM根据你设定的特定标准，评估其他LLM给出的回复，也就是用LLM来开展LLM（系统）评估。在《Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena》论文 里，就把这种方式作为人工评估的替代方案提了出来，毕竟人工评估既费钱又耗时。用LLM当裁判主要有以下三种类型：
论文地址：https://arxiv.org/abs/2306.05685
单输出评分（无参考）：给裁判LLM一套评分标准，让它根据各种因素，比如LLM系统的输入、检索增强生成（RAG）流程里的检索上下文等，给LLM的回复打分。
单输出评分（有参考）：和上面类似，但LLM裁判有时不太稳定。提供一个参考的、理想的或者预期的输出，能帮助裁判LLM给出更一致的分数。
成对比较：给裁判LLM两个由LLM生成的输出，它会根据输入判断哪个更好。这也需要一套自定义标准来界定什么是“更好”。
这个概念理解起来并不复杂，给LLM一个评估标准，让它帮你打分就行。但具体该怎么操作，在哪些场景使用呢？
“用LLM当裁判”可以用来强化LLM评估，比如在LLM评估指标里，让它作为打分器。使用时，先给你选定的LLM一个清晰、简洁的评估标准或评分规则，然后让它根据各种参数，比如LLM的输入和生成的输出，计算出一个0到1之间的指标分数。下面是一个让LLM裁判评估总结连贯性的示例提示：
prompt = """
你会收到一篇新闻文章的总结（LLM输出）。
你的任务是评估这个总结与原文（输入）的连贯性。
原文：
{input}
总结：
{llm_output}
分数：
"""
收集这些指标分数，就能形成一套全面的LLM评估结果，用来对LLM（系统）进行基准测试、评估，甚至做回归测试。
用LLM作为LLM评估指标的打分器，来评估其他LLM，这种趋势越来越流行，原因很简单，其他替代方案都不太给力。LLM评估对于量化和找出LLM系统性能的改进方向至关重要，但人工评估速度太慢，而像BERT和ROUGE这样的传统评估方法，又会忽略LLM生成文本里更深层次的语义，难以达到预期效果。想想看，传统的、规模小得多的自然语言处理（NLP）模型，怎么能有效评判大段开放式生成文本，还有Markdown或JSON等格式的内容呢？
这方法真的可行吗？
简单来说，确实可行。相关研究（还是上面提到的那篇论文）表明，用LLM当裁判，和人工评判的一致性，甚至比不同人之间评判的一致性还要高。而且，你也不用担心评估用的模型不如你应用里使用的模型。
乍一看，用一个LLM去评估另一个LLM生成的文本，似乎有点违背直觉。模型既然生成了输出，它凭什么能更好地评判这个输出，或者发现其中的错误呢？
关键在于任务的分离。我们不是让LLM重新生成内容，而是用不同的提示，甚至是不同的模型专门用于评估。这样能激发模型不同的能力，通常会把评估任务简化成一个简单的分类问题，比如评估质量、连贯性或正确性。检测问题往往比一开始就避免问题要容易，因为评估比生成简单，LLM裁判只需要评估生成的内容，比如检查相关性，而不需要改进答案。
除了评估提示从根本上不同，还有很多方法可以提高用LLM当裁判的准确性，比如思维链提示（CoT prompting）和少样本学习，后面我们会详细介绍。我们还发现，把LLM裁判的输出限定在特定范围，能让指标分数更具确定性。在DeepEval里，用户可以构建决策树（建模为有向无环图（DAG），节点代表LLM裁判，边代表决策），来创建高度符合自己标准的确定性评估指标。在“有向无环图（DAG）”那部分，会有更详细的介绍。
（题外话：用LLM当裁判效果更好。一开始，我依赖像ROUGE和BLEU这样的传统非LLM指标，它们是基于单词重叠来比较文本的。但很快就有用户反馈，这些指标哪怕对简单句子的评分都不太准确，更别提解释评分原因了。）
用LLM当裁判的替代方案
其实这部分内容本可以不写，但确实有两种比较流行的替代方案，用来评估LLM。下面说说我认为大家错选它们的常见原因：
人工评估：人工评估常被视为评估的黄金标准，因为人能理解上下文和细微差别。但它耗时久、成本高，而且由于个人主观理解不同，评估结果可能不太一致。在实际应用中，一个LLM应用每月可能会生成大约10万条回复。就我自己来说，看完几段话并做出评估，平均要花45秒。这样算下来，每个月要花大约450万秒，差不多连续52天（还不算午休时间）才能评估完所有回复。
传统NLP评估方法：像BERT和ROUGE这样的传统评分器有不少优点，速度快、成本低、可靠性也不错。但就像我之前在比较各类LLM评估指标评分器的文章里提到的，这些方法有两个致命缺陷：一是必须有参考文本，才能和LLM生成的输出进行对比；二是准确率很低，因为它们会忽略LLM生成输出里的语义，而这些输出往往带有主观性，格式也很复杂（比如JSON）。考虑到实际应用中的LLM输出是开放式的，没有参考文本，传统评估方法很难满足需求。
（另外，人工评估和传统NLP评估方法都缺乏可解释性，也就是没办法解释给出的评估分数是怎么来的。）
这么看来，目前用LLM当裁判是最好的选择。它扩展性强，可以通过微调或提示工程来减少偏差；速度相对较快，成本也比较低（当然，这得看和哪种评估方法对比）；最重要的是，它能理解非常复杂的生成文本，不管内容和格式如何。了解了这些，下面我们来探讨一下用LLM当裁判在LLM评估中的有效性、优缺点。
LLMs比你想象的更有判断力
问题来了，用LLM当裁判到底有多准确呢？毕竟LLM是概率模型，还是会出现幻觉，对吧？
研究表明，如果使用得当，像GPT-4（没错，还是它）这样的前沿LLM，在成对比较和单输出评分中，与人工评判的一致性能高达85%。可能有人还持怀疑态度，但这个数据其实比不同人之间评判的一致性（81%）还要高。
GPT-4在成对比较和单输出评分中表现一致，这意味着它有一套相对稳定的内部评分规则，而且通过思维链提示（CoT），还能进一步提高这种稳定性。
G-Eval
G-Eval是一个框架，通过思维链提示（CoT）让LLM裁判在计算指标分数时更稳定、更可靠、更准确（往下看，能了解更多关于思维链提示（CoT）的内容）。
G-Eval首先会根据原始评估标准生成一系列评估步骤，然后通过填空范式，利用这些步骤来确定最终分数（这么说可能有点复杂，简单来讲，G-Eval需要一些信息才能发挥作用）。比如说，用G-Eval评估LLM输出的连贯性时，要先构建一个包含评估标准和待评估文本的提示，生成评估步骤，再让LLM根据这些步骤给出1到5分的评分。
后面你会发现，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），用LLM也能实现这一点。在这种方法里，每个节点代表一个处理特定决策的LLM裁判，边则定义了决策之间的逻辑流程。把LLM交互拆分成更细的原子单元，能减少模糊性，确保结果符合预期。拆分得越细，就越能避免不一致的情况。
上面这张有向无环图（DAG）是用来评估会议总结用例的，下面是在DeepEval里对应的代码：
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）这样更精细的技术。实际上，要是你想用有向无环图（DAG）先筛选出格式正确性等特定要求，再运行G-Eval，也是可以的。文章最后有完整示例，里面我们把G-Eval当作叶节点，而不是返回一个硬编码的分数。
LLMs并不完美
和大家想的一样，用LLM当裁判也不是十全十美的，它存在不少缺点：
结果不稳定：它给出的分数不具有确定性，也就是说，对于同一个待评估的LLM输出，不同时间得到的分数可能不一样。如果你想完全依赖它的评估结果，就得用有向无环图（DAG）这样的好方法让分数稳定下来。
自恋偏差：有研究表明，LLM可能会偏向自己生成的答案。这里用“可能”，是因为研究发现，虽然GPT-4和Claude-v1分别有10%和25%的更高胜率偏向自己，但它们也会偏向其他模型，而GPT-3.5则没有这种偏向。
内容多就更好：我们都知道“少即是多”，但LLM裁判往往更喜欢冗长的文本，而不是简洁的文本。这在LLM评估里是个问题，因为LLM计算出的评估分数可能无法准确反映生成文本的质量。
评分不够精细：在做一些宏观判断时，比如判断事实是否正确，或者用简单的1 - 5分制给生成文本打分，LLM还算靠谱。但当评分标准变得更细致，分数区间更小的时候，LLM给出的分数就很可能比较随意，导致评判结果不太可靠，随机性更大。
位置偏差：用LLM裁判进行成对比较时，像GPT-4这样的LLM通常会更青睐第一个生成的LLM输出。
此外，还有像LLM幻觉这样需要考虑的问题。不过，这些问题并非无法解决。下一部分，我们就来看看如何克服这些局限。
提升LLM评判能力的方法
思维链提示（CoT Prompting）
思维链提示（CoT Prompting），就是让模型阐述自己的推理过程。在使用思维链提示（CoT）辅助LLM裁判时，要在提示里加入详细的评估步骤，而不是模糊的宏观标准，这样能帮助裁判LLM做出更准确、更可靠的评估，也能让LLM的评判结果更好地符合人的预期。
实际上，这就是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)
少样本提示（Few-Shot Prompting）
少样本提示的概念很简单，就是在提示中加入一些示例，以此更好地引导LLM进行评判。由于会增加输入的token数量，所以这种方式在计算资源上的消耗会更大一些。不过研究显示，少样本提示能将GPT-4的评判一致性从65.0%提升到77.5% 。
关于少样本提示，其实没有太多复杂的内容。如果你曾尝试过不同的提示模板就会知道，在提示中添加几个示例，很可能是引导LLM生成理想输出最有效的方法之一。
利用输出token的概率
为了让计算出的评估分数更具连续性，避免让裁判LLM在更精细的评分尺度上输出分数（这可能会导致指标分数出现随意性），我们可以让LLM生成20个分数，然后利用LLM输出token的概率，通过计算加权求和的方式对分数进行归一化处理。这样做既能最大程度减少LLM评分中的偏差，还能让最终计算出的指标分数更加平滑、连续，同时也不会牺牲准确性。
值得一提的是，DeepEval的G-Eval实现中也采用了这一方法 。
参考引导评判
相较于无参考的单输出评判，为裁判LLM提供一个预期输出作为理想答案，能帮助其更好地符合人类预期。在提示中，你可以简单地将预期输出作为少样本提示中的一个示例。
限定LLM评判范围
不要让LLM一次性评估整个生成的输出，你可以考虑将其分解为更细粒度的评估。比如，利用LLM实现问答生成（QAG），这是一种计算非随意性分数的强大技术。问答生成（QAG）能基于对封闭式问题的“是/否”回答来计算评估指标分数。例如，如果你想计算LLM输出相对于给定输入的答案相关性，可以先提取LLM输出中的所有句子，然后确定与输入相关的句子比例，最终的答案相关分数就是LLM输出中相关句子的占比。从某种程度上来说，我们之前提到的有向无环图（DAG）也运用了问答生成（QAG）技术（特别是在需要进行二元判断的节点上）。
问答生成（QAG）之所以强大，是因为它能让LLM的评分不再随意，每个分数都能对应到一个数学公式。将最初的提示拆分为只包含句子，而不是整个LLM输出，还能减少需要分析的文本量，有助于应对模型幻觉问题。
交换位置
这方法没啥高深的，在成对的LLM裁判评估中，我们只需交换输出的位置，只有当一个答案在两种顺序下都被偏好时，才判定其获胜，以此来解决位置偏差问题。
微调
如果需要更具领域针对性的LLM裁判，你可以考虑对Llama-3.1这样的开源模型进行微调。如果你希望LLM评估过程的推理速度更快、成本更低，微调也是个不错的选择。
在LLM评估指标中使用LLM裁判
最后，LLM裁判目前最广泛的应用，就是作为LLM评估指标中的评分器，来评估LLM系统。
一个优秀的LLM评估指标实现，会运用上述所有技术来优化LLM裁判评分器。以DeepEval为例，在RAG指标（如上下文精度）中，我们使用问答生成（QAG）来限定LLM的评判范围；在自定义指标（如G-Eval）中，采用自动思维链提示（auto-CoT）和对输出token概率进行归一化处理；最重要的是，在所有指标中都运用少样本提示，以覆盖各种边缘情况。
文章最后，我给大家展示下如何用几行代码，调用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
from deepeval.metrics import GEval
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。
上下文精度评估
上下文精度是一个RAG指标，用于判断RAG流程中检索到的节点顺序是否正确。这一点很重要，因为LLM往往会更关注提示末尾附近的节点（近因偏差）。上下文精度是通过问答生成（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裁判是最佳选择。当然，LLM裁判也存在一些缺点，比如评判中可能存在偏差，但这些问题可以通过思维链提示（CoT）和少样本提示等提示工程方法来解决。
- END -