LLM 评估系统实战完全指南

今年早些时候，我写了《你的 AI 产品需要评估》。很多人问我：“该如何开始使用 LLM-as-a-Judge？”这篇指南分享了我在帮助 30 多家公司搭建评估系统后总结出的经验。

问题：AI 团队正被数据淹没

你是否曾花费数周构建一个 AI 系统，最后却发现自己根本不知道它是否真的有效？有这种经历的不止你一个。我注意到，团队在使用 LLM 评估 AI 输出时，总是在重复犯同样的错误：

指标过多： 创建大量衡量指标，最终变得难以管理。

随意的评分体系： 在多个维度上使用未经校准的量表（例如 1～5 分），不同分数之间的差异既不明确又主观。一项内容为什么是 3 分而不是 4 分？没人知道，而且不同评估者对这些量表的理解往往也不一样。

忽视领域专家： 没有让真正深入理解相关主题的人参与进来。

未经验证的指标： 使用无法真正反映用户或业务所关心事项的衡量指标。

结果呢？团队最终被堆积如山的指标或他们既不信任、也无法使用的数据所淹没。进展陷入停滞，每个人都感到沮丧。

例如，我经常会看到类似这样的仪表盘：

追踪一大堆采用 1～5 分量表的分数，往往意味着评估流程存在问题（稍后我会讨论原因）。在本文中，我会告诉你如何避开这些陷阱。解决方案是使用一种我称为“批评影随”（Critique Shadowing）的技术。下面让我们逐步了解具体做法。

第 1 步：找到首席领域专家

在大多数组织中，通常会有一位（也许两位）关键人物，他们的判断对 AI 产品能否成功至关重要。这些人要么拥有深厚的领域专业知识，要么能够代表你的目标用户。在流程早期识别并邀请这位首席领域专家参与至关重要。

为什么找到合适的领域专家如此重要？

他们制定标准： 这个人不仅定义了技术上什么是可接受的，还能帮助你了解自己正在构建的东西是否真的是用户想要的。

他们制定标准： 这个人不仅定义了技术上什么是可接受的，还能帮助你了解自己正在构建的东西是否真的是用户想要的。

捕捉未言明的期望： 让他们参与进来，可以帮助你发现其偏好和期望，而这些内容可能是他们一开始无法完整表达出来的。通过评估过程，你可以帮助他们明确，一次“过得去”的 AI 交互究竟应该是什么样子。

捕捉未言明的期望： 让他们参与进来，可以帮助你发现其偏好和期望，而这些内容可能是他们一开始无法完整表达出来的。通过评估过程，你可以帮助他们明确，一次“过得去”的 AI 交互究竟应该是什么样子。

判断的一致性： 组织中的不同人员可能对 AI 的表现持有不同意见。聚焦于首席专家，可以确保评估结果保持一致，并与最关键的标准对齐。

判断的一致性： 组织中的不同人员可能对 AI 的表现持有不同意见。聚焦于首席专家，可以确保评估结果保持一致，并与最关键的标准对齐。

主人翁意识： 让专家参与进来，会使他们在 AI 的开发过程中拥有切身利益。因为亲自参与塑造了 AI，他们会对其投入更多关注。最终，他们也更有可能认可这个 AI。

主人翁意识： 让专家参与进来，会使他们在 AI 的开发过程中拥有切身利益。因为亲自参与塑造了 AI，他们会对其投入更多关注。最终，他们也更有可能认可这个 AI。

首席领域专家的示例：

• 心理健康 AI 助手的首席领域专家可以是一位心理学家。
• 分析法律文书的 AI，其首席领域专家可以是一位律师。
• 客服聊天机器人的首席领域专家可以是一位客户服务总监。
• 教育类 AI 工具的首席领域专家可以是一位骨干教师或课程开发者。

在规模较小的公司中，这个人可能是 CEO 或创始人。如果你是一名独立开发者，那么你自己应当承担领域专家的角色（但请诚实评估自己的专业水平）。

如果你必须依赖管理层，就应该定期结合真实用户反馈来验证他们的假设。

许多开发者会尝试自己充当领域专家，或者找一个方便的人来代替领域专家（例如自己的上级）。这很容易酿成灾难。不同的人对于什么是可接受的会有不同意见，而你不可能让所有人都满意。真正重要的是让你的首席领域专家满意。

