打开任何一个大模型排行榜，你看到的通常是这样一个画面：某个模型排在榜首，综合得分 87.3，另一个模型排在后面，得分 79.1。很多人会下意识地认为，87.3 是“模型能力强”的刻度尺读数，79.1 是“能力稍弱”的读数。但如果我告诉你，这个读数和“评测时调整了哪些参数、用了什么模板、写了多少个示例、评分怎么解析”深度绑定，甚至同一个模型换一套评测配置后，得分可以从 31% 跳到 89%，你对排行榜的信心还会那么足吗？
这不是危言耸听。近期一篇专门研究大模型评测配置的论文，用一个非常直观的案例把这个问题摆到了台面上：被记为 gemma4-31b 的模型——你可以把它理解为一个约 31B 参数规模的开源模型实例——其得分并不是稳定在一个点附近，而是可以在 31% 到 89% 这个极宽区间内波动。换算成通俗说法，就是同一个考生，换一种考法，成绩一会儿像“连题都没读懂”，一会儿像“全校前几名”。论文的结论也因此非常尖锐：LLM 排行榜的名次，很大程度由评测配置决定，不只是由模型本身的真实能力决定。
这篇文章想和你聊清楚三件事：评测配置到底包含哪些变量，为什么它们能带来如此夸张的分数波动，以及作为工程师，在模型选型、内部迭代和技术报告发布时，应该怎样设计一套能经得起追问的评测流程。如果你正在用排行榜选模型、给模型做 benchmark，或者要向团队汇报“A 模型比 B 模型强 3 个点”，那么这篇文章就是写给你的。
1. 为什么 LLM 排行榜正在失去“标尺”意义
传统软件评测有一个隐含前提：测量对象在固定条件下可以稳定复现。你测试 MySQL 的 QPS，只要硬件、版本、参数、压测脚本不变，跑十次的结果基本不会离谱。数据库优化、排序算法、RPC 框架的基准测试，都有资格被称为“标尺”，因为测量环境相对可控。
但大模型评测完全不符合这个前提。模型不是一个输入固定输出的确定性函数，它本质上是“根据输入文本不断预测下一个 token”的概率系统。输出结果对输入语境、采样参数、输出解析方式极其敏感。同一道逻辑题，你把它包装成中文口语和英文 formal instruction，答案可能不一样；你在 prompt 前面加一个示例和加三个示例，正确率可能明显不同；你让模型“直接输出答案”还是“先分析再输出答案”，后处理解析时会不会漏掉答案，都会导致分数发生显著变化。
更麻烦的是，评测分数在现代技术传播中经常被“广告化”。少数厂商和团队愿意公开完整评测配置，更多时候我们看到的只是一个漂亮的综合分数。可是，这个分数到底是在哪个测试集子集上算出来的？提示词是谁写的？few-shot 给几个示例？temperature 设了多少？答案匹配是宽松还是严格？这些细节每一项都可能左右结果。那些在排行榜上看起来只差一两个点的模型，很可能并非能力差距，而是评测配置的差距。
对开发者来说，这个问题的代价是真实的。你在选型时基于某个排行榜把模型 A 换成了 B，结果线上任务指标反而下降，这就是典型的“榜单分数与真实场景脱节”。你在做模型迭代时，新版本分数提升了 2 个点，但实际只是新版模型的输出格式更贴合你的解析器，推理能力并没有提升。你向老板汇报“我们模型进入某榜前三”，最后别人复现时却完全得不到同样结果，这对技术团队的信任是直接伤害。
所以，面对任何 LLM 榜单，最稳妥的判断是：把“模型在 XX 榜上得了多少分”理解成“该模型在某组特定评测配置下达到的报告值”，而不是“该模型能力的绝对刻度”。这不是要求你怀疑一切，而是要求你多看一层方法论。
2. 评测配置到底包含哪些变量
要理解评测配置为什么能造成 31% 到 89% 这种量级的差异，得先弄清楚一条完整的模型评测流水线由什么组成。
一条典型的离线评测链路是：评测数据集 → Prompt 构造 → 模型推理 → 输出解析 → 指标计算。听起来只有五步，但每进入一步，你都要面对很多可调选项。
2.1 提示词与上下文模板
这一层最容易被忽略，也最容易造成差异。同样是让模型做多选题：
- system prompt 用语不同：是“你是一个可靠助手”，还是“请严格按要求作答”；
- 题目是中文还是英文；
- few-shot 示例给 0 个还是 5 个；
- 有没有要求先输出推理过程；
- 输出格式是“直接写 A/B/C/D”，还是“以 JSON 返回”。
上述每一种变化都会改变模型看到的 token 序列。大模型不会自动“翻译”成统一的语义，它会对不同表述产生不同响应。你实际比较的，往往不是“两个模型的解题能力”，而是“两个模型在该 prompt 模板下的模式匹配能力”。
2.2 解码与生成参数
模型推理阶段的输出也并非铁板一块。
- temperature 越高，采样越随机，同一道题可能给出不同答案；
- top_p、top_k 会影响候选 token 的截断范围；
- max_tokens 太短，模型可能没写完就被截断，导致后处理阶段拿不到最终答案；
- seed 是否固定，也直接关系到实验能否复现；
- 甚至同样设置 temperature = 0，不同推理框架、不同 batch size 下的浮点计算顺序也可能带来微小但不可忽略的差异。
如果你在评测时使用 temperature = 0.3 甚至更高，而又不固定 seed、不多次采样取平均，那么榜单成绩本身就会带有较大随机性。
2.3 数据集与任务口径
这是评测配置里最“高阶”的旋钮。同一份 benchmark，选择不同子集、不同数量题目、不同题目顺序，都可能直接影响得分。
更要警惕的是数据污染问题。很多开源评测集已经被大规模爬进训练语料，新模型可能不是“会做”这些题，而是“见过”这些题。如果评测团队没有对评测集做污染检测和过滤，所谓的高分就很难反映真实泛化能力。
2.4 输出解析与评估方法
模型输出是自然语言，不是标准的程序返回值。怎么从模型生成的文本中判断“答对了”，本身就是一个主观且容易出错的环节。
- 严格字符串匹配：只有输出与参考答案完全一致才算对；
- 宽松解析：允许先写推理过程，再提取最后答案；
- 用大模型当裁判：让 GPT-4 或另一个模型给结果打分。
这套逻辑对低分和高分的影响巨大。一个模型如果很懂推理但格式略微放飞，在严格解析下可能直接得 0 分；另一个模型只会输出一个标准格式的答案，反而拿满分。这说明排行榜测的不仅是知识，更可能是“格式纪律”。
2.5 运行环境与模型加载方式
模型权重是 fp16 还是 int8，是否量化，上下文窗口开了多少，推理使用哪个框架，这些属于最后一层影响因素。它们通常不会让结果从 31% 跳到 89%，但足以让复现者发现“分数对不上”。
上面任何一个变量单独变化，可能只让分数产生几个点的浮动；但如果多个变量一起变化，分数就可能彻底“失锚”。论文提到 gemma4-31b 的得分在 31% 到 89% 间波动，正是这种多变量叠加的极端表现。它本质上在提醒研究者：评测配置是一套完整的考试制度，而不是一句可以忽略的“实验参数”。
3. 同一个模型分数从 31% 到 89%，说明什么
3.1 分数跨度的含义
很多模型在论文中报 benchmark 分数时，通常只给一个点估计，比如“准确率 67.5%”。你很难意识到，这个点估计背后可能存在远超统计噪声的不确定性。
31% 到 89%，差值约 58 个百分点。如果某一组评测配置下准确率只有 31%，通常会被认为“这个模型基本不能用”或者“在任务上远弱于主流模型”；而 89% 在很多公开榜单上已经是相当漂亮的成绩。也就是说，评测配置的不同，可以把同一个模型从“不合格”推到“优秀”，能力评价出现质变。这不是量级的微调，而是完全不同的结论。
需要说明的是，我们并不掌握论文实验中每一组配置的具体细节，因此不能强行断言“到底哪个变量把分数推到极低或极高”。但从常识推断，这种跨度通常来自多层变量叠加：prompt 模板、任务子集、few-shot 设置、解码参数、答案抽取规则、甚至评测数据本身的污染风险，共同形成了一个放大系统。任何一个环节设计得不合理，都足以让分数失真。
3.2 对榜单排名的连锁反应
一个模型已经可以出现如此大的分数漂移，不同模型之间的差距就更不该被当成精确值。很多时候，榜单上第一名与第十名之间的综合分差距，可能只有 5 到 10 个百分点。而 58 个百分点的单模型波动，已经远远超过排行榜上头部模型之间的常见差距。
这意味着，只要换一套评测配置，很多模型的相对名次都可能发生大规模重排。所谓“第一名和第二名差 0.5 分”，在缺少误差区间和配置透明度的情况下，并没有太强的决策价值。论文的标题里用了“名次很大程度由评测配置决定”这样直接的表述，恰好在提醒行业：当测试方法不稳定时，排名本身就可能是一种幻觉。
4. 为什么大模型评测如此容易波动
理解了评测配置的分类，还需要从底层机制上明白，为什么模型行为对配置如此敏感。这也是很多做传统软件评测的工程师跨界过来时最不适应的地方。
4.1 条件语言模型的本质
从数学视角看，大模型是一个条件概率模型，每一轮生成都在估计 P(next_token | context)。context 包含全部历史 token，包括系统提示词、会话历史、任务描述和当前输入。模型并不会把“语义”和“格式”分开处理，格式上的变化会直接改变 token 概率分布。
更麻烦的是，生成是自回归的。前面任何一个 token 的概率变化，都可能被后续生成步骤放大。prompt 里一个标点符号、一个空行的变化，在极端情况下可能让模型走向完全不同的回答路径。这是大模型评测天然比传统软件评测更“脆”的根本原因。
4.2 指令遵循能力还没有达到人类那样的鲁棒性
对人类来说，“请回答以下问题”和“Please answer the following question”含义基本相同。但模型对指令语言的敏感度通常很高。同一个模型在英文 prompt 下表现很好，换成中文 prompt 后可能明显下降；反过来也一样。这种差异并不代表模型“不懂中文”，而是它在训练数据中见过的指令分布更偏向某一种语言风格。
在实际评测中，如果所有模型都用同一套英文模板测试，那些在英文 prompt 上训练更充分的模型会显得更强；如果换成中文模板，排名就可能变化。评测团队必须在报告中明确说明 prompt 语言和模板来源，否则不同榜单之间完全不可比。
4.3 少样本示例实际上在“改写任务”
few-shot 示例看似是公平的，它把任务要求具象化了。但示例的选择并不中性。
如果你给的示例总倾向于某个选项或某种回答结构，模型可能学到这种偏好。它甚至会照搬示例中的格式，而不是真正理解示例背后的规则。0-shot 和 5-shot 之间的分数差异，在很多任务上可以轻松超过 10 个百分点。一旦评测方对模型 A 使用 5-shot，对模型 B 使用 0-shot，排名就已经失去了公平基础。
4.4 解码随机性没有被真正控制
很多榜单没有公开采样参数。即便公开了 temperature，也不一定固定 seed，更不会重复多次实验并报告方差。在随机采样模式下，同一模型在同一评测集上的两次运行，可能出现明显差异。
业界通常建议，面向严肃评测时把 temperature 设为 0，并固定 seed；如果任务需要采样多样性，就重复运行多次，取中位数或均值，同时报告标准差。可惜，很多评测并没有遵守这样的纪律，读者自然无法判断榜单分数是偶然的一次抽样，还是稳定结果。
4.5 数据污染和子集选择会在无形中改写排名
公共 benchmark 的另一大隐患是数据污染。假如模型训练时见过 GSM8K 或 MMLU 的题目，它在这些测试集上的分数就不再代表推理能力，而更像是记忆检索能力。新模型往往在这方面占便宜，因为它们的训练语料更新、更全。
另外，评测集子集的难度分布并不均匀。模型 A 可能在某种难度的子集上很强，模型 B 在另一种子集上更强。如果只报告一个汇总平均分，或者只挑选对自家模型有利的子集，排行榜的说服力就会被严重削弱。
4.6 答案抽取和 LLM 裁判是失真的高发区
在数学和代码类任务中，输出解析往往直接决定生死。一个模型有完整的推理过程，但最后一行没有按“答案是 X”的标准格式输出，就会被严格正则记为零分；另一个模型完全不懂推理，只是学会了“把最后一行写成 X”的格式，反而可能得分。此时，评测衡量的是模型对输出格式的遵循能力，不是目标能力。
采用 LLM 作为评分器时，问题会转移到裁判模型身上。裁判模型本身的偏好、提示词、温度、甚至被评答案的排列顺序，都会影响打分结果。论文中 31% 到 89% 的波动，放在这种多误差源叠加的框架下，就不难理解了。
5. 动手实践：给模型做一次“配置敏感性自检”
从工程角度看，与其盲目相信某个榜单，不如建立自己的“配置敏感性自检”流程。你不需要复现论文里的全部实验，只需用一个小规模任务和几组差异明显的配置，就能判断某个模型的分数到底稳不稳。
5.1 定义最小配置矩阵
我们以一个多选问答任务为例，准备 200 条样本即可。目标不是刷高分，而是观察同一模型在不同配置下的分数区间。建议至少准备三组配置：
- 零样本 + 中文精简 prompt + 严格执行格式 + temperature = 0
- 三样本 + 英文 prompt + 允许自由推理 + 宽松抽取 + temperature = 0.3
- 五样本 + 带格式约束 prompt + 严格抽取 + temperature = 0
这三组配置分别模拟了“保守评测”“宽松评测”“指令跟随评测”三种视角。如果模型在这三组配置下的得分差距很小，说明它在该任务上更稳定；如果差距很大，你就应该警惕任何以单点分数展示的排名。
5.2 用 YAML 描述评测配置
为了让评测可复现，第一件事是把配置工程化。下面是一份 YAML 示例，描述一组评测配置。
# 文件路径：configs/eval_strict_zero.yaml model_id: gemma4-31b task_file: data/qa_dev_200.csv prompt_template: templates/zero_shot_zh.md num_fewshot: 0 temperature: 0.0 top_p: 1.0 max_tokens: 256 answer_extraction: strict再准备另一组宽松配置。
# 文件路径：configs/eval_loose_3shot.yaml model_id: gemma4-31b task_file: data/qa_dev_200.csv prompt_template: templates/few_shot_en.md num_fewshot: 3 temperature: 0.3 top_p: 0.9 max_tokens: 512 answer_extraction: loose为什么要把这些内容写进 YAML？因为“评测配置”同样是代码仓库的一部分。如果只写在 README 或聊天记录里，过两个月就很难追溯；写在配置文件里，就可以进 Git，可以评审，也可以自动化批量执行。
5.3 批量执行脚本示例
下面这段 Python 脚本是一个“配置敏感性自检”的骨架。它会遍历 configs 目录下所有 YAML 配置，依次执行评测，并输出分数区间。run_model 和 parse_answer 需要你根据实际推理后端来实现，脚本提供了一个清晰的调用框架。
# 文件路径：sensitivity_check.py import csv import glob from statistics import mean, median import yaml def load_samples(task_file: str): """读取评测样本，CSV 中需要包含 question 与 ground_truth 两列。""" with open(task_file, encoding="utf-8") as f: return list(csv.DictReader(f)) def build_prompt(sample, cfg): """根据配置中的模板文件构造 prompt。""" with open(cfg["prompt_template"], encoding="utf-8") as f: template = f.read() if cfg["num_fewshot"] == 0: return template.format(question=sample["question"]) demonstrations = "" for i in range(cfg["num_fewshot"]): demonstrations += f"示例{i + 1}：示例题目\n答：示例答案\n" return template.format( demonstrations=demonstrations, question=sample["question"] ) def run_model(prompt, cfg): """ 实际项目中，请在这里接入你的推理后端： - vLLM / TGI / Ollama 等 OpenAI 兼容接口 - HuggingFace pipeline - 云端模型 API 下面只保留接口占位，避免直接运行产生误导。 """ raise NotImplementedError("请按你的模型服务实现 run_model") def parse_answer(raw_output, rule): """根据 strict / loose 抽取答案。""" if rule == "strict": return raw_output.strip() # loose 模式：尝试定位“答案是”等提示词后的内容 lowered = raw_output.lower() for keyword in ("answer:", "答案是", "最终答案"): if keyword in lowered: return lowered.split(keyword)[-1].strip() return raw_output.strip() def evaluate(preds, golds): correct = sum(1 for p, g in zip(preds, golds) if p == g) return correct / len(golds) def main(): config_files = sorted(glob.glob("configs/eval_*.yaml")) scores = {} for cfg_file in config_files: with open(cfg_file, encoding="utf-8") as f: cfg = yaml.safe_load(f) samples = load_samples(cfg["task_file"]) preds = [] golds = [s["ground
