摘要：Google AI 团队发布教程，讲解如何为"模型评模型"编写可靠的布尔式评分标准，指出模糊提示会导致评估不一致与 token 浪费，并给出四条经验。
用大模型去评判大模型的输出（LLM-as-a-Judge），现在几乎是做 AI 产品的标配。但 Google 团队这篇教程点破了一个常被忽视的坑：评判标准没写好，评出来就是噪声。问题出在哪？最常见的是"模糊提示"。比如让评审模型给个"整体质量如何"的结论——这种开放式问题，模型每次的情绪和侧重都不一样，两次跑结果可能对不上，既不可复现，又白烧 token。Google 给的解法是用布尔式评分标准（boolean rubric）：把评分拆成一条条能用"是/否"回答的具体问题，例如"回答是否包含了步骤三""是否出现了与问题无关的内容"。每条独立判定，最后再汇总，评估的一致性和可解释性立刻上来。
教程里沉淀的经验大致四条。第一，问题尽量布尔化，避免"打分 1 到 10"这种弹性空间——"是/否"没有歧义，而"给个 7 分"在不同上下文里含义漂移极大。第二，一条标准只测一件事，别把"准确性"和"语气"揉在一起，否则你不知道低分到底扣在哪儿。第三，给评审模型看的是"判定依据"而非"自由发挥"，减少漂移，让它顺着你定义好的维度走，而不是自己发明评判标准。第四，先在小样本上验证评审模型和人类判断的一致性，再放大规模，否则你只是把错误自动化了——一个本身就偏的评审模型，跑得越多，坑埋得越深。
对做评测体系的团队，这其实是把"测试"这门老手艺重新请回来：好的评分标准像好的单元测试——明确、可重复、能定位问题。当你的产品开始用 AI 管 AI，这套工程纪律比模型本身更决定成败。一个很现实的场景是：你想用 LLM 评委来给客服机器人的回答打分，如果评委标准含糊，你今天看到的"满意度 92%"和明天看到的"满意度 78%"可能只是评委心情变了，而不是产品真退步了——这种噪声会直接废掉你的迭代决策。把标准写成布尔 rubric，等于给评委发了张"只能勾选"的答题卡，它想跑偏都没地方跑。
把 #13 和 #14 放一起看，Google 这两篇教程其实在讲同一件事的不同侧面：要让 AI 系统可靠，光换更强的模型没用，得在"外壳"和"度量"上都下硬功夫。harness 管住"模型怎么干活"，rubric 管住"我们怎么判断它干得好不好"。两者都是把"软"的智能，用"硬"的工程约束起来。对任何在认真做 AI 产品的团队，这两篇加起来，比追十个新模型发布都实在。
把这套方法落到工具层面，建议每个做 AI 产品的团队都维护一份"评审 rubric 仓库"：把常用的评判维度沉淀成可复用的布尔问题集合，版本化管理，像管代码一样管评测标准。这样当模型升级、或业务口径变了，你只需改 rubric 而不必重写整套评估逻辑，评审的一致性也能跨版本比较。另一个常被忽略的细节是评审模型本身也要被测——定期抽一批它的判定结果让人复核，算一个"人和评委的一致率"，一旦掉到阈值以下就说明 rubric 或评委模型需要调。评测不是上线前的一次性动作，而是伴随产品全生命周期的"质量仪表盘"。把 LLM 评委用好了，它能让你在每次迭代时都看清"到底变好了还是变坏了"，而不是凭感觉拍脑袋。
