打开任何一个大模型排行榜你看到的通常是这样一个画面某个模型排在榜首综合得分 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, encodingutf-8) as f: return list(csv.DictReader(f)) def build_prompt(sample, cfg): 根据配置中的模板文件构造 prompt。 with open(cfg[prompt_template], encodingutf-8) as f: template f.read() if cfg[num_fewshot] 0: return template.format(questionsample[question]) demonstrations for i in range(cfg[num_fewshot]): demonstrations f示例{i 1}示例题目\n答示例答案\n return template.format( demonstrationsdemonstrations, questionsample[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, encodingutf-8) as f: cfg yaml.safe_load(f) samples load_samples(cfg[task_file]) preds [] golds [s[ground
评测配置决定大模型排行榜？从31%到89%的分数波动真相
打开任何一个大模型排行榜你看到的通常是这样一个画面某个模型排在榜首综合得分 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, encodingutf-8) as f: return list(csv.DictReader(f)) def build_prompt(sample, cfg): 根据配置中的模板文件构造 prompt。 with open(cfg[prompt_template], encodingutf-8) as f: template f.read() if cfg[num_fewshot] 0: return template.format(questionsample[question]) demonstrations for i in range(cfg[num_fewshot]): demonstrations f示例{i 1}示例题目\n答示例答案\n return template.format( demonstrationsdemonstrations, questionsample[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, encodingutf-8) as f: cfg yaml.safe_load(f) samples load_samples(cfg[task_file]) preds [] golds [s[ground