立场：停止每次被动修补模型，开始主动测试驱动的AI开发

# 停止被动修补模型，转向主动测试驱动的AI开发  
来源：https://arxiv.org/html/2607.20532  

###### 摘要  

许多现代AI系统设计用于在多样化、开放式的用例下运行。为了帮助泛化部署系统，许多部署系统维护管道采用反应式AI飞轮，观察用户行为中新出现的反馈（错误）并相应地修补模型。然而，当作为主要维护机制时，这些飞轮往往忽略这些错误在系统目标中的更广泛背景，未能预先防范潜在的未来边缘案例，从而导致更多不必要的飞轮迭代。此外，由于开放式世界用例的长尾特性，统计上收集剩余错误变得越来越困难（Boneh和Hofri，1997 (https://arxiv.org/html/2607.20532#bib.bib23)）。本文主张需要一个*主动测试驱动飞轮*来解决反应式飞轮的局限性，并接近可泛化系统。我们倡导创建一个“测试空间”，在技术上将反馈数据映射到任务目标，从而将飞轮从反应式演进为主动式。我们通过数学证明主动式飞轮比反应式飞轮以更少的迭代实现更好的长期扩展，来强化我们的立场。  

数据中心的AI，模型评估  

见图1：反应式和主动式AI飞轮概览。在反应式范式中，反馈被分类处理，具体错误被修补（例如“行人”和“消防车”），未能泛化到具体错误之外。相比之下，主动式范式将反馈映射到所需任务条件的测试空间，并处理整个任务条件（例如“为公共服务车辆让行”和“识别人员”）。这种主动式支持改进泛化和未来错误预防。为了视觉清晰，测试空间被表示为2D空间，每个反馈与一个任务条件相关联。由于主动式飞轮在结构上组织反馈的方式不同，反应式分类中归为一组的相同反馈可能落入测试空间的不同区域。  

## 1 引言  

近期机器学习进展催生了多个商业AI系统——从语言模型到机器人和自动驾驶（AD）——其雄心勃勃的目标是在不断扩展的用例下进行开放式现实世界操作。这些AI系统需要卓越的泛化能力，以适应包含新用户上下文和交互的未知情况。我们尤其在实际AI（例如机器人和AD系统）中看到这一需求，其中现实世界的交互测试分布极为广泛（Palma，2025 (https://arxiv.org/html/2607.20532#bib.bib4)；Dnistran，2025 (https://arxiv.org/html/2607.20532#bib.bib2)）。从ImageNet的出现到最近的GPT模型，开发通用AI系统的传统方法强调使用大型、多样化的训练数据集作为实现泛化性的经过验证的方法（Deng等人，2009 (https://arxiv.org/html/2607.20532#bib.bib18)；Achiam等人，2023 (https://arxiv.org/html/2607.20532#bib.bib6)）。现在，基础模型（FMs）加速了训练泛化AI系统的过程，因为系统可以轻松构建在FMs之上，而这些FMs是在多样化的、互联网规模的数据上训练的（Rankin，2025 (https://arxiv.org/html/2607.20532#bib.bib11)）。具体而言，更快的开发意味着更快的系统部署。一旦部署，任何测试反馈都是更新系统的重要信号。现在的问题是，我们如何有效利用这些信号并修复系统？已部署AI系统的一种常见且公开记载的维护模式是“飞轮”循环——一个通过利用系统反馈（从轻微边缘案例到灾难性失败，例如AD中快速、急转弯到碰撞）持续改进系统的循环。为简洁起见，我们将此反馈谱系统称为泛化“错误”。由于飞轮对实际测试反馈做出反应，我们将此范式称为“反应式测试驱动”飞轮（RF）。在此范式中，反馈数据被记录并分类，通常借助人工干预。一种常见的数据中心实践是从预先存在的数据湖中检索与反馈数据相似的数据，甚至从头收集，以重新训练和验证模型（Clips，2022 (https://arxiv.org/html/2607.20532#bib.bib7)），而模型中心的实践则直接训练反馈数据（Yao等人，2021b (https://arxiv.org/html/2607.20532#bib.bib5)）。RF因其能够产生明显的短期进展并与软件维护的事件响应工作流对齐而具有操作上的吸引力（Sillito和Kutomi，2020 (https://arxiv.org/html/2607.20532#bib.bib50)）。  

反应式飞轮面临三大挑战。首先，通过仅考虑与错误相似的数据或直接训练错误本身，纯反应式飞轮侧重于修补特定的观察到的错误（Ilharco等人，2022 (https://arxiv.org/html/2607.20532#bib.bib214)），这与泛化性目标相反。因此，这种纯反应式循环仍然是防御性的，未能防止未来的漏洞。例如，在2023年一起涉及一辆亮灯停泊消防车的致命自动驾驶车辆（AV）碰撞事故后，由于缺乏报告消防车碰撞的案例，表明该特定场景可能已经被修补（ABC7，2023 (https://arxiv.org/html/2607.20532#bib.bib1)）。然而，2025年一起涉及同一AV系统和一辆亮灯停泊校车的潜在致命碰撞揭示，根本原因——在附近有行人的交通中停泊的公共服务车辆——仍未得到解决（Dnistran，2025 (https://arxiv.org/html/2607.20532#bib.bib2)）。修补消防车事件未能泛化到功能相同的校车场景，如图1 (https://arxiv.org/html/2607.20532#S0.F1)所示。  

其次，RF效率低下。无法预先防范未来错误，RF导致更多迭代和积压，从而对固定资源造成压力。最后，反应式飞轮假设它们最终会遇到所有边缘案例。然而，随着更多边缘案例被发现，遇到剩余案例显著变得更困难。这被称为优惠券收集问题（Boneh和Hofri，1997 (https://arxiv.org/html/2607.20532#bib.bib23)），在物理AI中尤其危险，因为等待极其罕见且可能不安全的案例出现会带来不可接受的安全风险，正如Koopman（2024 (https://arxiv.org/html/2607.20532#bib.bib12)）所观察到的。  

为了克服这些挑战，我们主张，*要实现可泛化的AI系统，反应式测试驱动补丁在结构上是次优的，需要目标导向、主动测试驱动的飞轮*。重新审视自动驾驶（AD）的消防车和校车场景，揭示了AD目标中的一个共同根本原因：未能为停在交通中靠近行人的公共服务车辆停车。美国国家公路交通安全管理局（NHTSA）（USDOT，2017 (https://arxiv.org/html/2607.20532#bib.bib3)）的AD指南将这些车辆检测、因关联性预测附近行人以及应对这些异常状况列为核心要求。这些在机动车辆管理局（DMV）手册中也有涵盖（DMV，2025 (https://arxiv.org/html/2607.20532#bib.bib8)）。如果最初的消防车错误被映射到各种必需的驾驶任务条件，修复这些条件本可以防止后续的校车事件。我们在图1 (https://arxiv.org/html/2607.20532#S0.F1)中展示了这个反应式与主动式对比的示例。为了解决RF的第一个局限性并引入预防优势，关注任务条件将飞轮从防御性修补转变为主动优化。因此，我们认为，*需要覆盖“测试空间”* 以将反应式测试驱动飞轮演进为主动式测试驱动飞轮。受“训练空间”——用于传统数据集策展中数据多样性选择的n维训练数据映射（Shen等人，2025 (https://arxiv.org/html/2607.20532#bib.bib14)；Diao等人，2025 (https://arxiv.org/html/2607.20532#bib.bib13)；Slyman等人，2024 (https://arxiv.org/html/2607.20532#bib.bib16)；Sener和Savarese，2017 (https://arxiv.org/html/2607.20532#bib.bib15)）——的启发，对于给定任务，我们将“测试空间”定义为包含任务条件向量化表示且无需系统数据的n维空间。操作上，主动目标不仅仅是命名这个空间，而是改进对其重要区域的覆盖。一个具体的地图集式实现可以将此空间视为任务条件的地图集：地图集定义了哪些条件可以被覆盖，而频率加权地图集指定了每个条件应指导更新的强度。在图1 (https://arxiv.org/html/2607.20532#S0.F1)中，我们可视化了测试空间在AD示例上的效果。通过将系统错误映射到这个空间，主动飞轮可以处理整个任务条件，而不是孤立的错误。这种设置还通过绕过通常用于反馈分类的人工干预来鼓励自动化。为了加强我们的立场，我们数学证明即使是我们测试空间主动飞轮的简单设计，也能通过以更少的飞轮迭代和积压实现明显更好的长期扩展，从而克服RF的第二个局限性。此外，由于主动飞轮不依赖收集所有边缘案例来修复潜在错误，它减轻了优惠券收集问题的安全后果，即RF的最后一个局限性。最后，我们讨论了开发测试空间驱动的主动飞轮的开放挑战，以指导未来研究。  

## 2 反应式飞轮简述  

由于事件驱动和观察失败驱动的更新循环在已部署ML系统及相邻研究中很常见，我们首先讨论为什么反应式AI飞轮对研究和行业社区仍有吸引力（Clips，2022 (https://arxiv.org/html/2607.20532#bib.bib7)；Tang等人，2020 (https://arxiv.org/html/2607.20532#bib.bib9)；Yao等人，2021a (https://arxiv.org/html/2607.20532#bib.bib10)）。我们参考附录A (https://arxiv.org/html/2607.20532#A1)以获取驱动这些动机的扩展相关研究文献。  

错误是有限的，最终都会出现。反应式错误修正隐含地假设可能用例及相应错误的宇宙是有限的。这在封闭集机器学习（ML）中似乎合理，其任务集合是有限且可枚举的（Geng等人，2020 (https://arxiv.org/html/2607.20532#bib.bib24)）。反应式迭代策略在ML研究中很常见，并得到学习曲线（Viering和Loog，2022 (https://arxiv.org/html/2607.20532#bib.bib149)）、难负样本挖掘（Shrivastava等人，2016 (https://arxiv.org/html/2607.20532#bib.bib55)）和主动学习（Cohn等人，1996 (https://arxiv.org/html/2607.20532#bib.bib131)）等概念的支持，这些概念认为ML模型通过解决发现的弱点随时间改进。这带来了这样的直觉：尽管边缘案例的长尾很广泛，但我们正在逐步解决，并且关键的是，这个过程会足够快地收敛到实用程度。鉴于大型语言模型在基准测试上快速性能提升直至几乎解决基准（Brand和Denain，2025 (https://arxiv.org/html/2607.20532#bib.bib22)）等例子，这一假设似乎合理。  

已知错误的积压是暂时的。反应式维护还假设任何未修复错误的积压是一种暂时现象，工程团队会随时间逐渐减少。在早期部署中，随着新的错误模式涌入，问题积压可能会积累，但从业者通常认为随着模型成熟，积压会缩小。这类似于软件项目中的“错误积压”，通常在上线后达到峰值，并在几个更新周期后清除（Mockus等人，2002 (https://arxiv.org/html/2607.20532#bib.bib213)）。ML社区继承了这种直觉：他们期望在最初的发现激增之后，模型将达到一个平衡状态，新错误变得罕见且大多是次要的，使得未解决问题得以解决（Sculley等人，2015 (https://arxiv.org/html/2607.20532#bib.bib49)；Shrivastava等人，2016 (https://arxiv.org/html/2607.20532#bib.bib55)）。  

## 3 比较反应式与主动式  

在现实世界中运行的现代AI系统暴露于无数的场景，涵盖无数用户上下文和边缘案例。然而，当前的反应式飞轮假设这些场景是有限的。为了在单一设置下隔离和比较反应式与主动式范式的扩展行为，我们引入一个简化的飞轮模型，该模型遵循反应式飞轮的隐含假设（错误是有限的），从而有利于反应式设置。我们将所有证明（定理等）留于附录。  

### 3.1 模型设置  

考虑由开发者部署的ML模型。存在一组 \(M\) 个未发现的使用场景，模型最初没有经过充分训练，在部署中会失败。这些场景可能对应长尾稀有事件或潜在的新用途，在开发期间未被强调。例如在AV中，一个稀有使用场景可能是“为停在靠近行人的交通中的公共服务车辆停车”。实际上，尽管高流量部署会遇到重复事件，但为分析方便，我们假设每个 \(M\) 场景都是不同的。在测试空间设计下，这些 \(M\) 场景由 \(K\) 个因子刻画。为进一步简化分析，我们假设每个场景与一个因子相关联。因子将场景均匀划分，每个因子得到一组 \(M/K\) 个场景。这些假设仅为了分析清晰，不影响反应式与主动式范式之间的定性分析和比较。虽然我们定义了有限的 \(M\) 和 \(K\)，但我们的分析将关注这些参数的渐近性质。我们还注意到，人力工作量随事件数量扩展，而不仅仅是不同的场景数量 \(M\)。因此分析低估了人类注意力的消耗。在时间 \(t=0\) 时，模型部署给用户。每个时间步 \(t\) 反映一轮AI飞轮，其中模型被使用、提供反馈、模型被更新以解决这些反馈。*开发者的目标是在尽可能少的飞轮迭代中发现并更新模型以纠正所有 \(M\) 个场景。* 在每个时间步 \(t\)，设 \(i \in [M]\) 为从 \(M\) 个场景中均匀随机抽取的一个场景，设 \(\mathcal{K}(i) \subset [M]\) 为此场景所属的组，设 \(\mathcal{U}_t\) 为模型在时间 \(t\) 无法处理的场景集合，初始化为 \(\mathcal{U}_0 = [M]\)。如果 \(i \in \mathcal{U}_t\)，则用户交互导致模型错误。开发者记录此事件并尝试更新模型以解决错误。如果开发者成功，则 \(i\) 在下一个时间步被从 \(\mathcal{U}_{t+1}\) 中移除。每次飞轮迭代产生事件分析、数据获取、重新训练和重新部署的成本。在固定资源预算下，观察到有限数量的错误，开发者可以采用不同的策略来处理错误。我们注意到，在实践中，开发者每次迭代会解决大量错误，尤其是对于高流量产品。