做AI这行的，不管你是搞训练的还是做应用的，几乎都逃不过一个问题：有人拿个模型过来问“它到底行不行”。你要说“感觉还行”，对方肯定不满意。但你要是能甩出一串分数，比如MMLU多少、GSM8K多少、HumanEval多少，对方立马就有体感了。这串分数从哪来？就是Benchmark，基准测试。

我这份AI学习笔记已经整理到第67篇，这篇专门把大模型评测这块摊开讲清楚。内容包括：Benchmark到底在测什么、主流的评测集各有什么脾气、为什么同一个模型在不同榜单上分数能差出一大截，以及我自己跑评测时踩过的坑和最终沉淀下来的操作流程。适合刚入门的同学建立评测知识框架，也适合已经在跑模型但被各种榜单指标绕晕的开发者，看完至少能搞清楚那些眼花缭乱的分数背后到底代表了什么能力。

1. 基准测试到底在测什么

1.1 没有统一标尺，就没法谈性能对比

先说个生活化的类比。你买手机的时候，会看跑分、看续航测试、看拍照样张，因为这些指标把“好不好用”这个模糊问题拆成了可量化的维度。大模型也是一个道理，模型能力太抽象，你说“这个模型聪明”，什么叫聪明？能写诗算聪明，能解数学题算聪明，能写代码也算聪明。如果没有一套统一的考试题，每个团队都说自己的模型好，那行业就乱套了。

Benchmark就是这套统一的考试题。它把“模型能力”拆成多个维度：知识储备、推理能力、数学能力、代码能力、指令遵循、安全性、多模态理解等等，然后用固定的题目和固定的评分规则给模型打分。这样一来，无论你用的是哪个模型，只要在同一套题上跑，分数就可以互相比较。

这里有个关键概念要区分：数据集和基准。很多人把这两个混着用，实际上“数据集”是题本身，“基准”是“题目+评测方法+评分规则”的完整协议。比如有了一道数学题，你怎么问模型？是直接给题让模型答，还是加一句“请逐步思考”？答案格式有什么要求？评分是看最终结果还是看过程？这些都属于评测协议的一部分。同一个模型，用不同协议去测同一个数据集，分数都可能不一样，这一点在后面踩坑部分会详细讲。

1.2 评测协议里的基本术语，先统一一下

聊基准测试绕不开几个术语，这里集中解释，后面才不会懵：

• Zero-shot（零样本）：不给模型任何示例，直接提问。比如直接问“1+1等于几”。这测的是模型对指令的泛化理解能力。
• Few-shot（少样本）：在提问前给模型一些示例，比如给两道做过的题和答案，再让模型做新题。少样本能帮助模型理解任务格式，通常分数会比零样本高。
• CoT（Chain-of-Thought，思维链）：要求模型把推理过程一步步写出来再给答案。对数学、逻辑类题目有明显帮助，但也会让生成变长，评测耗时上升。
• Pass@1：模型第一次生成的结果就算对错，测的是“一次答对”的能力。
• Pass@k：允许模型生成k次答案，只要其中一次对了就算通过。这个指标主要用在代码生成评测里，因为真实写代码本来就是多轮尝试的过程。

这些术语之所以重要，是因为你看到一张榜单的时候，如果它没写清楚评测协议，分数就失去了参照意义。两个模型都用5-shot CoT测GSM8K，分数才有可比性；一个是0-shot、一个是5-shot，分数直接对比就是在耍流氓。

2. 主流基准全景拆解：你的模型适合测哪套

市面上公开的大模型评测集几十个，我按考察能力把它们分成了六大类。每个类别挑最常用的来拆解，看完你就知道该拿哪套题去测你的模型。

2.1 综合知识类：MMLU与中文场景的C-Eval

MMLU（Massive Multitask Language Understanding）是目前最出圈的综合知识评测，覆盖57个学科，从数学、物理、历史到法律、伦理，总共约1.4万道四选一选择题。它的设计思路很直接：像高考一样，从各个学科抽题考模型，看谁的知识面更广。评测时通常用5-shot，也就是每个学科先给几个示例再正式测。

MMLU的好处是覆盖面广、题目稳定、跨模型可比性强，所以几乎所有大模型发布时都会带一笔MMLU分数。坏处也很明显：它测的主要是知识记忆和基础理解，对复杂推理能力的区分度不够。一个模型如果训练数据量大，见过很多类似题目，MMLU分数就能刷得很高。所以现在很多榜单不只报MMLU，还会搭配推理类评测。