请记住：这不必占用领域专家太多时间。在本文后面的部分，我会讨论如何提高这一流程的效率。但他们的参与对于 AI 的成功绝对至关重要。

找到专家后，我们需要为他们提供合适的数据进行审查。接下来我们来谈谈该怎么做。

第 2 步：创建数据集

在首席领域专家加入后，下一步是构建一个数据集，用来捕捉 AI 将会遇到的问题。数据集必须足够多样化，并且能够代表 AI 在生产环境中将要面对的各种交互类型。

多样化的数据集为何重要

全面测试： 确保你的 AI 能够在广泛的情境中接受评估。

真实交互： 反映用户的真实行为，使评估更具相关性。

识别弱点： 帮助发现 AI 可能难以应对或容易产生错误的领域。

用于构建数据集的维度

你需要定义适合自身用例的维度。例如，以下是我经常用于 B2C 应用的维度：

功能： AI 产品的具体功能。

场景： AI 可能遇到并需要处理的情境或问题。

用户画像： 具有不同特征和需求的代表性用户类型。

功能、场景和用户画像示例

场景是 AI 需要处理的情境（而不是根据 AI 回复的结果来定义的）。

这种分类法并非通用

这种分类法（功能、场景、用户画像）并非通用于所有情况。例如，如果用户不会直接与你的 AI 交互，那么设置用户画像这一维度可能根本没有意义。核心思想是：你应该梳理出适合自身用例的维度，并生成覆盖这些维度的数据。在完成第一轮评估后，你很可能还需要对这些维度进行调整。

要构建数据集，你可以：

• 使用现有数据： 从 AI 系统中抽样真实的用户交互或行为。
• 生成合成数据： 使用 LLM 创建真实可信的用户输入，覆盖各种功能、场景和用户画像。

通常，你会将这两种方法结合起来，以确保全面覆盖。合成数据不如真实数据，但它是一个不错的起点。此外，我们只使用 LLM 生成用户输入，而不让它生成 LLM 回复或内部系统行为。

无论使用现有数据还是合成数据，都应确保对已定义的各个维度进行充分覆盖。

纳入系统信息

制作测试数据时，应在适当的地方使用你的 API 和数据库。这样可以创建更真实的数据，并触发正确的场景。有时，你需要编写简单的程序来获取这些信息。下面示例中的“假设”（Assumptions）列指的就是这一点。

用于生成用户输入的 LLM 提示词示例

下面是一些提示词示例，用于说明如何使用 LLM 为功能、场景和用户画像的不同组合生成合成用户输入：

生成合成数据

生成合成数据时，你只需要创建用户输入。然后将这些输入提供给你的 AI 系统，由它生成 AI 回复。务必完整记录所有内容，以便评估你的 AI。回顾一下，具体流程如下：

1. 生成用户输入： 使用 LLM 提示词创建真实可信的用户输入。
2. 将输入提供给你的 AI 系统： 把用户交互输入当前版本的 AI。
3. 捕获 AI 回复： 记录 AI 的回复，形成完整的交互。
4. 整理交互： 创建一个表格，用于存储用户输入、AI 回复和相关元数据。

这里没有唯一正确的答案。你至少要生成足够多的数据，确保每一种维度组合都有对应的示例（在这个简化示例中，就是功能、场景和用户画像）。不过，你还应该继续生成更多数据，直到觉得已经不再发现新的失败模式为止。根据具体用例的不同，我生成的数据量会有很大差异。

你可能会怀疑使用合成数据是否合理。毕竟，它不是真实数据，又怎么能成为一个良好的替代？根据我的经验，它的效果出人意料地好。我最喜欢的一些 AI 产品，例如 Hex，就使用合成数据来支持其评估：

"LLM 在生成优秀且多样化的用户提示示例方面表现出人意料地出色。这可以用于为应用功能提供支持，也可以悄悄地用于构建评估基准。如果这听起来有点像一条大语言模型蛇在吞自己的尾巴，我和你一样惊讶！我只能说：它行得通，就这样发布吧。" —— Bryan Bischof，Hex 公司 AI 工程主管

现在，你的数据集已就绪，接下来是最重要的部分：让你的领域主任专家评估这些交互。

