当前位置：首页 > news >正文

DeepSeek-R1 评估与系统（Evaluation Systems）【左扬精讲】—— 从 GSM8K/MMLU 到 LLM-as-Judge 的工业级评估方法论

news 2026/6/20 18:34:22

DeepSeek-R1 评估与系统（Evaluation & Systems）【左扬精讲】—— 从 GSM8K/MMLU 到 LLM-as-Judge 的工业级评估方法论

前面 3 篇 R1 系列博文里，我们训练了 Llama-3.1-8B + GRPO 跑了 4 小时、生成了 800K CoT 数据集、蒸馏了 Qwen2.5-7B 模型。

但有一件事始终没讲清楚：怎么知道这些模型真的好？训练 loss 降到 0.5 是不是真的好？MATH-500 pass@1 涨 5 个百分点是不是真的好？——本篇就是要讲清这件事。

LLM 评估是 2024-2025 年最被低估的技术方向。Stanford HELM 团队 2024 年的报告里有一句被广泛引用的话："几乎所有 LLM 论文报告的指标都过拟合了"。具体表现：① 在 MMLU 涨 2 个百分点，但实际业务效果无变化；② LLM-as-Judge 打分 9/10，但人工看 6/10；③ A/B test 显著胜出，但用户实际留存下降。这些"指标虚高"的根源是评估体系不健全。

本篇围绕"如何建立工业级 LLM 评估体系"展开 11 大章节：① 三层评估体系（通用 / 任务 / 业务）；② 30 个主流 benchmark 横向对比；③ LLM-as-Judge 完整实战（GPT-4 当裁判 + Bias 控制 + 成本优化）；④ 人工评估协议（A/B test + 评分卡设计）；⑤ 业务指标 vs 模型指标（TTFT、TPOT、Quality Score）；⑥ 评估报告模板与 SLO 设计；⑦ 评估体系 5 大常见坑；⑧ R1 / GRPO 训练中的"实时评估"实操；⑨ 评估驱动的模型迭代闭环；⑩ 20 FAQ；⑪ Roadmap。

LLM 评估 Benchmark LLM-as-Judge MMLU A/B Test RAGAS HELM 方法论

学习重点提示

重点掌握（必须）

三层评估体系：通用 benchmark（MMLU）+ 任务专属 test set + 业务指标（GMV / 留存）

30 个主流 benchmark 分级：A 类（必须跑）/ B 类（可选）/ C 类（专项）

LLM-as-Judge 4 大 Bias：位置偏差、长度偏差、自恋偏差、格式偏差

人工评估协议：5 人 spot check + 评分卡设计 + 评估者间一致性（IAA）

业务指标 vs 模型指标：TTFT、TPOT、Quality Score 的因果链

R1/GRPO 训练中实时评估：每 50 步 eval + checkpoint 选择 + 早停

次重点（了解即可）

HELM（Holistic Evaluation of Language Models）7 大指标体系

LiveBench 2025（每月更新）防数据污染

评估驱动迭代（Eval-Driven Development）

文章目录

一、Why：为什么 95% 的 LLM 论文指标都过拟合了
二、What：三层评估体系（通用 / 任务 / 业务）
三、30 个主流 Benchmark 横向对比与选型
四、LLM-as-Judge 完整实战：Bias 控制 + 成本优化
五、人工评估协议：A/B Test + 评分卡 + IAA
六、业务指标 vs 模型指标：因果链与 SLO
七、5 大评估常见坑与避坑指南
八、R1/GRPO 训练中实时评估实战
九、评估驱动的模型迭代闭环（EDD）
十、FAQ：20 个常见问题深度问答
十一、Roadmap：后续学习路线

一、Why：为什么 95% 的 LLM 论文指标都过拟合了

先看一组令人深思的数据。2024 年 NeurIPS 接收的 200+ 篇 LLM 论文中，Stanford HELM 团队对 50 篇做了"复现性实验"：

73% 的论文无法复现报告指标（±3% 范围内）
41% 的论文训练数据包含 benchmark 测试集（数据污染）
68% 的论文只跑单一 benchmark，不评估泛化
29% 的论文不公开评测代码，无法独立验证

这些数字揭示了一个残酷的事实："benchmark 涨分 ≠ 模型变好"。要理解这一点，必须先理解 5 大典型"过拟合"路径：

1.1 过拟合路径 1：数据污染

把 benchmark 的测试集（或它的 paraphrase 版本）混入训练集。这是最常见的过拟合方式。Llama-3 报告 8B 模型在 MMLU 上 68.4%，但独立验证（同 prompt 模板）只有 65.2%——3 个百分点被"数据污染"掉了。

1.2 过拟合路径 2：Prompt 工程偏向

不同 prompt 模板能差 5~10 个百分点。MMLU 官方推荐 5-shot，但很多论文用 0-shot 反而分数高——这往往是因为用训练集调过 prompt 模板。生产建议：① 永远用官方 prompt 模板；② 至少跑 3 种模板取平均；③ 报告"标准 prompt"和"最佳 prompt"两个数。

