用于互联自动驾驶的五层MLOps架构

机器学习操作（MLOps）范式将DevOps范式扩展到基于机器学习的系统的特定挑战。当这些系统嵌入自动驾驶系统（ADS）时，由于它们在复杂、动态、开放的世界环境中运行，它们面临着额外的要求，在这些环境中，误用、故障或功能不足可能会对人员、财产或环境造成严重伤害。为了应对这些挑战，已经制定了一些法规和标准。在EU，《人工智能法案》（AI  Act）为人工智能系统提供了统一的法律框架，包括ADS等高风险人工智能系统。《人工智能法案》要求特定行业的立法与其强制性要求保持一致，例如《型式批准框架条例》（the Type Approval Framework  Regulation）（EU）2018/858《一般安全条例》（the  General  Safety Regulation）（EU）2019/2144，以及（EU）2022/1426中ADS型式批准的实施规则。

重要标准包括功能安全（FuSa）的ISO 26262、预期功能安全（SOTIF）的ISO 21448和ADS安全设计、验证和确认的ISO/TS 5083。人工智能系统在ISO/PAS 8800中有所涉及，该标准提供了一个基于ISO 26262和ISO 21448的人工智能安全管理框架。UL 4600描述了适用于在自动驾驶模式下运行并结合人工智能技术的车辆的安全案例评估标准。在联合国层面，NATM ADS验证指南旨在提供一种可重复、客观和基于证据的多支柱方法来验证ADS的安全性。联合国全球技术法规（GTR）草案通过定义统一的ADS要求和相应的合规性评估，以此指导为基础。这些文档提供了重要的指导方针，但它们没有指定能够满足要求的具体架构。虽然这是有意为实施提供灵活性，但这也意味着如何为ADS设计和实施MLOps流程的问题仍然悬而未决。研究和行业都为定义可应用于ADS的MLOps过程的抽象、需求或组件做出了重要贡献。然而，仍然需要一个全面的架构，将这些贡献整合到一个连贯的概念蓝图中，以实施ADS的MLOps流程。

图1：拟议MLOps架构的五层

此外，之前的工作还没有集中在车辆连接的潜力上，以扩展对学习机会的检测，使其超出可以在单个车辆数据中检测到的边缘情况。本文解释了Shalev Shwartz等人定义的黑天鹅事件如何通过多辆车的集体评估来检测，作为遵循所提出架构的MLOps过程的一部分。本文的贡献如下：

• ADS的五层MLOps架构，可实现集体、持续学习，并持续保证安全和性能。

• 描述实现封闭MLOps循环的层职责和跨层交互。

• 一个多层次的自我评估概念，用于检测和减少包括黑天鹅事件在内的边缘情况。

MLOps范式将DevOps范式扩展到开发和部署机器学习模型的具体挑战，即机器学习产品的操作化。MLOps范式包括“在机器学习产品的端到端概念化、实施、监控、部署和可扩展性方面的最佳实践、概念集以及开发文化”。它需要解决Sculley等人描述的ML特定挑战。表一总结了这些关键的机器学习特定挑战。

图2：MLOps生命周期描述了集成ML模型开发和模型运行的连续过程，以自动化和简化ML模型的软件交付管道

图2中描述的MLOps生命周期是一个连续过程的抽象说明，该过程集成了ML模型开发和操作，以自动化和简化ML模型到生产环境中的交付。无限循环表示包括表2中描述的一组迭代阶段的连续循环。图3提供了实现图2中所示MLOps生命周期的典型MLOps过程的架构。提供ML模型，并向所述服务的消费者提供预测服务。预测服务从特征存储接收其输入数据。或者，服务也可以直接使用来自服务消费者的输入数据。

图3：实现MLOps生命周期的典型MLOps流程的架构。该图描绘了最重要的任务和存储组件，并显示了它们之间的一般数据流

表1：MLOPS范式需要解决的关键ML-SPECIFIC挑战

表2：MLOPS生命周期中关键阶段的描述，分为ML和OPS部分

监测预测服务的性能，如果性能下降，例如由于数据漂移（参见表1），可以触发用于重新训练模型的自动训练管道。在这种情况下，模型训练包括更新模型权重以提高模型性能，将模型应用于验证数据以选择要测试的模型，以及在专用测试数据上测试模型以给出模型性能的无偏估计。在元数据存储中跟踪训练运行，并将相应的模型保存到模型注册表中。

