全面采用亚马逊云科技:利用亚马逊云转变生产运营

全面采用亚马逊云科技:利用亚马逊云转变生产运营

关键字: [Amazon Web Services re:Invent 2024, 亚马逊云科技, 生成式AI, Bedrock, Cloud Migration Journey, Generative Ai Solutions, Data Strategy Vision, Single Cloud Simplification, Production Operations Transformation]

导读

在本次会议中,了解bpx energy在亚马逊云科技上对生产运营的转型。bpx分享了其从多云简化并全面采用亚马逊云科技的历程,包括SAP和Esri ArcGIS。探索bpx如何准备其环境和数据以转变石油和天然气生产运营。

演讲精华

以下是小编为您整理的本次演讲的精华。

2024年亚马逊云科技再次发明大会上举办了一场题为“全面采用亚马逊云科技:利用亚马逊云转变生产运营”的精彩会议。会议伊始,亚马逊云科技高级解决方案架构师Lee向与会者表示热烈欢迎。为了了解观众对相关主题的熟悉程度,Lee先请与会者举手,询问有多少人来自能源行业、正在进行迁移工作或正在尝试或部署人工智能(AI)解决方案。这个互动有效地为会议设置了重点:云迁移、现代化以及在能源行业中集成生成式AI(GenAI)。

Lee介绍了本次会议的主讲人:他自己代表亚马逊云科技能源和公用事业业务部门,以及BPX能源公司首席架构师Mike Brogan。会议议程包括全面探讨云迁移和现代化的机遇、挑战和结构化方法。随后,Mike将分享BPX能源从Azure迁移到亚马逊云科技的真实经历,包括迁移关键系统如SAP和EZ/RA RJs。在会议后半段,Lee将阐述亚马逊云科技的GenAI愿景、数据策略,并深入探讨一种GenAI解决方案架构。

Lee向观众强调,促使客户迁移到亚马逊云科技的常见业务驱动因素包括数据中心退出、业务全球化以及能源行业内的并购。此外,客户还希望提高敏捷性、员工生产力,并将企业转变为数据驱动型组织,从而更深入了解客户群体。成本降低也是一个重要因素,客户在亚马逊云科技上可实现比本地解决方案节省31-35%的巨大成本。然而,Lee强调,客户期望从亚马逊云科技获得的不仅仅是成本节约,还包括提高安全性、运营恢复能力、数字化转型、企业现代化以及对可持续发展的承诺。

Lee承认,迁移存在挑战,并借鉴了亚马逊云科技与数千家客户合作的丰富经验。首先是云运营和安全性,需要定义一种安全的云运营模式。其次是项目管理和规划至关重要,因为企业无法长期停止运营仅为迁移服务。有效管理依赖关系并执行业务目标至关重要。第三,资源可用性是一个挑战,因为迁移需要既精通现有技术栈又精通云技术的人员,以及充足的财力和时间资源。

技术障碍如网络问题、版本不兼容性和系统集成也可能进一步使迁移过程复杂化。对于商业现成软件,Lee建议客户咨询供应商是否支持应用程序级别的迁移,特别是考虑将数据库迁移到Amazon关系数据库服务(RDS)时。

为了应对这些挑战,Lee倡导采用一种结构化的迁移和现代化方法,这种方法已在亚马逊云科技客户群中广泛观察到。第一阶段是评估准备情况、创建变革理由并评估团队、利益相关方和企业本身的准备程度。第二阶段是动员,通过早期成果产生动力、迭代以提高速度,并构建云运营模型,例如建立云卓越中心。

第三阶段包括大规模迁移和现代化过程。一旦着陆区域准备就绪,客户就会加速迁移工作。值得注意的是,大多数客户都会抓住机会至少进行一些程度的现代化,解决安全漏洞和服务寿命终止的问题。在此阶段,将持续优化性能、成本和运营卓越性,与亚马逊云科技架构优化框架的支柱保持一致。

Lee随后邀请观众分享他们的经历,通过举手询问他们是否至少在较高层面上遇到过类似的机遇、挑战和方法。这个互动环节有助于验证结构化方法在观众的集体经验中的共鸣。

接下来,Lee介绍了BPX能源公司首席架构师Mike Brogan,分享他们令人难以置信的迁移历程。Mike首先概述了BPX能源公司,这是BP在美国陆上的油气业务部门,主要资产集中在伯米安、鹰卡地区和海恩斯维尔盆地。BPX能源的云之旅始于2017年,当时他们开始探索亚马逊云科技的软件即服务(SaaS)产品、存储解决方案和物联网(IoT)实施。