C-Eval是中文场景下最有影响力的综合评测集，包含52个学科、约1.4万道四选一题，覆盖人文、社科、理工、其他四个方向，还分了初中到研究生的难度层级。它的题目全部是中文，评分也考虑了中文模型的特点，对评估中文大模型很合适。国内团队做模型基本都会报C-Eval分数。

2.2 推理与数学：GSM8K与MATH

GSM8K是小学数学应用题集，约1300多道题，主打“多步推理”。比如“小明有5个苹果，妈妈又给了他3个，他吃掉了2个，请问还剩几个”这种级别，但实际题目比这个复杂一些，需要模型分步计算。这套题的魅力在于：题目答案唯一，评分客观，而且对模型的真实推理能力比较敏感。一个模型如果只会背知识但不会推理，在GSM8K上分数会很难看。

评测GSM8K时，CoT的影响特别明显。让模型直接给答案，和让模型“先写解题过程再给答案”，分数能差出20个百分点。这个现象也催生了很多专门针对推理优化的训练方法。

MATH是竞赛级数学题集，约5000道题，覆盖代数、几何、概率、数论等七个方向。难度远超GSM8K，很多题目对专业选手都有挑战性。MATH满分是5分，每个题按步给分，评测比较复杂。能在MATH上拿高分的模型，推理能力基本是行业第一梯队。

2.3 代码能力：HumanEval与MBPP

HumanEval是OpenAI发布的代码生成评测集，包含164个编程问题。每个问题给出一段函数签名、文档字符串和几个示例，要求模型补全函数体。它的评分标准是Pass@k，模型生成的代码要能通过预置的单元测试才算正确。164个题量看着不大，但覆盖了循环、递归、字符串处理、位运算等常见编程场景，区分度很好。

MBPP是另一个常用的代码评测集，包含约974个基础编程题，难度比HumanEval低一些，更贴近日常编程任务。它的题目会直接描述“编写一个函数，实现某某功能”，模型需要根据描述生成完整代码。

代码评测有个坑要注意：HumanEval这种补全式题目对模型输出格式极其敏感。模型如果多写了一个解释性的句子，哪怕代码本身是对的，也可能因为无法通过严格解析而被判错。所以跑代码评测时，通常会用专门的解析器提取代码片段，或者要求模型严格只输出代码。这也是为什么同一模型在不同代码榜单上的分数经常对不齐——解析规则不一样。

2.4 多模态与长文本：MMMU、MMBench、LongBench

MMMU是面向多模态大模型的评测集，包含约3万道大学级别题目，覆盖艺术、工程、商业、科学、医学等六个学科。每道题都配有图片，模型需要同时理解图像内容和文本问题才能作答。这类评测考察的是视觉理解和跨模态推理能力，对多模态模型的区分度很好。

MMBench是中文团队推出的多模态评测集，包含约3000道题，用了一套更精细的能力标签体系，把“识别”“定位”“推理”“OCR”等维度拆开打分，能更细致地反映模型在哪些多模态能力上有短板。

LongBench是专门测长文本理解的评测集，包含21个数据集，覆盖单文档问答、多文档问答、摘要、代码补全、数学推理等场景，上下文长度从几千字到几万字不等。长文本评测有个典型现象：模型在短文本上表现很好，但上下文一长性能就断崖下跌。LongBench的设计就是为了暴露这个问题。

2.5 安全、对齐与指令遵循：TruthfulQA、AlignBench、IFBench

这一类比前面几类更特殊，因为它测的不是“模型会不会”，而是“模型愿不愿意好好答”。模型知识再丰富，如果用户一问就编造事实、输出危险内容，或者不按用户指令执行，那在生产环境里就是灾难。

TruthfulQA是一套判断题集，专门测模型是否会给出事实错误或“看起来正确但实际是编造”的答案。它选了很多人们容易误解的常识性问题，比如“地球是平的这种说法对吗”，模型如果直接顺着错误观点回答就会被判错。

AlignBench是中文场景的对齐评测，从真实性、安全性、有用性等多个维度打分，题目类型包括聊天、写作、翻译、数据分析等，对中文对话模型的对齐效果有很好的衡量。

