LLM排行榜分数不可尽信：评测配置才是关键

LLM 排行榜名次很大程度由评测配置决定——看到这个结论很多人第一反应是怀疑但一篇论文给出了更直观的例子被评测的 gemma4-31b得分可以在 31% 到 89% 之间波动。也就是说同一个模型面对的可能是同一类能力项只是因为 prompt 模板、采样参数和答案解析方式不一样就能从榜单底部冲到榜单顶部。先说明一句这个具体模型标识和论文里的详细复现条件我没有看到足够完整的官方材料所以这篇内容不把模型本身当成重点去展开。真正值得展开的是它揭示的问题大多数排行榜上的分数本质上是“评测配置 模型能力”的混合结果而评测配置这个变量往往被选型的人忽略了。如果你平时靠排行榜挑模型或者正在给自己的业务做模型评测这篇内容会帮你拆清楚为什么分数不可比、评测配置到底影响什么、怎么在自己的真实场景里跑出一份可信的评测结果。1. 为什么排行榜上的名次可能不是“能力排名”1.1 论文结论最值得先看的一点这篇论文最直接的贡献不是告诉你“某个模型很强或很弱”而是把评测过程变成了受控变量然后证明只要评测配置变化同一个模型的得分区间可以大到让人无法做任何能力判断。如果不限制评测配置排行榜上的名次更像“当前评测工程师选择了什么答案格式”而不是“模型实际能解决什么问题”。这对两类人影响很大。第一类是直接用榜单做技术选型的人。看到某个模型在榜单上排在前面就把它接到 agent、知识库、文档处理或者客服场景里。等上线后发现效果不对又回头怀疑模型本身有问题。但真正的问题可能出在榜单任务和你的任务不一样榜单 prompt 和你的调用方式不一样榜单的评分标准也没覆盖真实用户说的那些话。第二类是做大模型应用开发的人。很多团队在多个模型之间做 A/B但因为评测配置不固定今天测出的模型 A 高明天换个 prompt 变成模型 B 高。整个评测过程不仅没法指导选型还会让团队内部对“谁更好”吵来吵去。所以这篇内容不是让你彻底不信排行榜而是告诉你榜单能看但要看它的配置边界。1.2 名次和配置的关系三个常见误解第一个误解是“排行榜名次代表真实世界能力”。绝大多数公开榜单都是在固定任务、固定题库、固定 prompt 下跑出来的结果。比如选择题任务只衡量模型选择正确选项的能力不会衡量它是否能在复杂文档里找到准确信息也不会衡量它在长对话里的稳定性。真实业务往往比单个 benchmark 复杂得多。第二个误解是“平均分高的模型综合能力更强”。排行榜为了给出一个直观的大排名通常会把多个 benchmark 的分数做平均。这个操作会掩盖一种情况模型 A 在数学任务上极高在对话任务上很低但因为平均分排进前十模型 B 各项比较均衡平均分略低一点排在后面。从真实应用看B 可能更适合大多数场景但榜单不会告诉你这一层。第三个误解是“同一份榜单上的分数可以直接互相比较”。即使大家都在同一个榜单页面上看分也要看榜单使用的评测库版本、数据集版本、few-shot 数量和生成参数有没有变化。有些榜单会持续更新任务配置可能换过好几轮。旧榜分数和新榜分数混在一起看比较的基础就不成立。这三个误解叠加起来就会出现 31% 到 89% 这样的极端现象不是模型在该强的时候弱、在该弱的时候强而是评测配置在替你决定“该用哪种姿势考它”。2. 拆解评测配置同一个模型从哪几个环节被拉开差距2.1 生成参数temperature、top_p、max_tokens先看生成阶段。大多数评测工具默认使用 greedy decoding也就是把 temperature 设为 0让模型每次挑概率最高的 token。这个配置的问题是它只代表一条确定路径不一定代表模型在真实使用中的表现。真实用户调用时很多应用会设置 temperature 大于 0让回答更有变化。当评测题目是需要精确答案的数学题或代码题时temperature 一旦上去模型的随机性会直接拉低准确率。比如一道选择题温度较低时模型能稳定输出正确答案温度调到 0.7 以后连续跑五次可能错两次。对论文里那种“得分在 31% 到 89% 之间”的现象生成参数只是其中一个变量不是全部但单靠它就能造成很大波动。top_p 和 top_k 也会影响结果。top_p 控制候选 token 的累积概率范围调小会让输出更保守。top_p 和 temperature 不是独立的两者一起调整时模型行为变化会非常明显。max_tokens 更像一个“隐形杀手”。如果模型生成答案需要 300 个 token而你只给了 128 个 token 的上限答案会在中途被截断。解析程序只能从半截内容里找答案结果自然偏低。评测时设置 max_tokens 太小模型不是不会做而是没有机会把答案写完。2.2 任务模板与少样本示例任务模板是评测配置里最容易被低估的部分。同样一道数学题发给模型时可以是“请回答以下问题XX 等于多少”“你是一个数学老师请认真解题并先给出推理过程。”“只输出最终数字不要解释。”这三种写法会对同一个模型产生完全不同影响。尤其是带有“先给出推理过程再给答案”的提示对复杂题目通常有正面作用因为给了模型更多 token 空间做中间推理。但推理过程越长最后解析最终答案就越困难一步解析错整个分就丢了。少样本示例同样关键。评测任务里加的 few-shot 示例数量从 0 到 3 到 5分数可能一路走高。原因是模型可以从示例里学到格式和风格不一定是学到解题方法。示例选得好模型输出稳定示例选得差反而会带偏模型。这里还有一个经常踩坑的点示例本身不能从测试集里来。如果示例和测试题目高度相似模型能照猫画虎分数虚高一旦到了真实输入没有这种“标准答案模板”效果立刻下降。评测是为了预判真实效果不是为了做一份漂亮的验证集报告。2.3 输出解析与评测集差异答案解析是整个评测链条里最像“人工后门”的环节。有些评测直接用规则解析比如从模型输出里用正则表达式抓“答案是 X”里的 X。模型只要多写了一句话“让我再想想”正则就可能抓错内容。写解析规则的人如果对 prompt 非常了解可以设计出专门匹配该模型的规则从而显著拉高分数。还有一类评测用另一个模型来打分也就是所谓的 LLM-as-judge。这种方案把 prompt 模板的差异扩散到了裁判模型身上。裁判模型的格式偏好、长度偏好都成了干扰因素。同一个答案换一个裁判模型分数可能完全不同。评测集本身也需要看。不同题库的难度分布不一样。MMLU 是选择题测试的是知识覆盖GSM8K 是小学数学应用题测试的是多步推理HumanEval 是代码生成。把哪个任务放进总榜、任务权重怎么配直接决定了模型总名次。一个在数学任务上表现相对稳定、在通用知识问答上偏弱的模型如果题库里数学题占比高就可能排名靠前。2.4 运行框架和权重精度的隐性影响同样是模型权重用 HF transformers 跑、用 vLLM 跑、用推理框架的量化版本跑结果不一定完全一致。权重精度是其中最容易忽略的一项。fp16、int8、int4 量化后的模型在部分任务上差异可能不大但在需要精确推理、长上下文记忆或代码类任务上量化带来的信息损失会被放大。评测时如果用 fp16生产时却用 int4那么榜单分数和生产体验对不上几乎是必然的。框架差异更多体现在采样器的行为上。不同推理框架对 temperature、top_p 的实现细节有差别甚至同一个框架不同版本之间也可能出现零散差异。对于一些对随机性敏感的任务这种差异会反映在最终分数上。还有一个常见干扰是评测批次大小。batch size 不会直接影响单道题的对错但它可能改变模型内部的 padding 行为、attention mask 组织方式从而影响输出。实际测试时如果两轮评测用了完全不同的 batch size得到不同结果也是有可能的。3. 在本地把自己的任务跑成可信评测3.1 先准备一个小而准的业务评测集要避免被公开榜单误导最直接的办法不是去造一套完美评测框架而是先给自己准备一份“业务评测集”。这份评测集不一定要很大但一定要贴近真实使用场景。我建议从这些地方收集题目线上真实用户问题去掉可能涉及隐私的信息后直接脱敏使用你们业务里最高频的几种输入类型比如客服提问、文档片段、代码注释、表格数据需要模型输出特定格式的任务比如 JSON、Markdown、简短的指令预想到的困难场景比如长文档、多轮对话、歧义问题。数量上不用贪多。快速验证阶段 30 到 50 条就够正式评估可以做到 200 到 300 条。关键是每一条都要有明确的“期望结果”或者“判断标准”。没有标准答案的评测集只能让人凭感觉打分很难复现。这一步的核心价值是把“榜单上的平均能力”转换成“我业务里的具体能力”。模型在公开榜上多强和你能不能把它接进现有链路是两回事。3.2 固定评测协议的最小流程有了评测集之后接下来要做的不是立刻把候选模型全部跑一遍而是先固定一份评测协议。协议至少应该涵盖这些内容prompt 模板写死是否使用 system promptfew-shot 示例的条数和具体内容temperature、top_p、max_tokens答案解析方式每个模型跑几次如何取最终分数。下面是一个最小流程的伪代码。它不能直接复制到你的项目里但可以帮你理解固定评测协议该怎么做。# 伪代码固定评测配置的最小流程 # 实际使用前需要根据模型路径、tokenizer、评测集结构做调整 from transformers import AutoModelForCausalLM, AutoTokenizer model_id your_model_path # 替换成你的模型目录或合法模型标识 model AutoModelForCausalLM.from_pretrained(model_id, device_mapauto) tokenizer AutoTokenizer.from_pretrained(model_id) SYSTEM_PROMPT 你是一个严谨的问答助手请直接给出答案不要额外解释。 def build_prompt(question, fewshot_examplesNone): messages [{role: system, content: SYSTEM_PROMPT}] if fewshot_examples: for item in fewshot_examples: messages.append({role: user, content: item[question]}) messages.append({role: assistant, content: item[answer]}) messages.append({role: user, content: question}) return tokenizer.apply_chat_template(messages, tokenizeFalse) def run_single_answer(question, fewshot_examplesNone, temperature0.0): prompt build_prompt(question, fewshot_examples) inputs tokenizer(prompt, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokens512, do_sampletemperature 0, temperaturetemperature, top_p0.9, pad_token_idtokenizer.eos_token_id, ) generated_ids outputs[0][inputs.input_ids.shape[1]:] return tokenizer.decode(generated_ids, skip_special_tokensTrue)这段伪代码里最需要注意的还是参数部分。temperature 设为 0 时do_sample 必须为 Falsetemperature 大于 0 时又要按需调节 top_p。很多人写评测脚本时直接把 temperature 改成 0.7但没有打开 do_sample结果模型还是 greedy 解码看起来改了参数实际没生效。同一个模型可以按统一协议跑多轮。评估时可以取多次结果的平均值同时记录最低分和最高分。如果一个模型在同一份测试集上两次跑分相差很大单次分数就没有参考价值。3.3 判断结果看均值、方差和坏例评测结束以后先不要急着比较平均分。更合理的做法是看三个指标。第一是整体正确率或达标率也就是平时说的排行榜分数。第二是多次运行的标准差标准差大说明模型在该评测配置下不稳定。第三是失败样本的分布。如果模型在一个固定类别上整体失败平均分再高也不能直接上线。我在实测中习惯先看 20 条样本的输出原文。这样可以判断模型是真正的懂还是“碰巧输出对了”。比如有的题目只要求输出选项号模型输出了一整段文字但结尾包含正确答案解析器也能拿到正确答案。这算不算过了如果真实业务只需要最终选项那可以算过但如果真实业务需要完整解释评测只抓关键词就会过度乐观。失败样例也很有价值。把每个模型的失败样例放到一起能看出模型差异。很多时候模型 A 和模型 B 平均分差不多但它们做错的题几乎没有交集。这说明它们适合不同场景选哪个不取决于分数而取决于哪些错误你更不能接受。4. 最容易干扰分数的变量对照表4.1 关键参数与固定建议表格下面是我筛选出的对评测结果影响比较大的变量。不是所有项目都需要把每一项都列成流程文档但至少在你评测报告里要写清楚。变量它对分数的影响固定建议prompt 模板写法变了模型可能答对也可能答错影响可以超过 10 个百分点评测前写死不要中途频繁修改system prompt会改变模型输出的风格长度和格式倾向按真实业务设置没有业务约束就固定为统一提示few-shot 示例示例数量和质量会直接拉高或带偏分数固定数量示例内容要从评测集外准备temperature数值越大精确任务上错得越多方差越大需要稳定答案时设为 0需要多样性时另行轮次测试top_p与 temperature 一起影响候选 token 集合建议固定为 0.9 或 1.0并写进报告max_tokens太小会让长答案被截断拉低实际得分根据任务类型预留足够空间比如 512 或 1024答案解析方式正则抓取或 LLM 打分都会引入误差先打印输出原文再决定解析策略权重精度量化程度越高精确任务越可能出现损失评测精度尽量和生产部署精度保持一致推理框架版本采样器和 padding 行为有差异同一轮对比使用同一框架评测集版本题库内容变化后新旧分数不可比记录数据集版本号或 commit 信息这张表核心是帮你理解如果两个模型的评测报告里参数列不完整仔细比较没有意义。如果那个报告连 temperature、few-shot 数量、prompt 模板都没有写只能把它当“模型某次跑分记录”不能当成权威答案。4.2 不同场景下评测配置怎么选评测配置的固定不是要让所有场景用同一套设置而是要针对场景选择合理设置。知识问答和客服场景输出要做到稳定和可预期。评测时建议把 temperature 设为 0系统提示词直接描述角色和输出格式比如“你是客服助手请用简洁中文回答”。这能模拟真实线上调用的状态。代码生成场景评测标准通常是有没有通过测试用例。提示词里需要明确语言、函数名和输入输出约束。代码题的答案解析不能只看文本包含什么更稳妥的是提取出完整代码再直接跑用例和测试这样比正则抓代码块更接近真实结果。文本创作和头脑风暴场景temperature 可以调高一些让模型产生更多样化的内容。这时的评测不适合只算一个准确率最好加人工打分或规则评分评价维度包括相关性、完整性和格式合规性。Agent 和工具调用场景题目往往长得像“用户提出一个任务模型需要调用什么工具、传什么参数”。评测配置里很重要的一项是工具描述怎么写。工具描述不同模型选择正确工具的概率就会不同。评测这类模型时不能只给一个文本模板要把工具的 JSON Schema 也一起固定下来。5. 分数复现不了或波动太大时的排查顺序5.1 从输出先排查再回到数据和配置如果你是按论文或其他开源评测脚本复现分数跑出来和报告中不一致先不要怀疑模型文件下载错了。我常用的排查顺序是这样的。第一步打印原始输出。把模型在测试题目上生成的完整回答打印出来看它是不是直接被截断、输出为空或输出了一堆重复内容。如果输出本身不完整后续任何解析都没意义。第二步检查 prompt 模板是否完全一致。不少评测卡片只写了“使用 5-shot”但没有列出 few-shot 的具体内容。示例完全不一样模型表现就可能差很多。最稳妥的办法是把模板写到报告里后续别人才能复现。第三步检查生成参数。尤其是 temperature、top_p 和 do_sample 是否匹配。有的库在不传 do_sample 时即使 temperature 是 0.7也不会真正采样。第四步核对评测集版本。同一个任务名不同版本可能增加或删减了题目分数没有可比性。第五步核对权重精度。如果公开分数用的是 fp16你本地用的是 int4相差几个百分点很正常。第六步检查解析逻辑。这是最容易“复现成功但方案不对”的环节。如果你用规则解析可能只适合某一类模型输出风格换成另一个模型输出风格变化解析失败率升高分数就会莫名下降。5.2 榜单脚本常见的坑如果你在复现公开榜单时碰到分数和榜单差异较大我还可以给你一些常见坑的提醒。数据集切分是最容易忽视的问题。公开的评测任务包含 train、validation、test 多个集。如果复现脚本不小心用 train 或 validation 做测试分数会虚高。对比多个模型时数据泄漏方向如果不同结论会完全失效。模板里的“问题编号”和“选项顺序”也可能造成干扰。有些任务选择题会在题目里加一段“请从 A、B、C、D 中选择”。这个提示看起来很普通但模型对顺序的敏感度不同选项顺序变了可能就会改变结果。评测时模型还没加载完整的 tokenizer 配置也可能出问题。比如 pad_token 设置不对模型批量生成时可能出现警告输出中夹杂大量 pad token。解析时如果没有清理特殊 token分数会被拉低。还有一个比较隐蔽的点batch size 太大时有些模型会尽量节省显存行为可能不同于单条推理。如果你先用小 batch 跑通再加大 batch 复现分数结果不一致可以考虑减少 batch 并尽量保持和公开脚本一致。从这里能看出复现失败多数不是“模型不行”而是配置没有对齐。反过来说如果你要在项目里长期使用评测最好把评测脚本连同参数一起纳入版本管理。每次评测完除了保留平均分还要保留一份用于复现的配置文件。6. 怎么用排行榜指导选型而不被榜单带偏6.1 三个判断标准排在第一的判断标准是看榜单任务覆盖范围而不是看总名次。你可以做一张对比表列清楚每个任务分别考什么能力。如果模型 A 的总分比模型 B 高但模型 A 的高分来自常识问答模型 B 的高分来自代码与数学而你的业务刚好是代码场景那就应该优先关注模型 B。第二个标准是看评测配置与实际部署是否接近。榜单如果使用 temperature 为 0 的 greedy 解码而你的应用为了生成丰富内容把 temperature 设成了 0.8两者面对的不是同一种模型行为。这时榜单提供的信息有限你需要用接近线上温度的配置重测一次。第三个标准是看多次运行的稳定性。没有运行多次的榜单分数只能代表“某个随机种子抽到的一次结果”。如果评测脚本没有固定随机种子下一次重新跑可能得到不同名次。挑选模型时不仅要看平均分排名还要看不同运行之间的波动。波动大的模型即使平均分排名靠前上线排障压力也更大。6.2 落到真实业务前的最后一步在没有做真实业务评测之前不要直接根据榜单纯单确定最终方案。我倾向于把选型流程分成三层。第一层是快速初筛。用公开榜单把候选模型圈到 2 到 3 个不要试图在几十个模型里做精测。这层只需要看总分和任务覆盖不用投入太多精力。第二层是业务小样本评测。用自己整理的三五十条业务题目以固定协议快速跑一遍。输出完整答案并人工阅读。这层的主要目的是剔除完全不合适的模型而不是追求精确排名。第三层才是正式评测。用 200 条以上的业务评测集跑多轮记录平均分、标准差和失败样例。如果条件允许可以把两个候选模型部署成内部接口用真实流量做一段小范围 A/B。到这里你会发现公开排行榜在整个选型过程中只承担漏斗第一层的角色。它的价值是把大量模型筛选到少数候选而不是替你决定最终答案。我见过不少团队在选模型时陷入“高分迷信”把榜单前十名的模型逐一接入项目测试每个模型都跑完整流程最后浪费了大量时间。更务实的做法是先定好自己的评测集用统一协议快速跑两个最符合任务类型的模型再针对输出细节做判断。评测配置影响分数这件事看起来像一个学术问题但其实离工程很近。只要你的应用场景不是公开榜单的原场景你就需要建立自己的评测协议。31% 到 89% 的波动提醒我们任何单一的排行榜数字都不应该成为技术决策的唯一依据。真正该做的是把评测配置写清楚、把评测集贴近业务、把多次运行结果放一起看然后再决定让哪个模型上线。