从模型规模到实际效果：基础模型能力评估为何不能只看单项榜单

生成摘要

AI 生成，仅供参考

公开榜单上的名次，描述的是某次测试里的相对位置，不是基础模型在所有任务上的通用能力。大语言模型被放到不同题目、提示和计分规则下，会交出彼此不能直接相加的分数；语言理解、推理能力、代码生成、工具调用和长上下文，各自只覆盖真实使用中的一个切片。把单项高分当成“模型已经全面更强”，往往会在上线后发现：换一种问法、换一批材料，或要求它真的去调用外部工具时，表现并不跟着榜单移动。

评测要回答的问题其实很窄：在这份材料、这种提示、这种解码方式和这种评分标准下，模型输出与预期有多接近。分数同时受任务分布、提示模板、评判者和随机抽样影响。同一模型换一套题，名次可以改变；同一套题换一种提示，分数也会动。因此，读结果之前先要看清系统由哪些部分组成，而不是只看最后一列数字。

评测系统在测量什么

一次可复现的模型评测，至少包括任务样本、输入模板、生成配置、评分规则和运行环境。样本决定“像不像你的问题”，模板决定模型被允许怎样作答，生成配置决定温度、长度和是否允许多次采样，评分规则决定什么样的差异算错。运行环境则把上下文长度、可用工具和超时限制写进条件里。少报其中任何一项，别人就无法判断这个分数能不能在自己的系统里重现。

公开实践里常见两类组织方式。一类是统一评测框架，把多项基准接到同一接口上运行，便于横向比较，也便于固定随机性和提示格式；HELM 和 LM Evaluation Harness 属于这一类工具。另一类是平台里的基线评测与自定义评测：基线多用行业标准题集查看通用表现，自定义则按业务标签、数值、字符串匹配、文本相似度或人工标准打分。有的流程明确把标准题集用于观察微调之后的相对变化，而不是给所有预设模型做一次总排名。用途不同，同一套题目的读法就不同。

语言理解与指令遵循

以 MMLU、C-Eval 为代表的标准题集，多考查学术知识、数学与科学常识等，题型往往封闭，答案可以自动核对。它们能说明模型在既定选项或标准答案下是否选对，对比较“知道不知道”很有用，却很少告诉你：用户把需求写成一段含糊指令时，模型会不会追问、会不会漏掉约束、会不会用错语气。

对话与指令遵循类测试，例如常被提及的 MT-Bench、AlpacaEval，更关心回答是否有帮助、是否贴合指令。这类榜单经常让另一个模型充当评判者，按质量给分。这样做扩展了开放题的覆盖面，也把评判模型的偏好写进了分数：更长、更礼貌、更像评判者常见答案的文本，可能得到更高分，即使关键事实并没有更正确。

推理能力

推理题若有唯一答案，自动评分很干净，适合看计算、逻辑和多步推导的终点对不对。终点正确不等于路径可靠。模型可能跳步、用错中间结论，却碰巧撞上答案；也可能步骤清楚，只在最后一位出错。只公布准确率时，这两种情形会被记成同一类失败或同一类成功。

开放式推理更难打分。标准答案无法穷尽时，人工或模型评判都要依赖量表：是否使用了给定条件、是否承认不确定、是否在约束内停止。量表一改，排名就可能改。所以推理能力的高分，应理解成“在这类封闭或半封闭题目上更常到达可接受终点”，而不是“任何需要想一步的任务都会更稳”。

代码生成

代码生成通常用隐藏测试、用例通过率或多次采样中的通过情况来计分。它回答的是：生成结果能不能在这组测试下跑通。它通常不回答仓库里的命名是否一致、依赖是否已存在、错误处理是否过宽、改动会不会破坏邻近模块。通过单元测试的片段，仍可能无法合并进真实项目。

若任务是补全函数，高分说明局部合成能力较强；若任务是在多文件工程里按接口改行为，评测就必须提供仓库上下文、构建命令和失败日志。没有这些条件的代码榜，不能直接外推到工程助手。安全相关输出同理：测试集没覆盖的注入、越权或危险默认值，不会出现在通过率里。

工具调用

工具调用看的是行为，不只是措辞。模型要判断该不该调用、选哪个工具、参数是否符合约定、失败后是否重试或改口。只评最终自然语言的对话基准，可能给一段从未真正调用工具的流畅回答高分；放到智能体流程里，这一步就是失败。

评这项能力时，至少要固定工具清单、参数模式、返回格式和超时。工具结果本身有噪声时，还应记录模型是复述了错误结果，还是根据模式发现了异常。否则，分数混在一起，分不清是模型不会调用，还是工具接口不稳定。

长上下文与当场学习

长上下文测试若只要求从很长材料里找回一条指定事实，测到的是定位，不是理解。真实材料常常前后矛盾、版本过期、格式不齐，用户要的是按当下上下文做决定，而不是复述模型参数里已经记住的常识。

