方法：怎么产出一个分数，以及凭什么相信它

这一章是把第 1 章的「评什么」翻译成「怎么评」的一章。第 1 章把要测的东西分成四层模型——其中 outcome 层（任务最终成没成）和 component 层（单步检索 / 单次工具调用对不对）正是本章方法各自落地的地方：有客观答案的 outcome 与 component 信号用 reference-based 打分，开放式的 outcome 质量用 LLM-as-a-judge。本章先讲两类打分方法本身，再用一整节讲一个常被跳过的问题——判分器自己可信吗。读者读完应当能为一个任务挑出打分方法，同时能说出「在我拿这个 judge 对着人类校准过之前，我不信它」。

2.1有标准答案时：reference-based 打分

reference-based 打分把模型输出和一个已知的「正确答案」（reference）做机械比对，给出一个不需要任何模型来评判的客观分数。

四种主力做法

exact match（精确匹配）：输出字符串与答案逐字符相等才算对，否则算错。抽取式问答、分类标签、枚举型字段用它。它最严格——「Paris」和「Paris.」（多一个句点）都算错，所以通常配一层归一化（去标点、统一大小写、去首尾空格）。

F1（token overlap，词级重叠）：把输出和答案都切成 token 集合，precision = 命中的 token 占输出的比例，recall = 命中的 token 占答案的比例，F1 是两者的调和平均。它比 exact match 宽容：答案是「the capital of France」、输出是「capital of France」时 exact match 给 0，F1 仍给高分。SQuAD 等抽取式 QA 基准的标准指标就是 exact match + F1 并列。

状态比对（state comparison）：当任务的产物是一个可枚举的状态——数据库被改成什么样、文件系统里多了哪些文件、购物车里最终有哪几件商品——就不比文本，直接比对执行后的世界状态是否等于期望状态。这是 agent 任务里最贴近 outcome 层的客观信号：不管 agent 中间怎么绕，只看终局状态对不对。

code：跑测试就是最干净的 eval。当模型输出的是代码，最干净的判分不是比对文本，而是把测试跑一遍——通过 / 不通过是一个完全客观的二元信号，不需要任何人或模型来解读。代码生成的事实标准基准（HumanEval、MBPP、SWE-bench）全部用执行单元测试来打分。这也是为什么「能转成代码 + 测试」的任务，eval 设计上是最幸运的。

BLEU 与 ROUGE：n-gram 时代的两个遗产

在 LLM judge 出现之前，机器翻译和摘要靠两个 n-gram 重叠指标打分，今天仍会在论文里遇到：

• BLEU（n-gram precision，偏精确率）：机器翻译指标。看译文里的 n-gram（连续 n 个词）有多少能在参考译文里找到，再乘一个对过短译文的惩罚。核心是 precision——「生成的词组里，有多少在参考译文里也出现」。
• ROUGE（n-gram recall，偏召回率）：摘要指标。反过来看参考摘要里的 n-gram 有多少被生成摘要覆盖到。核心是 recall——「参考摘要里该覆盖的要点，被盖住了多少」。

2.2没标准答案时：LLM-as-a-judge

LLM-as-a-judge（用大模型当裁判）让一个 LLM 按给定标准去评判另一个模型的输出，把「读懂语义再打分」这件人类才会做的事自动化。

用 LLM 当裁判有三种模式，区别在于喂给 judge 什么、要它吐出什么形状的结果。三种模式的可扩展性、信号粒度、对噪声的敏感度各不相同。

pointwise：按 rubric 给单个输出打分

给 judge 一个输出加一份评分准则（rubric），要它输出一个绝对分（如 1–5）。优点是 O(n)——n 个输出评 n 次，线性扩展，能直接跑 CI、能给单条样本一个可记录的分数。代价是绝对分会漂移：同一个 judge 在不同批次、不同 prompt 措辞下对「4 分」的理解会变；而且它抓不住小差距——两个质量明显有别的回答会双双被打成 4 分，因为绝对刻度太粗。

pairwise：A/B 谁更好

给 judge 两个输出，只问「哪个更好」。优点是信号最细——人类对「A 比 B 好」的判断远比对「A 值几分」的判断稳定，相对偏好天然消除了绝对刻度的漂移。Chatbot Arena 的排行榜就建立在海量 pairwise 对战上。代价有两个：一是 O(n²)，n 个候选两两比较要 ~n² 次调用，贵；二是对顺序敏感——judge 会系统性偏爱排在前面的那个（position bias，§2.3）。