第 3 步：引导领域专家做出通过/失败判断及评论

领域专家的工作是专注一件事："AI 是否实现了期望的结果？"不需要复杂的评分量表或多个指标。只需一个明确的通过或失败决定。除了通过/失败决定外，领域专家应该撰写一份评论，解释其推理。

为什么简单的通过/失败指标很重要？

清晰性和专注力：二元决定迫使每个人考虑真正重要的事情。它将评估简化为单一的、至关重要的问题。

清晰性和专注力：二元决定迫使每个人考虑真正重要的事情。它将评估简化为单一的、至关重要的问题。

可操作的见解：通过/失败判断易于解释和采取行动。它们帮助你快速确定 AI 是否满足用户的需求。

可操作的见解：通过/失败判断易于解释和采取行动。它们帮助你快速确定 AI 是否满足用户的需求。

强制明确期望：当领域专家必须判断交互是否通过或失败时，他们被迫清楚地表达他们的期望。这个过程揭示了关于 AI 应如何表现的细微差别和未明言的假设。

强制明确期望：当领域专家必须判断交互是否通过或失败时，他们被迫清楚地表达他们的期望。这个过程揭示了关于 AI 应如何表现的细微差别和未明言的假设。

高效使用资源：保持评估过程易于管理，特别是在刚开始时。你避免陷入可能还不有意义的详细指标中。

高效使用资源：保持评估过程易于管理，特别是在刚开始时。你避免陷入可能还不有意义的详细指标中。

评论的作用

除了二元通过/失败判断外，为 LLM 生成的输出撰写详细评论很重要。这些评论：

捕捉细微差别：评论允许你注意某事大部分正确但有待改进的地方。

捕捉细微差别：评论允许你注意某事大部分正确但有待改进的地方。

指导改进：详细的反馈提供了关于如何增强 AI 的具体见解。

指导改进：详细的反馈提供了关于如何增强 AI 的具体见解。

平衡简洁与深度：虽然通过/失败提供了明确的判决，评论则提供了理解判断推理所需的深度。

平衡简洁与深度：虽然通过/失败提供了明确的判决，评论则提供了理解判断推理所需的深度。

为什么要撰写评论？

实际上，领域专家可能并未完全内化所有判断标准。通过强制他们做出通过/失败决定并解释其推理，他们澄清了他们的期望，并为细化 AI 提供了宝贵的指导。

"但我的问题很复杂！"相信我——从简单开始会迫使你专注于真正重要的事情。如果需要，你之后可以引入更多复杂性。

优秀评论的例子

为了说明简单的通过/失败判断如何与详细的评论在实践中结合，这里是一个表格，展示了用户与 AI 助手交互的例子。该表格包括通过和失败的情况，评论解释了为什么 AI 获得该判断。在 AI 尽管存在关键问题仍然通过的情况下，评论突出了这些方面，并为何仍然总体通过进行了论证。对于失败的交互，评论解释了导致失败的关键要素。

这些例子表明 AI 可以获得"通过"和"失败"判断。在评论中：

对于通过的情况，我们解释了为什么 AI 成功地满足了用户的主要需求，即使存在可以改进的关键方面。我们强调这些改进领域，同时为总体通过判断辩护。

对于通过的情况，我们解释了为什么 AI 成功地满足了用户的主要需求，即使存在可以改进的关键方面。我们强调这些改进领域，同时为总体通过判断辩护。

对于失败的情况，我们识别了导致失败的关键要素，解释了为什么 AI 没有达到用户的主要目标或危害了用户体验或安全等重要因素。

对于失败的情况，我们识别了导致失败的关键要素，解释了为什么 AI 没有达到用户的主要目标或危害了用户体验或安全等重要因素。

最重要的是，评论应该足够详细，以便你可以在为 LLM 评判工具的少量样本提示中使用它。换句话说，它应该足够详细，使得新员工可以理解它。过于简洁是常见的错误。

请注意，与 AI 的用户交互示例已简化以简洁起见——但你可能需要为领域专家提供更多背景信息来做出判断。更多相关内容见后文。

此时，你不需要对 AI 失败的技术原因进行根本原因分析。很多时候，在深入细节之前先了解整体行为的感觉很有用。

开始时不要偏离二元通过/失败判断

