第 9 章 评估与基准

学习目标

• 掌握离线评估指标（准确率/F1/AUC/BLEU/ROUGE/PPL）的适用边界；
• 熟悉 LLM 能力基准：MMLU、GSM8K、HumanEval、MATH、BBH；
• 理解偏好评估：MT-Bench、Chatbot Arena、AlpacaEval 的方法论差异；
• 掌握 RAG 评估、Agent 评估、工具调用评估的分层框架；
• 理解人评、A/B 测试与在线指标的闭环；
• 认识幻觉、毒性、偏见、越狱评估与污染、红队、可信评估的雷区。

---

9.1 评估：生命周期的质检站

训练出的模型能不能用、比上一个版本好不好、能不能上线——评估回答这些问题。它是生命周期的「质检站」，也是唯一能阻止坏模型进入生产环节的关卡（第 19 章的 CI/CD/CT 会把评估自动化为发布门禁）。

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart LR
    A[模型版本] --> B[离线评估
基准+业务集]
    B -->|通过| C[在线小流量
A/B 与影子]
    B -->|不通过| D[回到数据/训练]
    C -->|达标| E[全量上线
在线监控]
    C -->|不达标| D
    E -->|反馈| F[评测集迭代]
    F --> B

评估的三条铁律（本章反复出现）：

1. 没有单一指标能描述 LLM——能力是多维的，评估必须成套；
2. 离线分数 ≠ 在线效果——最终裁判是用户行为；
3. 评测集是资产也是风险——污染的评测集比没有评测集更糟。

9.2 离线评估指标：从分类到生成

传统 ML 指标按任务类型分（这些指标在 LLM 时代依然用于分类/抽取类微调任务）：

指标	任务	定义	坑
Accuracy	分类	对的比例	类别不平衡时失效
Precision/Recall/F1	分类/抽取	查准、查全、调和平均	阈值敏感
AUC-ROC	排序/二分类	随机正例排在负例前的概率	只看排序不看校准
BLEU	文本生成	n-gram 重叠精度	不衡量语义，翻译界已弃用
ROUGE	摘要	n-gram 召回	同上，仅做粗筛
Perplexity	语言建模	$e^{\text{交叉熵}}$（第 7 章）	低 PPL ≠ 好回答，只说明「像训练分布」

关键认知：BLEU/ROUGE 对开放生成基本失效（同一个意思有无数种说法，n-gram 匹配不上），这正是 LLM 评估转向「模型评模型」与「人工/在线评估」的原因。PPL 只用于预训练过程监控（同分布可比），不能跨模型比较、更不能预测对话质量。

9.3 LLM 能力基准：MMLU、GSM8K、HumanEval、MATH、BBH

四大公版基准构成能力评估的「高考科目」：

基准	考什么	形式	满分线现状（2026）
MMLU	学科知识（57 科选择题）	4 选 1	头部模型 >90%，已饱和
GSM8K	小学数学应用题	数字答案	已饱和（>95%）
MATH	竞赛数学	数值+证明	接近饱和
HumanEval	代码生成（Python 函数）	单元测试通过率（pass@1）	已饱和（>90%）
BBH	综合推理（BIG-Bath 精选）	多任务	部分饱和

四个工程要点：

1. Prompt 格式决定分数：同样的模型，few-shot 数量、CoT 提示、答案抽取正则不同，MMLU 能差 5 个点以上。对比模型必须固定 harness（推荐用 lm-evaluation-harness 或 opencompass 统一跑）。
2. 饱和即失效：GSM8K 从「区分器」变成「及格线」，前沿区分已转移到更难的变体（GPQA、AIME、SWE-bench）。
3. 中文能力：公版基准偏英文，中文要用 C-Eval、CMMLU、SuperCLUE 等本土基准补充。
4. 版本快照：评测代码与 few-shot 样例要随评测集版本固化，否则跨时间对比无效。

9.4 偏好评估：MT-Bench、Arena、AlpacaEval

能力基准测「会不会做题」，偏好评估测「回答讨不讨人喜欢」。三条方法论路线：

• MT-Bench（Multi-Turn Bench）：80 道多轮对话题，由 GPT-4 级裁判模型按 1-10 打分。便宜、快，但裁判偏好会传导（裁判偏爱长答案、自家风格）。
• Chatbot Arena（LMSYS）：真实用户匿名对比两个模型的回答并投票，Elo 排名。目前最被信任的「真实感」指标——因为用户投票接近真实使用偏好，难以刷分。缺点：慢、贵、题目分布不可控（用户爱问什么就测什么）。
• AlpacaEval / AlpacaEval 2.0：给定指令集，模型回答 vs 参考模型（GPT-4）由裁判判胜负，报告胜率。2.0 引入长度控制（LC），修掉「更长=更好」的裁判偏差。

