利用 AWS 分析和托管数据库区分生成型 AI 应用程序

关键要点

在定义生成型人工智能（AI）愿景的过程中，各组织处于不同阶段。生成型 AI应用程序的价值取决于您的数据，使用领域特定数据，可以为企业提供独特视角。本文提出了一个框架，帮助实现与您的数据相结合的生成型 AI应用程序，并分享了一个模块化资产，以便快速开始实施。

随着生成型人工智能（AI）潜力的不断评估，组织在定义其生成型 AI愿景的阶段各不相同。许多组织的重点是在大型语言模型（LLMs）和基础模型（FMs）上。但这仅仅是一个开始，能够让您从生成型 AI中获得差异化价值的关键在于您的数据。

生成型 AI 应用程序依然是应用程序，因此您需要：

• 操作性数据库 ：支持用户体验，以便于生成型 AI 模型以外的交互步骤
• 数据湖 ：存储特定领域的数据，并进行分析以探索和理解如何在生成型 AI 中使用这些数据
• 数据集成和管道 ：管理（来源、转换、丰富和验证等）数据，使其可用于生成型 AI
• 治理 ：管理数据质量、隐私合规等方面，确保满足适用的隐私法规，保障安全和访问控制

LLMs 和其他 FMs基于普遍可用的集合知识进行训练。如果您直接使用这些模型，它们将提供通用答案，对您的公司没有实际的差异化价值。然而，结合特定领域的数据使用生成型 AI可以为您的业务提供有价值的视角，使您能够构建与众不同的生成型 AI 应用程序及产品，脱颖而出。简而言之，您需要用您的特定数据来丰富生成型 AI 模型。

关于公司数据对生成型 AI 重要性，：“如果您的数据未为生成型 AI做好准备，您的业务也无法适应生成型 AI。”

在这篇文章中，我们提出了一个使用您的数据来实施生成型 AI应用程序的框架。我们还分享了一个可重用、模块化和可扩展的资产，帮助您迅速开始采用这个框架并实现您的生成型 AI应用程序。此资产旨在增强目录搜索引擎的能力，改善最终用户体验。

您还可以在业务智能（BI）领域中扩展此解决方案，考虑客户360度洞察用例，或在风险与合规领域中监控交易和欺诈检测等用例。

解决方案概述

您可以使用三个关键数据元素（或上下文元素）来区分生成型 AI 的响应：

• 行为上下文 ：您希望 LLM 如何表现？哪个角色应由 FM 扮演？我们称之为行为上下文。您可以通过 向模型提供这些指示。
• 情境上下文 ：用户请求是否是进行中的对话的一部分？您有没有任何对话历史和状态？我们称之为情境上下文。此外，用户是谁？您对用户及其请求有什么了解？这些数据源于您特定用途的数据存储和之前的交互。
• 语义上下文 ：是否有任何具有明显相关性的数据显示将帮助 FMs 生成响应？我们称之为语义上下文。通常情况下，这些数据来自 和搜索。例如，如果您正在使用搜索引擎查找产品目录中的产品，您可以将产品细节编码为向量，并存储在向量存储中，从而能够进行不同类型的搜索。

将这三个上下文元素结合使用，比仅依赖于普遍可用的 FM 更有可能提供连贯、准确的答案。

有不同的方法可以设计此类型的解决方案；一种方法是通过补充 模式，使用增强检索生成（RAG）派生的数据，使生成型 AI 与最新的、特定上下文的数据结合使用。第二种方法是使用您的微调或自定义生成型 AI模型与最新、特定上下文的数据。

技术架构

在实现如上所述的架构时，有几个关键方面需要考虑。首要方面是，当应用程序接收到用户输入时，应尽快处理并为用户提供响应，并保持最低延迟。这一部分的应用程序还需要使用能够处理大量用户及其活动的数据库。这意味着主要使用事务和操作数据库。

根据您的用例目标，您可能会将提示模板与 (Amazon S3) 或数据库单独存储，以便在不同的使用条件下应用不同的提示。或者，您可能将其视为代码，并使用源代码控制来管理其演变。

如 、 和 能够提供低读取延迟，并适合处理对话状态和历史（情境上下文）。文档和键值数据模型使您可以灵活调整对话状态的架构。

用户档案或其它用户信息（情境上下文）可以来自多种数据库来源。您可以将这些数据存储在关系数据库（如 ）、NoSQL 数据库或图形数据库（如 ）中。

语义上下文来源于向量数据存储或机器学习（ML）搜索服务。与 以及 是直接与向量交互的好选择。如果您希望在不显式维护向量或调优相似度算法的情况下获得更好的语义搜索效果， 是一个不错的选择。

是一个完全托管的服务，通过统一的 API，提供来自领先 AI 初创公司的高性能 FM。您可以从中选择多种 FM，以找到最适合您用例的模型。同时，Amazon Bedrock还提供丰富的能力，构建具有安全、隐私和负责任 AI 的生成型 AI 应用程序。Amazon Bedrock 提供与 Aurora 和 OpenSearchService 的集成，因此您无需自己显式查询向量数据存储。

