关键字: [Amazon Bedrock, Insurance Claim Lifecycle, Automated Task Execution, Knowledge Base Search, Customer Authoritative Data, Agent Functionality]

本文字数: 700, 阅读完需: 4 分钟

导读

在此演示中, 演讲者展示了一个保险代理人示例解决方案, 该解决方案将Amazon Bedrock 的Agents 和Knowledge Base 相结合, 以自动化保险理赔生命周期。 该解决方案使代理人能够执行诸如创建新理赔、发送待处理文档提醒、收集理赔证据, 以及在存储于Amazon S3 的客户数据存储库中搜索信息等操作。演示重点介绍了Amazon Bedrock 如何通过Agent 实现高效的任务执行、跨Knowledge Base 的强大搜索功能, 以及与现有业务逻辑和数据源的无缝集成。

演讲精华

亲爱的朋友们, 欢迎来到今天的演示。Kyle Bloxam 是亚马逊云科技 (AWS) 的解决方案架构师。今天, 他将为大家展示如何使用 Amazon Bedrock 的 Agents 和 Knowledge Base 功能, 实现自动化任务执行和高效搜索客户知识库。

Amazon Bedrock 的 Agents 和 Knowledge Base 建立在现有的企业资源之上, 因此用户可以利用现有的业务逻辑和客户权威数据源来驱动代理功能。这个保险代理示例解决方案结合了 Amazon Bedrock 的 Agents 和 Knowledge Base, 以自动化保险理赔生命周期。

代理可以执行诸如创建新理赔、发送待处理文档提醒、收集理赔证据以及搜索现有理赔信息等操作, 还可以跨越存储在 Amazon S3 中的客户权威数据存储库中的其他数据。我们在此解决方案中使用 Streamlit 启动一个示例前端, 模拟客户的生产应用程序。

在 Streamlit 应用程序的右侧是本地终端, 用户可以在其中看到每个前端操作的后端流程。该应用程序提供两个功能。第一个是 Amazon Bedrock Agent 的提示输入, 允许用户使用自己的任务输入来调用代理。另一个是 Amazon Bedrock Knowledge Base 的文件上传功能, 使用户能够将本地文件上传到用作客户知识库数据源的 Amazon S3 存储桶。一旦文件上传完成, 文件上传功能就会启动一个ingestion 作业来同步知识库数据源。

我们导航到 Amazon Bedrock Agents 控制台, 选择保险代理。代理概览提供了代理名称、ID 、描述和 IAM 角色等元数据。如果向下滚动, 就会看到代理的工作草稿。一旦选择工作草稿, 用户将看到用于配置代理的基础模型说明。 模型是代理将用于反应性提示的基础模型, 作为其推理过程的一部分。然后, 说明概述了代理的预期功能。可以将说明视为代理在其迭代式反应性提示推理过程中使用的基本提示的一部分。这是一个过程, 通过一系列迭代的思考、行动和观察, 代理推理出最终的响应。

代理配备了一套工具, 其中一些被称为动作组。动作组是一组 API 及其相应的业务逻辑。它们的 OpenAPI 模式定义为存储在 Amazon S3 中的 JSON 文件, 该模式允许代理与动作组描述一起推理每个 API 的功能。每个动作组可以指定一个或多个 API 路径, 然后这些 API 路径的业务逻辑通过与动作组关联的 Lambda 函数执行。

当选择” 创建理赔” 动作组时, 例如, 可以看到动作组由一个描述组成, 允许代理识别该动作组的用途, 然后可以看到包含 API 业务逻辑的 Lambda 、存储在 S3 中的 OpenAPI 模式提供了额外的上下文细节, 所有这些都是为了让代理理解 API 的功能。

现在, 让我们来看看知识库。知识库提供了完全托管的 RAG (Retrieval Augmented Generation) 功能, 使代理能够访问用户的数据。当选择” 理赔知识库” 时, 用户将看到可以通过指定一个描述来配置知识库, 指导代理何时使用知识库。