裁判模型的系统性问题（LLM-as-Judge 的三大偏差）：位置偏差（偏爱第一个答案）、长度偏差（偏爱长答案）、自恋偏差（偏爱与自己同家族的答案）。缓解手段：交换位置各判一次、长度控制、多个裁判交叉。凡是「模型评模型」的分数，都要当作「有噪声的偏好代理」而非真值。

9.5 RAG、Agent、工具调用评估

LLM 应用的评估自成体系，分组件与端到端两层：

9.5.1 RAG 评估（分层拆解）

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart LR
    A[Query] --> B[检索]
    B -->|召回| C[文档块]
    C --> D[生成]
    D --> E[回答]
    B -.检索指标.-> B1[召回率/MRR/nDCG]
    D -.忠实度.-> D1[回答是否忠于检索内容]
    E -.答案质量.-> E1[正确性/完整性/引用准确]

层	指标	工具
检索层	Recall@K、MRR、nDCG	标注 query-正确文档对
忠实层（Faithfulness）	回答有无检索外的编造	RAGAS、TruLens
答案层	正确性、完整性、引用命中率	人评 + LLM 裁判

RAG 的黄金三角：检索得到（recall）、答案忠于来源（faithfulness）、答案答对问题（correctness）。三层要分别度量——只看端到端正确率时，「检索对了但答错」和「检索错了但模型靠记忆答对」会被混在一起，而两者的修复动作完全不同（第 17 章展开）。

9.5.2 Agent 与工具调用评估

Agent 评估的复杂度在于「过程」而非「结果」：

• 工具调用格式：函数名/参数是否合法（JSON Schema 校验，可自动判）；
• 工具选择正确性：该调哪个工具、什么时候不调（拒答也是能力）；
• 轨迹评估（Trajectory）：多步规划的合理性——步数是否冗余、是否死循环；
• 端到端任务成功：最终状态是否达成（如 SWE-bench 的 issue 是否真被修复）。

基准代表：BFCL（Berkeley Function Calling Leaderboard）、τ-bench（多轮工具使用）、SWE-bench（真实 GitHub issue 修复）。Agent 评估的核心难题是「环境不稳定性」——外部工具的输出随时间变化，评测要打桩（mock）保证可复现，但 mock 又会失真。这个张力没有完美解，只有「关键路径打桩 + 抽样真实环境校验」的折中。

9.6 人评、A/B 测试、在线指标

离线评估之后是「真实世界」的检验：

人评（Human Evaluation）：标注员对回答按维度打分（有用/相关/无害/格式），或成对比较。质量取决于标注指南与标注员水平，成本高、周期长，用于关键版本的门禁与评测集建设。

A/B 测试：线上流量随机分组，新旧模型各服务一部分用户，比业务指标。这是最终裁判：

指标类型	例子	说明
参与度	对话轮数、留存、使用频次	用户用脚投票
满意度	点赞/点踩、CSAT 问卷	显式反馈
任务完成率	问题解决率、转化率	业务价值
成本	每 query token 成本、延迟	反向指标

LLM 特有的在线坑：位置与长度效应在线上同样存在；A/B 的显著性检验周期要预计算（方差大时要更长的实验）；「模型变长=用户更满意」的假象要用长度归一化剥离。影子流量（shadow deployment，新模型只推理不返回用户）用于上线前的生产流量回归测试（第 16 章）。

9.7 幻觉、毒性、偏见、鲁棒性、越狱评估

安全与负责任维度的评估（第 23 章治理视角展开）：

• 幻觉：事实性幻觉用「可验证事实 QA」测（答案可与知识库比对）；忠实性幻觉用 RAGAS 的 faithfulness 维度。「拒答正确率」也是指标——不知道就说不知道。
• 毒性：RealToxicityPrompts 等数据集 + Perspective API 类毒性分类器。
• 偏见：BBQ（刻板印象问答）、Winogender（性别职业关联）、WinoBias。按子群体分性能差距（第 6 章的偏差度量）。
• 鲁棒性：对抗扰动（同义改写、错别字、prompt 格式变化）下的分数稳定性——分数波动大说明能力是「背出来的」。
• 越狱（Jailbreak）：恶意 prompt 绕过安全对齐。用 AdvBench、HarmBench 等红队数据集测攻击成功率（ASR）。

9.8 评估集污染、可信评估、红队测试

9.8.1 污染（Contamination）

第 6 章埋的雷在这里爆：评测集混入训练数据，分数虚高且无意义。检测方法：

