Google AI团队发布LLM-as-a-Judge评估量表编写指南：以布尔事实约束减少评分偏差
Google AI开发者Jan-Felix Schmakeit在技术博客中分享四项经验，主张将评分量表视为形式化规范，通过原子化、客观化问题降低LLM评判者的主观歧义，并建议与人类专家校准。
AI解读：Google团队在GitHub发布Agent Skills系列后，需要评估这些智能体在开放问答、信息检索等生成任务上的表现。由于无法靠编译等确定性测试规模化检查这些输出，他们采用LLM-as-a-judge方法：让模型基于结构化评分量表，用真/假问题逐项评判回答并汇总准确率。如果量表问题写得模糊或主观，评判模型的输出就会不稳定，既浪费token又得不到有用信号。 这次指南的实用价值在于它把量表写作从'凭感觉提问'变成了形式化规格编写。四个要点对开发者的直接约束是：问题必须原子化（如把'是否包含元数据且输出为JSON'拆成两个独立问题）、只评判客观可观测事实（用MUST/MUST NOT这类RFC 2119语言，不问'回答是否全面'）、不与提示词之外的要求挂钩、以及用人类专家标注的金标准集校准评判模型。比如提示词没要求引用时，就不该因缺引用扣分；即使模型没调用指定工具但答案正确，也应算通过。 受影响的是所有构建基于LLM的评估管道或自动评测系统的开发者。遵循这套规范后，最直接的改变是评分可重复性提高，偏差减少，且因为布尔判断复杂度低，可以用更小更快的模型做评判，节约成本。普通业务用户无需立即行动，但可以意识到：自动评测分数能否信任，取决于量表设计和校准质量而非模型大小。现阶段没有公开验证数据说明这套方法能把一致性提升到具体百分比，仍需要团队按文中步骤自行校验。
Google AI开发者Jan-Felix Schmakeit发布技术博客，介绍如何为LLM-as-a-judge评估编写可靠的评分量表。文章是其《如何设计可信AI评估》系列的第二部分，基于该团队在GitHub上发布的Google产品与技术Agent Skills套件的测试经验。
团队采用LLM-as-a-judge方式评估复杂生成输出：基于模型的评分者按照结构化量表，用一组真/假问题评判每个响应，汇总后得到该响应的准确率分数。Schmakeit认为，给LLM模糊提示或主观问题会造成歧义，导致数据噪声大、评估不一致，还会浪费token预算。
四项编写经验
文章提出四项经验，核心是把量表当作形式化规范对待。第一，问题必须原子化且互不重叠：避免把多个需求放在同一问题中，如“响应是否包含元数据属性且格式为JSON”，这迫使评判模型猜测哪个子句更重要，应拆分为两个独立检查；底层同一概念不应多次测试，以免同一错误被重复扣分。
第二，用客观事实约束评判者，避免主观推理：不要问“回答是否全面”或“智能体为何这样做”这类需要解释的问题，只评估响应中预期存在的具体可观测事实；使用RFC 2119的MUST、MUST NOT、REQUIRED等严格语言；明确测试负面约束，例如检查智能体未建议某个已弃用功能，而非问其是否“使用最佳实践”；强制真/假二元答案；将评分量表隔离在独立系统中，防止智能体针对测试调整答案。
第三，只评提示词明确要求的内容：避免对提示词中未陈述的要求打分，例如提示未要求引用时，不应因模型未提供引用而扣分；检查目标应是最终响应而非是否调用特定工具或按固定步骤执行，因为预训练模型若已知答案，可能绕过自定义工具，如需评估过程应先让智能体输出执行计划再评估该计划。
第四，校准评判模型：要求领域专家手动标注一组“金标准”测试响应，将LLM-as-a-judge的自动评分与专家评分对比，若不一致通常说明量表或评分指令存在歧义，需调整量表措辞或评分指令，直到与专家判断一致为止。