LLM性能漂移：31352次测量揭示API模型稳定性真相

当基准测试从快照变成时间序列

长期以来，我们对大语言模型（LLM）基准测试的理解存在一个隐含假设：一个模型被评测、得分被公布，然后我们讨论这个分数时，就好像它描述的是一个相对稳定的对象。但对于通过API提供服务的模型来说，"模型名称"背后的东西是会随时间变化的——服务基础设施在变、供应商配置在变、版本在变，有时甚至在没有明显公开版本更迭的情况下，行为也悄悄发生了改变。主流LLM API供应商（OpenAI、Anthropic、Google等）在模型版本管理上的实践差异很大。OpenAI采用日期快照命名（如gpt-4-0613），承诺特定快照版本在一定时期内行为一致，但其通用别名（如gpt-4）指向的实际版本会静默切换。Anthropic则通过模型ID中的日期后缀来标识版本。然而，即使在同一命名版本内，供应商也可能进行推理优化（如量化、推测解码、KV缓存策略调整）或基础设施变更（如切换GPU型号、调整批处理策略），这些变化不会反映在版本号中，却可能微妙地影响模型输出分布。这种"名义上相同、实质上不同"的情况，正是纵向评测试图捕捉的核心问题。

AI Stupid Level平台的创始人在Reddit上分享了一项引人深思的观察：他们不再把基准测试当作一场"排行榜竞赛"，而是将其视为一个纵向测量问题（longitudinal measurement problem）。纵向测量是社会科学和医学研究中的经典方法论概念，指对同一观测对象在多个时间点上反复测量，以捕捉其随时间的变化轨迹。与横截面研究（cross-sectional study）只拍一张快照不同，纵向研究能够区分"个体内变化"和"个体间差异"。将这一框架引入LLM评测，意味着我们不再把每次基准测试视为独立事件，而是将同一模型的多次评分视为一条时间序列，从而可以应用趋势分析、季节性分解和变化点检测等统计工具。他们持续评估模型在编程、多轮推理和工具使用上的表现，同时以更高频率运行轻量级探针。

这个视角的转变意味着，核心问题不再是"哪个模型得分最高"，而是一系列更微妙的诊断性问题：模型的行为是否偏离了它自己此前的基线？这种变化是否超出了它正常的重复调用波动范围？基准配置本身是否发生了改变？效应是否集中在某个特定任务上？是否在同一供应商的多个模型之间存在相关性？以及——一个看似能力退化的现象，是否实际上只是可用性或基础设施问题？

核心数据：3:1的方差比揭示了什么

这项分析的核心发现来自一组相当扎实的数据：跨越49个模型的31352次重复评分观测。

结果显示了两个关键数字：

• 日内（within-day）分数的标准差为2.80分
• 日间（between-day）每日中位数的标准差为8.43分

这大约是3:1的差异。

日内与日间方差的区分，在统计学中属于方差分解（variance decomposition）的经典框架，常见于重复测量的ANOVA分析和ICC（组内相关系数）计算中。日内方差反映的是测量工具本身的随机噪声——在LLM语境下，这主要来自模型推理时的采样温度、API调用的随机种子差异等。而日间方差则可能包含系统性变化的信号，比如供应商的模型权重更新、推理基础设施的配置变更、负载均衡策略的调整等。3:1的方差比意味着日间层面的系统性波动远大于单纯的测量噪声，这在信号检测理论中是一个值得警觉的信号强度。

换句话说，同一天内多次调用同一模型产生的波动，远小于不同日期之间的波动。

作者非常克制地指出，这个结果本身并不足以证明供应商在逐日修改模型——因为存在太多可能的混杂因素：任务组成、采样、数据缺失、供应商行为、方法论变更，都可能贡献这种差异。但这已经足以说明一个问题：时间维度上的变化值得被专门测量，而不应被简单当作围绕某个"永久排行榜分数"的噪声。

这是一个重要的方法论态度。在大多数评测报告中，模型性能被默认视为静态的。而这项工作提醒我们，API背后的模型是一个"移动的靶子"，任何单点测量都可能只是某个时间切片的偶然结果。

严谨的纵向评测方法论设计

基于上述认识，作者团队采用了一套颇为讲究的测量方法论，其中几个设计值得从事生产环境ML的工程师借鉴：

版本化与兼容性比较

他们对基准配置进行版本化管理，只在兼容的测量条件下才对纵向观测数据进行比较。这避免了拿苹果和橘子作对比——如果基准配置本身变了，那么分数变化就无法归因于模型本身。

基于执行的评估，而非LLM裁判

在可能的情况下，他们使用基于执行的重复评估（execution-based evaluation），而不是用另一个LLM来当"裁判"。这一点尤为关键。

