如果你已经花了几个月时间折腾数据集清洗、LoRA 微调、分布式训练，结果模型一上线，连你自己都说不清它到底比 base 强在哪，那我建议你停下来，认真读一读这篇。LLM 训练做到后期，真正拉开差距的往往不是训练脚本写得多花哨，而是评测体系稳不稳。这一节 Lab 15，咱们不讲炼丹，专门把“怎样评测模型好坏”这件事拆开聊透：基准怎么选，数据污染怎么防，以及怎么让评测流程做到可复现、可追溯、经得起别人质疑。
我先说一个可能不太好听的事实：国内很多团队的评测，其实是“表演型评测”。找一个榜单，跑几个熟人指标，挑最好看的结果写进汇报里，剩下的日志删掉。这种玩法在模型规模小、内部试用的时候没有问题，可一旦你要把模型推向真实业务、或者开源出去，评测不严谨带来的反噬会非常快——别人复现不出你的分数，数据污染被扒出来，甚至只是评测集和微调集来自同一个源头，都足以让整个模型的可信度归零。所以，评测不是训练结束后的收尾动作，它应该是和训练并行设计的一等公民。
1. 为什么说评测是 LLM 训练中“最容易被低估”的环节
1.1 评测决定你下一步改哪里
先说最实际的一点：评测的直接产出不是分数，而是下一步的动作方向。比如你在做指令微调，训练完发现 MMLU 涨了 2 个点，但 GSM8K 掉了 4 个点，这说明什么？说明 SFT 数据里数学推理类样本比例不对，或者 LoRA 的 rank 设置让模型在推理任务上发生了灾难性遗忘。如果你只跑一个综合榜单，看一个总分，这 2 和 -4 就被平均成 -1 了，你会得出“模型差不多没变”的错误结论，错过修正数据配比的机会。
我自己习惯把评测当成一次“系统体检”，不是抽血化验一个指标就完事，而是分系统查：知识储备查 MMLU、C-Eval；推理能力查 GSM8K、MATH、BBH；代码能力查 HumanEval、MBPP；长文本理解查 LongBench；指令跟随和真实性另建一组内部集。每个方向独立出报告，改哪里一目了然。
1.2 评测不严谨的代价是链式放大的
评测体系不严谨，坑的不止是当前版本。你的 checkpoint 选择、LoRA 超参、数据配比，全部依赖评测分数做决策。如果评测集本身有偏差、评测脚本有 bug、或者温度参数没有固定，你选出来的“最优 checkpoint”可能只是一个噪声尖峰。
更麻烦的是，这个不严谨的分数会被写进实验记录、项目周报、开源模型卡（Model Card）。等模型部署到线上，用户反馈和你的评测结果对不上，你再回头排查才发现是评测时 prompt 模板写错了——这种问题在真实项目里一点也不少见。所以我的原则是：评测脚本的代码审查严格程度，至少和训练脚本一样高。
2. 基准怎么选：理解每一个分数的“适用半径”
2.1 主流基准各自在测什么
很多人对基准的认知停留在“MMLU 测知识，GSM8K 测数学”，这话对，但太粗了。我按实际使用经验把常用的公开基准重新梳理一遍：
MMLU / MMLU-Pro：57 个学科的多选题，覆盖人文、社科、理工等。它测的是“知识广度和基础理解”，但注意它是 4 选 1，存在约 25% 的猜测保底分数。MMLU-Pro 提高了选项数量和干扰项难度，能更好拉开模型差距，缺点是题目更少、更不稳定。
C-Eval / CMMLU：中文综合基准。C-Eval 包含 13948 道题，覆盖 52 个学科，是目前中文评测绕不开的基准。但它的 few-shot 设置敏感度很高，我实测下来 0-shot 和 5-shot 的分数能差出 10 个点以上，评测时必须在报告里写明 shot 数。
GSM8K / MATH：数学应用题与竞赛题。GSM8K 侧重多步算术推理，MATH 难度高一个档次。这两个基准对 CoT 提示非常敏感，评测时用 chain-of-thought 还是直接答案，结果天差地别。
HumanEval / MBPP：代码生成。HumanEval 是 164 道函数补全题，用 pass@k 评估。这里有个经典坑：pass@k 是估算指标，官方脚本用了截断正态概率估计，并不是简单地在 k 个样本里有多少通过。很多人直接算 pass@1，忽略了采样温度对通过率的影响。
BBH（BIG-Bench Hard）：从 BIG-Bench 里挑的 23 个困难任务，测的是组合推理、逻辑、多步处理。它比 MMLU 更能区分顶级模型的推理能力，但同样对 few-shot 模板敏感。
LongBench：长文本理解基准，包含单双文档问答、摘要、代码补全等 14 个任务。如果你的模型改了 RoPE 基频、扩了上下文窗口，必须跑这个，它测的是真实的长文本利用能力，不是“能读多长”，而是“长了之后还能不能答对”。
2.2 一个基准组合的默认配方
我开源过自己的内部评测配方，给中小团队做参考，不需要对所有公开基准都跑一遍，优先跑一套“组合拳”：
通用知识：MMLU（5-shot），MMLU-Pro（5-shot），C-Eval（5-shot，中文） 推理：GSM8K（8-shot CoT），MATH（4-shot CoT），BBH（3-shot） 代码：HumanEval（pass@1，temperature=0.2），MBPP（pass@1） 长文本：LongBench（0-shot，按它官方设置） 指令跟随：内部 200 条集合（后面讲怎么建） 中文场景：CMMLU（5-shot）+ 自己业务场景的评测集
这套组合跑一轮大约耗时 2~6 小时（看模型和 GPU），信息量已经足够支撑绝大多数训练决策。千万别贪多，评测集跑太多，时间成本会严重挤占真正该用的“人工审查案例”环节。
2.3 少样本设置、提示模板这些“看似琐碎”的参数，必须写进评测报告
为什么同一个模型，同一个公开基准，不同人跑出来的分数不一样？除了随机种子，最大的变量是评测时的 prompt 模板。比如 GSM8K，有人直接给题目让模型答，有人用官方的 CoT few-shot 模板，还有人用自己写的“让我们一步步思考”模板——三者分数能差 5~8 个点。这不算作弊，但说明评测分数无法脱离设置而存在。
所以我在评测报告里强制固定这几项：基准名称、数据版本、shot 数、是否有 CoT 提示、温度、top_p、最大生成长度、并发数（因为并发会影响显存分配导致的推理波动）。没有这些信息的分数一律视为无效。
3. 数据污染：你以为在测知识，其实在测“记忆”
3.1 数据污染的两种面孔
数据污染这个问题，在 2023 年之前大家重视程度还不够，直到很多模型的训练数据里被扒出包含测试集内容，整个行业的评测可信度才被摆上台面。污染分两种，一种是无意的：你爬的网页语料里，本身就包含了 MMLU 的题目和答案；另一种是刻意的：为了让分数好看，把测试集放进训练集或者 SFT 数据里。后者已经不是技术问题，而是学术道德问题，我不展开，但前者的普遍性远超大多数人的想象。
我举个例子。你在爬 GitHub 上代码仓库的时候，很可能顺手把含有 HumanEval 题目的测试文件也爬进去了。就算原仓库只是“讨论”或“备份”这个文件，模型在预训练阶段见过这些内容，评测时就会通过记忆路径做对题，而不是通过真正的代码推理。最终结果是分数虚高，上线后一遇到真实代码任务立刻原形毕露。
3.2 怎么检测数据污染：四个实用手段
如果你怀疑自己的预训练语料或 SFT 数据可能和评测集有重叠，我常用的检测手段有四种，按成本从低到高排序：
N-gram 重叠扫描：把评测集的每道题切成 8-gram / 13-gram 的 token 序列，去训练语料里做近似匹配。如果题目有连续的 13 个 token 能在训练集里找到完全一致的片段，基本可以判定存在重叠。这个方法成本低，适合前置筛查。
困惑度（Perplexity）测试：把评测集题目输入模型，如果模型对测试集文本的困惑度显著低于它对普通同领域文本的困惑度，说明测试文本很可能出现在训练阶段。这个方法不需要训练语料，操作最方便，但只能定性。
记忆探测：直接让模型续写某道题的开头，看它能不能“背”出后续内容。如果它生成的文本和标准答案高度一致，说明存在记忆。这个适合抽查，不能全量做。
时间线切割：如果你的训练语料按时间做了归档，可以按时间切训练集和测试集。比如 2023 年 6 月之后的文本不进预训练，评测时用这个时间之后的题目。这是最可靠的手段，但对数据管线要求很高。
3.3 给开源模型做评测前，先做“防污染筛查”
这里有个特别容易被忽略的场景：你现在评测的模型大多是从开源 base 模型继续训练的，base 模型本身可能已经被污染了。换句话说，即便你完全没有把测试集放进自己的 SFT 数据，你的 base 在预训练阶段可能早就见过 MMLU 题目了。所以你评估“你的微调增量”时，必须同时跑一遍 base 模型的分数，然后看差值和相对变化，而不是只报绝对值。
3.4 定期刷新测试集：动态评测是未来
静态基准的生命周期会越来越短，因为互联网文本里关于这些基准的讨论文章、题解、博客会不断增长，今天干净的数据，明年可能就脏了。我的做法是保留一套内部“动态基准”：
- 每季度人工编写 200~300 道新题目，涉及业务关键能力
- 题目用加密存储，不进任何训练流程，连参与编写的人都签保密协议
- 评测脚本支持只更新题目、不更新代码，分数与历史结果做对齐校准
当然这个成本不低，但如果你做的是垂直行业模型（法律、医疗、金融），动态基准几乎是必需品，因为你不能指望通用公开基准能测出你的业务正确性。
4. 可复现评测流程：从我到我们，从结果到证据
4.1 一套标准的评测工作流长什么样
可复现不是说“我记录了命令，下次能跑出来”，而是“另一个人拿着你的说明，能复现出完全一致的数字”。我给自己项目定的标准评测流程是这样：
准备阶段：校验评测集版本（用哈希值固定），冻结模型 checkpoint（保存 tokenizer 配置、模型配置、权重文件的哈希），固定评测配置（脚本版本、依赖版本、GPU 型号），然后写一个评测清单文本。
执行阶段：用统一的评测入口跑任务，日志输出每道题的结果而不是只输出汇总分数。每个任务记录开始时间、结束时间、耗时、显存峰值、异常日志。
归档阶段：汇总数据生成报告，包含：提交哈希、评测日期、硬件环境、每个基准的配置、逐题结果文件（JSONL）、汇总表格、异常说明。上传到内部实验管理系统，关联到对应的训练实验。
4.2 评测脚本和训练的耦合：一个常见的“假复现”陷阱
很多团队说“我的评测可以复现”，但评测脚本的依赖库是 pip install 的时候顺带装的，比如 transformers 和 vllm 的版本在三个月后早就变了，那时候再跑，采样结果会对不上，甚至 inference API 都变了。我踩过这个坑，后来强制要求：
- 用固定镜像或 requirements-lock.txt，锁定 transformers、tokenizers、datasets、peft、vllm、lm-eval 等关键包的精确版本
- 把评测执行代码 Docker 化，镜像标签写入评测报告
- 凡是涉及“评测结果对比”的实验，尽量在同一批硬件、同一镜像下跑完，跨硬件跑要单独做对齐验证
4.3 采样参数“差一点”，结果差很多
可复现评测还有一个很脏的坑：生成时的随机性。llm 的推理采样默认有随机性，即使你设置了 temperature，重复跑两次也会因为不同的随机种子得到不同的生成结果。所以评测任务必须固定 seed，并且最好设置成开 deterministic（如 vllm 的--seed参数）。我习惯每个任务固定 seed=42，并且把 seed 写在报告里。
另外注意：有些推理框架为了保证并发效率，默认会动态 batching，batch 内样本顺序变化会导致部分归一化算子产生细微差异，从而影响结果。所以真正严格的可复现评测，我用单卡串行或者固定 batch 的组合，牺牲一点速度换确定性。
4.4 评测结果三级存档，而不是只留一个数字
我参与过几次模型评测体系的内部审计，发现大多数团队对评测结果的管理都极为松散。最常见的形态是：一张 Excel 表，几列分数，连日期都没有。这样做的后果是，三个月后你想分析“为什么这个 checkpoint 好”，你拿不到当时用了哪个版本的测试集和 prompt，只能重新跑一次，然后发现分数和当时对不上，又怀疑是不是模型文件有问题——全套流程都在内耗。
所以我建议至少做三级存档：
- 原始运行产物：每道题的输入输出 JSONL、运行日志
- 处理后的汇总数据：按基准、按 seed 汇总的 score 表
- 人类可读报告：对比图、结论、决策说明
三级数据分别存储，权限分离。只有汇总表可以被修改，原始产物只读。这样即使有人想“调整”结论，也能追溯到底层。
5. 搭建一套低成本、可复现的评测环境
5.1 直接选择一个成熟的评测框架，别自己造轮子
实测下来最稳的是以下三个，各有侧重：
lm-evaluation-harness（EleutherAI）：最普及，支持几百个公开基准，自定义任务也方便。它的 YAML 配置方式值得学习，能把 prompt 模板、few-shot 设置、评测指标都固定在一个文件里。这也是我做所有公开评测的基础。
OpenCompass（上海人工智能实验室）：中文和 Code 评测支持更好，集成了评测结果的可视化、模型对比，适合做中英双语模型的横向评测。
HELM（斯坦福）：重在“多维度、多场景”，强调评测标准化和覆盖度，更适合做研究型全量评测，工程上使用成本略高。
如果你没有特殊需求，我直接推荐 lm-eval-harness + 自己的评测集管理仓库。它的学习曲线平缓，环境隔离干净，社区更新也快。
5.2 用 YAML 固化评测任务，做到“配置即文档”
lm-eval-harness 的 YAML 任务配置非常能打，我把它视为评测复现的核心。一个任务配置里，你固定了：数据集名称、数据集路径、prompt 模板、shot 数、评测指标、tokenizer 相关设置。
举一个最小的 GSM8K 配置示例：
task: gsm8k dataset_path: gsm8k dataset_name: main output_type: generate_until test_split: test fewshot_split: train num_fewshot: 8 doc_to_text: "Question: {{question}}\nLet's think step by step.\n" doc_to_target: "{{answer}}" generation_kwargs: do_sample: false temperature: 0 max_gen_toks: 1024 metric_list: - metric: exact_match这段配置表达的信息量，比你写 2000 字评测说明文档都要高。因为它不只是“文档”，它是直接被执行的文件。我要求团队所有评测任务的 prompt 修改必须走 MR 评审，合入后自动触发一轮全量回归，确保改 prompt 的副作用是被记录的。
5.3 评测集管理：版本、权限、血缘
评测集本身也是需要治管的。我最开始的做法简单粗暴——就是一个目录，里面放几个 JSON 文件，带日期命名。直到有一次我发现自己同时存在两个版本的“内部指令测试集”，一个叫instruction_v2_final.json，另一个叫instruction_v2_final_final2.json，就知道必须换了。
目前的做法是用一个独立的 Git 仓库管理评测集，每次更新走版本 tag，并使用哈希校验。任何评测报告必须记录评测集仓库的 commit 号和文件哈希。如果你不想用 Git 这么麻烦，至少做到：评测集目录只读部署，对外提供一个带文件哈希的清单文件。
5.4 预算不够时，先用“黄金集 + 抽查”策略
并不是所有团队都有资源跑全量基准。如果你卡在算力不足，我有一个折中策略：构建一个 500 条以内的小型“黄金集”，覆盖你业务最关心的 8~10 个能力维度，每条题目都是精心挑选或人工编写的。
黄金集跑一轮只要几分钟，适合做迭代中快速反馈；全量公开基准每周或每个里程碑跑一轮，作为对外宣发和模型存档依据。评测不是越全越好，而是越稳越好——稳定、可解释、低成本，才能持续跑下去。
6. 我以为我稳了，结果评测翻车的三个真实案例
6.1 案例一：并发一开，分数悄悄变了
有一次我开开心心地用 vllm 的并发跑 LongBench，对比上一周的分数，发现长了 3 个点。一开始以为是新 checkpoint 更强，后来为了确认又关了并发跑了一遍，结果掉回原位。原因就是动态 batching 改变了某些样本的 normalize 结果。从那以后我学到一条规矩：对比实验结果必须用完全相同的推理设置，并发模式也算设置之一。
6.2 案例二：SFT 数据里藏了测试集题目
这个案例尤其值得警惕。一次我在做领域模型的指令微调，用了一批从行业论坛爬来的帖子。后来评测时发现模型在内部金融问答测试集上得分异常高，高到不像一个 7B 模型能做到的。排查后发现：爬取的网页里恰好包含了某平台发布的“金融大模型测试题”讨论帖，题目和答案都在里面。这不算恶意，但结果已经失真。最后我把这批数据全部重新清洗过滤，才得到正常分数。
这件事给我的教训是：SFT 数据的清洗流程里，必须加一道“测试集题目过滤”的检查，绝不能假设外部数据源是干净的。
6.3 案例三：小模型跑出了不可能的高分
还有一次，我在评测一个 LoRA 微调后的 7B 小模型，它的 MMLU 分数比同量级模型高出一大截。第一反应是开心，第二反应是怀疑。逐题检查后才真相大白：评测脚本用的 model 配置里，误加载了未经冻结的 base 模型权重，导致实际推理的并不是我微调后的 checkpoint，而是一个混血的权重状态。分数当然不对。这个 case 让我强制要求：评测前先跑一遍“权重哈希校验”，确认加载的权重文件 MD5 和训练产物记录一致。
后面我还在评测脚本里加了“防呆断言”逻辑：如果模型参数量和我期望的不一致、如果 tokenizer vocab 数量和配置不一致，直接报错中止，不产出分数。宁可跑不出来，也不能让错误的分数流转到下游。
7. 把评测报告写成人话
最后这点很多人容易忽略，但也是评测价值的最终落点。写评测报告，尤其写给你团队里不搞训练的人看的时候，别一上来就贴 MMLU 的雷达图，你要先回答三个问题：
- 这个模型比我上一版强在哪？
- 它做不好什么，暴露了什么短板？
- 这次的评测结论，下一轮训练该怎么改？
我见过写得很好的评测报告，开头就一句话：“v2.3 模型在数学推理上比 v1.9 提升了 5.1%，但代码生成的可运行率下降了，推测是 SFT 数据中代码与 CoT 的比例失衡，下一步准备调整数据配比。”这句话比十个表格更有决策价值。
我现在写评测报告的标准模板是三段式：先说关键结论（一句话），再到证据（数据和图表），最后给出下一步动作（含明确的测试假设）。整个过程不允许出现“感觉变好了”“好像差不多”这类词。
评测这件事，做到后面拼的不是上不上 80 分，而是能不能每一次都清楚地回答“为什么是这个分数”。你只要把基准的选择逻辑、污染防护流程、可复现环境搭建这三件事做扎实，你训练出来的模型就经得起别人的推敲，也经得起自己三个月后回头看。这套环境下一次再训新模型的时候，你真会发现，评测报告从“交差用的”变成了“真正帮你做决策的那个东西”。
