一、为什么大模型“跑分榜”越来越难读

大模型发布时，通常会同时展示多组评测结果，覆盖知识问答、数学推理、代码生成、专业文书、科学分析、工具调用和终端操作等能力。许多读者会自然地把这些数字理解为“同一张试卷上的总成绩”，但现实往往并非如此。

一个看似简单的综合得分，背后可能包含以下变量：

• 多套来源不同、题型不同的评测集；
• 不同任务采用不同的抽样数量；
• 部分任务按答案对错评分，部分任务按生成文件验收；
• 部分结果来自单次运行，部分结果取多次运行均值；
• 不同能力项可能经过归一化后再加权；
• 一些题目公开可见，另一些题目只有评测机构掌握；
• 有些模型允许使用工具，有些模型只能输出文本；
• 有些结果由独立机构复测，有些结果来自模型提供方自行提交。

因此，榜单上的“65分”和另一个页面上的“60分”，未必能直接相减，更不能简单推出前者在所有业务中都强约8%。要正确理解跑分，首先要分清评测对象、评测方法和统计口径。

二、综合指数不是一套固定试卷

1. 综合分通常如何产生

大模型综合指数一般会选取若干能力维度，再将各项结果汇总。其简化形式可以表示为：

综合得分 = Σ（能力项标准化得分 × 能力项权重）

假设某套评测包含五个维度：

知识问答      权重 20%
科学推理      权重 20%
代码任务      权重 25%
专业文书      权重 15%
工具操作      权重 20%

如果模型在各项中的标准化得分分别为72、65、80、70和60，那么示意性的综合计算为：

72×0.20 + 65×0.20 + 80×0.25 + 70×0.15 + 60×0.20
= 69.9

这里的69.9不是“答对了69.9%的题”，而是多个维度经过处理后的加权结果。某些评测还会使用排名分、相对分、胜率或非线性变换，因此综合分与原始正确率之间可能不存在直接对应关系。

2. 为什么不能只问“一共有多少道题”

单一选择题题库可以明确回答题量，例如共500题，每题1分。但综合评测往往把多种任务放在一起：

• 知识任务可能包含数百道短问答；
• 编程任务可能只有几十个问题，但每题需要编写完整程序；
• 终端任务可能数量更少，却要执行多步操作并验证环境状态；
• 专业文书任务可能要求生成表格、报告或演示材料；
• 长上下文任务可能只包含少量样本，但每个样本输入很长；
• 智能体任务可能需要连续调用多个工具，单次运行成本较高。

因此，“题目数量”无法完整反映评测规模。更合理的描述应至少包含：

1. 样本数量；
2. 每个样本的平均步骤数；
3. 输入与输出长度；
4. 是否允许调用工具；
5. 单题是否存在多次尝试；
6. 是否采用重复运行；
7. 总推理成本和执行时长。

一个包含50个复杂环境任务的评测，可能比数千道选择题更能检验模型在实际工程中的稳定性。

三、常见评测能力可以分为哪些类型

1. 知识与事实问答

这类任务主要检查模型是否掌握基础知识、专业概念以及事实之间的关系。题型可能包括选择题、填空题和短问答。

示意题目如下：

某服务在高并发读取场景中出现热点，请从缓存、数据分片和请求调度三个角度分析可能的缓解方案。

这类题目的优点是评分效率高、覆盖范围广；缺点是容易受到训练数据覆盖和题目泄露影响。模型记住答案，不等于真正具备推理能力。

评估知识问答时，应关注：

• 题目是否具有明确答案；
• 是否包含过时知识；
• 是否考查记忆而非理解；
• 是否存在多个合理表述；
• 是否对语言风格给予了不必要的高权重。

2. 数学与科学推理

数学和科学任务不只看最终答案，还可能要求模型展示推导过程、使用单位、处理约束条件并识别无效假设。

示意题目：

某批处理系统每分钟接收1200个任务，单个工作节点平均每分钟处理80个任务。
若希望系统在一个节点故障后仍能消化平均流量，至少需要配置多少个节点？

此类任务可以通过最终数值自动判分，但仍需处理边界问题。例如模型给出正确结果却使用了错误推导，或者推导正确但输出格式不符合解析规则。高质量评测应将“答案正确性”和“推理可靠性”分开记录。

3. 代码生成与软件工程

代码评测的关键不在于代码是否“看起来合理”，而在于能否通过真实测试。常见验证方式包括：

• 编译或解释是否成功；
• 单元测试是否通过；
• 是否满足时间和空间限制；
• 是否正确处理异常输入；
• 是否引入安全问题；
• 是否修改了不应修改的文件；
• 是否完成跨文件依赖调整。

