Eval 回填税：为什么每一次模型能力发布成本都超出了你的预算

一名高管发了一封只有一行字的邮件：“好消息——我们在下个冲刺周增加视觉能力。”产品经理将其解读为一星期的工作量：更换模型、开放图像参数、发布。评估（Eval）团队读了同样的邮件，脑子里已经开始起草一份尚未获批的四周计划。到了周五，这种认知脱节在站会上表现为一句含糊的“我们需要做一些评估工作”，然后大家一致同意以后再解决。

这种在“我们添加了视觉能力”与“我们可以安全发布视觉能力”之间的鸿沟，就是评估补填税（Eval Backfill Tax）。每当新的模型能力落地时——多模态输入、工具使用、更长上下文、推理轨迹、电脑使用——这项工作就会悄无声息地落在评估团队身上。因为历史测试案例是在一个模型不会以这些新方式失败的体系下构建的。测试套件依然显示绿色，头条基准测试分数在上升，但生产环境的发布却暴露出了没人写过测试的失效模式。

这种“税收”很少被列入路线图的项目清单中。它表现为归因错误的进度滞后（“模型集成比我们想象的要难”），表现为评估团队积压工作的悄然扩张，或者表现为发布两周后的一次事故——视觉功能自信地误读了一张截图，而这种错误是纯文本测试套件永远无法捕捉到的。发布过两三次新能力的团队不再感到意外。而第一次发布新能力的团队则会被这项税收的方方面面同时击中，并将其称为运气不好。

补填工作到底包含什么

评估团队在发布后的检查清单比大多数产品经理意识到的要长。每一项都是独立的工作，有自己的负责人、依赖关系和失效模式。

在新的能力范畴下重新对旧案例进行评分。 一个纯文本评估案例的问题是“总结这篇文章”，评分标准关注忠实度、幻觉率和长度合规性。增加视觉能力意味着这篇文章现在可能以截图的形式出现，而新的失效范畴包括 OCR 漂移、布局误读和微小文字遗漏——现有的评分标准没有一个包含这些内容。要么评估案例在能力更新后失效，要么其评分标准增加新的维度并需要重新标注。无论哪种选择都是工作量。

为新的失效模式生成对抗性案例。 一个不能“看”的模型不会误读嵌入的水印，不会混淆同一页上的两张图表，也不会被遭受提示词注入攻击的图像所欺骗。一旦它能看见了，这些都变成了真实的攻击面。评估团队必须要么从头编写对抗性案例，要么从公开基准测试中借用并根据团队自己的评分标准重新标注——而公开基准测试从未针对生产查询分布进行设计，因此覆盖面充其量是局部的。

重新校准评判者。 如果团队使用以大模型为评判者（LLM-as-a-judge），那么评判者的提示词是针对不包含图像基础回复、关于视觉模糊性的解释性拒绝或多模态工具输出的输出形态编写的。评判者现在会自信地对它没有评分标准的输出进行评分，通常是将其强行压缩到它确实知道如何评分的、最接近的文本概念中。修复方法是针对新输出空间中人工标注的示例进行重新校准——即使是小样本，这也是一项耗时数天的练习。

针对新能力进行评估集版本管理。 当你在灰度发布期间在生产环境中同时保留纯文本和视觉路径时，你现在拥有一个需要评估两种不同能力范畴并让它们保持相当标准的测试套件。如果评分标准将两者合并为一个分数，那么这个分数就是虚假的。如果将其拆分，那么每个下游仪表板、告警规则和每周审查都需要更新。

孤立来看，这些项目没有一个是合理的。它们之所以成为一种“税收”，是因为它们都在能力落地的同一天到来，而且没有人为它们在能力发布预算中预留空间。

为什么历史评估集对新故障保持沉默

一种自然的直觉是，一个拥有 2,000 个案例的评估集肯定能捕捉到一些新的失效模式，哪怕是纯属偶然。但在实践中，它几乎捕捉不到任何模式。原因是测试集构建方式中一个微妙的属性：案例是从模型在策划时可能表现出的失效模式中抽样的。纯文本模型无法产生 OCR 错误，因此测试套件中没有任何案例旨在暴露 OCR 错误。那些看起来应该能发现问题的案例——比如关于文章中图表的查询——是在假设图表内容已转录到提示词中的前提下构建的。模型从未被要求去真正读取图表。

这意味着评估集不仅在新能力上是不完整的，而且在结构上对其是盲视的。添加更多相同形态的案例没有帮助。团队需要的是那些设计假设就是新能力的案例，而不是碰巧提到它的案例。

第二个复合效应：针对旧输出形态训练的评判者会可靠地误评新的输出形态。一个评分标准为“回复是否引用了相关章节”的评判者提示词，会悄悄接受一个通过视觉位置而非文本引用章节的视觉回复，即使视觉位置是错误的。评判者不知道如何惩罚这一点，因为没人告诉它去观察。因此，评估套件显示绿色并不是因为模型是正确的，而是因为评判者不具备发现错误的能力。

加载中…