机器之心编译

编辑：大路

技术分享——数据科学家在摩根大通的一天

欢迎来到 AIM319 会议：数据科学家在摩根大通的一天。

今天，我们要讲的是人工智能和机器学习，以及亚马逊 SageMaker 等产品如何改变数据科学家的工作方式。

我的名字是 Tom Lococo，AWS 的首席技术客户经理、JPMC 账户团队的成员。在过去的五年里，我一直在 AWS 平台上工作，主要是帮助金融服务领域的工作人员，实施云技术去更好地服务客户。

我很荣幸今天能和 Daryush Laqab 一起演讲，他是 JPMC（摩根大通）的 AI/ML 产品负责人。此外，我还想送上对两位 AWS 架构师的赞誉，Hannuel Joshua 和 Ken Jackson。

我们今天要在这里介绍的是我在 AWS 的工作中最激动人心的部分之一，运用 AI/ML 帮助客户解决复杂的集成挑战——在完全安全的环境中实施 SageMaker。这个任务之所以复杂，是因为从根本上讲，数据科学家的角色是关于访问和分析许多不同的数据集，并且他们还需要与许多不同的人合作，而这些需求有时又会发生冲突。

从数据治理的角度来看，我们需要能够跟踪「谁使用和改变这些数据集的每一个数据」。而从 AI/ML 的角度来看，我们还需要跟踪使用每一个被应用到模型的数据「血统」。

而获得解决方案以部署 JPMC，需要我们解决下图所示的每一个需求：

首先，我们需要从内部的 HDFS 文件系统与源数据集中获取数据；其次，所有数据流需要配置为完全私有，这意味着他们需要在没有接入互联网或公共服务设施的地方，去穿越私人链接；第三，所有传输中和静止中的数据都需要加密，以满足高度机密工作负载的要求；第四，JPMC 的云用户，包括数据科学家，通常提供和管理服务区以通过服务目录接口，这意味着他们已经降低了可视性到底层云服务的配置和操作；最后，集中监控的要求和日志会影响我们调试的方式，并对 Ai/ML 工作负载进行故障排除。

我们打算在今天的会议结束前，向您展示如何在一个完全兼容的环境中实现 SageMaker。

所以，废话不多说，让我把话筒交给 Daryush。这样他就可以告诉你关于人工智能平台上的 JPMC，以及如何解决我们目前所介绍的每一个要求。

我的名字是 Daryush，产品管理负责人，负责摩根大通在 AI 上的全公司 AI/ML 平台。今天我们在这里为大家讲述 OmniAI 的故事，以及它如何能真正帮助我们摩根大通的数据科学家的生活。

在此，我想先告诉你一些关于我们的业务和业务规模的一些情况，然后我们将触及一些高层次的 AI/ML 用例。再然后，我将谈一下为什么数据科学家可以帮助摩根大通。之后，我们将讨论数据科学家面临的一些挑战。当然我们也会有一个 OmniAI 的演示，和经验教训，以及我们下一步的计划。

摩根大通是一家全方位的金融服务机构，先给大家提供几个数据点，让大家感受一下我们的规模。总体而言，我们有大约 27 万亿美元的资产托管，包括 5200 万活跃的数字用户，我们每天会处理价值约 6 万亿美元的支付。

这样的规模当然需要一个非常庞大的技术组织，我们公司有 5 万多名技术和软件工程师，开发了 6000 多个应用，这包括内部应用和外部应用程序。我们还会定期处理超过 450PB 的数据——这就是我们业务工作的规模水平！

而在这个规模层面上，我们很难不去靠数字去经营。所以，这就有了成千上万的量化分析师、ML 工程师和数据科学家。现在这些 ML 工程师和数据科学家正在处理各种不同的需求和情况。

我们与美国 50% 以上的家庭有一定的金融关系，这就使改善客户体验变得极其重要。我们致力于在与客户的每一个接触点，利用数据去增加我们对客户的了解，但同时又不损害客户的隐私和敏感数据。

所以我们的重点就是使用 AI/ML 给客户提高客户体验，包括我们的机构投资者客户。对此，我们创建了很多问答（FAQ）机器人和聊天机器人。

我们使用了许多高级 NLP 模型来训练这些机器人，比如使用 Elasticsearch 对我们的内容进行大量的搜索，从我们的知识库里找到问题的答案。

当然，我们在每一个市场都有参与，包括股票市场、股市。所以，在这些股市中寻找规律，并为我们自己和我们的客户找到更好的交易时机，也是公司大量使用 AI/ML 的另一个领域。

同样，在我们的组织中，我们每天收到了相当多的电子邮件：从我们的机构投资者，私募股权投资者和其他客户。所以我们还使用了不少 AI/ML 来处理这些邮件，管理这些邮件，进行排队分类，然后把它们送到正确的地方。

