向量数据存储在生成式人工智能应用程序中的作用

同时，许多客户还注意到，在生成式人工智能应用程序中，向量数据存储或向量数据库的使用越来越普遍。他们想知道，这些解决方案如何适应他们围绕着生成式人工智能的整体数据战略。在这篇文章中，我们介绍了向量数据库在生成式人工智能应用程序中的作用，以及 AWS 解决方案如何帮助您充分利用生成式人工智能的强大功能。

生成式人工智能应用程序

所有生成式人工智能应用程序的核心都是大型语言模型（LLM）。LLM 是一种机器学习（ML）模型，利用大量的内容（例如可通过互联网访问的所有内容）进行训练。在利用海量可公开访问的数据训练之后，LLM 被视为基础模型（FM）。这些模型可以针对各种使用场景进行调整和优化。Amazon SageMaker JumpStart 提供各种预先训练的专有开源基础模型，您可以在此基础上进行构建。这样的模型包括 Stability AI 的 Text2Image（用于根据文本提示生成逼真的图像），以及 Hugging Face 的 Text2Text Flan T-5（用于文本生成）。Amazon Bedrock 是使用 FM 构建和扩展生成式人工智能应用程序的最简单方法。借助该服务，您可以通过 API 访问 AI21 Labs、Anthropic、Stability AI 和 Amazon Titan 的模型。

尽管生成式人工智能应用程序单纯依赖 FM 就可以获得广泛的现实世界知识，但是，要想针对特定领域的主题或者专业化主题获得准确的结果，就需要对其进行定制。此外，互动内容越专业，出现幻觉（结果缺乏准确性，但看起来似乎非常正确）的频率就越高。那么，如何自定义生成式人工智能应用程序以实现领域专业化呢？

使用向量数据存储带来领域专业化

提示工程（也称为情境内学习）可能是最简单的一种方法，用于将生成式人工智能应用程序植根到特定领域的环境中并提高准确性。尽管这种技术无法完全消除幻觉，但是可以将语义含义范围缩小到您的特定领域。

就其内核而言，FM 根据一组输入词元来推断出下一个词元。在这种情况下，词元是指任何具有语义含义的元素，例如文本生成中的单词或短语。您提供的情境相关性越高，推断出的下一个词元与情境相关的可能性也就越大。您查询 FM 时使用的提示应包含输入词元，以及尽可能多的情境相关数据。

情境数据通常来自内部数据库或数据湖，这是托管您的特定领域数据的系统。尽管您只需通过附加这些数据存储中的其他特定领域数据就可以扩充提示，但是向量数据存储可帮助您使用语义相关的输入来设计提示。此方法称为检索式增强生成（RAG，Retrieval Augmented Generation）。在实际应用中，您可能会设计一个提示，使用与情境相关的个性化数据（例如用户个人资料信息）和具有相似语义的数据。

对于生成式人工智能的使用，您的特定领域数据必须编码为一组元素，每个元素在内部表示为向量。该向量包含跨一组维度（数字数组）的一组数值。下图演示的示例中，首先将情境数据转换为语义元素，然后再转换为向量。

这些数值用于在多维向量空间中，映射元素彼此之间的关系。当向量元素具有语义（它们表达了一种含义）时，邻近度就会成为情境关系的指标。以这种方式使用时，此类向量被称为嵌入。例如，在表示杂货或烹饪数据领域情境的多维空间中，“Cheese”的语义元素可以放在“Dairy”的语义元素附近。根据您的特定领域情境，语义元素可以是单词、短语、句子、段落、整个文档、图像或其他完全不同的东西。您将特定领域的数据集拆分为有意义的元素，这些元素可以相互关联。例如，下图说明了在烹饪情境中简化的向量空间。

因此，要为提示生成相关的情境，您需要查询数据库，并在向量空间中查找与您的输入密切相关的元素。借助向量数据存储系统，您可以大规模存储和查询向量，并使用高效的最近邻查询算法以及合适的索引来改善数据检索。任何具有这些向量相关功能的数据库管理系统都可以是向量数据存储。许多常用的数据库系统都提供了这些向量功能以及其他功能。在具备向量功能的数据库中存储特定领域数据集，这种做法可以带来的一个好处是，您的向量将位于源数据附近。您可以使用其他元数据来扩充向量数据，而无需查询外部数据库，您还可以简化数据处理管道。

为了帮助您快速开始使用向量数据存储，我们今天公布了 Amazon OpenSearch 无服务器的向量引擎。在正式发布后，该引擎会提供一个简单 API，用于存储和查询数十亿个嵌入。但是，我们认为，在适当的时候，所有 AWS 数据库都将具有向量功能，因为这可以简化您的操作和数据集成。此外，还有以下选项可用于满足更高级的向量数据存储需求：