1. n-gram 重叠：评测题与训练语料做 n-gram 匹配（GSM8K 题目原文出现在语料里）；
2. 记忆探测：给评测题的前半句，看模型能否逐字续写出后半句（能续写=背过）；
3. 时间切分：训练数据截止日期早于评测集发布日期，天然无泄漏（Holdout 越晚构建越可信）。

治理动作：去重时把评测集列为「黑名单重点排除」；构建私有的、永不公开的业务评测集（公版基准必然逐渐污染，私有集是长期资产）。

9.8.2 可信评估清单

一次可信的模型对比至少要交代：评测集版本与来源、prompt 格式与 few-shot 设置、答案抽取规则、解码参数（temperature=0 还是采样）、跑分次数与方差、是否有污染检查。任何「我们模型 XX 分」的宣称，缺了这些要素都应打折。

9.8.3 红队测试（Red Teaming）

在攻击者之前攻击自己的模型：专职红队用越狱、提示注入、多轮诱导、编码混淆（base64、拼音、emoji 变体）等手段探测漏洞，产出「攻击成功案例 → 对齐数据 → 修复回归」的闭环。红队与自动化对抗生成的区别：人类红队提供真正的创造性攻击，自动化提供规模，生产级安全要两条腿走路（第 23 章）。

---

本章要点回顾

1. 评估三铁律：没有单一指标、离线≠在线、评测集既是资产也是风险。
2. BLEU/ROUGE 对开放生成失效、PPL 不能跨模型比较——这是 LLM 评估转向裁判模型与在线评估的原因。
3. 能力基准（MMLU/GSM8K/HumanEval）已饱和，区分度转移到 GPQA/SWE-bench 等难题与中文本土基准。
4. 偏好评估三路线：MT-Bench（裁判打分）、Arena（真人投票，最可信）、AlpacaEval（胜率+长度控制）；裁判三大偏差：位置、长度、自恋。
5. RAG 评估分三层：检索（recall/MRR）、忠实（faithfulness）、答案（correctness），分层才能定位问题。
6. Agent 评估看轨迹与端到端，环境打桩与真实性的张力要用「关键路径打桩+抽样校验」折中。
7. A/B 与在线指标是最终裁判；污染检测（n-gram、记忆探测、时间切分）与私有评测集是可信评估的底线；红队是安全的最后一道质检。

习题

1. 你的模型 MMLU 涨了 3 分但用户满意度降了。列出至少 4 个可能的解释与验证方法。
2. 设计一个客服场景的私有评测集：维度、规模、构建方法、防污染策略、更新节奏。
3. 为什么 Chatbot Arena 比 MT-Bench 更抗刷分？它有什么自身的偏差？
4. RAG 系统端到端正确率 75%。设计一套分层评估方案，把 25% 的错误分解到检索层/忠实层/答案层，并给出每层的修复动作。
5. 用记忆探测法检验一个开源模型是否「背过」GSM8K：设计具体实验（提示模板、判定标准、统计方法）。

延伸阅读

• Hendrycks et al., Measuring Massive Multitask Language Understanding（MMLU）, 2021
• Cobbe et al., Training Verifiers to Solve Math Word Problems（GSM8K）, 2021
• Chen et al., Evaluating Large Language Models Trained on Code（HumanEval）, 2021
• Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, 2023
• Dubois et al., Length-Controlled AlpacaEval, 2024
• Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation, 2023
• Wei et al., Simple and Scalable Strategies to Continually Pre-train Large Language Models, 2023（含污染讨论）
• Perez et al., Red Teaming Language Models with Language Models, 2022

第 2 篇小结

第 2 篇「数据、训练与评估」走完了「把模型造出来」的全过程：

• 第 6 章数据工程：四类核心数据（预训练/指令/偏好/RAG），质量优先于数量，去重防记忆与污染，版本与血缘让问题可追溯。
• 第 7 章训练基础：交叉熵与 AdamW、Warmup-Stable-Decay 调度，训练谱系 PT→CPT→SFT→对齐，RLHF 三段式与 DPO 直通车，灾难性遗忘的对抗。
• 第 8 章高效训练：BF16 稳定性之源，梯度检查点与 ZeRO/FSDP 的显存分片，LoRA/QLoRA 把微调成本降两个量级，长上下文与编译加速。
• 第 9 章评估：能力基准已饱和、偏好评估三路线、RAG/Agent 分层评估、A/B 是最终裁判、污染与红队是底线。

到这里，「单机视角」的建模链路完整了。但真实的 LLM 训练与推理远不是一张卡的事——**第 3 篇「分布式训练与基础设施」**把视角拉到千卡集群：数据/张量/流水/专家并行的原理，Megatron 与 DeepSpeed 的框架格局，以及支撑它们的计算、存储、网络与调度体系。