跳转到 Amazon Bedrock Knowledge Base 控制台, 选择” 理赔知识库” 以更仔细地查看配置。在知识库概览中, 用户将看到一些配置元数据, 包括知识库名称、ID 、描述和 IAM 角色。

作为知识库配置的一部分, 正在构建现有的客户知识库存储库。将知识库指向 Amazon S3 数据源后, 可以跨启动到 S3 控制台查看 S3 存储桶内容。在这个案例中, 最初有九个对象, 它们是一些包含理赔金额、修理估计、常见问题文档和其他信息文档的组合。

回到 Knowledge Base 控制台, 选择数据源, 用户可以看到它的同步历史记录。创建知识库时, 可以指定现有的向量存储, 或者允许 Bedrock 在知识库配置的过程中为用户创建向量存储。如果它为用户创建了一个, 它就会在用户的behalf 创建一个 OpenSearch Serverless 集合作为向量存储索引。

一旦配置完成, 每个数据源同步都会为存储在 S3 中的文本数据创建向量嵌入, 以便代理可以使用这些嵌入来根据相似性搜索比较返回信息给用户或增强后续基础模型提示。我们在这里看到, 最初的九个对象与知识库同步。

回到 Streamlit UI, 将首先上传一个理赔金额文档。Streamlit UI 显示文件已成功上传到 S3, 下面显示了同步知识库数据源的ingestion 作业状态。用户可以在应用程序中预览理赔金额文档。这是文档的近景, 其中包含各种车辆、财产、人身伤害和总理赔金额。

文档上传到 S3 并且知识库同步后, 现在可以询问代理该文档中包含的信息。可以从诸如” 理赔 ID 3b450c-9d 的总理赔金额是多少?“ 这样的查询开始。在幕后, 代理识别它需要使用知识库搜索工具, 然后跨文档执行相似性搜索使用文本嵌入。我们将在演示的后面更详细地讨论代理跟踪。我们看到代理的响应是, 指定的理赔 ID 的总理赔金额为 86,130 美元。

可以跟进另一个问题, 利用代理所拥有的上下文历史记录, 只需指定” 同一理赔的车辆理赔金额是多少?“ 我们看到代理的响应是, 指定的理赔 ID 的车辆理赔金额为 62,640 美元, 我们可以根据提供的文档验证总理赔金额和车辆理赔金额的响应。

如果导航回 Amazon S3 控制台并刷新, 现在可以看到存储桶中有 10 个对象, 包括最新的理赔金额文档。对数据源屏幕进行类似的刷新将显示最新的同步添加了一个新文件, 这都是 Streamlit 应用程序中的 Knowledge Base 上传功能的一部分。

让我们上传另一个文档, 这次是同一理赔的修理估计文档。文件上传后, 数据源同步完成。我们可以再次预览文档, 给您一个更近距离的观察, 文档内容如下。然后我们将从一个关于修理估计文档的问题开始, 比如” 同一理赔的修理估计总额是多少?“ 这个用例是保险代理想要跨文档比较两个值, 确保修理估计总额与车辆理赔金额总额相匹配。代理的响应是, 指定理赔的修理估计总额为62,640 美元。

现在询问” 那同一理赔的修理估计诊断是什么?“ 指定理赔的诊断是” 前端碰撞、前轴断裂和挡风玻璃破碎” 。

最后, 询问” 那同一理赔的修理估计解决方案是什么?“ 代理回应说, 该理赔的解决方案是需要保险赔付, 我们可以根据修理估计文档中包含的信息验证代理提供的响应。

现在想象一下, 保险代理正在协助客户处理理赔过程, 代理想要查询公司的内部常见问题文档, 以便为客户的问题提供回答。例如,“ 根据被保险人的驾驶历史和理赔记录, 保单费率是如何计算的?” 也许投保人担心最近的理赔会如何影响保费。

代理的回应是, 保费是使用专有算法计算的, 其中包括驾驶历史、理赔频率、车辆类型和位置等因素。一个内部模型会分析历史数据来评估风险并确定适当的保费率。这将是一个内部常见问题文档。

第一个回应, 我们可能不一定想与客户分享, 但它可以让我们了解公司的内部流程。保险代理可能会跟进另一个问题。在这种情况下, 发生理赔时, 代理应该遵循哪些步骤以确保理赔流程顺利高效?