• Amazon Aurora PostgreSQL 兼容版关系数据库，带有 pgvector 开源向量相似度搜索扩展插件
• 带有 k-NN（k-最近邻）插件的 Amazon OpenSearch Service（一种分布式搜索和分析服务），以及 Amazon OpenSearch 无服务器的向量引擎
• Amazon Relational Database Service（Amazon RDS）for PostgreSQL 关系数据库，带有 pgvector 扩展插件

嵌入应存储在靠近源数据的位置。因此，决定哪种选项适合您的因素包括：目前您存储数据的位置以及对这些数据库技术的熟悉程度、向量维度的扩展、嵌入数量、性能需求。在深入探讨这些选项的更具体指导之前，我们先来了解 RAG 的工作原理以及如何在 RAG 中应用向量数据存储。

为 RAG 使用向量数据存储

您可以使用嵌入（向量）来提高生成式人工智能应用程序的准确性。下图展示了此数据流。

您获取特定领域的数据集（上图的右侧，用蓝色表示），将其拆分为语义元素，然后使用 FM 计算这些语义元素的向量。然后，您将这些向量存储在向量数据存储中，这样就能够执行相似度搜索。

在生成式人工智能应用程序（上图的左侧，用橙色表示）中，您获取最终用户提出的问题，使用与数据集相同的算法将其拆分为语义元素（词元化），然后在向量数据存储中，查询输入元素在向量空间中的最近邻。借助存储，您可以获得具有情境相似性的语义元素，然后将其添加到您设计的提示中。此过程进一步使得 LLM 建立在您的特定领域情境之上，这样 LLM 更有可能输出准确且与情境相关的内容。

在向量数据存储中，在最终用户的关键路径上，使用并发读取查询执行相似度搜索。使用嵌入来填充向量数据存储以及保持更新数据更改的批处理过程，主要是对向量数据存储的数据写入。这种使用模式的各个方面以及前面提到的注意事项（例如熟悉度和规模）决定了哪种服务适合您：是 Aurora PostgreSQL 兼容数据库、OpenSearch Service、OpenSearch 无服务器的向量引擎还是 Amazon RDS for PostgreSQL。

向量数据存储注意事项

对于向量数据存储，我们介绍的使用模式还带来了一些独特而重要的注意事项。

您要使用的特定领域的数据量，以及用于将这些数据拆分为语义元素的过程，决定了向量数据存储需要支持的嵌入数量。特定领域的数据随着时间的推移不断增长和变化，您的向量数据存储也必须适应这种增长。在大规模使用时，这会影响索引效率和性能。特定领域的数据集产生数亿甚至数十亿个嵌入的情况并不少见。您可以使用分词器来拆分数据，自然语言工具包（NLTK，Natural Language Toolkit）提供了多个可供您使用的通用分词器。不过您也可以使用其他工具。归根结底，合适的分词器取决于特定领域数据集中包含何种语义元素，如前所述，这可能是单词、短语、文本段落、整个文档或具有独立含义的任何数据细分。

另一个需要考虑的重要因素是嵌入向量的维数。不同的 FM 生成具有不同维数的向量。例如，all-MiniLM-L6-v2 模型生成的向量有 384 个维度，而 Falcon-40B 向量有 8192 个维度。向量的维度越大，它所能表示的情境就越丰富，直至达到某个临界点。最终您会看到收益递减和查询延迟增加。这最终会导致维数灾难（对象似乎稀疏分布且不相似）。要执行语义相似度搜索，通常需要具有密集维数的向量，但您可能需要减小嵌入维度，以便数据库能够高效地处理此类搜索。

另一个考虑因素是您是否需要精确相似的搜索结果。向量数据存储中的索引功能可显著加快相似度搜索的速度，但它们也会使用近似最近邻（ANN，Approximate Nearest Neighbor）算法来生成结果。ANN 算法以性能和内存效率换取准确性。这些算法无法保证每次都返回最近邻。

最后要考虑的是数据治理。您的特定领域数据集可能包含高度敏感的数据，例如个人数据或知识产权。在向量数据存储接近您的现有特定领域数据集的情况下，您可以将访问权限、质量和安全控制扩展到向量数据存储，从而简化操作。在许多情况下，您无法在不影响数据的语义含义的情况下剥离此类敏感数据，这随之会降低准确性。因此，对于创建、存储和查询嵌入的系统，了解和控制流经其中的数据流非常重要。

使用 Aurora PostgreSQL 或 Amazon RDS for PostgreSQL 及 pgvector

