一篇论文给我印象很深它直接挑战了一个常见的认知我们以为 LLM 排行榜比的是模型能力实际上很大程度上比的是“评测配置”。论文给出的例子很极端同样是那个模型材料里记为 gemma4-31b 的实例在不同评测配置下得分可以从 31% 一路波动到 89%。这个现象不是“评测有误差”这么简单。它意味着如果换一套提示词、换一组采样参数、换一种题目格式同一个模型的排名可能从腰部直接冲到头部也可能从头部掉到末尾。换句话说很多公开排行榜的单次名次参考价值没有想象中高。这篇文章就结合论文的结论拆解以下内容评测配置到底是什么、哪些旋钮影响最大、31% 和 89% 是怎么形成的、排行榜应该怎么读、以及如果你想自己做模型评测怎么设计才能减少这种波动。1. 核心现象速览信息项内容论文核心观点LLM 排行榜名次受评测配置影响非常大甚至超过模型真实能力差异实例现象同一待评模型在多种评测配置下得分可在 31% 到 89% 之间大幅波动主要变量提示词措辞、采样参数、任务指令格式、少样本示例、评分标准、输出约束受影响环节知识问答、代码生成、数学推理、指令遵循等所有评测维度最大风险评测结果失真、榜单被“刷分”、模型选型决策被误导可借鉴方向评测环境标准化、多次运行取区间、报告评测配置细节适用读者LLM 选型工程师、跑榜玩家、评测工具开发者、AI 产品负责人这个现象提醒开发者跑一次评测就对比两份模型得分很多时候统计上并不稳固。一个模型得 60 分另一个模型得 65 分如果评测配置不同这个 5 分差距基本没有意义。2. 为什么评测配置能大幅影响榜单位次先建立一个大前提LLM 评测不是“把题目丢给模型、模型吐出答案、比对对错”那么简单。一次推理包含非常多的中间环节而每一个环节里都有人为设定。从评测题目进入模型开始至少经过这些步骤评测集构造题目如何从原始数据变成模型输入需不需要加前缀、加说明、加示例。提示词模板模型看到的完整文本是什么不同模板可能改变模型对任务的解读。采样参数temperature、top_p、max_tokens这些参数影响输出的确定性。解码与停止条件模型何时停止输出输出长度上限是多少。答案抽取从模型输出里提取答案用正则、用规则、还是用另一个模型抽取。评分方式是精确匹配、模糊匹配、关键字匹配还是用 LLM 当裁判打分。数据预处理是否清理了特殊符号、是否统一格式、是否排除了难以解析的样本。论文指出很多排行榜在公布分数时并不会把这些配置全部公开。于是评测结果看起来客观其实是建立在大量隐藏假设之上。31% 到 89% 的差异不是“模型偶尔发挥失常”而是评测系统在多个环节上对模型不友好或友好的叠加效果。比如模型本身不是通过“直接给出简短答案”的方式训练的评测却要求它必须严格只输出A/B/C/D模型习惯在回答前生成思考过程评测系统却只截取最后一段甚至因为输出过长被判错模型对英文指令更敏感评测却用了它不擅长的表达风格采样参数设置了一个不利于这类任务的随机度导致相同问题跑两次结果都不一样。所以一个真正值得讨论的问题不是“这个模型排第几”而是“这个模型在什么条件下排第几”。3. 评测配置中容易被忽略的变量好回到工程视角。控制评测配置实际上是控制下面这些变量。每个变量都能影响最终分数而多数排行榜不会完整披露。3.1 提示词模板差异同样是“解答这道数学题”至少有这几种写法只给题目What is 17 * 23?要求步骤Please solve the problem step by step.给角色设定You are a helpful math tutor. Solve the problem.约束输出格式Only output the final answer as a number.不同模型对不同写法的响应差异很大。某些模型对复杂指令更敏感某些模型在简单指令下表现更好。论文中 31% 到 89% 的波动区间提示词模板变化是主要贡献者之一。3.2 采样参数常用采样参数包括参数作用对评测分数的影响temperature控制随机性过高容易答偏过低可能重复top_p控制候选词累积概率配合 temperature 影响输出多样性max_tokens限制最长输出太短会导致答案截断stop自定义停止词停止词不匹配可能产生多余输出seed随机种子部分推理后端支持影响可复现性排行榜如果固定了 temperature那相当于固定了一种“模型行为模式”。这本身没问题但没写出来就有问题。3.3 few-shot 示例的选取少样本示例能显著影响输出风格。给出一个高质量示例模型可能模仿它的推理过程给一个错误方向的示例模型可能被带偏。甚至示例的顺序都会产生影响。论文评测如果要公平需要明确说明使用了多少示例、示例来自哪里、排序规则是什么。3.4 答案抽取与评分规则这是最隐蔽的环节。很多评测集不是选择题而是开放式问答。模型输出一段完整回答后评测脚本需要从中找到“正确答案”。如果脚本只是精确匹配关键词模型用同义词改写就可能被判错如果脚本用规则抽取消极表达模型遇到复杂句式也可能抽取失败如果脚本用另一个 LLM 来评分评分模型自身的性能又成为新的变量。一个典型的例子是让模型输出“答案是21”。如果评测脚本只提取“21”而模型输出的是“21 个苹果”可能因为格式问题被判错。这不是模型不会做是解析器没接住。3.5 指令语言和措辞论文实验里常常发现某些开源模型在英文指令模板下表现更好换成本地化措辞后任务理解变差。如果评测集是英文题目但提示词中出现非英文指令排序有些模型的回答质量会下降。这个结果不反映“模型的真实推理能力”只反映“模型在该评测配置下的指令遵循能力”。4. 31% 到 89% 的波动区间说明什么从材料看这个 31% 是“较不利配置下的结果”89% 是“较友好配置下的结果”。两者相差 58 个百分点。这是什么概念在很多知名榜单上排名前列的模型之间不过相差零点几个百分点。如果评测配置能让一个模型跨 58 个百分点的区间波动那榜单上几个点的差异根本说明不了模型能力差别。这是一个非常严重的测量学问题。我把它拆成三层观测值不等于真值我们看到的分数是模型在特定管道下的表现不是唯一表现。分数既要看均值也要看分布只看一次运行结果会忽略方差。同一个模型在同一配置下跑 5 次可能分数波动几个点。模型差异的置信区间两个模型如果各自分数误差区间叠加后包含对方那么它们的高低关系在统计上不显著。所以评估一个模型不能只拿“排行榜分数”说话。真正靠谱的流程应该是固定评测脚本、多次运行、观察分数分布、记录完整配置。否则你选型选到的可能不是你需要的模型而是一个恰好适配了某套提示词模板的模型。5. 评测配置如何影响你的模型选型决策对普通开发者来说读排行榜很容易做错决定。比如你看到两个模型在某个 Leaderboard 上排名差距明显。模型 A 排第 8模型 B 排第 20。如果你直接选模型 A可能进入一个误区这个榜单的评测配置偏好模型 A 的输出风格而你的业务场景与这个评测配置并不一致。更实际的决策方法是先确定你的任务类型。再准备你业务里的真实测试样本。然后固定一套统一评测配置例如相同的提示词模板、相同的采样参数。最后跑 2 到 3 次观察两个模型的结果差异和稳定性。这个思路不只是为了公平对比更是为了降低“排名幻觉”带来的误导。另外还要注意论文材料里提到的模型名称可能来自研究总结如果要在实际环境中复现需要注意模型具体版本、参数规模和来源尽量使用与业务环境一致的推理后端。6. 如何设计一套相对稳健的评测流程论文给出的是现象分析实际操作中我们可以把评测做“保守化”处理不是追求让模型得分最高而是追求让自己的判断不容易被配置带偏。6.1 固定并记录配置评测脚本需要包含一份完整配置记录。配置可以分成模型参数、推理参数、评测参数和环境参数四类。一个参考配置文件示例{ model: { name: your-model-id, revision: commit-or-version, backend: vllm-or-transformers }, inference: { temperature: 0.2, top_p: 0.9, max_tokens: 2048, stop: [\n\n, |endoftext|], seed: 42 }, evaluation: { prompt_template: ./templates/chat_v1.txt, few_shot_count: 5, answer_extraction: llm-judge, scoring_metric: exact_match }, environment: { gpu_count: 1, cuda_version: 12.1, backend_version: 0.4.2 } }把这份配置文件和评测代码一起提交任何一个后来者都能复现结果。6.2 多次运行取区间单次评测结果不构成决策依据。建议至少用这种策略同一配置下跑 3 次记录每次分数、平均分、最高最低分。两个模型对比时看区间是否重叠。如果区间重叠较大就用更多样本或更稳定的参数重新测。6.3 设置多组提示词模板不要只用一套提示词模板。因为单套模板可能对某个模型更有利。设计三组模板# 模板清单示例 templates/ ├── prompt_v1_brief.txt ├── prompt_v2_detailed.txt └── prompt_v3_role_play.txt然后使用同一个评测集分别评测取综合结果。这样能降低单一模板偏好带来的排名波动。6.4 抽样检查人工复核在自动评分之外人工抽看 50 到 100 条模型输出检查是否是“评分规则误判”导致假的高分或低分。这种做法不能完全取代自动评测但它能帮你判断自动评分的可信度。7. 评测环境准备与本地复现思路如果你想自己跑一个小的评测实验围绕“不同评测配置导致分数波动”进行验证下面给出一套通用的本地复现思路。注意以下示例是通用流程具体路径、端口、模型名需要根据你的实际项目替换。7.1 基础环境检查建议先确认以下几项Python 3.10 以上版本。一个可用的推理后端比如 vLLM、Transformers、Ollama 或 OpenAI 兼容服务。准备一批测试问题建议 30 到 200 条不需要太大规模。磁盘空间要足够放下模型权重。GPU 显存取决于模型规模参数量越大占用越高实际需要以你的模型版本为准。7.2 启动模型服务如果使用 OpenAI 兼容服务启动方式通常类似python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9实际命令取决于你选择的推理框架。如果没有 vLLM也可以用其他后端只要能对外提供接口就行。7.3 编写评测脚本用 Python 编写调用评测脚本。下面是一个通用模板用来在不同配置下给同一模型打分对比import requests import json def chat_completion(prompt: str, temperature: float 0.2, top_p: float 0.9): url http://127.0.0.1:8000/v1/chat/completions payload { model: your-model-id, messages: [{role: user, content: prompt}], temperature: temperature, top_p: top_p, max_tokens: 2048, seed: 42 } resp requests.post(url, jsonpayload, timeout120) resp.raise_for_status() return resp.json()[choices][0][message][content] def run_eval(prompt_template: str, temperature: float): questions [ Explain the concept of overfitting., Write a Python function to calculate Fibonacci numbers., What are the main causes of climate change?, If a train travels 60 km in 1.5 hours, what is its average speed? ] results [] for q in questions: full_prompt prompt_template.replace({question}, q) output chat_completion(full_prompt, temperaturetemperature) results.append({question: q, output: output}) return results if __name__ __main__: brief_prompt {question} detailed_prompt Please answer the following question carefully and provide a clear explanation:\n\n{question} results_brief run_eval(brief_prompt, 0.2) results_detailed run_eval(detailed_prompt, 0.2) with open(results_brief.json, w, encodingutf-8) as f: json.dump(results_brief, f, ensure_asciiFalse, indent2) with open(results_detailed.json, w, encodingutf-8) as f: json.dump(results_detailed, f, ensure_asciiFalse, indent2)这个脚本不直接完成自动评分但能提供两组原始输出方便你观察同一模型在不同提示词下的回答差异。7.4 人工评分对比得到输出后可以按“正确性、完整性、格式合规”三档人工打分也可以接入评分模型。评分时建议不保留“哪个提示词模板”的信息做盲评减少主观偏差。8. 评测结果观察如何判断配置是否在起副作用评测配置是很中性的东西没有什么“万能最优配置”。同一套配置可能让一个模型表现很好同时严重压制另一个模型。关键是从评测结果中识别出“配置副作用”。下面这些信号可以作为参考8.1 输出长度截断如果很多模型输出恰好等于max_tokens上限说明max_tokens设置可能限制了模型完整回答。尤其在代码生成和长文本推理题里这会让分数失真。8.2 解析失败率偏高评测日志中大量样本被判为“格式错误”“无法解析”这种情况大概率是抽取器规则太严或停止条件不对。建议先检查模型原始输出如果输出里有正确答案但被判定格式不符则需要修正抽取逻辑。8.3 多次运行分数波动大如果同一个模型在同一配置下跑 3 次分数差距超过 5 个百分点说明采样参数偏大或评测集样本量太小。这时应该调低temperature或扩大测试集。8.4 一个极端结果拉高平均分如果一个模型总体的平均分不错但最小分数特别低检查是否存在系统层面“上下文崩坏”情况。这种情况通常不是因为模型不会做题而是因为长上下文输入后模型输出质量急剧下降。9. LLM 评测常见问题与排查方法自己搭建评测流程时容易踩不少坑。下面按现象给出一张排查表很多是我在实际折腾评测流程时遇到的问题。问题现象可能原因排查方式解决方案同一模型同一配置分数忽高忽低采样随机性temperature过高固定 seed调低 temperature设置temperature0.2多次运行取平均模型输出质量好但评分很低答案抽取规则过于严格或匹配方式不合理查看原始输出看是否包含正确内容改用 LLM Judge 评分或增加正则容错换一套提示词后分数大幅变化模型对指令措辞敏感用多组提示词模板分别评测综合报告多模板结果不只取单次记录批量评测到一半卡住接口超时、显存溢出或请求频率过高查看后端日志增加超时时间减小 batch加入失败重试max_tokens耗尽导致答案不完整生成长度上限设置过低检查输出是否恰好等于截断长度按任务增加生成长度上限如设 2048 或 4096模型输出有额外说明文字提示词未约束输出格式在提示词中加入“只输出最终答案”用停止词或格式约束减少解析负担排行榜显示 A 优于 B本地实测相反评测集或评测配置差异对比双方使用的评测集与采集参数使用自己的业务样本做小范围人工评测10. 回归到论文本身读榜单时要多一步思考这篇论文的做法和很多严谨评测研究一致不要问“谁更强”要问“在什么配置上谁更强”。论文揭示的核心风险是如果各个评测项目没有统一约定提示词模板、采样参数、多少示例、如何抽取答案那榜单分数里混入了大量配置噪声。而配置噪声可能导致开源社区形成错误的“模型强弱印象”。接下来如果你也在做模型评测或者正在挑模型建议按下面的顺序调整先确定“评测配置”的定义不要只记分数要记录完整参数。使用至少 3 组不同提示词模板。对模型做多次采样得到分数区间。在自动评分后做小规模人工抽查。对照你的真实业务不要完全依赖别人的榜。如果你觉得现在直接手写评测流程太慢也可以考虑先用现成的评测框架或评测集然后在其基础上增加自定义模板变量。这样能快速建立起一套属于自己的可信评估流程。11. 最佳实践如何向团队或社区报告模型评测结果最后一条很实际无论是写技术总结还是给团队汇报都不要只给一个排名表。一份可信的评测报告至少要包含以下内容。模型信息模型名称、权重来源版本、量化方式如果有、推理后端。评测集信息题目数量、来源、语言、难度分布。提示词模板完整模板文本最好随仓库发布。推理参数temperature、top_p、max_tokens、seed、停止词。运行次数与分布多次运行后得到的均分、最高分、最低分。抽取和评分代码可以复现的打分逻辑。已知局限哪些任务是评测集覆盖不到的哪些评分规则可能产生偏差。把这些信息公开以后别人才能判断你的评测是否可信也才能在自己的环境里继续复现。12. 总结与下一步LLM 排行榜本身不是没有价值它的价值在于提供一个大规模、低成本、可横向对比的参考坐标。但论文用 31% 到 89% 的极端波动提醒我们评测配置不是一个可以忽略的细节它是评测结果的一部分。你想比较模型能力就必须把配置固定下来并且公开出来。对于经常跑模型评测、在排行榜上选型的人这篇文章最值得记住的一点是不要无条件相信某个单一榜单至少用你自己的任务样本在一套固定配置下跑一遍并多做几次看分数的分布情况。记录 prompt 模板、采样参数、抽取规则把这些和最终分数一起保存。这样你的选型判断就稳定得多。如果以后再看到某个模型“分数暴涨”别急着惊叹先翻一下它用的评测配置是不是刚好适合那个模型的输出风格再下结论。