Q4 Inc 如何利用 Amazon Bedrock、RAG 和 SQLDatabaseChain 解决数据集挑战，构建其问答聊天机器人

by Stanislav Yeshchenko Tamer Soliman 和 Mani Khanuja 在 2023年12月6日于 进阶 (300) Amazon Bedrock 人工智能 客户解决方案 永久链接 留言

文章重点

企业越来越多地运用检索增强生成RAG方法来构建问答聊天机器人，但这一过程中存在数据集的挑战，特别是不同类型数据数字、文本、结构化、非结构化或半结构化的混合。

Q4 Inc 的应用案例

总部位于多伦多的 Q4 Inc 是一个先进的资本市场接入平台，致力于转变发行者、投资者和卖方之间的连接、沟通与互动方式。Q4 平台提供多种产品，包括投资者关系网站、虚拟活动解决方案、参与分析、投资者关系 CRM、股东及市场分析、监控和 ESG 工具。

在快速变化的数据驱动的金融环境中，投资者关系官IRO在提升公司与股东、分析师及投资者之间的沟通中扮演著至关重要的角色。IRO的日常任务包括分析来自企业内部的各类数据，包括 CRM、所有权记录及股市数据。这些数据用于生成财务报告、确定投资者关系目标、并管理与现有及潜在投资者的沟通。

为了满足日益增长的高效数据检索需求，Q4 计划构建一个聊天机器人问答工具，为 IRO 提供直观易用的信息访问方式。最终目标是实现公共可用数据与特定客户的专有数据的无缝整合，同时保持最高水平的安全性和数据隐私。Q4 希望保证查询响应时间在几秒钟内，以确保最佳用户体验。

金融市场是一个高风险的受监管行业，提供不准确或过时的信息可能会影响投资者和股东的信任，并可能引发数据隐私风险。鉴于行业特点，Q4 在评估任何解决方案之前，将数据隐私和响应的准确性作为指导原则。

Q4 的概念验证选择使用财务所有权数据集，该数据集由时间序列数据及多元素组成，描述投资机构、个人和上市公司之间的交易历史等。

实验与挑战

显然，要理解人类语言问题并生成准确答案，Q4 必须使用大型语言模型LLMs。以下是团队进行的几个实验以及所面临的挑战和学到的教训：

预训练：Q4 意识到使用自身数据集对 LLM 进行预训练的复杂性和挑战，这种方法耗资巨大且需经历数个非小型步骤如数据预处理、训练及评估；这会需要一支专业跨学科团队来持续进行增量预训练以处理新数据。

微调：微调预训练基础模型涉及使用数个标记样本，这个过程中会出现模型假象，导致模型难以理解细微的上下文，并返回错误的结果。

RAG 与语义搜索：常规 RAG 使用语义搜索作为移向 SQL 生成前的最后一步。团队测试了使用搜索、语义搜索及嵌入技术来提取上下文。这些方法对于基于自然语言的文本内容表现良好，但在处理主要由数字以及金融交易等数据组成的 Q4 数据集时效果不佳。即使对于数字所生成的嵌入，其相似性排名也很困难，常常导致错误信息的检索。

Q4 的结论：生成 SQL 是前进的道路

考虑到常规 RAG 方法面临的挑战，团队开始考虑 SQL 生成。这种想法是利用 LLM 先从用户问题生成一条自然语言的 SQL 语句，然后将该查询运行于数据库以获取相关上下文。最终的上下文将用来增强输入提示，用于后续的总结步骤。

Q4 假设为了提高检索步骤的回忆率，特别是对于数字数据集，必须首先从用户问题生成 SQL。这不仅提高准确率，也能保持特定问题的业务领域上下文。为了生成准确的 SQL，Q4 需要使 LLM 对其数据集结构完全了解，这意味著输入提示必须包括数据库模式、少量范例数据行，及难以理解字段的详细说明。

根据初步测试，这种方法显示出良好的结果。配备所有必要信息的 LLM 能够正确生成 SQL，并成功执行该查询，检索出正确的上下文。经过这样的尝试后，Q4 认为 SQL 生成是解决其数据集中上下文提取挑战的可行之路。

解决方案概述

大型语言模型(LLMs)是拥有数十亿个参数的大型模型，使用来自多个来源的大量数据进行预训练。由于这些训练数据集的广泛性，LLMs 具有在多个领域中的一般知识。这些模型的推理能力因模型不同而异，可以通过使用额外的特定领域的预训练数据或通过标记数据进行微调进一步优化。给予正确的上下文、元数据和指示，让所选择的通用 LLM 能生成优质的 SQL，只要它拥有访问适当的特定领域的上下文。

在 Q4 的案例中，我们首先将客户问题转换为 SQL。我们通过将用户问题、数据库模式、一些范例数据行以及详细指示合并为提示来生成 SQL。在获得 SQL 后，如果需要，我们可以运行验证步骤。当我们对 SQL 的质量满意时，便执行该查询以检索我们在接下来步骤中所需的相关上下文。现在我们拥有相关上下文后，可以向 LLM 发送用户的原始问题、检索的上下文以及一组指示，让其生成最终的摘要回应。这一步的目标是让 LLM 总结结果，提供一个有上下文且准确的答案，然后传递给用户。

在整个过程中，所选择的 LLM 对于准确性、成本和性能影响深远。选择一个能够灵活在同一用例中或不同用例间切换的 LLM 平台，可以在优化输出质量、延迟和成本方面提供好处。我们在本文后面会详细讨论 LLM 的选择。

解决方案组件

在概述了高层次的解决方案后，让我们深入进入细节，开始于解决方案组件。

Amazon Bedrock

