跳到主要内容

你的评估测试集对现任模型存在过拟合

· 阅读需 12 分钟
Tian Pan
Software Engineer

一个新的前沿模型发布了。它更便宜、更快速,并在各大公开排行榜上霸榜。你使用你花了 18 个月构建的评估套件对其进行测试,结果它的得分比你目前运行的模型还要。于是你保留了现有的模型,将挑战者模型归类为“尚未准备好”,然后继续之后的工作。

令人不安的部分在这里:那个结果几乎没有告诉你哪个模型更好。它告诉你的其实是,你的评估套件是通过观察当前模型的失败、处理一次又一次的生产事故而构建的,然后通过修补来消除那些特定的失败。这个套件并不是对质量的客观衡量,它是某个模型“疤痕组织”的目录。而一个拥有不同弱点的挑战者模型,在面对一个针对现有模型特定弱点而收集的测试集时,表现总是会显得更差——即使它在你实际服务的流量上表现得更好。

这就是“现有模型偏见 (incumbent bias)”,它是没人会在迁移决策中计算的切换成本。它在更好的选择出现很久之后,依然悄悄地将你锁定在旧模型上,而且它还是披着“严谨工程”的外衣做到这一点的。

评估套件通过“复盘”成长

没有人会一开始就坐下来设计一个全面的评估套件。它们不是那样被构建出来的。它们是逐渐累积的。

生命周期总是一样的。一个模型在生产环境中输出了错误的内容——它幻觉出了一个退款政策,遗漏了一个必填的 JSON 字段,忽略了一个否定词,或者弄乱了一个日期。有人被传唤 (paged) 了。链路追踪 (trace) 被诊断。而修复方法几乎从来不是“重新训练模型”——而是一个提示词补丁 (prompt patch)、一个少样本 (few-shot) 示例、一个护栏 (guardrail) 或一个后处理器。然后,如果团队足够严谨,那个失败案例就会变成一个永久的评估案例,这样同样的回归 (regression) 就不会再潜入。

这样做几百次,你就拥有了一个成熟的评估套件。它看起来很健壮。它有几百个案例,每一个都是通过真实的痛苦换来的。但看看每个案例的来源:每一行之所以存在,是因为你的当前模型至少失败过一次。这个套件是一个特定模型弱点的底片。它不是任务的地图——它是现有模型在执行任务时的错误史地图。

提示词修复让情况变得更糟。当你用一个 few-shot 示例或精心编写的指令来修补失败时,你是在针对模型调整提示词。这两者现在已经共同进化了。你的指令依赖于这个特定模型如何分词、它在哪里分配注意力、它对什么措辞有反应。评估案例及其修复方法是一套匹配的组合,完全契合一个模型的行为轮廓。

换入一个挑战者模型,这套组合的两部分都会失效。挑战者没有现有模型的失败模式,所以这个案例从未测试过它挣扎的地方。而提示词修复是围绕现有模型的怪癖设计的,因此它可能会主动混淆新模型。你测的不是挑战者。你测的是挑战者模仿你现有模型的程度。

为什么“更差”通常意味着“不同”

在针对现有模型量身定制的套件中运行一个真正有能力的挑战者模型,你通常会看到一个独特的特征:它修复了一堆现有模型从未失败过的案例(因为它们不在你的套件中,所以你得不到加分),同时在另一组较小的案例上失败了(这些案例在你的回归测试中明显缺失,所以这些失败直到生产环境才会被发现)。

将这些汇总成一个总通过率,挑战者模型的得分会比现有模型低几个百分点。这个数字被解读为“更差”。但将其分解后,真实的故事是“错误分布不同”——而且在你实际看到的流量上,错误可能更少。评估套件无法向你展示这一点,因为它只包含现有模型已经教过它的失败案例。

在基准测试领域有一个经验性的类比。当 Scale AI 为 GSM8K 小学数学基准测试构建了一个全新的平行版本时,几个模型系列在问题上的准确率比在原始问题上下降了两位数——这是典型的过拟合特征。模型并没有背下具体的题目,但整个生态系统已经含蓄地针对那一套固定题目进行了调整。你的私有评估套件比 GSM8K 更加过拟合,因为它不仅仅是针对一个固定集合进行调整——它是通过单个模型的失败而生成的,并且修复方案是针对同一个模型共同设计的。

