如何为LLM评判编写可靠的评分规则

Follow up to Part 1: How to Design AI Evaluations You Can Actually Trust

在 Google，我们正在 GitHub 上发布一套面向 Google 产品和技术的 Agent Skills 系列。我们的团队希望测量这些技能的性能，以了解它们的表现如何。确定性测试（如检查生成的代码是否能编译）是理想选择。不幸的是，对于开放式问答或信息检索任务这类细微的生成式响应，很难大规模创建这类测试。

在上一篇文章中，我们探讨了「测什么」——即我们要求 agent 执行的评估动作。下一步是看「如何判断」agent 是否成功，即对 agent 的响应进行可靠且准确的评估。

为了大规模评估复杂输出，尤其是涵盖广泛领域且包含细微部分的 topics，我们采用「LLM-as-a-judge」方法。响应基于结构化评分规则（rubric）由基于模型的评分器进行评估。评判模型使用一组真/假问题评估每个响应。汇总后，这些答案提供响应的准确度得分。

给 LLM 一个模糊的 prompt 或主观问题会导致其响应产生歧义。这种歧义会引入噪声数据并导致评估不一致。最终，这会浪费你的 token 预算在毫无价值的指标上。

为了使这些评估更加可靠，你必须像对待正式规格说明一样对待你的评分规则。通过约束评判模型评估严格的、客观的布尔真值，可以降低幻觉发生的几率。因为评估严格的布尔真值是复杂度较低的任务，你甚至可以使用更小、更快的模型进行评分。

以下是我们学到的四个经验教训，帮助你为 LLM-as-a-judge 评分器编写健壮的评分规则问题。

Keep Questions Atomic and Distinct

在单个问题中评估多个要求，例如「响应是否包含元数据属性且将输出格式化为 JSON？」，会迫使 LLM 评判模型猜测哪个子句更重要。这种歧义导致评分不一致和 token 浪费。

拆分复合问题：不要写一个大检查，而是将你的需求分成离散的、原子化的 TRUE/FALSE 问题。（例如，检查 1：是否包含元数据属性？AND 检查 2：输出是否为 JSON？）

避免重叠问题：不要在评分规则中多次测试相同的底层概念。重叠可能导致单个错误被双重惩罚，从而破坏准确度得分。

降低推理负担：消除评判模型权衡竞争子句的需要。当每个问题只评估一个独立的事实时，评分就会更加一致。

Constrain the Judge: Objective Facts Over Subjective Reasoning

基于评分规则的方法之所以存在，是因为给 LLM 评判模型一个完整的散文式 prompt 来评估复杂响应会导致不一致的数字。如果你问评判模型主观问题如「这是一个全面的答案吗？」或让它解释「为什么 agent 这样做？」，你就会引入导致噪声、不可重复数据的歧义。

专注于可观察的事实：不要让评判模型评估需要解读的概念，如意图、质量或推理。只评估你期望在响应中找到的具体事实。

编写正式规格说明：使用严格、客观的语言，如 RFC 2119 术语（MUST、MUST NOT、REQUIRED），来测试可观察的结果。评判模型不应该需要猜测你的意思。

测试负面约束：明确验证 agent 不应该做什么。不要问 agent 是否「使用了最佳实践」，而是检查它没有建议某个特定的已弃用特性。

要求严格的真/假答案：通过对客观事实强制执行严格的 TRUE/FALSE 分类，降低推理负担并减少评分差异。

避免作弊机会：如果有机会，agent 会定制答案来操纵你的测试。保持评分规则隔离在单独的系统中。设计专注于严格功能结果或特定 topics 的评分规则，而不是宽泛的关键词匹配。

Grade Only What You Asked For

构建评分规则时，很容易不小心根据 prompt 中从未声明的要求对 agent 进行评估。这样做会产生假阴性并降低测量的准确度。

评分规则与 prompt 对齐：只评估明确要求的内容。例如，如果 prompt 从未要求提供引文，不要因为模型未能提供引文而扣分。

评估目的地，而非旅程：避免编写检查 agent 是否使用了特定工具或遵循了 rigid 步骤序列的评分规则。如果预训练模型已经知道答案，可能会完全绕过自定义工具。

评估最终响应：评估客观输出。如果需要评估逐步过程，请 prompt agent 输出执行计划并评估该计划本身。

Calibrate Your Judge

即使你遵循这些规则并编写了完美的原子化、客观问题，你的 LLM 评判模型仍然可能误解你的评分说明和评分规则。为了保证你的 pipeline 产生一致的评分和可靠的信号，你必须证明评判模型的评分与人类主题专家对相同响应的评估方式一致——即通过校准。

建立人类基准：让主题专家手动评估一组「黄金集」测试响应。

运行对比：用你的 LLM-as-a-judge 对抗这个黄金集运行，并将自动评分与人类评分进行比较。

识别差异：如果 LLM 评判模型与人类专家意见不一致，这通常表明你的评分规则或评分说明过于模糊。

迭代直到对齐：调整和校准你的评分规则问题或评分说明，直到 LLM 评判模型与人类专家持续对齐。只有到那时，你的评判模型才准备就绪。

一旦你有了这些可靠数据，下一步就是让它可见。在 AI Evals at a Glance: Heatmaps for Stakeholders 中，Joe Spiro 解释了如何获取这些原始测量值并可视化评估。

在构建我们的 agent skills 时，我们了解到模糊的评估评分规则不能提供有用的信号和反馈。强制你的 LLM 评判模型评估严格的布尔事实可以消除这种噪声。它使你的测试可重复，优化你的 token 支出，并让你有信心地测量你的 AI 工具是否真的在改进。

Photo by William Warby on Unsplash

For further actions, you may consider blocking this person and/or reporting abuse