基于《大规模语言模型：从理论到实践（第2版）》第11章 大语言模型评估
爆款小标题：模型好不好不能靠感觉：原书第11章评估体系与常用指标
为什么这一节重要
模型迭代与上线前必须回答「好不好、好多少、差在哪」。原书第 11 章建立了从语言建模能力到任务表现再到对齐与安全的多维度评估体系，并介绍了困惑度、准确率、BLEU/ROUGE、人类偏好与安全评估等常用指标。本节把这些维度与指标讲清，并强调「业务侧要有自有评估集」「自动指标与人工结合」，避免只看公开基准或凭感觉上线。
学习目标
- 了解原书给出的评估维度：能力维度（知识、推理、安全等）、任务类型与评估层级（单模型/对比/端到端）。
- 掌握困惑度、准确率、BLEU/ROUGE 等常见指标的含义与适用场景。
- 知道如何设计最小可用的评估集与评估流程。
一、评估体系（原书第 11 章）
原书第 11 章建立了多维度评估体系，可概括为：
能力维度：语言建模能力（如困惑度，反映模型对文本分布的拟合）、任务表现（分类、生成、推理、代码等任务的准确率或生成质量）、对齐与安全（人类偏好一致性、有害输出、越狱与红队测试等）。不同维度对应不同的评估数据与方法。
评估层级：单模型绝对表现（如在某基准上的得分）、多模型对比（如 A vs B 的胜率或偏好）、端到端系统表现（含 RAG、Agent 等组件的整体效果）。业务落地时，除参考 MMLU、HumanEval 等通用基准外，务必构造自有评估集——覆盖核心场景的「标准问 + 标准答（及可选的相关文档标注）」，每次改模型、prompt 或检索策略都跑一遍，避免与业务分布脱节。原书第 11 章对评估体系有完整展开。
二、常用指标详解（原书第 11 章）
困惑度（Perplexity）：反映模型对序列的拟合程度，主要用于预训练与语言建模评估；定义为交叉熵的指数，越低越好。困惑度不直接反映「生成是否有用、是否合人类偏好」，故生成任务中还需其他指标。困惑度对数据分布敏感，换数据集后需重新计算才有可比性。
任务准确率：分类、多选题、判断题等有标准答案的任务，用准确率、F1、 exact match 等。如 MMLU 用准确率、HumanEval 用 pass@k。pass@k 表示在 k 次采样中至少有一次正确的概率，常用于代码生成等「多解」任务。
生成质量：BLEU（n-gram 重叠，偏字面匹配）、ROUGE（召回率导向，常用于摘要）、BERTScore（基于语义相似度）等衡量生成与参考的匹配程度。需注意：自动指标与人工体验可能不完全一致（如 BLEU 高但回答啰嗦或偏题），建议结合人工抽检做最终判断。BERTScore 利用预训练模型的语义表示，对同义改写更友好，但计算成本高于 BLEU/ROUGE。
人类偏好与安全：通过人工或奖励模型对「同一 prompt 的多个输出」排序/打分，得到偏好一致性；安全维度可做红队测试（试图触发有害输出）、越狱测试等专项评估。原书第 11 章对上述指标的计算方式与典型基准有详细说明。人类偏好的标注需统一规范，避免不同标注员标准不一致导致噪声。
基准数据集：MMLU（多任务理解）、HumanEval（代码）、GSM8K（数学）等公开基准便于跨模型对比；但基准与业务分布可能不一致，业务落地时需在自有评估集上补充评估，避免「基准高、业务差」的脱节。
三、案例：评估脚本的最小实现
完整可运行代码（依赖：pip install nltk rouge-score；运行前 python -c "import nltk; nltk.download('punkt')"）：
import json, os
def sentence_bleu_simple(ref: str, hyp: str, lang="zh") -> float:
ref_t, hyp_t = (list(ref), list(hyp)) if lang == "zh" else (ref.split(), hyp.split())
if len(hyp_t) == 0: return 0.0
try:
from nltk.translate.bleu_score import sentence_bleu
return sentence_bleu([ref_t], hyp_t, weights=(0.25,0.25,0.25,0.25))
except: return 0.0
def rouge_scores(ref: str, hyp: str) -> dict:
try:
from rouge_score import rouge_scorer
out = rouge_scorer.RougeScorer(["rouge1","rougeL"], use_stemmer=False).score(ref, hyp)
return {"rouge1": out["rouge1"].fmeasure, "rougeL": out["rougeL"].fmeasure}
except: return {"rouge1": 0.0, "rougeL": 0.0}
def run_eval(eval_file=None):
data = json.load(open(eval_file)) if eval_file and os.path.exists(eval_file) else [
{"query":"退货政策？","expected":"7天内可无理由退货。","hypothesis":"根据政策，7天内可无理由退货。"},
{"query":"远程几天？","expected":"每周可远程2天。","hypothesis":"每周可远程办公2天。"}
]
results = [{"bleu": sentence_bleu_simple(i.get("expected",""), i.get("hypothesis", i.get("expected",""))), **rouge_scores(i.get("expected",""), i.get("hypothesis", i.get("expected","")))} for i in data]
avg = {"bleu": sum(r["bleu"] for r in results)/len(results), "rouge1": sum(r["rouge1"] for r in results)/len(results), "rougeL": sum(r["rougeL"] for r in results)/len(results)}
print(f"BLEU: {avg['bleu']:.4f}, ROUGE-1: {avg['rouge1']:.4f}, ROUGE-L: {avg['rougeL']:.4f}")
return avg
if __name__ == "__main__":
run_eval()
中文 BLEU 按字分，英文按词分。
四、工程实战要点
1. 自有评估集的构建与维护
业务侧至少保留「核心场景 + 标准问+标准答」的回归集，每次改模型或 prompt 都跑一遍。评估集应覆盖：高频场景、边界 case、负例（应拒绝或说不知道的）、以及多轮对话等。随着业务演进，需定期补充新场景、淘汰过时样本，避免评估集与线上分布脱节。
2. 自动指标与人工结合
自动指标与人工抽检结合，避免自动指标与真实体验脱节。建议流程：每次迭代跑自动指标（如 BLEU、准确率），对变化较大的版本做人工抽检（如 20–50 条），从「相关性、完整性、是否有幻觉、格式是否正确」等维度打分；上线前做小规模 A/B 测试，收集真实用户反馈。
3. 评估流程的自动化
将评估脚本纳入 CI/CD 或迭代流程，每次提交或发版前自动跑评估集并记录结果；可做趋势图（如每次迭代的得分曲线），便于发现 regressions。评估结果应与模型版本、prompt 版本、数据版本一起记录，便于回溯与复现。
五、常见误区 & 避坑指南
- 误区：只看公开基准排名。避坑：基准与业务分布可能不一致，需在自有数据上评估。
- 误区：评估集长期不更新。避坑：业务与攻击方式变化后，评估集要补充与轮换。
六、小结与衔接
本节基于原书第 11 章梳理了评估体系（语言建模—任务—对齐与安全）、常用指标（困惑度、准确率、BLEU/ROUGE、人类偏好与安全）以及业务侧自有评估集与人工结合的重要性。下一节为多模态大语言模型简介（6.3），再下一节为推理服务与生产部署（6.4）。
课后思考题
- 困惑度主要反映模型的哪类能力？为什么生成任务中还会额外看 BLEU/ROUGE？
- 若你要为「客服话术生成」设计评估方案，你会包含哪些维度、用哪些指标（至少各列 2 个）？