IFBench专门测指令遵循能力，比如“在回答开头加一个感叹词”“把第三句话翻译成英文”这类细颗粒指令。很多模型在复杂指令组合下会漏掉某一条，这类评测就是揪这些小毛病。

2.6 通向AGI的评测：AGIEval等

AGIEval是一套用人类标准化考试题来测模型的评测集，包括高考、司法考试、公务员考试等真实考题。设计理念很直接：既然这些考试人类能用，那模型如果真具备通用智能，也应该能应对。这套评测对模型的综合能力要求极高，分数普遍偏低，更像是一个“理想化”的上限测试。

还有个经常被一起提到的ARC（AI2 Reasoning Challenge），它分Challenge集和Easy集，测的是科学推理能力，题目基于小学到高中的科学知识，但需要多步推理和常识判断。

3. 比分数更容易踩的坑：榜单正确打开方式

3.1 数据污染比想象中严重

数据污染是基准测试最大的灰色地带。简单说，就是评测题的答案或者题目本身，可能已经混进了模型的训练数据。模型不是“会做”这道题，而是“见过”这道题，直接背出了答案。

怎么判断一个模型是不是被污染了？有个典型迹象：在某些公开评测集上分数特别高，但换一批从未公开过的新题，分数明显下滑。业内有人专门做过实验，用新出的、网上没有答案的题去测一些高分的商业模型，结果比公开榜单上的分数低很多。这说明那些模型很可能在训练时“见过”公开题。

我自己测试模型时有个习惯：不只看公开榜单，会自己留一小部分数据做Hold-out验证，或者找一些刚发布、还没大范围传播的新数据集去测。如果模型在新数据上的表现和公开榜单差距过大，那它的真实能力至少要打个问号。

3.2 prompt写法能“改写”成绩

很多人没意识到，评测时prompt的写法本身就是影响分数的变量。同一道题，你直接问“答案是什么”和引导式地问“请逐步推理后给出答案”，模型给出的结果可能完全不一样。再比如Few-shot示例的选择——你从题库里挑三个容易的示例当引导，分数能比挑三个难的示例高好几个点。

更隐蔽的是温度参数。很多人在评测时把温度设成默认值或者0.7，但评测追求的是确定性，温度应该设为0或者非常低。温度一高，模型每次生成的答案都在变，同一道题可能这次答对下次答错，分数自然不稳定。

所以我一直强调一个原则：跑评测要用固定的脚本、固定的参数、固定的prompt模板，不要手工改来改去。手工改一次，结果就不具备可比性了。这也是为什么业内的开源评测框架都要加锁——参数的微小变动会直接影响结果。

3.3 看待榜单的三条实操原则

基于上面这些坑，我总结出三条看榜单的原则：

第一，同协议才有可比性。比较两个模型时，先确认它们是否用了同样的评测版本、同样的few-shot设置、同样的CoT设置、同样的解码参数。协议不一致的分数对比没有意义。

第二，细分维度比总分重要。很多榜单会把几十个数据集汇总成一个总分，但这会掩盖短板。一个模型总分高，可能是靠代码分拉上来的，它在医疗领域的表现可能完全不能看。选模型要回到你的实际场景，看对应细分维度的分数。

第三，公开榜单是参考，不是结论。真正决定模型能不能用的，是它在你自己业务数据上的表现。我见过一个模型在公开榜单上分数一般，但在一家企业的特定业务场景里跑得比高分模型还好，因为业务数据的分布恰好是那个模型的强项。评测是筛选工具，不是终点。

4. 亲自跑一次基准测试的完整记录

讲完理论，下面记录一次我自己跑综合评测的完整流程，直接照着做就能复现。

4.1 环境准备与数据获取

跑基准测试的第一步是准备环境。基础硬件方面，跑7B级别的小模型，一张24G显存的显卡就够了；跑70B级别的大模型，需要多卡或者量化方案。我自己常用的配置是单卡跑量化后的13B模型，速度能接受，结果和全精度差距很小。

数据集获取方面，主流的评测集都能在开源社区下载。这里有个经验：下载数据集时要锁定版本，不要下载最新主分支，因为数据集可能有更新，版本一变分数就变了。我一般会在项目里记录数据集的具体版本号，方便事后复现。

