模型 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[后处理规则] --> F

Benchmark 结果至少要绑定模型版本、数据集版本、样本数量、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，再精确的小数点也没有意义。