自动评测 vs 人工评测

摘要：自动评测（以 LLM-as-Judge 为代表）解决了人工评测"贵、慢、不可规模化"的痛点，但自身带有可测量的偏差。本文给出三类评测器的取舍、LLM-Judge 的偏差清单、用 Cohen's Kappa 做人工校准的方法，以及三种更稳健的 Judge 模式，帮你在"规模"与"可信"之间拿到平衡。适用场景：所有需要给开放式生成做质量打分的团队。

核心概念：三类评测器

类型	优势	劣势	适用
代码评测器	快、客观、可复现、便宜	对有效变体脆弱、无细微判断	格式/工具调用/状态校验
LLM-as-Judge	灵活、可扩展、捕捉细微差别	非确定、更贵、需校准	开放式问答、轨迹质量
人工评测	黄金标准、匹配专家判断	昂贵、慢、难大规模	校准基准、高利害决策、抽检

行业现状

LLM-as-Judge 已是工业界主流规模化解法，但它"有用、有偏、易误用"。正确姿势是：用自动评测跑规模，用人工评测做校准与抽检，二者形成闭环而非二选一。

LLM-as-Judge 的常见偏差

必须已知的盲区

自我偏好 / 长度偏见（Self-enhancement Bias）：judge 倾向给"长篇大论"或"与自己语风相近"的回答无理由高分。
位置偏差（Position Bias）：成对比较时，放前面的选项更容易被选中。必须交换 A/B 位置各跑一次再汇总。
宽松偏见：默认偏向"给高分"，需用带权重量规约束。
任务特定漂移：换模型/换 prompt 后，judge 一致性可能变化，需重新校准。

用 Cohen's Kappa 做人工校准

任何评测 LLM 上线前，必须用 50–100 条判定案例交由领域专家（SME）盲审，计算 Judge 与人工的 Cohen's Kappa 一致性。参考 Landis & Koch (1977) 分级：

Kappa (κ)	一致性等级	行动
< 0.0	轻微一致	评测 prompt 严重歧义，重设计量规
0.0–0.20	一般一致	增加 few-shot 示例、细化维度
0.21–0.40	中等一致	可初步使用，但频繁人工复核
0.41–0.60	显著一致	可投入，定期抽样复核
0.61–0.80	几乎完美	可信任用于自动化

未校准的 Judge 不可用于发布决策

若 κ < 0.8，说明 Judge 的 prompt 规则有歧义或模型逻辑不足，必须调整量规或更换更强 judge。把未校准的自动分数当作"绝对真理"是评测最常见的误用。

三种更稳健的 Judge 模式

直接打分法（Direct Scoring）：用带权重和详细标准的量规，而非模糊"1-5 分"。关键：明确定义每档含义（如 3=完成任务但有冗余，4=完成且高效）。
成对比较法：让 judge 对比轨迹 A 与 B 选更好，比绝对打分方差更小。注意交换位置运行两次消除位置偏差。
自动量规生成：垂直领域手写标准累，可让更强 judge 先读 SOP 再生成该领域评分标准。

操作步骤：建立校准闭环

python

import random
from openai import OpenAI

client = OpenAI()

JUDGE_PROMPT = """你是专家评测员，对用户回答打分。
问题：{question}
参考量规（好答案应做到）：{rubric}
待评回答：{response}
按 1-5 打分并给出理由：
5=完全满足量规，正确清晰完整
4=基本满足，小瑕疵
3=部分满足，缺关键要素
2=大多不满足
1=完全错误/答非所问"""

def judge(question, rubric, response):
    resp = client.chat.completions.create(
        model="gpt-4o",   # TODO(verify): 替换为你的 judge 模型与版本
        messages=[{"role": "user", "content": JUDGE_PROMPT.format(
            question=question, rubric=rubric, response=response)}],
        temperature=0,     # 降低随机性，保证可复现
    )
    return resp.choices[0].message.content

降低偏差的实操

temperature=0 让 judge 尽量确定。
成对比较时交换位置各跑一次取多数。
对长输出做首尾裁剪（去除"当然，以下是…"等寒暄）再送 judge，减少长度偏见。
关键信息（如事实性）用代码评测器先门禁，只对模糊项上 judge。

何时必须人工上场

发布前最终判定、高利害场景（医疗/法律/金融建议）。
校准基准：没有 SME 盲审就没有 Kappa，自动评测失去可信锚点。
新能力探索：自动评测没见过的失败模式，人工抽样发现。
A/B 体验对比：语气、品牌调性等主观维度，自动评测仍不可靠。

验证

python

# 人工校准一致性（示意：用 sklearn 计算 Cohen's Kappa）
from sklearn.metrics import cohen_kappa_score
# human_labels / judge_labels 为同一批样本的两列 1-5 标签
kappa = cohen_kappa_score(human_labels, judge_labels)
print("Cohen's Kappa =", kappa)   # 目标 >= 0.8 才可信投入

回滚 / 清理

评测不直接影响线上；但 judge 模型/prompt 变更需版本化，避免"换了 judge 导致历史分数不可比"。
校准样本集（人工标签）应随评测代码一起入库，作为回归基线。

故障排查

现象	原因	处理
Judge 全给 5 分	量规太松 / 自我偏好	收紧 rubric，加负向描述
与人工严重不符	未校准 / 任务漂移	重做 Kappa 校准
成对比较前后不一致	位置偏差	交换位置各跑一次
成本爆炸	每条多次 judge	代码门禁前置 + 更小 judge

安全与合规

评测数据泄露与偏见风险

送 judge 的内容若含生产 PII，需用私有部署 judge 或脱敏（见 dataset.md、online-monitor.md）。
自动评测可能放大训练数据偏见（性别/地域等），人工抽检必须覆盖敏感维度。
Judge 模型本身有立场，发布前需在敏感维度做偏见审计，不可完全依赖自动分。

成本 / 性能

LLM-Judge：每条样本一次或多次 judge 调用，规模上千即产生可观 token 成本 [未实测，取决于样本长度与 judge 模型]。
人工：单条 SME 标注成本高但仅用于校准（50–100 条/轮）与抽检，量级可控。
降本：代码评测器前置过滤明显错误 → 仅模糊样本上 judge；用更小 judge 模型 + 人工抽检兜底。

自动评测 vs 人工评测 ​

核心概念：三类评测器 ​

LLM-as-Judge 的常见偏差 ​

用 Cohen's Kappa 做人工校准 ​

三种更稳健的 Judge 模式 ​

操作步骤：建立校准闭环 ​

何时必须人工上场 ​

验证 ​

回滚 / 清理 ​

故障排查 ​

安全与合规 ​

成本 / 性能 ​

参考资料 ​