LLMs as a Judge: How to Know if Your LLM is Healthy

以LLM作为裁判：如何判断你的大语言模型是否健康

ByteByteGo

2026年9月14日

为什么在部署到生产环境前必须评估每个AI代理——以及如何操作（赞助内容）

如果你在没有离线验证的情况下部署AI代理，那么你的用户实际上在承担测试工作。获取实用框架，了解如何在AI代理投入生产前评估其生产就绪性。

通过本指南，你将学习如何：

• 构建涵盖核心用例、边缘情况和对抗性输入的注释测试数据集
• 设计能反映实际业务影响的确定性评估器和以LLM作为裁判的评估系统
• 在实验过程中端到端追踪多代理工作流，提前发现潜在故障
• 通过保持离线测试环境与生产环境一致，防止模型漂移

获取指南

大型语言模型（LLMs）本质上与其他软件系统一样，也是一种软件系统。但我们不能像测试普通软件系统那样来测试LLM。

例如，软件应用中的普通函数可以接收两个数字并始终返回相同的总和。然而，当我们向LLM提出相同的问题两次时，它很可能会生成两个措辞不同的答案。这两个答案都可能是可接受的。但这也让评估变得复杂。要评估LLM，我们必须测量其在各种情境下是否持续保持正常行为。

“以LLM作为裁判”是这个评估过程的重要组成部分。它涉及使用一个语言模型来评估另一个语言模型生成的输出。但仅有一个裁判模型是不够的。一个健康的LLM评估系统需要结合多种要素，包括传统软件测试、精心策划的示例、自动化检查、基于模型的评估、人工审核和生产监控。

在本文中，我们将详细探讨LLM评估的全过程。以下是我们将涵盖的内容：

• 什么构成了LLM应用的健康状态？
• 为什么普通测试不足以评估LLM？
• LLM评估的基本循环
• 用于重复测试LLM行为的黄金数据集
• 自动化指标：快速但有限的检查
• 以LLM作为裁判的含义
• 裁判模型评估答案的不同方式
• 人工评估与校准
• 评估技术栈

什么构成了LLM应用的健康状态？

在什么情况下我们可以称一个LLM是健康的？

答案非常简单。如果一个LLM能够持续生成有用的输出，同时在准确性、安全性、速度、可靠性和成本等方面保持在可接受的范围内，那么它就被认为是健康的。例如，考虑一个客户支持助手。我们不能仅通过一个简单的问题（如“它是否返回了正确的输出？”）来判断其健康状况。

我们需要考虑多个问题：

• 它是否理解了客户的问题？
• 根据公司文档，答案在事实层面是否正确？
• 它是否完整回答了问题？
• 它是否遵循了所需的语气和格式？
• 它是否避免编造不存在的政策？
• 它是否拒绝了不应回答的请求？
• 它是否在可接受的时间内做出了响应？
• 处理该请求的成本是否在可接受范围内？

正如我们所看到的，这些问题都与质量的不同维度相关，每个维度都很重要。我们可以拥有一个友好且相关性高的助手，但它可能会生成事实错误的答案。它可能准确但过于冗长，导致用户无法快速找到答案。它可能生成优秀的答案，但每次请求都需要30秒的时间。因此，在评估大型语言模型（LLM）时，我们必须衡量系统的多个方面。

我们还需要区分LLM的健康状况和应用程序的健康状况。我们不能简单地将模型标记为所有问题的根源。问题可能由各种来源引起。例如，我们可能有错误的提示、缺失的文档、检索逻辑不佳、错误的工具调用、过时的数据，或周围代码的更改。

为什么普通测试不足以评估LLM？

传统软件测试通常依赖于确定性行为。如果函数接收到已知输入，测试会期望特定输出。例如：

输入：add(2, 3)
预期输出：5

这种测试之所以有效，是因为存在一个确切的正确答案。然而，LLM的任务不同。例如，考虑问题“解释为什么密码重置链接可能会过期”。

一个可能的回答可能首先讨论安全性。另一个回答可能首先解释过期时间。即使底层答案正确，句子的写法可能完全不同。

三个特性使LLM评估变得复杂。

首先，LLM的输出不是确定性的。这是因为LLM使用基于概率的方法生成答案。我们可以使用相同的提示和模型，但答案可能不同。增加模型的温度只会增加变化。但即使设置低温，也无法使每个模型和基础设施组合完全可重复。

