核心评估评估方法LLM-as-a-Judge

LLM-as-a-Judge

LLM-as-a-Judge 是一种评估方法：用一个 LLM 去评估另一个 LLM 应用的输出质量。与仅依赖人工评审或简单启发式指标不同，你让一个能力强的模型（“judge”）按照预定义标准对应用输出进行打分并给出推理。

由于这种方式既兼具人类判断的细腻，又能像自动化评估一样大规模铺开，它已经成为评估 LLM 应用最受欢迎的方法之一。

LLM-as-a-Judge 的工作原理

核心思想很直接：把输入、应用的输出和评分 rubric 一起交给一个 LLM，让它对输出做出评估。judge 模型会产出一个分数以及解释其评估的链式推理。

一个典型的 LLM-as-a-Judge prompt 通常包含：

  1. 评估标准 —— 定义”好”是什么样的 rubric（例如 “如果答案事实错误打 1 分，如果完全准确并有出处打 5 分”）
  2. 输入上下文 —— 原始的用户 query 或 prompt
  3. 要评估的输出 —— 应用的回复
  4. 可选的参考 —— 用于对比的 ground truth 或期望输出

judge 模型随后返回结构化的分数和推理，可以被记录、聚合并随时间分析。

为什么使用 LLM-as-a-Judge？

  • 可扩展： 相比人工标注员，judge 可以快速评估上千条输出。
  • 类人判断： 比简单指标更能捕捉细微差别（例如有用性、毒性、相关性），尤其是在 rubric 引导下。
  • 可重复： 在 rubric 固定的情况下，重复运行同样的 prompt 可以获得一致的分数。

如何使用 LLM-as-a-Judge？

LLM-as-a-Judge 评估器可以在三种数据上运行：Observations（单次操作）、Traces（完整工作流）或 Experiments（受控的测试数据集）。具体选哪种，取决于你是在开发中测试、还是在监控生产环境，以及你需要的粒度。

决策树

需要评估哪种数据？

↓
线上生产数据
监控实时流量
↓
Observations （推荐）
单次操作：LLM 调用、检索、工具调用
Traces （旧方式）
完整工作流的执行
离线实验数据
在受控环境中测试
↓
Experiments
基于数据集的受控测试用例

生产实践：团队通常在开发阶段使用实验来验证变更，然后在生产环境部署 Observation 级别的评估器，以实现可扩展、精准的监控。

理解每种评估目标

评估线上生产流量，实时监控你的 LLM 应用表现。

在 trace 内部的单个 observation 上运行评估器 —— 例如 LLM 调用、检索操作、embedding 生成或工具调用。

为什么选择 Observations

  • 执行更快：评估在数秒内完成，而非数分钟。彻底消除评估延迟和积压。异步架构每分钟可处理上千次评估。
  • 操作级别的精度：通过 observation 类型筛选，只评估最终的 LLM 回复或检索步骤，而不是整个工作流。针对特定操作能够减少评估量和成本。
  • 可组合的评估：在同一 trace 内对不同操作运行不同的评估器。同时对 LLM 输出做毒性评估、对检索做相关性评估、对生成做准确性评估。
  • 组合筛选：将 observation 筛选条件（类型、名称、metadata）与 trace 筛选条件（userId、sessionId、tags、version）叠加。例如：“所有标签为 ‘customer-support’ 且属于高级用户的对话中的 LLM 生成”。

数据流转

在数据接入时，每个 observation 都会按照你的筛选条件进行匹配。匹配的 observation 被加入评估队列。评估任务随后被异步处理。分数会附加到具体的 observation 上，每个评估器为每个 observation 产生一个分数。根据筛选条件，可能有多个 observation 同时匹配，从而在一次 trace 上产生多个分数。

示例用例

  • 只评估最终对用户的聊天机器人回复的有用性
  • 监控所有面向客户的 LLM 生成的毒性分数
  • 通过针对文档检索 observation 跟踪 RAG 系统的检索相关性

一步步设置

创建一个新的 LLM-as-a-Judge 评估器

进入 Evaluators 页面并点击 + Set up Evaluator 按钮。

Evaluator create

设置默认模型

接着，定义评估使用的默认模型。这一步需要先配置好 LLM Connection。详情见 LLM Connections。

所选默认模型必须支持结构化输出，这一点至关重要。 这是我们系统正确解析 LLM judge 评估结果的前提。

选择一个评估器

Evaluator select

接下来，选择一个评估器。主要有两种方式：

Litefuse 提供了一份不断扩充的评估器清单，由我们以及 Ragas 等合作伙伴构建和维护。每个评估器都为某个特定质量维度沉淀了最佳实践的评估 prompt —— 例如 Hallucination、Context-Relevance、Toxicity、Helpfulness。

  • 开箱即用：无需自己写 prompt。
  • 持续扩展：未来会加入更多 OSS 合作伙伴维护的评估器，以及更多类型（例如基于正则表达式的评估器）。

选择要评估哪些数据

选好评估器和模型后，配置要在哪些数据上运行评估。参考上面的 How it works 一节，了解哪种方式更适合你的用例。

配置步骤

  1. 选择 “Live Observations” 作为评估目标
  2. 通过 observation 类型、trace 名称、trace 标签、userId、sessionId、metadata 等属性筛选到具体 observation
  3. 配置采样率（例如 5%）以控制评估成本和吞吐