性能监控中的严重性能下降或其他异常也会触发数据记录，这些记录可以输入到特征存储中，其中包括将原始数据转换为有用特征的预处理步骤。它们还可能引发开发人员进行更彻底的数据分析。这些可以执行探索性数据分析，调整自动训练管道，请求更多或不同的带注释数据进行训练，尝试新的模型架构，或调整训练超参数。

对生成的模型和训练管道本身的性能进行了分析。纠缠（参见表1）使这些步骤特别困难。在元数据存储中跟踪实验，并将相应的模型保存在模型注册表中。如果训练管道性能和模型性能满足各自的要求，则自动训练管道的源代码库将被更新并自动构建、测试和打包。部署生成的工件，可能之前会经过一个阶段和质量保证（QA）环境。

一旦自动训练管道生成的改进模型被推送到模型注册表，预测服务就可以用新模型进行更新，循环重新开始。这种架构的一个关键特征是，开发人员不直接生成要部署的模型，而是开发和维护生成模型并评估其性能的自动化训练管道。

表3列出了操作配备ADS的车辆的挑战，这些挑战要求ADS的ML系统和MLOps架构的设计不同于许多传统的、更集中的ML系统及MLOps体系结构。与许多其他基于机器学习的系统相比，这些特性的结合使得ADS的MLOps架构的设计特别具有挑战性。

表3：配备AD的车辆的特性，需要为ADSS设计MLOPS架构，以区别于许多传统的MLOPS流程

配备ADS的车辆的高风险性质非常强调MLOps流程的性能监控部分。在ADS的MLOps背景下，多级性能自我评估（参见表四）对于检测学习机会非常重要，例如，当ML模型的性能不足时，应触发数据记录，以便开发人员将获得的见解和新数据纳入受影响的ML模型的持续学习过程中。自我评估对于维持车辆的运行安全也很重要，例如，在某些操作条件下触发最小风险机动。

ADS的架构允许在不同级别进行自我评估。遵循微服务架构的ADS可能由不同的服务（例如，对象检测）组成，这些服务是不同子系统（例如，感知）的一部分，而这些子系统又是整个ADS的一部分。多辆配备ADS的车辆组成一个车队，可能由额外的非车载系统支持。这些车队级实体之间的连接也允许进行集体评估。数据可以在车辆和车外系统之间共享，以便进行集体分析，例如在云后端。

表4列出了评估是否应记录数据的不同级别，以及在这些级别可能出现的示例性挑战。为了更好地了解在配备ADS的车辆车队中出现的学习机会，图4中引入了置信度性能矩阵。它描述了系统在满足其当前功能要求方面可以具有的置信水平的不同组合，以及这些要求是否实际得到满足。在这种情况下，“系统”可以指不同的级别，如表四所示。该矩阵的灵感来自ISO 21448（SOTIF）图6中场景类别的可视化。

表4：配备广告系统的车队的评估水平和相应的挑战

图4：置信性能矩阵描述了系统在满足其当前功能要求方面的置信水平和实际满足要求的程度的不同组合。系统的运行可分为四类：可靠行为、防御行为、危害行为、高风险行为。颜色表示相关的风险水平：绿色（低风险）到红色（高风险）。高风险行为对应于持续改进ADS性能的特别重要的学习机会

在那里，场景根据它们是已知的还是未知的，以及它们是否危害进行分类。在ISO 21448中，知识维度反映了SOTIF生命周期内的知识状态。相比之下，图4中的置信度性能矩阵是指系统本身的运行时状态。可靠的系统行为以高性能和高置信度为特征。在这种情况下，没有立即需要改进该系统。数据记录可能会被触发，但不是必需的。高绩效加上低信心会导致防御性行为。由于系统不知道其实际性能是否足够，因此应采用安全功能。在这种情况下，数据记录可以被触发，因为低置信度可以作为触发器，也应该被触发，这是因为防御行为可能会对用户满意度产生负面影响，但也可能产生进一步的负面后果。

低性能加上低置信度可能会导致违反安全要求。这种组合代表了危害行为，可以对应于危害事件，即“可能导致伤害的事件”；因此，应采用安全功能。如果此类事件发生在可能导致伤害的场景中，并且系统无法控制危害事件，则此类行为可能会导致实际伤害。在这种情况下，可以而且应该再次触发数据记录。