然而,2019年标志着一个重要里程碑,当年春季BPX能源将其上游SCADA系统迁移到亚马逊云科技,秋季则将SAP实例迁移到另一家云供应商。采用双云战略主要是为了严格的安全隔离,将运营技术(OT)环境部署在亚马逊云科技上,而信息技术(IT)环境则托管在另一个云平台上。这种做法是为了缓解利益相关方对于公有云环境中的SCADA系统的安全顾虑。

在接下来的两年里,BPX能源继续将资产迁移到云平台,并将数据整合到一个单一的云数据湖中。与此同时,他们更深入地探索分析和机器学习,评估了各种解决方案,最终选择了Amazon SageMaker。有趣的是,SageMaker成为首个部署在亚马逊云科技上的企业IT资产,这一关键发展促使BPX能源重新考虑其多云战略。

正如Mike所回顾的那样,在去年的再次发明大会上,BPX能源的首席技术官(CTO) Jordy Herrell展示了他们的云之旅,当时SageMaker是唯一部署在亚马逊云科技上的企业IT资产。这一认识促使BPX能源质疑维持双云战略的必要性,他们意识到可以在单一云平台内实现环境的安全和隔离,同时消除多云方式固有的额外复杂性。

2023年,BPX能源做出战略决策,迁移到单一云平台,并启动了为期18个月的“一云”(One Cloud)计划。虽然承认最后一英里往往是最长的,但Mike表示他们已完成99%的迁移工作,只剩下一些残余。这一成就使BPX能源能够实现统一云战略的优势,并进一步利用AI和GenAI解决方案推动转型目标。

值得注意的是,BPX能源设定了到2030年将产量翻一番而不增加现金成本或人员的企业目标。Mike强调,要实现这一宏伟目标,离不开利用技术和云的能力。“一云”迁移是这一转型之旅的关键一步。

阐述“一云”计划背后的愿景时,Mike强调,虽然预计随着时间的推移成本会有所降低,但成本节约并非主要目标。相反,重点是技术简化,与BPX能源更广泛的简化之旅保持一致。这包括整合到单一上游SCADA系统、单一时序数据库、统一数据湖、单一SAP实例,并精简服务合作伙伴。简化是一个核心原则,使BPX能源能够说服领导层通过消除冗余、减少对多种技能的需求以及更加专注于实现目标来提高效率。

通过简化和提高效率,BPX能源旨在加快创新步伐并为业务交付价值。正如Mike坦率地承认的那样,一张原本用于执行摘要的幻灯片无意中出现在了演示文稿中,这凸显了保持专注于核心目标的重要性。

Mike继而概述了“一云”计划的时间线,整个过程历时18个月,尽管他们最初设定了更加激进的12个月目标。考虑到所涉及的复杂性,他们制定了一个现实的15个月计划,并在此基础上推进,最终由于途中遇到一些意料之外的挑战而延长至18个月。

与人们的直觉相反,BPX能源首先着手迁移他们最复杂和最关键的SAP实例。与此同时,他们还在为其他应用程序、服务和数据库的架构和设计工作。在采用传统的迁移方法后,他们将剩余应用程序划分为多个波次,并分批迁移。

总体而言,BPX能源迁移了91个应用程序,这个数字对某些人来说可能看起来并不多,但实际上占他们应用程序资产的三分之一,他们估计总共有大约300个应用程序。这一统计数据突出了SaaS解决方案在他们环境中的普遍性,从而减少了需要迁移的应用程序数量。此外,他们还迁移了280TB的文件共享数据。

Mike将迁移过程比作搬运一个装满物品的储物单元。出于效率的考虑,他们决定不对内容进行分类,而是整体搬运,因此需要第三方解决方案来处理大量数据传输。这个比喻突出了在有限的时间内迁移大量数据所涉及的复杂性。

除了应用程序和文件数据,BPX能源还需要迁移超过1,000个无服务器组件,这些组件存在于他们之前的云环境中。与服务在不同云平台上等价的假设相反,Mike承认情况并非总是如此,因此在迁移过程中需要进行一定程度的现代化。

现代化工作涉及多个层面,从采用基础设施即代码、部署管道和容器化等当代实践,而不是虚拟机,到确保健壮的部署遵循标准,如维护独立的非生产、预生产和生产环境。此外,他们加强了高可用性和灾难恢复配置,从而为应用程序提供了更加健壮和有弹性的平台。

