如果你正在搭建 LLM-as-a-Judge 评估流程，你大概率写过这样的 评分标准：“请判断这个回答是否有帮助。” 就这么一句话，扔给评判模型。第一次跑，它说“有帮助”；第二次跑，同一个模型换了套说法；第三次换另一个评判模型，直接判负。这不是模型不稳定，而是你在用模糊的尺子量精细的活。Google AI 团队最近发布了一组教程，核心就一件事：怎么为 LLM-as-a-Judge 写可靠的布尔式评分标准。四句话能概括：问题原子化、标准客观化、边界显式化、结果校准化。
模糊的提示词，正悄悄击穿你的评测
同一个问题，三种答案，零个共识
教程里举了最常见的反面教材：让模型判断“回答是否解决了用户的问题”。听起来没问题，但“解决”意味着什么？是提供了步骤，还是给出了结论？是让用户满意，还是信息完整？不同评判模型会抓住不同侧面，结果自然南辕北辙。
更隐蔽的是，同一个模型在不同温度下也可能给出不同判断。你以为自己在做 A/B 测试，实际上有一半的差异来自评测噪声。而这些噪声的根源，就是评分标准里那些未经定义的主观词。
浪费 token，只是最轻的代价
模糊标准最直接的问题是浪费 token——你要多跑几轮、多让几个人看结果、甚至重新生成输出。但这些都能用钱和时间解决。真正棘手的是，你把一套不确定的评估器当作基准，去迭代 prompt。每一次评估的随机波动，都会被解读成“新方案更好了”或“方案退步了”。于是整个优化过程变成了在噪音里打转。
用不稳定的评测去指导稳定的改进，是实验设计上的双重浪费。
主观不是原罪，模糊才是
需要主观判断的任务并不少见。比如“回答是否礼貌”“语气是否合适”，这些本来就没有唯一答案。问题不在于“主观”，而在于你没有界定主观的具体维度。
当评分标准写成一个笼统的形容词时，评判模型只好自行脑补。它脑补出的规则，未必是你脑补出的规则。最后你评的不是你的任务，而是模型对你任务的理解。
原子化：让每个评分问题只长一个心眼
一条问题，只测一个特征
Google 团队给出的第一条经验：问题是原子化的，且互不重叠。所谓原子化，就是一条评分标准里只允许出现一个可判定的事实。
举个例子。“回答是否准确且全面”是一个典型的复合问题。如果回答准确但不全面，评判模型该打勾还是打叉？它被迫在内部做复杂决策，而这种决策往往是不可复现的。正确的拆法是：“回答中的事实性信息是否全部为真”和“回答是否覆盖所有问题点”分成两条。
问题之间不能偷偷重叠
原子化还意味着每条标准之间要有清晰的边界。假设一条问“是否提供了操作步骤”，另一条问“步骤是否清晰易懂”。前者其实已经隐含了对步骤存在性的判断，后者如果只包含“看不懂”的解释，就会产生逻辑交集。
一旦标准之间互相嵌套，你很难定位评估分歧来自哪一条。评判模型可能觉得这条扣了分，那条也扣了分，但你和它争论半天都不知道错在哪。
用“不重叠清单”代替描述性段落
实际操作中，别用一大段话来描述什么算“好答案”。长段落天然鼓励模糊，因为你能在一句话里塞进多个评价维度。试着把它改写成一个布尔式清单：每条以“是否”或“有没有”开头，只允许回答 True 或 False。
这种清单写完后要默读一遍：如果任何两条之间存在“如果这条成立，那条也必然成立”的关系，说明重叠了，拆开它们。
只评客观事实，让 MUST 做你的守门员
别让模型凭感觉打分
第二条经验是：只让评判模型评估客观事实，而不是让它评估美学、风格或“整体质量”。客观事实有一个好处：你可以根据原文去验证。评判模型说“价格没提到”，你可以翻出原文看它到底说没说到。
相比之下，“回答是否有洞察力”这种标准根本无法验证。洞察力是什么？模型的“审美”和你的一致吗？大概率不一致。
RFC 2119 术语给评分装上强制力
为了让客观性更进一步，Google 团队建议在标准里引入 RFC 2119 的定义性术语：MUST、SHOULD、MAY。这套标准原本用于规范互联网协议中的关键词，现在正好可以用来给评分标准画边界。
比如：“如果回答中 MUST 包含明确的错误信息，则本条判定为 False。” 这里的“MUST”让评判模型知道没有回旋余地。同样，“回答 SHOULD 包含至少一个示例”暗示可以没有，但那是质量降级的信号。
评判模型对这类规范语言相当敏感。用标准化的词汇去替代“应该”“最好”“建议”等口语化说法，能显著降低评分中的随意感。
别把“客观”包装成主观
有些标准看起来客观，其实很主观。“回答是否清晰”就是典型的伪客观。“清晰”的判定因人而异，你无法用一个统一算法去测量。要让它变客观，就得把抽象概念换成可见证据——比如“回答是否用项目符号分列出了三项以上理由”。
哪怕你的评价维度最终要落在“有用”上，也要把它翻译成几个可观察的客观条件：是否直接回答、是否涵盖关键约束、是否给出可执行输出。
评分标准别越界：只评 prompt 里真正写过的事
模型的自作主张是评估毒药
第三条经验看起来简单，却最容易犯：只评 prompt 中明确要求的内容。用户要求写一段 Python 代码，没说必须加注释，评判模型却因为代码缺少注释而扣分。这听起来像有“责任心”，但实际上是越权。
LLM-as-a-judge 的职责不是当老师的“最佳答案评审员”，而是判断实际输出有没有满足用户写下的要求。它自己脑补出的额外规则，会引入大量不一致。
把“隐含要求”从 prompt 里挖出来
有些要求你没写，但心里觉得“这还用说吗”。比如你让模型“给出一个营销方案”，暗自希望它包含预算估算。可评判模型读不到你的潜意识，它只看 prompt 文本。
所以当你确定预算估算是必需项，就把它显式写进用户 prompt 里，然后在评分标准里对应一条：“回答是否包含预算估算部分。” 这样评分标准才有了依据。
写 rubric 时对照 prompt 逐条打勾
一个很实用的自查动作：把写好的每一条评分标准，拿回原始 prompt 里找证据。如果找不到任何一句用户指令与之对应，就把这条删掉，或者修改 prompt 把要求补上。
这样做的意义在于防止你使用一套“万金油”评估表去评判所有任务。同一套 rubrics 看似面面俱到，其实对你的任务毫无针对性。真正的可靠必须始于对用户 prompt 的忠诚。
用 golden set 把评判模型调教到与人类同频
为什么必须有一组专家标注的样本
即使 rubrics 写得再干净，评判模型仍可能出现系统性偏差。它可能在某类表达上格外苛刻，也可能在某个领域里频繁漏判。这时你需要一条“外部准绳”——专家标注的 golden set。
所谓 golden set，是提前准备好的一组输入-输出样本，每一条都由人类专家用同一套评分标准给出最终 True/False 标签。它代表了你的评估体系所认可的“标准答案”。没有这个锚点，你永远不知道是模型变好了，还是它只是换了一种偏差。
校准不是一次性事件，而是一个循环
Google 团队给出的校准流程非常直白：先让评判模型跑一遍 golden set，把它给出的标签与专家标注对比，找出所有不一致的地方。接下来不是去骂模型，而是去审视 rubrics——哪一条措辞造成的误解？哪一条的边界仍然模糊？修改后重新跑一遍。
这个过程要反复进行，直到评判模型和人类专家的一致率稳定在一个可接受区间。校准的终点不一定是完全一致，而是双方对标准的理解已经基本同频。
一致率要到多少才算够？
一个常被追问的问题：需要 100% 一致吗？Google 团队给出的答案是：去测两位人类专家之间的互评一致率。如果两个人背靠背打分也会出现 85% 的一致性，那你的评判模型只要达到这个水平，就已经具备了替代人工评审的基本资格。
换句话说，你在校准的不是让机器模仿某个真理，而是让它接近人类共识的上限。到了这一步，LLM-as-a-judge 才真正从“能跑”变成了“可信”。
四条经验并不高深，却直指评测系统中最容易被忽略的工程细节。打磨 rubrics 的过程，本质上是在替评判模型扫清认知障碍——当你把标准写得真正具体、客观、有边界并经过校准，那个折腾你的“不稳定 judge”就会变成最可靠的评测合伙人。