相反，高置信度的低性能构成高风险行为，因为没有激活安全功能来实现安全状态。在这种情况下，系统不知道自己的局限性，可能会造成伤害。与危害行为相比，造成伤害的可能性更大，因为安全功能没有发挥作用，增加了危害事件无法控制的可能性，即使系统意识到这些事件是可以控制的。

从个人评估的角度来看，高风险行为与未知或黑天鹅事件有关。黑天鹅事件是指系统在不知道故障的情况下发生故障，并且故障不可再现或再现性未知的罕见事件。尽管在车辆级别很少见，但与常规边缘情况一样，此类事件在车队级别仍然很多。

通过将评估移动到更高的级别，例如通过聚合来自多个冗余服务的数据和置信度（子系统级评估），或通过聚合来自多种车辆的数据和置信度（集体级评估）。然而，并不能保证这总是可能的。

图4引入了信心作为操作系统性能旁边的第二个维度，因为特别是在高风险系统中，功能不足应在导致伤害之前被检测到，例如，当触发导致危害行为的条件不会导致伤害时，因为场景缺乏必要的条件。如果配备ADS的车辆闯红灯进入十字路口，但没有十字路口交通，仍应触发数据记录，以允许持续学习过程纳入此事件的数据，以便系统在未来发生相同或类似情况时显示正确的行为。优选地，即使当本地感知堆栈对不正确的交通灯解释高度自信时，也会触发数据记录。然而，如果ADS仅使用其自身的本地（不）确定性来确定是否应触发数据记录，则可能会错过此事件；因此，需要集体评估。这种集体评估可以结合多辆车和非车载系统的观察结果，以识别在单辆车层面上仍然不可见的不一致性。

实际上，图4中描绘的类边界不一定是离散的，而是连续的。尽管如此，该矩阵提供了一个有用的抽象概念来描述配备ADS的车辆车队中出现的学习机会。该图还说明了由于资源限制或隐私问题而试图将更高层次的数据聚合最小化与最大化检测到的学习机会之间的困境。

即使ADS的置信水平很高，可能仍需要在更高的评估水平上汇总数据和置信度。在这些情况下，需求甚至可能最高，因为系统可能没有意识到自己的局限性，也不会采用旨在实现安全状态的安全功能。因此，尽管看似不直观，但在个人ADS对其当前表现表现出高度信心的情况下，可能会出现通过集体评估进行集体持续学习的最重要学习机会。

图5：四个行为类别的相对份额会随着集体、持续学习的阶段而变化。总彩色区域对应于整个运行域。预期结果是更大比例的可靠行为（绿色）和更小比例的防御行为（黄色）、危害行为（橙色）和高风险行为（红色）

图5展示了MLOps过程中集体、持续学习的核心预期结果，即提高ADS作战域（OD）中可靠行为的比例，同时降低高风险、危害和防御行为的比例。这不仅可以通过提高基于ML的ADS的性能来实现，还可以通过更好的置信度校准来实现。

与标准MLOps架构（参见图3）相比，ADS的MLOps体系结构分为五层，而不是ML开发和ML操作之间的传统两层划分。请注意，图6中描述的大部分功能架构在ADS的通用DevOps架构中是相同的，该架构包括基于ML和非基于ML的应用程序。

图6：配备ADS的车辆车队的MLOps流程的五层架构，实现了集体、持续的学习。该图描述了最重要的任务和中央存储组件

A.开发层

开发层的主要目的是注释数据以构建训练、验证和测试数据集，以及开发训练管道组件以在模型训练层中执行。

具体而言，该层（1）添加和细化数据注释，可能利用模型注册表中的模型进行主动学习或注释辅助；（2）执行详细的数据分析，例如，当由评估层触发时；（3）进行实验；（4）分析开发数据集上的训练运行，主要是为自动化训练管道开发组件，源代码保存在相应的源代码库中；和（5）构建、测试和打包训练管道组件，以存储在包注册表中。

与典型的MLOps架构类似，该层不直接生成部署模型，而是专注于训练管道组件的开发和数据集的开发。

B.模型训练层

与图3中描述的标准MLOps管道相比，这一层仅用于自动生成和持续改进包含ML模型的应用程序。它不提供预测服务；这些由运行层处理。

具体而言，模型训练层（1）从特征存储中检索数据样本；（2）执行数据预处理；（3）在（4）从包注册表中的打包训练管道组件自动部署的自动训练管道内训练和评估模型（可选地从从模型注册表中检索的预训练模型初始化）。它（5）在元数据存储中记录训练元数据和统计数据；（6）在模型注册表中注册训练好的模型（具有来源和度量）；以及（7）将模型打包到应用程序中，明确描述输入和输出、功能和性能配置文件。