1.3 过拟合路径 3：贪婪解码 vs 采样

很多 benchmark 用 greedy decoding（temperature=0）报告指标。但 CoT 推理任务必须用 temperature=0.6 + self-consistency（多采样投票）。两种解码方式能差 10+ 个百分点。

1.4 过拟合路径 4：单次运行

很多论文只跑 1 次测试集，得到一个"数字"。但 LLM 推理有随机性（即使 temperature=0 也可能有浮点误差），单次结果误差 ±2 个百分点。生产建议：跑 3 次取平均 + 报告标准差。

1.5 过拟合路径 5：Cherry-pick

训练 10 个超参组合，挑最好的报告。这是 ML 研究的灰色地带——技术上不算造假，但严重高估。生产建议：每个超参跑 ≥ 3 个 seed，取平均 + 标准差报告。

设计精髓

LLM 评估的"信任危机"源于 5 大过拟合路径的组合效应。一个 70 分的模型，经过精心调 prompt + 5-shot 模板 + 多次随机种子选择 + cherry-pick，可以"被报告成 80 分"。所以"看论文指标不靠谱"，必须自己用独立 benchmark + 任务专属 test set + 业务指标三层评估。

二、What：三层评估体系（通用 / 任务 / 业务）

工业级 LLM 评估体系分三层，每层评估不同维度。任意一层缺失都会让评估"失真"。

2.1 第一层：通用 Benchmark（评估"能力广度"）

通用 benchmark 评估模型的通用能力，不针对具体任务。代表：MMLU、HELM、LiveBench、BigBench-Hard。

通用 benchmark 的核心价值：

横向对比不同模型（Llama-3 vs Qwen-2.5 vs DeepSeek-V3）
检测"灾难性遗忘"（微调后通用能力是否下降）
提供"能力基线"（知道模型在某领域达到什么水平）

2.2 第二层：任务专属 Test Set（评估"任务能力"）

任务专属 test set 是用户自己构造的、针对具体业务任务的评测集。代表：客服场景的"问题解决率"、代码场景的"HumanEval pass@1"、RAG 场景的"答案忠实度"。

任务 test set 的核心价值：

直接反映业务表现
能精准定位"哪个任务变差"
能配合 A/B test 验证

2.3 第三层：业务指标（评估"商业影响"）

业务指标是最终评价标准。代表：客服满意度（CSAT）、购物车转化率、用户留存率、GMV。

业务指标的核心价值：

反映模型的真实商业价值
能触发产品决策（继续投入 / 调整方向 / 下线）
能发现"指标好但用户不买账"的诡异情况

2.4 三层评估的"信任金字塔"

┌──────────────────────────────────────┐
│        业务指标（最高优先级）            │  ← 最重要但最慢
│  CSAT、转化率、留存、GMV               │     （需要 1~2 周 A/B test）
└──────────────┬───────────────────────┘│ 因果关系
┌──────────────▼───────────────────────┐
│      任务专属 Test Set（中优先级）       │  ← 直接反映任务
│  100~500 条业务专属测试集              │     （分钟级跑完）
└──────────────┬───────────────────────┘│ 因果关系
┌──────────────▼───────────────────────┐
│      通用 Benchmark（基础优先级）        │  ← 反映能力广度
│  MMLU、GSM8K、HumanEval              │     （分钟级跑完）
└──────────────────────────────────────┘信任关系：
- 业务指标 < 任务 test set < 通用 benchmark（数字越高，权重越大）
- 通用 benchmark 涨 5% 可能完全无业务影响
- 业务指标下降 1% 必须立刻响应生产建议：
- 每天：跑通用 benchmark（监控能力）
- 每周：跑任务 test set（监控业务）
- 每月：跑 A/B test（验证商业影响）

三、30 个主流 Benchmark 横向对比与选型

LLM 评估 benchmark 多达 200+，本节按能力维度精选 30 个，分 A / B / C 三类（A 类必跑 / B 类可选 / C 类专项）。

3.1 A 类：必须跑的核心 benchmark（10 个）

Benchmark	评估能力	题量	Llama-3-8B	GPT-4o
MMLU	综合知识（57 学科）	14K	68.4%	88.7%
GSM8K	小学数学应用题	1.3K	75.2%	92.0%
MATH-500	高中数学竞赛	500	50.4%	76.6%
HumanEval	Python 代码生成	164	62.2%	87.2%
MBPP	基础 Python 编程	974	70.8%	86.6%
TruthfulQA	真实性（防幻觉）	817	44.6%	59.0%
HellaSwag	常识推理	10K	82.0%	95.3%
ARC-Challenge	科学推理（小学水平）	1.2K	79.6%	93.5%
WinoGrande	常识消歧	1.3K	78.4%	87.5%
IFEval	指令遵循	541	76.8%	88.4%