代理回应说, 代理应该遵循内部理赔处理协议, 通过从投保人那里收集必要的信息来启动流程。这包括有关事故的详细信息、照片和任何支持文档。然后, 内部理赔系统将指导代理完成每一步, 确保理赔解决顺利高效。

但是, 如果我们想让类似的常见问题可以外部访问, 以便客户可以按需自助获取所需信息呢? 好吧, 我们可以创建一个包含外部常见问题的文档。您可以在这里看到这样一个文档的示例, 其中包含问题、答案和源URI 。我们使用之前演示的相同工作流通过文件上传过程上传此文档。然后, 我们可以在数据源同步后, 通过提出诸如” 决定我的汽车保险费率的因素有哪些?“ 这样的问题来查询知识库。

代理回应说, 决定您的汽车保险费率的因素包括您的驾驶记录、年龄、位置、车辆类型、保险选项等。保险公司使用专有算法和模型来分析这些因素, 并根据风险确定适当的保费率。

也许作为客户, 我会跟进提出另一个问题,“ 我如何降低汽车保险费率?”

代理告诉我们, 有几种方式可以降低您的汽车保险费率, 包括保持良好的驾驶记录, 没有事故或交通违规; 参加防御性驾驶课程, 这可能会让您获得折扣; 将多份保单捆绑在同一家供应商处; 以及符合可用折扣的资格, 如优秀学生、安全驾驶员等。您可以与代理沟通, 讨论您的具体保单情况以及是否有资格获得折扣。

最后, 如果我们导航回Amazon S3 文档存储库, 我们现在可以看到有12 个对象, 包括指定理赔的修理估计以及现在的外部保险常见问题文档。查看数据源同步历史记录显示有两个额外的同步, 每个同步分别添加了一个文件, 即修理估计, 然后是外部保险常见问题文档。

然后, 为了演示动作组功能, 我们返回Streamlit 应用程序并提供最后一个用户输入, 在这种情况下, 是创建新理赔的请求。基于此用户输入, 代理将识别它需要使用” 创建理赔” 动作组, 该动作组对应于” 创建理赔”API 路径及其相应的业务逻辑, 最终返回响应, 代理已创建一个具有唯一ID 的新理赔。需要处理该理赔的待处理文档是驾驶执照、登记证和证据。请尽快上传这些文档, 以便我们可以继续处理您的理赔。如果您有任何其他问题, 请告诉我。

让我们来看看代理的架构。用户可以使用文本提供输入来与代理交互。对于Amazon Bedrock, 我们发出的一些示例提示是” 创建新理赔” 或” 向投保人发送特定理赔的待处理文档提醒” 或任何您可能用于客户数据存储库的自然查询, 例如” 特定理赔ID 的总修理估计是多少?“ 或常见问题, 如” 我如何降低保险费率?”

在预处理过程中, 您在这里看到的第二步, 代理验证、上下文化和分类用户输入。用户输入以任务的形式出现, 由代理使用其聊天历史记录和在代理创建期间由用户指定的说明和基础模型来解释。这些说明为代理提供了关于其预期操作和最终目的的描述性指导。

在第3 步编排过程中, 代理制定了一个基本原理, 其中包括需要调用哪些动作组API 和知识库查询来生成观察结果, 它以迭代的方式进行反应式提示, 直到为用户生成最终响应。代理使用的工具是动作组和知识库。动作组是一组API 及其相应的业务逻辑, 其中OpenAPI 模式定义为存储在S3 中的JSON, 业务逻辑通过Lambda 函数执行。知识库则提供了完全托管的检索增强生成(RAG) 功能, 允许代理访问客户特定数据。您可以指定包含文档或知识存储库的Amazon S3 数据源, 然后知识库会提供托管的向量存储, 并自行创建向量嵌入, 以便您可以跨文档存储库执行相似性搜索, 并将最相关的上下文信息与原始基本提示相结合。

最终, 进入第6 步, 一旦所有编排迭代完成, 代理将使用构建代理的Amazon Bedrock 基础模型创建最终响应。

