关键字: [ 亚马逊云科技中国峰会2024, Amazon Bedrock Agent, 生成式Ai 应用程序开发, 亚马逊Bedrock Agent, 多步骤任务编排, 企业数据安全访问, 思维链踪迹展示]
本文字数: 8200, 阅读完需: 41 分钟
导读
在亚马逊云科技中国峰会2024 上, 王苏茵和金蝶的方守宇分享了如何使用AmazonBedrockAgent 简化生成式AI 应用程序的开发。他们介绍了AmazonBedrockAgent 的主要构成、编排和安全性, 以及金蝶如何在一周内完成了两个场景的PoC 验证, 三个月后就实现了产品的落地和上线。他们解释了AmazonBedrockAgent 如何通过自然语言与大语言模型交互, 自动分解和编排任务, 并动态调用API 来完成目标。他们还分享了在开发过程中面临的挑战, 如准确理解用户意图、捕捉上下文、确保可信AI 以及优化响应时间, 以及与亚马逊技术团队合作解决这些挑战的方法。
演讲精华
以下是小编为您整理的本次演讲的精华，共7900 字，阅读时间大约是40 分钟。
大家好, 我是王苏茵, 来自亚马逊云科技的美国旧金山办公室。非常高兴这次有机会能够回来和各位在座的同行一起交流。那今天我将和来自金蝶的智能财务应用部经理方守宇和大家一起探讨这个如何使用 Amazon Bedrock Agent 来简化生成式 AI 的应用程序开发的这个话题。
好, 今天议程我就是首先给大家介绍一下 Amazon Bedrock Agent, 包括它的主要构成、编排以及它的安全性。然后我们会请方经理来跟我们分享一下金蝶是如何在使用 Amazon Bedrock Agent 在一周之内完成了这个 POC, 并且在之后的3 个月就实现了产品的落地和上线。
在我开始之前, 我想做一个小调查, 问一下大家, 现在我想询问在座的各位, 有多少是已经在从事这个生成式AI 应用的开发或者是计划马上要这样做的, 请举一下手好吗? 看来就是这个大家已经有一些这个准备要在做或者马上要做的这个问题, 所以我接下来谈到的这些难题或者挑战, 可能是大家已经遇到或者是马上就要遇到的一些问题。
首先, 这个生成式AI 这个领域是一个发展非常迅速的领域, 我们以前可能是以年或者半年为单位来做这个技术迭代, 但是现在我们可能我们说每个月甚至每周都有新的技术在出现, 所以说对于开发者来说, 这个要求和这个学习曲线是非常陡峭的, 所以说这个我们急需有一些效率提升的工具来帮助大家完成这个生成式AI 应用的开发。
那其次我相信大家可能对这个和大源模型都有一些交互了, 大家使用这个过程当中可能也发现在这个大源模型是很强大, 但是它并不能就是自行地去采取一些操作, 这个是需要我们给它非常细致的提示, 可能才能达到我们想要的效果。
另外从这个产品就是应用开发的这个过程的角度来讲, 一方面就是 agent 这种智能型的智慧体, 它的开发过程是一个非常复杂的工程, 可能中间涉及到各种这个参数的调整, 流程的编排, 包括这个业务流程的设计, 可能以前我们的开发的范式都是好, 我们把这个所有的流程清晰地定义下来, 然后再去执行, 但是这个过程也是一个非常耗时的, 而且加上我们可能需要和多种的这个语言接口进行对接, 同时数据库和这个系统的集成也需要可能花费大量的时间和精力。
那面临这些问题,Amazon Bedrock Agent 它存在的目标就是使希望使得这个生成式AI 应用程序能够使用自然语言去执行多步骤的这个业务和任务。这里面的主要功能就是首先包括使用这个大语言模型, 用自然语言对我们的这个模型和这个 agent 去进行提示, 而且这个背后的这个运行就是由 Bedrock Agent, 它自动地去为大家分解和编排这个要执行的任务, 并且通过动态调用的调用API 的形式来完成我们希望它达成的目标。
与此同时, 非常重要的一点是这个安全和私密性, 因为我们涉及到可能非常多这个客户的数据或者公司内部的数据, 那我们会保证这个公司的数据是被安全而且私密地访问的。另外一个我听到很多客户的反馈, 大家都说这个功能非常的重要, 就是能够显示这个思维链的踪迹, 那这个踪迹就是说我们每一步这个任务是如何拆解的, 如何达到最终我们想要的这个结果的, 这个流程是清晰可见的。所以这个对于不仅是有一些行业有一些特殊要求, 比如说金融行业, 可能我们对这个产品最后推出的这个逻辑的这个清晰度, 是大家要了解得非常清楚, 可能客户才会相信你的最终结果对这个行业也是非常重要的。对于我们普通就是开发者来说, 其实有这么一个踪迹的追踪的过程, 大家也能更清楚地了解, 对于这个开发和调试的过程也是很有帮助的, 所以这个就是它的功能。
那总结一下它的优势在就是 Amazon Bedrock Agent 可以自动地编排多步骤的任务, 而且可以简化这个 AI 助手的构建和部署的过程。另外我们提供对于企业数据和 API 的安全访问, 也给大家非常大的自由度去选择这个编程的语言。这些的目标都是为了希望大家能够专注于把这个开发的精力和时间主要花在能够就是提供你们产品的核心价值的这个上面, 而不是花在可能花很多的时间在基础设施的建设上, 这个也是为什么我们提供了是一个完全托管的基础设施服务。
好, 那我接下来讲一下这个 Bedrock Agent 它的构成。我们构建一个智能体, 最终我们的终端用户是通过自然语言和这个我们构建的智能体这个 agent 去进行交互的。那我可能就会告诉这个 agent 说请你帮我做一件什么事情, 那 agent 呢就会说好, 我已经做完了, 那我的结果是什么啊? 那这个智能体内部一主要有四个构成部分, 第一就是这个说明, 或者我们叫 instructions, 就是我们为我们要告诉这个智能体, 你的目标是什么, 你的角色是什么, 你要帮助我完成什么样的任务。然后第二部分就是操作, 或者我们叫 action 和 action groups, 就是说你这个 agent 可以采取一些什么样的行动来实现我的目标。知识库就是我们有一些知识背景需要提供给这个 agent, 让他知道我在, 我是在这样一个知识背景下去完成这个任务的。一般可能是我们公司内部的一些数据或者是资料等等, 当然也可以是外部的。最后就是 Amazon Bedrock 里面的大语言模型, 目前 CloudIneu 3 已经是 Sonny 和 High 库两个模型都是在上面, 已经是提供这个服务的支持了, 那我们还继续兼容那个 CloudIneu 2.1 和 v2 以及 Instruct 这些模型都是可以使用的。另外我知道我们还就是最新加入了 Amazon Titan Text Model, 我们会不断地会提供更多的模型, 在就是支持 agent 的这个构成。
那我们稍微深入地讲一下这个 action group 或者操作里面都有哪些内容。这个就是主要包括三个关键的要素。第一就是 action group 的描述, 这个描述就是说我们用自然语言去帮助这个智能体了解我们这个操作组适用哪些情况, 就是告诉这个智能体好, 你现在要做这个 group, 要做这些事情。然后我们需要去定义这个 API 的架构。那 API 的架构主要就是说我们要详细地去定义好每一个操作它具体是什么内容, 我们可以理解为传统的, 就是当我们开发的时候做的函数, 就是我操作的名称, 输入的函数, 输入的参数, 数据的类型, 以及响应的要求, 并且我们要提示它在什么时候使用, 如何调用, 以及如何使用这个函数产生的结果。那这个是我们定义好这个 agent 它可以做什么样的行动。那最后一部分 lambda 函数, 它是一个支持说我们运行这个操作, 然后得出结论的这一个计算的服务。那 lambda 是一个我们叫无服务器或者 serverless 的一个计算服务, 它可以它是可扩展性非常强, 而且安全性也非常高的。那我们通过这三个主要组成部分是由就是开发者, 他可以就是直接深度参与控制的, 那么剩下的那些工作其实都由 Amazon Bedrock Agent 可以替他家做完很多这样其他自动化的流程。
那我想给大家讲一个更具体一点的例子, 让大家看一下这个我们的操作和知识库是可以怎么样结合起来实现一些我们行动上的目标。比如说我们今天想构建一个这个 HR 的政策助手, 那我们要求它是一个 HR 智能体, 可以负责帮助员工了解这个 HR 政策以及管理休假的时间。那我们首先可能就需要一个这个 HR 知识库对吧? 这里面要涵盖就是诶这个公司内部所有的假期的政策。然后我们要定义一个这个 HR 操作, 那这个操作就是说我可以批准员工要请假的这个要求, 那我可能要求一些什么样的这个输入信息, 你可以告诉我你的开始和截止日期, 那我的输出就是我的审批状态, 以及我你剩余的这个假期天数。那作为一个用户, 也就是我们的员工, 他可以来问这个问题, 说好, 那我今年能休多长时间的假? 那这个我们构建的 agent 就会通过查询这个知识库告诉他好, 我今年你可以休15 天假。那好, 员工可以基于这个基础上说好, 那我想在十二月八号到十五号之间去请一个假, 那这个时候 agent 就会继续调用这个 HR 的操作, 说好, 你已经给了我这个开始和结束的日期, 那我给你的反馈就是这个假期已经批准了, 同时我还可以告诉你你的假期还剩多少天。所以我们可以看到这个信息, 就是我们其实用到了前面这个对话的这个历史, 这个15 天的信息, 同时把它包括在了这个行动当中。所以说这就是一个具体的例子, 可以让他让大家看一下这个操作和知识库是如何结合的。
那这个幕后这一切的这个编排是怎么发生的呢? 好, 当一个任务被送到这个 Amazon Bedrock Agent 我们构建的这个智能体之后, 它会结合我们之前给它的提示, 就是各种 prompts, 然后还有我们的对话历史, 包括我们定义好的这个操作、知识库, 还有我们的说明, 以及这个任务, 然后通过这些把这些信息综合起来都发送给我们在 Amazon Bedrock 上面的大语言模型, 然后通过思维链这个技术, 然后 agent 就会把这些任务分解为各个子任务, 并且确定这些任务的这个执行次序。比如说我们看这有任务1 到任务 n 对吧, 它有它的顺序, 然后根据这个在每一步去调用决定。agent 会替我们去决定它要调用哪一个操作组, 或者说需要哪些知识库里面的信息, 然后这些信息会被反馈给这个 Bedrock Agent, 然后它进一步会去再次调用这个大语言模型, 把我们的这个任务的要求和刚刚我们产生的一些结果去生成一个更可读的形式, 作为一个最终反馈给我们的用户。那这就是幕后这个事情刚刚我们看到的那样, 请假成功的结果是怎么样发生的?
刚刚我们也提到了这个 agent 编排过程, 是啊, 透明可见的这些, 这个踪迹和这个提示工程都是在这个控制台和 SDK 当中会有详细的显示。这个对于就是我们刚刚提到的, 如果你要去做调试, 或者你要 debug, 或者你行业有一些具体的要求, 那有这些踪迹会很大程度上的帮助大家厘清这个过程。
那我再说一个就是提示工程, 我们看到这个有这个 agent, 这边有 Pre Processing, 还有什么 orchestration,knowledge base 和 post Processing, 这里面每一步都涉及到它自己的 prompt engineering 。那其实我们是给大家这个, 这个是就是自由度, 可以去调整每一步的这个 prompt, 然后去达到一个最终我们想要的 agent 给的一个 response 的结果, 所以这个自由度和控制力也是非常非常高的。
那最后我再谈一下这个 agent 的安全性, 所有 Bedrock Agent 里面涉及到的资源, 它都有自己的 IAM 角色, 那 IAM 是我们控制这个权限的一个 亚马逊云科技 的服务, 那我们可以给予每一个这个资源, 它独立的这个拒绝或者授予访问的权限的这么一个能力。然后另外所有的 Bedrock 的模型都是基于就是 Amazon 最高的这个模型安全的标准进行构建的, 包括所有的数据都是被加密的, 在发送过程中或者是在存储的形式下都是被加密的。然后这个另外还有一个就是 Gatekeeper 这个东西, 我们这些都是谈论的这个服务本身的安全性, 那 Gatekeeper 是另外一个我们马上要全面推出的一个功能, 就是说它可以保证你模型输出的内容也是安全的, 你可以给它添加一些就是这个过滤器, 或者是说告诉这个模型哪些内容是隐私的信息, 我们需要把它过滤掉, 这个是从这个输出内容的安全性上有一个进一步的保障。
那好, 我今天分享的内容就到这, 然后我们接下来有请金蝶的方经理来为大家分享一下金蝶是如何快速的实现这个项目的落地的。
好, 谢谢大家, 感谢王老师, 感谢各位来宾。首先非常荣幸受邀这一次来分享一下我们金蝶与亚马逊合作开发的两个真实的 agent 案例, 我也是希望能通过这一次机会, 一方面从一个研发部门的角度来真实地跟大家分享一下, 我们在开发 agent 的过程当中遇到了哪些困难, 以及这些困难是怎么解决的, 还有我们对这个 agent 的它的底层的开发平台, 开发工具有哪些需求, 真实的需求。另外也是抛砖引玉, 希望可跟大家分享一下, 就是我们金蝶对于这个深层次的 AI 技术, 对于未来的这个 ERP 产品会产生怎样的影响。
首先还是先做一个简单的介绍, 就是我们今年是已经成立了30 年的一家中国的企业管理软件厂商, 是我们行业的领导者, 从之前的 DOS 时代, 到 Windows 时代, 到互联网时代, 到云计算时代, 以及到现在的 AI 时代, 我们始终保持着行业领先, 然后拿下了多项第一的成绩。在现在的这种 AI 的时代, 我们也深刻地认识到, 大模型可能会深刻地影响到或者甚至是颠覆了我们原来的 ERP 产品和客户的业务流程。所以我们也提出了 all in AI 的口号, 希望基于原生的 AI 技术重新去重构我们的这个 ERP 的产品。
那么生成式 AI 技术究竟会怎么样去影响我们的 ERP, 或者是影响我们的业务流程? 我们认为可以从三个方面进行这个总结。那么首先像面向全员, 我们认为它会重构我们原来的用户的体验, 原来我们的 ERP 产品追求功能的强大, 但是相对应的我们的功能也会非常复杂。一个用户无论他是一个日常的用户, 还是一个专业岗位, 比如说财务或者是供应链的这种用专业用户, 他要面对几十个单据, 几十个功能入口, 或者是几十个就复杂的操作的任务工作台, 那么这种用户体验是非常非常繁琐的, 而且是学习成本相当高的。那么现在有了这个大模型以后, 我们认为已经进入了从这 GUI 进入了这个 COI 的时代, 用户他可以通过这种自然语言的交互去准确地找到我想用什么样的功能, 我想发起什么样的业务, 是面向全员的, 那么面向我们的专业岗位, 刚才还说了, 我的这种专业的财务岗位或者是人力岗位的话, 我们认为大模型它可以具备这种重构业务流程的能力, 从原来的自动化的这种效率的提升, 到现在我的大模型可以针对外部的条件, 可以做一些相对的交互, 一些交互, 一些灵活的应对, 从而去灵活的自适应去为我的用户推荐流程, 甚至是辅助我的用户、企业用户去重构我的企业流程。那么第三个面向我们的企业管理者, 我们认为大模型带来的这个改变是从原来的经验式的这种角色到现在的这种智能化的角色。大模型相对于人, 我认为它有两个不可替代的一个巨大优势, 一个是它底层的知识的体系的构建一定是远远超过于人类的, 第二个是它的数据获取和处理能力也是远远超于人类的。那么原来一个典型的场景是我的企业管理者通过我的 ERP 或通过我的线下去收集一些相关信息, 然后做出我的生产、销售或者其他的相关角色。那么现在有了大模型以后, 他可以去辅助我的人员去做出一些决策。一个比较典型的场景就是去年我们年底发布的一个场景, 原来我要做一个费用预算的预测, 这么一个预测模型。那么预测模型的建立, 那么有哪些影响因素, 或者叫特征向量, 原来是完全基于我主观经验去发掘的。那么有可能是 GDP 的成长, 或者是这个外部的这些相关政策, 或者是一些其他的影响因素, 那么现在有大模型以后, 他可以去告诉我的这个用户, 诶, 你在建模的时候, 你在建立这个预测模型的时候, 是不是还有几个因素没有考虑到, 那么是不是这些因素可以有些别的这些权重的负重, 那么从而去辅导我的这个企业决策人员去做出更好的决策。
那么重构的方向找到了, 那么下面就是重构的场景, 我们调研了我们大量的这个 ERP 的客户, 然后选择了两个比较普遍或者是痛点比较深的场景, 所有这一次基于我们这个大模型, 或者基于我们 AI agent 技术, 希望能重构的这个场景功能。第一个就是刚才所说的面向于全员用户, 我们这次希望可以做一个提单的助手, 传统的 ERP 刚刚说了, 它有一个大量的复杂的繁杂用口, 很多客户跟我们反馈, 他们的老用户, 就年纪稍微大一点的老用户, 或者是新入职的员工用户, 根本没有办法找到我企业我功能的入口, 或者我想发起个业务, 完全找不到人, 我只能去咨询我的 IT 运维人员, 或者咨询我的这个共享中心的客服人员。那么我们希望这一次基于这个 agent 的技术重构我们这么一个提单助手的功能, 帮助我的用户, 让我的用户只说出他的业务需求, 那么我帮助他去寻找或规划后续他要一步一步该怎么去完成这个业务。
那么第二个场景呢, 是面向我企业的关键用户, 也就我企业的管理者, 日常其实除了这种月度的, 季度的, 这种定期的, 这种数据分析需求, 那种需求他们可能会看一些模板化的报表, 或者 BI, 或者看板, 那么他还会有一些日常的需求, 那比如说明天我要跟一个客户去谈业务了, 诶, 临时的, 我会说诶, 财务经理, 你帮我看一下我跟这个客户之前我们的这个往来是什么样子的, 然后去年卖了他多少货, 那么这种临时性的需求, 在以往的场景下, 那只能把这个任务下到给我的人财务经理, 然后财务经理再去分配给下部下级人员, 一个一个去收集和计算数据, 然后再回馈给我的这个管理者, 那么这个流程是很长的, 而且这个成本也是很高的, 那么希这一次我们是希望基于 agent 技术去重构我们这么一个管理助手的这么一个角色, 帮助我的用户, 企业用户可以自助式地、临时性地去快速地查询到我企业的一些业财数据。
当然就是选择的这两个 agent 场景。其实我们也是面临的一些研发挑战, 首先最典型的挑战是什么呢? 是我们的这个 ERP 领域内从来没有过相关的竞品或者是其他的这种企业做过相关的 agent 应用, 那么我们是第一家, 可能是一个比较长线比较领先的一个尝试。那么这个功能该怎么开发, 或者开发落地以后它能怎么样地去服务客户, 或者是我们在研发环境里面把它事情跑通了, 那么在客户的生产环境里, 客户是否满意, 其实我们心里也是有一些犯嘀咕的。另外还有一点就是说 agent 开发其实跟原来传统的这种模板化的脚本化的功能开发是不一样的, 那么 agent 开发它会有大量的就是中间的调试, 然后还会有一些基于底层模型的调试, 那么这个这种 agent 开发的这个流程我们以前是不熟悉的, 所以这也是我们这次要面临的一重大挑战。
场也要方向定了, 场景定了, 那再下一步就是自然而然的就是 agent 开发的这个工具的选型。然后也是去年年底的时候比较凑巧, 因为亚马逊本来就是我们金蝶出海的一个云服务商的合作伙伴, 那么去年底的时候, 我们 Bedrock 产品也推出了, 然后我们亚马逊老师正好是来金蝶跟我们沟通了一下我们 Bedrock agent 相关的模块, 然后我们也是把这个 agent 的这个 Bedrock agent 模块和市面上一些开源的 agent 开发平台进行了一个内部比较。我们后来发现, 从功能成熟度来说, 可能是我们 亚马逊云科技 的这个 agent 模块, 它的前台的业务逻辑, 然后它的这些相关组件, 包括刚才说的就是 trace ID 的这种跟踪, 上下文的这种管理, 还有后台日志管理的, 它可能是确实更加的这个成熟和全面。另外也是我们基于我们跟亚马逊它的这些技术老师的一些历史合作, 我们也知道亚马逊现在企业它确实是个比较务实, 比较技术范的这么一个企业。就所以最后我们选择了 Bedrock 这个平台作为我们这个 agent 这个试点的这个底层工具。事实也证明我们这次选择是没有错的。我们经过了一个礼拜把这两个场景确实 POC 都验证通了, 然后现在经过了三个月的时间, 这两个场景功能也已上到了我们一家这个客户的真实的生产环境当中。
就下面我们通过一个视频直观地先理解一下我们做的这个产品是什么样子的。作为公司的新员工, 昨天我为部门采购了一批办公用品, 但是我既不熟悉公司的报销政策, 也不了解公司的报销系统, 我该怎么办? 很简单, 我们只需要告诉数字员工我要报销为部门购买的办公用品。我们看到数字员工首先识别了我要报销的意图, 并且拆解出了四个任务。确认了要报销的意图后, 数字员工快速解析意图, 提取出费有明细项目和金额这两个报销所需的关键信息。接下来, 数字员工则以问询的方式向我询问了报销金额是多少。在收集了相关信息以后, 数字员工快速完成了报销单据的创建, 并返回了链接。我只需要点击链接即可快速跳转报销单编辑界面, 一键提交单据, 快速完成报销。
这个其实就是我们的一个真实的产品截图, 就因为由于这家客户他的企业性质可能不适于他的这个品牌露出, 但是这个产品就是这个样子的。那么在做这一个特性的时候, 其实我们是面临了几个巨大挑战。第一个挑战就是这个场景其实业务是很复杂的, 我们经过调研这个客户, 他有17 个单据,50 多个业务类型。那么如何去准确地定义我的客户, 他到底是想发起什么样的业务类型, 然后并且帮他去补充他这个发起业务类型所需要的关键信息, 这对我们的这个功能设计以及底层的模型其实是一个比较大的挑战。
那么第二个, 其实大家肯定也之前也听说过 ERP 里面通过自然语言去发起, 因为是比如说差旅报销, 或者是一些费用报销这种场景, 但是这个功能为什么一直没有广泛推广到其他业务类型? 其实有个很大的关键点在于什么呢? 关于在于就是客户他真实的这种对话的场景其实是非常口语化的, 它不会像你原来的那种设定的模式一样, 在一句话之间把你提单所需要的所有的关键信息全部一次性地告诉你, 它一定是个口语化的, 甚至它不会提到你单据原来的名称, 它只会说它的意图。那么这种时候我们是需要通过 agent 模式去捕捉它上下文里面相关的意图, 以及相关的这些理解能力, 从而去帮助客户准确地定位到它的这个单据。
第三个, 其实也是我们之前在推广我们的这个客户的时候经常遇到的问题, 就是所有的 AI 的功能不只是大模型, 还有原来的我们机器学习算法的一些 AI 特性, 这些特性对于我们的用户来说, 它的推导过程它是其实是一个黑盒, 当如面对一些 C 端客户的时候, 其实如果他是个黑盒, 可能 C 端用户他已经接受了, 但是当对于这种 ERP 场景下, 对于面, 特别是面对我们 B 端用户, 特别是我们的财务、税务这种非常严肃的客户的时候, 如果当你的这种中间的推导过程没有展现给他的时候, 他是无法信任你的推导结果的, 如果他不没有办法信任你的推导结果, 那么他就没有办法信任你这个功能最后给出的这个结论。所以这个是一个可信任的 AI, 是我们一直要解决的一个大的问题。
那么第四个就是我们的这个客户响应时间, 大家现场的观众或者是咱们嘉宾肯定都用过 GPT, 就是你们用过不同的 GPT, 你们也知道一轮对话可能会消, 根据它的这个复杂程度, 然后你会消耗一个3-5 秒, 这是一个普通对话的消耗时间, 但是 agent 跟一般普通对话还不一样, agent 的模式之下, 你出一句对话, 它背后可能有3-5 轮甚至8 轮的推导过程, 每一轮推导过程可能都是5 秒、10 秒甚至是几十秒的时间, 那么如果把这些时间全都压缩在一起, 然后再给客户一个结果的回馈的话, 那么用户的体验是非常差的, 很多用户, 特别是一些电脑小白用户, 他会觉得你电脑就已经死机了, 你的系统就已经, 所以这个问题也是我们要解决的问题。
那么面对这一些问题, 其实我们跟亚马逊的技术老师在一起进行了一些集中的技术攻关, 我们是怎么解决的? 首先通过首先针对这个业务场景的复杂度的问题, 以及语义理解的问题, 我们通过一些分类器以及 NER 的这个提取器, 然后再结合我们 CloudIneu 3 本身, 它确实是非常优秀的这个中文语义提理解能力, 结合我们上下文, 结合上下文一起, 然后通过不断地去修改我的这个, 通过修改迭代我的这个 prompt 的优化和我们 knowledge base 相关的东西, 我们现在可以做到97% 的准确性, 可以理解到用户的意图。用户哪怕你说我, 我可以说我不想去这个, 我不直接说我要去诶, 出差或者出差申请, 我就是说诶, 明天有没有这个去深圳的机票或者怎么样, 他也可以理解到你的意图, 哎, 你可能是想发起一个差旅申请, 可能是你想要进行一个出差, 他的这个语言理解能力已经达到一个接近真人的水平了。
那么还有一个关键点刚刚说到, 就是这个可信 AI 的问题。所以这是我这次用 Bedrock 它这个非常惊喜的一个点, 在于什么呢? 他可以把这个推导的过程以这个很明确的方式展现给我的用户和展现我的研发者。当我把这个推导的过程展现给我的用户的时候, 我用户可以看到诶, 我这个结果是来源于哪一条? 我公司的规章制度, 我是怎么样得到这个推导结果的? 当我说出一需求来的时候, 我是怎么样一步一步思考的? 他能, 当他能看到这个思考过程的时候, 他就可以信任这个结果了, 就是面向我的用户来说, 那么面向我的研发的同事来说, 其实也有很大的一个关键点在于我们的这个 agent 研发过程中有个很关键的工作是什么? 就是要调整我的这个我提示与工程, 那么我提示与工程我是要看着我的 trace ID 一步一步不断去尽调去优化的, 如果我的这个推理的结果跟我一开始预想的不一样, 那么我是要能看到它是中间是哪一步推理出了问题, 那么现在有了这个 trace ID, 这个直观的展示的话确实也方便了, 大大缩短了我们的这个研发的流程。
最后还有一点就是我们这个刚才讲这个响应时间问题, 其实响应时间问题我们是通过了多个工具去解决它的。第一个就是换模型本身能力的提升, 现在换了 CloudIneu 3 以后, 它确实在地做到了一轮的这个返回, 做到了两秒到3 秒之间的这个反馈时间, 那么这个时间用户是基本上可接受的。第二个是我们跟我们的亚马逊老师, 其实对于我们之前的推导过程也做了一轮优化, 对于一些其他的这个优, 其他的这个多余的流程, 我们做了一些合并和删减。那么第三个是我们对于我们的前端的交互界面其实也是做了一些优化。像刚才说的, 如果我的后端要进行多轮的这个推导, 那么我可以在第一轮推导完成之后, 就先把一些内容展现给我的客户, 让我的客户知道, 诶, 我的 agency 实际上是在思考的, 它是在不断地解决问题的, 它没有死机, 然后也从而降低我客户的使用焦虑。
那么这是我提单助手的这个功能。那么下面简单地看一下我们这个指标查询的这么一个助手功能。数字员工通过融合 AI agent 的能力, 可以实现及时精准的指标数据查询, 重塑企业分析决策流程。在传统模式下, 由于模型固有的局限性, 意图识别易出错, 导致指标查询准确率低, 且难以处理复杂的查询需求。有了数字员工以后, 我们能够利用 AI agent 能力允许用户进行实时的补充和澄清, 并灵活运用各类工具, 确保指标查询百分百准确。
下面我们以上港集团为例, 介绍基于数字员工的指标查询助手。上港集团张总需要查询公司以往的研发费用投入情况, 来决定企业后续的研发投入计划。我们请数字员工助手帮我们查询公司2022 年研发费用投入情况。可以看到, 数字员工收到这样一个问题后, 会自主思考、规划与拆解任务, 理解用户意图, 自主学习企业的知识库, 匹配推荐相关度最高的指标, 用户可以对指标进行确认或更正。确认指标后, 数字员工会自主识别到未收集到的查询参数, 并提醒用户补充。收集完参数后, 由于用户输入的组织信息是模糊的, 数字员工可以智能推荐相关度最高的组织。并且数字员工会展示指标对应的数据查询条件以及数据表, 用户能够轻松追踪数据的来源。在确认参数无误后, 数字员工将智能的选择并运用多种数据查询工具来精确地提取所需数据, 数据不会传输给大模型, 数据安全有保障。
这个场景我相信大家之前肯定看到过, 就是自然语言技术发展以来, 都会有这种通过自然语言去查询指标的这个场景或者功能的介绍, 但是这个功能其实一直也没有铺开, 难点是什么? 其实我们认为难点核心在于两个, 一个是自然语言环境下, 客户对于数据查找的, 它的这个条件其实是非常复杂的。那比如说我想问一句, 金蝶的收入增长情况怎么样? 那么这里面金蝶到底指的是金蝶国际、金蝶中国, 还是上海金蝶、北京金蝶? 那么收入增长情况是怎么样? 它指的到底是我今年的收入情况是怎么样, 我这个第一季度收入情况还怎么样, 还是去年季、去年全年的收入情况怎么样? 其实在这个指标多, 然后这个筛选条件多的情况之下, 过去的那种命中关键词, 或者是那种基于简单的语义理解的方式, 很难准确地捕捉到用户的意图, 所以无法读出准确的答案, 这是第一个难点。
第二个难点, 这个功能其实我们的客户对于这个结果的准确需求其实非常高的, B 端用户和C 端用户的一个极大的不同点在于,B 端用户对结果的可靠性要求极高。像回到我们的功能来说, 如果这个功能它的准确性是90.9%, 这个功能对客户来说它也是不可用的, 必须是100% 的准确性给我找到我的数据, 准确的找到数据, 并且给到我这个计算结果, 那么大模型它天然的大家也知道它不擅长这个数据的计算, 或者特别是复杂逻辑的计算, 那么为了解决这个问题, 其实我们也是跟这个亚马逊的老师做了很多的这个技术攻关才解决到。
首先第一个, 那么我们怎么样准确的100% 获得用户的这个意图, 我们是通过交互的能力, 结合我们自己的这一个相关的一些前端的数据的一些整理, 数据结构的梳理, 然后再通过 agent 的这个多轮确认的这么一个工作, 然后可以保证诶我用我的用户, 虽然他讲了那这么一句话, 但是我把这个用户的意图拆解成了几个问题, 然后每个问题我分别把这个搜索的条件和结果, 我再展示给用户看, 最后让用户去确认的方式, 我可以保证我的结果一定是用户他想问的问题, 如果用户不想问, 那么他可以去改变那个搜索条件, 那么这是第一个, 在前端的意图的这个理解上面, 我保证了100% 正确。
那么第二个数据获取怎么保证百分之正确? 其实我们也是利用了 API 的能力, 前面大模型我只做这个意图的理解, 还有这个逻辑的推导。那么最后这个取数和算数的工具, 我们还是通过我们的 API 的开发, 传统工具的调用, 那么从而保证了我的数据的绝对准确性和这个隐秘性。我们是通过这个方式解决了这个场景的一些相关痛点。
那么最后简单总结一下, 就是我们在这次合作当中, 我对这个 Bedrock 的一些看法, 或者是一些我觉得它的优势。首先第一个我就认为最大的改变是什么? 就是我们的研发模式已经改变了, 原来我们的这种传统的脚本式的功能研发, 其实是我的产品设计师来写产品需求, 中间配几个产品的研发人员写前端或者后端代码, 那么最后还有测试人员。那么传统的研发, 我不知道大家的这个研发比例是怎么样的, 我们这边的比例差不多是一比三比一的这种人员分配, 但是现在有这种面向 agent 那种研发模式, 我们的产品设计师更多的就是直接会参与到我们的 agent 它这中间的这个研发, 然后这个提示与工程的调试把直接把他的思路作为了这个我就直接体现到了最后的这个产品的结果当中, 研发的比例也变成了1:1.5:1, 差不多是这么一个比例了。这可能对以后所有的产品研发可能都是一个巨大的挑战和改变。
那么第二个就是一个稳定的, 我们这个产品平台刚刚所说我们所用到的这种 trace ID 的跟踪, 上下文的管理这些功能, 其实大大缩短了我们的这个研发的流程。那么第三个就是这个运营管理的这一块, 一个成熟的功能, 它要从我们的研发的落地, 然后到给客户推广上线, 其实它不是说上线了它就是成熟了, 我们会有大量的需求, 在上线之后客户才临时反馈过来, 那么这个时候我们需要比如说我们的这日志管理进行快速的这种获取, 也要从而对我们产品进行迭代。
那么最后为我们亚马逊的小伙伴简单地做个广告, 希望大家积极参与到我们精英培训和这个相关的一些认证计划, 谢谢大家!
总的来说, 这场分享会全面介绍了Amazon Bedrock Agent 的技术细节、应用案例和开发经验。王苏茵从Bedrock Agent 的构成、编排流程、安全性等方面进行了详细阐述, 并强调了它在简化AI 助手构建、提高开发效率方面的优势。
接着, 金蝶软件的方守宇分享了他们在使用Bedrock Agent 开发两个真实案例” 提单助手” 和” 管理助手” 的过程。他们面临了语义理解、可信AI 、响应时间等多个挑战, 但通过与亚马逊的技术攻关最终将这些问题解决。方守宇认为,Bedrock Agent 改变了他们的研发模式, 产品设计师可以直接参与到提示工程的调试中, 研发效率也因此大幅提升。
此外, 方守宇还分享了他们对生成式AI 技术对ERP 产品和业务流程的影响看法。他们认为生成式AI 将重构用户体验、业务流程, 并辅助企业管理者做出决策。因此, 金蝶提出了”All in AI” 的口号, 希望基于AI 技术重新构建ERP 产品。
总的来说, 这场分享会生动展现了Bedrock Agent 在简化生成式AI 应用开发方面的实践案例, 并对其未来发展前景给予了积极评价。两位演讲者的分享为生成式AI 应用程序的开发提供了宝贵的经验和见解。
下面是一些演讲现场的精彩瞬间：
亚马逊云科技中国峰会2024 上, 亚马逊与金蝶合作探讨如何利用Amazon Barlog Agent 简化生成式AI 应用程序开发。
亚马逊云科技中国峰会2024 上, 亚马逊强调了数据安全和隐私保护的重要性, 以及AI 思维链踪迹的透明度, 以满足不同行业的需求。
亚马逊云科技中国峰会2024: 探讨亚马逊Bedrock 大语言模型及其在知识库、行动组和目标实现中的应用。
亚马逊云科技中国峰会2024: 亚马逊Bedrock Agent 通过思维链技术分解任务, 确定执行顺序, 调用操作组和知识库, 生成可读结果反馈用户。
亚马逊云科技中国峰会2024 上, 演讲者阐述了大模型如何重塑用户体验, 从繁琐的GUI 界面转向自然语言交互, 为所有用户带来简单高效的体验。
亚马逊云科技中国峰会2024 上, 演讲者阐述了大模型如何从根本上改变企业管理者的角色, 从经验式决策转向智能化决策辅助。
亚马逊云科技在前端交互界面进行了优化, 让客户能够实时看到AI 系统的思考过程, 降低使用焦虑。
总结
亚马逊云科技推出了 Amazon Bedrock Agent, 旨在简化生成式 AI 应用程序的开发。这个服务允许开发者使用自然语言指令来编排多步骤任务, 并通过动态调用 API 来实现目标。Bedrock Agent 由指令、操作、知识库和大语言模型组成, 可自动分解任务、确定执行顺序并调用相应操作组和知识库。它提供了安全的企业数据和 API 访问, 以及可见的思维链踪迹, 满足行业合规需求。此外,Bedrock Agent 还支持提示工程, 让开发者可自由调整每一步的提示以优化结果。
金蝶公司利用 Bedrock Agent 在一周内完成了两个生成式 AI 应用的 PoC 验证, 三个月后就实现了产品上线。他们面临了理解复杂业务意图、捕捉上下文、保证 AI 过程透明可信以及优化响应时间等挑战。通过与亚马逊技术团队合作, 金蝶成功应对了这些挑战, 实现了高准确度的意图理解、清晰展示推理过程、缩短响应时间等目标。Bedrock Agent 的可见思维链和提示工程功能在此过程中发挥了关键作用。
亚马逊云科技和金蝶的案例展示了 Bedrock Agent 在简化生成式 AI 应用开发、提高开发效率以及满足企业级需求方面的优势。这为企业充分利用大模型技术、重塑产品和服务奠定了基础。
2024 年 5 月 29 日，亚马逊云科技中国峰会在上海召开。峰会期间，亚马逊全球副总裁、亚马逊云科技大中华区总裁储瑞松全面阐述了亚马逊云科技如何利用在算力、模型、以及应用层面丰富的产品和服务，成为企业构建和应用生成式 AI 的首选。此外，活动还详细介绍了亚马逊云科技秉承客户至尚的原则，通过与本地合作伙伴一起支持行业客户数字化转型和创新，提供安全、稳定、可信赖的服务，以及持续深耕本地、链接全球，助力客户在中国和全球化发展的道路上取得成功 。