企业官网建设流程全解析

这两年做模型评测，圈子里的一个共识是：数字好看已经不能说明任何问题了。今天一个模型在 MMLU 上刷了 90 分，明天另一个模型在 BIG-bench Hard 上又刷新了纪录，后天还有模型在 HELM 的某个场景矩阵里拿到新 SOTA。榜单越来越热闹，可很多人其实没想清楚一个问题——这些 benchmark 到底各自在测什么？为什么同一个模型，换个基准排名就完全倒挂？这篇内容，我准备把 MMLU、BIG-bench、HELM 这三个主流评估体系放在一起，从设计思路、指标含义到实际使用中的坑，逐一拆开讲清楚。适合正在做模型技术调研的人、准备写技术报告的研究同学，以及所有想要看懂大模型评测数据的读者。这算是我自己这几年踩坑之后的一份评估体系使用笔记，不一定全面，但保证都是实测经验。

1. 评估体系全景：为什么不能只盯一个分数

1.1 评估的本质是行为采样

先聊一个最容易被忽略的问题：大模型的能力是观察不到的，你只能通过它在特定任务上的输出来推断。这就像你没法直接“看见”一个人会不会游泳，只能让他下水游一圈。而所谓下水游一圈，就是评估。

正因为这种间接性，任何评估体系都存在三个先天约束。第一，样本有限。一个 MMLU 只有一万多道题，你拿它去推断模型在真实世界里的全部知识面，本身就存在误差。第二，任务形态单一。选择题和开放式问答、多轮对话、工具调用，考察的是完全不同的能力维度。第三，训练集污染无法彻底规避。预训练数据规模动辄十几万亿 token，谁也不能保证 benchmark 题目绝对没被模型“背”过。这三个约束决定了任何单一分数，哪怕是 90 分，也只能说明“模型在这一批题、这种问法、这套选项下表现不错”，不能外推到一切场景。

1.2 评估体系的三个基础维度

我自己的习惯，是把评估需求拆成三个维度来看：知识广度、推理深度、场景生态。

知识广度看的是模型“知道多少”，典型代表是 MMLU 这种多学科选择题，覆盖历史、法律、计算机、医学等几十个学科。推理深度看的是模型“能不能想明白”，典型代表是 BIG-bench Hard 里的那些反直觉任务，比如需要多步逻辑推断、反事实推理的题目。场景生态看的是模型“在真实任务里好不好用”，典型代表是 HELM 那种把模型放到多个场景里、同时测多个指标的做法，比如新闻摘要、问答、信息抽取，每个场景都看准确率、鲁棒性、校准度。

这三个维度不是并列关系，而是递进关系。知识广度是底座，没有常识性知识，推理无从谈起；推理深度是核心，决定模型上限；场景生态是终点，最终要落到产品里。做评估规划时，我会建议至少覆盖两个维度，如果只有一个维度的预算，优先选场景生态，因为离真实使用最近。

1.3 数字时代的三个典型误区

我见过很多人在评估上栽跟头，基本逃不出这三个误区。

第一个误区是“唯分数论”。看到某个报告里 MMLU 高 0.5 个点，就认为模型整体更强。实际上 0.5 个点在 MMLU 上可能只是几道题的差距，而这几道题恰好是模型见过的。第二个误区是“跨榜对比”。不同 benchmark 的题目难度、评估方式、prompt 模板都不一样，A 模型在 MMLU 上比 B 模型高，和 B 模型在 HELM 的某场景上比 A 模型高，这两个结论完全可以同时成立，且不矛盾。第三个误区是“拿学术指标当产品指标”。MMLU 高不代表你的客服机器人能答好用户问题，因为真实对话里没有“四选一”，只有开放式的、带噪声的、上下文可能不完整的提问。

2. MMLU 拆解：含金量和软肋都在哪里

2.1 它到底是什么

MMLU（Massive Multitask Language Understanding）是当前被引用最多的通用知识评估基准之一。它包含 57 个学科、约 1.4 万道选择题，覆盖从人文、社科到 STEM 的多个领域。设计上是 few-shot 评估：给模型几个示例，再让模型回答新问题，满分 100 分。

这里有个关键点：MMLU 的初衷是测“知识覆盖面”，不是测“最高推理能力”。它的大多数题目，是一个受过良好教育的人凭借知识储备能直接选对的，而不是需要深度推导才能做出来的。这也是为什么很多模型在 MMLU 上的分数会远高于在 BIG-bench Hard 上的分数——因为两套基准对能力的侧重完全不同。

2.2 分数怎么读才不算浪费