有研究指出，现有训练更偏向让模型推理“已知”内容，而许多真实任务依赖杂乱、会变化的上下文；并为此构造了考察 context 学习的评测，看模型能否从当次给出的材料里形成可用规则。这类设计提醒我们：上下文窗口变长，只说明装得下更多文本，不说明模型会优先服从这些文本，更不说明它能在冲突信息中保持稳定。

单项高分为什么搬不进真实任务

测试集为了可评分，会把任务收成稳定分布：题干完整、答案确定、格式统一。生产环境则是残缺需求、多轮改口、权限限制和迟到的反馈。分布一变，榜单上的差距可能缩小、消失，甚至反向。

场景迁移失败通常不是神秘的“泛化不够”四个字就能解释的。输入语言变了，选项题上的知识优势可能用不上；输出必须严格符合内部模板时，开放对话里的高分风格会变成负担；必须引用给定文档时，参数里的旧知识可能主动覆盖文档。评测没有把这些约束写进题目，模型就没有在这项能力上被测量过。

下面的对照只说明测量范围，不代表任何模型的高低。

分数会被哪些因素推高或压低

数据污染

若题目、答案或高度相似的改写已经进入预训练或后训练数据，模型可能在“回忆”而不是在“求解”。污染会让公开基准偏乐观，而且越常用的榜越难保证干净。私有的、晚于训练截止日期采集的业务样本，更有机会露出这种虚高。比较微调前后时，也要确认新增数据没有把评测题本身学进去，否则提升无法归因到能力。

提示词与评判设计

少样本示例、思维链提示、系统指令、输出格式约束，都会改变得分，却不必然改变模型权重。调参者若反复对着同一评测集改提示，直到分数好看，这个分数测量的是“提示加模型”，而且过拟合了这套题。换一批同分布的新题，提升就可能缩水。

自动规则适合有标准答案的题；文本相似度和字符串匹配适合格式固定的输出；分类量表适合质检标签。开放回答若交给另一个大语言模型打分，成本较低，但评判者的长短偏好、立场和自身错误会传递下去。人工评测能发现规则漏掉的问题，却更慢，而且评分人之间需要校准。没有写明评判者是谁、量表如何措辞，开放题分数就缺少可比性。

成本与重复运行

完整跑一遍多基准、多提示、多次采样，费用和时间都高。团队因此会抽子题、只跑一次或只报最好的一次。子题越小，偶然波动越大；只报最好的一次，会把抽样运气写成能力。工程上更有用的是同一协议下的重复结果：中心水平、波动范围，以及失败集中在哪一类。波动大于模型之间的差距时，名次没有决策价值。

时延、调用次数和上下文开销也应记入同一张表。一个略低分但稳定、便宜、可在时限内返回的模型，可能比极高分但无法按同一协议复现的结果更适合上线。评测若只优化准确率，会系统性偏向昂贵配置。

从基准到业务的迁移

学术题、考试题和客服工单、内部代码、合同审查不是同一分布。中文标准集上的优势，不能保证英文接口文档上的指令遵循；代码题上的通过率，也不能保证工具参数填写正确。迁移前应先写清失败长什么样：是事实错、格式错、漏约束、误调用，还是在长材料中引用了过期段落。失败类型不同，该补的是数据、提示、工具，还是换模型，结论完全不同。

用来选型的判断顺序

把公开榜当作候选筛选，而不是验收标准。筛选之后，用与上线分布接近、且没有参与提示调优的样本做复核。样本不必一开始就很大，但要覆盖你真正不能接受的错误，并在协议冻结后尽量少改。

可以按同一顺序比较候选模型，避免每个模型一套“最有利提示”：

冻结任务样本、提示模板、解码参数、工具与上下文上限
对每个候选模型：
  生成输出
  按预先写好的规则记录得分与失败类型
  同时记录时延、调用量和成本
若模型间差距不大于重复运行的波动，则视为未区分
再用未参与调参的业务样本复核一次

解读时分开看五件事，而不是合成一个“综合 intelligence”分数。指令是否被遵守，给定材料是否被优先使用，推理终点是否在约束内，代码或工具动作是否可执行，长输入下错误是否随长度明显变多。这五件事有一项不满足业务底线，其他项的领先就不足以采纳。

基线题集适合观察模型是否保住了通用题目上的水平，尤其是微调之后有没有退步；自定义题集适合决定能不能进你的流程。两者都要保留题目版本和评分脚本。模型、提示或检索材料一变，就应重跑，而不是沿用几个月前的截图。公开名次可以作为背景，不能代替这次运行。

技术突破若只体现在某一基准的抬升上，还需要同一协议下的重复、贴近场景的失败分析和可接受的成本，才能判断它是否变成了稳定效果。做不到这三步，更稳妥的说法是：这项指标变好了，其余能力仍未被这次测试测量。