评测框架方面，建议直接用现成的开源评测工具库，不要自己造轮子。成熟的评测框架对数据格式、prompt模板、评分逻辑都有统一处理，能避免很多低级错误。在开源社区搜索“大模型评测框架”就能找到主流方案。

4.2 跑通一个综合评测的完整流程

我用一个假设的demo-chat模型在MMLU子集上做演示。先写一份最简单的评测配置：

# 下载评测数据和模型权重后，执行评测命令 python run_eval.py \ --model demo-chat \ --task mmlu \ --fewshot 5 \ --max_len 2048 \ --batch_size 4 \ --temperature 0

这个命令的含义拆开讲：

• --model demo-chat指定要测的模型，实际的模型路径可以指向本地权重目录。
• --task mmlu指定评测集，框架会自动加载对应的数据集和prompt模板。
• --fewshot 5表示用5-shot模式，也就是每个学科前给5个示例。这是MMLU的标准设置。
• --max_len 2048限制生成的最大长度。MMLU是选择题，答案通常很短，2048足够。
• --batch_size 4是批量大小，取决于显存。显存不够就调小到2或者1。
• --temperature 0把采样温度设为0，保证评测结果的确定性。这一步很关键。

跑的时候注意观察日志，框架会逐学科打印准确率，最后汇总一个平均分。MMLU总共57个学科，全量跑下来，13B模型在主流显卡上大概需要一到两个小时。

几个常见报错和处理方式：

• 显存不足（OOM）：优先调小batch_size，从4改到2或者1。还不行就上4bit量化，显存占用能降一半。
• 数据集格式报错：有些框架要求数据集有特定的json格式，下载后需要检查字段名是否匹配。常见的字段是question、choices、answer。
• 生成乱码或全空格：通常是tokenizer版本和模型不匹配导致的，重新检查模型加载路径，或者更新tokenizer配置。

4.3 结果怎么解读，以及为什么不能只看平均分

评测跑完后，框架会输出类似这样的结果：

| 学科 | 准确率 | |---------------|--------| | abstract_algebra | 0.28 | | anatomy | 0.45 | | ... | ... | | average | 0.42 |

看到这个结果，第一步不是看平均分，而是看分学科的分布。平均分0.42看起来不高，但如果你是做医疗应用的，anatomy（解剖学）单科0.45才是你最关心的；如果你是做数学应用的，abstract_algebra（抽象代数）0.28就说明模型数学能力不足，得换方案。

另外要注意给每个学科看样本量。MMLU里有些学科只有几十道题，一两道题的对错就能让分数波动好几个百分点，这种学科分数的置信度不高，参考价值有限。

4.4 进阶：如何自建mini评测集做快速回归

完整跑一遍MMLU要一两个小时，日常开发中不可能每次都跑全量。我自己习惯的做法是：从各个评测集里抽取一小部分题，建一个mini评测集，大概200道题，覆盖综合、推理、代码、中文几个核心维度，几分钟就能跑完。

这样做有两个好处：一是开发过程中可以快速验证模型改动有没有坏影响，相当于给模型做“冒烟测试”；二是可以在项目里固化成回归流程，每次模型更新后跑一遍，分数波动超过阈值就报警，及时发现问题。

等模型稳定了，再去跑全量评测，发布正式的分数报告。这是实验室里验证功能、发布前跑全量的完整闭环。

5. 最后的实操心得

基准测试这件事，我用一句话总结：它是模型的体检报告，不是成绩单。体检报告的意义在于告诉你身体哪个系统可能有隐患，而不是给你贴一个“优等生”的标签。选模型、调模型，真正要关注的是那些和你业务强相关的细分指标，而不是那个被反复传播的平均分。

我实际测试过很多模型，也踩过不少坑。最大的体会是：评测结果的可复现性，往往比分数本身更重要。一个你无法复现的分数，再高也没有意义。所以我在每次评测时都会记录下完整的协议信息——数据集版本、few-shot设置、prompt版本、温度参数、模型版本——形成一份标注清楚、随手可查的评测报告。这样不管是自己后续迭代，还是别人来质疑结果，都能给出完整解释。

下一步我打算把这个评测流程进一步自动化，把mini评测集做成定时任务，每天跑一遍，这样模型一旦出现回归就能第一时间发现。如果你也在做模型迭代，这个思路可以参考。基准测试本身不难，难的是持续、规范地测。把这一环做扎实了，你的模型在真实场景里的表现才真正有底。