现在，回到摩根大通的数据科学家的生活。正如我提到的，AI/ML 可以被改进，变得更加平滑。但在摩根大通的数据科学研究中也有一些障碍。

我将在这张幻灯片上强调几个。

首先是数据访问。

我们的数据科学家一直面临这个严峻的挑战，这其中也包括存储敏感数据、处理敏感数据和数据主权问题。像你们大多数企业界的人一样，我们也面临着「数据使用」的问题，特别是授权问题。因此，我们会先进入一个程序来记录使用历史，并确保该数据集的使用得到授权。

其次，我们是一个大型组织，有很多历史遗留的「基础设施」，这些是随着时间的推移而建立起来的，也是一直在缝缝补补的，而这些又都是紧密结合的。

因此，将部分或全部基础设施转移到公共云上，用基于 AI/ML 的引擎取代规则基础引擎，是发展的必然，但又需要大量的时间，这些历史遗留问题也在阻碍创新。

第三，我们是一个大型的组织，有很多业务线，而这些业务线也都是受监管的实体。它们需要在不同的监管环境中发挥作用。所以，为了确保这些监管义务被考虑到，数据科学研究的进度也会变慢，这也是大多数行业都没有面临的挑战。

最后一点，是我们的监管和合规义务。我们极其认真地对待这些义务。前边，我已经简要地谈到了数据治理义务：确保只对需要访问某项数据的人开放该数据的访问权，并确保他们出于正确的目的获得该数据的访问权，但这还不是全部。

我们其实还有模型治理的义务，任何一个模型，都是经过训练核查的。我们不会直接允许模型进入生产环境。任何模型都需要经过模型审查和模型治理过程：该模型是如何创建的，该模型是如何发展的，以及是否对这些模型进行了充分的实验？这个模型到底有没有产生这些预期的结果？

然后我们还有软件治理问题，我们的这些模式都是在生产环境中运行的，而软件开发人员却无法直接访问生产环境，所以我们需要确保一个刚刚训练好的模型能在生产环境中运行。

总结一下这些问题，就是「职责分离」。数据科学家和 ML 专业人员在构建、并在较低的开发环境中训练一个模型。他们不能仅仅将模型推到生产环境中，还需要经过一个模型治理过程。而当模型真正在生产环境中运行时，他们又无法进行访问和调试，因为那里还涉及到数据的敏感程度。所以我们确实需要一个 ML 工程师去维护该环境。

数据操作和数据移动也是如此。

大约两年前，我们开始了一个新研究，来构建全公司的 AI/ML 平台和摩根大通的生态系统，我们称之为 OmniAI。

我们与 AWS 和 SageMaker 团队合作来一起构建这个 SageMaker 和 AWS 上的机器学习和 AI 平台。这个平台展现了不少蓝图模式和参考架构，可以用来做 AI/ML。

它们有不同的模型训练模式，特别是在模型推理和模型托管方面。我们也有数据标签的模式和模式的实验。

而鉴于这次只有 30 分钟的时间，要把所有的这些图案都讲出来有点难，所以我们就选择一个模式来一起演练一下。

这个模式是关于一个数据科学家做交互式训练的，在 Jupyter notebook 上使用 SageMaker。

那么我们就从这里开始，重点介绍几个方面。

首先，你看我们的平台部署情况，这实际上是一个混合部署，部分部署运行在我们的数据中心、内部环境和私有云中，而另一部分则运行在 AWS 和公有云上。

数据科学家首先开始在 AI 平台上，使用我们的控制平面，在 prem 上运行，这就是我们识别数据科学家身份的地方。

我们会对他进行认证，然后使用我们的 on-prem ADFS 目录对它们进行授权。再之后，我们就能准确地知道这个数据科学家有权访问哪些数据集。

而且我们可以正确管理和设置这个环境，不少的「风险管理治理」和「合规性控制」也是在这个阶段应用的。

现在来到 AWS 方面，这里我们描绘的是一个角色，去致力于训练、创建模型的结构、模型优化和实验。

而就在旁边，它有三个字母，上面写着 HCD（highly confidential data），意思是高度机密的数据。这些都是非常敏感的数据，我们现在来谈谈这个话题。

在中间，你看到我们有一个实例在运行，这是一个 Jupyter 上的实例，我们使用了我们的 CI/CD 流水线，用于将 Jupyter Notebook 部署到这个实例中。

在上边蓝图的中心，由它的 VPC 固定，同时你也会看到，我们在角落里有我们的 S3 buckets。

现在，S3 允许我们确保数据在静止时是加密的。事实上，我们非常依赖这项服务，通过充分地利用它，我们可以自己管理这些密钥。

