大模型评测全攻略：从指标选型到评测集构建的实战方法论

大模型评测这事最近被问得特别多。好多朋友手里拿着模型要么是微调过的要么是自研的张嘴就问我这模型到底行不行然后甩过来一张跑分图。但说实话光看一张分数表根本说明不了问题——大模型评测真正难的不是跑个benchmark而是搞清楚你在评什么、怎么评、分数背后意味着什么。这篇文章我就用自己实际做评测的经验把大模型评测这件事从头到尾拆一遍。不绕弯子直接讲评测的维度拆解、指标选型、评测集构建、工具链实操以及我在真实项目里踩过的各种坑。不管你是刚入门想给模型做个全面体检还是准备做Agent评测集构建、垂直领域模型效果验证这篇都能给你一套可以直接抄作业的方法论。1. 评测的起点先搞清楚你为什么要评1.1 评测不是打分是回答业务问题很多人把评测理解成给模型算个分”这个理解太窄了。我在实际项目里看到的评测需求大概能分成四类能力体检型零基础基线评估想知道一个开源模型或API模型的能力天花板在哪能不能胜任某些任务。典型场景是选型比如在Llama、Qwen、DeepSeek之间做技术选型。迭代验证型自己在微调或RLHF每个checkpoint出来都要跑一轮评测看训练方向对不对。这种评测关注的是相对变化而不是绝对分数。场景准入型垂直领域落地前评估比如法律问答、医疗分诊、工业检测报告生成。这种评测关注的不是模型多聪明而是在特定任务上的可用率。安全合规型检测模型有没有偏见、幻觉、越狱风险、有害内容生成。这类评测现在越来越重要尤其是企业做私有化部署前。你会发现四类需求的评测方案完全不一样。能力体检可以跑通用benchmark迭代验证要控制变量跑稳定子集场景准入需要自建评测集贴近真实业务安全合规要用定向攻击和红队测试。所以我的习惯是接到评测需求先问三个问题你的决策是什么这个决策依赖哪些能力评测结果怎么影响决策这三个问题问完评测方案基本就出来了。评测不是为了得到一个分数而是为了降低你下一步决策的不确定性。1.2 评测的核心维度能力、对齐、安全把评测维度归纳一下我通常分成三块能力维度包括知识储备世界知识、专业领域知识、推理能力逻辑推理、数学推理、代码推理、语言能力生成质量、指令跟随、多语言、以及最近大家特别关注的长上下文能力和工具调用能力。知识类任务考的是记忆推理类任务考的是推导这两类在评测集上表现差异很大。对齐维度关注的是模型是否按人类偏好输出包括有用性、诚实性、无害性。具体评测手段有用RLHF reward model打分、人写偏好对做胜率评估win rate、对抗性prompt测试。对齐不好的模型可能能力分很高但回答风格很讨厌比如过度道歉、拒绝回答该回答的问题、或者胡说八道还很自信。安全维度是单独一块包括测试模型被越狱攻击的鲁棒性、敏感话题的处理边界、幻觉率给出无中生有的信息、偏见歧视种族、性别等刻板印象。这块和内容安全强相关企业部署前必须做。这三个维度分开评测、最后综合判断。千万别只拿一个MMLU分数就下结论一个模型可能MMLU很高但幻觉率同样很高放到客服场景里就是灾难。2. 指标与基准集理解分数的真实含义2.1 经典benchmark怎么选现在的基准集多到让人眼花缭乱但真正被行业公认、可以跨模型对比的其实就那么几个体系benchmark考察能力题量说明MMLU世界知识学科知识约1.4万题57个学科从人文到STEM全覆盖MMLU-Pro推理增强版约1.2万题增加干扰选项、减少纯记忆题C-Eval / CMMLU中文知识约1.3万题学科覆盖广中文评测必跑GSM8K小学数学推理约8500题考察多步算术推理对思维链敏感MATH竞赛数学约5000题难度高区分度大HumanEval代码补全164题考察Python函数级代码生成MBPP代码生成约974题偏基础编程能力BBH综合推理约6500题23个任务偏复杂推理IFEval指令跟随约1000题验证模型是否严格按要求输出GPQA研究生级问答448题难度极高当前模型的区分度好选基准集有个原则别贪多要覆盖你要做的决策。如果模型要做代码相关任务HumanEvalMBPP必跑如果做中文场景C-Eval、CMMLU必跑如果担忧推理能力GSM8KMATH是标配。通用能力基线MMLU或MMLU-Pro跑一个就够再加一个BBH补推理维度。2.2 指标背后的计算逻辑评测指标这里坑特别多因为不同benchmark的指标计算方式差异很大直接对比会闹笑话。Accuracy准确率多选任务的标准指标但要注意选项顺序敏感性问题。有些模型对选项的位置敏感A位置和C位置一样的选项回答正确率会有差异。所以部分评测框架会做选项打乱permutation取平均这样更稳健。Perplexity困惑度反映模型对文本概率建模的好坏越低越好。但PPL对tokenizer、文本领域都敏感不同模型之间直接比PPL意义不大。它适合做同一个模型不同checkpoint的对比不适合跨模型对比。passk代码生成任务的核心指标表示采样k次中有至少一次通过测试的概率。注意pass1和passk的差异——pass100高不代表平时好用因为实际生成时你就跑一次。HumanEval官方给的pass1是单次采样的通过率更贴近实用场景。BLEU / ROUGE / METEOR生成任务和翻译任务的指标通过n-gram重叠度衡量。这类指标和人类判断的相关性越来越被质疑尤其对长文本生成、摘要任务几乎只能做个参考。我现在的习惯是这些指标只用来做回归测试真正评估还是靠人工评分或LLM-as-judge。有一个容易被忽略的点few-shot设置会影响分数。同一个模型在MMLU上0-shot、5-shot的结果可以相差好几个点因为示例会教模型输出格式和推理模式。对比两个模型时必须保证完全相同的few-shot设置否则结果没有可比性。2.3 生成式评测最难的一趴现在大模型的使用方式越来越偏向开放生成开放问答、摘要、Agent任务这些都是传统多选评测覆盖不了的。生成式评测目前主流有两条路一条是参考答案匹配生成结果和参考答案算相似度。这个方法实现简单但问题很明显模型可能给出了正确但和参考答案表述不同的答案被误判为错误反过来可能文字相似但语义完全不同。所以它只适合答案格式高度约束的任务。另一条是LLM-as-judge用一个强模型当裁判给被评测模型的回答打分。这是我目前主力使用的方式。用GPT-4或者Claude类的模型当裁判对回答的正确性、完整性、格式做评分。但这里有个致命坑裁判模型本身有偏好。比如有些模型生成的回答过长裁判会误以为更全面而打高分有些裁判对中文理解不够评分会出现偏差。解决方法是让裁判模型只做相对比较pairwise comparison而不是绝对打分并且对两个回答的顺序做对称处理A/B互换各评一次再综合结论。还有一条更接近真实的路是人工评测建立详细的rubric评分规则让人基于标准打分。成本高、速度慢但最可靠尤其是做产品效果验收时不可替代。3. 评测集构建自己出题才是核心竞争力3.1 从现成benchmark到自建评测集跨界不是拼凑用过现成benchmark之后你会发现它们永远离你的真实业务差一层。这就是为什么我强烈建议团队至少维护一个自建评测集哪怕一开始只有50道题。自建评测集的流程大概是这样的第一选定任务场景。以一个客服场景为例任务可以定为给定历史对话和用户当前问题模型需要给出符合话术规范的回复且信息准确、语气专业。第二步设计样本。找真实对话记录做脱敏和改写覆盖不同用户情绪、不同问题复杂度、不同领域分支。取样时要刻意加入边界case——用户问模糊问题、用户提供错误信息、用户需要多轮澄清。第三步定标。每条样本附上参考答案和评分维度评分不能只有一个总分至少要分信息准确度话术合规度语气自然度三个维度打分。第四步验证。评测集建好后用两三个不同能力的模型跑一遍看分数能不能拉开差异。如果最强和最弱的模型得分都差不多说明题目设计有问题难度或区分度不够。自建评测集的价值在于它能锚定你自己的业务标准。很多时候外部benchmark涨了两个点但业务核心指标一点没动问题就出在benchmark和业务场景两张皮。自建集就是来拉齐这件事的。3.2 Agent评测集构建任务轨迹比结果更重要Agent评测是现在最热门的方向之一也是我最近在做的重头戏。Agent任务的评测不能只看最终结果对不对要看过程中模型的每一步决策。一个典型的Agent任务评测集要记录以下几个要素初始任务描述比如帮我预订一家周五晚上6点、2人、预算500以内的日料店可用工具集搜索工具、查询工具、预订工具等要定义清楚每个工具的输入参数环境的动态变化比如搜索返回的结果列表、库存状态的变化、用户中途追加条件期望的执行路径先调用搜索、再筛选、最后提交预订这中间可能不是唯一正确路径但要符合效率最优原则评分规则结果正确占多少分路径合理占多少分是否出现多余调用、无效调用、错误参数占多少分Agent评测目前行业里还没有统一标准OpenAI和Anthropic用的Agent评测集各有各的思路。我的做法是分两层评分结果层任务是否完成、输出格式是否正确过程层工具调用序列是否合理、是否浪费了不必要步骤、是否在失败时正确重试。过程层的评分可以用规则自动判也可以让强模型当裁判看轨迹。我个人建议过程和结果分开报分不要混成一个总分这样诊断问题时会清晰很多。有个非常实用的细节Agent评测集里的工具调用格式要和实际部署环境保持一致。很多Agent评测是在模拟环境里做的模拟环境工具的输出格式和真实API不完全一样导致评测分数虚高。最好用mock工具但真实API schema这样评测结果对真实部署有预测性。3.3 数据泄露评测集和训练集撞题怎么办数据泄露contamination是评测界的老大难问题。公共benchmark比如MMLU、GSM8K网上有海量相关数据模型训练时很可能已经见过了。这会造成分数虚高而且你根本不知道虚高了多少。对自建评测集数据泄露的风险同样存在。如果评测集是从公开渠道收集的或者团队成员在项目推进过程中接触过这些题目再拿去评测模型结果就可疑了。我的建议是第一评测集冻结和版本化。评测集定稿后除了评测组核心人员训练组不应该看到题目。每次评测用同一个版本避免评测集变化导致结果不可比。第二定期下发新样本。每年或每季度从真实业务里抽取新样本加入评测集防止模型训练数据时间范围覆盖了评测集。第三做泄露检测。可以用模型对评测题目的困惑度来辅助判断——如果模型对评测题的PPL明显低于普通文本说明可能见过这些数据。这个方法不是完美的但能提供一个预警信号。Frozen evaluation set constant refresh这两手都要抓。4. 跑一次靠谱的评测实操全流程4.1 评测工具链选型现在跑评测的主流工具我用下来比较顺手的有三个OpenCompass司南上海AI Lab出品的评测框架覆盖面最全支持多模型、多数据集并行评测中文社区文档和生态都很好。它自带大量评测集想要横向对比国内模型首选它。缺点是因为功能多配置稍微复杂学习成本高一些。lm-evaluation-harnessEval HarnessEleutherAI出品的经典评测框架轻量、灵活、社区活跃。适合快速跑MMLU、GSM8K、HumanEval这些经典集尤其是做checkpoint迭代验证时非常高效。缺点是新评测集接入要写适配器对小白不算友好。OpenAI EvalsOpenAI开源的评测框架原生支持LLM-as-judge如果你要做生成式评测、开放问答评测这个上手最快。缺点是绑定OpenAI生态比较深跑本地模型要写一层适配。我的工具选型经验基线对比用OpenCompass迭代验证用Eval Harness生成式任务用OpenAI Evals。三套工具各有侧重没必要只认一个死磕。另外如果你平时用微调框架如LLaMA-Factory、PEFT它们自带评测脚本适合快速看参数变化带来的影响但结果不要作为对外宣称的分数来源。4.2 评测实操关键参数与步骤我以一个典型的命令行评测为例展示从零开始跑MMLU的完整流程。假设本地模型已经部署在OpenAI兼容API上地址是http://localhost:8000/v1# 安装OpenCompass推荐用conda环境隔离 conda create -n opencompass python3.10 -y conda activate opencompass git clone https://github.com/open-compass/opencompass.git cd opencompass pip install -e . # 准备模型配置以Qwen2.5-7B-Instruct为例 cat configs/models/my_qwen.py EOF from opencompass.models import OpenAI models [ dict( typeOpenAI, pathQwen2.5-7B-Instruct, openai_api_basehttp://localhost:8000/v1, keyEMPTY, query_per_second1, max_seq_len8192, meta_templatedict( round[ dict(roleHUMAN, api_roleHUMAN), dict(roleBOT, api_roleBOT), dict(roleSYSTEM, api_roleSYSTEM), ], ), ) ] EOF # 跑MMLU这里指定了5-shot的MMLU子集 python run.py \ --models my_qwen \ --datasets mmlu \ --max-partition-size 20000 \ --dry-run # 先试运行看配置是否有错这里有几个参数值得展开讲query_per_second请求并发数。如果模型推理服务吞吐不够并发太大会导致超时或排队影响评测效率。本地部署用vLLM的话一般可以设到2-4。meta_template模型对话格式的模板。必须和你的模型训练时用的chat template一致否则模型输出会崩。Qwen系列、Llama系列、DeepSeek的模板不一样选错模板评测分数会大幅下降。--max-partition-size分批参数防止一次加载太多数据把评测节点内存打爆。跑完出结果的命令一般是python run.py \ --models my_qwen \ --datasets mmlu \ --work-dir output/mmlu_qwen2.5-7b然后在输出目录里看summary表OpenCompass会生成每个子集的accuracy。MMLU有57个子集我一般先看平均分再挑几个关键学科看细分——比如计算机科学、法律、医学这些和业务相关的。4.3 评测结果的解读与报告分数不是终点拿到分数之后真正的工作才开始。我见过一堆人拿到summary table就结束了这是最大的浪费。正确姿势是对细分结果做分析。举一个实际案例某次评测一个微调模型MMLU总分和基座模型差不多但如果分学科看发现它在职业心理学上暴涨在物理学上暴跌。原因是微调数据里职业心理学的题目特别多导致模型在这个子集上过拟合。如果只看总分你完全发现不了这个问题。所以我会把评测结果拆到学科粒度、样本粒度去找分数波动的来源再对应回溯训练数据配比的问题。另外要注意评测报告里必须写清楚评测条件用了多少shot、max_tokens是多少、temperature是多少、使用的框架版本。上次有个团队汇报模型效果说比另一个模型高5个百分点结果细问之下发现他们用OpenCompass跑的5-shot对方用Eval Harness跑的0-shot根本不适合对比。评测条件不透明是评测结果不可信的头号原因。5. 常见问题与排查技巧实录5.1 Prompt敏感性同一模型两次评测分数不一样这是评测中最常见也最隐蔽的坑。同一个模型、同一个评测集因为prompt模板里多了一句引导语分数就可能变化。比如有的框架在问题之前加一句请仔细思考并回答GSM8K的分数可能会提高因为触发了模型更充分的思维链。解决方法是固定模板并记录模板版本。所有评测统一用一套prompt模板模板改动必须走审批或至少同步记录。横向对比时如果想减少模板影响可以跑两次不同模板取平均值。对于推理类任务我还会额外设置CoT开关的对比评测——开思维链的和不开的分别跑一遍看模型是真实推理能力还是匹配了模式。5.2 解码参数temperature和top_p对分数的影响代码生成、数学推理这些任务解码参数的微小变化可能带来几个点的波动。尤其是passk类的指标当temperature高、采样多样化时passk会明显变高。如果你拿temperature0.8的pass100去宣传而别人用的是temperature0这就不公平了。我的建议是统一用temperature0、top_p1做最严格的确定性评测这代表模型真实水平需要看采样分布情况时可以单独跑temperature分档实验但报告中明确标注。还有一个细节是max_tokens要给够GSM8K这种多步推理题max_tokens给128还是512分数能差好几个点。5.3 推理框架的差异float16和int8影响大不大跑评测时用哪个推理引擎也会影响结果。vLLM和HuggingFace Transformers的采样逻辑在细节上略有不同同一个模型可能得出微小但可观察的差异。更值得警惕的是量化推理——int8、int4量化后的模型和float16对比在推理密集型任务上可能会掉分而知识型任务影响较小。这个问题的处理办法是在做模型选型对比时所有模型都要用同一推理框架、同一精度跑。如果企业最终部署要用int8量化那评测也应该基于int8的结果来做决策否则评测环境和生产环境不一致评测参考价值就大打折扣。5.4 评测集冻结合规性还有一点容易被忽视的是评测集的合规性。用公开benchmark评测没问题但如果你的评测集里包含私有业务数据、用户对话就要注意脱敏和权限控制。评测集不要存在公共仓库不能随意外发。有些大模型开源社区要求评测集公开这涉及到数据授权问题要提前和法务确认不然吃官司了才想起来就晚了。我个人在做评测时会把合规审查作为评测集上线前的必经环节——不光是业务数据的脱敏还要确认评测集里没有违反第三方使用协议的内容。6. 我的几点评测心得做评测这行越久越觉得评测本质上是建立信任的过程让模型在可控的、可复现的、有区分度的样本上接受检验再把结果转化为决策依据。说几个我经验里的核心体会。第一个是永远不要只跑一套评测通用benchmark加自建评测集已经是标配有条件的再加安全评测和人工抽测。四个维度互相印证才能拼出一张靠谱的模型画像。第二个是评测集要持续维护不是建完就完事了要持续加新题、优化评分规则否则评测集本身也会老化。第三个是过程纪录比分数本身更重要每次评测的配置、版本、环境全部记录在案半年后发现分数异常才能有据可查。最后分享一个小技巧我会在每次评测报告里加一个**评测可信度**自评栏用高、中、低来标注这次评测结果的可信程度。如果评测集是新建的、样本量不足、并且模型对prompt非常敏感可信度就标低。这个自评能防止团队对外发布结论时过度自信——评测是在对抗不确定性明确了不确定性本身就赢了一大半。