一篇评测集如何同时看穿模型和agent我先讲个真实经历。去年我在做一次模型选型候选模型有四个三份榜单、两篇博客看起来各有胜负。我当时犯了一个所有新手都会犯的错——拿公司内部的上线样例去挨个试结果发现四家在业务场景里表现都不差根本分不出谁更值得长期投入。后来一个做评测的朋友点醒我你在拿“随堂测验”做“期末考”一份没有经过设计的评测集分数再高也只说明模型运气好。这话让我换了思路开始认真研究评测集。所谓“看穿模型和agent”本质上不是某个模型有多强而是在可控的、可复现的、经过标准化的任务集上你给它们出同一套卷子然后对比得分。这套卷子就是评测集。今天这篇内容我会完整把评测集的核心逻辑、选型方法、实操流程和常见坑讲透不光是让你会用还要让你能自己构造一份可信的评测集。1. 评测集到底是什么看懂“考卷”背后的逻辑1.1 评测集不是题库是一把“刻刀”很多人把评测集理解为“很多问题拼在一起”这种理解不能说错但会让人忽略最关键的层面。评测集真正的价值不在“题目多”而在“切片准”。我习惯把评测集比作一把刻刀。模型是一个大块原石榜单分数是石头表面的一道反光而评测集是从不同角度切进去的切面——数学推理是一个面代码生成是一个面指令跟随是一个面agent部分则切得更深任务分解、工具选择、多轮纠错、记忆回放每个面都能反映出模型某类底层能力。所以一份合格的评测集至少要满足三个条件题目难度有梯度既要能筛掉完全不会的也要能区分“会一点点”和“精通”任务类型有覆盖模型能力不是单点而是多维度的单测一个题型等于盲人摸象评分标准可复现同一道题谁跑、什么时候跑、用什么框架跑结果都应该基本一致。如果你手里一套评测集跑完只得出一个“准了”或者“不行”的模糊结论那说明这套评测集没切到位。真正的评测集应该告诉你这份模型在哪个具体步骤上塌了。后面我会细说怎么定位。1.2 为什么模型评测和agent评测必须分开看把“模型”和“agent”放在标题里是因为这两类对象在评测时的复杂程度完全不在一个量级。单模型评测好比给一个考生发一张标准试卷考生只需要在限定时间内给出答案。你关心的是知识储备、推理链条、生成质量输入是独立的输出也是独立的每道题互不影响。评测集维护起来相对轻松跑分也比较稳定。agent评测就完全是另一回事。agent是一个“带着目标去行动的系统”它在每一轮会收到新的环境反馈然后决定下一步动作。评测内容不只是在考模型的生成能力还在考模型能不能把任务拆成合理的子步骤能不能在工具返回报错时改变策略能不能在长程任务中记住前面做过的事情多智能体场景下能不能有效协作。所以一套模型评测集直接拿去测agent通常会失真。因为单轮问答的分数无法反映agent的工作可靠性。这就是为什么我们会看到有些模型在MMLU上拿了很高的分但部署成agent后实际任务完成度惨不忍睹。我见过有人用一份纯问答评测集去测两个agent框架跑完觉得框架A明显更好后来仔细一看框架A只是把工具调用的格式整理得更好模型本身生成工具参数的能力其实和框架B差不多。这里就是评测粒度的错位。想看穿agent评测集里就必须包含任务型题目、交互型题目和环境反馈型题目靠一套纯知识问答打不了这个仗。1.3 评测集的三层结构数据、指标、协议既然要用评测集就得先理解它的内部结构。一份成熟的评测集通常由三个层面组成三个层面各司其职。第一层是数据层。数据层包括输入提示词、标准答案、评分参考有时还有辅助字段比如“该题是否需要多步推理”“是否允许调用工具”等。数据质量决定评测下限如果标准答案本身有错后面分数跑得再高也是虚假繁荣。第二层是指标层。常用的有准确率、F1、BLEU、Rouge代码生成场景还会看Passk执行递归场景看任务完成率。不同任务类型匹配不同指标拿BLEU去测代码题基本没有意义拿Passk去测开放域聊天也说明不了问题。第三层是协议层。协议层定义“怎么跑”包括模型生成时的温度参数、最大token数、是否使用few-shot示例、停止词怎么设置、遇到超时可重试几次等。这一层最容易被忽略但它恰恰是评测结果可复现的关键。同一个模型在相同数据上温度从0改到1结果可能天差地别。实际操作中最让我头疼的也是协议层。因为很多开源评测集在发布时没有明确写协议你只能通过源码读默认参数。读到了还要确保换一个框架之后参数照样生效。这块我会在第3章展开讲。2. 评测集怎么选先看模型还是先看任务2.1 通用能力评测集MMLU、GSM8K、HumanEval的正确用法目前公开常用的通用能力评测集已经形成几大类我按任务类型给它们分个组。知识广度类代表是MMLU。它覆盖STEM、人文、社科等多个学科多选题为主考察的是模型“知识储备基本推理”。适合做模型初筛但不适合测评agent也不适合判断模型的深度推理能力。数学推理类代表是GSM8K小学数学应用题要求分步推理。还有MATH数据集难度更高。跑这类数据时我建议重点看模型在某一步推导出错的位置而不是只看最终答案正确率因为很多模型会“答案对了、推理是瞎编的”。代码生成类代表是HumanEval写函数补全。用passk指标其中k通常取1、10、100。pass1代表一次性写对的概率pass100代表模型能否在有多次尝试机会时找到解法后者更能反映模型的代码潜力。指令跟随类代表性有IFEval和MT-Bench。IFEval会把指令拆成可验证的约束比如“输出必须包含三个问题”“回答要在100字以内”用约束满足率作为指标。MT-Bench则是多轮对话再由裁判模型打分。这里有个实用建议通用评测集至少在两类任务上都跑一遍不要只看模型在你任务类型上的表现。比如你明明在做代码agent却只跑MMLU那就测不出代码能力但只跑HumanEval又测不出模型在中文指令理解上的短板。交叉评测才能把木桶的短板找出来。2.2 agent专项评测集任务完成率才是硬指标如果你要评估的是agent而不是纯模型那就得关注专项评测集。agent专项评测集的特点是题目本身就是“一个带目标的任务”评测过程会注入环境反馈最终打分看任务是否完成。代码agent方向SWE-bench是绕不开的。它把真实GitHub仓库里的issue整理成任务让agent自己改代码、跑测试。指标以“解决的issue比例”为准非常贴近实际开发场景。另一个是RepoBench偏代码补全与跨文件理解。工具调用方向API-Bank和ToolBench把一组API封装成工具让agent根据用户需求去选择、调用工具并解析结果评测重点在“工具选择的准确率”和“参数填充的完整率”。如果你的agent主打“帮我订机票”“帮我查天气”这类评测集非常值得参考。多智能体协作方向GAIA虽然不算严格的多智能体但它的题目需要多轮检索和推理很多框架拿它做整体能力压测。AgentBench则在操作系统、数据库、知识图谱等多个环境里设置了交互任务覆盖面很广。我特别推荐你关注一个指标任务完成率。完成率是agent评测里最硬、最不容易作假的数字。它不在乎过程是否优雅只看最终状态是否达到目标。相比之下类似“工具调用次数”“平均往返轮数”最多只能作为辅助参考不能当作核心成绩。2.3 选评测集时的四条实用原则评测集选择是个老生常谈但永远有人踩坑的话题。基于我自己的使用经验给你四条实用原则第一先定“你要看什么”再选“数据怎么排”。很多团队第一步就去下载最火的榜单然后往回套自己的业务这是本末倒置。正确顺序是把业务任务拆成能力项再从评测集里挑覆盖这些能力项的题目。第二看数据覆盖年份和领域范围。大模型知识有截断时间评测集也有时效性。一个2021年就停止更新的代码题集很可能无法体现新框架带来的能力提升。挑评测集时先看它是否仍然“卷得动”当前的主流模型。第三优先选“有执行环境”的评测集。尤其agent评测像SWE-bench这类带执行器的数据集比纯静态问答要真实得多。因为你能看到agent改的代码到底能不能通过测试而不是靠裁判模型的主观打分。第四多个评测集组合使用但别贪多。组合时遵循“21”原则两个通用能力评测集加上一个业务专项评测集。太多的评测集堆在一起跑分时间会拖得很长参数对齐也变得复杂反而不利于你快速做决策。3. 手把手跑通一个模型评测实操篇3.1 环境准备和评测框架选型实操环节从环境准备开始。你要跑一份开源评测集一般需要准备GPU环境、Python环境、评测框架和模型权重。GPU方面显存大小决定了你用多大规模的模型、什么样的加载方式。推理一个7B参数模型bf16精度大概需要14-16GB显存8B模型差不多也是这个量级如果做4bit量化7B模型可以压到6GB左右。跑评测时显存占用往往高于单次推理因为要连续批量处理所以我建议你的显存至少要有模型推理需求的1.2倍以上。框架选型上模型评测最常用的是lm-evaluation-harness全程叫EleutherAI/lm-evaluation-harness支持几百个评测集封装了统一的协议层省去很多自己写prompt模板的麻烦。如果你要测agent则可以用LangChain或自建的执行环境来包装评测集现在也有许多agent评测框架例如OpenAI的agent-projects用的评估框架、以及各类支持tool-use执行器的框架。选框架的核心思路是先确认框架支不支持你目标评测集的原始格式。如果支持就省掉格式转换的步骤如果不支持就得自己写适配器这部分往往是实际工作中最耗时的地方。3.2 使用lm-evaluation-harness跑通MMLU的完整流程安装lm-evaluation-harness很简单直接用pippip install lm-evaluation-harness然后跑MMLU我一般会先指定模型路径、任务名称和输出路径lm_eval --model hf \ --model_args pretrained/path/to/model,trust_remote_codeTrue,dtypebfloat16 \ --tasks mmlu \ --batch_size auto \ --output_path results/mmlu_test \ --log_samples这里有几个参数值得解释model_args里pretrained指向本地模型权重目录trust_remote_codeTrue是为了加载那些模型结构需要自定义代码的模型不加可能会报错。--tasks mmlu是任务名。lm-evaluation-harness内部把每个评测集封装成一个注册好的task运行前可以先执行lm_eval --tasks list查看所有支持的评测集。--batch_size auto会让框架自动探测最优batch size这比手动指定更省心但在显存不足时自动探测也可能OOM建议第一次跑固定成1或2。跑的过程中控制台会逐任务打印准确率最终在输出目录生成results_*.json。这个JSON包含每个子任务的分数注意MMLU并不是单一准确率而是多学科子任务比如mmlu_anatomy、mmlu_physics等等汇总后才能得到整体分。只看聚合分数你会丢失很多学科维度上的细节。3.3 结果解读只盯着准确率就亏了评测跑完不是终点解读才是关键。第一步是看子任务分布。MMLU有57个子任务如果模型在formal_logic上只有30%准确率在professional_law上却有70%说明模型的“逻辑规范化推理”是短板而不是所有知识都差。第二步是对照baseline。同一个评测集、同样的参数跑一遍你当前线上模型得到基线线。然后再跑新模型看差值。差值比绝对值更有参考价值因为不同框架、不同prompt模板会带来系统性的分数偏移。第三步是分析错误样本。评测框架通常支持--log_samples参数把每个样本的输入、模型输出、标准答案都落盘。有了这些样本你可以做错误分类是答非所问、格式违反、推理缺失还是单纯知识遗漏。这一步非常费时间但也是收益最高的。第四步是关注生成质量而不是二分类正确率。很多评测集允许自由生成比如某些指令跟随任务你需要自己再写一段脚本做后处理把模型输出的换行、标点规范化后再计算指标。我见过有人直接拿原始输出算ROUGE因为标点差异把分数压得特别低这不是模型能力问题而是后处理问题。这里有个参数细节要特别提醒评测集指定的fewshot数量和实际num_fewshot要一致。很多公开榜单会写用了5-shot但默认框架跑的是0-shot结果完全对不上。正确做法是先在数据集官网查推荐配置再在lm-eval的task配置里检测是否有默认值。3.4 模型融合与模型检查器场景怎么测根据热词延伸很多朋友对“模型融合”和“模型检查器”这两个场景感兴趣。评测集在这两个场景里的用法不太一样单独拿出来说。模型融合通常指多个模型集成或权重融合比如DARE、模型插值、LoRA合并。评测融合效果时我建议跑“能力对比矩阵”选三份评测集分别覆盖推理、代码、指令跟随然后对基线模型、参与融合的子模型、融合后模型都跑一遍。重点看融合模型的分数是“取长补短”还是“负向干扰”。我调过一组权重插值实验融合后的模型在GSM8K上比两个子模型都高但HumanEval分数反而下降。这种“单点涨分全局失衡”的情况单靠一个评测集根本看不出来只有做交叉能力扫描才抓得住。模型检查器则是给模型行为做“体检”的工具。我理解你可能是想找一套能系统化检查模型能力边界的方法。用评测集做检查器时不要只关注“会不会”还要设计“会不会误导”。比如给模型输入一个带有隐含陷阱的指令看它会不会被带偏。这种检查器评测集不需要很大一百道精心设计的题目就够用。检查器的核心指标是“误判率”和“拒绝率”。误判率指模型在输出中给出看似自信实则有错内容的比例拒绝率指模型错误判断自己能力不足而拒绝回答的比例。两者都要看只盯着一边会做出一个要么乱说要么装哑巴的模型。4. agent评测实操比模型评测变量多到哪里4.1 三类agent任务的评测侧重点进入agent评测我建议把它拆成三类分别有各自的侧重点。检索型agent核心能力是“从一堆信息里找到答案”。评测侧重点是检索正确率、信息定位耗时的轮次、是否被无关信息干扰。评测集通常会提供一组文档库和若干问题agent需要自己检索并回答。跑这类任务时我特别关注“记忆污染”问题上一题的搜索结果会不会串到下一题。代码型agent核心能力是“在仓库级代码中完成修改”。评测侧重点是是否能让测试通过、是否引入回归错误、是否保持代码风格一致。SWE-bench就是典型。评测这类agent除了完成率我还会看补丁diff大小diff过大通常意味着agent写了很多冗余代码这在工程上是不受欢迎的。交互型agent核心能力是“在多轮对话中理解用户意图并完成任务”。评测侧重点是任务完成度、多轮状态跟踪准确率、兜底策略是否合理。比如用户中途改变需求agent是否能正确放弃旧目标重新规划新目标。这类评测打分最难自动化往往需要裁判模型或者人工打分。4.2 结果不稳定同一agent跑两遍结果不一样是bug吗这是agent评测里最劝退新人的问题。评测脚本一模一样两次跑出来的分数却不一致于是怀疑环境有问题。其实agent评测天然具有随机性主要原因有三个。一是模型生成的随机性。LLM采样过程中temperature不为0同样的输入会得到不同输出。跑agent任务时推荐把模型temperature设成0绝大多数推理模型在贪心解码下会稳定很多。如果任务必须靠采样提高探索性那就固定随机种子并在评测报告中注明随机种子值。二是agent框架的异步调度。agent在调用工具、解析模型输出时往往存在并发线程或事件循环。即使模型输出确定只要环境反馈顺序变了路径就会变。解决办法是串行评测并做多次运行取平均。我建议至少跑3次取平均数和标准差。三是评测集自身状态的污染。有些任务里agent是有“记忆力”的前一次运行的记忆没有被清空会直接影响后一次任务的结果。每次评测前必须重置环境包括清空向量库、会话上下文和临时文件。所以多跑几遍再下结论。4.3 agent记忆与上下文管理怎么测“记忆”是agent评测里最特殊的一环。热词里也出现了“agent记忆”可见关注度很高。常规模型评测完全不会测这个但agent在长程任务中记忆机制是否可靠直接决定结果。我的做法是设计一组“记忆连续性”任务。任务模式如下第一步向agent提供一段背景信息比如一个包含多个成员信息的会议记录 第二步让agent执行一个无关任务把注意力调走 第三步再询问关于第一步背景信息中的具体细节看agent能否准确回答。关键观察点是agent在第二步之后有没有遗忘以及有没有把无关任务的信息错误地“记”到背景信息上。没有记忆或记忆串扰严重的agent在这个评测里会明显暴露出缺陷。上下文管理测试则是看agent能不能在长上下文中定位关键信息。我会故意把关键信息埋在长文档中段而不是开头和结尾然后提问。模型普遍对上下文两端的信息更敏感中间部分容易被忽略这是Transformer结构导致的常见现象。跑这类评测时把上下文总长分段标记作为分析依据。5. 评测集使用中的高频坑问题排查速查表5.1 六类典型问题与快速定位方法我整理了评测过程中最高频的六类问题附带定位方法建议直接对照排查。问题现象可能原因快速定位方法分数比榜单低一半评测协议不一致fewshot、模板、停止词检查本次评测与官方配置是否一致尤其是fewshot数量同一模型不同框架分数差大后处理逻辑不同对比两个框架对生成内容的解析规则模型输出为空/超时模型生成停止词未配置检查停止词是否包含评测集要求的终止符agent任务完成率波动大环境未重置或采样随机性固定seed串行执行重置记忆多次取均值评测数据与训练集重叠数据污染抽样人工检查或用去重工具对比训练语料显存OOMbatch_size过大调小batch_size或打开模型量化加载这类问题有个共同特征都是“环境问题”而不是“模型问题”。如果评测结果出现明显异常我第一条经验是先检查评测协议而不是去怀疑模型权重损坏。5.2 评测数据污染看起来高分实际却废了数据污染是评测集使用过程中最隐蔽的问题。具体表现是模型在预训练或对齐阶段已经见过评测集的全部或部分题目于是跑分虚高但遇到实际业务场景立刻原形毕露。数据污染通常无法在评测时肉眼发现只能从侧面验证。几种常见方法一是交叉验证。拿一套时间更晚、风格更新的评测集做对比测试。如果老评测集分数非常高、新评测集分数一般就要警惕污染。二是波动分析。数据被污染过的模型在评测集各子任务上的得分通常极不均匀某些几乎是满分某些又低到离谱。那种“科目之间分数断裂感严重”的模型大概率有记忆泄露。三是手工查看输出。聚合指标可能掩盖一切。我会随机抽20个评测样本看模型输出是“思路清晰逐步推理”的风格还是像“背过答案直接写结论”的风格。这个差异人眼很容易分辨。预防思路有两个一是优先选用发布较晚的评测集二是在自己的数据集上做去重把与公开评测集相似度高的样本剔除。做RAG或agent产品时建议额外保留一批私有评测集永远不要对外发布。5.3 自定义评测集要避免的三件事如果你要构建自己的评测集三个最常见的坑需要绕开。第一题目难度倒挂。自己编写评测集时很多人会不自觉地出一些“对自己模型有利”的题导致整套卷子难度集中在某一能力上忽略了其他能力。解决办法是先写能力分布矩阵再按比例出题比如推理题占比40%、工具调用占比30%、多轮对话占比30%然后严格按比例执行。第二评分标准模糊。如果是自由生成任务没有明确评分Rubric裁判模型打分就会忽高忽低。比如“回答是否礼貌”这种描述太主观要量化成“是否有道歉句式”“是否提供解决方案”等可验证条目。第三答案没有多解覆盖。大模型生成同一道题的答案可能五花八门如果你只准备了一个标准答案那么哪怕模型答对了但表达方式不同也会被误判成错。建议每道主观题收集3-5个参考答案变体或直接使用LLM-as-judge并附上评分标准。6. 从“会用”到“会造”如何构建一个可信的评测集6.1 从业务场景抽象出任务类型自己做评测集的第一步永远不是写题而是抽象任务类型。一个业务场景可以拆出若干种“能力原子”比如一个客服agent拆开后包括意图识别用户说“我的快递还没到”能不能识别为查询物流。多轮澄清用户说“那换一个吧”能不能结合上文知道“那”具体指代什么。工具调用调用物流接口时参数订单号、查询范围填得对不对。边界拒答用户问“你周末休息吗”能不能合理应对而不是一本正经胡说。建议用表格列出能力原子与测试题量的对应关系。比如意图识别出20题、多轮澄清出10题、工具调用出30题、边界拒答出10题。测试题量不必大但每种能力必须有覆盖。6.2 评测数据的字段设计和评分卡制作评测数据最小结构至少要包含以下字段字段说明示例task_id唯一编号task_001prompt输入内容“帮我查一下订单8888到哪了”expected_action期望的agent动作调用query_logistics参数order_id8888expected_answer期望的最终回答包含“运输中”和具体时间difficulty难度等级easy / medium / hardcategory能力分类tool_call / multi_turn / refusal除了数据本身我强烈建议为每个维度做一个评分卡。评分卡不是简单的0/1而是1-5分制每个分数对应明确的描述。比如工具调用维度1分是“拒绝调用工具且回答错误”3分是“调用了工具但参数有误”5分是“调用正确且参数完整、返回解析无误”。有了评分卡即使让人工打分不同标注者之间的结果一致性也会高很多。6.3 最小可用评测集的迭代路径新团队或新项目构建评测集我建议走“小步快跑”路线不要一开始就追求几百上千道题。第一版目标只有一个能区分“可用”和“不可用”。题量控制在100道左右覆盖最核心的3-5个能力原子人工跑分耗时大概一到两天。跑完之后不要急着扩量先观察这100道题有没有“区分度差”的题目——比如所有模型都能满分或者所有模型都0分这类题目要么难度不对要么答题标准不明确需要调整。第二版目标升级成“能区分模型间的微小差异”。题量扩到300-500道加入中等难度和困难难度样本。此时可以开始用小批量自动化评估先把生成和评分脚本固化下来。第三版目标变成“可回归、可长期监控”。题量500以上引入多批次实验记录把每次评测的配置参数固化到配置文件里。达到这个阶段评测集才真正成了你手里的“照妖镜”任何模型改动、prompt改动你都能快速判断是变好还是变差。说实话运行评测这套流程本身并不难难的是你愿不愿意花一个下午去把每个样本的错误类型标记清楚。我自己的体会是评测集的价值一半在数据里另一半在错误分析里。很多人跑完评测只看一个总分然后就开始调prompt这等于考试只看了成绩单却没有看卷子上的错题进步自然会慢。最后分享一个实用小技巧建立一份“评测日志”每次跑分都记录评测集版本、模型版本、框架参数、随机种子和跑出来的完整指标。等到模型迭代三个月后这份日志能帮你节省大量的倒查时间。评测集不是一次性工具它更像你的长期体检方案只有坚持记录和对比才能真正“看穿”不透明的模型和agent能力变化。