但对于我们非常非常敏感的数据，我们还增加了一个额外的安全层，并在此基础上进行加密。我们在摩根大通建立了一个密钥管理服务，在这些由云 HSM 支持的账户之间运行。

因此，所有这些部分一起工作，可以绝对确保数据安全。

当然，我们会产生不少的日志和数据点，所以我们使用了 Kinesis、Firehose 和 CloudWatch 来捕获所有这些日志。此外，我们还有一个日志转发服务，能将这些日志的一部分转移到我们的私有云日志服务。

让我们看一个实际工作的演示吧，看看这个蓝图在实际中是如何工作的。在这个演示中，我们将使用 OmniAI 来训练一个非常简单的模型，当然也会使用到 SageMaker。

我们再来回顾一下架构图，和在这个演示中需要注意的几个问题。

首先，我们要使用 FDIC 的数据集。

特别是，FDIC 对每家银行的存款汇总，这是 2017 年和 2018 年的数据。它是一个略微增强的数据集，因为它还有一个标志，可以表示该银行是否在 2019 年及以后的某个时间倒闭。

我们在这个数据集中大概有 17.8 万行，目标是训练一个预测模型，可以去查看进入银行的存款。然后给我们一个该银行的概率——在未来 12 个月或更长时间内是否会倒闭。

所以在这个演示中要注意的事情，是 OmniAI 环境如何创造一个安全、合规的，但对于数据科学家来说，却易于使用的环境去进行他们的机器学习和训练。

而 OmniAI SDK 又将如何帮助数据科学家们，去只关注机器学习方面的问题，而不用担心基础设施方面的难题。

好了，我们开始吧。正如我刚刚所提到的，这个演示我将扮演一个数据科学家。

现在，我已经通过 OmniAI 系统。也已经创建了一个 Jupyter 的实例。事实上，我现在就在那个 Jupyter 实例上，而这个 Jupyter 实例是一个美国东部的 T3X 大型实例。

现在，作为一名数据科学家，我想确保我是在一个安全、合规的环境下工作。在此我是完全依靠平台提供商以确保安全和合规性到位的。

因此，作为平台提供商，OmniAI 需要关于该环境的结构，和该环境的不同部分如何相互交流的，这也包括在该环境中安装了哪些包。

这里要实际强调的这两行。

数据科学家基本上是说：「嘿，OmniAI SDK，告诉我我需要使用哪些 bucket，同时告诉我需要添加的 KMS 键有哪些。」

因此，我不需要真正担心太漫长的 path 或者 KMS 的密钥会是什么。

再来看看我们的架构图中 bucket 的设置方式：

我们在设置加密解密密钥的方式。这些都是我们蓝图的一部分，也是模式的一部分。在默认情况下，我们依靠的是 S3 服务自带的静止时加密。

但对于我们非常非常敏感的数据，我们使用 JPMC 的钥匙管理服务以增加安全和加密的层级，而这也是在 S3 内置服务的基础上。

这也是 OmniAI SDK 让数据科学家们为什么能够从平台获得这些信息，而不需要担心安全问题。

现在，让我们来看看我们的数据集。正如我之前提到的，这是一个公共数据集——FDIC 数据集。

它这里有一列表格去识别银行是否已经失败了。

这里约有 17.8 万行。

你还可以看到，除失败和未失败外，我们还有 54 个其他栏，为该银行提供其他数据点。

比如：如该银行的资产数额，或该银行的存款总数，该银行的存款总额，以及该银行的位置。

所有最终有用的元数据，都被用于创建一个预测模型。

再来说说 OmniAI SDK。OmniAI SDK 是建立在 SageMaker 的 Python SDK 之上的。这意味着，数据科学家可以直接导入 SageMaker，SageMaker SDK 的所有功能。

SageMaker SDK 的所有功能是以其原始形式提供给数据科学家。

再次注意，这个环境也是一个安全、合规的环境。因此，数据科学家可以只使用原生的 SageMaker APIs 来完成他们的工作。他们可以自己进行一些设置和修改。如果他们愿意的话，他们也可以仅依靠 OmniAI SDK 来为他们处理所有这些设置。

此外，有一个功能让数据科学家们的工作变得超级简单，而不用花心思去调整这些设置和配置——使用这个方程 get_py_sdk。

我们实际来看一下这部分代码。

这里，我作为一个数据科学家，只是在设计训练工作的参数，而我即将向 SageMaker 提交这些参数。

我正在告诉它，切入点在哪里？其实，切入点就在这里。我使用的是 SageMaker 内置 Scikit-learn 的 SKLearn，并且我使用的是其中的一个线性模型。

更具体的说是逻辑回归。这就是我的切入点。