BPX能源利用了他们在2019年从BHP收购资产时获得的流程和经验教训,在迁移过程中对每个应用程序进行了架构评审、变更控制委员会和安全风险评估。

在迁移的主要应用程序中,Mike着重介绍了SAP,他们首先在5个月内完成了SAP的迁移,这是一个战略性举措,他比喻为“建立势头”。借用“烧船”的概念,即全力以赴,不留后路,BPX能源决定先迁移SAP,确保一旦启动,该计划就不会有放弃的风险。

实时运营(RTIS)应用程序是另一个重大迁移,之前在他们的旧平台上存在性能问题、可扩展性限制和频繁中断。对于这个应用程序,BPX能源对基础架构进行了大规模的重新架构,以解决这些挑战。

在RTIS和另一个主要应用程序Well Connected Portal(一个由多个应用程序组成的自主开发平台)之间,BPX能源面临一个困境。虽然他们更希望将这些应用程序停用,但停用进程进展缓慢,因此不得不迁移。幸运的是,BPX能源的一名云架构师参与了迁移团队,他曾参与开发大部分Well Connected Portal应用程序,为团队提供了宝贵的见解和专业知识。

深入探讨SAP迁移的技术细节,Mike展示了一个高级网络图,承认与他们复杂的SAP实施相比,这个图过于简单,后者涉及超过100个与SCP平台的接口和集成。值得注意的是,在迁移过程中,BPX能源做出了战略决定,将与母公司BP的集成重新设计,将BP视为外部合作伙伴,而不是同一组织的一部分。

虽然SAP建议将他们的SAP实例迁移到软件即服务(SaaS)产品,但BPX能源当时认为好处不足以弥补成本,因此决定将实例保留在自己的云环境中。他们将在几年后重新评估这一决定,届时取决于SAP产品的改进情况。

强调SAP迁移的复杂性,Mike指出了数百个内部和外部集成,包括与BP的文件传输和API。对于熟悉SAP的人来说,他承认这种集成复杂性并不罕见,但在迁移过程中确实构成了重大挑战。

与预期相反,BPX能源发现迁移他们的整体SAP应用程序比迁移众多较小的应用程序更简单。一个特殊的风险领域是他们的生产会计流程,这些流程依赖于SAP系统中的定制和Crawford Plus包。确保这些定制在迁移后继续正常运行需要高度关注和努力。

虽然有人认为迁移是一个“非事件”,但Mike证实了100多名参与迁移周末的人员的付出和努力,突出了这项工作的重要性。

作为现代化努力的一部分,BPX能源将他们的SAP实例从之前云环境中的Gluster文件系统和基于虚拟机的NFS文件共享迁移到Amazon Elastic File System (EFS)。尽管在迁移过程中最初遇到挑战,并对亚马逊和亚马逊云科技关于EFS的表现提出了一些不太友好的评论,但结果证明了一切。自去年8月迁移以来,BPX能源没有遇到任何集群故障,这与之前每季度都会发生的故障形成了鲜明对比。

转向ArcGIS应用程序(在BPX能源内部称为OneMap),Mike强调了一个独特之处:它拥有一个面向互联网的界面和公共IP地址,在他们的环境中属于罕见情况。这需要特别注意安全措施,包括实施Amazon Route 53、虚拟Palo Alto防火墙和AWSWeb应用程序防火墙。

OneMap的其余架构遵循了一种更加传统的无服务器设计,Mike承认对某些与会者来说可能看起来平平无奇。然而,他强调之前将RTIS应用程序直接迁移到另一个云平台的尝试失败了,因此在迁移到亚马逊云科技时需要重新设计。

BPX能源组建了一个专门的团队,并为OneMap迁移设定了一个紧迫的最后期限,因为平台所有者即将生育,需要在新家庭成员到来之前完成迁移。

作为OneMap现代化努力的一部分,BPX能源将文件共享从Azure迁移到Amazon FSx,并将数据库从基础设施即服务(IaaS)转移到平台即服务(PaaS),具体是Amazon关系数据库服务(RDS)。Mike诙谐地回顾了他与亚马逊云科技的持续对话,呼吁更多独立软件供应商(ISV)认证其产品与RDS的兼容性,从而使BPX能源能够利用RDS,而不必在云中部署SQL Server实例。