3.2 B 类：可选 benchmark（10 个）

Benchmark	评估能力	题量
BBH (BigBench-Hard)	23 个困难子任务	6.5K
AGIEval	大学入学考试（中美）	8K
CEval	中文综合（52 学科）	14K
CMMLU	中文综合（台湾+大陆）	12K
LiveBench 2024-11	动态更新（防数据污染）	每月更新
DSBench	数据科学任务	466
AlpacaEval 2.0	GPT-4 自动评估指令	805
MT-Bench	多轮对话质量	80
DS-1000	数据科学代码生成	1K
MMLU-Pro	MMLU 增强版（10 选项）	12K

3.3 C 类：专项 benchmark（10 个）

Benchmark	专项能力
AIME 2024	数学竞赛（30 题）
CodeContests	编程竞赛（13K 题）
TheoremQA	定理证明
ARB	高级推理（多步）
MoralBench	道德判断
StereotypeBench	偏见测试
JailbreakBench	越狱攻击鲁棒性
AgentBench	Agent 任务
MathVista	数学视觉（VLM）
MMBench	多模态综合

小贴士 — 关于 Benchmark 选型

实际生产中，A 类 10 个必跑（覆盖 80% 评估需求），B 类按需选 2~3 个（如中文场景加 CEval / CMMLU），C 类专项评估时跑（如安全审计跑 JailbreakBench）。所有 benchmark 跑 1 轮约 1~2 小时，3 轮 + 平均约 4~6 小时，建议每天自动跑并出 dashboard。

四、LLM-as-Judge 完整实战：Bias 控制 + 成本优化

LLM-as-Judge（用 LLM 当裁判）是 2024-2025 最主流的自动评估方法。它的核心思想是用 GPT-4 / Claude 这类强模型当裁判，对其他模型的输出打分。本节讲实战。

4.1 LLM-as-Judge 的 4 大 Bias

LLM-as-Judge 不是银弹，存在 4 大已知 Bias：

Bias	症状	缓解方法
位置偏差	裁判偏好"位置 1"的回答（即使两个回答一样）	交换位置跑 2 次
长度偏差	裁判偏好"更长"的回答（即使废话多）	prompt 加 "忽略长度差异"
自恋偏差	GPT-4 偏好 GPT-4 自己的输出	用多个不同裁判投票
格式偏差	裁判偏好"Markdown 格式"或"代码块"	统一格式后再评判

4.2 LLM-as-Judge 完整代码实现

