如何为“LLM 作为评委”编写可靠的评分标准
英文标题:How to Write Reliable Rubrics for LLM-as-a
Google 团队分享了为“LLM 作为评委”编写可靠评分标准的四个关键经验,以提高 AI 评估的一致性和准确性。
为什么值得关注
随着 AI 生成内容越来越复杂,传统的确定性测试难以评估其质量。“LLM 作为评委”是一种可扩展的评估方法,但若评分标准模糊,会导致评估结果不可靠,浪费资源。本文提供的实用指导能帮助开发者设计更稳健的评估体系,从而更准确地衡量 AI 工具的性能,推动 AI 技术的可信发展。
核心要点
- 将复合问题拆分为原子性的 TRUE/FALSE 问题,避免重叠。
- 评分标准应基于客观事实,使用 MUST、MUST NOT 等正式语言。
- 只评估提示中明确要求的内容,避免评估过程或未提及的方面。
- 通过人类专家评分校准 LLM 评委,迭代直至一致。
- 使用严格的布尔问题可减少幻觉,提高评估一致性。
这是第 1 部分:如何设计你真正可以信赖的 AI 评估的后续文章。
在 Google,我们正在 GitHub 上发布一套适用于 Google 产品和技术的 Agent Skills。我的团队有兴趣衡量它们的性能,以了解它们表现如何。确定性测试(例如检查生成的代码能否编译)是理想的选择。不幸的是,对于细微差别的生成式响应(例如开放式问题的答案或信息检索任务),这类测试很难大规模轻松创建。
在我之前的文章中,我们探讨了你要测试什么,也就是你要求 agent 执行的那些评估动作。下一步是研究你如何断言 agent 是否成功。这意味着要为 agent 的响应创建可靠且准确的评估。
为了大规模评估复杂的输出,尤其是当主题涵盖广泛领域且包含细微差别时,我们采用了一种“LLM 作为评委”的方法。响应会使用基于模型的评分器,根据结构化的评分标准进行评估。评委使用一组对/错问题来评估每个响应。汇总这些答案后,就能为一个响应提供准确度分数。
给 LLM 一个模糊的提示或主观的问题会导致其响应含糊不清。这种模糊性会引入噪声数据,并导致评估不一致。最终,这会浪费你的 token 预算,却换来毫无用处的指标。
为了让这些评估更可靠,你必须像对待正式规范一样对待你的评分标准。通过限制评委只评估严格、客观的布尔真值,你可以减少幻觉(即模型编造不实信息)的发生几率。由于评估严格的布尔真值是一个不那么复杂的任务,你甚至可以使用更小、更快的模型来进行评分。
以下是我们学到的四个经验教训,可帮助你为你的“LLM 作为评委”评分器编写稳健的评分问题。
保持问题原子性和独立性
在单个问题中评估多个要求,例如“响应是否包含元数据属性并将输出格式化为 JSON?”,会迫使 LLM 评委猜测哪个子句更重要。这种模糊性会导致评分不一致并浪费 token。
- 拆分复合问题:不要编写一个大的检查项,而是将你的要求拆分为离散的、原子性的 TRUE/FALSE 问题。(例如,检查 1:它是否包含元数据属性?以及 检查 2:输出是否为 JSON?)
- 避免问题重叠:切勿在你的评分标准中多次测试同一个底层概念。重叠可能会因为单个错误而对被评估的模型进行双重惩罚,这会破坏你的准确度分数。
- 减少推理负担:消除评委权衡相互冲突的条款的需要。当每个问题只评估一个独特的事实时,你的评分就会变得更加一致。
约束评委:客观事实优于主观推理
采用基于评分标准的方法,是因为给 LLM 评委一个完整的散文式提示来评估复杂响应会导致不一致的数字。如果你问评委主观问题,比如“这是一个全面的回答吗?”,或者要求它解释“为什么 agent 会这样做?”,你就会引入模糊性,从而产生嘈杂、不可重复的数据。
- 关注可观察的事实:不要要求评委评估需要解释的概念,例如意图、质量或推理。只评估你期望在响应中找到的具体事实。
- 编写正式规范:使用严格、客观的语言,例如 RFC 2119 术语(MUST、MUST NOT、REQUIRED),来测试可观察的结果。评委绝不应该猜测你的意思。
- 测试否定约束:明确验证 agent 不应该做什么。不要问 agent 是否“使用了最佳实践”,而是检查它是否没有建议某个特定的弃用功能。
- 要求严格的真/假答案:通过强制对客观事实进行严格的 TRUE/FALSE 分类,你可以减少推理负担并减少评分差异。
- 避免作弊机会:如果给 agent 机会,它们会定制答案来欺骗你的测试。将评分标准隔离在单独的系统中。设计侧重于严格功能结果或特定主题的评分标准,而不是宽泛的关键词匹配。
只为你要求的内容评分
在构建评分标准时,很容易意外地根据提示中从未说明的要求来评估 agent。这样做会产生假阴性,并降低你测量的准确性。
- 使评分标准与提示对齐:只评估明确要求的内容。例如,如果提示从未要求提供引用,就不要因为模型未能提供引用而扣分。
- 评估结果,而非过程:避免编写检查 agent 是否使用了特定工具或遵循了严格步骤序列的评分标准。预训练模型如果已经知道答案,可能会完全绕过自定义工具。
- 评估最终响应:对客观输出进行评分。如果你需要评估逐步过程,请提示 agent 输出执行计划,并评估该计划本身。
校准你的评委
即使你遵循这些规则并编写了完美原子性、客观的问题,你的 LLM 评委仍然可能误解你的评分说明和评分标准。为了保证你的流程生成一致的评分和可靠的信号,你必须通过校准来证明评委的评分与人类主题专家对完全相同响应的评估方式一致。
- 建立人类基线:请主题专家手动评分一组“黄金标准”测试响应。
- 运行比较:让你的“LLM 作为评委”针对这组黄金标准运行,并将自动评分与人类评分进行比较。
- 识别差异:如果 LLM 评委与你的专家意见不一致,这通常表明你的评分标准或评分说明过于模糊。
- 迭代直至一致:调整和校准你的评分问题或评分说明,直到 LLM 评委始终与人类专家保持一致。只有这样,你的评委才算准备好。
总结
一旦你获得了这些可靠的数据,下一步就是使其可见。在 AI 评估一览:面向利益相关者的热力图 中,Joe Spiro 解释了如何获取这些原始测量结果并将评估可视化。
在构建我们的 agent skills 时,我们了解到模糊的评估标准无法提供有用的信号和反馈。强制你的 LLM 评委评估严格的布尔事实可以消除这种噪声。它使你的测试可重复,优化你的 token 支出,并让你能够自信地衡量你的 AI 工具是否真的在改进。
照片由 William Warby 拍摄于 Unsplash
如需采取进一步行动,你可以考虑屏蔽此人并/或举报滥用行为。
术语表
- LLM 作为评委
- 一种使用大型语言模型作为评分器,根据结构化评分标准评估其他 AI 响应的方法。
- 评分标准
- 一套明确的规则或问题,用于评估 AI 响应的质量。
- 原子性
- 指评分问题应拆分为最小、独立的单元,每个问题只评估一个事实。
- 幻觉
- AI 模型生成不真实或编造信息的行为。
- 校准
- 通过比较 LLM 评委的评分与人类专家评分,调整评分标准以提高一致性。
- RFC 2119
- 一种标准,定义了 MUST、MUST NOT 等关键词,用于正式规范中表达要求。
生产区
使用这篇文章
复制包含 frontmatter、中文正文和英文来源的 Markdown。
我的研究区
记录自己的判断,不会写回原文或公开页面。
一句话说清这篇材料能支撑什么角度。
每行一个,最多 20 个。
支持 Markdown。要核对的数据、可复用的方法、反方观点或补充来源。