回顾OneMap平台的优势,Mike重申了简化的总体主题,这使得安全性、高可用性、监控简化和可扩展性得到了改善。简化有助于专注利用技能、围绕单一平台和目标达成一致,最重要的是加快了创新的交付,以支持BPX能源的业务目标。

随着迁移之旅的展开,BPX能源汲取了宝贵的经验教训,Mike与观众分享了其中几点。一个关键教训是在迁移步伐和现代化程度之间寻求平衡。虽然他们抓住了现代化的机会,如采用基础设施即代码、部署管道、容器化,并加强了环境和可用性配置,但在某些情况下,过度的现代化努力可能会威胁到迁移时间表。

在Well Connected Portal的案例中,其中一些组件即将到期,BPX能源认识到完全升级实际上需要重写应用程序,这是他们在迁移时间表内无法完成的任务。找到现代化和迁移步伐之间的适当平衡至关重要。

有效的沟通和协调是另一个关键教训。Mike强调,通过多种渠道频繁沟通,包括电子邮件广播、会议、公告、内部社交媒体平台和面对面互动,这一点至关重要。尽管在高层和中层管理层举行了大量会议,旨在让利益相关方了解“一个云”计划,但Mike回忆起有些领导人表示惊讶或提出疑虑的情况,这凸显了持续和多方位沟通的重要性。

虽然常被忽视,但文档在迁移过程中证明了其价值。BPX能源承认,如果一开始就拥有全面的文档,迁移之路将会更加顺畅,并减少了实施合作伙伴的抱怨。未来,保持文档的及时更新将是一个优先事项。

预测和减轻未知依赖关系和集成的影响是一个重大挑战。尽管他们尽了最大努力进行沟通和协调,但BPX能源还是遇到了一些业务部门自行开发工具和集成而技术团队并不知情的情况。识别和解决这些未经记录的依赖关系导致了迁移推出的延迟和中断。

在一个值得注意的案例中,BPX能源遵循了所有规定的流程,与相关利益相关方进行了沟通,并停用了一个系统,但随后遭到用户的反对,原因是他们对该系统存在未经记录的依赖关系,这凸显了彻底尽职调查的重要性。

另一个经验教训是在重大迁移计划中途更换服务合作伙伴是不可取的。BPX能源公司在迁移项目期间更换了大约75%的支持和开发团队,影响了负责提供有关待迁移应用程序信息的团队和负责将已迁移应用程序过渡回运营环境的团队。更换服务合作伙伴导致迁移时间线从最初计划的15个月延长至最终的18个月。

随着“一云”迁移即将完成,BPX能源公司已将重点转移到利用亚马逊云科技上的GenAI能力来进一步推进2030年转型目标。Lee继续演示,深入探讨了亚马逊云科技的GenAI愿景和数据战略。

Lee引用了麦肯锡的一项研究,强调了GenAI的变革潜力,预计每年将为全球经济增加2.6万亿至4.4万亿美元。为了提供背景信息,他将这一数字与英国当时约3.1万亿美元的经济规模进行了比较,凸显了预期影响在全球范围内的巨大程度。

然而,随着客户开始踏上GenAI之旅,Lee承认他们常常面临几个关键问题。首先,出于安全仍然是首要任务,会产生关于数据安全和隐私的担忧。其次,客户寻求指导,了解如何快速大规模地采用,以及不同的途径来启动他们的GenAI采用并提升团队和组织的技能。第三,鉴于可用模型的丰富性,客户难以确定最适合其特定用例和需求的选择。

为了解决这些问题,Lee概述了亚马逊云科技的GenAI愿景和路线图,其核心是实现业务价值。借鉴麦肯锡研究的预测,Lee强调最终目标是捕获GenAI为全球经济带来的万亿美元价值。

路线图首先确定关键业务目标和价值,如通过提高产出、改善安全、减少非生产时间、降低成本和改善风险管理来转型生产运营。这些目标因行业和组织而异,可能包括增长、盈利能力或开发新产品和服务。

一旦确定了业务目标,下一步就是评估当前的技术和数据平台状况,必要时简化复杂性并构建能力来解决差距。这一评估将为制定人工智能和数据战略提供信息,并配合努力提升员工技能和弥补任何存在的技能差距。

建立健全的治理、安全和风险管理框架是路线图的关键组成部分,确保GenAI采用遵循行业最佳实践和监管要求。

最终,组织将达到一个拐点,开始构建、获取或集成量身定制的GenAI解决方案以满足其特定需求。这一阶段涉及试点和测试解决方案、在生产环境中部署和监控它们,并持续评估其性能,根据需要进行必要的优化和扩展。