而我想在一个 m5 大型实例上运行这个训练。从 SageMaker 中，我可以选择任何我想要的实例。从这里开始，我使用的是 Scikit Learn，所以我不能使用分布式训练。

如果我使用的是，比方说 TensorFlow，我可以创建一个由 10 个或 100 个节点组成的集群或大群。但在这里，是不可以的。

实际上，我是使用内置和本地参数，去告诉 SageMaker 的 API。

我作为一个数据科学家，只关注这些。而 OmniAI 和 SDK 会得到所有这些参数，会自动丰富它们，并为其添加其他配置。然后，会将该作业提交给 SageMaker，并运行该服务。

事实上，我们的 OmniAI SDK 的验收标准之一，是允许一个数据科学家。可以去任何一个开源的 SageMaker 教程，将该代码复制并粘贴到 OmniAI 中，然后做非常小的修改，比如添加一行代码，再点击 「运行」，整个项目就会运行。

我们的目的就是想让它变得那么简单，那么直接。

现在，关于 OmniAI SDK 的一些事情。我们已经谈过了 KMS 密钥，也已经谈过了其中的一些安全问题，比如自动设置的安全组或自动配置的作用。当然还有一些项目，如子网，以及 VPC 和网络是如何进行，以及不同组件之间的通信都有涉及。

其实，数据科学家最不需要担心的是子网和 VPC 以及网络的事情。

作为一个数据科学家，我只想专注于数学的研究和 ML 方面的难题，而 OmniAI SDK 就可以让你做到这一点。

看，我在这里的模型训练已经结束了。

而且我现在已经创建了一个压缩包的模型。

正如我所提到的，这个研究已经进行了几年的时间。这里，我还想跟大家分享一下我们目前的一些成果。

在 2019 年底，我们使用人工智能帮助摩根大通节省了约 1.5 亿美元的开支。基本上是在更低的成本上，去完成同样的工作。而在 2020 年，我们还有幸获得了「CIO 创新 100 奖」。

一路走来，我们有很多收获，学到了一些东西。这些对我们是非常有用的，也希望它们能对你有用。

首先，从我这个演讲一开始就有谈到的——职责分离、职责分工。我们认为非常、非常有帮助的是，是数据科学家和 ML 工程师的分离。这两个角色有时会解决同一个「端到端问题」。但鉴于他们是在不同的环境中工作，要遵守不同的规定和监管预期。所以我们会从不同的角度来看这两个角色，并为每个人打造流畅的体验。

这也涉及到第二点——创新。在 SageMaker 之上，去构建一个端到端的 AI/ML 流水线应该是很直接的，因为 SageMaker 把你 95-99% 的中心都放在那里了。

这里的创新是围绕管理风险。我所说的管理风险，不是指管理业务的风险，而是管理数据科学家和 ML 工程师的风险。特别是，设计代码和规划可以消除这种风险，起码降低这种风险。这可能不是最酷的软件开发方式，但这对建立一个安全的环境是相当有帮助的。

同时，这也涉及了我们今天要说的第三点。我们是做金融服务的，这是一个高度监管的行业。在某些时候，我们还需要添加自己的定制，以确保端到端平台适合具体的需求和工作流程。与此同时，这也能降低了「特有环境」所带来的风险。当然，SageMaker 和 AWS 会给你不少这样的构件，但它们有可能无法带你走完所有的路。所以你需要创建那些定制化的东西。

而当你在构建这些定制化的时候，你会看到一些「反击」，这也是我想说的第四项。

你会看到一些惰性。比如「好吧，这在我的 on-prem 环境没有崩溃，我为什么要改变它？我为什么要修复已经能运行的东西？」

其实，正是在这些时候，我们可以发现「被量化、被衡量」的重要性，用数字去显示实际价值。数字和数据对改善观点也有很大的帮助。

此外对于角落案例，一定要记住 80-20 法则，这对我们很有效。不要专注于解决一切的角落案例，这会增加很多额外的定制化需求。

最后一个是拥抱生态系统。我们说的生态系统是指，大家都可以到这个平台上来，并能为该平台做出贡献。

你们不仅能贡献数据集、代码、蓝图和参考架构，还可以真正来到我们的平台，在我们的构件上建立新的服务。

这不仅仅能让我们的工作量减少一点，还有助于建立对该平台的兴趣。

在下一步的工作上，我们会继续使用 SageMaker 和 SageMaker Studio 服务。

同时，我们很幸运地与 SageMaker 团队合作创建了一些新服务，我们也将继续坚持类似的创新。在这一过程中，我们也将继续把工作负载从我们的传统环境转移到 SageMaker 和 OmniAI 上。

视频链接：https://www.youtube.com/watch?v=ixsSHaQG38k&feature=emb_logo