基础代码题通常要求补全一个函数，工程型代码题则可能要求理解现有项目、定位缺陷、修改多个模块并运行测试。后者更接近真实开发，但复现成本也更高。

例如，一个工程任务可能要求：

现有订单服务在重复请求下会产生重复记录。
请定位原因，在不改变公开调用约定的前提下修复问题，并补充覆盖并发场景的测试。

评分不能只检查是否新增了“去重”逻辑，还要验证并发安全、事务边界、失败回滚和已有功能是否受到影响。

4. 终端与环境操作

终端类评测用于检验模型是否能在受控环境中完成多步骤任务。典型过程包括：

1. 阅读任务说明；
2. 检查目录与文件；
3. 执行命令；
4. 分析错误输出；
5. 修改配置或代码；
6. 再次运行验证；
7. 交付最终环境状态。

这类评测与普通问答有本质区别。问答任务只检查文本，而终端任务检查模型是否真的把环境改到正确状态。

其评分通常依据：

• 目标文件是否存在；
• 配置项是否正确；
• 服务是否成功启动；
• 自动测试是否通过；
• 数据结果是否符合约束；
• 是否执行了破坏性操作；
• 最终环境是否可重复验证。

由于模型生成具有随机性，同一个任务运行多次可能得到不同结果。因此，只公布一次成功记录通常不够。更合理的做法是报告多次运行成功率、平均步骤数、超时率和异常退出率。

5. 专业文书与文件交付

企业应用并不只需要回答问题，还常常需要生成可直接使用的交付物，例如：

• 结构化分析报告；
• 项目计划；
• 风险清单；
• 数据表格；
• 培训材料；
• 需求说明；
• 测试方案。

此类评测需要同时考察事实正确性、结构完整性、格式规范和文件可用性。例如，一份报告即使语言流畅，如果遗漏关键风险、引用了不存在的数据或无法正常打开，也不能算合格。

文件类任务适合采用“机器检查加人工复核”的组合方式：

机器检查：
- 文件是否生成
- 格式是否可读取
- 必填章节是否存在
- 表格字段是否完整
人工或模型评审：
- 论证是否充分
- 建议是否可执行
- 内容是否前后一致
- 是否存在事实性错误

6. 工具调用与智能体任务

智能体评测关注模型能否自主规划并调用外部能力。一个任务可能需要检索资料、读取文件、执行计算、更新数据并生成总结。

需要重点观察的指标包括：

• 工具选择正确率；
• 参数填写正确率；
• 无效调用次数；
• 任务完成率；
• 平均执行步骤；
• 总耗时；
• 资源消耗；
• 遇到异常后的恢复能力。

“最终答案正确”并不能覆盖全部风险。模型可能在中间步骤中执行多余操作，甚至尝试修改不相关的数据。因此，企业在评估智能体能力时，还应检查权限边界、操作审计和失败回滚。

四、公开题、隐藏题与数据污染

1. 公开题的价值和局限

公开评测集有利于研究者理解规则、复现结果和定位模型短板。开发者可以在同一套任务上验证提示词、推理参数和系统架构。

但题目长期公开后，可能进入模型训练数据、微调数据或人工优化流程。此时，高分可能来自：

• 直接记住题目与答案；
• 学习了公开解析；
• 针对固定格式进行专门优化；
• 使用包含参考答案的检索数据；
• 反复尝试后选择最佳结果。

这并不意味着公开题完全失去价值，而是其结果需要结合污染风险解释。

2. 隐藏题为什么越来越重要

隐藏题不会提前公布完整内容，能够降低针对性刷分的空间。评测组织者通常只公开任务类型、评分原则和少量示例，将正式样本保留在受控环境中。

隐藏评测仍需解决以下问题：

• 题目是否具有代表性；
• 评分规则是否透明；
• 参测方是否获得相同资源；
• 测试版本是否一致；
• 失败样本是否接受审计；
• 更新题库后历史成绩是否仍可比较。

隐藏不等于可信。一个完全不公开方法的分数同样缺乏解释力。理想状态是“题目内容受控，方法与统计口径透明”。

3. 动态题库与持续更新

为降低污染风险，评测集可以持续加入新题，并定期淘汰已广泛传播的样本。动态题库更接近真实世界，因为业务需求、软件环境和知识内容本身也会变化。

不过，题库更新会带来版本问题。不同时间获得的结果可能来自不同试卷，因此榜单应明确标注：

• 评测版本；
• 样本更新时间；
• 执行时间；
• 评分规则版本；
• 是否对历史模型重新测试。

如果这些信息缺失，就不应把跨版本的细小分差解读为能力提升。

五、评分方式决定了数字能否相信

1. 精确匹配

精确匹配要求输出与标准答案完全一致，适用于格式固定的任务。例如数值答案、分类标签和确定性字段。