常见的错误是偏离二元通过/失败判断。让我们重新审视之前的仪表板：

如果你的评估包含一堆 LLM 以 1-5 评分（或任何其他评分）进行评分的指标，你做错了。让我们深入了解原因。

这不可行：人们不知道如何处理 3 或 4。不能立即明显这个数字比 2 好在哪里。你需要能够说"这个交互通过是因为……"和"这个交互失败是因为……"。

大多数情况下，这些指标都无关紧要：每次我分析领域专家判断数据时，它们往往与这类指标无关。通过让领域专家做出二元判断，你可以找出真正重要的事情。

这就是为什么我讨厌许多评估框架附带的现成指标。它们倾向于误导人们。

对通过/失败判断的常见异议

"业务部门说这 8 个维度很重要，所以我们需要评估所有这些。"

"我们需要能够说出为什么交互通过或失败。"

我可以保证，如果有人说你需要在 1-5 评分上测量 8 件事，他们不知道自己在寻找什么。他们只是在猜测。你必须让领域专家主导，并通过评论做出通过/失败判断，这样你可以找出真正重要的事情。在这里坚守立场。

让领域专家轻松审查数据

最后，你需要消除审查数据的所有摩擦。我之前写过关于这个的文章。有时，你可以直接使用电子表格。在什么对领域专家最容易的方面是一个判断的问题。我发现我经常需要提供额外的背景信息来帮助领域专家理解用户交互，例如：

• 关于用户的元数据，如其位置、订阅等级等。
• 关于系统的额外背景，如当前时间、库存级别等。
• 资源，以便你可以检查 AI 的响应是否正确（例如：能够搜索数据库等）。

所有这些数据都需要在单个屏幕上呈现，以便领域专家可以在不跳过任何步骤的情况下审查它。这就是为什么我建议构建一个简单的网络应用来审查数据。

你需要多少个例子？

你需要的例子数量取决于任务的复杂性。我的启发式方法是我从大约 30 个例子开始，并持续到我不看到任何新的失败模式。从那里，我持续到我不再学习任何新东西。

接下来，我们将看看如何使用这些数据来构建一个 LLM 评判工具。

在查看数据后，你可能会在你的 AI 系统中发现错误。与其继续前进并构建一个 LLM 评判工具，你想修复任何明显的错误。记住，LLM 作为评判工具的全部要点是帮助你找到这些错误，所以如果你早点发现它们，那完全没问题！

如果你已经按照我之前的文章开发了第 1 级评估，你应该不会有任何普遍存在的错误。但是，这些错误有时候会漏掉。如果你发现了普遍性错误，修复它们并回到第 3 步。持续迭代，直到你觉得系统已经稳定。

第 5 步：迭代地构建 LLM 评判者

批评的隐藏力量

在你看到数据之前，你无法写出好的评判提示词。Shankar 等人的论文"谁来验证验证者？将 LLM 辅助评估与人类偏好对齐"很好地总结了这一点：

要评级输出，人们需要外化和定义他们的评估标准；但是，评级输出的过程帮助他们定义那些评估标准。我们称这一现象为标准漂移，它意味着在人类判断 LLM 输出之前完全确定评估标准是不可能的。

从专家示例开始

让我分享一个构建 LLM 评判者的真实例子，你可以应用到自己的用例中。当我帮助 Honeycomb 构建他们的 Query Assistant 功能时，我们需要一种方式来评估 AI 是否在生成好的查询。这是我们 LLM 评判提示词的样子，包括来自我们领域专家 Phillip 的少样本评价示例：

You are a Honeycomb query evaluator with advanced capabilities to judge if a query is good or not.
You understand the nuances of the Honeycomb query language, including what is likely to be
most useful from an analytics perspective.

Here is information about the Honeycomb query language:
{{query_language_info}}

Here are some guidelines for evaluating queries:
{{guidelines}}

Example evaluations:

<examples>

<example-1>
<nlq>show me traces where ip is 10.0.2.90</nlq>
<query>
{
  "breakdowns": ["trace.trace_id"],
  "calculations": [{"op": "COUNT"}],
  "filters": [{"column": "net.host.ip", "op": "=", "value": "10.0.2.90"}]
}
</query>
<critique>
{
  "critique": "The query correctly filters for traces with an IP address of 10.0.2.90 
   and counts the occurrences of those traces, grouped by trace.trace_id. The response 
   is good as it meets the requirement of showing traces from a specific IP address 
   without additional complexities.",
  "outcome": "good"
}
</critique>
</example-1>

