跳转到主要内容

你的 LLM 评估在欺骗你:统计功效问题

阅读需 1 分钟Tian PanTian Pan

你的团队花了三天时间迭代系统提示词。评估分数从 82% 提升到了 85%。你上线了。三周后,生产指标毫无变化。发生了什么?

简短的答案是:你的评估欺骗了你。不是恶意为之,而是样本量不足加上忽视了方差。在 100 个样本的测试集上提升 3 个百分点,完全在大多数 LLM 系统的噪声底线以内。在这个规模下,你无法区分信号与随机性——但几乎没有人会在采取行动之前做这个数学验证。

这就是 LLM 评估中的统计功效问题,它正在悄无声息地腐蚀大多数 AI 产品团队的迭代循环。

为什么大多数评估套件小到没有实际价值

统计功效是指当真实效应存在时,你的测试能够检测到它的概率。功效取决于三个因素:样本量、你试图检测的效应大小,以及测量的方差。

功效的标准目标是 80%——也就是说,你接受五分之一的概率错过真实的改进。要在 5% 显著性水平下达到 80% 功效,所需样本量随方差增大,并与效应大小的平方成反比地缩小。如果你想检测的效应减半,所需样本量就增加四倍。

来看一个具体计算。假设你的基准准确率为 82%,你想检测到真实的改进达到 85%——即 3 个百分点的提升。使用双比例 z 检验,α=0.05,功效 80%:

  • p=0.82 的方差:0.82 × 0.18 ≈ 0.148
  • p=0.85 的方差:0.85 × 0.15 ≈ 0.128
  • 每组所需 n ≈ 2,400 个样本

你需要大约 2,400 个带标签的样本来可靠地检测 3 个百分点的提升。而平均的内部评估套件——50 到 200 个在初始开发期间手工整理的样本——甚至连量级都达不到。在 100 个样本时,80% 功效下的最小可检测效应更接近 10–12 个百分点,而不是 3 个。

这不是一个小的校准问题。团队经常基于纯粹是噪声的 3 个百分点的评估改进来上线提示词变更,同时又因为只检查了 80 个样本而无法检测到 8 个百分点的退步。

非确定性放大了问题

即使你接受"我们只用几百个样本",LLM 输出还引入了第二个方差来源,而大多数团队完全忽视了这个来源:模型本身是非确定性的。

用相同参数两次将同一个输入传给云端托管的 LLM,你不会总是得到相同的输出。这是因为概率性 token 采样、分布式推理硬件上的浮点运算差异,以及并行系统中不确定的执行顺序。一项研究发现,在两个不同云服务商上托管的同一模型之间存在统计显著的性能差异(p=0.013)——相同的模型权重,不同的基础设施,可测量的不同基准结果。

这创造了一个双组分方差结构:

  • 问题间方差:有些问题比其他问题更难;你的 100 个样本可能碰巧偏简单或偏难
  • 问题内方差:同一个问题,反复询问同一模型,会得到不同的答案

两个组分都会放大你的测量不确定性。实际后果是,单次评估分数——运行一次,报告为一个数字——包含的噪声远超"85.0%"这种精度所暗示的水平。报告"准确率:85%"就像用水银温度计报告精确到小数点后三位的温度。

当你比较两个模型时你实际上在做什么

当团队比较基准模型和候选模型时,他们通常在同一评估集上运行两者,然后比较结果的准确率数字。如果候选模型比基准模型高 3 个点,候选模型获胜。

这不是假设检验。这是对两个有噪声的点估计的比较。没有置信区间,你就没有任何信息来判断观察到的差异是否超过了噪声底线。

更好的方法是配对分析。当两个模型评估相同的问题时,你可以分析每个问题的差异,而不是总体分数。这利用了模型往往在问题难度上达成一致的事实——如果两个模型都在难题上挣扎,在简单题上成功,那么它们分数之间的协方差提供了"免费"的方差减少。在相同问题集上的配对分析系统上比在独立样本上的双样本分析更敏感。

但即使是配对分析也需要足够的样本。配对方法减少了方差,但并不消除对统计功效的需求。对于 3 个百分点提升检测场景,执行良好的配对测试可能将所需样本量减半——降至大约 1,200 个。仍然不是 100 个。

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 9 分钟

LLM-as-Judge 的对抗性失效:当你的评测框架被操控

一个输出固定回复的「空模型」在 AlpacaEval 上拿下了 86.5% 的胜率。本文系统梳理 LLM 评测框架被操控的方式、其内在的结构性偏差,以及让评测流水线保持诚实的审计方案。

insider
evaluation
阅读需 10 分钟

模式匹配失败:当你的 LLM 流利地解决了错误的问题时

流利且扣题的 LLM 回答如果解决了错误的问题,是生产环境中最难处理的 Bug 类型。本文提供了一套实用的指南,用于检测表面特征过拟合,并设计能够揭示这些问题的提示词。

insider
llm
阅读需 9 分钟

黄金数据集衰减问题:当你的评估集成为负担时

经过精心策划的评估集在数月后会悄然偏离生产环境的实际情况。了解如何检测评估何时测量了错误的目标、保持基准测试真实性的轮换策略,以及告诉你何时该重新构建评估集的监控触发器。

insider
ai-engineering
阅读需 10 分钟

你团队的基准测试正在互相欺骗:共享评估基础设施的污染问题

共享评估基础设施通过缓存补全、顺序运行污染和提示词状态渗漏悄无声息地破坏基准测试结果——而大多数团队从未察觉。本文介绍修复这一问题的技术和组织控制措施。

insider
ai-engineering
阅读需 12 分钟

Eval 异味目录:让你的 LLM 评估套件比没有评估还糟糕的反模式

一份关于毒害 LLM 评估套件的反模式实战指南 —— 包括数据污染、脆弱的断言、评估腐化、评委合谋、虚荣聚合指标 —— 以及在无需重写整个测试框架的情况下恢复有效信号的重构模式。

insider
ai-engineering