使用 AWS Lambda 和 Amazon Bedrock 构建无服务器文档聊天

by Pascal Vogel 于 2023年10月04日 发布于 Amazon Bedrock Amazon DynamoDB Amazon Simple Queue Service (SQS) AWS Lambda永久链接 分享

本文由 Pascal Vogel解决方案架构师和 Martin Sakowski高级解决方案架构师撰写。

关键要点

大型语言模型 (LLMs) 在文本生成、分析和摘要、翻译等通用任务中表现出色。通过“检索增强生成”RAG方式可以提升 LLMs 在特定领域的知识。本文介绍的解决方案使用户能够对上传的 PDF 文档提问，结合了 LLM 的文本生成和分析能力，并使用文档内容的向量搜索。该方案采用 AWS Lambda、Amazon DynamoDB 等无服务器服务构建，易于扩展与适应。

LLM大型语言模型在执行文本生成、分析与总结、翻译等一般任务时显示出高效性。由于它们是在大型数据集中进行训练的，因而可以使用广泛的一般性知识。然而，由于训练是在离线状态下进行，并利用了公开可用的数据，这也限制了它们访问专门、安全、和及时的信息的能力。

提升 LLM 在特定领域知识的一个方法是基于特定领域数据集进行微调。然而，这一过程耗时且资源消耗较大，需要专门的知识，并可能不适用于某些任务。例如，微调无法使 LLM 访问到每日更新的信息。

为了解决这些问题，检索增强生成RAG正显示出有效性。通过 RAG，可以使用 LLM 外部的数据来增强提示，通过添加相关的检索数据来丰富上下文。这种方式允许不同数据源的集成，并完全将数据源与机器学习模型分开。

工具如 LangChain 和 LlamaIndex 逐渐受到欢迎，因为它们能够灵活地集成多种数据源，包括向量数据库、搜索引擎和当前公开的数据源。

在 LLM 的背景中，语义搜索 是一种有效的搜索方式，它考虑了用户提供的提示的上下文和意图，而不仅仅是传统的字面搜索。语义搜索依赖于 词嵌入，将词、句子或文档表示为向量。因此，文档必须使用嵌入模型转化为嵌入，以作为语义搜索的基础。由于这一嵌入过程仅需在文档首次被获取或更新时进行，因此它非常适合于与 AWS Lambda 结合的事件驱动计算。

本文介绍了一种解决方案，可以让你对上传的 PDF 文档提出自然语言问题。该解决方案结合了 LLM 的文本生成和分析能力，以及对文档内容的向量搜索。它使用无服务器服务，如 AWS Lambda 来运行 LangChain，并使用 Amazon DynamoDB 进行对话记忆。

Amazon Bedrock 用于提供对基础模型如 Amazon Titan和领先 AI 初创公司如 AI21 Labs、Anthropic 和 Cohere开发的模型的无服务器访问。有关可用 LLM 和部署说明的完整列表，请查看 GitHub 仓库。

下面我们将高层次地介绍该解决方案的工作原理，然后深入探讨具体元素及其使用的 AWS 服务。以下图示提供了简化的解决方案架构，并突出显示了关键元素：

解决方案概述

用户与 Web 应用程序交互的流程如下：

用户通过静态 Web 应用程序前端上传 PDF 文档到 Amazon Simple Storage Service (Amazon S3) 桶中。这一上传触发了一个元数据提取和文档嵌入过程。该过程将文档中的文本转换为向量，并将这些向量加载到向量索引中并存储在 S3 中以备后用。当用户与 PDF 文档交谈并向后端发送提示时，Lambda 函数会从 S3 中检索索引并搜索与提示相关的信息。LLM 随后会利用向量搜索的结果、对话中的先前消息以及其通用能力来形成对用户的回复。

如以下截图所示，该解决方案中部署的 Web 应用程序允许你上传文档，并列出上传的文档及其相关元数据，例如页数、文件大小和上传日期。文档状态指示文件是成功上传、正在处理，还是已准备好对话。

通过点击已处理的文档，你可以访问聊天界面，该界面允许你向后端发送提示。你可以对每个文档进行多次独立的对话，保持独立的消息历史。

嵌入文档

当新文档上传到 S3 桶时，一个 S3 事件通知 触发一个 Lambda 函数，该函数从 PDF 文件中提取元数据如文件大小和页数，并将其存储在 DynamoDB 表中。一旦提取完成，包含文档位置的消息将被放置在一个 Amazon Simple Queue Service (Amazon SQS) 队列中。另一个 Lambda 函数使用 Lambda 事件源映射 来轮询该队列。应用 解耦消息传递模式 确保提取元数据和文档嵌入功能松散耦合，并保护更为计算密集的嵌入功能。

