BBVA 通过 ADA 及其全球分析、数据和人工智能平台的发展，继续实现其机器学习（ML）能力的工业化和扩展。ADA 平台目前为七个国家的数据科学家提供服务，提供对开发环境、共享数据资产和生产部署能力的集中访问。它还提供标准化的 ML 管道，数据科学家使用这些管道在业务部门之间一致地构建和部署模型。

随着采用率的扩大和整个银行用例的多样化，有必要在此坚实的基础上再接再厉，以实现更大的灵活性、可扩展性和自动化。这包括让团队能够构建针对特定业务需求量身定制的更多模块化和可重复使用的机器学习管道，以及支持更快的实验和交付。

为了实施该框架，BBVA 利用 AWS 技术，这些技术提供了技术基础，同时支持银行在治理、风险管理和可审计性方面的高标准。

挑战

ADA 的机器学习工作流程建立在强大且管理良好的基础上，成功地支持了该平台的发展。随着用例规模和复杂性的增加，出现了新的优化和可扩展机会。

在开发方面，数据科学家利用标准化脚手架和基于笔记本的工作流程，实现了快速原型设计和早期价值交付。随着采用率的提高，重点转移到增强模块化、改善代码重用以及加强团队间的可重复性和版本控制实践上。协调各业务部门的开发模式已成为确保大规模一致性和长期可维护性的自然步骤。

同时，还有机会进一步赋予数据科学家更大的实验和迭代自主权，同时保持平台的稳定性和治理标准。

从运营角度来看，开发和治理流程的定义清晰有效，但作为独立的工作流程运行。随着模型和项目数量的增加，通过加强自动化和集成来简化生命周期管理成为当务之急。将相关资产（训练管道、模型、推理管道）整合到统一的项目结构中，并自动化审批和审计流程，将减少协调开销并增强可追溯性。

为了抓住这些机会，BBVA 和 AWS 合作设计和实施了基于 Amazon SageMaker AI 的现代 MLOps 框架，引入了云原生自动化，并在整个模型生命周期中强化了最佳实践。

解决方案概述

MLOps 架构为数据科学家和机器学习工程师提供了构建机器学习管道所需的基础设施和工具，用于训练、批量推理和监控，同时保持管理和可追溯性。

在 ADA 的平台中，用户通过从目录中选择 MLOps 模板资产来触发新项目的创建。这可以帮助各个国家和业务部门的团队从每个项目一开始就始终如一地工作。此部署收集重要的监管元数据，例如模型描述、企业所有者以及与将要开发的模型相关的模型等级。

每个项目都会自动预置一个专用 GitHub 存储库，其中包含一个基于 SageMaker Pipelines 的标准化代码支架，用于训练模型，将其与指标和元数据一起注册到亚马逊 SageMaker 模型注册表中。

该平台支持全自动机器学习开发工作流程，其中标准化构件和自助服务功能允许团队独立开发、测试和部署机器学习解决方案，同时依赖于共享的生产就绪基础。

它还提供了更高的灵活性，从单片方法转向了松散耦合的方法。

这使团队可以专注于提供业务影响，而不是管理基础设施和协调的复杂性。用户可以组合可重复使用的流水线组件，对其进行参数化并提高迭代效率，而不是一步实现端到端逻辑。

为了缩短测试时间，该解决方案部署了专用的临时开发工作流程来测试新功能，然后再将其合并到主分支。有关更多详细信息，请参阅 “临时开发工作流程” 部分。

开发和生产环境通过 GitHub Actions 过渡，GitHub Actions 附加到每个环境中的关联存储库分支。亚马逊 EventBridge 和 AWS Lambda 共同合作，按照模型治理政策规定的批准工作流程在生产环境中注册该模型。

图 1 — AWS 上的 MLOps 架构

工作流程

以下工作流程显示了如何在平台内端对端地应用这些功能。

实现 ML 模型的端到端工作流程遵循以下步骤：

-数据科学家在 ADA 控制台中创建项目。该平台使用 GitHub 操作自动配置项目资源，例如专用的 GitHub 存储库和必要的 CI/CD 工作流程。

-用户在功能分支中创建和工作并提交他们的代码。

-用户针对主分支创建拉取请求 (PR) 以进行沙盒部署。

-PR 的状态会触发 GitHub 操作。在 PR 保持开放的同时，将创建一个新的临时环境，提供临时资源，允许用户在沙箱中测试其新功能。

-当开发者将 PR 合并到主分支时，GitHub Actions 会移除临时环境并将所有 SageMaker 管道部署到沙盒账户中。

-开发人员将 PR 合并到主分支后，将这些资源部署到生产账户需要首先从 main 生成手动版本。在这种情况下，平台仅提供推理管道，集中部署。

-在执行训练管道和注册新模型的过程中，用户将模型版本升级为可生产版本，从而触发模型批准工作流程。请参阅 “批准工作流程” 部分。