优点是客观、快速；缺点是容易误伤语义正确但表达不同的答案。评测方通常需要先进行格式清理，例如去除多余空格、统一大小写或提取最终答案。

2. 程序化验证

代码、计算和文件任务适合使用自动程序验收。相比关键词匹配，程序化验证更接近真实可用性。

例如，评测一个数据处理任务时，可以检查：

输入记录数是否保持一致
必填字段是否完整
聚合结果是否正确
异常记录是否按规则隔离
输出文件是否能够被正常读取

程序化验证也可能存在测试覆盖不足的问题。模型生成的结果通过现有检查，不代表不存在隐藏缺陷。因此，测试用例应覆盖正常路径、边界条件、异常输入和安全约束。

3. 人工评审

开放式写作、方案设计和复杂推理通常需要人工判断。为了降低主观性，可采用：

• 双人独立评分；
• 匿名评审；
• 明确的评分量表；
• 对分歧样本进行复核；
• 定期计算评分者一致性。

评分量表应将维度拆开，而不是只给一个模糊的“整体质量分”。例如：

事实准确性：0—4
任务完成度：0—4
逻辑一致性：0—4
可执行性：0—4
格式规范性：0—2

4. 模型裁判

使用另一个大模型比较答案，可以显著降低开放式任务的评分成本，但模型裁判也可能出现偏差：

• 偏好更长的回答；
• 偏好特定写作风格；
• 受到答案顺序影响；
• 对自身生成风格更加宽容；
• 无法识别专业领域中的细微错误；
• 在缺少参考资料时凭印象评分。

降低风险的方法包括交换答案顺序、多裁判投票、随机抽样人工复核，以及公开评分提示和一致性数据。模型裁判适合提高评测规模，但不应被视为天然客观。

六、同一模型为什么会出现多个成绩

即使模型本身不变，以下设置也可能显著影响结果：

• 系统指令不同；
• 是否启用推理过程；
• 输出随机性设置不同；
• 最大输出长度不同；
• 是否允许重试；
• 是否提供工具；
• 工具执行超时时间不同；
• 上下文是否包含示例；
• 是否采用多次采样后择优；
• 是否计算额外推理预算；
• 并发压力和网络错误处理不同。

例如，“单次直接回答”和“最多尝试五次后选出最佳结果”并不是同一评测条件。后者可能获得更高成功率，但成本和延迟也会增加。

因此，完整的成绩记录至少应包含：

模型版本
评测集版本
执行日期
输入模板
采样设置
最大输出限制
工具权限
重试规则
运行次数
评分程序版本
平均成本与延迟

缺少这些信息的数字只能作为线索，而不能作为严格结论。

七、如何判断几分差距是否有意义

榜单中相差一两分，可能是真实能力差异，也可能只是抽样误差和运行波动。判断差距是否可靠，需要关注统计信息。

假设某评测只有100个独立样本，模型A完成62个，模型B完成60个。仅凭62%与60%无法断定A稳定优于B，因为换一批样本或重新运行后，结果可能反转。

更稳妥的做法包括：

1. 增加样本规模；
2. 对随机任务重复运行；
3. 报告均值与波动范围；
4. 使用配对比较，观察两者在相同样本上的输赢；
5. 按任务类型拆分结果；
6. 检查差异是否集中在少数异常题；
7. 同时比较成本、延迟和失败率。

企业选型时，与其追求综合分高出零点几分，不如确认优势是否落在关键业务能力上。例如，客服场景更关注事实准确性、拒答边界和响应时延；研发场景则更关注代码修改成功率、测试通过率和上下文理解能力。

八、官方成绩与独立复测应如何看待

模型提供方通常最了解自身能力和最佳使用方式，其成绩有助于读者快速认识能力边界。但官方测试可能采用经过优化的提示、推理预算或执行环境，因此不一定代表普通用户的默认体验。

独立复测的价值在于：

• 使用统一脚手架；
• 对多个模型采用相近条件；
• 降低选择性报告；
• 提供横向比较；
• 更容易暴露复现问题。

独立评测也并非绝对中立。题目选择、能力权重、预算限制和评分偏好都会影响排名。判断一份独立成绩单是否可靠，可以检查：

• 是否公开方法；
• 是否说明资金或利益关系；
• 是否记录模型和题库版本；
• 是否允许复核失败样本；
• 是否解释异常数据；
• 是否同时报告质量、成本和速度；
• 是否对方法更新提供变更说明。

最可靠的决策方式不是迷信某一张榜，而是交叉参考官方结果、独立复测和企业自己的业务测试。

九、企业如何建立一套可复现的内部评测

1. 从业务风险出发定义能力

不要先收集热门题库，再思考这些分数有什么用。应先列出真实业务中的关键任务与失败后果。