我见过太多人只看 MMLU 的总分，这实际上浪费了这套基准最有价值的部分——分科成绩。57 个学科里，模型的表现往往极其不均衡。我实测过一个 7B 量级的开源模型，总分离 70 不远，很体面，但拆开看，它在“临床知识”上能到 80 分，在“形式逻辑”上只有 55 分。这个分科差异能直接告诉你这个模型的训练数据长什么样，以及它在哪些领域属于“背诵型”能力。所以读报告时不要只看总分，要去看分科矩阵。

另外要留意一个小细节：报告分数时，很多文章没有说明是 macro average 还是 micro average。MMLU 默认的官方分数是 macro average，也就是 57 个学科各自算准确率后取平均。对于学科样本量不一致的情况，micro average 会更偏向样本量大的学科，两个数值会差出 1 到 2 个点。如果对比不同家的模型报告，必须先确认两边用的是同一种平均方式。

2.3 实测跑分的几个关键设置

跑 MMLU 时有几个参数直接决定分数，不固定下来复现性会很差。

第一个是 temperature。正式评估通常设成 0，因为我们需要的是确定性的、可复现的答案。凡是报告里没写 temperature 的，我基本默认它不可复现。第二个是 few-shot 的 shot 数和样例选择。官方通常用 5-shot，但少数模型对示例顺序很敏感，同一个示例集合换个顺序，成绩能差 1 到 3 分。建议固定一个随机种子，并把示例顺序写进报告附录。第三个是 prompt 模板。不同模板对模型的影响极大，我实测过同一个模型，用“Question: … A/B/C/D”和用“请回答下列问题”的英文模板，成绩能差出 3 个点以上。

这里还有一个容易被忽视的坑：选项顺序。模型可能对特定的选项排列产生位置偏好，比如倾向于选 A 或 D。严谨的评估应该对选项做 shuffle，或者至少报告原始顺序下的结果并注明。如果只是想快速对比两个模型，固定同一套顺序问题不大，但如果你想给研发团队提优化建议，shuffle 之后能暴露出不少模型对“选项位置”的过拟合现象。

2.4 MMLU 的软肋

聊完好的，说两个绕不开的问题。

第一个是量程饱和。MMLU 的题目难度天花板有限，近年来的头部模型已经逼近 90 分大关，再往上提升的空间很小，区分度急剧下降。换句话说，两个模型一个 88 分一个 90 分，你很难说后者真的“更聪明”。这也是 MMLU-Pro、GPQA 这类更难基准出现的原因。第二个是污染问题。预训练数据可能已经包含大量 benchmark 题目，模型在训练阶段“见过”答案，就等于开卷考试。检测污染的方法很多，但最有效的还是控制变量——拿一份与公开题同分布的、新出的私有题去测，对比分数差。我自己团队现在评估新模型时，MMLU 只作为“副作用最小”的基线存在，真正做决策要靠后续要讲的其他基准和业务集。

3. BIG-bench：压力测试的逻辑和用法

3.1 协作式基准的独特基因

BIG-bench 和 MMLU 的诞生背景完全不同。它是一个大规模协作的 benchmark，由数百个任务组成，涵盖逻辑推理、数学、常识、多语种理解、代码生成、反事实推理等。它的设计理念不是“模拟考试”，而是“压力测试”——专门挑那些模型容易翻车的、对人类来说却很简单的任务，用一个个小任务去试探模型的能力边界。有些任务非常冷门，比如识别语义陷阱、推断奇怪的因果链条，你甚至会觉得这些题不像正经考题，但正是这种“不正常”才有区分度。

3.2 为什么说 BBH 比全量 BIG-bench 更实用

全量 BIG-bench 有几百个任务，测一轮的成本和解释成本都很高，而且大量任务模型已经能拿高分，区分度不高。所以后来社区从里面挑出了 23 个相对困难的任务，组成了 BIG-bench Hard（BBH）。我的建议是：日常评估直接用 BBH 就够，而且建议使用 chain-of-thought（CoT，即思维链）模式去测，少数任务还要配上 few-shot 示例。因为直接让模型作答，很多推理类型的问题它根本无从下手，而显式要求它“一步一步思考”后，分数会显著提升。

在 BBH 里，我最看重的子集是因果判断、逻辑谬误识别、多步算术和反事实推理这四类。它们在区分“知识型模型”和“推理型模型”上非常灵敏。举个例子，我测过一个开源模型，它有很不错的 MMLU 分数，知识储备看着很扎实，但一到 BBH 的反事实推理子集就只有 40 多分——明显是训练数据里多见结论、少见推导路径。

3.3 BBH 实测里的关键细节