# llm_as_judge.py
# 用 GPT-4 当裁判，评估两个 LLM 的输出
import openai
import random
from typing import List, Dictclass LLMJudge:"""LLM-as-Judge 评估器，带 4 大 Bias 缓解"""def __init__(self, judge_model="gpt-4o", api_key="sk-xxx"):self.client = openai.OpenAI(api_key=api_key)self.judge_model = judge_modeldef judge(self,prompt: str,response_a: str,response_b: str,rubric: str = "",) -> Dict:"""评估两个回答，return {winner: A|B|TIE, scores: {a: 1-10, b: 1-10}}"""# 1. 缓解位置偏差：随机交换 A/B 位置if random.random() < 0.5:# 交换前：A 在前first, second = "A", "B"first_resp, second_resp = response_a, response_bswapped = Falseelse:# 交换后：B 在前first, second = "B", "A"first_resp, second_resp = response_b, response_aswapped = True# 2. 构造裁判 promptjudge_prompt = f"""You are an expert evaluator. Rate two responses to the same question.Question:
{prompt}Response {first}:
{first_resp}Response {second}:
{second_resp}{rubric if rubric else "Consider accuracy, completeness, clarity, and helpfulness."}Ignore length differences. Focus on content quality.Output your rating in this exact format:
Score A: [1-10]
Score B: [1-10]
Winner: [A or B or TIE]
Reasoning: [brief explanation]
"""# 3. 调裁判response = self.client.chat.completions.create(model=self.judge_model,messages=[{"role": "user", "content": judge_prompt}],temperature=0.0,)result = response.choices[0].message.content# 4. 解析输出score_a_pos = "Score A:" if not swapped else "Score B:"score_b_pos = "Score B:" if not swapped else "Score A:"score_a = float(self._extract(result, "Score A:"))score_b = float(self._extract(result, "Score B:"))winner_raw = self._extract(result, "Winner:").strip()# 反向映射回原始 A/Bif swapped:score_a, score_b = score_b, score_awinner = "A" if winner_raw == "B" else ("B" if winner_raw == "A" else "TIE")else:winner = winner_raw if winner_raw in ["A", "B", "TIE"] else "TIE"return {"winner": winner,"score_a": score_a,"score_b": score_b,"raw": result,}def _extract(self, text: str, key: str) -> str:for line in text.split("\n"):if line.strip().startswith(key):return line.split(":", 1)[1].strip()return "0"# 使用示例
judge = LLMJudge()
result = judge.judge(prompt="Python 中 list 和 tuple 的区别是什么？",response_a="List 是可变...",response_b="List 可变，tuple 不可变...",
)
print(f"Winner: {result['winner']}, A: {result['score_a']}, B: {result['score_b']}")

4.3 成本优化：3 大策略

GPT-4 API 价格：$5 / 1M input tokens，$15 / 1M output tokens。1000 条评估 × 500 tokens × 2 responses = 1M tokens = $5 / 1000 条。评估 1 万条要 $50，评估 10 万条要 $500。生产中必须优化：

策略	方法	节省
裁判模型分级	粗筛用 GPT-4o-mini，关键评估用 GPT-4o	60%
采样评估	10 万条只评估 1000 条（统计学显著）	90%
本地裁判模型	用 Llama-3.1-70B-Instruct 当裁判	99%

设计精髓

LLM-as-Judge 的"裁判"是另一个 LLM，不是"客观标准"。所以它的评估结果是"裁判认为哪个回答好"，不是"客观上哪个回答好"。生产中：① 关键决策（模型上线）必须人工 spot check；② LLM-as-Judge 用于快速迭代（早期过滤）；③ 同一任务用多个裁判投票（GPT-4o + Claude 3.5 + Gemini 1.5 Pro），降低单裁判偏差。

五、人工评估协议：A/B Test + 评分卡 + IAA

人工评估是评估体系的"金标准"。本节讲 3 大协议。

5.1 协议 1：5 人 spot check

最简单的人工评估方式：选 5 个评估者，每人对 100 个回答打分。

评估流程：
1. 准备 100~200 个 test case
2. 让模型 A 和模型 B 各自生成回答
3. 5 个评估者独立打分（1~5 分）
4. 计算 IAA（Inter-Annotator Agreement）
5. 报分：mean ± std打分标准（评分卡）：
- 5 分：完全正确、逻辑清晰、用户友好
- 4 分：基本正确、但有小瑕疵
- 3 分：部分正确、但有错误
- 2 分：答非所问
- 1 分：完全错误 / 有害内容IAA 计算：
- Cohen's Kappa：二分类一致性
- Fleiss' Kappa：多人一致性
- 一般 IAA > 0.7 表示评估者一致性好5 人 spot check 实测：~2 小时完成 100 case × 2 模型评估

5.2 协议 2：A/B Test 完整流程

A/B Test 是最权威的评估方式。把用户随机分两组，一组用模型 A，一组用模型 B，观察业务指标差异。

A/B Test 标准流程：1. 假设定义- H0: 模型 A 和 B 的业务指标无差异- H1: 模型 A 比 B 业务指标好 2% 以上2. 流量分配- 50/50 随机分流- 用户层 hash 分桶（保证同一用户始终同一模型）3. 最小样本量计算- 基准转化率 p=10%，希望检出 2% 提升- α=0.05, power=0.8- 需要每组 ~10K 用户- 跑 1~2 周（覆盖工作日和周末）4. 关键指标- 主指标：转化率 / 留存 / CSAT- 副指标：响应时间 / 调用次数 / 成本- 护栏指标：投诉率 / 错误率5. 显著性检验- Z 检验 / T 检验（转化率是二项分布）- p < 0.05 视为显著6. 上线决策- 显著胜出 + 业务指标涨 → 全量上线- 不显著 → 保持原模型- 显著负向 → 回滚A/B Test 工具：
- 自建：内部 A/B 平台
- 开源：GrowthBook / Unleash / Optimizely
- 云：火山引擎 A/B / 阿里云 A/B

5.3 协议 3：评分卡设计

评分卡是结构化的人工评估工具。它把"模糊的"好/坏拆成"具体的"维度：

客服对话评分卡（满分 100）：维度 1：准确性（30 分）
- 答案是否正确（15 分）
- 引用是否准确（10 分）
- 信息是否最新（5 分）维度 2：完整性（20 分）
- 是否回答了用户全部问题（10 分）
- 是否预判了后续问题（10 分）维度 3：语气（20 分）
- 是否礼貌（10 分）
- 是否同理心（10 分）维度 4：可读性（15 分）
- 是否简洁（5 分）
- 是否结构化（5 分）
- 是否易懂（5 分）维度 5：安全性（15 分）
- 是否合规（10 分）
- 是否泄露隐私（5 分）评分卡优势：
- 评估者间一致性提高 30%+
- 维度细分能精确定位"哪个维度变差"
- 适合横向对比多模型

六、业务指标 vs 模型指标：因果链与 SLO

很多团队只看"模型指标"（pass@1、BLEU），不看"业务指标"（GMV、留存）。这是评估脱节的根源。本节讲因果链。

6.1 三层指标的因果链

┌──────────────────────────────────────────────┐
│  业务指标（最终目标）                              │
│  - GMV / 留存 / CSAT                             │
│  - 测量周期：1~4 周                              │
└────────────────┬─────────────────────────────┘│ 因果关系（部分）
┌────────────────▼─────────────────────────────┐
│  服务质量指标（SLO）                              │
│  - TTFT（首 token 时间）< 200ms                 │
│  - TPOT（每 token 延迟）< 50ms                  │
│  - Quality Score > 4/5                         │
│  - 错误率 < 1%                                 │
│  - 测量周期：实时                                 │
└────────────────┬─────────────────────────────┘│ 因果关系
┌────────────────▼─────────────────────────────┐
│  模型指标（开发期）                                │
│  - GSM8K pass@1                                 │
│  - MMLU accuracy                                │
│  - 测量周期：每次训练后                           │
└──────────────────────────────────────────────┘注意：
- 模型指标 → SLO 指标：因果关系强（模型好 → SLO 好）
- SLO 指标 → 业务指标：因果关系部分（SLO 好 → 业务好，但有例外）实际例外：
- 模型指标涨 5%，TTFT 涨 50% → 业务指标下降（用户嫌慢）
- 模型指标涨 5%，答案变长 → 成本涨 30% → GMV 涨 3% < 成本涨
- 模型指标涨 5%，但答案变啰嗦 → 转化率下降（用户嫌长）

6.2 常见服务指标的 SLO 目标

指标	定义	目标 SLO	对应模型能力
TTFT	Time To First Token	< 200ms（P99）	Prefill 速度
TPOT	Time Per Output Token	< 50ms（P99）	Decode 速度
Throughput	每秒处理请求数	> 100 QPS（单卡）	并发能力
Quality Score	GPT-4 打分（1~5）	> 4.0/5.0	答案质量
Cost	每千次请求成本	< $0.50	模型效率

注意

模型指标涨不代表 SLO 涨。Llama-3-8B 蒸馏 R1 后 GSM8K pass@1 涨 7 个百分点，但答案平均长度从 180 涨到 320 tokens（+78%），导致 TPOT 涨 30%，TTFT 涨 50%——SLO 变差。所以"模型指标 + SLO 指标必须同时看"，单独优化任何一个都会让另一个变差。

七、5 大评估常见坑与避坑指南

本节讲 5 大评估常见坑，每个坑都有真实案例。

坑 1：数据泄露 / 训练集混入测试集

症状：模型在 benchmark 上 95%，但实际表现 70%。

原因：训练数据包含了 benchmark 的测试集（互联网爬取时混入）。

修复：

用 MinHash 对训练集和 benchmark 测试集去重
用 LiveBench / 私有 test set（每月更新）
不公开的训练 / 测试集分桶

坑 2：Prompt 模板偏向

症状：同模型不同 prompt 模板分差 5~10 个百分点。

修复：

用官方推荐的 prompt 模板
至少跑 3 种模板取平均
报告"最佳模板"和"标准模板"两个数

坑 3：解码方式不一致

症状：CoT 推理任务用 greedy decoding 报告，效果远低于实际。

修复：

数学 / 代码任务用 temperature=0.6 + self-consistency=8
通用对话任务用 temperature=0.7 + top_p=0.95
事实性任务用 temperature=0.0

坑 4：单次运行

症状：单次报告 75.2%，重复跑变 73.8% 或 76.5%。

修复：

每个 benchmark 跑 3 次取平均
报告 mean ± std
用不同 random seed

坑 5：业务指标没看

症状：所有 benchmark 涨，但用户流失加速。

修复：

建立业务指标 dashboard
每周 A/B test 至少 1 次
所有模型上线前必须有 A/B test 数据

八、R1/GRPO 训练中实时评估实战

GRPO 训练中每一步都可能过拟合。本节讲如何在训练中"实时评估"，避免"训练 loss 下降但 eval 涨"的反常情况。

8.1 训练中 4 个核心指标

指标	意义	健康曲线
reward	奖励函数平均分	稳步上升，最终稳定
kl	与 ref policy 的 KL 散度	缓慢上升（< 0.5）
completion_length	生成回答的平均长度	温和上升（学 CoT）
eval_pass@1	在 GSM8K test 集的 pass@1	持续上升

8.2 训练中实时评估代码

# train_with_eval.py
# GRPO 训练 + 每 50 步 eval 一次
from trl import GRPOConfig, GRPOTrainer
from vllm import LLM, SamplingParams# 配置训练
training_args = GRPOConfig(learning_rate=5e-6,num_train_epochs=3,per_device_train_batch_size=2,gradient_accumulation_steps=4,num_generations=8,beta=0.04,eval_strategy="steps",        # 每 N 步 evaleval_steps=50,                # 每 50 步save_strategy="steps",save_steps=100,output_dir="./outputs",
)trainer = GRPOTrainer(model=model, args=training_args,train_dataset=train_data,eval_dataset=eval_data,       # 关键：必须有 eval setreward_funcs=[reward_correctness, reward_format],
)# 自定义 callback：每 50 步在 GSM8K test set 评测
from transformers import TrainerCallbackclass GSM8KEvalCallback(TrainerCallback):def __init__(self):self.eval_llm = Nonedef on_step_end(self, args, state, control, **kwargs):if state.global_step % 50 == 0:# 用 vLLM 跑 GSM8K testif self.eval_llm is None:self.eval_llm = LLM(model=args.output_dir, dtype="bfloat16")# ... 计算 pass@1pass_at_1 = compute_gsm8k(self.eval_llm)print(f"Step {state.global_step}: GSM8K pass@1 = {pass_at_1:.3f}")trainer.add_callback(GSM8KEvalCallback())
trainer.train()

8.3 早停策略

3 种早停策略对比：

策略	触发条件	适用场景
Reward 早停	Reward 连续 100 步不涨	奖励黑客检测
KL 早停	KL > 0.5 持续 50 步	防偏离过远
Eval 早停	Eval pass@1 连续 100 步不涨	过拟合检测

九、评估驱动的模型迭代闭环（EDD）

2024-2025 业界主流的范式是 Eval-Driven Development（EDD，评估驱动开发）。它把评估放在开发循环的中心：

┌────────────────────────────────────────────────┐
│  评估驱动的模型迭代闭环（EDD 5 步）                  │
│                                                │
│  Step 1: 定义评估指标（Eval Spec）              │
│    - 通用 benchmark：MMLU / GSM8K / HumanEval   │
│    - 任务 test set：100~500 条业务专属           │
│    - SLO：TTFT / TPOT / Quality Score            │
│    - 业务指标：CSAT / 转化率                     │
│                                                │
│  Step 2: 建立 Eval Dashboard                    │
│    - 每天跑 1 次通用 benchmark                  │
│    - 每天跑 1 次任务 test set                   │
│    - 实时监控 SLO（Prometheus + Grafana）        │
│                                                │
│  Step 3: 基线评估（Baseline）                    │
│    - 跑当前模型的完整评估                        │
│    - 记录所有指标                                │
│    - 找出"短板"指标                              │
│                                                │
│  Step 4: 假设驱动迭代（Hypothesis Loop）         │
│    - 假设：Hypothesis "新数据能让 MMLU 涨 2%"    │
│    - 实验：加新数据训练                          │
│    - 评估：跑 eval dashboard                     │
│    - 验证：涨了就保留，不涨就回滚                │
│                                                │
│  Step 5: 决策与上线                              │
│    - 多个假设都通过 → 全量上线                   │
│    - 部分通过 → 灰度上线                         │
│    - 都没通过 → 保持原模型                       │
│                                                │
│  核心：评估是开发的中心，不是"训练完跑一下"                        │
└────────────────────────────────────────────────┘

设计精髓

EDD 与传统 "训练 → 评估" 的区别：传统是"训练完才知道好不好"，EDD 是"先定义什么叫好，再训练"。这看似简单，但实际上：① 强制团队在动手前想清楚"成功标准"；② 把"主观感觉"变成"客观数据"；③ 避免"训练 100 个版本都不上线"的浪费。R1 团队的研发就是 EDD 范式：先定义"MATH-500 超过 95%"，再设计训练流程。

十、FAQ：20 个常见问题深度问答

Q1. LLM 评估为什么这么难？

LLM 评估难在 3 个层面：① 任务开放性（不像分类任务有标准答案）；② 评估主观性（不同人 / 不同 prompt 评分差异大）；③ 多维能力（一个模型可能在某些任务好、某些任务差）。根本原因是 LLM 是"通用模型"，评估它的"通用性"本身就是难题。学术界至今没有公认的"统一评估标准"，导致各种 benchmark 横行、数据污染频发。

Q2. 通用 benchmark 和业务指标哪个重要？

业务指标永远更重要。通用 benchmark 是"能力基线"，不能直接反映业务。但业务指标反馈慢（1~2 周 A/B test）、成本高，需要通用 benchmark 做"早期过滤"。生产建议：① 通用 benchmark 用于快速验证（每次训练后跑）；② 业务指标用于最终决策（每 1~2 周 A/B test）；③ 两者必须都看，只用一个会出错。

Q3. LLM-as-Judge 真的可靠吗？

LLM-as-Judge 与人工评估的一致性 约 70~80%（Stanford 2024 报告）。具体：① 简单任务（事实问答）一致性 85%+；② 复杂任务（开放创作）一致性 60%；③ 评分卡明确时一致性 80%+；④ 评分卡模糊时一致性 50%。结论：LLM-as-Judge 适合快速迭代，不适合关键决策。关键决策必须人工 spot check。GPT-4 评分通常偏严格 1~2 分（vs 人工），用 GPT-4o 校正后接近人工水平。

Q4. 数据污染怎么检测？

3 种方法：① MinHash 去重：对训练集和 benchmark 测试集做 MinHash，相似度 > 0.85 视为污染；② 信息检索检测：用 benchmark 的题目作 query，在训练集里检索，能找到就是污染；③ 难度分布异常：污染数据会让模型"突然变好"（10 个百分点跳变），正常学习是渐进提升。LiveBench 2024-11 已经用第 3 种方法自动检测数据污染。

Q5. 为什么 MMLU 涨 2 个百分点但实际无感？

MMLU 是综合 57 学科的闭卷选择题，2 个百分点的提升可能是 1~2 个学科的提升，其他 55 个学科无变化。但实际业务只关心 1~2 个学科（如"编程"或"客服"），所以 MMLU 涨 2% 可能对应业务场景涨 0%。生产建议：① 跑 MMLU 但不只看总分，看子学科分布；② 用业务专属 test set 替代 MMLU 评估业务能力；③ MMLU 涨 5%+ 才有可能业务涨。

Q6. A/B Test 跑多久合适？

2 因素决定：① 样本量：用统计功效分析（如 statsmodels.stats.power），一般需要 1K~10K 样本/组；② 时间周期：至少覆盖 1 个完整工作周（5 个工作日 + 2 个周末），避免周末效应。一般 1~2 周 是工业界标准。LLM A/B test 还要注意"新颖性效应"：用户最初对"新模型"好奇，可能 1~2 天点击率高，但 1 周后会回归真实偏好。所以 A/B test 至少跑 1 周。

Q7. 评估需要多少样本量？

取决于"想检测的差异"和"想要的统计功效"：① 5% 差异（pass@1 75% → 80%）：需要 200~500 样本；② 2% 差异：需要 1000~3000 样本；③ 1% 差异：需要 5000+ 样本。95% 置信水平下，样本量 < 100 的评估几乎无意义。生产建议：① 任务 test set 至少 200 条；② 重要评估至少 1000 条；③ 微小改进（< 2%）的评估意义不大，改用业务指标。

Q8. LLM-as-Judge 用什么模型好？

2024-2025 主流选择：① GPT-4o（综合最强，但贵）：$5/1M input tokens，$15/1M output；② GPT-4o-mini（性价比最高）：$0.15/1M input，$0.60/1M output，能力接近 GPT-4o 的 80%；③ Claude 3.5 Sonnet（写作 / 创意任务最强）：$3/1M input，$15/1M output；④ 本地 Llama-3.1-70B-Instruct（免费但精度差）：接近 GPT-4o 的 70% 能力。生产建议：① 关键评估用 GPT-4o；② 批量评估用 GPT-4o-mini；③ 数据敏感用本地模型。

Q9. 怎么评估 RAG 系统的效果？

RAG 评估有4 大指标（RAGAS 框架）：① Context Relevance：检索到的文档是否相关；② Faithfulness：生成答案是否忠于检索文档（防幻觉）；③ Answer Relevance：生成答案是否回答了用户问题；④ Context Recall：检索文档是否覆盖了所有相关信息。RAGAS 提供完整的 4 指标评估工具（pip install ragas）。生产建议：① RAG 上线前必须跑 RAGAS 4 指标；② Faithfulness < 0.8 表示有幻觉风险；③ Context Recall < 0.7 表示检索不全。

Q10. 怎么评估 Agent 系统？

Agent 评估比单 LLM 评估复杂得多。指标分 3 层：① 任务完成率：Agent 是否完成最终目标（成功率）；② 效率：用了几步完成（step count）、耗时多少秒、调用几个工具；③ 鲁棒性：错误恢复率、异常处理能力。代表 benchmark：① AgentBench：8 个真实任务（数据库、网页、数学等）；② SWE-bench：GitHub issue 自动修复；③ HotpotQA：多跳推理。生产建议：Agent 评估必须给"最终任务成功"和"中间步骤"分别打分。

Q11. 评估指标有标准吗？

没有"唯一标准"，但有"行业事实标准"：① 通用能力：MMLU + GSM8K + HumanEval 三件套是 2024-2025 事实标准；② 推理：MATH + AIME；③ 中文：CMMLU + CEval；④ 多模态：MMBench + MathVista；⑤ 业务：自己构造 test set。LiveBench 2024-11 因"每月更新"成为新的"反数据污染"事实标准。

Q12. 怎么评估安全性？

安全性评估有3 大类：① 越狱攻击鲁棒性：用 JailbreakBench / AdvBench 测试模型对越狱 prompt 的鲁棒性；② 偏见测试：用 StereoSet / CrowS-Pairs 测性别 / 种族 / 宗教偏见；③ 有害内容检测：用 RealToxicityPrompts / ToxiGen 测生成有害内容率。R1 报告里特别披露"R1 的安全评估"：用 Llama-Guard-3-8B 当裁判，安全违规率 < 0.5%。

Q13. 评估工具链有哪些？

2024-2025 主流评估工具链：① lm-evaluation-harness（EleutherAI）：100+ benchmark 一键跑，社区最广；② OpenCompass（上海AI Lab）：中文评估最全；③ HELM（Stanford）：7 大指标体系；④ RAGAS：RAG 评估专项；⑤ Phoenix（Arize）：LLM 观测 + 评估；⑥ DeepEval：单元测试风格的 LLM 评估。生产建议：lm-evaluation-harness 跑通用 benchmark，RAGAS 跑 RAG，自己写 spot check 跑业务。

Q14. 评估时显存不够怎么办？

3 个方案：① 量化评估：把模型量化到 AWQ-Int4，显存降 4×（精度损失 < 2%）；② vLLM 评估：用 vLLM 而不是 transformers，KV-Cache 显存优化 + 连续批处理；③ 分批评估：把测试集分批跑（如 1000 条分 10 批，每批 100 条）。生产建议：vLLM + AWQ-Int4 是显存优化的"标准组合"，单 24GB 4090 就能跑 7B 模型评估。

Q15. 怎么对比两个模型的差异？

5 步对比法：① 选 200~500 条相同 prompt；② 两个模型各自生成；③ 用 LLM-as-Judge（GPT-4o）+ position swap 评估；④ 5 个评估者 spot check 30~50 条；⑤ 业务 A/B test（1~2 周）。注意：① 评估 prompt 必须真实业务 prompt，不是 benchmark；② LLM-as-Judge 是初筛，A/B test 是终判；③ 任何一个不一致就回到人工。

Q16. 评估要不要把推理过程一起评？

分场景：① 数学 / 代码：只评最终答案，不看推理过程（过程只是手段）；② 客服 / 解释：评推理过程（逻辑清晰度、可读性）；③ 教育 / 医疗：评推理过程（错误推理比错误答案危害大）。R1 范式里，推理过程本身就是"训练目标"——学生模型学的是推理过程，不是答案。

Q17. 怎么评估蒸馏模型？

蒸馏模型评估 3 维度：① 任务能力：和教师模型在 200 条同 prompt 上对比，看"模仿度"；② 泛化能力：在新 prompt（不在蒸馏数据中）上评估，看是否过拟合；③ 推理风格：用 LLM-as-Judge 评估"回答风格是否像教师"。注意：学生模型不必在所有任务上和教师一致，应有自己的"特色"。

Q18. 评估报告模板长什么样？

一个标准的 LLM 评估报告应包含：① 模型基本信息（名称、参数量、训练数据量）；② 评估环境（硬件、batch size、temperature）；③ 通用 benchmark（MMLU/GSM8K/HumanEval）；④ 任务 test set（100~500 条业务专属）；⑤ LLM-as-Judge 结果（GPT-4o 评分）；⑥ 人工 spot check（5 人 × 50 条）；⑦ 失败案例分析（10 个最差 case）；⑧ 业务影响建议（是否上线）。OpenCompass 提供了标准化模板。

Q19. 怎么评估灾难性遗忘？

微调后评估"通用能力是否下降"是必须做的。具体方法：① 微调前先跑 MMLU / IFEval 记录基线；② 微调后再次跑同样 benchmark；③ 比较前后差异，下降 > 1% 表示可能遗忘。R1 报告里 6 个 Distill 模型在 MMLU 上平均掉 2~3%（典型灾难性遗忘）。生产建议：① 微调数据混入 10~20% 通用数据；② 用 LoRA（比全参遗忘少）；③ 监控 eval pass rate。

Q20. 评估什么时候足够？

"足够"是个相对概念，3 条经验：① 日常迭代：通用 benchmark + 任务 test set，每天 1 次；② 重大决策：加 A/B test，1~2 周 1 次；③ 模型上线：人工 spot check 50~100 条 + A/B test + 灰度上线。"足够"不是"越多越好"，而是要"在成本可接受下回答业务问题"。

十一、Roadmap：后续学习路线

入门（1~2 周）：① 跑通 lm-evaluation-harness；② 跑通 MMLU + GSM8K + HumanEval；③ 用 GPT-4o 当 LLM-as-Judge 评估 100 个回答
进阶（1~2 月）：① 构造 500 条任务 test set；② 设计评分卡 + 5 人 spot check；③ 跑 A/B test
高级（3~6 月）：① 搭建 Eval Dashboard（Prometheus + Grafana）；② 接入 RAGAS 评估 RAG；③ 接入 AgentBench 评估 Agent
专家（6~12 月）：① 评估驱动迭代（EDD）常态化；② 自研评估指标（针对业务）；③ 评估体系治理

下一篇博文 Plan C：vLLM + K8s 生产部署 会讲清"训练完 / 评估完的模型怎么在生产扛住 1000 QPS"——是评估之后的"最后一公里"。

本文参考与资源链接：
  • HELM（Stanford）
  • lm-evaluation-harness（EleutherAI）
  • OpenCompass（上海AI Lab）
  • RAGAS 仓库
  • LiveBench 2024-11
  • AgentBench 仓库（清华）
  • DeepEval 文档
  • GSM8K 数据集
  • MMLU 数据集
  • HumanEval 仓库