“大模型评测”这四个字，放在去年还只是少数技术团队内部的小众话题，今年已经变成每个认真用大模型的人绕不开的一道坎。我最近帮几个团队做过选型评测，也帮一个内部的微调项目搭过完整的回归体系，最大的感受是：评测这件事，表面上是跑分数，本质上是建立一套你能真正信得过的判断标准。这篇文章不打算复述那些公开榜单上的数字，而是想把我从零搭评测体系时踩过的坑、想明白的道理、以及现在每天都在用的实操流程，完整地讲一遍。无论你是要选型采购，还是要验证自己的微调成果，这套思路应该都能直接套用。
1. 为什么“跑几个榜单分数”远远不够：大模型评测的真实需求
1.1 评测到底在为谁服务
先说一个很反直觉的结论：同一个模型，用同一套公开题集，不同团队测出来的分数可能差出一大截，而且两边都觉得自己没测错。原因不是题集本身有问题，而是评测目标不一样。
我做过的评测需求大致分三类。第一类是选型对比，比如要接一个商用闭源模型，得先确定选哪家，这类评测的核心是“横向可对比、稳定可复现”，你关注的是相对差异而不是绝对分数。第二类是研发回归，比如你自己微调了一个模型，每次训练完都要跑一遍固定测试，这类评测的核心是“敏感性”，得能看出即使很小的改动带来的能力变化。第三类是验收交付，比如公司采购模型前要求你必须给出一个结论，这类评测的核心是“可解释性”，分数出来之后要能说清楚为什么是这个分数。
三类目标决定了你要选不同的题集、用不同的评分方式，甚至要有不同的容错空间。很多团队一上来就找一套公开题集全量跑一遍，把分数摆在PPT上，恰恰是所有做法里最没信息量的一种。
1.2 榜单分数的三个天然局限
第一个局限是“过拟合”。只要一套题集存在的时间够长，很多模型的训练数据里就可能包含它。模型见没见过题，在成绩上的差距是肉眼可见的。我不太相信任何没有做过数据去重检查的评测结果。
第二个局限是“单向度”。公开榜单总分往往由一个平均分撑起来，一个擅长数学但对自然对话很弱的模型，和另一个什么都会一点但什么都不精的模型，可能拿到同一个平均分。真实使用场景里没有人会在意“平均能力”，在意的是在特定任务上是可用还是不可用。
第三个局限是“时滞性”。榜单数据发布、模型迭代、评测环境变化，等你拿到一份漂亮榜单的时候，上面的模型版本可能已经换了几轮。评测是决策的辅助工具，不是一个可以长期挂在那里不动的纪念碑。
这三条不是说公开榜单没有价值，而是说你要带着这三个局限去解读它。真正能指导决策的评测，往往是基于你的真实任务定制的那一套。
2. 先画能力地图：评测到底该测哪些维度
2.1 从任务到能力：把“聪明”拆成可量化的指标
很多第一次做评测的人会问一个问题：到底该测多少项？我的习惯是先画一张能力地图，把大模型的能力拆成若干个可以单独测量的维度，再从自己的业务场景里找到需要重点考察的维度。
常见的维度大概是下面几类：
- 知识广度与事实性：模型对世界知识的掌握程度，以及回答问题时不瞎编的能力。
- 数学与符号推理：多步计算、方程求解、逻辑推导，这类能力最容易自动化评分。
- 代码生成与理解：给定需求生成代码、阅读代码解释功能、修复给定Bug。
- 指令跟随与格式控制：模型能不能严格按你给的格式输出，比如只输出JSON、限定字数。
- 多轮对话与上下文理解：在长对话里不丢信息，能准确引用前文内容。
- 开放生成与创造力：写作、头脑风暴、内容改写这类没有唯一答案的任务。
- 安全与拒绝能力：对不合适的请求能否礼貌拒绝，而不是一本正经地给出危险答案。
每一类维度都需要对应的题集和评分方法。知识题可以自动判分，数学题要区分过程和结果，代码题需要运行验证，而开放生成类任务往往只能借助模型裁判或者人工抽检。
我建议的做法是：先把维度表画出来，标出“本次必测”“可选”“不测”三档。你会发现很多常见的评测焦虑其实来源于把可选项当成必选项，白白浪费时间和算力。
2.2 中文场景下容易忽视的维度
中文大模型评测有一个经常被忽略的维度：中文特有场景。通用英文知识题的分数，很难反映一个模型在中文环境里的真实表现。
我通常会额外补三类中文相关测试。一是中文知识文化相关题目，比如古诗词理解、成语应用、传统典籍问答。二是中文指令口语化理解，比如用户把需求说得啰嗦、口语化甚至带错别字，模型能否正确理解意图。三是中英混杂场景，代码注释中英文夹杂、技术文档翻译等日常开发场景。
为什么强调这些？因为很多模型在纯中文标准题集上表现很好，一旦落到真实的、脏乱差的中文输入上就迅速掉链子。评测如果不能反映你真实面对的输入分布，那它测出来的分数对你的业务就没有实际意义。
3. 公开题库与自建题集：评测基线的选型与取舍
3.1 四类常见公开题集的适用边界
现在能见到的公开题集大致分四类，我按适用场景整理了一张表：
| 题集类型 | 典型特点 | 适合用途 | 不适合用途 |
|---|---|---|---|
| 学科知识类 | 覆盖多学科，题量大，可自动判分 | 快速横向对比模型知识面 | 判断业务场景可用性 |
| 数学推理类 | 以应用题为主，步骤明确，评分客观 | 考察多步推理能力 | 考察真实对话体验 |
| 代码类 | 从代码补全到Bug修复 | 研发团队选型 | 产品经理做能力汇报 |
| 对话与指令类 | 开放式答案，依赖人工或模型评分 | 验证真实交互体验 | 追求精确分数差异 |
选公开题集的第一原则是：你的评测目标决定了题集类型，而不是反过来。给别人汇报选型结论时，用第一类和第二类就够了；自己优化模型时，第三类和第四类才是关键。
3.2 自建题集的采样逻辑与标注成本
在选型评测这类场景里，我强烈建议至少自建一部分题集。自建题集的规模不需要很大，关键是覆盖你的真实业务。
我自己常用的一种做法是“场景倒推采样”。比如你要做一个客服助手，那就从历史对话里抽一批真实工单，脱敏后改写成评测题；你要做一个文档摘要工具，就找一批真实文档，配套写好标准摘要要求。然后按下面的逻辑分配：
- 约30%来自历史真实数据改写，保证贴近场景。
- 约30%来自公开题集的精选子集，保证可以和外部结果对照。
- 约30%来自一轮一轮攒下来的疑难样本，专门用来暴露模型短板。
- 约10%来自人工构造的对抗样本，比如故意含糊的需求、要求模型拒绝的回答。
这样构造出来的题集，既有对比基准的“锚点”，又有真实业务的“抓手”，比单一来源可靠得多。
顺便说一句，自建题集的标注成本并没有想象中那么高。一套几百题的小规模题集，三个人花一个周末就能完成初版，关键在于标准答案的写法——尽量把“判断标准”写清楚，因为后面换人复核时，标准模糊是最大的返工原因。
3.3 一个可参考的最小基线组合
如果暂时没有精力自建，直接拿公开题集拼一套最小基线，我的建议组合是：
- 知识理解类200题，覆盖多学科选择题。
- 数学推理类150题，全部是步骤化解答题。
- 代码类100题，以函数级生成和修复为主。
- 指令跟随类100题，以格式约束输出为主。
总共550题。配合固定的提示词模板和统一评分脚本，一个晚上就能跑完一个模型的评测。跑完之后你会发现，这组基线给出的维度画像，比任何单一榜单纯粹的总分都有价值。
4. 实操：从零搭建一套可复现的大模型评测流水线
接下来是这篇文章的重头戏，我把现在在用的评测流水线完整过一遍。这套流程核心目标只有一个：可复现。评测最怕的就是昨天跑85分，今天什么都没改，变成了91分。
4.1 环境准备与推理参数冻结
第一步是彻底冻结推理参数。我见过很多评测波动，最终查下来问题都出在参数不一致上。需要写死并记录在案的有：
- 采样温度，通常固定为0，做能力评测时不要开随机采样。
- 最大生成长度，按题集特性设定，比如代码题可以放宽到2048，选择题256就够。
- 停止符号，包括回答结束符、专用的格式分隔符。
- 系统提示词，整份评测全程统一。
这里特别强调温度。有些API默认温度不是0，而且不同接口对temperature的默认处理不一样。如果你不显式传入，两个批次跑出来的结果可能差异非常大。我在评测脚本里会在每个请求中显式写入参数，并在结果文件里记录使用的具体配置。
4.2 提示词模板：最容易被低估的变量
提示词模板是评测链条里最隐蔽但影响最大的变量。同一个模型，同一个问题，提示词里多一句“请直接给出答案”，分数可能浮动好几个点。这不是玄学，而是模型对指令格式极其敏感。
所以我的规则是：一套评测用一套模板，并且模板一旦定稿就冻结。任何人对模板的修改，都要走版本变更记录。你可以在评测脚本里为每个题集单独建一个模板文件，用版本号管理，结果文件里同时记录模板哈希值。
真要比对模型A和模型B时，同样的模板必须一字不差地用到两个模型上，否则比较就没有意义。
4.3 评分环节：精确匹配、模型裁判还是人工抽检
评分方式根据题型来定，我分成三层：
- 第一层，客观题自动判分。选择题用固定答案匹配，数学题可以用答案归一化之后精确匹配，这类题的判分完全自动化，成本最低。
- 第二层，带步骤的开放题，用另一个大模型当裁判。这是目前社区里最常见的方式，但有个前提：裁判模型本身要经过验证，你需要随机抽一批它的评分结果跟人工评分对照，一致性至少达到一定水平之后才能全量使用。
- 第三层，真实业务场景题目，保留人工抽检。哪怕你不能全量人工评，也一定要抽检5%到10%，发现自动评分和人工体验不一致时及时修正。
用模型当裁判的时候，我会把评分标准写得很细，给裁判一个结构化的评分提示，包括分数等级定义、扣分项、输出格式要求。裁判的随机性也是真实存在的，一种缓解办法是同一个样本让裁判评三次取中位数，虽然增加成本，但在关键题集上值得。
4.4 结果聚合与报告生成
跑完所有题集之后，需要把原始结果聚合成一份可阅读的报告。我习惯用一个表格记录每个维度上的各项指标，并且按维度汇总：
| 维度 | 题量 | 自动判分均值 | 模型裁判均值 | 人工抽检一致性 |
|---|---|---|---|---|
| 知识理解 | 200 | 82 | - | - |
| 数学推理 | 150 | 67 | 71 | 92% |
| 代码生成 | 100 | - | 74 | 88% |
| 指令跟随 | 100 | 88 | - | - |
报告里除了数字，还要记录评测的环境信息、模型版本、题集版本、模板版本、参数配置。这样一份报告，任何人拿过去都能复现同样的分数，才算是合格的评测产出物。
5. 评测结果里的“陷阱”：一次真实踩坑全记录
写了这么多方法论，接下来分享一个实际踩坑的完整过程。这个案例我印象特别深，因为它完美展示了评测里“一切正常但结果异常”的典型特征。
5.1 现象：同模型两次评测分数差异巨大
当时我在对比两个模型版本，第一天跑了一个版本A，得分还不错；第二天准备跑版本B，顺手把版本A也重跑一遍当对照。结果版本A的得分比前一天低了将近10个百分点。代码没改，题集没改，模型版本没变，接口参数我也确认过，看起来一切正常。
第一反应是怀疑题集被污染了，或者模型服务端出了问题。于是我把两天的原始请求都拿出来对比，发现一个非常隐蔽的差异：两天的提示词模板文件内容一模一样，但解析时对换行符的处理不一样。第一天用的模板在末尾有一个额外的空行，第二天重构脚本时，一个不小心把那个空行去掉了。
就是这一个空行，让一批指令类题目的输出格式产生了整体性偏移，模型开始附带解释而不是直接输出固定格式，自动判分脚本因为格式不匹配，大量判定为错误。分数差异就是这么来的。
5.2 排查链路：定位问题出在提示词
整个过程走了一条比较典型的排查链路。先从结果文件反查请求日志，筛选出得分下降最明显的几十个样本；然后发现这些样本集中在指令格式类题集；再把同样的样本用两种提示词去手工调用，确认差异可以稳定复现；最后对比两份提示词文本，才发现换行符的差异。
这个案例给了我三个教训。第一，提示词模板必须用文件形式集中管理，哪怕改一个字符也要走版本变更，不能直接写在脚本里随手改。第二，评测报告里必须记录模板的哈希值，而不是只写“模板v2”这种含糊标记。第三，每次跑评测之前，先随机抽20个样本人工看一眼输出，比任何自动化检查都更快发现问题。
5.3 更多“坑”的清单
除了上面这个，我在评测过程中还遇到过不少常规但又容易反复踩的坑，列出来供参考：
- 测试集污染：模型训练数据里可能包含公开题集的原始题目，得分虚高。缓解办法是自建一部分私有题集，并定期轮换。
- 随机性：即便温度设成0，某些推理框架仍然存在微小的随机差异。关键结论尽量多次运行取均值。
- 上下文长度：同样一道题，前面拼接的示例数量不同，模型表现不同。示例的选取和数量都要固定。
- 数值解析错误：模型输出了正确答案但格式不规范，“1200”写成“1,200”，判分脚本就判错。解决办法是判分前先做数值归一化。
- 算力不足导致的截断：长文本生成被提前截断，导致部分题目的答案不完整。记录每个样本的完成原因，区分正常结束和截断结束。
这些坑单独看都不起眼，但是叠加在一起，足以让一份评测报告彻底失真。评测的价值建立在细节的可靠性之上，这话一点不夸张。
6. 让评测结果真正指导决策：几个实用分析视角
6.1 交叉分析：总分高不等于场景可用
拿到各维度分数之后，下一步不是急着下结论，而是做交叉分析。我最常用的是把维度分数和应用场景建立对应关系。
举个具体例子。一个模型在知识理解维度拿到88分，看起来很高，但你的应用场景是长文档问答，需要很强的多轮上下文整合能力，而它在多轮对话维度只有61分。那么“88分很高”这个判断就是错误的，因为你根本不会拿它去做那个场景的任务。
正确的做法是给场景里的每个关键能力设一个最低分数线。比如做代码助手，代码生成维度低于70就一票否决；做客服，指令跟随低于75不考虑。总分只能用于初筛，能不能用要看维度画像是否覆盖场景要求。
6.2 长尾样本的价值
我看评测结果时，除了看平均分，一定会单独拉出两类样本来看：一类是“意想不到的强”，模型答对了大多数同类模型都答不对的题；另一类是“意想不到的弱”，常识性内容却答错了。
这两类样本是迭代模型的富矿。前者说明模型在某类能力上有潜意识的涌现，可以顺藤摸瓜找到训练数据里值得强化的方向；后者往往是数据覆盖不均衡的典型信号。很多团队只看平均分，把这两类样本全丢了，其实丢掉了评测里最有价值的信息。
6.3 评测报告的呈现方式
最后简单说一下评测报告怎么写。给不同的人看，报告的重点完全不同。
给技术人员看，重点是维度明细、错误样本、参数环境，让他们能继续深入排查。给产品人员看，重点是场景映射、能力边界、典型好与坏的案例。给决策者看，重点是一页纸的结论，包含推荐选项、风险提示、成本对比，而不要抛一堆表格让他们自己解读。
我自己习惯在报告里固定放两个部分：信任要素和关键样本。信任要素列清楚评测环境、题集版本、复现方式；关键样本则精选每类维度最有代表性的成功和失败案例。这两块加起来，报告的含金量会比单纯一堆分数高得多。
最后再分享一点个人体会。大模型评测这两年越来越热，但热度并没有让评测变得更容易，反而因为人人都能跑出一堆分数，真正可信的评测反而更稀缺了。我始终觉得，评测的核心不是那个数字，而是你能不能回答出三个问题：这个分数是怎么来的？换一批题还会是这个结论吗？这个结论对我的决策意味着什么？把这三句话想明白，一套评测体系的骨架就已经搭好了。往里面填题量、填维度、填自动化脚本，都只是锦上添花。