前置条件

  • SDK 版本：Python v3+（基于 OTel）或 JS/TS v4+（基于 OTel）
  • 当按 trace 属性筛选时：要按 trace 级别属性（userId、sessionId、version、tags、metadata、traceName）筛选 observation，需要在埋点代码中使用 propagate_attributes()。否则 trace 属性不会出现在 observation 上。如果你按 trace 级别属性筛选但没有把这些属性传播到 observation，你的 observation 就不会被评估器命中。

映射变量并预览评估 prompt

接下来你需要告诉 Litefuse：你的 observation、trace 或实验条目中的_哪些属性_对应于 prompt 中变量的实际数据，从而让评估有意义。例如，你可能把系统记录的 observation input 映射到 prompt 的 {{input}} 变量，把 LLM 回复（observation output）映射到 prompt 的 {{output}} 变量。这一映射对评估的合理性和相关性非常关键。

  • Prompt 预览：在配置映射时，Litefuse 会展示用真实数据填充后的评估 prompt 实时预览。预览使用过去 24 小时中匹配筛选条件的历史数据。你可以在多个示例间切换，看它们的数据是如何填入 prompt 的，从而确认映射的正确性。
  • JSONPath：如果数据嵌套在 JSON 对象内部，你可以使用 JSONPath 表达式（如 $.choices[0].message.content）精确定位。
Filter preview

触发评估

要看到评估器跑起来，你需要发送 trace（最快），或通过 UI / SDK 触发一次实验运行（搭建时间更长）。请确保按你想触发评估的方式，在评估器设置中正确选择目标数据。

✨ 完成！你已经成功设置了一个会在你的数据上运行的评估器。

需要自定义逻辑？请改用 SDK —— 详见 Custom Scores 或一个外部 pipeline 示例。

调试 LLM-as-a-Judge 执行

每次 LLM-as-a-Judge 评估器执行都会创建一条完整的 trace，让你完全看清评估过程。这能帮你调试 prompt 问题、检查模型回复、监控 token 用量并追溯评估历史。

你可以通过在 tracing 表格中按环境 litefuse-llm-as-a-judge 进行筛选来查看 LLM-as-a-Judge 的执行 trace：

Tracing table filtered to litefuse-llm-as-a-judge environment

LLM-as-a-Judge 执行状态
  • Completed：评估成功完成。
  • Error：评估失败（点击执行 trace ID 查看详情）。
  • Delayed：评估遇到 LLM 提供方的速率限制，正在指数退避重试。
  • Pending：评估排队中，等待执行。

进阶话题

从 trace 级别迁移到 observation 级别评估器

如果你已经在 trace 上运行评估器，希望升级到 observation 级别以获得更好的性能与可靠性，请阅读完整的评估器迁移指南。

排查 observation 级别评估器问题

如果你的 observation 级别评估器没有执行，参见为什么我的 observation 级别评估器不执行？，了解常见原因和解决方案。

回填历史 observation 分数

你可以基于 observations 表中的历史数据运行 observation 级别的 LLM-as-a-Judge。这在你已经接入了生产数据，并希望用一个新的或更新过的评估器对匹配的 observation 进行追溯打分时非常有用。

前提：为该评估器开启 Fast Mode。如果想让同一个评估器也实时作用于新接入的数据，还需要升级到最新的 SDK：Python v4+ 或 JS/TS v5+。

回填分数的步骤：

  1. 打开 Traces 表。
  2. 筛选到你想回填的时间范围和 trace 条件。使用与评估器相同的筛选条件。
  3. 选中匹配的行。
  4. 点击 Actions → Evaluate。
  5. 按照评估流程在所选 trace 上运行评估器，为匹配的 observation 回填分数。

Tracing table with filters applied before backfilling observation-level evaluations

这个回填流程从 traces 表发起，但生成的分数会附加到每条 trace 内部匹配的 observation 上。

FAQ

什么是 LLM-as-a-Judge 评估？
LLM-as-a-Judge 是一种评估方法：用一个大型语言模型（“judge”）评估另一个 LLM 应用的输出质量。judge 模型接收输入、应用的输出和评分 rubric，然后产出一个分数及其推理。它是评估 LLM 应用最受欢迎的方法之一，因为它结合了类人判断和自动化扩展能力。
LLM-as-a-Judge 与人工评估相比有多准确？
研究表明，强的 LLM judge（例如 GPT-5 级别的模型）在许多质量维度上与人工评估的一致性可达 80-90%，与人类评注者之间的一致性相当。配合精心设计的 rubric 和清晰的评估标准，准确性会显著提升。为获得最佳效果，建议用一小批人工标注样例校准你的 LLM-as-a-Judge 配置。
哪些模型适合作为 LLM judge？
通常能力最强的模型评估效果最好。具备强指令遵循和推理能力的模型（如 GPT-4o、Claude Sonnet、Gemini Pro）被广泛使用。judge 模型应支持结构化输出，以便分数能被可靠解析。在 Litefuse 中，judge 模型通过 LLM Connections 配置。
LLM-as-a-Judge 的成本如何？
成本取决于 judge 模型和被评估输入的大小。一次典型评估的成本在 $0.01-0.10 之间。可以通过以下方式控制成本：(1) 采样评估部分 trace，(2) 针对具体 observation 而非完整 trace 评估，(3) 为更简单的评估选择性价比更高的 judge 模型。
能否用 LLM-as-a-Judge 评估 RAG？
可以。LLM-as-a-Judge 对 RAG 流水线特别有效。你可以评估 faithfulness（答案是否基于检索到的上下文？）、relevance（答案是否切题？）和 completeness（答案是否覆盖了所有相关信息？）。Litefuse 还集成了 RAGAS，提供专门的 RAG 评估指标。
核心概念标注队列
这个页面对你有帮助吗？
支持