“这个模型的输出质量怎么样？”
在 2026 年，回答这个问题的最佳方式仍然不是人工评估——太慢、太贵、太主观。但也不是随便让另一个 LLM 打分——你会发现它给自己的输出打 9 分，给竞品的打 6 分。自动评估是一门需要精心设计的工程学科。这篇文章把目前最主流的三种方法拆开来讲，并给出一个生产级的评估流水线。## LLM-as-Judge：最方便，最危险LLM-as-Judge 的思路很简单：让一个"裁判 LLM"（通常是 GPT-5 或 Claude Opus）来评估另一个 LLM 的输出。pythondef llm_as_judge(prompt, response, criteria, judge_model="gpt-5.2"): judge_prompt = f"""请你作为评审专家，根据以下标准评估回复质量。标准：{criteria}用户问题：{prompt}模型回复：{response}请给出 1-10 分的评分，并解释评分理由。评分：""" return call_llm(judge_model, judge_prompt)textLLM-as-Judge 在 MT-Bench 等评测中表现出与人类评估 0.85+ 的 Spearman 相关性——看起来很不错。但它的陷阱也很深：陷阱一：位置偏差（Position Bias）。 LLM 倾向于给第一个出现的答案打更高分。如果同时评估模型 A 和模型 B 的输出，A 排在前面的得分平均高 0.5 分。解法： 交换顺序评估两次，取平均值。pythondef debiased_judge(prompt, response_a, response_b, criteria): # 评估两次，交换顺序 score_a1, score_b1 = judge_pair(prompt, response_a, response_b, criteria) score_a2, score_b2 = judge_pair(prompt, response_b, response_a, criteria) score_a = (score_a1 + score_a2) / 2 score_b = (score_b1 + score_b2) / 2 return score_a, score_btext陷阱二：自我偏好（Self-Preference）。 如果裁判 LLM 是 GPT-5，它会偏好 GPT-5 生成的输出——这个偏差在不同模型对之间高达 0.3-0.7 分。解法： 用第三方模型做裁判——如果你在评估 GPT-5，用 Claude Opus 做裁判，反之亦然。陷阱三：长度偏差（Verbosity Bias）。 LLM 给长回复的打分普遍偏高，即使长回复中包含了更多废话。解法： 在评估提示词中明确要求"不考虑回复长度"。### G-Eval：引入思维链的结构化评估G-Eval（Liu et al., 2023）在 LLM-as-Judge 的基础上加了两层改进：思维链（CoT）评估和概率归一化。pythondef g_eval(prompt, response, criteria, judge_model="gpt-5.2"): # Step 1: CoT 评估 cot_prompt = f"""你是一个专业的 LLM 输出评估专家。评估标准：{criteria}用户问题：{prompt}模型回复：{response}请一步一步分析：1. 回复是否正面回答了用户的问题？2. 回复中的事实是否准确？3. 回复的结构和表达是否清晰？4. 回复中是否有无关内容或错误信息？请基于以上分析给出评分（1-10）：""" analysis = call_llm(judge_model, cot_prompt) # Step 2: 用概率分布做评分（可选，G-Eval 的特色） # 获取模型对每个分数 (1-10) 的 logprob score_probs = get_score_logprobs(judge_model, prompt, response) expected_score = sum(i * prob for i, prob in enumerate(score_probs, 1)) return { "score": expected_score, "analysis": analysis, "distribution": score_probs }textG-Eval 的 CoT 评估让打分更有依据（不是凭空给分），而且在论文中显示与人类评估的相关性比普通 LLM-as-Judge 高 5-10 个百分点。但 G-Eval 的代价是评估成本翻倍——每评估一条样本需要 2 次 LLM 调用（CoT 分析 + 概率计算）。### MT-Bench：多轮对话评估基准MT-Bench 是 LMSYS 提出的评估框架，它的核心创新在于不再只评估单轮回复，而是评估多轮对话质量。MT-Bench 设计 80 个多轮对话问题，覆盖 8 个类别：写作、角色扮演、推理、数学、编程、提取、STEM、人文学科。每个问题 2 轮对话。评估流程：yaml第一轮： 用户：写一个 Python 函数来检测回文字符串 模型：[代码回复] 第二轮： 用户：这个函数能处理空字符串吗？ 模型：[改进回复]评估： - 第一轮得分：代码正确性、可读性、边界处理 - 第二轮得分：是否能根据反馈改进、是否识别了边界条件textMT-Bench 最大的价值不是"打分"，而是逼着模型展示多轮交互能力。 很多模型在第一轮表现不错（因为单轮刷题刷得多），但在第二轮面对追问时就露馅了。## 生产级评估流水线在实际工程中，我们不会只用一种评估方法。我总结了一个三级评估体系：### Level 1：规则评估（实时，成本零）对于有明确答案的任务，用规则就够了：pythondef rule_based_eval(response, expected): checks = [] # 代码：能跑通吗？ if "code" in expected: checks.append(("执行通过", execute_code(response["code"]))) # JSON：格式对吗？ if "json" in expected: try: json.loads(response) checks.append(("JSON 合法", True)) except: checks.append(("JSON 合法", False)) # SQL：语法对吗？ if "sql" in expected: checks.append(("SQL 语法", validate_sql(response))) return all(passed for _, passed in checks)text规则评估覆盖了约 40% 的生产流量——代码生成、SQL 生成、结构化输出。零成本，实时反馈。### Level 2：G-Eval 评估（T+1，批量）对于没有明确"正确答案"的任务（写作、摘要、翻译），用 G-Eval 批量评估：pythondef batch_evaluate(model_responses, judge_model="gpt-5.2"): results = [] for item in model_responses: score = g_eval( prompt=item["prompt"], response=item["response"], criteria=item["criteria"], judge_model=judge_model ) results.append(score) # 汇总统计 return { "mean": np.mean([r["score"] for r in results]), "p50": np.median([r["score"] for r in results]), "distribution": [r["score"] for r in results] }text### Level 3：人工抽检（每周，样本量 100-200）自动评估再准，也替代不了人的判断。每周从流量中随机抽 100-200 条，人工标注。人工标注的主要作用是：1. 校准自动评估：检查 G-Eval 的评分和人工评分是否存在系统性偏差2. 发现新问题：自动评估只看预设维度，人可能发现新的质量问题（比如语气不当、文化敏感性问题）## 评估的元问题：评估本身靠谱吗？我们做了一个元评估实验：让 5 个人类专家评估 1000 条模型输出，同时用 GPT-5、Claude Opus、Gemini 3 三个裁判模型评估同一批数据。结果：| 裁判模型 | Spearman 相关性 | 偏差方向 ||---------|----------------|---------|| GPT-5.2 | 0.87 | 偏正向 (+0.3) || Claude Opus 4.8 | 0.84 | 偏保守 (-0.2) || Gemini 3 Ultra | 0.81 | 偏正向 (+0.5) || 三个裁判的 Ensemble | 0.91 | 接近中性 |结论：用多个裁判模型的 Ensemble 比单裁判靠谱。pythondef ensemble_judge(prompt, response, criteria): judges = ["gpt-5.2", "claude-opus-4.8", "gemini-3-ultra"] scores = [] for judge in judges: score = g_eval(prompt, response, criteria, judge_model=judge) scores.append(score["score"]) # 去掉最高分和最低分，取平均（防止异常裁判） trimmed = sorted(scores)[1:-1] return sum(trimmed) / len(trimmed)textEnsemble 评估的成本是单裁判的 3 倍，但如果评估结果直接影响模型迭代决策（决定要不要上线新版本），这个成本是值得的。## 总结自动评估没有"银弹"。我的建议是：1. 能用规则评估的用规则——既不花钱又不偏2. 主观任务用 G-Eval + 多裁判 Ensemble——相关性 0.9+3. 每周人工抽检 100 条——校准自动评估，发现盲区4. 不要只盯着分数——分数的分布、离群值、下降趋势比单次分数更重要最后一条最重要。一个模型的平均分从 8.3 掉到 8.1 可能不显著，但如果"数学推理"子维度从 8.5 掉到了 6.2，这就是一个需要停机上线的信号。