跑 BBH 时，有个细节比 MMLU 更讲究：prompt 的 CoT 指令。官方和社区流传的 BBH prompt 模板很多，不同模板对分数的影响巨大。我的做法是固定使用官方发布的带 CoT 示例模板，不做任何改写，并把模板字符串直接附在评估报告里。另外，BBH 的输出解析比 MMLU 麻烦。很多任务不是简单的 ABCD，而是需要模型生成一段文字再从中抽取最终答案。这里必须写一套可靠的解析器，否则模型明明答对了，解析没抽出来，分数白白丢掉。我建议解析时采用容错策略：先按格式匹配最终答案，匹配不到就回退到全文字符串匹配关键结论，再不行才判错。

还有一个实操心得是，BBH 对量化模型特别敏感。我做过一组实验：同一个模型跑 FP16 和 INT4 量化，MMLU 只掉了 0.7 分，但 BBH 掉了 5 分以上。这说明量化的损失主要集中在推理链路的高层能力上，而不是表层知识记忆上。如果你的产品打算上量化版本，BBH 是一个非常好的回归测试集，比 MMLU 灵敏得多。

3.4 BBH 的局限性

BBH 也不是万能的。第一，它的语言负载很高，很多任务是英文语境下设计的，翻译成中文后会失真，直接用中文模型测英文版 BBH，会低估模型真实的推理能力。如果要做中文评估，建议自己构建或寻找社区维护的中文推理题集。第二，BBH 的题目偏向“单轮推理”，基本不涉及多轮对话、上下文管理和工具调用。模型在一个复杂客服对话里能不能保持逻辑一致，BBH 完全测不出来。第三，BBH 的分数对 CoT 示例的质量很敏感，示例写得不好，模型会被带到沟里去——这一点很多人没意识到。

4. HELM：多场景多指标的“照妖镜”

4.1 它不是单一榜单，而是一套评估框架

HELM（Holistic Evaluation of Language Models）的思路和 MMLU、BIG-bench 完全不同。HELM 不追求设计新的难题，而是把模型放进一组标准化的场景（scenarios）里，每个场景再用一组标准化指标（metrics）去度量。简单说，MMLU 给你一个分数，HELM 给你一张表：某个场景下准确率多少、鲁棒性多少、校准度多少、公平性表现如何。

这种被社区称为“评分矩阵”的设计，好处是你能直接看到模型在不同任务形态下的差异。比如一个模型可能在“情感分析”场景里准确率很高，但在“问答”场景里校准度很差，意思是它答对的时候语气很自信，答错了也一样自信，这种“过度自信”的问题在单指标基准里几乎看不到。

4.2 为什么我要强调“校准度”

校准度这个概念，在真实业务里价值极高。举一个直觉化的例子：你做一个智能客服，用户的提问模型大概率能答对七成，但剩下三成它会在不确定时给你编一个看似合理的答案，而且语气非常肯定。这种模型上线之后，用户体验是灾难性的。校准度衡量的正是“模型预测的置信度和实际正确率之间的匹配程度”。HELM 提供了一组标准化的置信度评估方法，不需要自己额外设计，跑完场景就能看到。

我强烈建议任何准备把模型用到产品里的人，至少在 HELM 的某一两个核心场景上跑一次校准度指标。很多团队在模型选型时只对比 accuracy，上线后才发现“答错时还挺确定”的问题，这时候再换模型代价已经很大了。

4.3 实操中的选场与成本控制

HELM 的场景非常多，不是每个场景都值得跑。我的经验是：先明确用途，再选 3 到 5 个核心场景。比如我做文本分类任务，就会选“情感分析”“主题分类”类场景；做问答产品，就选“短问答”“长问答”类场景。如果只是想做一次通用能力摸底，选“自然语言推理 + 摘要 + 问答”三个场景基本就够了。

HELM 最大的缺点是评估成本高。全量跑完几十个场景，按当前的 API 调用成本，可能会是一笔不小的开销。所以我通常用抽样跑：每个场景抽固定的样本量，比如 200 到 500 条，记录在本地的快照里，然后用 HELM 提供的工具算出指标。抽样后分数会有波动，但用于横向比较模型之间的相对高低，问题不大。关键是让所有待评估模型用同一批抽样样本和同一个 prompt 模板，这样才能保证公平。

4.4 HELM与MMLU、BIG-bench的位置关系

把三者放一起看，我的定位是：MMLU 是“体检”，查知识储备；BIG-bench/BBH 是“压力测试”，查推理上限；HELM 是“试岗”，查真实任务上的综合表现。三个体系解决的是不同问题，不是替代关系。

我见过不少团队试图只用其中一个基准完成模型选型，基本都会踩坑。只看 MMLU，你可能会选到一个知识广但推理弱的模型；只看 BBH，你可能会忽视模型在实际业务场景中的校准问题；只看 HELM，你又很难快速判断模型的基础知识广度。现实中正确的姿势是组合使用。

5. 一场实战复盘：我如何组合使用这套体系

5.1 背景：一个客服对话模型的项目评估