进一步检查知识库架构, 我们看到知识库功能通过两个关键过程来划分: 首先是预处理, 其次是运行时执行。

在预处理过程中的第1 步, 存储在Amazon S3 客户数据源存储库中的文档会经过分段, 通过我们所称的”chunking” 将文档中的文本拆分为更易于管理的块。然后在第2 步, 这些块会使用Amazon Bedrock 嵌入模型转换为嵌入, 这些嵌入随后用于创建向量索引, 以便我们可以在传入的用户查询与构成知识库的数据源中的文本之间执行语义相似性比较。

在运行时, 用户提供他们的文本输入。该输入也使用 Amazon Bedrock 嵌入模型转换为向量。向量索引会被查询以获取与用户查询相关的块, 系统通过检索增强生成将额外的上下文添加到基本提示中, 然后该增强提示与额外上下文一起用于为用户生成响应。

创建知识库后, 用户将导航到亚马逊云科技管理控制台中的 KnowledgeBase 控制台。在左侧的堆栈菜单下, 用户将在” 编排” 下找到” 知识库” 和” 代理”, 选择” 知识库” 。用户将看到可用的知识库, 我们将导航到” 理赔知识库”, 在那里用户将看到知识库配置的概览, 包括知识库名称、让我们知道何时使用知识库的描述、知识库 ID 以及其他一些元数据统计信息, 如状态、创建日期和关联的 IAM 角色。

如果向下滚动, 用户将看到为此知识库配置的数据源, 一个指向 S3 存储桶的” 理赔数据源” 。如果打开数据源, 用户将看到数据源名称、数据源 ID 和其他元数据。用户还可以看到同步历史记录。因此, 当用户向 Amazon S3 文档存储库添加新文档时, 需要同步知识库以确保嵌入保持最新状态, 并存储在托管的向量存储中, 在我们的案例中是 OpenSearch Serverless 集合。

用户将返回知识库控制台, 将看到知识库的测试窗口。如果测试窗口最小化, 请选择右上角的” 测试” 选项。用户将选择要与知识库交互的模型。在我们的案例中, 我们将使用 ClOD 2.1 。选择该模型后, 用户就有机会在此知识库上执行一些测试查询。这允许用户在将知识库与代理集成之前验证知识库的功能。

用户可以询问诸如” 理赔 ID 2S34W-8X 的修理估计诊断是什么?“ 这样的问题。用户会看到该修理估计的诊断是前端碰撞和散热器破裂。

用户将询问” 那同一理赔的修理估计解决方案是什么?”

因此, 知识库能够利用对话历史记录和我们知识库数据源中的文档上下文来提供响应, 即理赔 ID 2S34W-8X 的解决方案是更换前保险杠、引擎盖和散热器, 该理赔的修理估计为 5,390 美元。用户还会看到这里有脚注, 让用户可以进一步检查响应。因此, 用户会看到响应是从哪个块生成的。

用户会看到在解决方案和总修理成本的两种情况下都是如此。如果用户展开这个结果详情, 可以看到从同一文档生成的两个块, 其中包含了我们刚刚从存储在 Amazon S3 中的 PDF 文档中查询的相关上下文。

让我们看一下模拟的修理估计。我们将在该估计的注释中向用户展示, 诊断是前端碰撞和散热器破裂, 以及有关车身状况、解决方案和理赔ID 的其他注释。

我们将继续在知识库上进行测试, 询问诸如” 发生事故后驾驶员应该怎么做?“ 这样的问题, 假设用户是一名保险代理人, 正在回应一位最近发生事故的客户, 他们正在询问发生事故后的最佳做法, 这些数据存储在我们存储在 Amazon S3 中并通过知识库访问的常见问题文档中。

因此, 我们在这里看到, 驾驶员首先应确保每个人的安全, 然后与其他相关方交换信息, 如果可能的话拍照, 并报警。驾驶员应立即联系其保险公司报告事故, 并启动理赔流程。当我们检查结果详情时, 我们看到这些上下文信息是通过保险常见问题文档提供的。保险常见问题文档包含一系列 6 个问题及其对应的答案, 其中” 发生事故后我应该怎么做” 的问题及其对应的答案被读取并返回给用户通过知识库查询。

