模型 Benchmark 方差控制：平均分之前，先看波动有多大

一、平均分很容易掩盖不稳定

模型 Benchmark 里最常见的结论是“模型 A 比模型 B 高 1.2 分”。但如果多次运行的波动已经达到 1 分以上，这个结论就没有想象中稳。评测不是只算平均值，还要看方差、置信区间和样本覆盖。

大模型评测尤其容易受采样参数、提示模板、评测集抽样、API 状态和判分器差异影响。一次运行得到的分数，只是一次观测，不是模型能力的完整描述。

二、评测流程要记录随机因素

影响波动的因素要进入元数据。

flowchart TD A[评测任务] --> B[数据集抽样] A --> C[Prompt 模板] A --> D[采样参数] A --> E[判分器版本] B --> F[多次运行结果] C --> F D --> F E --> F F --> G[均值与方差]

如果只保存最终表格，不保存这些变量，后续无法解释分数变化来自模型，还是来自评测配置。

三、先写一个最小统计结构

from statistics import mean, stdev scores = [78.1, 77.6, 78.4, 76.9, 78.0] avg = mean(scores) sigma = stdev(scores) print({"mean": avg, "std": sigma})

真实评测里还要计算置信区间，并按任务类型拆分。总体分数稳定，不代表每个子任务都稳定。

四、方差过大时不要急着下结论

如果分数波动很大，先检查样本量是否太小、判分器是否稳定、生成参数是否固定、评测集是否包含大量模糊题。模型能力差异可能存在，但当前评测方法不足以支持结论。

还要观察错误分布。两个模型平均分接近，但一个稳定错在同类任务，另一个随机波动，这对业务选型的含义完全不同。平均分是摘要，不是解释。

重复运行并不是浪费。它能暴露评测系统本身的不确定性。对于差距很小的模型，只有多次运行和显著性检验才能避免过度解读。

最后，报告里应该写清“不能说明什么”。例如当前评测只能说明指定数据集和参数下的相对表现，不能代表所有业务场景。边界写清楚，结论才可信。

方差控制还要区分模型内波动和评测器波动。如果答案由另一个模型评分，判分器本身也可能不稳定。可以固定判分器版本、温度和提示模板，并抽样做人工复核。否则被比较的不只是候选模型，还包括评测器的随机性。

样本分层也很重要。把简单题和困难题混在一起求平均，可能让大量简单题压低方差，掩盖困难题的不稳定。更合理的做法是按任务类型、文本长度、语言、难度分桶，分别报告均值和方差。

当两个模型差距很小，可以引入 bootstrap。对样本重复重采样，估计分数差的分布。如果大部分重采样结果都显示 A 优于 B，结论才更稳；如果分布大量跨过 0，就应该写成“当前证据不足以证明显著差异”。

最后，评测脚本要固定输出顺序和随机种子。多线程请求、异步调用、失败重试都会改变样本顺序和结果记录。方差分析依赖干净数据，如果日志本身错位，统计再漂亮也没有意义。

还要把失败样本纳入统计口径。API 超时、解析失败、判分失败如果被直接丢弃，平均分会被抬高。更稳妥的做法是单独报告失败率，并说明失败样本是否计为 0 分、重试后计分，还是从统计中剔除。

评测报告可以用“结论强度”分级。差异显著且多次运行稳定，才能写成明确优劣；差异存在但方差较大，只能写成倾向；差异落在噪声范围内，就应该写成未观察到可靠差异。

五、总结

模型 Benchmark 不能只看平均分。方差、置信区间、随机因素和错误分布同样重要。分数差距小于评测波动时，不要急着宣布模型更强，先证明评测结果足够稳定。