即使进行精确的字符串比较，也可能将许多有效答案标记为失败。例如，“支付被拒绝是因为信用卡过期”和“信用卡的过期日期导致支付失败”传达了相同的信息。

其次，质量是多维且部分主观的。我们无法对答案的详细程度、语气或组织方式设定普遍正确的标准。对开发人员合适的回答可能让客户感到困惑。在支持聊天中，简短的回答可能很有效。但在文档中，更长的回答可能更合适。

这并不意味着质量无法衡量。它只是意味着我们需要首先定义期望的质量。例如，“给出一个好答案”这样的目标过于模糊，无法测试。更好的选择可能是“直接回答问题，仅使用提供的政策，并解释所有必要步骤”。

第三，正确性也取决于上下文。例如，“此订单能否退款？”的答案取决于多个数据点，如订单日期、产品类型、账户状态、地区和当前退款政策。特定回答对一个客户可能是正确的，对另一个客户可能是错误的。

因此，要正确评估，我们必须包含模型可用的上下文。我们必须能够测试答案相对于该上下文的正确性。

当然，对于大型语言模型（LLM）应用中确定性部分，传统测试仍然是必要的。例如，JSON解析、权限检查、计算、数据库操作、API契约和工具执行等功能，应继续依赖常规的单元测试和集成测试。

基本评估循环

实用的LLM评估系统围绕一个重复流程构建，其工作方式如下：

• 收集具有代表性的测试用例。
• 在这些用例上运行应用。
• 使用多种评估方法检查生成的回答。
• 将结果与当前生产版本进行对比。
• 阻止或调查导致重大回归的变更。
• 监控真实生产流量，发现测试集遗漏的问题。
• 将新发现的失败案例重新加入测试集。

请参见下图：

最后一步至关重要。我们需要通过添加更多示例来持续完善有价值的评估数据集。随着真实用户不断暴露出意外问题、模糊指令、文档格式和系统失效的新方式，此类数据集会不断增长。

用于LLM行为重复测试的黄金数据集

黄金数据集是经过精心策划的输入集合，包含对理想响应应包含内容的详细说明。可以将其视为类似单元测试套件的工具。但与单元测试不同的是，我们不总是通过精确匹配来验证答案。

例如，退款助手的测试用例可能包含以下信息：

这种方案比提供一个完美撰写的参考答案更有价值。这是因为可能存在多种合理表达答案的方式。关键在于LLM能否在遵循既定约束条件的同时做出正确决策。

我们应创建的黄金数据集不应仅包含简单常规的请求，理想情况下应包含：

• 能代表大部分真实流量的常见请求。
• 错误回答可能导致严重损害的重要案例。
• 需要澄清的模糊问题。
• 信息中没有答案的问题。
• 嵌入在检索文档中的恶意或无关指令。
• 非常简短、非常长、写得差或包含多种语言的输入。
• 以往生产环境中的失败案例。
• 边界情况，例如恰好在最后允许日期完成的退货。

我们还应将数据集划分为不同组别。开发集可在提示语优化阶段使用，但应保留一个独立的验证集，在开发阶段保持较低可见度。否则，提示语可能会逐渐适应已知示例，却无法真正提升对真实用户的帮助效果。

我们不应将黄金数据集视为静态的输入输出对。根据应用需求，测试用例可能包含输入、源文档、预期事实、禁止声明、可接受的工具调用、评分标准以及可选的参考回答。

精确匹配检查适用于输出必须与预期值完全一致的情况。它在受约束的提取任务中表现良好，例如返回国家代码、分类标签或数据库标识符。但对于开放式自然语言答案，其效果较差。

正则表达式和模式验证器可以检查输出是否符合所需的结构。例如，一个应用程序可能需要包含 customer_id、issue_type 和 priority 等字段的有效 JSON。在这种情况下，验证器可以可靠地检查这些字段是否存在，以及它们的值是否使用了预期的类型。

程序性检查可用于验证 URL、引用、数值范围、必填短语、禁用短语、字数限制，或特定产品 ID 是否存在于数据库中。

BLEU（双语评估替补）和 ROUGE（面向召回的摘要评估替补）通过比较生成答案与参考答案中的单词或词序列来评估质量。BLEU 因在机器翻译中的应用而流行，而 ROUGE 常用于摘要任务。它们在某些大规模比较中可能有用，但主要关注文本重叠度的衡量。我们可能会得到一个单词排列不同但含义保持不变的回答。