Lee认识到GenAI领域创新步伐的迅速,承认组织无法无限期地置身事外,而竞争对手继续向前推进。该路线图为采用GenAI能力提供了一种有序的方法,同时降低风险并最大化创造业务价值的潜力。

转向数据主题,Lee强调,虽然生成模型和应用程序备受关注,但它们只是冰山一角。在表面之下,存在着复杂的数据管理和治理需求。

组织将需要继续存储和管理结构化和非结构化数据,维护运营数据库以支持现有应用程序和客户体验。数据湖和分析平台在积累和分析特定于业务的数据方面发挥着关键作用,而数据集成管道则促进了数据的转换和准备,以供人工智能和生成解决方案使用。

数据治理,包括数据质量、隐私、合规性、安全性和访问控制,仍然是一个关键组成部分,确保在GenAI生命周期中对数据的完整性和负责任使用。

Lee将现代数据战略作为实现更好的GenAI模型和体验的基础。通过利用可扩展的数据湖和专门构建的数据服务,组织可以开发高度与其特定业务领域相关的GenAI模型。这些改进的模型和体验反过来又会带来更好的产品和服务,吸引更多用户,推动更高的采用率和参与度。这种良性循环产生更多数据,可以反馈到可扩展的数据湖中,进一步完善和增强GenAI模型。

认识到客户加快GenAI采用的迫切需求,Lee概述了几种与亚马逊云科技合作创新的途径。一种方法是与专门从事特定行业、技术栈或企业工作流程的亚马逊云科技解决方案架构师(SA)合作。这些SA与客户合作进行代码设计会议,并交付量身定制的解决方案以满足其独特的用例和需求。

值得注意的是,在最新的Gartner Magic Quadrant报告中,亚马逊云科技连续第14年被评为战略云平台服务领导者。Gartner特别强调亚马逊云科技解决方案支持是一个关键的区别优势,凸显了与亚马逊云科技 SA密切合作推动创新的价值。

另一种创新途径是生成AI创新症候群,亚马逊云科技团队与客户合作加速最小可行产品(MVP)的范围界定、快速概念验证(POC)原型设计,并制定生产部署路线图。这些参与往往涉及与亚马逊云科技专业服务团队在交付过程中的合作。

第三种方法利用亚马逊创新方法论,亚马逊云科技的数字创新团队与客户合作使用“反向工作”机制。这涉及撰写新闻稿、常见问题解答、用户故事和开发视觉效果,以构思和完善产品理念。

在与BPX能源公司的合作中,亚马逊云科技和BPX团队共同开发了一种GenAI解决方案架构,以支持与数据的对话式用户体验。该架构从最终用户开始,无论是办公室员工还是现场运营团队,他们通过提出问题与应用程序进行交互。

第一个解决方案组件称为问题重写器,它接收用户的请求以及对话上下文和历史记录,并使用附加的上下文信息重写问题。重写后的问题被发送到路由器组件,路由器确定它是Python生成用例还是单一生成用例。

对于Python生成用例,路由器将请求发送到Python生成器,Python生成器执行Python代码并生成所需的输出,如图形或可视化效果。或者,对于单一生成用例,路由器将请求发送到单一生成器,单一生成器生成并执行相应的SQL查询,从云数据库中检索表格数据。

最后,检索到的数据和自然语言上下文由数据到文本组件综合,生成对用户原始问题的自然语言响应,包含表格数据和上下文信息。

Lee随后更详细地介绍了应用程序架构,从右上角的文档处理管道开始。包含生产运营手册和程序的PDF文件等文档存储在Amazon Simple Storage Service (S3)中。使用Amazon Textract从这些文档中提取信息,包括表单、表格和图像,然后将其转换为向量并存储在Amazon OpenSearch Service中。此过程利用了Amazon Bedrock嵌入模型,在用户与应用程序交互之前为应用程序准备了相关数据。

该应用程序遵循无服务器架构设计,最终用户与前端应用程序交互,该应用程序将请求发送到Amazon API Gateway。API Gateway由Amazon Lambda函数支持,Lambda函数通过利用Amazon Simple Queue Service (SQS)和Amazon DynamoDB来处理并发用户请求的排队和存储。

对于单一生成用例,Lambda函数调用Bedrock生成SQL查询,该查询针对运行在亚马逊云科技上的各种运营数据库(包括但不限于Amazon Relational Database Service (RDS))执行。检索到的关系数据被传回Lambda函数,Lambda函数再次调用Bedrock,将表格数据和自然语言上下文综合为文本响应,发送给最终用户。

