大模型评测指南：从MMLU到Agent，榜单该怎么读、测试怎么做

这几年被问得最多的一个问题就是："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_output=run_agent("取消订单并退款"), expected_tools=["order_cancel", "refund_create"], expected_output="订单已取消，退款已提交。" ) assert_test( test_case, metrics=[ AnswerRelevancyMetric(threshold=0.7), ToolCorrectnessMetric(threshold=0.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 教会了我们"可复现的度量"有多重要，Agent 评测正在教会我们"贴近业务的指标"有多稀缺。你永远不可能找到一个完美的、永不被 hack 的公开评测，但你完全可以通过自建黄金测试集、把评测嵌进 CI、坚持人工抽检和三方交叉验证，建立起属于自己团队的一套可信体系。这才是评测这件事真正的意义——不是为了在排行榜上争第一，而是为了让你在做每一个技术决策的时候，手上有足够可信的信息。