-然后，下游应用程序使用经批准的模型和推理管道。

临时开发工作流程

BBVA MLOps 演变中最具变革性的创新之一是引入了临时开发工作流程。这种方法重新定义了数据科学家和机器学习工程师如何验证和迭代他们的工作，从基于合并的验证转向基于分支的模型，该模型支持更快的实验，同时保持质量标准。

在实现临时工作流程之前，验证变更需要将代码合并到共享分支（主分支）中，这给开发周期带来了额外的阻力。这凸显了更灵活的验证机制的必要性，这些机制可以在不影响共享环境的情况下支持更快的迭代。此外，这种迭代开发会生成一个新的流水线，该流水线以每次合并到主流的顺序版本命名，随着版本号的增加，未使用的管道激增。这种顺序方法在开发周期中引入了效率低下和潜在风险。

临时工作流程实现利用 GitHub Actions 和 SageMaker 为每个拉取请求创建隔离的临时资源。当开发者打开 PR 时，CI/CD 平台会使用 {PROJECT_NAME}-pr-{PR_NUMBER} 等命名约定自动在项目的沙盒账户中预置一整套资源（SageMaker 管道、SageMaker 模型包组和相关资源）。

该平台现在通过灵活的配置系统引入了 SageMaker Pipelines 管理，该系统允许团队启用或禁用特定的管道，即使存储库中存在代码也能防止部署。它还支持在创建或更新流水线时自动执行，能够直接在配置中指定执行参数，从而加快开发反馈循环。最重要的是，它支持特定环境的配置，允许团队为临时工作流程、沙盒和生产环境定义不同的行为。此功能是跨团队扩展 ML 开发的关键推动力。

图 2 — 临时开发工作流程生命周期

管道版本控制和资源管理

得益于 SageMaker 的新管道版本控制功能，BBVA 团队现在可以更有效地管理管道的演变。SageMaker 不是使用版本后缀创建全新的流水线定义，而是仅在流水线定义或步骤代码发生变化时本机生成新版本。这减少了管道资源的总数，同时提高了可追溯性，整合改善了配额管理，帮助团队减少配额消耗，实现了精确的回滚和比较功能。这项新功能允许团队跟踪管道定义的变化并比较不同版本的性能。

在使用这些新的临时工作流程时，多个用户可以跨分支和拉取请求工作，创建资源（管道、模型等）。临时工作流程系统实现资源清理，以防止成本积累。当 PR 关闭时，CI/CD 平台将执行多步销毁过程：停止运行执行、删除模型版本、删除管道定义和清理模型包组。这种资源生命周期管理已成为 BBVA 的 MLOps 模型中重要的运营学科。在试点用例中，自动清理使成本降低了 40-55％。

并行开发和企业整合

多个用户或团队可以同时使用不同的功能，每个功能都在自己的隔离环境中独立测试和运行。

开发人员可以快速迭代，自由实验，满怀信心地测试复杂场景，而不会影响其他团队或共享资源。这种并行性使试点用例中的开发时间缩短了 20-75%。

尽管临时工作流程提供了前所未有的灵活性，但它们不会影响质量或治理。部署临时资源的 GitHub 工作流程与 BBVA 的企业验证框架完全集成，可触发质量检查，包括 SonarQube 集成、安全漏洞扫描、合规性验证、自动测试和强制性代码审查。BBVA 已将这些特定于 MLOPS 的工作流程集成到其 GitHub Actions 的集中存储库中，使它们可以轻松地在银行的所有 MLOps 项目中重复使用，并确保质量始终如一，同时减少新项目的工作量。

模型治理框架

BBVA 已将模型管理直接嵌入到机器学习生命周期中。审批规则、职责分离、基于风险等级的晋升和可审计性不再作为互不关联的手动步骤处理，而是作为平台工作流程本身的一部分。SageMaker 模型注册表与银行的模型治理框架相集成，以编程方式执行这些规则，同时为数据科学家保持简化、受控的体验。

该框架解决了三个核心挑战：

-确保没有数据科学家可以批准自己的模型（防止自我批准）。

-根据模型风险等级自动做出促销决策。

-维护每个模型生命周期事件的集中审计跟踪。

这些控制措施有助于确保所有模型生命周期过渡均可追踪、可审计，并符合 BBVA 的内部风险管理政策。

模型生命周期阶段

在 SageMaker 模型注册表中注册的模型经历了四个阶段：开发、质量保证、预生产和生产。每个阶段与特定状态（进行中、待批准、已批准或拒绝）配对，决定允许的过渡以及每项操作的负责角色。有关更多信息，请参阅模型生命周期的暂存构造。

图 3 中的图表说明了允许的阶段和状态转换。

图 3 — 模型审批工作流程