去年我们团队做了一个面向特定业务领域的客服对话模型，目标是提升意图识别准确率、情感判断能力和长文档摘要质量。当时团队里对“怎么评估这个模型好不好”争论很大。研发同学的直觉是多跑几个知名基准，产品同学则关心真实用户体验。最后我牵头设计了一套“业务集 + 基准组合”的评估方案。

方案分三层。第一层是业务集：从真实客服对话里脱敏抽了 1200 条样本，覆盖高频意图和典型槽点，标注了标准答案，这是最重的一层。第二层是通用基准：MMLU 全量分数作为知识基线，BBH 选 8 个推理子集作为推理基线。第三层是场景化评估：参考 HELM 的思路，自建了 3 个与业务更贴近的场景，每个场景配准确率、鲁棒性和校准度三个指标。

5.2 评估结果的意外发现

跑完数据之后，有一个发现让我印象很深：两个待选模型 A 和 B，A 在 MMLU 上比 B 高 2 分，大家一度准备直接选 A。但业务集上 B 的意图识别准确率比 A 高 5 个百分点，情感判断的校准度也明显更好。再回头看 BBH，A 在推理任务上虽然总分略高，但在“反事实推理”这个子集上不如 B。最终我们选了 B。上线之后真实对话数据复盘，B 的转人工率、错误意图率都优于 A，证明当初的评估组合起了作用。

这件事给我的教训是：MMLU 这种“知识广度题”很难预测“业务场景中的行为”，而 BBH 对推理分项的解读又比总分更重要，HELM 式的场景指标则最接近产品体验。单看任何一个基准，我们都做了错误决策。

5.3 可复现的评估报告模板

为了团队内部复现，我把评估报告固定成了下面这样的模板。每次跑完，把 slug 填好，数字基本不会有什么歧义。

这个模板的规则是：所有模型用完全相同的 prompt、完全相同的采样参数、完全相同的样本顺序，并把随机种子写进附录。哪怕以后模型版本更新，老报告的复现度也有保障。

6. 基准会老化：从 MMLU 到 MMLU-Pro 的量程迭代

6.1 为何老基准会“失灵”

一个不怎么被提起但非常重要的事实：评估基准是有生命周期的。模型在某个基准上拿到 80 分以后，再往上提升，难度越来越大，分数的信息量却越来越小。当头部模型在某个基准上超过了人类专家的平均分，这个基准基本就“死了”——它不再能区分模型的相对强弱。

这也是为什么社区里不断出现新基准。MMLU-Pro 把原先的题量做了精简但提升难度，选项从 4 个增加到 10 个，并且增加了更多干扰项；GPQA 这类基准则直接用研究生级别的问答题去压榨模型。它们是对老基准量程饱和的一种回应。

6.2 排行榜通胀的应对方法

基准寿命变短，带来一个直接后果：你在网上看到的榜单，可能反映的是“数据被记住的能力”，而不是“泛化能力”。去年某个模型在 MMLU-Pro 上表现一般，却在老版 MMLU 上表现极好，十有八九是预训练数据里“老题”的比例太高。

我自己应对这个问题的办法，是坚持“三件套”组合：一个最新基准看上限，一个经典基准看基线，一个业务集看真实表现。最新基准往往还没被大规模污染，能看出模型的真实泛化能力；经典基准方便和其他报告对标；业务集则是最终决策依据。三者缺一不可。

6.3 说给新手的建议

如果你刚入坑这个领域，我的建议是不要试图追踪所有新基准。先把手上的经典基准吃透，搞清楚它们的指标设计、量程上限、污染风险，再根据业务需求选一到两个新基准做增量验证。评估体系的核心目标永远不是“分数好看”，而是“可信地推断模型在目标场景中的表现”。基准只是工具，不要被工具绑架。

7. 常见问题速查表：评估中的 8 个坑

最后整理一份实战中高频遇到的问题和排查方案，都是我自己踩过后验证有效的。

这 8 个坑，前四个我自己全踩过。最典型的是刚做评估那会儿，只跑 MMLU，没有固定 prompt 模板，模型评估脚本换了一个人维护之后，分数莫名掉了 3 分，排查了半天才发现是模板变了。从那之后，我在团队里立了一条规矩：评估代码和 prompt 一律入库，版本变更必须走 review，任何数字要能直接追溯到脚本和模板。

如果你现在正要搭一套模型评估方案，我的建议顺序是：先建业务集，再选两到三个差异化的公开基准，最后用 HELM 式的场景指标补校准和鲁棒性视角。预算再多一点，可以加一个最新基准去对冲污染风险。每跑完一轮，把样本、配置、分数全部存档。我个人的经验是，这样跑出来的评估结论，在研发和产品两边都站得住脚，也比单纯追榜单扎实得多。