在本系列的第 1 部分中，我们描述了 BBVA 基于亚马逊 SageMaker AI 构建的 MLOps 架构，包括临时开发工作流程和模型治理。
在设计全球架构期间，BBVA 与四个业务部门并行合作，对现有的机器学习用例进行现代化改造。这种并行方法使团队能够从一开始就根据实际生产要求验证架构决策。
这些用例涵盖不同的领域（风险建模、定价优化、个性化推荐和财务预测）、数据规模、计算要求和团队成熟度水平。它们之间确定的通用模式有助于定义可重复使用的 MLOps 基础，该基础成为通用生产就绪模板的基础，同时也塑造了支持不同 ML 工作负载自定义模板所需的平台功能。
这篇文章介绍了 BBVA 如何利用这些试点项目来识别可重复使用的机器学习模式、标准化操作工作流程，以及设计可扩展的 MLOps 模板，以加速机器学习交付，同时保持团队和业务领域的管理和灵活性。
挑战
四个业务部门参与了最初的试点项目，尽管在不同的领域和地区开展业务，但他们还是分享了制定和标准化机器学习交付实践的机会。
尽管团队已经利用了代码存储库、实验跟踪和模型生命周期功能，但随着时间的推移，实施模式自然会独立演变，从而减少了团队间的重复使用，增加了具有相似技术基础的新项目的入职工作量。
围绕模型推广和管道管理的操作流程还将自动化和手动活动结合在一起，随着用例数量的增加，为提高可扩展性创造了机会。缺乏隔离的测试环境意味着验证管道变更需要合并到共享分支，从而减缓反馈循环。
团队已经具备了实验跟踪、模型注册和基本监控等治理能力，但实施方法因团队而异。标准化这些实践为提高整个 ML 生命周期的可追溯性、一致性和可见性提供了机会。
机会显而易见：通过将常用模式标准化为可重复使用的模板、简化运营工作流程以及将治理和可追溯性直接嵌入到开发体验中，加速机器学习交付并实现工业化。
方法论
在大型组织中实现机器学习工作流程现代化需要的不仅仅是引入新工具。BBVA 的目标是定义一种构建和操作机器学习的可扩展方式，使人员、流程、治理和技术保持一致。
为实现这一目标，BBVA 和 AWS 专业服务共同举办了一系列涉及多个业务部门的发现和评估会议。该团队在进行 MLOps 架构设计的同时进行了这些会议，从一开始就嵌入了业务、运营和治理要求。通过将 BBVA 的领域专业知识与亚马逊的向后工作方法相结合，这种调整使最终的架构建立在实际业务需求的基础上。
我们首先在同意成为该解决方案的早期采用者的四个业务部门进行了结构化探索会议。每个业务部门都带来了不同的 ML 技术用例（从 XGBoost 回归到深度神经网络）、不同的开发成熟度水平和运营限制。我们没有规定单一路径，而是使用这些会议来绘制这些不同的工作流程，以确定共同的模式、挑战和分歧。
这种双轨方法对于使现实世界的业务需求与正在设计的通用 mLOps 平台保持一致至关重要。结果是通过真实的数据点对整个组织的 “好” 是什么样子有了共同的理解。
这些探索会议的发现直接为可重复使用的 MLOps 模板和标准化操作工作流程的设计提供了依据。因此，该技术提案平衡了四个维度的标准化：
-人员，我们在此为从个人笔记本电脑工作转向协作、版本控制的流程提供了指导。
-流程，为代码审查、测试和部署建立标准。
-治理、嵌入合规控制、模型审批工作流程和可追溯性，以减少人工监督并确保监管的一致性。
-将 mLOps 模板集成到 ADA 平台的技术，在经过验证的生产就绪基础上启动新的机器学习项目。
解决方案概述
如第 1 部分所述，用户从 ADA 控制台中选择 MLOps 资产，为新项目配置专用 GitHub 存储库和标准化代码支架。该脚手架为机器学习生命周期提供了端到端的设置，包括用于训练、推理以及数据和模型监控的可重复使用的 SageMaker 流水线。这意味着团队可以针对其特定的机器学习用例进行自定义，同时继承平台的内置治理、实验跟踪和 CI/CD 集成。
训练管道
图 1：可重复使用的 MLOps 模板中的默认训练管道。
图 1 中的图表显示了可重复使用的 MLOps 模板中包含的默认训练管道。该模板显示了模型构建过程的离散步骤：数据处理步骤（SageMaker 处理或 Amazon EMR 步骤，视用例需求而定）、训练步骤、模型评估步骤、基于性能的条件检查、数据和模型质量检查以及向 SageMaker 模型注册表的注册步骤。团队通过添加满足其特定需求的步骤（例如额外的预处理阶段）来扩展此基础结构。
这种模块化设计允许：
-步进级缓存，在两次运行之间跳过不变的步骤，从而减少迭代开发期间的执行时间和计算成本。例如，当尝试不同的模型时，数据处理逻辑保持不变。
-一种以 CPU 为先的计算策略，其中管道仅将 GPU 实例用于需要它们的步骤，而处理和评估则在经济实惠的 CPU 实例上运行。
-在可行的情况下，基于 Python 的执行取代 PySpark。并非每个 ML 用例都需要分布式计算。对于这些情况，将步骤作为基于 Python 的 SageMaker 处理任务运行可以简化开发体验并消除对 EMR 集群的依赖。当用例需要大规模数据准备时，团队可以在同一管道中将 EMR 支持的 PySpark 步骤与基于 Python 的下游步骤相结合。下文将详细介绍这种混合模式。
-基于性能阈值的条件模型注册，仅将符合质量标准的模型升级到 SageMaker 模型注册表。
-训练步骤中集成了 MLFlow 实验跟踪，使用标准化命名约定将超参数、指标和工件记录到集中式跟踪服务器，将每次运行映射到相应的管道执行和模型注册表版本。
图 2：mlFlow 捕获训练中的指标并在仪表板中对其进行可视化。
推理管道
图 3：来自 MLOps 模板的推理管道。
上图显示了推理管道模板。AWS Lambda 步骤从 SageMaker 模型注册表检索最新批准的模型版本。然后，处理步骤准备输入数据，执行预测，并将结果存储在亚马逊简单存储服务 (Amazon S3) 中。与培训渠道一样，各团队通过额外步骤扩展了这一基础。关键功能包括：
-通过集中功能自动检索模型版本，该功能可解析 Amazon S3 中相应的模型工件，无需手动管理项目路径。
-无缝模型更新：用户配置推理管道以每次检索最新的批准模型版本。当经过再训练的模型通过第 1 部分中描述的批准工作流程（训练管道中没有实质性变化）过渡时，推理管道会自动选择该模型，无需对推理管道本身进行新的生产部署或重新批准。
在这两个管道中，这些设计决策缩短了迭代开发期间的管道执行时间，并通过将实例类型与实际步骤要求相匹配来优化计算成本。在运营方面，自动模型检索和集成监控缩小了模型部署与持续模型运行状况之间的差距，使团队能够以最少的人工协调保持最新的生产预测。
扩展 MLOps 模板
虽然默认模板涵盖了最常见的 ML 开发模式，但不同的业务领域引入了额外的技术和操作要求。我们没有创建互不关联的工作流程，而是扩展了可重复使用的模板基础以支持专业的工作负载，而不会偏离标准化管道结构。
用于深度学习的 GPU 加速训练
BBVA 的一个业务部门需要并行训练多个计算密集型深度学习候选模型。目标是根据评估指标仅动态选择表现最佳的模型，从而使该模型符合注册资格。该团队通过使 SageMaker Pipelines 能够并行运行多个训练作业来实现这一方案。随后的流程步骤将评估所有经过训练的模型，并根据预定义的业务标准选择最佳候选模型，自动将所选模型注册到 SageMaker 模型注册表中。
对于涉及深度神经网络或需要矩阵密集型计算的架构的此类用例，我们创建了一个模板，该模板可以自然扩展到由 GPU 支持的训练步骤。主要改编包括：
-训练步骤配置切换到 GPU 优化的实例系列（例如 ml.g5 或 ml.p4d），仅适用于训练步骤本身。处理、评估和监控步骤继续在经济实惠的 CPU 实例上运行，保留基本模板的成本优化策略。
-容器环境转移到支持 CUDA 的框架镜像（例如，支持 GPU 的 PyTorch 或 TensorFlow），而管道编排、实验跟踪集成和条件注册逻辑保持不变。
-平行训练步骤，允许团队在更短的时间内建立竞争模型，并在训练工作期间保持环境隔离。
该扩展展示了一个核心设计原则：无论计算后端如何，流水线框架（数据处理、训练、评估、条件检查和注册）都保持一致。采用 GPU 工作负载的团队继承与基于 CPU 的用例相同的缓存、监控和 MLFlow 跟踪功能，从而减少了支持异构模型架构的运营开销。
图 4：来自可重复使用的 MLOps 模板的扩展管道示例。
混合 PySpark 和 Python 流水线
一些业务领域在足够大的数据集上运行，需要分布式处理，而它们的下游训练和推理工作负载可以在单实例 Python 环境上高效执行。为了支持这些场景，我们使用混合执行模型扩展了可重复使用的 MLOps 模板，该模型将基于 Pyspark 的分布式处理与基于 Python 的 SageMaker 训练和推理作业相结合。
-数据处理步骤利用 SageMaker Pipelines 中的 EMR 步骤，使用直接从 ADA 平台数据湖提供的 PySpark 跨大型数据集进行分布式转换（联接、聚合、特征工程）。此步骤生成存储在 Amazon S3 中的经过处理的数据集供下游步骤使用。
-将数据转换为可供训练的格式后，后续步骤将作为基于 Python 的标准 SageMaker 处理或训练作业执行。这样可以避免为无法从分布式计算中受益的步骤配置 EMR 集群。
-该管道通过明确定义的 S3 路径和数据架构在 EMR 和 Python 阶段之间保持明确的契约，使团队能够在不中断另一个阶段的情况下独立迭代任一阶段。
这种混合执行模型允许团队将分布式处理的可扩展性与基于 Python 的机器学习开发的简单性和灵活性相结合，同时保持工作负载之间一致的编排、管理和监控框架。它还为团队提供了从完全基于 Spark 的机器学习工作流程向基于模块化且经济高效的 Python 执行模式的渐进迁移路径。
常见的可扩展性模式
这两个扩展都有一组模式，任何团队在调整模板时都可以应用这些模式：
-实例级计算专业化：每个管道步骤都声明自己的计算需求，允许将 GPU 实例、EMR 集群和 CPU 资源分配到需要的地方。
-与框架无关的编排：管道定义层（步骤排序、缓存、条件逻辑）与执行框架分离，无论是 GPU 上的 PyTorch、CPU 上的 Scikit-Learn 还是 EMR 上的 PySpark。
-一致的治理界面：无论使用哪种模板，每个管道执行都会记录到 MLFlow，通过相同的模型注册表工作流程注册模型，并与第 1 部分中描述的 CI/CD 自动化集成。
-多模型流水线：无论是用于训练还是推理，流水线模式都可以分支成并行路径，在不同的模型上训练和注册或运行推理，与顺序方法相比，减少了总执行时间。
这些扩展验证了模板架构可以吸收在初始评估会议中发现的多样性，从轻量级梯度增强模型到 GPU 密集型深度学习和大规模分布式处理，而不会分解成互不关联的、针对特定团队的解决方案。
经验教训和最佳实践
首批试点项目证实，当团队根据实际用例进行构建时，MLOps 标准化最为有效。他们帮助 BBVA 确定了项目间的共同模式，同时保持了不同数据量、模型架构、计算需求和治理要求所需的灵活性。
一个关键的经验教训是，模板应该起到加速器的作用，而不是约束作用。通用 MLOps 模板为训练、推理、数据监控和模型监控管道提供了可随时投入生产的基础，并且已经集成了 CI/CD、实验跟踪、模型注册和治理功能。团队可以在需要时扩展这些管道，同时仍遵循一致的生命周期模型。
试点项目还表明了改善开发者体验的重要性。基于拉取请求的临时环境允许团队在将变更合并到共享分支之前对其进行安全验证，从而实现更快的反馈、并行开发和更好的协作。结合自动测试、代码审查和安全检查，这种方法可以提高速度和质量。
另一种最佳做法是在步骤级别上优化管道。通过为每个阶段分配正确的计算资源，使用缓存，并在适当的情况下组合 PySpark、Python、CPU 和 GPU 工作负载，团队得以缩短执行时间并提高成本效率。
该团队还将治理直接嵌入到机器学习生命周期中。标准工作流程处理模型版本控制、审批工作流程、MRM 集成、监控和可追溯性，从而减少了手动工作量并使合规性更易于遵循。
总体而言，首批试点表明，标准化但灵活的 MLOp 运营模式可以加速开发，提高执行效率，降低成本，提高知名度并加强治理。试点项目确定了以下最佳实践：
-从实际用例开始。
-重复使用可用于生产的模板。
-启用临时验证环境。
-优化每个管道步骤的资源。
-从一开始就集成监控。
-通过设计嵌入治理。
结论和后续步骤
西班牙对外银行采用的第一波 MLOps 证实了朝着更标准化、可重复使用和更受管控的方式大规模交付机器学习解决方案的价值所在。通过从实际生产用例出发，BBVA 定义了一个通用的 MLOps 基础，该基础可以加速交付，同时保持不同业务领域、技术模式和监管要求所需的灵活性。
这种新的工作方式已经在帮助团队减少碎片化，改善重复使用，并加强他们在生产环境中控制、监控和操作机器学习解决方案的方式。这些改进从 30% 到 75% 不等。低端来自步进缓存，它消除了冗余处理。高端产品反映了从基于笔记本的工作流程向模块化管道的迁移，该流水线结合了 CPU 优先计算和基于 Python 的执行。
BBVA 将继续通过以下方式发展和提高这些能力：
-在更多团队、地区和机器学习项目中扩大采用率。
-通过生成式 AI 功能（例如辅助文档、模板生成和智能指导）丰富开发者体验。
-在相同的运营基础上，向更广泛的 AIOps 能力迈进。
总体而言，这种演变代表了 BBVA 实现人工智能和机器学习交付工业化的重要一步。它使该组织能够更高效地提供可靠、受管控且可随时投入生产的人工智能解决方案，最终目标是为 BBVA 运营所在国家的客户提供更好、更快、更安全、更个性化的服务。