打包的应用程序存储在应用程序注册表中，并由评估层进行门控。模型训练层中的大多数方面仍然与标准MLOps管道相似，如远程协助、驾驶或干预，以及与乘客等非驾驶相关的任务和紧急处理。

与车辆运行层类似，车队运行层可以（3）运行影子模式车队应用程序，以测试新的或更新的软件开环。车队运营层还负责（4）在车队层面协调不同任务和应用程序的运营，包括跨多辆车或C-ITS中的其他实体协调任务。这也涉及在集体层面触发的数据记录。如果应用程序在评估层被标记为特殊部署，则车队运营层负责协调相应的部署策略。这些策略可能包括A/B测试，即将应用程序的两个版本部署到车队的不同部分并比较其性能；金丝雀测试，即将新版本的应用程序部署到车队中的一小部分，以限制潜在问题的影响；滚动更新，即在进一步进行之前，在监测问题的同时，逐步向车队的更大子集提供更新；OD限制测试，即允许车队和车辆编排层仅在特定的操作领域部署应用程序；受控部署测试，即，允许车队和车辆编排层仅将应用程序部署在车队运营商使用的特定车辆上，例如测试轨道测试或与安全驾驶员的现场测试。

车队监控（5）是另一个核心任务，可以在检测到异常、边缘情况和功能不足等情况下触发数据记录和/或车队编排任务。此外，车队运营层负责（6）汇总车队和车辆运营层的数据记录，可能用额外信息丰富数据，整理数据，得出统计数据，并将数据存储在车队数据存储中。最后，它负责（7）触发OTA更新，当新的或更新的已验证应用程序可用，并且车辆有资格并能够接收它们时，将应用程序从已验证的应用程序注册表移动到车辆应用程序注册表。

E.车辆运行层

车辆运行层负责运行每辆车。它（1）根据当前要求编排车辆应用程序注册表中可用的应用程序（参见Kampmann，（2）运行构成负责动态驾驶任务（DDT）的车辆ADS的应用程序，包括可能的安全功能，例如实现最小风险机动（参见Ackermann）、与远程操作员的交互、通过内部HMI与乘客的交互以及通过外部HMI与环境的交互；它（3）运行影子模式车辆应用程序，（4）与车队运营层交换实时数据，（5）监控基于车辆的数据以记录相关事件，特别是在异常、边缘情况、ODD边界接近/出口、检测到的功能不足以及ADS的激活/重新初始化和停用的情况下；并在需要重新配置ADS时触发编排器。最后，它（6）将记录存储在本地车辆数据存储中，以便稍后通过车队运行层传输到车队数据存储。

图6描述了单个车队的MLOps架构。它假设数据可以在所有层之间共享，以提高和确保整体系统性能，即操作MLOps流程的组织拥有对数据的所有必要访问权限。在多车队的情况下，多个组织运营自己的车队，但仍然共享某些层的某些组件，或者在不同层（或其部分）由不同组织运营的单个车队情况下，数据流将受到更多限制。在这些情况下，可以应用联合学习方法。

所提出的ADS MLOps流程的五层架构为车队运营商和其他利益相关者实施这一流程提供了概念蓝图，使他们能够持续确保其配备ADS的车队的安全性和性能。该架构旨在使标准MLOps架构适应与ADS相关的特定要求和挑战，并利用集体评估的可能性来检测和减少黑天鹅事件、其他功能不足和故障。

通过为基于机器学习的ADS提供集体、持续的学习，MLOps架构旨在随着时间的推移提高ADS在作战领域的可靠行为比率，同时降低高风险、危害和防御行为的比率。对每一层的任务和职责以及跨层交互的详细描述为实施相应的MLOps流程提供了一个全面的起点。未来的工作将包括这种实施，以实证评估架构，并确定潜在的差距和进一步改进的领域。

此外，有必要更详细地将架构组件映射到法规和标准的广泛要求，以评估架构是否需要调整或扩展以满足所有要求。同时，需要进一步的研究来确定是否应该扩展当前的法规和标准，以更好地支持基于ML的ADS的集体、持续学习。

最后，未来的研究应该调查所提出的架构对其他类别的复杂、高风险物理人工智能系统的适用性。

免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系alpha.yuan@houwa-tech.com告知，我们会在第一时间做出处理。