沙盒账户中的所有数据科学家在 SageMaker Studio AI 中共享相同的 AWS 身份和访问管理 (IAM) 执行角色（有关角色配置的详细信息，请参阅第 3 部分：BBVA 如何在 AWS 上构建全球分析和机器学习平台）。为了区分个人用户，该平台使用 SourceIdentity，这是一种通过 AWS 安全令牌服务 (STS) 传播的属性，用于识别从 Studio 发出的每个 API 调用背后的个人用户。被动批准工作流程使用这种身份在整个模型生命周期中强制执行职责分离。

批准工作流程

治理框架实施不同的审批工作流程，每个工作流程都解决了不同的治理问题。

自动批准工作流程由于性能下降、数据集更新或业务需求的变化，生产模型经常需要重新训练。每次都要求完整的批准周期会使团队无法保持模型的最新状态。

自动批准工作流程解决了这个问题：如果已经获得生产批准的模型完成训练且未发生实质性变化，则该工作流程会自动批准新的模型版本，而无需重复管理流程。而且，如果管道定义发生了变化，则该模型必须经过完整的批准周期。

自动促销需要满足以下所有条件：

-训练管道创建状态为 “开发/进行中” 的模型包。

-与模型包关联的 Git 分支是主分支。

-同一 SageMaker 模型包组的先前版本处于 “生产/批准” 状态。

-之前获得生产批准的版本是使用与当前版本相同的训练管道版本生成的。

基于手动的批准工作流程当不满足自动促销条件时，数据科学家通过将模型生命周期从开发/进行中更新为质量保证/待批准来请求 QA 批准。另一位数据科学家审查了该模型，要么将其推广到下一阶段，要么拒绝它。

模型达到预生产/待批准后，该平台会根据模型的风险等级自动评估是否可以跳过企业主批准步骤。该工作流程会自动将风险较低的模型提升到生产阶段。而风险较高的模型需要另一位数据科学家来推广。

使用 AWS Step Functions 实现集中审批工作流程

ADA 使用 AWS Step Functions 构建了集中式被动批准工作流程。SageMaker 模型注册表中的每个 createModelPackage 或 updateModelPackage 操作都会触发一个 EventBridge 事件，该事件会启动 Step Functions 状态机，该状态机实时验证该操作并在需要时采取纠正措施。

沙盒账户向中央账户中的 Amazon DynamoDB 表报告模型生命周期状态。此表存储沙盒账户中每个模型包的阶段、状态和源身份，从而支持过渡验证、自我批准检测和回滚。

图 4 中的图表显示了状态机的简化流程。

图 4 — AWS Step Functions 模型批准工作流程

总体而言，状态机执行以下步骤：

-在 SageMaker 模型注册表中创建或更新模型包时，EventBridge 事件会触发状态机。

-Guard 检查可验证该事件不是源自先前的回滚，模型属于 MLOps 项目，并且该操作具有有效的源身份。

-状态机从集中式 DynamoDB 表中检索先前的生命周期状态。

-对于 UpdateModelPackage 事件，它会检测自我批准场景。对于 CreateModelPackage 事件，它会评估模型是否可以自动升级到生产环境。

-工作流程根据责任矩阵验证过渡，并回退所有无效的过渡。

-通过满足基于等级的跳过条件，模型将自动升级到生产模式。

-将模型生命周期状态保存到 DynamoDB，并将事件发送到中央账户以进行通知和审计。

跨模型生命周期的通知最重要的流程改进之一是 ADA 与模型风险管理平台之间的更紧密集成。BBVA 通过自动通知关键生命周期事件（例如项目初始化或生产推广），减少了开发、治理和风险管理之间的手动交接。这使两个平台保持一致，并提高了整个模型生命周期的可追溯性。

结论

BBVA 的 MLOps 转型表明，当应用于实际用例时，现代化机器学习实践如何带来切实的商业价值。

在四项试点计划中：风险建模、定价优化、个性化建议和财务预测团队，开发时间缩短了 20-75％，成本降低了 40-55％，具体取决于用例和 MLOps 成熟度的初始水平。这些改进是由 BBVA 内部新的 MLOps 运营模式推动的：标准化的项目创建、临时验证环境和自动化 CI/CD 工作流程使团队能够更快地行动，同时保持监管银行环境所需的控制水平。

除了提高效率外，该平台还通过设计嵌入了治理、合规性和可追溯性。集中管理和自动审批工作流程降低了运营风险，同时支持与监管要求保持一致。

更重要的是，这种转变代表着 BBVA 内部向将机器学习视为一流工程学科的转变，并得到了支持规模、一致性和持续创新的平台功能的支持。

在本系列的第 2 部分中，我们将探讨实现这些结果的用例，以及推动进一步改进的下一组增强功能，包括将进一步提高模型可靠性以及随着采用规模的持续扩大实现更主动的生命周期管理的功能。