模型 Benchmark 复现：分数相同不代表实验相同

模型 Benchmark 复现分数相同不代表实验相同一、Benchmark 最怕不可复现模型 Benchmark 看似简单跑一套评测集得到一个分数然后和其他模型比较。但实际复现时prompt 模板、解码参数、样本版本、后处理规则、随机种子、硬件环境都会影响结果。分数相同不代表实验相同。两个团队都报 82 分如果评测口径不同这个数字就不能直接比较。有一类常见情况团队 A 用 few-shot prompt团队 B 用 zero-shot template两者报告的分数相差不到 1%但实际能力差距可能大得多。二、评测配置要完整记录flowchart TD A[模型版本] -- F[Benchmark 结果] B[数据集版本] -- F C[Prompt 模板] -- F D[解码参数] -- F E[后处理规则] -- FBenchmark 结果至少要绑定模型版本、数据集版本、样本数量、prompt 模板、temperature、top_p、最大输出长度、评分脚本和后处理规则。没有这些信息后续分数变化无法解释。到底是模型变好了还是 prompt 更适配或者评分脚本修了 bug都说不清。三、结果文件要机器可读{ model: llm-2026-07-04, dataset: qa_eval_v3, prompt_hash: a81f, temperature: 0, score: 0.824, sample_count: 1200 }机器可读结果方便做趋势图也方便 CI 比较。不要只把结果贴进文档截图。benchmark_reproducibility: require_prompt_hash: true require_dataset_hash: true save_raw_outputs: true save_failed_cases: true保存原始输出很关键。总分下降时必须能回到具体样本看是某类任务退化还是评分脚本变化。四、比较要看置信区间样本少时1 分差距可能只是随机波动。Benchmark 报告应该给出置信区间或至少做 bootstrap 估计。尤其是 LLM Judge 评分评审模型本身也有波动。还要区分整体分和分项分。一个模型总分略高但在关键业务任务上低很多未必适合上线。评测要服务决策而不是服务排行榜。评测频率和深度也是一对权衡。每周跑全量 Benchmark 能快速发现变化但样本覆盖、置信度评分、人工复核都需要大量资源。可以选择核心集高频跑全量集按版本跑把性价比最大化。Benchmark 还要记录失败样本分布。比如数学推理提升长文本问答下降中文任务稳定代码任务退化。总分变化可能很小但分项退化会直接影响产品体验。benchmark_report: overall_score: true category_scores: true confidence_interval: true regression_cases: true raw_output_link: required评测环境也要隔离。线上服务有缓存、限流和动态路由可能影响输出。做模型对比时尽量使用固定模型端点和固定配置避免请求被路由到不同后端。如果 Benchmark 用到了裁判模型还要记录裁判版本和评分提示词。裁判变了分数体系也可能变。不要把裁判模型当成绝对标准。报告里还应写明“不可比较”的情况。比如样本集换版、评分规则改动、Prompt 模板变化过大时不能把新旧分数直接画在同一条趋势线上。严谨的 Benchmark知道什么时候不该比较。五、总结模型 Benchmark 复现要记录模型、数据、Prompt、解码参数、评分脚本、原始输出和失败样本。分数只是结果实验口径才是比较的基础。口径不清的 Benchmark再精确的小数点也没有意义。