<example-2>
<nlq>show me slowest trace</nlq>
<query>
{
  "calculations": [{"column": "duration_ms", "op": "MAX"}],
  "orders": [{"column": "duration_ms", "op": "MAX", "order": "descending"}],
  "limit": 1
}
</query>
<critique>
{
  "critique": "While the query attempts to find the slowest trace using MAX(duration_ms) 
   and ordering correctly, it fails to group by trace.trace_id. Without this grouping, 
   the query only shows the MAX(duration_ms) measurement over time, not the actual 
   slowest trace.",
  "outcome": "bad"
}
</critique>
</example-2>

<example-3>
<nlq>count window-hash where window-hash exists per hour</nlq>
<query>
{
  "breakdowns": ["window-hash"],
  "calculations": [{"op": "COUNT"}],
  "filters": [{"column": "window-hash", "op": "exists"}],
  "time_range": 3600
}
</query>
<critique>
{
  "critique": "While the query correctly counts window-hash occurrences, the time_range 
   of 3600 seconds (1 hour) is insufficient for per-hour analysis. When we say 'per hour', 
   we need a time_range of at least 36000 seconds to show meaningful hourly patterns.",
  "outcome": "bad"
}
</critique>
</example-3>

</examples>

For the following query, first write a detailed critique explaining your reasoning,
then provide a pass/fail judgment in the same format as above.

<nlq>{{user_input}}</nlq>
<query>
{{generated_query}}
</query>
<critique>

注意每个示例包含：

• <nlq> 标签中的自然语言查询 (NLQ)
• <query> 标签中的生成查询
• <critique> 标签中的评价和结果

在上面的提示词中，示例评价是固定的。一个更高级的方法是根据你要评判的项动态包含示例。你可以在关于持续上下文学习的这篇文章中了解更多。

与领域专家迭代提示词直到收敛

在这种情况下，我使用了一个低技术含量的方法来迭代提示词。我给 Phillip 发了一个电子表格，其中包含以下信息：

• 输出（通过或失败）

Phillip 随后用他自己版本的电子表格和他的评价填充。我用这个来迭代改进提示词。电子表格看起来像这样：

我还跟踪了一段时间内的一致性率，以确保我们正朝着好的提示词收敛。

在这个例子中，我们使用模型和人类评估者之间的一致性，因为我们的数据集大约是平衡的（大约 50% 的实例是失败）。但是，使用原始一致性一般不推荐，当类不平衡时可能会误导。相反，你通常应该分别测量精确率和召回率，以更准确地了解你的评判者的对齐情况。

我们只用三次迭代就达到了 LLM 和 Phillip 之间超过 90% 的一致性。因人而异，这取决于任务的复杂性。例如，Swyx 为 AI News（一个极其流行、具有高质量推荐的新闻聚合器）做过类似的过程数百次。这个产品正因为这个过程带来的质量而获得了重要的认可。

如何优化 LLM 评判提示词？

我通常手工调整提示词。我用 DSPy 之类的提示词优化器没有太多成功。但是，我的朋友 Eugene Yan 刚刚发布了一个名为 ALIGN Eval 的有前景的工具。我喜欢它，因为它简单有效。另外，不要忘记前面提到的持续上下文学习的方法——当正确实施时，它可能很有效。

在罕见的情况下，我可能会微调一个评判者，但我倾向于不这样做。我在常见问题部分谈论这个。

这个过程的人性化一面

这个过程中发生了一些意想不到的事情。Honeycomb 的领域专家 Phillip Carter 发现，审查 LLM 的评价帮助他更清楚地表达了自己的评估标准。他说：

"看到 LLM 如何分解它的推理，我意识到我对某些边界情况的判断方式并不一致。"

这是我反复看到的一个模式——构建 LLM 评判者的过程通常有助于标准化评估标准。

此外，由于这个过程迫使领域专家仔细查看数据，我总是会发现关于产品、AI 能力和用户需求的新见解。由此产生的好处往往比创建 LLM 评判更有价值。