LLM作为裁判：构建真正有效的评估器实用指南
大多数 AI 团队都在错误地衡量事物，使用错误的方式，并且让错误的人参与其中。典型的评估设置是这样的：一个 1 到 5 的李克特量表，少量示例，以及一个初级工程师进行数据统计。然后有人会构建一个 LLM 评判者来自动化这个过程——六个月后却想不明白为什么整个系统漏洞百出。
如果方法得当，将 LLM 用作评判者是一种强大的模式。但“方法得当”这个词在句子中承载了大量工作。本文是一个具体的指南，教你如何构建与实际质量相关联、捕获真实回归问题并经受住生产环境考验的评估器。
LLM 评判者在实践中为何失败
在构建 LLM 评判者之前，值得了解为什么这么多团队在使用它们时会遇到困难。研究估计，超过 90% 的团队发现 LLM-作为评判者的实施比预期更难。失败模式集中在几个反复出现的 模式中。
偏置问题真实存在且可衡量。 LLM 评判者表现出至少十二种有记录的偏置类型。其中影响最大的是：
- 位置偏置：仅仅交换两个待比较的响应的顺序，就能在代码评估任务上使准确率提高 10% 以上。评判者评估的不是质量，而是位置。
- 冗余偏置：较长的响应系统性地得分更高，无论额外的长度是否增加了价值。
- 熟悉度偏置：评判者偏爱与其训练分布模式匹配的输出。GPT-4 会给困惑度较低的输出打高分，而不管其实际质量如何。这与其说是自我偏好，不如说是风格上的熟悉度。
在专业领域，一致性率急剧下降。 在通用指令遵循方面，LLM 评判者与人类偏好的一致性率达到 80% 以上。但在医疗保健、法律和其他专家领域，这一比例下降到 60-70%——这在许多任务中几乎只比随机猜测好一点。
真正的问题通常是评估设计，而不是评判者本身。 无论是人类还是 LLM 进行评估，一个定义不明确的评估标准都会产生糟糕的判断。那些盲目效仿 LLM 评判者而不解决其基本评估方法的团队，最终只会得到一个更快、更便宜的同样糟糕的信号。
停止使用 1 到 5 分的量表
你可以在评估设置中做出的最有影响力的改变，就是从多点量表切换到二元通过/失败判断。
原因如下：当你要求某人给一个输出打“5 分中的 3 分”时，他们同时在做两件事——决定输出是否足够好， 以及在一个任意的量表上选择一个位置。第二个任务引入了噪声，掩盖了第一个任务。3 分和 4 分有什么区别？这并不一目了然，也不会在不同的审阅者之间或不同时间保持一致。
二元判断迫使你清晰表达。这个输出完成了任务，还是没有完成？这是一个有理有据的答案的问题。你可以更可靠地在二元标签上训练 LLM 评判者，而不是训练它来复制某人对 3 分和 4 分之间差异的直觉。
二元判断的关键伴侣是要求书面评论。当审阅者将某项标记为失败时，他们必须具体解释原因。这有两层作用：它使评估变得有理有据，并且它产生了你可以实际用来改进你的评判者和你的底层系统的内容。
批评影子评审流程
构建一个有效的 LLM 评判者的最可靠路径是一个迭代过程，它从领域专家开始，最终形成一个通过一致性得分证明其价值的自动化评估器。
第 1 步：确定合适的领域专家。 这不是团队中最资深的人，也不是最方便的人。这是拥有最深厚专业知识的人——是那种能发现微妙的错误医疗建议、法律上的不合逻辑之处，或技术上能运行但违反你系统不变性原则的代码片段的人。一个专家设定一致的标准，胜过三个善意的通才制造噪声。
第 2 步：构建一个多样化的评估数据集。 从三个维度进行结构化：
- 特征：你正在评估的具体功能
- 场景：边缘情况和失败模式（模糊输入、缺失上下文、偏离主题的查询）
- 角色：代表性用户（专家、新手、非母语使用者）
目标是至少 30 个示例。持续进行，直到你不再看到新的失败模式。混合使用真实的生产示例和合成输入效果很好——使用你实际的系统从 LLM 制作的输入中生成输出。
第 3 步：让专家使用通过/失败加书面评论进行评估。 评论必须具体。“这个回答没有帮助”不是评论。“这个回答建议增加剂量而没有检查患者的肾功能，这对于这类药物是禁忌的”才是评论。正是这种具体性使得少样本学习成为可能。
一个有用的副作用是：撰写评论的行为迫使专家阐明他们可能没有意识到的标准。评估标准通常只有通过评估过程才能变得清晰——这就是从业者所说的“评估标准漂移”。
第 4 步：在构建评判者之前修复普遍存在的失败。 如果 40% 的输出以相同的方式明显失败，请首先修复它。基于根本性失败输出构建的 LLM 评判者将学会区分不同程度的糟糕，这并没有用。
第 5 步：迭代地构建评判者。 将专家示例嵌入到你的评判者提示中，并根据专家的真实标签进行测试。分别跟踪精确率和召回率——当你的通过/失败分布不平衡时，原始的一致性率会产生误导。目标是达到 90% 以上的一致性，这通常需要两到三轮的完善。
第 6 步：执行错误分析。 按特征、场景和角色细分失败率。手动分类失败的根本原因。真正的洞察力存在于此——不是在总体准确率数字中，而是在理解评判者在哪种输入上犯错以及为什么犯错。
第 7 步：仅在需要时创建专门的评判者。 如果你的错误分析显示评判者在特定输入子集上系统性地失败，请为该子集构建一个专门的评判者。不要预先这样做。
生产架构：分层评估
最佳的评估系统采用分层架构，平衡了覆盖范围、成本和准确性：
第一层 — 自动化 LLM 评判器：处理 80-90% 的评估量。快速、廉价，在 CI/CD 中运行。在明显的回归问题到达生产环境之前捕获它们。
第二层 — 多评判器共识：对于不确定的情况和边界决策，运行多个评判器并要求它们达成一致。多评判器共识可以将科恩 Kappa 系数推至 0.95 范围——这比单评判器评估可靠得多。
第三层 — 人工审查：保留给高风险决策、新型故障模式以及自动化层的定期校准。人工审查的输出会反馈到你的专家数据集中。
这种架构还支持持续监控。随着时间推移，跟踪各层之间的一致性率。当第一层和第二层之间的分歧超出预期时，这表明你的评判器已经偏离了你的真实数据。当人类和你的自动化系统在特定输入类型上持续存在分歧时，你就发现了评估标准中的一个空白。
选择你的评判模型
没有哪个单一模型是所有任务的最佳评判器。选择取决于你的约束条件：
- GPT-4 类模型：经过充分研究的基线模型，对于短期评估具有强大的成本/速度平衡，在研究基准中被广泛用作参考点。
- Claude：提示缓存优势使其在你的评估标准冗 长且在多次评估中重复使用时具有成本效益。对于侧重策略或与合规性相关的标准特别有用。
- Gemini：长上下文窗口减少了需要比较长文档、文字记录或多轮对话的评估中的分块开销。
你在生产中使用的模型不必与你用于评估的模型相同。许多团队即使生产系统使用更便宜的模型，也会运行一个能力更强的模型作为评判器——质量差异可以证明成本是合理的。
一个注意事项是：在使用 LLM 评判器时，给定任务上哪个模型表现最佳的排名并不总是保持一致。一个用 GPT-4 构建的评判器可能会产生与用 Claude 构建的评判器不同的排名，即使两者都经过良好校准。如果你使用 LLM 评判器来比较不同的模型，这一点很重要。
你不能跳过的唯一规则
即使你在其他所有地方都走捷径——即使你自己是领域专家，即使你的评估数据已经结构良好——也有一条没有例外的规则：查看你的数据。
评估管道的商业价值不在于自动化评判器。它在于你对系统故障模式的理解。一个查看 200 个示例并手动分类 50 个故障的团队，会学到任何仪表板都无法告诉他们的东西。LLM 评判器是扩展这种理解的基础设施，而不是替代品。
聚合指标会随时间漂移。提示会改变。用户行为会转变。上个季度罕见的输入，这个季度变得普遍。那些保持高评估质量的团队，是那些定期重新审视原始示例、更新评估标准并将评估视为持续实践而非一次性产物的团队。
入门
如果你正在构建你的第一个 LLM 评判器，这条路径可能比看起来更简单：
- 选择你的系统最需要做对的一件事
- 找到最了解系统何时做错这件事的人
- 让他们评估 50 个示例并提供书面批评
- 构建一个评判器，使其判断与他们的判断一致性达到 90% 以上
- 在每次部署前在 CI/CD 中运行它
其他一切——专业的评判器、分层架构、校准管道——都基于这个基线工作的。在增加复杂性之前，先确保第一个评判器是正确的。
从 LLM 评估中获得最大价值的团队，并非拥有最复杂基础设施的团队。他们是那些从一个经过良好校准的评判器开始，并养成了实际阅读其失败案例习惯的团队。