在模型选择方面,Lee承认基础模型和大型语言模型的创新步伐很快,新模型频繁推出。他强调没有“一统天下”的模型,客户从中获益的是拥有选择权,能够根据准确性、延迟和成本要求的平衡来选择模型。

在与BPX Energy合作的过程中,亚马逊云科技和BPX团队使用不同的模型和各种提示工程技术构建了多个人工智能解决方案组件。他们在选择模型时,着重于在准确性、延迟和成本之间取得适当的平衡,并在会议期间以表格形式总结了所选择的解决方案组件、提示工程技术和模型。

总的来说,本次会议涵盖了亚马逊云科技有关云迁移和现代化的结构化方法,以BPX Energy实现“一云”迁移至亚马逊云科技的真实案例为例。随后,会议转向亚马逊云科技的通用人工智能愿景、数据策略建议,以及与BPX Energy共同开发的用于改造生产运营的通用人工智能解决方案架构。演讲者分享了成功采用通用人工智能能力的见解、经验教训和创新途径,强调了这项技术在各行业的变革潜力。

下面是一些演讲现场的精彩瞬间:

成千上万的无服务器组件迁移和应用程序现代化,采用基础设施即代码、部署管道和容器化,从而构建了一个更加健壮的平台。

全面采用亚马逊云科技:利用亚马逊云转变生产运营_第1张图片

亚马逊的首席技术官将将SAP迁移到云端比作“焚舰”以建立势头,防止回头。

全面采用亚马逊云科技:利用亚马逊云转变生产运营_第2张图片

该公司成功将其整体应用程序和定制的SAP系统迁移到亚马逊云科技,这要归功于参与迁移过程的团队的辛勤工作和奉献精神。

全面采用亚马逊云科技:利用亚马逊云转变生产运营_第3张图片

演讲者警告了业务中未知或未记录的工具和集成所带来的风险,强调了有效沟通和集中式知识管理的重要性。

全面采用亚马逊云科技:利用亚马逊云转变生产运营_第4张图片

亚马逊云科技解决方案架构师与客户合作,设计量身定制的创新解决方案,以满足其特定的用例和需求,利用亚马逊云科技业界领先的云平台和专业知识。

全面采用亚马逊云科技:利用亚马逊云转变生产运营_第5张图片

亚马逊云科技和BPX能源合作撰写了一篇联合博客、演示文稿和展示之旅,重点介绍了他们成功的用例实施和AI/数据科学集成。

全面采用亚马逊云科技:利用亚马逊云转变生产运营_第6张图片

总结

这次演讲围绕着BPX能源迁移到亚马逊云科技单一云平台的转型之旅展开,简化了他们的多云状态,并拥抱生成式人工智能来推动创新和运营卓越。BPX能源的首席架构师Mike Brogan分享了他们的“一云”计划,强调了简化、提高效率和加速创新交付的好处。

迁移涉及将91个应用程序(包括SAP和RTIS等关键系统)从多个云合并到亚马逊云科技上。这种简化使技能能够集中利用,围绕单一平台保持一致,并能够更快地交付创新,以满足BPX在2030年将产量翻倍而不增加成本或人员的目标。

亚马逊云科技解决方案架构高级经理Lee随后讨论了生成式人工智能愿景和数据策略。他强调数据是差异化因素,可扩展的数据湖和专门构建的数据服务能够支持更好的人工智能模型和体验。Lee还展示了在亚马逊云科技上创新的方式,例如与亚马逊云科技解决方案架构师、生成式人工智能创新联合会和亚马逊创新方法论合作。

演讲最后深入探讨了一种生成式人工智能解决方案架构,利用了Amazon S3、Textract、OpenSearch Service、API Gateway、Lambda、SQS和DynamoDB等亚马逊云科技服务。Lee强调了模型选择的重要性,平衡准确性、延迟和成本,并提供了进一步学习的资源。

亚马逊云科技(Amazon Web Services)是全球云计算的开创者和引领者。提供200多类广泛而深入的云服务,服务全球245个国家和地区的数百万客户。做为全球生成式AI前行者,亚马逊云科技正在携手广泛的客户和合作伙伴,缔造可见的商业价值 – 汇集全球40余款大模型,亚马逊云科技为10万家全球企业提供AI及机器学习服务,守护3/4中国企业出海。

你可能感兴趣的:(AWS)