LLM-as-a-Judge（用大语言模型充当评判者）是近年来LLM评测中流行的方法，最初由LMSYS在其Chatbot Arena中推广，后被多个基准平台采用。其核心思路是让GPT-4等强模型对其他模型的输出进行质量评分或成对比较。然而这种方法存在多重已知缺陷：首先是位置偏差（position bias），裁判模型倾向于偏好特定位置的回答；其次是自我偏好偏差，模型倾向于给与自己风格相似的输出更高分；最关键的是，裁判模型本身也是通过API调用的，同样面临版本漂移问题。这就形成了一个测量学上的噩梦：你的测量工具和被测对象可能在同时发生不可控的变化，导致观测到的分数变化根本无法归因。用LLM-as-a-judge来测量漂移，无异于用一把会伸缩的尺子量长度。

区分可用性失败与任务结果

他们把可用性故障（availability failures）与有效的任务结果分开处理。这直接回应了前面提出的诊断问题——一次超时或服务不可用，不应被误读为模型能力的退化。同时，他们会在供应商暴露相关信息时，追踪服务和版本的元数据，并对生成的时间序列运行变化点检测（change detection）。

变化点检测是时间序列分析中的一个核心问题，旨在识别数据生成过程的统计特性（如均值、方差或分布）发生突变的时间点。经典算法包括CUSUM（累积和控制图）、PELT（Pruned Exact Linear Time）和贝叶斯在线变化点检测等。在LLM性能监控的场景中，变化点检测可以帮助自动识别模型行为的突变——例如某天开始模型的代码生成能力突然下降5分，这可能对应供应商的一次静默更新。然而，LLM性能时间序列的特殊挑战在于：数据点相对稀疏、噪声较大、且可能存在多种尺度的变化（渐变的能力衰退vs突发的版本切换），这使得传统变化点检测算法的假阳性率可能偏高。

基准污染：越透明反而越失真

这项工作还触及了一个日益尖锐的问题：基准识别与污染（benchmark contamination）。

基准污染是指评测数据以某种方式泄漏进模型的训练数据，导致模型在基准上的表现被人为抬高，而非反映真实能力的提升。这一问题最早在传统NLP基准（如SQuAD、GLUE）中就已被关注，但在LLM时代变得尤为严重。污染可以通过多条路径发生：基准题目被发布到公开网页后被爬虫收集进预训练语料；开源社区在GitHub上复现评测代码时暴露了测试集；甚至供应商可能通过RLHF（基于人类反馈的强化学习）阶段的数据选择，间接针对已知基准进行优化。近期研究表明，部分模型在已知被污染的基准子集上的表现，比未污染子集高出10-15个百分点，这严重削弱了基准分数作为能力代理指标的可信度。

一旦某个基准变得足够知名，公开发布其每一道实时任务、提示词变换和隐藏测试，本身就可能改变你试图测量的对象——这些内容可能进入训练数据，或被供应商针对性优化。

这里存在一个根本的张力：科学要求透明可复现，但透明本身会破坏测量的有效性。

作者团队的应对策略是：将方法论的透明性与发布完整实时评测集分离开来。他们公开了方法论的完整版本（一份公开PDF），详细说明测量设计、假设、局限性和统计解释，但保留了确切的实时任务库和部分操作参数不予公开。

这是一种务实的折中：让方法论可被科学审查，同时不把"考题"直接交给被测对象。

留给LLM评测社区的开放问题

作者以研究者的姿态，向从事评测、变化点检测和生产ML的同行抛出了几个真诚的技术问题：

• 对于纵向LLM评估，应该用每日中位数作为主要的时间序列单元，还是直接对单次重复观测建模？
• 在版本元数据不完整时，如何区分真正的模型漂移与供应商/基础设施效应？
• 一个实时基准应该隐藏多少内容，才能在减少污染的同时，仍保持方法论上的科学可检验性？
• 对于这种非平稳、相对嘈杂的模型性能序列，是否存在比变化点检测器更好的方法？

这些问题没有标准答案，但它们指向了LLM评估领域一个尚未被充分重视的方向。

结语：把"漂移"当作一等公民

随着越来越多的应用直接依赖API提供的模型，模型行为的稳定性已经不再是学术好奇，而是实实在在的工程风险。今天运行良好的提示词，明天可能因为服务端的悄然变更而表现下滑。

这项基于31352次测量的工作，最大的价值或许不在于那个3:1的方差比数字本身，而在于它提出的框架：把时间变化当作需要严肃测量的一等公民，而不是排行榜分数周围的背景噪声。

对于任何在生产环境中依赖LLM的团队来说，这都是一个值得认真对待的提醒——你依赖的模型，可能并不像它的名字看起来那样稳定。

声明：原帖作者披露自己是AI Stupid Level平台的创始人，发帖目的是获取对方法论的技术批评，而非推广商业产品。方法论公开PDF：aistupidlevel.info