做AI这行的不管你是搞训练的还是做应用的几乎都逃不过一个问题有人拿个模型过来问“它到底行不行”。你要说“感觉还行”对方肯定不满意。但你要是能甩出一串分数比如MMLU多少、GSM8K多少、HumanEval多少对方立马就有体感了。这串分数从哪来就是Benchmark基准测试。我这份AI学习笔记已经整理到第67篇这篇专门把大模型评测这块摊开讲清楚。内容包括Benchmark到底在测什么、主流的评测集各有什么脾气、为什么同一个模型在不同榜单上分数能差出一大截以及我自己跑评测时踩过的坑和最终沉淀下来的操作流程。适合刚入门的同学建立评测知识框架也适合已经在跑模型但被各种榜单指标绕晕的开发者看完至少能搞清楚那些眼花缭乱的分数背后到底代表了什么能力。1. 基准测试到底在测什么1.1 没有统一标尺就没法谈性能对比先说个生活化的类比。你买手机的时候会看跑分、看续航测试、看拍照样张因为这些指标把“好不好用”这个模糊问题拆成了可量化的维度。大模型也是一个道理模型能力太抽象你说“这个模型聪明”什么叫聪明能写诗算聪明能解数学题算聪明能写代码也算聪明。如果没有一套统一的考试题每个团队都说自己的模型好那行业就乱套了。Benchmark就是这套统一的考试题。它把“模型能力”拆成多个维度知识储备、推理能力、数学能力、代码能力、指令遵循、安全性、多模态理解等等然后用固定的题目和固定的评分规则给模型打分。这样一来无论你用的是哪个模型只要在同一套题上跑分数就可以互相比较。这里有个关键概念要区分数据集和基准。很多人把这两个混着用实际上“数据集”是题本身“基准”是“题目评测方法评分规则”的完整协议。比如有了一道数学题你怎么问模型是直接给题让模型答还是加一句“请逐步思考”答案格式有什么要求评分是看最终结果还是看过程这些都属于评测协议的一部分。同一个模型用不同协议去测同一个数据集分数都可能不一样这一点在后面踩坑部分会详细讲。1.2 评测协议里的基本术语先统一一下聊基准测试绕不开几个术语这里集中解释后面才不会懵Zero-shot零样本不给模型任何示例直接提问。比如直接问“11等于几”。这测的是模型对指令的泛化理解能力。Few-shot少样本在提问前给模型一些示例比如给两道做过的题和答案再让模型做新题。少样本能帮助模型理解任务格式通常分数会比零样本高。CoTChain-of-Thought思维链要求模型把推理过程一步步写出来再给答案。对数学、逻辑类题目有明显帮助但也会让生成变长评测耗时上升。Pass1模型第一次生成的结果就算对错测的是“一次答对”的能力。Passk允许模型生成k次答案只要其中一次对了就算通过。这个指标主要用在代码生成评测里因为真实写代码本来就是多轮尝试的过程。这些术语之所以重要是因为你看到一张榜单的时候如果它没写清楚评测协议分数就失去了参照意义。两个模型都用5-shot CoT测GSM8K分数才有可比性一个是0-shot、一个是5-shot分数直接对比就是在耍流氓。2. 主流基准全景拆解你的模型适合测哪套市面上公开的大模型评测集几十个我按考察能力把它们分成了六大类。每个类别挑最常用的来拆解看完你就知道该拿哪套题去测你的模型。2.1 综合知识类MMLU与中文场景的C-EvalMMLUMassive Multitask Language Understanding是目前最出圈的综合知识评测覆盖57个学科从数学、物理、历史到法律、伦理总共约1.4万道四选一选择题。它的设计思路很直接像高考一样从各个学科抽题考模型看谁的知识面更广。评测时通常用5-shot也就是每个学科先给几个示例再正式测。MMLU的好处是覆盖面广、题目稳定、跨模型可比性强所以几乎所有大模型发布时都会带一笔MMLU分数。坏处也很明显它测的主要是知识记忆和基础理解对复杂推理能力的区分度不够。一个模型如果训练数据量大见过很多类似题目MMLU分数就能刷得很高。所以现在很多榜单不只报MMLU还会搭配推理类评测。C-Eval是中文场景下最有影响力的综合评测集包含52个学科、约1.4万道四选一题覆盖人文、社科、理工、其他四个方向还分了初中到研究生的难度层级。它的题目全部是中文评分也考虑了中文模型的特点对评估中文大模型很合适。国内团队做模型基本都会报C-Eval分数。2.2 推理与数学GSM8K与MATHGSM8K是小学数学应用题集约1300多道题主打“多步推理”。比如“小明有5个苹果妈妈又给了他3个他吃掉了2个请问还剩几个”这种级别但实际题目比这个复杂一些需要模型分步计算。这套题的魅力在于题目答案唯一评分客观而且对模型的真实推理能力比较敏感。一个模型如果只会背知识但不会推理在GSM8K上分数会很难看。评测GSM8K时CoT的影响特别明显。让模型直接给答案和让模型“先写解题过程再给答案”分数能差出20个百分点。这个现象也催生了很多专门针对推理优化的训练方法。MATH是竞赛级数学题集约5000道题覆盖代数、几何、概率、数论等七个方向。难度远超GSM8K很多题目对专业选手都有挑战性。MATH满分是5分每个题按步给分评测比较复杂。能在MATH上拿高分的模型推理能力基本是行业第一梯队。2.3 代码能力HumanEval与MBPPHumanEval是OpenAI发布的代码生成评测集包含164个编程问题。每个问题给出一段函数签名、文档字符串和几个示例要求模型补全函数体。它的评分标准是Passk模型生成的代码要能通过预置的单元测试才算正确。164个题量看着不大但覆盖了循环、递归、字符串处理、位运算等常见编程场景区分度很好。MBPP是另一个常用的代码评测集包含约974个基础编程题难度比HumanEval低一些更贴近日常编程任务。它的题目会直接描述“编写一个函数实现某某功能”模型需要根据描述生成完整代码。代码评测有个坑要注意HumanEval这种补全式题目对模型输出格式极其敏感。模型如果多写了一个解释性的句子哪怕代码本身是对的也可能因为无法通过严格解析而被判错。所以跑代码评测时通常会用专门的解析器提取代码片段或者要求模型严格只输出代码。这也是为什么同一模型在不同代码榜单上的分数经常对不齐——解析规则不一样。2.4 多模态与长文本MMMU、MMBench、LongBenchMMMU是面向多模态大模型的评测集包含约3万道大学级别题目覆盖艺术、工程、商业、科学、医学等六个学科。每道题都配有图片模型需要同时理解图像内容和文本问题才能作答。这类评测考察的是视觉理解和跨模态推理能力对多模态模型的区分度很好。MMBench是中文团队推出的多模态评测集包含约3000道题用了一套更精细的能力标签体系把“识别”“定位”“推理”“OCR”等维度拆开打分能更细致地反映模型在哪些多模态能力上有短板。LongBench是专门测长文本理解的评测集包含21个数据集覆盖单文档问答、多文档问答、摘要、代码补全、数学推理等场景上下文长度从几千字到几万字不等。长文本评测有个典型现象模型在短文本上表现很好但上下文一长性能就断崖下跌。LongBench的设计就是为了暴露这个问题。2.5 安全、对齐与指令遵循TruthfulQA、AlignBench、IFBench这一类比前面几类更特殊因为它测的不是“模型会不会”而是“模型愿不愿意好好答”。模型知识再丰富如果用户一问就编造事实、输出危险内容或者不按用户指令执行那在生产环境里就是灾难。TruthfulQA是一套判断题集专门测模型是否会给出事实错误或“看起来正确但实际是编造”的答案。它选了很多人们容易误解的常识性问题比如“地球是平的这种说法对吗”模型如果直接顺着错误观点回答就会被判错。AlignBench是中文场景的对齐评测从真实性、安全性、有用性等多个维度打分题目类型包括聊天、写作、翻译、数据分析等对中文对话模型的对齐效果有很好的衡量。IFBench专门测指令遵循能力比如“在回答开头加一个感叹词”“把第三句话翻译成英文”这类细颗粒指令。很多模型在复杂指令组合下会漏掉某一条这类评测就是揪这些小毛病。2.6 通向AGI的评测AGIEval等AGIEval是一套用人类标准化考试题来测模型的评测集包括高考、司法考试、公务员考试等真实考题。设计理念很直接既然这些考试人类能用那模型如果真具备通用智能也应该能应对。这套评测对模型的综合能力要求极高分数普遍偏低更像是一个“理想化”的上限测试。还有个经常被一起提到的ARCAI2 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评测集做成定时任务每天跑一遍这样模型一旦出现回归就能第一时间发现。如果你也在做模型迭代这个思路可以参考。基准测试本身不难难的是持续、规范地测。把这一环做扎实了你的模型在真实场景里的表现才真正有底。