reference-guided：把 gold answer 塞进 prompt

在 pointwise 或 pairwise 的基础上，额外把一份标准答案（gold answer）放进 judge 的 prompt，让它「对照着这份正确答案来评」。它只在任务有客观解时可用——数学题、有标准步骤的推理题、有正确事实的问答。一旦可用，它能大幅提升可靠性：Zheng 等人（MT-Bench）发现，对数学 / 推理这类题，给 judge 提供参考答案能把 judge 的失败率显著压下来，因为 judge 不必自己重新推一遍正确答案——它只要做对照。

2.3judge 的三大偏差与缓解

LLM judge 不是中立的尺子——它有三种可命名、可测量、可缓解的系统性偏差：偏爱靠前的答案、偏爱更长的答案、偏爱自己模型家族的答案。

Zheng 等人（MT-Bench / Chatbot Arena，2023）系统地测了这三种偏差。把它们当成 judge 的「已知故障模式」——每一个都有对应的工程缓解。

position bias：偏爱第一个答案

在 pairwise 模式下，judge 会系统性地偏向排在前面的那个答案，即使两个答案质量相当。把同一对答案交换位置再问一遍，judge 有相当比例会改口——说明它判的部分是「位置」而不是「质量」。

verbosity / length bias：偏爱更长的答案

judge 倾向于给更长的答案打更高分，即使多出来的内容只是冗余填充、没有增加任何信息。Eugene Yan 的实测里，把一个答案用等价但啰嗦的方式重写、内容实质不变，judge 仍有 超过 90% 的概率偏好那个更长的版本。不同模型抵抗力不同——GPT-4 在这项上抵抗得最好，但没有模型完全免疫。

self-enhancement bias：偏爱自己家族的输出

judge 会偏爱自己模型家族生成的输出，哪怕输出是匿名呈现的。Zheng 等人测得：Claude-v1 给自己家族的输出 +25% 胜率，GPT-4 给自己 +10%——即使评测时去掉了任何「这是谁写的」的标识。这意味着用某模型当 judge 去评它自己家族的 generator，分数会系统性虚高。

2.4G-Eval：让 judge 打分更细的机制

G-Eval 用「LLM 自动生成评分步骤 + 按 token 概率加权求分」两个技巧，把粗糙、方差大的整数分变成与人类判断更接近的连续分。

三步流程

① 给任务定义 + 评分准则。把要评什么（如「摘要的连贯性」）和一个 0–5 的准则交给 LLM。

② LLM 自动生成一串 chain-of-thought 评分步骤。不靠人手写细则，而是让 LLM 自己把准则展开成一份具体的、分步的评分指引（「先读原文抓主旨，再看摘要是否覆盖主旨、句子间是否连贯……」）。

③ form-filling 打分。让 LLM 按这份生成出来的步骤，像填表一样给出每一项的分。

关键技巧：概率加权分

真正让 G-Eval 与人类相关性变好的是最后这一步的聚合方式。不取 LLM 嘴上说的那个整数，而是看它对每个候选分数 token 的概率，做加权求和：

# 说明性伪代码，非可直接运行（省略了真实 API 调用与 logprob 取用细节）

# ① + ②：把准则交给 LLM，让它先生成一串评分步骤（CoT）
EVAL_PROMPT = """
任务：评估下面这段摘要的「连贯性」，分数 1-5。
评分准则：5 = 句子间逻辑顺畅、主旨连贯；1 = 跳跃、断裂。

第一步：自己列出评估连贯性的具体步骤。
第二步：按这些步骤，只输出一个 1-5 的整数分。

原文：{source}
摘要：{summary}
"""

# ③：form-filling —— 拿到模型在每个分数 token 上的概率分布
#     resp.logprobs 形如 {"1": p1, "2": p2, ..., "5": p5}
score_probs = get_token_probs(call_llm(EVAL_PROMPT), tokens=["1","2","3","4","5"])

# 关键技巧：概率加权分 = Σ p(s_i) · s_i  （over score tokens）
#   不取模型嘴上说的那个整数，而是按它对每个分数的"信心"加权
final_score = sum(p * int(s) for s, p in score_probs.items())

# 朴素法只会吐整数 4；加权后得到 4.31 —— 连续、可分辨细微差距
print(final_score)   # e.g. 4.31  （非固定值，取决于模型 logprobs）

Σ p·s核心就这一行：把 {1:.02, 2:.05, 3:.18, 4:.55, 5:.20} 这样的分布求期望，得到 3.88 而不是生硬的 4。连续分能分辨出朴素整数分压平掉的细微质量差。