嵌入函数从 S3 加载 PDF 文件，并使用文本嵌入模型生成所含文本的向量表示。LangChain 集成了来自各种 LLM 提供商的 文本嵌入模型。生成的文本向量表示被加载到 FAISS 索引中。FAISS 是一个开源向量存储，可以在 Lambda 函数内存中运行，使用 faisscpu Python 包。最后，该 FAISS 索引的 备份数据 被存储在 S3 存储桶中，保存于原始 PDF 文档旁边。

生成回应

当通过 Amazon API Gateway REST API 端点提交特定文档的提示时，该请求被 代理 到一个 Lambda 函数，该函数：

从 S3 加载相应 PDF 文件的 FAISS 索引备份到函数内存中。根据提示在 FAISS 向量库中进行相似性搜索。如果可用，使用 DynamoDBChatMessageHistory 集成 检索同一对话中以前消息的记录。此集成可以将消息历史存储在 DynamoDB 中，每个对话都通过唯一 ID 标识。最后，LangChain ConversationalRetrievalChain 会将用户提交的提示、向量搜索的结果和消息历史结合，传递给 LLM 以生成回应。

Web 应用程序和文件上传

一款静态 Web 应用程序作为该解决方案的前端。它由 React、TypeScript 、Vite 和 TailwindCSS 构建，并通过 AWS Amplify Hosting 部署，后者是一项完全管理的 CI/CD 及托管服务，适用于快速、安全且可靠的静态和服务端渲染应用程序。为了保护应用程序免受未授权访问，它与 Amazon Cognito 用户池集成。API Gateway 使用 Amazon Cognito 授权者 来验证请求。

用户可以直接通过 S3 签名 URL 将 PDF 文件上传至 S3 桶。这些 URL 通过 REST API 获得。几个 Lambda 函数实现了用于创建、读取和更新 DynamoDB 表中文档元数据的 API 端点。

扩展和适应解决方案

所提供的解决方案可作为蓝图进行增强和扩展，以开发基于 LLM 的用例。例如，你可以扩展解决方案，使用户能够跨多个 PDF 文档或其他类型的数据源提问。LangChain 使得将 不同类型的数据 加载到向量存储中变得简单，你可以用这些向量进行语义搜索。

一旦你的用例涉及跨多个文档进行搜索，考虑将向量从 FAISS 加载到内存的方式转移至专用的向量数据库。AWS 上有 几种向量数据库的选项。其中一种无服务器选项是 Amazon Aurora Serverless v2 与 PostgreSQL 的 pgvector 扩展。或者，像 Pinecone 或 MongoDB Atlas Vector Search 的 AWS 伙伴开发的向量数据库可以与 LangChain 集成。除了向量搜索，LangChain 还可以与传统的外部数据源集成，如企业搜索服务 Amazon Kendra、Amazon OpenSearch 和 许多其他数据源。

本文所述的解决方案使用相似性搜索来查找与用户提供的提示最相符的信息。虽然这在所展示的用例中效果良好，你也可以使用其他方法，如 最大边际相关性，以寻找最相关的信息来提供给 LLM。当在许多文档中进行搜索并接收许多结果时，像 MapReduce 等技术可以提高 LLM 响应的质量。

根据你的用例，你可能还想选择不同的 LLM，以实现结果质量与成本之间的理想平衡。Amazon Bedrock 是一项完全托管的服务，可通过 API 提供来自领先 AI 初创公司和亚马逊的基础模型FMs，因此你可以从各种 FMs 中选择，以找到最适合你用例的模型。你可以使用诸如 Amazon Titan、AI21 Labs 的 Jurassic2 或 Anthropic 的 Claude 等模型。

为了进一步优化生成 AI 应用的用户体验，考虑使用 Lambda 响应流式传输 实现实时流式响应到前端，并实现使用 AWS AppSync 订阅 或 Amazon API Gateway WebSocket APIs 的实时数据更新。

结论

AWS 无服务器服务使得构建生成型 AI 应用变得更为简单，因为它们提供了自动扩展、内置高可用性和按需计费模型。通过 AWS Lambda 实现事件驱动计算非常适合执行计算密集型的按需任务，如文档嵌入和灵活的 LLM 编排。

quickq加速器安卓版

本文介绍的解决方案结合了 LLM 和语义搜索的能力，以回应针对 PDF 文档的自然语言问题。它是一个蓝图，可以扩展和适应以适应更多的生成 AI 用例。

通过遵循 关联 GitHub 仓库 中的说明来部署解决方案。

有关更多无服务器学习资源，请访问 Serverless Land。

标签：贡献，无服务器