下图总结了可支持上述解决方案框架的 AWS 服务。

目录搜索用例

我们提出一个用例，展示如何使用生成型 AI 和客户数据增强现有产品目录的搜索引擎功能，例如电子商务门户的搜索功能。

每个客户都有自己的需求，因此我们采用前面章节中提出的框架，展示该框架在目录搜索用例中的实现。您可以将此框架用于目录搜索用例，也可以根据您的需求作为基础进行扩展。

关于目录搜索实现的一个额外好处是，它可以插件形式集成到现有的电子商务门户、搜索引擎和推荐系统中，因此您无需重新设计或重建当前的流程和工具；该解决方案只需进行有限的更改，就能增强现有功能。

解决方案架构和工作流如下图所示。

工作流步骤

1. 最终用户通过前端目录应用程序的Web界面浏览产品目录并提交自然语言的搜索请求（未显示）。目录前端应用程序将用户搜索发送到生成型 AI 应用程序。应用程序逻辑当前以容器形式实现，但根据需要可以通过 部署。
2. 生成型 AI 应用程序连接到 Amazon Bedrock，将用户搜索转换为嵌入。
3. 应用程序与 OpenSearch Service 连接，搜索并检索相关的搜索结果（使用包含产品的 OpenSearch 索引）。应用程序还连接到另一个 OpenSearch 索引，以获取搜索结果中列出产品的用户评论。在搜索方面，有 ，例如 k-NN、混合搜索或稀疏神经搜索。在此示例中，我们使用 k-NN 搜索。在创建 LLM 的最终提示之前，应用程序还可以执行另一步骤，从操作数据库检索情境上下文，例如客户档案、用户偏好和其他个性化信息。
4. 应用程序从 S3 数据湖获取提示模板，并创建工程化提示。
5. 应用程序将提示发送到 Amazon Bedrock 并检索 LLM 输出。
6. 用户交互信息存储在数据湖中，以便于后续使用和 BI 分析。
7. 在步骤 5 中检索到的 Amazon Bedrock 输出被发送到目录应用程序前端，从而在 Web 用户界面中向最终用户显示结果。
8. DynamoDB 存储用于展示电子商务产品目录中产品的产品列表。 用于将产品键复制到 OpenSearch。

安全考虑

安全与合规是任何业务的重要关注点。在采用本文描述的解决方案时，您应始终考虑到 AWS 优良架构框架的 。

需要考虑不同的安全类别，并结合不同的 在每个安全类别中使用。以下是一些与本文所示架构相关的示例：

• 数据保护 ：您可以使用 （AWS KMS）来管理密钥并根据数据分类政策加密数据。您还可以使用 管理、检索和轮换数据库凭证、API 密钥及其他敏感信息。
• 身份和访问管理 ：您可以使用 (IAM) 来指定谁或什么可以访问 AWS 服务和资源，集中管理细粒度权限，并分析访问情况以优化在 AWS 中的权限。
• 检测和响应 ：您可以使用 跟踪并提供关于用户和系统操作的详细审计记录，以支持审计并证明合规性。此外，您可以使用 来观察和监控资源及应用程序。
• 网络安全 ：您可以使用 在您的账户和 AWS 网络安全服务（如 、 等）之间集中配置和管理防火墙规则。

结论

在本文中，我们讨论了使用客户数据区分生成型 AI 在应用程序中的重要性。我们提出了一个参考框架（包括功能架构和技术架构），以利用客户数据实施生成型 AI应用程序，并使用上下文学习模式与 RAG 提供的数据。接着，我们展示了如何应用此框架设计一款生成型 AI应用程序，以使用客户数据增强搜索功能并个性化电子商务产品目录的搜索结果。

请联系 AWS 以获取有关如何为您的用例实施此框架的更多信息。我们也非常乐意分享本文中呈现的技术资产，以帮助您开始构建适用于特定用例的生成型 AI应用程序。

作者简介

Diego Colombatto 是 AWS 的首席合作伙伴解决方案架构师，拥有超过15年为企业设计和交付数字转型项目的经验。在 AWS，Diego与合作伙伴和客户合作，建议如何利用 AWS 技术，将业务需求转化为解决方案。他的兴趣包括解决方案架构、算法交易和烹饪，始终欢迎与他对话相关主题。

Angel Conde Manjon 是一名驻马德里的高级 EMEA 数据与 AI策士。他曾在多个欧洲研究项目中从事数据分析和人工智能相关研究，目前帮助合作伙伴发展以数据和 AI 为中心的业务。

Tiziano Curci 是 AWS 的经理，主管 EMEA 数据与 AI 产品开发团队。他领导一个团队，帮助 AWS 合作伙伴（G/SI 和 ISV）利用最全面的能力，涵盖数据库、分析和机器学习，帮助客户通过端到端的数据战略释放数据的强大力量。