Amazon Bedrock 是一个完全管理的服务，提供来自领先公司如 AI21 Labs、Anthropic、Cohere、Meta、Stability AI 和 Amazon的高性能基础模型选择。该服务还提供构建生成 AI 应用所需的广泛工具，简化开发过程并维护隐私和安全。此外，使用 Amazon Bedrock 可选择多种基础模型选项，并可使用自己的数据进行进一步微调，以使模型的回应与你的用例要求一致。Amazon Bedrock 是完全无服务器的，不需要管理底层的基础设施，通过单一 API 延伸对可用模型的访问。最后，Amazon Bedrock 支持多项安全和隐私要求，包括HIPAA合格性和GDPR合规性。

在 Q4 的解决方案中，我们使用 Amazon Bedrock 作为无服务器的 API 基础的多基础模型组件。因为我们希望在同一用例中进行多次LLM调用，根据任务类型选择最适合特定任务的模型，无论是 SQL 生成、验证还是总结。

LangChain

LangChain 是一个开源集成和协调框架，提供一组预构建模块I/O、检索、链和代理，用于整合和协调 FMs、数据源和工具之间的任务。该框架促进了建立需要协调多个步骤以生成期望输出的生成 AI 应用的过程，而无需从头编写代码。LangChain 支持 Amazon Bedrock 作为多基础模型 API。

在 Q4 的用例中，我们利用 LangChain 来协调和组织我们工作流程中的任务，包括连接数据源和 LLM。这种方法简化了我们的代码，因为我们可以直接使用现有的 LangChain 模块。

SQLDatabaseChain

SQLDatabaseChain 是可以从 langchainexperimental 导入的 LangChain 链。SQLDatabaseChain 使得创建、实现和运行 SQL 查询变得简单，利用其有效的文本到 SQL 转换和实现。

在我们的用例中，我们使用 SQLDatabaseChain 来进行 SQL 生成，简化和协调数据库与 LLM 之间的交互。

数据集

我们的结构化数据集可以存在于 SQL 数据库、数据湖或数据仓库中，只要我们支持 SQL。在我们的解决方案中，我们可以使用任何支持 SQL 的数据集类型；这应该与解决方案抽象化，并不应该改变解决方案的任何部分。

实施细节

现在我们已经探索了解决方案的途径、组件、技术选择和工具，我们可以将这些组件组合在一起。接下来的图表突出了端到端解决方案。

让我们逐步概述实施细节和流程。

生成 SQL 查询

为了简化编码，我们使用现有框架。我们使用 LangChain 作为协调框架。在输入阶段，我们接收用户以自然语言提出的问题。

在第一阶段，我们将此输入转换为可以执行的 SQL，以便从数据库中提取上下文。为生成 SQL，我们使用 SQLDatabaseChain，该链依赖于 Amazon Bedrock 获取所需的 LLM。通过 Amazon Bedrock，使用单一 API，我们可以访问多种基础 LLM，并为每次 LLM 调用选择最适合的模型。我们首先建立与数据库的连接，检索所需的表结构，以及一些我们希望使用的表中的示例数据行。

在测试中，我们发现 25 行的表数据足以提供足够的信息给模型，而不增加过多不必要的负担。三行数据刚好提供了上下文，并不会让模型负担过重。在我们的使用案例中，我们开始使用 Anthropic Claude V2，该模型在提供适当上下文和指示时以其先进的推理能力和清晰的上下文反馈闻名。作为指示的一部分，我们可以将更多澄清内容包含到 LLM 中，例如描述 CompNAME 列代表公司名称。我们现在可以通过将用户问题、数据库模式、三行样本数据及一组指示结合起来，构建提示，以清晰的 SQL 格式生成所需的 SQL，且不包含评论或附加内容。

所有输入元素的结合被视作模型的输入提示。精心设计的输入提示符合模型偏好的语法，对输出的质量与性能影响显著。选择一个适合特定任务的模型也非常重要，这不仅影响输出质量，还与成本和性能有关。

我们稍后会在本文中讨论模型选择以及提示工程优化，但值得注意的是，在查询生成阶段，我们注意到 Claude Instant 能够产生可比拟的结果，尤其是在用户问题表达清晰且不够复杂时。然而，即使是在较为复杂和间接的用户输入情况下，Claude V2 的表现更佳。我们了解到，虽然在某些情况下 Claude Instant 提供了较好反应，且具有更低的延迟和价格优势，但我们的查询生成案例更适合使用 Claude V2。

验证 SQL 查询

下一步是验证 LLM 是否成功生成了正确的查询语法，并确保该查询在考虑数据库模式和提供的示例行时具有上下文意义。在此验证步骤中，我们可以利用 SQLDatabaseChain 的本地查询验证，或向 LLM 进行第二次调用，包含生成的查询以及验证指示。

如果我们使用 LLM 进行验证步骤，我们可以使用与之前相同的 LLMClaude V2，或使用小型且性能更好的 LLM如 Claude Instant来完成这一相对简单的任务。利用 Amazon Bedrock，这应该是一个非常简单的调整。使用同一 API，我们只需在 API 调用中更改模型名称，便能轻松完成更改。值得注意的是，在大多数情况下，较小的 LLM 在成本和延迟上会提供更高的效率，应当加以考量，前提是获得所需的准确性。在我们的案例中，测试结果显示生成的查询在语法上始终正确，因此我们能够省略这一步验证，从而节省延迟和成本。

执行 SQL 查询

现在我们拥有经过验证的 SQL 查询，可将其运行于数据库以检索相关上下文。这应是一个简单的步骤。

我们将生成的上下文提供给所选 LLM，并附上最初的用户问题及一些指示，请求模型生成一个上下文清晰且优雅的总结。然后，我们将生成的摘要作为