其他语义相似性指标通过嵌入或专用评估模型比较回答的含义。这些指标比单词重叠更灵活，但我们仍不能将相似性等同于正确性。关于错误主题的错误答案仍可能与参考答案在语义上相似。

主要限制是自动化指标通常衡量的是狭窄且可观测的属性。它们应仅用于代码可以可靠检查的内容。

LLM-as-a-Judge 的含义

LLM-as-a-Judge 涉及将一个语言模型的回答发送给另一个语言模型，并要求该模型根据特定标准进行评估。

例如，考虑一个使用检索到的公司文档来回答问题的 RAG 助手。法官可能收到以下内容：

• 原始问题。
• 提供给助手的文档。
• 助手的回答。
• 评估标准。
• 可选的参考答案。

法官 LLM 随后可以评估相关性、事实支持、完整性、清晰度和遵循指令等属性。作为参考，一个简化的法官提示可能如下：

仅使用提供的政策来评估回答。

每个类别评分从 1 到 5：

准确性：
每个事实声明是否与政策一致？

完整性：
回答是否解决了问题的每个部分？

相关性：
是否始终关注客户的请求？

遵循指令：
是否避免了政策未支持的承诺？

返回包含评分、简要解释和任何未支持的声明的 JSON。

我们可以将法官模型的输出存储下来，与之前的评估运行结果进行比较。

与精确匹配相比，这种方法更加灵活，因为法官可以识别出措辞不同但表达相同想法的回答。它还可以识别细微的失败，例如仅回答问题的一半，或引入证据中可能不存在的声明。

法官模型评估答案的不同方式

有几种常见的评估答案的方法。让我们逐一详细探讨它们。

基于分数的评分

人类评估与校准

尽管在测试方面取得了所有进步，但模型能力的最终检验仍依赖于人类评估。

人类评估涉及人员使用相同的评分标准审查模型输出。这就是为什么当答案的正确性取决于法律、医疗、金融、科学或特定公司知识时，领域专家尤为重要。

然而，由于人类评估成本高且效率低，他们无法检查每个答案。他们最合适的角色通常是进行校准。为了实现这一点，人类审核员会对代表性样本进行评分。将结果与判断大语言模型（LLM）的评分进行比较。

例如，假设专家将100个答案标记为通过或失败。相同的答案由判断模型进行评估。该练习揭示了判断模型与专家意见一致的频率、其遗漏的失败类型以及是否需要调整其通过阈值。

人类审核员之间也可能存在分歧。这通常意味着评分标准有些模糊，或者任务本身确实具有主观性。因此，在将人类评分视为完美参考点之前，应先测量审核员之间的一致性。

对于大型语言模型（LLM）来说，人类评估仍然非常重要，包括：

• 创建和验证第一个评分标准。

• 审查高风险故障。

• 评估新型请求。

• 检查自动化评分是否反映真实价值。

• 调查不同评估者之间的意见分歧。

• 定期审计判断者是否存在偏差。

评估体系架构

在了解所有大语言模型评估方法后，现在可以整体审视评估体系架构。

我们应将这一评估体系理解为互补的层级结构，而非严格层级关系中某一层替代另一层。

• 底层是传统软件测试。用于验证权限、工具模式、数据库写入和计算等确定性组件。

• 黄金数据集提供可重复的测试场景，使整个大语言模型应用都能接受测试。

• 自动化检查可可靠测量属性，包括有效JSON格式、必填字段、精确提取值、引用结构和延迟时间。

• 大语言模型判断者评估需要模型理解语义的特性。可用于判断答案是否相关、完整、有证据支持，并符合详细评分标准。

• 人工审核员校准判断者，并处理那些后果或主观性过强、无法完全依赖自动化的案例。

• 生产环境监控完善了整个体系。测试集永远无法预见所有实际请求，因此需要生产环境信号来揭示新出现的故障。

结论

我们不应将大语言模型评估视为寻找完美准确率数字的过程。它是一个建立模型可信度的系统。

黄金数据集使关键场景可重复验证。自动化指标能快速检查具体且客观的属性。大语言模型判断者根据评分标准评估语义。人工审核员校准这些判断者并处理复杂决策。

因此，最可靠的问题不是简单地问"模型是否健康"？

而应是：在所有关键场景中，整个应用是否始终保持准确、有用、安全、可靠、快速且经济？同时，是否有足够的证据能检测到这些特性发生变化？

这才是大语言模型评估的真正目的。