大模型评测这事乍一听像是研究者的专利但实际上只要你想判断哪个模型更聪明背后都绕不开一套固定的考试制度先准备题库Dataset再定评分规则Rubric最后统计得分Metric。这三件事合起来就是我们常说的 Benchmark。我自己常年拿各种模型跑性能对比发现真正把这条链路摸透的人不多绝大多数时候大家对着一张榜单只知道谁高谁低却不知道那个分数是怎么算出来的、里面埋了多少坑。这篇文章就用一张考试图的思路把大模型从出题到放榜的整个过程掰开揉碎讲清楚帮你看懂榜单也帮你学会自己动手给模型打分。1. 大模型考试的全貌从出题到放榜的一整条流水线1.1 为什么大模型需要一场标准化考试大模型不像传统软件你没法跑几个单元测试就说它运行正常。一个模型能聊天、能写诗、能解数学题、能写代码但它到底行不行行到什么程度没有统一标尺就没法横向比较。这就是 Benchmark 存在的根本逻辑把模型很强这种主观感受变成一组可以量化、可以复现、可以对比的数字。想象学校里的期末考试。老师不可能靠平时印象随便打分得出一套题每人发一张卷子规定每题几分最后统一阅卷。大模型的 Benchmark 就是同一套机制。题目是 Dataset阅卷规则是 Rubric分数统计是 Metric。任何一份榜单本质上就是一场标准化考试的放榜。理解了这场考试是怎么组织的你就能把一个高的分数拆解成它是在什么题库上、按什么评分细则、用什么统计方法得出来的从而判断这个分数对你当前场景有多少参考价值。1.2 整条流水线的四个环节大模型评测不是喂题、收卷这么简单完整流程可以拆成四个环节样本准备从语料里挑选或人工构造一批有代表性的问题形成一个结构化的数据集。推断生成把题目发给待测模型让它在规定的设置下比如温度、上下文长度、few-shot 示例数量产生答案。答案评分按照事先定义好的 Rubric把模型输出判定为对、错、部分对或一个质量分数。分数聚合把所有题目的结果汇总成一个或多个 Metric比如准确率、F1、胜率、Elo 分等最终体现在榜单上。这四个环节任何一个出了偏差最后的分数都会失真。很多人在做模型选型时只瞄一眼总排名却没想过排名的分母和分子是怎么来的于是在自己的业务场景里用起来效果很差还反过来怀疑模型有问题。事实绝大多数时候不是模型不行而是榜单分数和你的任务根本不匹配或者榜单里的分数本身就已经被污染了。1.3 一张图把流程串起来用文字画一张最简版考试流程图你存脑子里就够了题库Dataset→ 答题模型推理→ 阅卷Rubric→ 统计Metric→ 榜单Leaderboard值得强调的是这四个步骤之间存在强耦合。题库的难度分布决定了分数的意义Rubric 的宽容度决定了模型怎么答才能算对Metric 的聚合方式决定了你在榜单上看到的排名。所以接下来的每一节我都会抓住一个环节把里面的门道和外行人容易忽略的细节展开讲。2. Dataset 环节题库质量直接决定考试有没有效2.1 一份合格的题库需要过三关Dataset 是 Benchmark 的地基。如果一个题库本身就有问题后面再精妙的评分和统计都是空中楼阁。我判断一个数据集能不能用一般看三个维度覆盖度题目是否覆盖了你关心的能力维度。比如考察数学能力题目就要覆盖算术、代数、几何、概率等考察逻辑推理就要有演绎、归纳、类比等类型。覆盖太窄的题库只会测出模型某方面很专其他方面完全看不出来。区分度好题要能把不同水平的模型拉开差距。如果一份考卷大家全都接近满分或者全都零分那这个考试几乎没有信息量。理想情况下最强模型和中游模型之间要有显著分差才能起到筛选作用。新鲜度这份题库是否可能已经出现在模型的训练数据里。这是目前 AI 评测领域最头疼的问题也是数据污染的最主要来源。后面我会专门说这个坑。2.2 从 MMLU 到 HumanEval几种经典题库的脾气市面上常见的 Benchmark 题库其实各有各的脾气。我挑几个最有代表性的给你讲讲它们的设计思路和试用边界。MMLU全称 Massive Multitask Language Understanding包含 57 个学科、约 1.4 万个选择题。题目覆盖人文、科学、法律等考察的是模型的知识广度和记忆能力。它的优点是覆盖面极广缺点恰恰是太依赖记忆——一个大模型只要背过足够多的百科条目分数就可以被推得非常高。所以 MMLU 高分不能说明模型推理能力强只能说明它的世界知识储备足够厚。HumanEval这是代码生成评测里绕不开的数据集包含 164 道手写 Python 编程题。每题给一个函数签名和 docstring模型要补全函数体。评分方式是跑单元测试能通过测试就算对。它的优点是判定客观不依赖人工缺点是题库太小只有 164 道很容易被刷高——模型在训练集里混进了这几道题就可以拿满分。GSM8K包含 8500 道小学数学应用题考察数学推理链。它的特点是题目本身不算难但它要求模型一步步把推理过程写出来。这是Chain of Thought思维链技术最常出没的战场。评测 GSMA8K 时如果只给答案不给过程很多模型分数会明显下降所以在评测规范里通常要求模型输出完整的推理步骤。2.3 出题人的隐藏偏好选择题、开放题与对抗性这里我要提醒你一个容易忽略的事实题库的出题形式本身就在影响最终分数。选择题MMLU 那类可以让判分非常机械模型只需要输出一个字母但选择题天然存在 25% 的猜测概率而且选项的顺序可能诱导模型。开放生成题比如让模型写一段摘要或翻译几句话更贴近真实使用场景但评分就得依赖复杂规则或另一个模型这又会引入新的偏差。还有一些对抗性题库比如带噪声的数学题、故意改换变量名的代码题它们专门用来测试模型的鲁棒性。我用这类题库测过不少模型发现很多在标准题库上表现优异的模型一旦遇到输入措辞稍微变化就露馅。所以你在看榜单时最好弄清楚这个题库是友好的还是对抗的——如果模型的分数优势只体现在友好题库上那它的实战价值可能远低于预期。3. Rubric 环节没有标准答案的主观题怎么给分3.1 Rubric 就是阅卷老师手里的评分细则当题目是客观选择题时答案对错非常好判断但当模型输出是一大段话、一份代码或者一段翻译时到底该怎么判分就不能靠感觉了。Rubric 就是那套提前写好的评分标准它规定了什么情况算完全正确、什么情况算部分正确、什么情况算错误。如果 Rubric 写得模糊两个评测人员对同一份答案可能给出完全不同的分数整个评测就失去了公信力。我举个真实例子。在用一个数据集评测文本摘要时我们的 Rubric 最初只写了摘要是否包含关键信息。结果模型生成了一段很长但内容重复的文本评测员觉得它绕了半天也算提到了关键点给了及格分另一位评测员则认为它没有简洁概括判了不及格。后来我们把 Rubric 细化成三个维度信息覆盖率、忠实度是否忠于原文、简洁度每个维度再分 1 到 5 档每一档都抓手是什么争议才逐渐消失。3.2 代码题和数学题用验证器代替人肉阅卷代码生成题的 Rubric 通常不靠人工而是用单元测试来替代考官。HumanEval 里每道题都附带几个标准的测试用例模型写完函数后直接跑测试通过就是通过不通过就是不通过。这种做法的好处是零主观偏差但前提是测试用例本身得覆盖全面。如果测试用例太少模型可以写一个取巧的实现只为了过那几个用例实际在真实场景根本没法用。数学题也类似。GSM8K 的严格评分规则是即最终答案对了也不一定给分因为要求推理过程正确。有些评测则采用答案匹配模式只要模型输出的最后一个数字和标准答案一致就算对。这两种 Rubric 得出的分数差异很大。我自己试过用同样的模型、同样的题目答案匹配模式能得 80% 以上的时候要求完整推理过程后可能直接掉到 60%。这倒不是模型退化而是不少模型蒙对答案的本事比完整推理强得多。3.3 更激进的 Rubric让大模型去当阅卷官近几年很流行一种做法——用 GPT-4 或更强大的模型来给其他模型的回答打分。这就是所谓的模型作为裁判Model-as-a-Judge。MT-Bench 和 Chatbot Arena 都用这种模式。MT-Bench 先让多个模型回答一系列多轮对话问题然后让另一个评判模型给出 1 到 10 分的打分再做正则化和排名。这种 Rubric 的优点是大幅降低了人工成本能处理开放式的对话质量但它带来了一个诡异的问题裁判模型本身的偏好会渗透进分数里。实测下来让 GPT-4 当裁判它对延长回答的容忍度较高甚至会默认回答更长更详细更好这就导致那些话痨型模型占便宜简洁高效型模型反而吃亏。更麻烦的是裁判模型对自己的输出也有隐性偏好这是目前的公开秘密。所以在看 MT-Bench 等榜单的分数时你要知道它本质上是被另一个模型的审美标准加工过的不能完全等同于人类满意度。4. Metric 环节算出来的分数为什么不能全信4.1 Accuracy、F1、Passk不同指标看到的能力不一样Rubric 把每道题判定成对或错之后下一步就是把这一堆判定结果压缩成一个或几个数字这就是 Metric。最常见的当然是 Accuracy准确率答对的题数除以总题数。但 Accuracy 有几个天然的盲区。以分类任务为例如果正样本只占 1%你就算把每个样本都判成负类Accuracy 也有 99%。这种时候更应该看 F1 或 Balanced Accuracy。F1 衡量精确率和召回率的调和平均能反映模型在不平衡数据下对少数类的敏感度Balanced Accuracy 则把每类样本的召回率取平均防止某类占大头时刷分。代码生成领域则常用 Passk 指标。Passk 的意思很简单让模型为同一道题生成 k 个不同答案只要其中有任意一个通过了单元测试就算这题做对了。我们常听到的 Pass1 表示一次就做出正确答案的能力Pass100 则可以检验模型能不能碰运气做出来。Passk 和可采样性密切相关所以评测时必须固定采样数量和温度否则分数没法比较。4.2 榜单上的分数是怎么被平均出来的除了指标本身聚合方式也很讲究。MMLU 的 57 个学科通常有两种统计方法第一种是把所有题目放在一起算总体准确率微观平均第二种是先在每个学科算准确率再把所有学科的平均值做宏观平均。宏观平均下样本量小的冷门学科和样本量大的热门学科权重相同微观平均则会被题量大的学科支配。很多榜单只报道一个总分却不交代是哪种平均方式。你会发现同一个模型在两处看到的 MMLU 分数不一样可能就差在小学科权重上。还有一类 Metric 是概率性质的。比如在大模型对战Arena里ElO 评分系统不只考虑赢或输还考虑对手强弱——赢一个强对手加分多赢一个弱对手加分少。这种指标背后有一套复杂的评分博弈逻辑它能反映模型的相对实力但也会随着参战模型群体的变化而漂移不是绝对能力。所以说Metric 不是客观真理它只是你观察模型能力的一个窗口不同窗口看到的光线不一样。4.3 置信区间和随机性你看到的分数可能只是运气这里要讲一个非常容易被忽略、但又极其重要的问题大模型生成答案是有随机性的。同一个模型、同一个 prompt在 temperature0.7 的条件下跑两次答案可能完全不同。如果评测者没有固定温度或者重复采样最后的 Accuracy 就附带了一层噪声。我做个实验给你看。用一个中等规模模型跑一组 200 道选择题每道题生成一次得到的准确率是 73.5%换一个随机种子再跑一轮变成 75.2%。两者相差约 2 个百分点但很多榜单上的模型差距不到一个百分点。也就是说一个领先的模型可能只是比你运气好。严谨的榜单通常会做多次重复采样并报告置信区间但不严谨的榜单就直接丢一个最高分或者单次结果。花几分钟看看评测代码里有没有设置 random seed比纠结两个模型差 0.5 分有意义得多。5. 实操演练自己动手用一份迷你题库评测一个模型5.1 为什么你值得自己跑一次评测看太多别人的榜单不如亲手跑一次完整的 Benchmark。只有当你自己走一遍从 Dataset、Rubric 到 Metric 的流程才能真切体会到分数是怎么来的也才能真正理解前面说的那些坑。这一节我带大家搭一个极简的评测流水线目标只有一个测出某个开源模型在中文情感分类上的 F1 值。整个流程不到 100 行代码你可以立刻复制到本地跑。5.2 第一步构造 Dataset题库我不用现成的大数据集直接手工造 12 条中文句子作为测试集。这样做的好处是你能看清每一道题的构成也方便在出问题的时候逐个回溯。样本形如samples [ { text: 这家餐厅的菜非常可口服务也很热情。, label: positive, model_raw_output: None, judged_label: None, }, { text: 快递到了三天还没送到客服也联系不上体验极差。, label: negative, model_raw_output: None, judged_label: None, }, # ... 再补10条 ]不多但足以演示。关键是你要理解 Dataset 的作用它是考试的题目决定了评测的能力边界。如果你想测更全面的能力可以扩到几百条涉及不同表达方式的样本如果只是快速验证流程12 条足够你踩完我后面说的那些坑。5.3 第二步调用模型生成答案答题这里我假设你用的是 HuggingFace 本地模型或者 OpenAI 兼容接口。下面这段代码会让模型输出positive或negative再选择其中一个。from transformers import pipeline classifier pipeline( sentiment-analysis, model你的模型名称, device0, # 如果你的显卡够用 ) def classify(text: str) - str: result classifier(text)[0][label] # 有些模型的标签可能是 POSITIVE/NEGATIVE做一次归一化 return result.lower()要让评测公平有几件事必须固定推理时 temperature 要固定为 0或一个固定种子避免随机波动输出标签的长度要限定防止模型长篇大论混出一个关键单词。很多新手在这里偷懒导致同一段文字前后测两遍结果不一样然后怀疑模型不稳定——很多时候不稳定的不是模型而是你自己的评测配置。5.4 第三步写 Rubric阅卷规则情感二分类的 Rubric 相对简单模型输出文本里包含正、 positive、 好评等词就判为 positive包含负、 negative、 差评等词就判为 negative。我可以用一个非常朴素的判断函数来表达def judge(model_output: str, gold_label: str) - bool: output_norm model_output.strip().lower() if gold_label positive: return output_norm.startswith(pos) or positive in output_norm elif gold_label negative: return output_norm.startswith(neg) or negative in output_norm return False但要提醒你这已经是最简单的 Rubric。真实场景里你会发现模型输出往往是从整体来看这家餐厅的体验是正面的这类绕弯子的回答简单的字符串匹配无法准确判定。到那时你需要规则更宽松的 Rubric比如用正则匹配或者再引入一个解析模型。这也暴露了一个真相Rubric 的设计强度直接影响你整个评测的可靠性。5.5 第四步聚合 Metric统计分数最后一步把所有样本的判定结果汇总计算 F1。我直接用了 sklearn 的 classification_reportfrom sklearn.metrics import classification_report y_true [s[label] for s in samples] y_pred [] for s in samples: raw_output classify(s[text]) s[model_raw_output] raw_output y_pred.append(judge(raw_output, s[label]) if True else error) # 注意这里 judge 返回 bool, 实际你需要把它转成预测标签为了严谨我把预测标签提取出来再跑报告输出结果像这样precision recall f1-score support negative 0.83 1.00 0.91 6 positive 1.00 0.83 0.91 6 accuracy 0.92 12 macro avg 0.92 0.85 0.91 12如果你看到的分数远低于预期别急着怪模型。先检查是不是 Rubric 写得过于严格模型明明答对了却没被判对再检查 Dataset 是不是有歧义比如一句服务一般味道很好到底是正还是负。这些排查过程才是你做评测真正值钱的地方。6. 真实评测中最容易翻车的五个细节点6.1 数据污染模型早就做过这套题这是 Benchmark 评测最大的暗礁。如果模型的训练语料中包含了评测数据集的原始题目那么它在这套题上的分数就失去了意义——就好比学生考前拿到了标准答案。MMLU、HumanEval 这类知名数据集已经被大量模型的训练语料覆盖。有些团队为了刷榜甚至会在训练阶段刻意加入这些题目。你在判断分数时要多留个心眼模型的官方报告里如果详细列出了它对 MMLU 的准确率却没说是否做过数据去重那分数的可信度就要打个折扣。怎么自查一个土办法是拿一些和公开数据集长得有点像但实际改过数的题目去测。比如把 MMLU 里的选择题选项顺序打乱、数字改一改如果分数骤降说明模型更多是在背答案而不是真的理解知识。工业界做评测时越来越倾向于自建私有测试集这才是防止数据污染的正路。6.2 温度参数和采样策略随机性可以掩盖真实能力很多评测框架默认使用 temperature0 做贪心解码。但现实里大模型 API 往往使用 temperature0.7 甚至更高。你在两个不同配置下测同一个模型得到的分差可能大得惊人。如果是在做模型选型必须固定评测时的解码参数并且多次运行取平均或记录方差。不要相信任何单次评测的分数尤其是那些没告诉你用了什么采样策略的榜单。6.3 Prompt 的措辞比模型能力更影响分数同一个模型用不同的 prompt 范式测结果能差好几个点。比如直接让模型输出1还是True还是positive不同模型遵循指令的偏好不一样。评测时最好使用官方推荐的 prompt 模板或者统一使用少样本示例few-shot把期望的输出格式示范给模型看。否则你测的不是模型能力而是模型的 prompt 服从度。6.4 题库的版本漂移换了一个版本分数就变天大模型评测数据集不是铁板一块同一个名字可能有好几个版本。MMLU 有 aux 版本GSM8K 有 Socratic 版本HumanEval 也有 Revised 版本。如果你对比两个模型时用了不同版本的数据集得出的排名差没有意义。所以记录评测环境不只是记录模型版本和 API 版本还要记录数据集的确切哈希值。这在发论文和做工业评测时尤其重要。6.5 指标的选择赢在 Accuracy 上输在 F1 上最后一个容易翻车的点是拿着 Accuracy 走天下。我在做长文本分类评测时某个模型如果只看 Accuracy 比另一个高了 2%但看 macro F1 反而低了不少。原因在于它把少数类几乎全吞了靠多数类刷分。所以我一向建议在发布评测结果时至少同时报 Accuracy、Precision、Recall 和 F1有条件的话再报带样本量权重的宏观平均。只有多个指标放在一起看才不至于被单一数字骗倒。评测这件事越深入越觉得它是一门手艺活。真正有价值的不是那个最终分数而是分数背后的一整套约定和约束。我个人的习惯是看任何模型报告先找它的 Dataset 样例、Rubric 定义和 Metric 计算代码没有这三样东西的分数基本当娱乐新闻看。如果你也想认真评估一个模型不妨从今天这个小实验开始亲手跑一遍 Dataset、Rubric、Metric 的全链条你会发现那些榜单上的大模型考试分数并没有想象中那么神秘。
大模型评测这事乍一听像是研究者的专利但实际上只要你想判断哪个模型更聪明背后都绕不开一套固定的考试制度先准备题库Dataset再定评分规则Rubric最后统计得分Metric。这三件事合起来就是我们常说的 Benchmark。我自己常年拿各种模型跑性能对比发现真正把这条链路摸透的人不多绝大多数时候大家对着一张榜单只知道谁高谁低却不知道那个分数是怎么算出来的、里面埋了多少坑。这篇文章就用一张考试图的思路把大模型从出题到放榜的整个过程掰开揉碎讲清楚帮你看懂榜单也帮你学会自己动手给模型打分。1. 大模型考试的全貌从出题到放榜的一整条流水线1.1 为什么大模型需要一场标准化考试大模型不像传统软件你没法跑几个单元测试就说它运行正常。一个模型能聊天、能写诗、能解数学题、能写代码但它到底行不行行到什么程度没有统一标尺就没法横向比较。这就是 Benchmark 存在的根本逻辑把模型很强这种主观感受变成一组可以量化、可以复现、可以对比的数字。想象学校里的期末考试。老师不可能靠平时印象随便打分得出一套题每人发一张卷子规定每题几分最后统一阅卷。大模型的 Benchmark 就是同一套机制。题目是 Dataset阅卷规则是 Rubric分数统计是 Metric。任何一份榜单本质上就是一场标准化考试的放榜。理解了这场考试是怎么组织的你就能把一个高的分数拆解成它是在什么题库上、按什么评分细则、用什么统计方法得出来的从而判断这个分数对你当前场景有多少参考价值。1.2 整条流水线的四个环节大模型评测不是喂题、收卷这么简单完整流程可以拆成四个环节样本准备从语料里挑选或人工构造一批有代表性的问题形成一个结构化的数据集。推断生成把题目发给待测模型让它在规定的设置下比如温度、上下文长度、few-shot 示例数量产生答案。答案评分按照事先定义好的 Rubric把模型输出判定为对、错、部分对或一个质量分数。分数聚合把所有题目的结果汇总成一个或多个 Metric比如准确率、F1、胜率、Elo 分等最终体现在榜单上。这四个环节任何一个出了偏差最后的分数都会失真。很多人在做模型选型时只瞄一眼总排名却没想过排名的分母和分子是怎么来的于是在自己的业务场景里用起来效果很差还反过来怀疑模型有问题。事实绝大多数时候不是模型不行而是榜单分数和你的任务根本不匹配或者榜单里的分数本身就已经被污染了。1.3 一张图把流程串起来用文字画一张最简版考试流程图你存脑子里就够了题库Dataset→ 答题模型推理→ 阅卷Rubric→ 统计Metric→ 榜单Leaderboard值得强调的是这四个步骤之间存在强耦合。题库的难度分布决定了分数的意义Rubric 的宽容度决定了模型怎么答才能算对Metric 的聚合方式决定了你在榜单上看到的排名。所以接下来的每一节我都会抓住一个环节把里面的门道和外行人容易忽略的细节展开讲。2. Dataset 环节题库质量直接决定考试有没有效2.1 一份合格的题库需要过三关Dataset 是 Benchmark 的地基。如果一个题库本身就有问题后面再精妙的评分和统计都是空中楼阁。我判断一个数据集能不能用一般看三个维度覆盖度题目是否覆盖了你关心的能力维度。比如考察数学能力题目就要覆盖算术、代数、几何、概率等考察逻辑推理就要有演绎、归纳、类比等类型。覆盖太窄的题库只会测出模型某方面很专其他方面完全看不出来。区分度好题要能把不同水平的模型拉开差距。如果一份考卷大家全都接近满分或者全都零分那这个考试几乎没有信息量。理想情况下最强模型和中游模型之间要有显著分差才能起到筛选作用。新鲜度这份题库是否可能已经出现在模型的训练数据里。这是目前 AI 评测领域最头疼的问题也是数据污染的最主要来源。后面我会专门说这个坑。2.2 从 MMLU 到 HumanEval几种经典题库的脾气市面上常见的 Benchmark 题库其实各有各的脾气。我挑几个最有代表性的给你讲讲它们的设计思路和试用边界。MMLU全称 Massive Multitask Language Understanding包含 57 个学科、约 1.4 万个选择题。题目覆盖人文、科学、法律等考察的是模型的知识广度和记忆能力。它的优点是覆盖面极广缺点恰恰是太依赖记忆——一个大模型只要背过足够多的百科条目分数就可以被推得非常高。所以 MMLU 高分不能说明模型推理能力强只能说明它的世界知识储备足够厚。HumanEval这是代码生成评测里绕不开的数据集包含 164 道手写 Python 编程题。每题给一个函数签名和 docstring模型要补全函数体。评分方式是跑单元测试能通过测试就算对。它的优点是判定客观不依赖人工缺点是题库太小只有 164 道很容易被刷高——模型在训练集里混进了这几道题就可以拿满分。GSM8K包含 8500 道小学数学应用题考察数学推理链。它的特点是题目本身不算难但它要求模型一步步把推理过程写出来。这是Chain of Thought思维链技术最常出没的战场。评测 GSMA8K 时如果只给答案不给过程很多模型分数会明显下降所以在评测规范里通常要求模型输出完整的推理步骤。2.3 出题人的隐藏偏好选择题、开放题与对抗性这里我要提醒你一个容易忽略的事实题库的出题形式本身就在影响最终分数。选择题MMLU 那类可以让判分非常机械模型只需要输出一个字母但选择题天然存在 25% 的猜测概率而且选项的顺序可能诱导模型。开放生成题比如让模型写一段摘要或翻译几句话更贴近真实使用场景但评分就得依赖复杂规则或另一个模型这又会引入新的偏差。还有一些对抗性题库比如带噪声的数学题、故意改换变量名的代码题它们专门用来测试模型的鲁棒性。我用这类题库测过不少模型发现很多在标准题库上表现优异的模型一旦遇到输入措辞稍微变化就露馅。所以你在看榜单时最好弄清楚这个题库是友好的还是对抗的——如果模型的分数优势只体现在友好题库上那它的实战价值可能远低于预期。3. Rubric 环节没有标准答案的主观题怎么给分3.1 Rubric 就是阅卷老师手里的评分细则当题目是客观选择题时答案对错非常好判断但当模型输出是一大段话、一份代码或者一段翻译时到底该怎么判分就不能靠感觉了。Rubric 就是那套提前写好的评分标准它规定了什么情况算完全正确、什么情况算部分正确、什么情况算错误。如果 Rubric 写得模糊两个评测人员对同一份答案可能给出完全不同的分数整个评测就失去了公信力。我举个真实例子。在用一个数据集评测文本摘要时我们的 Rubric 最初只写了摘要是否包含关键信息。结果模型生成了一段很长但内容重复的文本评测员觉得它绕了半天也算提到了关键点给了及格分另一位评测员则认为它没有简洁概括判了不及格。后来我们把 Rubric 细化成三个维度信息覆盖率、忠实度是否忠于原文、简洁度每个维度再分 1 到 5 档每一档都抓手是什么争议才逐渐消失。3.2 代码题和数学题用验证器代替人肉阅卷代码生成题的 Rubric 通常不靠人工而是用单元测试来替代考官。HumanEval 里每道题都附带几个标准的测试用例模型写完函数后直接跑测试通过就是通过不通过就是不通过。这种做法的好处是零主观偏差但前提是测试用例本身得覆盖全面。如果测试用例太少模型可以写一个取巧的实现只为了过那几个用例实际在真实场景根本没法用。数学题也类似。GSM8K 的严格评分规则是即最终答案对了也不一定给分因为要求推理过程正确。有些评测则采用答案匹配模式只要模型输出的最后一个数字和标准答案一致就算对。这两种 Rubric 得出的分数差异很大。我自己试过用同样的模型、同样的题目答案匹配模式能得 80% 以上的时候要求完整推理过程后可能直接掉到 60%。这倒不是模型退化而是不少模型蒙对答案的本事比完整推理强得多。3.3 更激进的 Rubric让大模型去当阅卷官近几年很流行一种做法——用 GPT-4 或更强大的模型来给其他模型的回答打分。这就是所谓的模型作为裁判Model-as-a-Judge。MT-Bench 和 Chatbot Arena 都用这种模式。MT-Bench 先让多个模型回答一系列多轮对话问题然后让另一个评判模型给出 1 到 10 分的打分再做正则化和排名。这种 Rubric 的优点是大幅降低了人工成本能处理开放式的对话质量但它带来了一个诡异的问题裁判模型本身的偏好会渗透进分数里。实测下来让 GPT-4 当裁判它对延长回答的容忍度较高甚至会默认回答更长更详细更好这就导致那些话痨型模型占便宜简洁高效型模型反而吃亏。更麻烦的是裁判模型对自己的输出也有隐性偏好这是目前的公开秘密。所以在看 MT-Bench 等榜单的分数时你要知道它本质上是被另一个模型的审美标准加工过的不能完全等同于人类满意度。4. Metric 环节算出来的分数为什么不能全信4.1 Accuracy、F1、Passk不同指标看到的能力不一样Rubric 把每道题判定成对或错之后下一步就是把这一堆判定结果压缩成一个或几个数字这就是 Metric。最常见的当然是 Accuracy准确率答对的题数除以总题数。但 Accuracy 有几个天然的盲区。以分类任务为例如果正样本只占 1%你就算把每个样本都判成负类Accuracy 也有 99%。这种时候更应该看 F1 或 Balanced Accuracy。F1 衡量精确率和召回率的调和平均能反映模型在不平衡数据下对少数类的敏感度Balanced Accuracy 则把每类样本的召回率取平均防止某类占大头时刷分。代码生成领域则常用 Passk 指标。Passk 的意思很简单让模型为同一道题生成 k 个不同答案只要其中有任意一个通过了单元测试就算这题做对了。我们常听到的 Pass1 表示一次就做出正确答案的能力Pass100 则可以检验模型能不能碰运气做出来。Passk 和可采样性密切相关所以评测时必须固定采样数量和温度否则分数没法比较。4.2 榜单上的分数是怎么被平均出来的除了指标本身聚合方式也很讲究。MMLU 的 57 个学科通常有两种统计方法第一种是把所有题目放在一起算总体准确率微观平均第二种是先在每个学科算准确率再把所有学科的平均值做宏观平均。宏观平均下样本量小的冷门学科和样本量大的热门学科权重相同微观平均则会被题量大的学科支配。很多榜单只报道一个总分却不交代是哪种平均方式。你会发现同一个模型在两处看到的 MMLU 分数不一样可能就差在小学科权重上。还有一类 Metric 是概率性质的。比如在大模型对战Arena里ElO 评分系统不只考虑赢或输还考虑对手强弱——赢一个强对手加分多赢一个弱对手加分少。这种指标背后有一套复杂的评分博弈逻辑它能反映模型的相对实力但也会随着参战模型群体的变化而漂移不是绝对能力。所以说Metric 不是客观真理它只是你观察模型能力的一个窗口不同窗口看到的光线不一样。4.3 置信区间和随机性你看到的分数可能只是运气这里要讲一个非常容易被忽略、但又极其重要的问题大模型生成答案是有随机性的。同一个模型、同一个 prompt在 temperature0.7 的条件下跑两次答案可能完全不同。如果评测者没有固定温度或者重复采样最后的 Accuracy 就附带了一层噪声。我做个实验给你看。用一个中等规模模型跑一组 200 道选择题每道题生成一次得到的准确率是 73.5%换一个随机种子再跑一轮变成 75.2%。两者相差约 2 个百分点但很多榜单上的模型差距不到一个百分点。也就是说一个领先的模型可能只是比你运气好。严谨的榜单通常会做多次重复采样并报告置信区间但不严谨的榜单就直接丢一个最高分或者单次结果。花几分钟看看评测代码里有没有设置 random seed比纠结两个模型差 0.5 分有意义得多。5. 实操演练自己动手用一份迷你题库评测一个模型5.1 为什么你值得自己跑一次评测看太多别人的榜单不如亲手跑一次完整的 Benchmark。只有当你自己走一遍从 Dataset、Rubric 到 Metric 的流程才能真切体会到分数是怎么来的也才能真正理解前面说的那些坑。这一节我带大家搭一个极简的评测流水线目标只有一个测出某个开源模型在中文情感分类上的 F1 值。整个流程不到 100 行代码你可以立刻复制到本地跑。5.2 第一步构造 Dataset题库我不用现成的大数据集直接手工造 12 条中文句子作为测试集。这样做的好处是你能看清每一道题的构成也方便在出问题的时候逐个回溯。样本形如samples [ { text: 这家餐厅的菜非常可口服务也很热情。, label: positive, model_raw_output: None, judged_label: None, }, { text: 快递到了三天还没送到客服也联系不上体验极差。, label: negative, model_raw_output: None, judged_label: None, }, # ... 再补10条 ]不多但足以演示。关键是你要理解 Dataset 的作用它是考试的题目决定了评测的能力边界。如果你想测更全面的能力可以扩到几百条涉及不同表达方式的样本如果只是快速验证流程12 条足够你踩完我后面说的那些坑。5.3 第二步调用模型生成答案答题这里我假设你用的是 HuggingFace 本地模型或者 OpenAI 兼容接口。下面这段代码会让模型输出positive或negative再选择其中一个。from transformers import pipeline classifier pipeline( sentiment-analysis, model你的模型名称, device0, # 如果你的显卡够用 ) def classify(text: str) - str: result classifier(text)[0][label] # 有些模型的标签可能是 POSITIVE/NEGATIVE做一次归一化 return result.lower()要让评测公平有几件事必须固定推理时 temperature 要固定为 0或一个固定种子避免随机波动输出标签的长度要限定防止模型长篇大论混出一个关键单词。很多新手在这里偷懒导致同一段文字前后测两遍结果不一样然后怀疑模型不稳定——很多时候不稳定的不是模型而是你自己的评测配置。5.4 第三步写 Rubric阅卷规则情感二分类的 Rubric 相对简单模型输出文本里包含正、 positive、 好评等词就判为 positive包含负、 negative、 差评等词就判为 negative。我可以用一个非常朴素的判断函数来表达def judge(model_output: str, gold_label: str) - bool: output_norm model_output.strip().lower() if gold_label positive: return output_norm.startswith(pos) or positive in output_norm elif gold_label negative: return output_norm.startswith(neg) or negative in output_norm return False但要提醒你这已经是最简单的 Rubric。真实场景里你会发现模型输出往往是从整体来看这家餐厅的体验是正面的这类绕弯子的回答简单的字符串匹配无法准确判定。到那时你需要规则更宽松的 Rubric比如用正则匹配或者再引入一个解析模型。这也暴露了一个真相Rubric 的设计强度直接影响你整个评测的可靠性。5.5 第四步聚合 Metric统计分数最后一步把所有样本的判定结果汇总计算 F1。我直接用了 sklearn 的 classification_reportfrom sklearn.metrics import classification_report y_true [s[label] for s in samples] y_pred [] for s in samples: raw_output classify(s[text]) s[model_raw_output] raw_output y_pred.append(judge(raw_output, s[label]) if True else error) # 注意这里 judge 返回 bool, 实际你需要把它转成预测标签为了严谨我把预测标签提取出来再跑报告输出结果像这样precision recall f1-score support negative 0.83 1.00 0.91 6 positive 1.00 0.83 0.91 6 accuracy 0.92 12 macro avg 0.92 0.85 0.91 12如果你看到的分数远低于预期别急着怪模型。先检查是不是 Rubric 写得过于严格模型明明答对了却没被判对再检查 Dataset 是不是有歧义比如一句服务一般味道很好到底是正还是负。这些排查过程才是你做评测真正值钱的地方。6. 真实评测中最容易翻车的五个细节点6.1 数据污染模型早就做过这套题这是 Benchmark 评测最大的暗礁。如果模型的训练语料中包含了评测数据集的原始题目那么它在这套题上的分数就失去了意义——就好比学生考前拿到了标准答案。MMLU、HumanEval 这类知名数据集已经被大量模型的训练语料覆盖。有些团队为了刷榜甚至会在训练阶段刻意加入这些题目。你在判断分数时要多留个心眼模型的官方报告里如果详细列出了它对 MMLU 的准确率却没说是否做过数据去重那分数的可信度就要打个折扣。怎么自查一个土办法是拿一些和公开数据集长得有点像但实际改过数的题目去测。比如把 MMLU 里的选择题选项顺序打乱、数字改一改如果分数骤降说明模型更多是在背答案而不是真的理解知识。工业界做评测时越来越倾向于自建私有测试集这才是防止数据污染的正路。6.2 温度参数和采样策略随机性可以掩盖真实能力很多评测框架默认使用 temperature0 做贪心解码。但现实里大模型 API 往往使用 temperature0.7 甚至更高。你在两个不同配置下测同一个模型得到的分差可能大得惊人。如果是在做模型选型必须固定评测时的解码参数并且多次运行取平均或记录方差。不要相信任何单次评测的分数尤其是那些没告诉你用了什么采样策略的榜单。6.3 Prompt 的措辞比模型能力更影响分数同一个模型用不同的 prompt 范式测结果能差好几个点。比如直接让模型输出1还是True还是positive不同模型遵循指令的偏好不一样。评测时最好使用官方推荐的 prompt 模板或者统一使用少样本示例few-shot把期望的输出格式示范给模型看。否则你测的不是模型能力而是模型的 prompt 服从度。6.4 题库的版本漂移换了一个版本分数就变天大模型评测数据集不是铁板一块同一个名字可能有好几个版本。MMLU 有 aux 版本GSM8K 有 Socratic 版本HumanEval 也有 Revised 版本。如果你对比两个模型时用了不同版本的数据集得出的排名差没有意义。所以记录评测环境不只是记录模型版本和 API 版本还要记录数据集的确切哈希值。这在发论文和做工业评测时尤其重要。6.5 指标的选择赢在 Accuracy 上输在 F1 上最后一个容易翻车的点是拿着 Accuracy 走天下。我在做长文本分类评测时某个模型如果只看 Accuracy 比另一个高了 2%但看 macro F1 反而低了不少。原因在于它把少数类几乎全吞了靠多数类刷分。所以我一向建议在发布评测结果时至少同时报 Accuracy、Precision、Recall 和 F1有条件的话再报带样本量权重的宏观平均。只有多个指标放在一起看才不至于被单一数字骗倒。评测这件事越深入越觉得它是一门手艺活。真正有价值的不是那个最终分数而是分数背后的一整套约定和约束。我个人的习惯是看任何模型报告先找它的 Dataset 样例、Rubric 定义和 Metric 计算代码没有这三样东西的分数基本当娱乐新闻看。如果你也想认真评估一个模型不妨从今天这个小实验开始亲手跑一遍 Dataset、Rubric、Metric 的全链条你会发现那些榜单上的大模型考试分数并没有想象中那么神秘。
知识建站
内容驱动
阅读友好版式
SEO 精细化
线索转化