这几年被问得最多的一个问题就是2026年了到底哪个大模型最强我每次都不太想直接回答因为这个问题本身就是个坑。你拿 MMLU 榜单出来对方说这玩意儿早就饱和了你换成 Chatbot Arena 的 ELO 分数对方说投票有品牌偏见你再转向 Agent 评测人家又说 Agent 评测五花八门、口径混乱。几个来回下来一场技术讨论就变成了玄学辩论。作为一个常年干模型评测、给企业做选型落地的人我的结论其实很简单榜单不是不能信而是绝大多数人根本不会读榜单。MMLU 的时代确实过去了但它留下的方法论陷阱还在延续Agent 评测是更接近真实业务的新战场可它的水分一点也不比当年的学术榜单少。这篇文章就把我从 MMLU 一路测到 Agent 实战踩过的坑、沉淀下来的判断标准一次性整理清楚。不管你是想给团队挑模型、做 Agent 开发还是单纯想搞明白厂商发的第一通稿能不能信都可以拿这套方法去套。1. MMLU 的兴衰一个榜单如何从硬通货变成安慰剂1.1 MMLU 当年为什么能成为行业标准MMLU全称 Massive Multitask Language Understanding中文一般叫大规模多任务语言理解。它从 57 个学科里抽题目覆盖人文、历史、法律、医学、物理、计算机这些领域每道题都是四选一的选择题模型需要在没有额外上下文的情况下直接给出答案最终算一个平均正确率。这套设计在 2020-2021 年提出的时候可以说精准地打中了行业的两个痛点。第一个痛点是当时各家模型都在吹自己知识面广但没有人能给出一个可复现的横向度量。MMLU 的题源相对固定、评分逻辑简单答案对错一锤子买卖天然适合做排行榜。第二个痛点是它足够宽57 个学科意味着模型不能靠偏科刷高分必须在各个领域都有一致表现。所以 GPT-4 当年在 MMLU 上拿到 86.4% 的时候行业内确实把它当成一次智力水平的质变来讨论。对我这种做选型的人来说MMLU 早期还有一个实用价值它是免费的知识广度粗筛器。比如我需要判断一个开源模型在通用知识上大概什么水平跑一遍 MMLU 就能快速建立起对标感不用先把所有业务场景都过一遍。在模型能力普遍不高的年代这个粗筛器很有意义。1.2 饱和、污染与选择题的三个死穴可惜 MMLU 的好日子没过多久。到了 2026 年头部模型在 MMLU 上的分数已经普遍逼近甚至超过 92%大家之间的差距只有一两个百分点。这个一两个百分点的差距在统计上基本就是噪声级别模型生成的采样随机性、评测时的 prompt 格式差异、甚至 GPU 内核的浮点运算顺序都能造成这么大的波动。也就是说当两个模型都在 90 分以上的时候你拿 MMLU 去分高下其实是在抛硬币。更麻烦的是污染问题。MMLU 的题目是公开的早就是各家预训练语料里的常客。模型很可能不是学会了知识而是记住了答案。业内应对污染的手段其实很有限要么做 n-gram 重叠检测看训练语料里有没有和测试题高度重合的片段要么把测试集换成新出的私有变体。但这些方法只能缓解不能根治。因为厂商完全可以靠人工改写、翻译、摘要等方式把题目洗一遍后再塞进训练数据常规去重手段根本抓不到。除此之外选择题这个形式本身也有三个死穴。第一选择题给了模型排除法的机会四个选项里通常有两个是明显错误的干扰项模型不需要真正理解题目只要学会挑选最像正确答案的选项就能拿分。第二选择题没法测推理链条模型选了 B 但它为什么选 B、推理过程是否合理评分机制完全不关心。第三选择题的干扰项质量直接影响难度很多开源社区版本的 MMLU 干扰项翻译得稀烂导致题目难度被严重稀释。1.3 MMLU 在今天还能怎么用我的态度不是MMLU 已死彻底抛弃而是把它降级用。我现在把它当 smoke test也就是冒烟测试。换了新模型、改了微调数据、升级了推理框架之后先跑一遍 MMLU确认模型没有离谱退化、知识面没有明显坍缩这就够了。但是要拿它在两个旗鼓相当的模型里做最终裁决不好意思我不会用。另外一个经常被忽略的用法是把 MMLU 按学科拆开看而不是只看总分。比如 Agent 要处理法律文本那就单独看 MMLU 的法律子集分数要做医疗问答就看医学子集。总分的意义越来越小但子集分布还能给你一点线索告诉你这个模型的知识盲区大概在哪。这个思路也适用于后面讲到的所有评测千万别只看一个汇总数字。2. 学术基准的二代目更难、更专但一样能刷2.1 GPQA、SWE-bench 与新一代天花板测试MMLU 饱和之后学术界推出了一批更难的基准试图重新拉开模型之间的差距。这里面最典型的是 GPQA一个面向研究生水平的科学问答数据集。它的特点是题目由领域专家出题并标注了专家可验证的难度等级当年 GPT-4 也只能拿到 30% 多的准确率人类专家也不过 60% 多。刚出来的时候大家都觉得这下总算有个测不穿的基准了。结果呢到了 2026 年头部模型在 GPQA 的 Diamond 子集上已经能摸到 80% 以上。不是说题目变简单了而是模型确实在科学推理上进步了但另一个不可忽视的原因是GPQA 题量很小总共就几百道题这种小样本基准最容易被针对性补强——厂商只要在训练阶段多塞几道同风格的题分数立刻就能涨几个点。小样本、高难度、专家标注这三顶帽子戴上去的基准往往在两三年内就会重蹈 MMLU 的覆辙。代码领域的情况类似。HumanEval 是最早的函数级代码生成基准考查模型根据 docstring 写一个函数的正确率这个基准在 GPT-3.5 时代还有意义到了 2025 年头部模型已经逼近 96% 以上的通过率基本废了。现在大家更认 SWE-bench它直接让模型去改真实 GitHub 仓库里的 issue要完成从复现问题、定位代码、写补丁到通过测试的全过程。这个基准确实更难、更接近真实工程但它同样逃不过污染公开的 issue 文本和补丁随时可能进训练语料。我看到有些团队已经开始用 SWE-bench Verified 的私有版本做评估目的就是防泄漏。2.2 Chatbot Arena人工投票的双刃剑在学术基准饱和的同时Chatbot Arena 这类众包人工评测平台成了另一个话语权中心。它的玩法很直接随机挑两个模型匿名回复同一个问题让用户投票选出更好的一方再通过 ELO 算法算出排名。它测的不是单选题而是开放对话质量这在形式上确实更接近真实使用。但用多了你就会发现这个榜单有两面性。优点是它很难被直接刷你没法像背 MMLU 答案那样去 hack 用户的投票。缺点是它有严重的系统性偏差用户群体的构成不是均匀的编码问题多的时候代码能力强的模型就占便宜用户偏好某些话痨风格时模型就会被鼓励废话连篇而不是精准回答。还有一个很现实的问题叫品牌偏差虽然平台做了匿名化但老用户可以通过回答风格猜出模型身份一旦猜出来投票就变成了站队。所以我对 Chatbot Arena 的定位是市场热度温度计不是工程选型天平。它适合回答哪个模型在公众舆论里口碑更好不适合回答哪个模型更适合做我们的客服知识库。2.3 工具调用评测通向 Agent 的桥头堡在大模型学会输出文字之后下一步就是调用工具。工具调用评测的代表性基准是伯克利的 Berkeley Function Calling Leaderboard一般简称 BFCL。它把工具调用拆成多个维度简单函数调用、多函数选择、并行调用、参数类型匹配、错误处理等等。BFCL 的价值在于它是 Agent 评测的前置环节。你想想一个 Agent 无论多聪明第一步永远是正确地把用户的请求转成一个工具调用这一步错了后面所有规划都是空中楼阁。所以在选型阶段我会先用 BFCL 粗筛一遍模型的工具调用能力把那些连基础函数调用都频繁出错的模型直接淘汰。但 BFCL 也有天花板它只测单次调用的正确性不测多轮对话中调用的持续性。真实 Agent 场景里模型经常要连续调用五六个工具、根据中间结果修正下一步计划这种过程性能力在 BFCL 里几乎体现不出来。这就引出了更关键的问题我们真正该测的是 Agent 在任务里的端到端表现。3. Agent 评测从考答题到考办事3.1 为什么 Agent 评测成了 2026 年的主战场从前模型是聊天机器人做的是答题现在模型是数字员工做的是办事。企业用户根本不在乎一个 Agent 在百科知识上考了多少分他们在乎的是让它去处理一个退款工单它能不能正确调用支付系统、能不能在用户信息缺失时主动追问、能不能在调用失败后自动重试。这完全是另一套评价维度。我自己的感觉是2024 年到 2025 年Agent 评测还停留在demo 展示阶段厂商放几个视频证明我的 Agent 能订机票、能写代码到了 2026 年大家已经开始认真讨论召回率、任务完成率、单任务成本、安全违规次数这些工程指标了。这说明 Agent 评测正在从讲故事转向做度量。但度量的口径五花八门同一个 Agent这家测出来 95% 完成率那家测出来 60%中间差的往往不是模型能力而是评测设计。3.2 主流 Agent 基准的成色目前国际上比较有代表性的 Agent 评测基准有这么几个。GAIA全称 General AI Assistants它设计了一批需要多步推理、结合工具、处理多模态信息的现实任务比如根据某份 PDF 里的表格回答一个问题并交叉对比另一个网页的数据。GAIA 的题目质量高但样本量极小总共只有几百道题而且题面常常包含真实网页链接这类活数据基准最大的问题是时效性链接改了、网页关了测试就失效了。AgentBench 是另一个常被引用的基准它把模型放进操作系统、数据库、知识图谱、游戏等八个环境里执行指令。它的优点是环境多样能测出模型的通用任务执行能力缺点是模拟环境毕竟是模拟的真实系统的报错、网络延迟、权限问题它都覆盖不到。tau-bench 则走了一条更务实的路它模拟的是零售和航空两个行业的客服对话场景用户、Agent、工具三方交互评测时既要看任务是否完成还要看对话是否自然。tau-bench 是我个人比较认可的方向因为它把办事和对话放在了一起测更贴近真实业务。但不管哪个基准都逃不过三个硬伤样本量小、环境固定、公开集易污染。所以我的原则是这些基准的结果可以参考但绝不能照单全收。真正决定要不要上生产的是在你自己的业务数据上跑出来的成绩。3.3 一个值得拆解的案例代码检视智能体怎么测我最近看到的一个企业级案例特别典型——某个代码检视修复的智能体对外公布了召回率 91.3% 的成绩。这个数字听着很好看但你要是仔细拆解它的评测方法就会发现里面藏着一整套完整的方法论。它做的事情是给定一个代码仓库和一个待检视的变更Agent 要找出里面潜在的缺陷并尝试修复。评测时团队先准备了一批已知含缺陷的代码变更作为标注集由专家预先标出所有真实缺陷的位置和类型。然后让 Agent 跑一遍计算它成功定位并修复的缺陷占全部已知缺陷的比例这就是召回率 91.3% 的来源。这个评测里有三个细节值得学习。第一它没有用完成率这种模糊指标而是用缺陷检出率这种业务可理解的指标管理层一听就知道 Agent 能发现多少真实问题。第二它同时会报误报率也就是 Agent 标记为缺陷但实际不是缺陷的比例。只看召回率不看误报率Agent 就会走向宁可错杀一千的极端在真实开发流程里反而增加人工负担。第三它把成本也摆上台面——跑一个变更平均消耗多少 token、多少时间这是企业上生产时必然要算的一笔账。这个案例给我的启发是Agent 评测的门面指标可以很漂亮但真正有用的评测报告一定是由任务定义 指标设计 成本核算三个部分组成。缺了任何一个那个数字都只是个营销素材。3.4 Agent 评测的四个经典陷阱第一完成率被神化。一个五步任务Agent 做对了四步、最后一步失败这算完成还是算失败很多评测直接粗暴地标记为失败导致模型能力被低估。更合理的做法是引入部分完成度的加权评分或者干脆按关键步骤是否完成来判定。第二评测环境与生产环境脱节。模拟环境里一切正常真实环境里网络超时、接口返回格式变化、第三方系统报错Agent 瞬间就不会玩了。我在评测时一定会做故障注入故意让某个工具调用失败看 Agent 能不能自己绕过去。第三奖励函数太过简化。如果你只按最终结果对错给分Agent 就会学会投机取巧比如遇到困难任务直接胡编一个答案。好的 Agent 评测应该拆分成规划质量、接地质量、恢复能力几个子维度分别打分。第四完全忽略成本。更强的模型往往意味着更高的 token 消耗。两个 Agent 完成任务率相同一个花钱是另一个的十倍选哪个答案不一定但这必须成为评测报告里的一个显性维度而不是被藏起来的秘密。4. 实操搭一条属于你自己的评测流水线4.1 第一步明确问题类型选择评测范式很多团队评测失败不是因为指标不够高级而是因为一开始就没想清楚自己在测什么。我习惯把评测需求分成三类。如果是封闭式问题也就是答案非对即错的那种比如选择题、代码输出、SQL 生成直接用自动指标对比最省事也最客观。如果是开放式问题比如文案写作、方案摘要、情感分析自动指标很难覆盖质量就需要规则 LLM-as-Judge 人工抽检三层结合。如果是 Agent 类任务那就得跑端到端记录任务完成率、关键步骤成功率、工具调用正确率、成本和安全违规次数这些指标缺一不可。三类问题对应三种范式最忌讳的就是拿评测开放问题的思路去测 Agent最后测出来的结果既浪费钱又没有参考价值。4.2 第二步构建黄金测试集质量和数量怎么平衡黄金测试集是整个评测的地基。我的经验是每个核心场景准备 30 到 50 条用例就够用了真不需要动辄上千条。关键在于覆盖度正常情况要有边界情况要有异常输入要有。举个例子你在做一个客服 Agent 评测用例集里不能只有用户正常问退款流程这类顺风题还得有用户连续追问三次用户提供的信息前后矛盾用户直接开骂用户要求违规操作这些逆风题。Agent 的差距恰恰是在逆风环境下拉开的。每条用例都要由领域专家写清楚标准答案和评分要点这一步偷懒后面所有指标都是空中楼阁。另外黄金测试集要定期轮换至少每季度清理一次把模型可能见过的题目替换掉防止污染悄悄渗进你的评测基准。4.3 落地工具推荐用 deepeval 这类框架把评测跑起来有了测试集下一步就是把它工程化。手工拿着 prompt 一条条去试在模型快速迭代期根本不可维护。我自己现在常用的是 deepeval 这个开源评测框架它提供了一套结构化的测试定义方式可以和 pytest 生态无缝集成。下面这段代码是我实际项目里用的一个最小示例import pytest from deepeval import assert_test from deepeval.test_case import LLMTestCase from deepeval.metrics import AnswerRelevancyMetric, ToolCorrectnessMetric def test_customer_service_agent(): test_case LLMTestCase( input用户想取消昨天晚上下的订单并申请退款。, actual_outputrun_agent(取消订单并退款), expected_tools[order_cancel, refund_create], expected_output订单已取消退款已提交。 ) assert_test( test_case, metrics[ AnswerRelevancyMetric(threshold0.7), ToolCorrectnessMetric(threshold0.8) ] )这个例子里我用了两个指标AnswerRelevancyMetric 检查回答和问题是否相关ToolCorrectnessMetric 检查 Agent 调用的工具链是否正确。跑起来之后每次模型更新或提示词调整只要执行 pytest就能立刻看到哪些用例回归了、哪些用例进步了。关键心得是评测代码必须和模型代码放在同一个仓库里独立管理这样每次发版前的回归测试才不会被人遗忘。4.4 第三步把评测变成 CI 的一环而不是一次性工程很多团队的评测是选型时跑一次上线前跑一次跑完就丢到一边。这可太浪费了。模型一升级、提示词一调整、工具接口一变之前的评测结果就全部失效。正确的做法是把评测嵌进持续集成流程。模型每次更新都自动跑一遍黄金测试集如果有分数回退就拦截发布。线上流量要按一定比例抽样每日或每周做一次影子评测拿真实请求去验证 Agent 表现。对 LLM-as-Judge 打分结果有争议的用例要自动标记出来让人类复核人工和机器协同评分。评测运行的 token 成本也要单独记账因为评测本身就是一项持续的成本投入不记账你就不知道自己到底为放心花了多少钱。5. 榜单信誉判断手册一个从业者的信度模型5.1 我看一个榜单先问五个问题每次厂商发来一张漂亮的海报我都不看结论先看方法。五个问题只要有一个答不清这个榜单的价值就打五折。第一个问题测试集是否公开、如何防污染如果测试集是公开下载的且没有给出任何污染检测方案那我默认分数有水分。第二个问题运行配置是否可复现采样温度是多少、生成了几次取最优还是取平均、用的什么解码参数这些细节不写清楚分数就没法复核。第三个问题评测代码是否开源我自己能不能独立跑一遍验证第四个问题样本量是多少、误差线有没有标只有几百道题的榜单几个样本波动就会改变排名。第五个问题发布方和被测模型有没有利益关系自己发布模型又自己发布评测夺冠通稿的至少要打五折再看。5.2 污染检测的一些技术细节防污染听起来是个概念落到技术上其实有几种可以用起来的手段。最基础的是 n-gram 重叠检测把测试题里的 8-gram 和 9-gram 片段拿去跟训练语料比对出现高频重合就要警惕。进阶一点的是嵌入向量相似度检测用模型把测试题和语料都编码成向量计算语义相似度语义级别的洗稿靠 n-gram 抓不到但向量相似度能筛出来。更硬核的做法是在测试集里埋 canary 哨兵题比如随机字符串加特殊格式的问题如果模型在这些绝不该见过的题上得分异常高那基本可以断定数据泄漏了。商业闭源模型你没法查它的训练语料但可以观察它的时间线合理性一个宣称数据截止到去年 6 月的模型如果对今年 3 月才发布的学术论文细节非常熟悉那要么是它实时检索了要么是数据截止日期说了谎要么就是评测题泄露了。查数据截止时间是普通人也能用的最简单的污染侦探法。5.3 哪些结论我信哪些我打折我自己形成了一个很实用的打折规则模型之间在私有任务集上的相对排序我比较信因为私有任务至少没有公开污染的问题而且任务跟我的业务对齐公开排行榜上的绝对分数我只参考不信因为绝对分数受污染、评测格式、解码参数影响太大相差不到 2 个百分点的名次差异我一律视为平局至于人类平手AGI 时刻这类评价性结论直接过滤。另外如果你有条件最靠谱的办法是亲自做匿名 A/B 测试。把两个模型的名字都藏起来同一批 prompt 各跑一遍让团队里不知道模型身份的人打分。品牌、口碑、先发印象这些噪声在匿名 A/B 面前全部失效测出来的结果才真正反映能力。6. 常见问题与排查心得6.1 为什么评测结果每次跑都不一样很多团队的自动化评测跑出来不稳定今天模型 A 赢明天模型 B 赢代码又没改过于是怀疑评测工具坏掉了。其实绝大多数情况下是三类原因模型解码的随机性、并行请求的乱序、以及浮点计算在 GPU 上的微小差异。排查时先把采样温度固定到 0再用固定 seed 和固定 batch 大小重跑如果还不稳就把样本量加大靠统计平均抹平波动。评测追求的不是完全复现而是在可接受的置信区间内稳定。6.2 为什么我的测试集上分数低官方排行榜却很高这是被问得最多的一个问题。答案通常出在 prompt 上官方评测有精心调过的 system prompt、few-shot 示例和答案抽取逻辑你本地只塞了一句请回答就把模型扔上去测分数当然差一截。我踩过几次之后现在把评测代码里的 prompt 单独抽成配置文件任何一次评测都严格记录用了什么格式、什么示例保证结果可以被审计和复现。评测不只是一堆分数它是 prompt 模型 解码参数 评分逻辑的整体结果任何一个环节不同分数都不可比。6.3 为什么 LLM-as-Judge 老是把差的模型判成高分用大模型当裁判确实效率高但它有严重的系统性偏见位置偏见喜欢给后面的答案更差分或更高分、长度偏见偏爱更长的输出、以及自我偏好和自己同源的模型被悄悄加分。我的排查手段有三个一是对调两个答案的展示顺序多跑几遍看分数是否跟着位置走二是给裁判模型设定明确的打分 rubrics强制它逐项打分而不是给一个笼统印象分三是拿一批已知答案的人类标注结果做校准如果裁判模型跟人类标注的一致率低于 85%就说明裁判设计有问题需要重做 prompt 或换一个更强的裁判模型。6.4 避坑清单速查表在项目组内部我常用下面这个速查表拿去就能用场景最常见的坑建议做法MMLU 类学术基准90 分以上还在分高下只做冒烟测试不看细粒度排名代码评测只看通过率忽略测试覆盖结合私有测试集和 SWE-bench 类任务开放问答只看 LLM-as-Judge 分数引入人工抽检和双向顺序校准Agent 完成率0/1 一刀切判定拆分部分完成度、关键步骤加权成本维度只测效果不测开销每次评测同步记录 token 与耗时数据污染测试集长期不变定期轮换用例 埋哨兵题检测关于榜单和评测这件事我在实际工作中最终沉淀出的态度是不要神化任何单一榜单也不要全盘否定所有榜单。MMLU 教会了我们可复现的度量有多重要Agent 评测正在教会我们贴近业务的指标有多稀缺。你永远不可能找到一个完美的、永不被 hack 的公开评测但你完全可以通过自建黄金测试集、把评测嵌进 CI、坚持人工抽检和三方交叉验证建立起属于自己团队的一套可信体系。这才是评测这件事真正的意义——不是为了在排行榜上争第一而是为了让你在做每一个技术决策的时候手上有足够可信的信息。