模型 Benchmark 方差控制:平均分之前,先看波动有多大
模型 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 不能只看平均分。方差、置信区间、随机因素和错误分布同样重要。分数差距小于评测波动时不要急着宣布模型更强先证明评测结果足够稳定。