假设打电话报告事故的投保人正在询问报告目的的推荐事故报告和图像要求。用户也可以向知识库提出这个问题。知识库查询返回的结果是, 对于事故报告, 建议包括事故的日期、时间和地点, 所有相关方的联系信息, 事故描述以及如何发生的情况, 如果有的话还有警方报告。或者, 双方可以填写一份” 机动车事故情况说明书” 。对于事故图像, 建议提交显示事故现场、相关车辆的详细照片, 以及一些其他信息。再次, 我们看到脚注, 可以查看结果详情, 其中我们看到了生成这些块的数据源文档。在这种情况下, 一个 Word 文档显示了事故报告的描述, 另一个文件则对应于事故图像, 格式与此相同。

假设投保人随后担心他们的免赔额, 以及该免赔额将如何影响他们获得保险公司赔付事故的能力。也许他们会向保险代理提出诸如” 免赔额是什么, 它是如何运作的?“ 这样的问题。代理可以查询知识库以获取这些详细信息, 假设这些详细信息包含在客户的 Amazon S3 文档存储库中的常见问题文档中。在这种情况下, 我们确实拥有该常见问题文档, 因此如果我们查看结果详情, 我们可以看到我们从常见问题文档中获取了相关信息, 知识库查询回应说, 免赔额是用户在保险责任生效前必须支付的金额, 例如, 如果用户的免赔额为 500 美元, 而修理费用为 2,000 美元, 用户支付 500 美元, 用户的保险公司支付剩余的 1,500 美元。这就是测试我们知识库功能的全部内容。

在确认了知识库性能后, 我们就可以将该知识库与代理集成, 并执行端到端的代理测试。对于端到端的代理测试, 我们首先导航到 Amazon Bedrock Agents 控制台。我们选择我们的保险代理, 并显示代理名称、ID 、描述和其他元数据。向下滚动, 我们选择我们的工作草稿, 它允许我们迭代开发我们的代理。我们的代理配置了一个 Anthropic Claude 2.1 模型和一组定义代理功能和预期用途的说明。在下面, 我们看到我们的三个动作组和知识库。“ 理赔知识库” 就是我们刚刚测试过的那个。

每次修改工作草稿时, 例如更改代理说明, 代理控制台都会提醒用户需要准备代理, 这将把代理的所有最新更改打包到一个可测试的包中。我们准备好代理, 并看到绿色横幅确认代理已准备就绪。现在我们可以开始在测试窗口中进行测试了。

首先, 我们使用” 创建新理赔” 这一用户输入来测试” 创建理赔” 动作组。代理根据其说明、对话历史记录以及一组可用的动作组和知识库工具, 通过反应式提示来完成用户请求。对于每个动作组, 代理利用动作组描述和 OpenAPI 模式中包含的 API 详细信息, 来理解该动作组的一系列 API 及其预期功能。然后, 代理根据亚马逊云科技 Lambda 定义的业务逻辑, 响应它已为特定保单 ID 创建了一个新的个人汽车理赔, 该理赔具有唯一的 ID, 状态为开放, 有三个待处理文档: 驾驶执照、登记证和证据。投保人通过亚马逊简单通知服务(SNS) 收到一封电子邮件, 其中包含他们的新理赔信息和理赔证据门户网站的链接。此时, 人工保险代理可能希望使用” 发送提醒” 动作组发送待处理文档提醒。最终, 通过 SNS 向投保人发送了待处理文档提醒, 并提供了一个唯一的跟踪 ID 。

