数据科学家在摩根大通的一天


欢迎来到 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


产业
暂无评论
暂无评论~