例如，企业知识助手可以拆分为：

• 能否找到相关资料；
• 能否基于资料准确回答；
• 能否标注证据来源；
• 资料不足时是否会承认不确定；
• 是否泄露无权访问的信息；
• 多轮追问后是否保持上下文一致；
• 响应时间是否满足要求。

每个能力都应对应具体样本和验收标准。

2. 建立分层题库

内部题库可以分为三层：

基础层

检验通用能力，如信息抽取、分类、摘要和格式遵循。此类任务应尽量自动评分。

业务层

使用脱敏后的真实业务样本，覆盖常见流程、专业术语和历史故障。业务层最能反映模型上线后的实际表现。

对抗层

专门测试高风险情况，例如指令冲突、越权请求、虚假前提、异常长输入和恶意内容。对抗层不一定占据很高权重，但应设置明确的上线门槛。

3. 同时设计平均指标与底线指标

平均分高并不意味着可以上线。一个模型可能在普通问题上表现优秀，却在少量关键任务中产生严重错误。

因此建议同时设置：

平均指标：
- 总体任务完成率
- 平均事实准确率
- 平均响应时间
- 单次任务平均资源消耗
底线指标：
- 高风险错误数必须低于阈值
- 越权操作必须为零
- 特定关键流程成功率不得低于要求
- 敏感数据泄露不得出现

平均指标用于比较方案，底线指标用于判断是否具备上线资格。

4. 固化运行环境

评测流程应尽可能自动化，并记录每次运行的配置。示意流程如下：

读取固定版本样本
  ↓
构造统一输入
  ↓
调用待测模型
  ↓
保存原始输出与运行日志
  ↓
执行自动评分
  ↓
抽样进行人工复核
  ↓
生成分项报告
  ↓
与历史版本做回归比较

不能只保存最终分数。原始输入、模型输出、工具调用轨迹、错误日志和评分结果都应可追溯，否则一旦成绩异常，就难以定位原因。

5. 控制评测数据泄露

内部评测集不应直接进入日常提示模板或训练材料。可以采用以下措施：

• 将开发集与正式测试集分离；
• 限制正式题库访问权限；
• 定期更换部分样本；
• 对题目进行语义变体生成后人工审核；
• 记录每个样本的创建和使用历史；
• 防止团队围绕固定答案过度优化。

如果模型在开发集上持续提升，但在隐藏测试集上没有同步改善，往往说明方案出现了过拟合。

十、读榜单时可以使用的检查清单

面对任何大模型跑分页面，可以依次提出以下问题：

关于评测对象

• 测试的是哪个具体版本？
• 是默认模式还是高推理预算模式？
• 是否允许调用外部工具？
• 是否允许多次尝试或择优输出？

关于题目

• 评测覆盖哪些能力？
• 样本规模和任务复杂度如何？
• 题目是公开、隐藏还是动态更新？
• 是否存在训练数据污染风险？
• 题目是否接近目标业务？

关于评分

• 使用精确匹配、程序验收、人工评审还是模型裁判？
• 开放式任务是否有明确评分量表？
• 是否公布评分者一致性？
• 是否对失败样本进行人工复核？

关于统计

• 是单次结果还是多次均值？
• 是否报告误差范围？
• 小幅差距是否具有统计意义？
• 是否存在少量异常样本拉高或拉低总分？

关于工程成本

• 完成任务需要多少次模型调用？
• 平均响应时间是多少？
• 超时率和失败率如何？
• 是否使用了额外工具或大量计算预算？
• 在相同预算下，结果是否仍有优势？

关于复现

• 是否提供完整方法说明？
• 是否记录题库和评分版本？
• 不同模型是否在相同环境运行？
• 历史成绩是否因规则变化而重新计算？

十一、正确使用跑分的核心原则

大模型评测的价值，不是制造一个永远正确的总排名，而是提供结构化证据，帮助使用者理解模型在不同任务中的能力边界。

综合分适合快速筛选候选方案，但不能替代分项分析；公开题适合复现和研究，但需要警惕数据污染；隐藏题能降低刷分风险，却仍需要透明的方法；模型裁判可以扩大评测规模，但必须通过人工抽检和多裁判机制控制偏差；终端与智能体任务更接近真实工作，同时也更依赖统一环境、重复运行和严格审计。

对于开发者和企业用户，最实用的判断方式可以概括为三步：

1. 先看评测方法，而不是先看排名。
2. 再看分项能力是否匹配业务，而不是只看综合分。
3. 最终用自己的样本、预算和风险要求完成复测。

榜单可以告诉我们“值得进一步测试谁”，却很难单独回答“最终应该选择谁”。只有当题目、环境、评分、成本和业务目标处于同一套可解释框架中，跑分才会从营销数字变成真正有用的工程证据。