2.5rubric 设计：从「模糊 Likert」到「错误驱动的二元判据」

rubric（评分准则）的质量决定 judge 的噪声。凭空发明的 1–5 Likert 量表噪声大；从真实错误里提炼出的具体二元 pass/fail 判据噪声小。

失败模式：凭空发明的 1–5 Likert

最常见的 rubric 是一个 1–5 的 Likert 量表：「1 = 很差，5 = 很好」。问题是两个评分员（无论人还是 judge）对每一档的理解不一样——评分员 A 的「4」和评分员 B 的「4」根本不是同一个东西，「3」和「4」的边界全凭感觉。喂给 judge，这种模糊性直接变成评分噪声：同一个输出多评几次给出不同分，因为量表本身没有可操作的判据。

修复：错误驱动的二元判据（Hamel Husain）

Hamel Husain 的做法是把 Likert 换成二元 pass/fail 判据，而且这些判据不是凭空发明的，而是从错误分析里发现的。先去看模型真实输出里反复出现的具体失败——「它会编造不存在的退货政策」「它会忽略用户指定的日期格式」——再把每一个失败固化成一条可判定的 pass/fail：「回答是否只用了知识库里有的政策？是 / 否」。二元判据消除了 Likert 的档位模糊：要么命中这个具体缺陷，要么没有，两个评分员不会再对「这算 3 还是 4」争执。

criteria drift 的 catch-22

Shankar 等人在 EvalGen（《Who Validates the Validators?》，2024）里发现一个绕不开的循环：给输出打分这个行为本身，才教会你判据到底是什么。研究里的参与者一边给输出打分，一边不断意识到「原来真正在乎的是这一点」，于是回头去改之前已经打过的分——他们的评判标准在打分过程中持续漂移（criteria drift）。这是一个 catch-22：你想先定好 rubric 再打分，但你要打了分才知道 rubric 该是什么样。

2.6校准：你凭什么相信这个 judge

一个 judge 在对着人工标注的 golden set 用 Cohen's κ 验证过、且没超出人与人一致率的上限之前，它给出的分数不能当真。

第一步：建一个 golden set

judge 只有在对着一个人工标注的 golden set 验证过才可信。golden set 是一批 ~30–200 条样本，要点有三：来自真实分布（从线上真实流量或贴近真实的数据里抽，不是凭空造的简单样例）、专家标注（由真正懂这个任务该长什么样的人打标签）、规模不必大（30–200 条足够测出 judge 和人类的一致程度，关键在质量不在数量）。

第二步：用 Cohen's κ 度量一致性，而不是裸 % agreement

对齐程度不要用裸的百分比一致率（raw % agreement），要用 Cohen's κ。κ 在裸一致率的基础上扣掉了「纯靠随机也会蒙对」的那部分一致——两个评分员就算瞎猜，在二分类上也有约 50% 会碰巧一致，裸一致率把这部分白送的运气也算成了功劳。Eugene Yan 给出过一个具体反例：一对评分的裸一致率 80%，换算成 Cohen's κ 只有 0.62。更要命的是类别不均衡时——如果 95% 的样本都是「pass」，一个无脑全判 pass 的 judge 裸一致率就有 95%，看着很高，κ 却接近 0，因为它完全没有信息量。裸一致率在这种分布下骗人最狠。

第三步：认清硬天花板——judge 不可能超过人与人的一致率

校准有一个不可逾越的上限：judge 与人类的一致率，不可能高于人类标注者彼此之间的一致率。如果两个专家对同一批样本只能达成 65% 的一致，那这个任务本身就有 35% 的主观模糊地带——judge 再强也变不出一个「正确答案」来，因为根本不存在一个所有人都同意的答案。这种情况下指望 judge 达到 80% 一致是数学上不可能的：80% 的「正确」从何而来？人类自己都给不出。这也给了一个判断 judge 是否够好的标尺：先测人与人一致率，再拿它当 judge 的目标上限。Zheng 等人的好消息是：在 MT-Bench 上，GPT-4 与人类的一致率超过 80%，和人与人之间的一致率持平——也就是说在那个任务上，GPT-4 judge 已经逼近了天花板，再调也榨不出多少。

下面这张表把全章收束成一个选型决策——给定任务类型，该用哪种打分方法、为什么。这是本章的「备选方案」核心：每一行的「为什么」都回指前面某一节揭示的机制或失效。