我们将扩大测试窗口以提高可读性。我们可以通过检查代理的跟踪来评估代理在每次动作组 API 调用和知识库查询时遵循的逻辑步骤。这提供了一个视角, 了解代理如何通过其反应式提示序列修改基本提示到基础模型。在预处理期间, 我们看到代理使用其上下文对话历史记录来识别相关理赔, 并确定需要调用通知待处理文档 API 。代理将用户输入分为 a 到 e 五个类别。在这种特殊情况下, 我们看到代理将其归类为类别 d, 即可以通过仅使用已提供的函数和来自对话历史记录或相关参数的参数( 或者它可以使用 ask user 函数直接向用户收集的参数) 来回答或协助的问题, 因此代理可以直接向用户提出澄清问题。在编排过程中, 我们看到步骤 1 是 API 调用, 步骤 2 是 API 响应和有效负载处理。默认情况下, 后处理处于非活动状态, 因此没有显示任何内容。

现在, 我们将测试代理与知识库的集成, 使用需要代理查询知识库的用户查询。“ 您提供哪些保险范围?” 人工保险代理可能会向Amazon Bedrock 代理提出这个问题, 以便他们可以快速为客户提供答复, 或者组织可以通过由代理和知识库驱动的按需自助服务模式直接向客户提供这些数据。对于Amazon Bedrock, 代理响应跟踪在这种情况下显示, 在预处理期间, 代理识别出需要查询知识库工具。然后在编排过程中, 我们看到步骤 1 是知识库查询。在步骤 2 中, 我们看到传递给 Anthropic Claude 模型的完整上下文和提示。然后在步骤 3 中显示查询响应, 默认情况下后处理仍处于非活动状态。

如果我们想修改代理预处理、编排、后处理和知识库生成的默认设置, 我们可以导航到工作草稿的提示设置, 并更改它们各自的基本模板格式。这就是我们对端到端代理功能测试的全部内容。经过一些额外的用户验收、峰值负载和其他性能测试, 代理就可以投入生产了。

总结一下, 在这个演示中, 我们学习了如何利用Amazon Bedrock 的Agents 和 Knowledge Base 功能来自动化保险理赔生命周期, 并高效地搜索客户知识库。我们看到代理可以执行诸如创建新理赔、发送待处理文档提醒、收集理赔证据以及搜索现有理赔信息等操作。知识库则提供了完全托管的检索增强生成功能, 使代理能够访问客户特定数据。我们还了解了代理和知识库的架构以及它们是如何协同工作的。总的来说, 这个解决方案展示了Amazon Bedrock 如何帮助企业利用现有资源和数据, 实现自动化任务执行和高效知识管理。

总结

该演示展示了Amazon Bedrock 的代理和知识库如何协同工作, 以自动化保险理赔生命周期并提供高效的跨客户知识库搜索功能。这些代理能够执行诸如创建新理赔、发送文档提醒、收集证据以及搜索现有理赔和存储在Amazon S3 中的其他数据等任务。

这些代理配备了动作组, 即在OpenAPI 模式中定义的一组API 及相应的业务逻辑, 使代理能够推理API 功能。知识库提供了检索增强生成功能, 使代理能够通过为来自Amazon S3 源的文本数据创建向量嵌入来访问客户数据, 从而进行相似性搜索。

通过迭代的反应提示, 代理开发出一种推理, 调用动作组API 和知识库查询来生成观察结果和最终响应。演示展示了创建新理赔、发送文档提醒、查询上传文档中的理赔详情和修理估计, 以及使用知识库回答常见问题。

这些代理的架构涉及预处理用户输入、通过反应提示协调动作组和知识库交互, 并使用基础模型生成最终响应。知识库架构包括将文档预处理为向量嵌入, 以及在运行时执行用户输入向量比较以进行上下文增强。总的来说, 该解决方案实现了自动化任务执行和高效知识检索, 用于保险理赔处理。

亚马逊云科技（Amazon Web Services ）是全球云计算的开创者和引领者。提供200 多类广泛而深入的云服务，服务全球245 个国家和地区的数百万客户。亚马逊云科技致力于成为企业构建和应用生成式AI 的首选，通过生成式AI 技术栈，提供用于模型训练和推理的基础设施服务、构建生成式AI 应用的大模型等工具、以及开箱即用的生成式AI 应用。深耕本地、链接全球 -- 在中国，亚马逊云科技通过安全、稳定、可信赖的云服务，助力中国企业加速数字化转型和创新，并深度参与全球化市场。