Pgvector 是一款开源的 PostgreSQL 扩展插件，由社区提供支持，可用于 Aurora PostgreSQL 和 Amazon RDS for PostgreSQL。该扩展插件对 PostgreSQL 进行扩展，提供了名为 vector 的向量数据类型，三个用于相似度搜索的查询运算符（Euclidian、负内积和余弦距离），以及 ivfflat（倒向文件和存储向量）索引机制，使向量可以更快地执行近似距离搜索。尽管您可以存储最多 1.6 万个维度的向量，但只能对 2000 个维度进行索引以提高相似度搜索性能。实际上，客户倾向于使用具有较少维度的嵌入。使用 Amazon SageMaker 和 pgvector 在 PostgreSQL 中构建人工智能驱动的搜索一文深入研究了这个扩展插件，是一个不错的资源。

如果您已经在关系数据库（尤其是 PostgreSQL）上进行了大量投入，并且在该领域拥有丰富的专业知识，那么您完全应该考虑为向量数据存储使用 Aurora PostgreSQL 与 pgvector 扩展插件。此外，高度结构化的特定领域数据集本质上也更适合使用关系数据库。如果您需要使用特定社区版本的 PostgreSQL，Amazon RDS for PostgreSQL 也是一个不错的选择。相似度搜索查询（读取）同样可以水平扩展，但需要遵循单个数据库集群中 Aurora 支持的最大只读副本数（15），以及复制链中 Amazon RDS 支持的最大只读副本数（15）。

Aurora PostgreSQL 还支持 Amazon Aurora Serverless v2，这是一种按需自动扩展配置，可以根据负载自动调整数据库实例的计算和内存容量。此配置简化了操作，因为在大多数使用场景中，您不再需要针对峰值进行预置或执行复杂的容量规划。

借助 Amazon Aurora 机器学习（Aurora ML）功能，您可以通过 SQL 函数调用托管在 Amazon SageMaker 中的机器学习模型。您可以使用该功能来调用 FM，直接从数据库生成嵌入。您可以将这些调用打包到存储过程中，也可以将它们与其他 PostgreSQL 功能集成，这样向量化过程就可以完全从应用程序中抽象出来。借助 Aurora ML 内置的批处理功能，您甚至可能无需从 Aurora 导出初始数据集，即可对其进行转换来创建初始向量集。

将 OpenSearch Service 与 k-NN 插件和 OpenSearch 无服务器的向量引擎结合使用

k-NN 插件使用自定义 knn_vector 数据类型，扩展 OpenSearch 这一开源的分布式搜索和分析套件，使您能够将嵌入存储在 OpenSearch 索引中。该插件还提供了三种执行 k 最近邻相似度搜索的方法：近似 k-NN、Script Score k-NN（准确）和无痛扩展（准确）。OpenSearch 包括非度量空间库（NMSLIB，Non-Metric Space Library）和 Facebook AI Research 的 FAISS 库。您可以使用不同的距离搜索算法来找到最适合需求的算法。这个插件也可以在 OpenSearch Service 中使用。Amazon OpenSearch Service 的向量数据库功能说明一文是很好的资源，可使用其来深入了解这些功能。

由于 OpenSearch 的分布式特性，对于具有大量嵌入的向量数据存储库来说，这是一个很好的选择。您的索引可以水平扩展，这样您就可以处理更多的吞吐量，用于存储嵌入和执行相似度搜索。对于想要更深入地控制执行搜索所用的方法和算法的客户而言，这也是一个很好的选择。搜索引擎专为低延迟、高吞吐量的查询而设计，为此在事务行为上进行了权衡。

OpenSearch 无服务器是一种按需的无服务器配置，消除了预置、配置和调整 OpenSearch 域的操作复杂性。您只需先创建索引集合，然后就可以开始填充索引数据。新公布的 OpenSearch 无服务器的向量引擎作为一种新的向量集合类型提供，同时还包括了搜索和时间序列集合。该引擎为您提供了一种简便的方法，让您可以着手使用向量相似度搜索。这为 Amazon Bedrock 提供了易于操作的配对方法，无需机器学习或向量技术方面的高级专业知识，即可将提示工程集成到生成式人工智能应用程序中。借助向量引擎，您可以在单个 API 调用中轻松查询向量嵌入、元数据和描述性文本，从而获得更准确的搜索结果，同时降低应用程序堆栈的复杂性。

在带有 k-NN 插件的 OpenSearch 中，向量在使用 nmslib 和 faiss 引擎时最多支持 1.6 万个维度，在使用 Lucene 引擎时最多支持 1024 个维度。Lucene 提供 OpenSearch 的核心搜索和分析功能，以及向量搜索。OpenSearch 使用自定义的 REST API 执行大多数操作，包括相似度搜索。它在与 OpenSearch 索引交互时实现了更好的灵活性，同时让您可以重复利用现有的构建分布式 Web 应用程序的技能。

