2 篇博文 含有标签「regression-testing」

大多数团队作为回归测试套件运行的评估集，是由一名工程师在项目第三周手工挑选的。到了第六周，因为没人想在发布前动它，它就被冻结了；而到了第九个月，它正被用来拦截部署。产品已经调整了两次。用户群翻了三倍。LLM 在生产环境中实际遇到的案例与那个冻结的测试集重合度可能只有 40%。当测试集通过时，没人相信它；当它失败时，没人知道是真实的失败，还是案例已经过时。团队写了一份提议“v2 评估集”的文档，却从未真正动手。

与此同时，系统在生产环境中处理的每一个请求都已被记录在追踪后端中。每一个提示词、每一次工具调用、每一项中间输出、每一次拒绝、每一次重试——所有这些都存储在对象存储中，按时间索引并带有 span 标签，随时准备回放。团队所能拥有的最高保真度的测试语料库已经在磁盘上了。他们却从零开始构建了一个评估集，而不是从中读取。

仪表板显示，这个版本的质量提升了两个点。文本评估套件运行正常。你的模型供应商发布了一个新的 Checkpoint，在你跟踪的每个公开基准测试上都超过了前一个版本。你推进了发布。一周后，支持团队标记了一个隐蔽但持续增长的工单量上涨，内容关于上传的屏幕截图 —— 用户反映模型“读错了图表中的数字”或“漏掉了表格中的一行”。几天后，音频转录的投诉接踵而至，主要来自非美式英语使用者。这些都没有出现在你的评估流水线中。发布看起来很健康。但事实并非如此。

这就是多模态评估漂移（Multimodal Eval Drift），几乎每一个在以文本为核心的架构上硬塞进视觉和音频功能的团队都在发布这种问题。曾经适用于文本的评估规范 —— 黄金集（Gold Sets）、LLM 作为评委（LLM-as-judge）、漂移仪表板、以及决定是否发布的综合评分 —— 在多模态领域仅剩空名。每个模态的失败率不具可比性，捕捉文本错误的评分标准（Rubrics）捕捉不到图像错误，而且产生文本黄金集的标注流水线是针对每半年发布一次的工作量校准的，而不是针对伴随每次 Checkpoint 更新而来的多模态退化。

正确的心智模型是：多模态并不是同一个模型上的一个开关 —— 它是一个具有不同失败分布的不同产品面，而忽视了这一区别的评估规范在每次模型发布时都在输出隐形的退化。