这是古德哈特定律 (Goodhart's Law) 的一个微妙变体。通常的说法是,当一个衡量标准变成目标时,它就不再是一个好的衡量标准了。而“现有模型偏见”的版本更为隐蔽:衡量标准是基于目标的错误构建的,所以它从一开始就不是一个中立的衡量标准。通过它意味着“表现得像现有模型”,而不是“擅长这项任务”。任何表现不同的模型——包括更好的模型——都会因为这种差异而受到惩罚。

将回归案例与能力案例分开

解决办法不是扔掉你辛苦建立的评估套件。那些生产环境的失败是真实的,你确实不希望它们再次发生。解决办法是停止将这一堆案例视为在测量同一件事。它测量的是两件事,需要分别评分。

特定于模型的回归案例 (Model-specific regression cases) 的存在是为了防止已知的失败再次发生。它们本质上与模型的行为绑定在一起。“给定这个模糊的退款请求,模型 X 曾经胡编乱造出一个政策——确保它不再这样做。”这是一个真正的保护措施,但它是关于模型 X 的陈述。一个从未有过这种失败的挑战者模型将轻而易举地通过它,而通过它并不能证明挑战者的质量。这些案例是为了在生产环境中守护特定模型,而不是为了比较两个候选模型

与模型无关的能力案例 (Model-agnostic capability cases) 描述了任务需要什么,无论谁来执行。 “从这封电子邮件中提取交付日期;正确答案是 2026-03-14。” 无论哪个模型阅读它,这都是事实。这些案例衡量的是任务本身,而不是模型在任务中的历史表现。它们是你的套件中唯一可以公平比较候选模型的部分。

大多数团队从未画过这条线,所以两种案例都存在于同一个文件夹中,并被平均成一个数字。明确地画出这条线。将每个案例标记为回归(绑定到模型,附带提示词修复)或能力(绑定到任务,由 Ground Truth 定义)。当你评估一个挑战者模型时,在能力集上对其评分,并将回归集视为诊断性的,而不是简单的通过/失败——挑战者在特定于现有模型的回归案例中失败,是关于它在哪里不同的信息,而不是它更差的证据。

这里有一个判断案例属于哪个桶的有用方法:如果“正确答案”是通过观察一个好的回答应该是什么样而撰写的,那么它就是能力案例。如果是通过观察现有模型哪里做错了并编码“不要那样做”而撰写的,那么它就是回归案例。两种不同的来源,两种不同的用途。

一个不作弊的供应商更换协议

一旦你接受了现有的测试套件是基于现任模型构建的这一事实,那么更换模型的评估协议就必须改变。目标是在你实际服务的分布上对挑战者模型进行评分,使用的案例应当是两个模型都未曾针对其进行过微调的。

从实时流量中提取新鲜的任务样本。 提取一份全新的、未见过的真实生产输入样本 —— 这些样本的时间应晚于你的测试套件,且从未被用于编写提示词修复方案。独立地对它们进行标注:如果存在标准答案则使用标准答案,或者由一个并非现有修复方案作者的评判者来进行标注。这就是你真正的测试集。在任何人看到模型输出之前将其锁定,从而确保挑战者和现任者是在相同的、未受污染的输入上进行评分。

中性化提示词。 你的生产提示词是与现任模型共同适应的 —— 它的 few-shot 示例、防御性指令以及措辞都倾向于当前模型的特性。通过那个提示词来对挑战者评分,衡量的是它与现任模型“拐杖”的兼容性,而不是能力。在断定挑战者表现更差之前,给它一个尝试其自身最佳提示词的机会。有时候,一次提示词重写就能抹平整个差距,因为所谓的“差距”从来都不在模型本身。

对错误分布评分,而不仅仅是总和。 不要停留在单一的通过率上。按类型和严重程度对错误进行分类。如果一个挑战者用 10 个低严重程度的格式错误换取了减少 2 个灾难性的策略幻觉,那这其实是一个“胜利”,即便你的综合指标会判定其为失败。迁移决策存在于分布之中,而非平均值。

然后在生产环境中进行 A/B 测试。 离线评估只能识别有潜力的候选者;它们无法得出定论,因为非确定性的输出对提示词、参数和版本极其敏感。将一部分真实流量路由给挑战者,并衡量用户真正感受到的结果 —— 任务完成情况、转人工率、下游修正 —— 而不是针对固定测试集的代理通过率。这是唯一一个不被任何人与任何模型的历史所影响的阶段。

同时也迁移你的回归案例。 一旦你决定使用新模型,不要把旧模型的回归案例作为唯一的通过/失败关卡。重新建立基准。在生产环境中运行挑战者,收集它的失败案例,并围绕你实际交付的模型构建一个新的回归层。否则,你接下来的一年都会在用旧模型的“伤疤”来否定新模型 —— 而你只是在一次迁移之后,重新制造了完全相同的偏见。

元经验:评估是有半衰期的

更深层次的一点是,评估套件并不是一个只会增值的固定资产。当你更换模型的那一刻,其中的回归测试部分就会贬值,因为这些案例始终是针对特定模型的主张。把那一部分看作是带有模型版本特征的产物:绑定到生成它的模型上,在你迁移时重新建立基准,永远不要把它误认为是一个中立的标尺。

能力测试部分是持久的部分 —— 那才是你关于任务真正的组织沉淀知识,也是比较候选者唯一公平的基础。大多数团队拥有的这类知识远比他们想象的要少,正是因为“通过事后剖析来积累”的过程制造回归案例的速度远快于制造能力案例。事后剖析是廉价且自动的;而清晰地阐述任务真正的需求则是一项几乎没人安排进日程的刻意工作。

评估中的现任者偏见是真实存在的切换成本,而且像大多数切换成本一样,直到你尝试切换时它才是隐形的。你会觉得“新模型就是没那么好”,而支持这一观点的是你信任的测试套件,因为你是诚实地构建它的。但在构建时的诚实并不能换来测量时的中立。一个由某个模型的错误汇编而成的套件,总是会偏袒该模型并丑化它的替代者。摆脱困境的方法不是减少对套件的信任 —— 而是搞清楚你正在阅读的是哪一部分,并在你实际服务的任务上测试挑战者,而不是在现任者的旧伤疤上。

References:Let's stay in touch and Follow me for more thoughts and updates