如果您需要将语义相似度搜索与关键字搜索使用场景相结合，OpenSearch 也是一个很好的选择。生成式人工智能应用程序的提示工程涉及情境数据的检索和 RAG。例如，客户支持座席应用程序可以提供以前具有相同关键字的支持案例，以及具有相似语义的支持案例，以此来构建提示，这样推荐的解决方案就会基于合适的情境。

通过 Neural Search 插件（实验版本），您可以将机器学习语言模型直接集成到 OpenSearch 工作流中。使用此插件，OpenSearch 会自动为在摄取和搜索期间提供的文本创建向量。然后，它会无缝地将向量用于搜索查询。这可以简化 RAG 中使用的相似度搜索任务。

此外，如果您偏好特定领域数据上的完全托管式的语义搜索体验，则应考虑使用 Amazon Kendra。该服务提供了开箱即用的语义搜索功能，具备先进的文档和段落排名功能，消除了管理文本提取、段落拆分、获取嵌入和管理向量数据存储的开销。您可以使用 Amazon Kendra 来满足语义搜索需求，并将结果打包到您设计的提示中，从而以最少的操作开销最大限度地发挥 RAG 的优势。使用 Amazon Kendra、LangChain 和大型语言模型，在企业数据上快速构建高精度的生成式人工智能应用程序一文更深入地探讨了这个使用场景。

最后，LangChain 支持带有 pgvector 的 Aurora PostgreSQL 和 Amazon RDS for PostgreSQL、OpenSearch 无服务器的向量引擎以及带有 k-NN 的 OpenSearch Service。LangChain 是一个流行的 Python 框架，可基于 LLM 开发具备数据感知能力的代理式应用程序。

小结

嵌入应在靠近特定领域数据集的位置存储和管理。这样一来，您就可以将嵌入数据与其他元数据组合，而无需使用额外的外部数据来源。同样，您的数据不是静态的，而是会随着时间的推移发生变化，将嵌入存储在靠近源数据的位置可以简化您的数据管道，从而使嵌入保持最新状态。

带有 pgvector 的 Aurora PostgreSQL 和 Amazon RDS for PostgreSQL，OpenSearch 无服务器的向量引擎以及带有 k-NN 插件的 OpenSearch Service，是满足您的向量数据存储需求的理想选择，但哪种解决方案最为适合最终将取决于您的使用场景和优先事项。如果您选择的数据库没有向量功能，这篇文章中讨论的选项涵盖了熟悉的 SQL 和 NoSQL 范围，而且很容易上手，没有太多的操作开销。无论您选择哪个选项，向量数据存储解决方案都需要维持由应用程序调度的并发吞吐量。使用完整的嵌入集合大规模验证您的解决方案，以确保相似度搜索响应延迟符合您的预期要求。

同时，您可以将提示工程与 SageMaker JumpStart 和 Amazon Bedrock 提供的基础模型结合使用，以便能够构建创新的生成式人工智能解决方案，且无需投资于大量的机器学习技能即可让客户满意。

最后请记住，这一领域的发展日新月异，尽管我们会尽一切努力随情况的变化更新指南，但这篇文章中的建议可能并不普遍适用。

立即在 AWS 上开始构建生成式人工智能应用程序！ 探索 AWS 提供的工具和功能，帮助您更快地进行创新，重塑客户体验。

在此处查看此博文的突厥语翻译版本。

Original URL: https://aws.amazon.com/id/blogs/database/the-role-of-vector-datastores-in-generative-ai-applications/

关于作者

G2 Krishnamoorthy 担任分析副总裁，负责领导 AWS 数据湖服务、数据集成、Amazon OpenSearch Service 和 Amazon QuickSight 部门。在担任当前职位之前，G2 在 Facebook/Meta 构建和运行分析与机器学习平台，并且在 Microsoft 参与了 SQL Server 数据库、Azure Analytics 和 Azure ML 等多个部分的构建工作。

Rahul Pathak 担任关系数据库引擎副总裁，负责领导 Amazon Aurora、Amazon Redshift 和 Amazon QLDB 部门。在担任当前职务之前，他曾担任过 AWS 分析副总裁，负责整个 AWS 数据库产品组合。他是两家公司的联合创始人，一家公司侧重于数字媒体分析，而另一家则侧重于 IP 地理位置。

Vlad Vlasceanu 是 AWS 数据库全球技术负责人。他的工作重心是推动客户采用专用数据库，开发规范性指导机制，以协助客户为其工作负载选择合适的数据库。他还是 AWS 数据库专家社区的负责人，帮助解决方案架构师培养数据库技能，让他们能够为客户提供最佳的数据库解决方案。