这篇文章是与 Q4 Inc. 的 Stanislav Yeshchenko 共同撰写的。
企业采用检索增强生成（RAG）作为构建问答聊天机器人的主流方法。我们不断看到源自可用数据集的多种问题。这些数据集通常是数字和文本数据的混合，有时是结构化的、非结构化的或半结构化的。
Q4 Inc. 需要解决它们在 AWS 上构建的许多 AI 方案之一中的一些挑战。在本文中，我们讨论了 Q4 实施的一个问答机器人用例，数字和结构化数据集所带来的挑战，以及 Q4 得出 SQL 可能是一个可行解决方案的结论。最后，我们详细了解了 Q4 团队如何使用 Amazon Bedrock 和 SQLDatabaseChain 实现了一个基于 RAG 和 SQL 生成的解决方案。
用例概述
总部位于多伦多，办事处设在纽约和伦敦的 Q4 Inc. 是一家领先的资本市场接入平台，正在转变发行人、投资者和卖方之间的高效连接、沟通和互动方式。Q4 平台通过 IR 网站产品、虚拟事件解决方案、参与分析、投资者关系客户关系管理（CRM）、股东和市场分析、监控和环境、社会和治理（ESG）工具，促进资本市场之间的互动。
在当今快节奏和数据驱动的金融环境中，投资者关系官员（IRO）在促进企业与股东、分析师和投资者之间的沟通中发挥着关键作用。作为他们日常职责的一部分，IRO 分析各种数据集，包括 CRM、所有权记录和股市数据。这些数据的汇总用于生成财务报告、设定投资者关系目标以及管理与现有和潜在投资者的沟通。
为了满足对高效和动态数据检索的不断增长需求，Q4 的目标是创建一个聊天机器人问答工具，为投资者关系官员提供一种直观简单的方式，以用户友好的格式访问所需信息。
最终目标是创建一个聊天机器人，无缝集成公开可用数据和专有客户特定的 Q4 数据，同时保持最高级别的安全性和数据隐私。在性能方面，目标是保持查询响应时间在几秒钟，以确保终端用户的良好体验。
金融市场是一个受监管的行业，涉及高风险。提供不正确或过时的信息可能影响投资者和股东的信任，同时可能存在其他数据隐私风险。了解行业和要求，Q4 将数据隐私和响应准确性确定为市场推出之前评估任何解决方案的指导原则。
对于概念验证，Q4 决定使用一个金融所有权数据集。该数据集由表示所拥有资产数量的时间序列数据点组成；投资机构、个人和上市公司之间的交易历史；以及许多其他要素。
考虑到 Q4 希望确保满足我们讨论的所有功能和非功能要求，该项目还需要保持商业可行性。在决定方法、架构、技术选择和解决方案特定要素的过程中一直如此。
实验和挑战
从一开始就清楚，要理解人类语言问题并生成准确的答案，Q4 需要使用大型语言模型（LLM）。
以下是团队进行的一些实验，以及识别出的挑战和吸取的教训：
- 预训练 – Q4 理解使用自己的数据集进行预训练 LLM 的复杂性和挑战。很快明显的是，这种方法需要大量资源，并涉及许多非平凡的步骤，如数据预处理、训练和评估。除了涉及的工作量之外，这将是一项成本禁止的任务。考虑到时间序列数据集的性质，Q4 还意识到随着新数据的涌入，它将不断进行增量预训练。这将需要一个跨学科团队，拥有数据科学、机器学习和领域知识的专业知识。
- 微调 – 对预训练的基础模型（FM）进行微调涉及使用多个标记的示例。这种方法在一些情况下取得了一些初步成功，但在许多情况下，模型产生了迷幻现象。模型难以理解微妙的上下文线索，并返回错误的结果。
- RAG 与语义搜索 – 在进入 SQL 生成之前，传统的 RAG 与语义搜索是最后一步。团队尝试使用搜索、语义搜索和嵌入来提取上下文。在嵌入实验中，数据集被转换为嵌入，并存储在向量数据库中，然后与问题的嵌入匹配以提取上下文。在三次实验中检索到的上下文随后被用作输入 LLM 的原始提示的补充。这种方法对于基于文本的内容效果很好，其中数据包括带有单词、句子和段落的自然语言。考虑到 Q4 的数据集性质，它主要是包含数字、财务交易、股票报价和日期的金融数据，三种情况下的结果都不理想。即使使用嵌入，来自数字的嵌入在相似性排序方面遇到困难，并且在许多情况下导致检索到不正确的信息。
Q4的结论：生成SQL是前进的道路
考虑到使用传统的RAG方法面临的挑战，团队开始考虑生成SQL。这个想法是使用LLM首先从用户问题中生成一个SQL语句，以自然语言的形式呈现给LLM。然后运行生成的查询语句对数据库进行检索以获取相关的上下文信息。最后，这些上下文信息被用来增强输入提示，以进行总结。
Q4的假设是为了在检索步骤中获得更高的回收率，特别是对于数字数据集，他们需要从用户问题中首先生成SQL。人们认为这不仅可以增加准确性，还可以保持给定问题所涉及业务领域中的上下文。为了生成查询，以及生成准确的SQL，Q4需要使LLM充分了解他们的数据集结构。这意味着提示信息需要包括数据库模式、几个样本数据行以及不易理解的字段的人类可读的字段解释。
根据初步测试，这种方法显示出了很好的结果。装备有所有必要信息的LLM能够生成正确的SQL，然后运行该SQL来检索正确的上下文。在尝试这个想法之后，Q4决定SQL生成是解决其特定数据集下上下文提取挑战的途径。
让我们从描述整体解决方案的方法开始，将其分解成其组成部分，然后将这些部分组合在一起。
解决方案概览
LLM是具有数十亿个参数的大型模型，使用大量数据从各种来源进行预训练。由于训练数据集的广度，LLM被期望具有各种领域的通识知识。LLM以其推理能力而闻名，不同模型的推理能力各有不同。通过进一步使用附加的领域特定预训练数据或使用标记数据进行微调，可以将这种一般行为优化为特定的领域或行业。在具备正确的上下文、元数据和指令的情况下，选择适当的通用LLM可以生成高质量的SQL，只要它能访问到正确的领域特定上下文。
在Q4的用例中，我们首先将客户问题转化为SQL。我们通过将用户问题、数据库模式、一些样本数据库行和详细的指示作为提示信息，与LLM合并生成SQL。在获得SQL后，我们可以运行验证步骤（如果需要）。当我们对SQL的质量满意时，我们将查询运行在数据库中以检索所需的相关上下文。现在我们有了相关的上下文，我们可以将用户原始问题、检索到的上下文和一组指示发送回LLM以生成最终的摘要回答。最后一步的目标是让LLM总结结果并提供具有上下文和准确答案的回应，然后将其传递给用户。
在整个过程的每个阶段使用的LLM选择对准确性、成本和性能都有很大影响。选择一个可以在同一个用例中（多个LLM用于不同任务）、或跨不同用例之间灵活切换LLM的平台或技术，可以优化输出质量、延迟和成本。我们将在本文的后面讨论LLM的选择。
解决方案构建块
现在我们已经概述了高层次的方法，让我们深入细节，从解决方案构建块开始。
Amazon Bedrock
Amazon Bedrock是一个完全托管的服务，提供来自领先公司的高性能FM选择，包括AI21 Labs、Anthropic、Cohere、Meta、Stability AI和Amazon。Amazon Bedrock还提供了一系列构建生成式AI应用所需的工具，简化开发过程并确保隐私和安全性。此外，使用Amazon Bedrock，您可以选择各种FM选项，并使用自己的数据进一步对模型进行私密调优，以使模型的响应与您的用例要求相匹配。Amazon Bedrock是完全无服务器的，无需处理底层基础架构，通过单个API扩展访问可用模型。最后，Amazon Bedrock支持多种安全和隐私要求，包括HIPAA合规和GDPR合规。
在Q4的解决方案中，我们使用Amazon Bedrock作为无服务器、基于API的多基础模型构建块。因为我们打算在同一用例中多次访问LLM，根据任务类型，我们可以选择最适合特定任务的模型，无论是SQL生成、验证还是摘要。
LangChain
LangChain是一个开源的集成和编排框架，具有一组预构建的模块（I/O、检索、链和代理），您可以使用这些模块在FM、数据源和工具之间集成和编排任务。该框架可以帮助构建需要编排多个步骤以生成所需输出的生成式人工智能应用程序，而无需从头编写代码。LangChain支持Amazon Bedrock作为多基础模型API。
针对Q4的用例，我们在工作流中使用LangChain来协调和编排任务，包括连接数据源和LLM。这种方法简化了我们的代码，因为我们可以使用现有的LangChain模块。
SQLDatabaseChain
SQLDatabaseChain是一个可以从langchain_experimental导入的LangChain链。SLDatabaseChain通过有效的文本转SQL转换和实现，简化了创建、实现和执行SQL查询的过程。
在我们的用例中，我们在SQL生成中使用SQLDatabaseChain，简化并编排数据库和LLM之间的交互。
数据集
我们的结构化数据集可以存储在SQL数据库、数据湖或数据仓库中，只要我们支持SQL。在我们的解决方案中，我们可以使用任何具有SQL支持的数据集类型；这应该对解决方案进行抽象化，并且不应以任何方式改变解决方案。
实施细节
现在我们已经探讨了解决方案方法、解决方案组件、技术选择和工具，我们可以将这些组件组合起来。下图突出了端到端解决方案。
让我们详细介绍实施细节和流程。
生成SQL查询
为了简化编码，我们使用现有框架。我们使用LangChain作为编排框架。我们从输入阶段开始，接收用户的自然语言问题。
在这个第一个阶段中，我们将这个输入转换为可以针对数据库运行的等效SQL，以进行上下文提取。为了生成SQL，我们使用SQLDatabaseChain，它依赖于Amazon Bedrock，以访问我们所需的LLM。通过Amazon Bedrock，使用单个API，我们可以访问多个底层LLM，并为每个LLM之行选择合适的LLM。我们首先建立与数据库的连接，并检索所需的表模式以及我们打算使用的表中的一些示例行。
在我们的测试中，我们发现2-5行的表数据足以提供足够的信息给模型，而不会增加太多不必要的开销。三行正好足够提供上下文，而不用过多输入来淹没模型。在我们的用例中，我们从Anthropic的Claude V2开始。该模型以其先进的推理和清晰的上下文响应而闻名，只要提供正确的上下文和指示。作为指示的一部分，我们可以向LLM中添加更多澄清细节。例如，我们可以描述列Comp_NAME代表公司名称。现在，我们可以通过将用户问题、数据库模式、我们打算使用的表的三行示例以及一组生成所需SQL的指令清洁地组合来构造提示。
所有组合在一起的输入元素被视为模型输入提示。对模型首选语法进行精心设计的输入提示对输出的质量和性能都有很大影响。选择用于特定任务的模型也很重要，不仅因为它会影响输出质量，还因为它具有成本和性能的影响。
我们在本文中讨论了模型选择、以及稍后的提醒工程和优化，但值得注意的是，在查询生成阶段，我们注意到克劳德Instant能够产生可比较的结果，尤其是当用户提问的表述较好且不太复杂时。然而，即使在用户输入更复杂和间接的情况下，克劳德V2也能产生更好的结果。我们得出结论，虽然在某些情况下克劳德Instant可能在延迟和价格方面提供了足够的准确性，但我们的查询生成案例更适合克劳德V2。
验证SQL查询
我们的下一步是验证LLM是否成功生成了正确的查询语法，并且查询在考虑到数据库模式和示例数据行时具有上下文意义。对于这个验证步骤，我们可以回归到SQLDatabaseChain中的原生查询验证，或者我们可以对LLM进行第二次训练，包括查询生成以及验证指令。
如果我们在验证步骤中使用LLM，我们可以使用之前相同的LLM（克劳德V2）或者一个更简单任务的更高性能LLM，例如克劳德Instant。因为我们使用的是Amazon Bedrock，这应该是一个非常简单的调整。使用相同的API，我们可以在API调用中更改模型名称，并解决这个变化。需要注意的是，在大多数情况下，较小的LLM可以在成本和延迟方面提供更高效率，并且应该被考虑，只要获得所需的准确性。在我们的情况下，测试证明查询生成一直保持一致的准确性，并且具有正确的语法。有了这个知识，我们能够跳过这个验证步骤，节省延迟和成本。
运行SQL查询
现在，我们有了经过验证的SQL查询，我们可以对数据库运行SQL查询，并检索相关的上下文。这应该是一个简单的步骤。
我们将生成的上下文提供给我们选择的LLM，同时提供初始用户问题和一些指导，并要求模型生成一个有关上下文的文本摘要。然后，我们将生成的摘要作为对初始问题的答案呈现给用户，与从我们的数据集中提取的上下文保持一致。
对于用于摘要步骤的LLM，我们可以使用Titan Text Express或克劳德Instant。它们都是摘要任务的良好选择。
应用集成
问答聊天机器人能力是Q4的AI服务之一。为了确保模块化和可扩展性，Q4将AI服务构建为通过API可访问的微服务，这些微服务可以通过API与Q4应用程序集成。这种基于API的方法实现了与Q4平台生态系统的无缝集成，并促进了将AI服务能力暴露给平台应用程序套件的实现。
AI服务的主要目标是提供从任何公共或专有数据源检索数据的简单能力，并使用自然语言作为输入。此外，AI服务提供了额外的抽象层，以确保满足功能和非功能性需求，如数据隐私和安全性。下图演示了集成概念。
实施挑战
除了我们前面讨论过的结构化数值数据的挑战，Q4还面临许多其他需要解决的实施挑战。
LLM选择和性能
选择适合任务的正确LLM至关重要，因为它直接影响输出的质量以及性能（往返延迟）。以下是影响LLM选择过程的一些因素：
- LLM的类型 – FM的架构方式和模型的初始预训练数据决定了LLM擅长的任务类型以及其表现。例如，文本LLM擅长文本生成和摘要，而文本到图像或图像到文本模型更适用于图像分析和生成任务。
- LLM的大小 – FM的大小是通过特定模型具有的模型参数数量来衡量的，现代LLM通常以十亿计。通常来说，模型越大，初始训练或后续微调的成本越高。另一方面，一般来说，对于相同的模型架构，模型越大，在执行其专门任务方面的智能性期望也就越高。
- LLM的性能 – 通常来说，模型越大，生成输出所需的时间就越长，假设您使用相同的计算和I/O参数（提示和输出大小）。此外，对于相同的模型大小，性能受到提示优化程度、I/O令牌大小以及提示的清晰度和语法的高度影响。良好设计的提示以及优化的I/O令牌大小可以改善模型的响应时间。
因此，在优化您的任务时，请考虑以下最佳实践：
- 选择适合当前任务的模型
- 选择最小的模型尺寸，以达到您所需的准确度
- 优化您的提示结构，并尽可能具体地以一种易于模型理解的方式提供说明
- 使用最小的输入提示来提供足够的指示和上下文信息，以达到您所需的准确度水平
- 将输出大小限制为对您有意义且满足您的输出要求的最小大小
根据模型选择和性能优化因素，我们开始优化我们的 SQL 生成用例。经过一些测试，我们注意到，只要我们有正确的上下文和指示，与 Claude V2 相同的提示数据，Claude Instant 在性能和价格上可以产生与 Claude V2 相当的 SQL 质量。当用户输入更直接和更简单时，这一点才成立。对于更复杂的输入，需要使用 Claude V2 才能实现所需的准确度。
将相同的逻辑应用于摘要任务，我们得出结论：使用 Claude Instant 或 Titan Text Express 会以更优秀的性能提供所需的准确度，而不是使用 Claude V2 这样的较大模型。正如我们之前讨论过的，Titan Text Expressed 还提供了更好的性价比。
编排挑战
我们意识到，在获得有意义的输出响应之前，需要进行许多编排工作来处理用户的问题。正如解决方案概述所示，这个过程涉及多次数据库访问和多个 LLM 访问的交织。如果我们要从头开始构建，我们必须投入大量资源来完成基本代码的开发。我们迅速转向使用 LangChain 作为编排框架，利用开源社区的力量，并重用现有模块，而不是重复发明轮子。
SQL 挑战
我们还意识到，生成 SQL 并不像语义搜索或使用嵌入等上下文提取机制那么简单。首先，我们需要获取数据库架构和一些示例行，将它们作为我们的提示包含在 LLM 中。还有 SQL 验证阶段，我们需要与数据库和 LLM 进行交互。因此，SQLDatabaseChain 是我们明智的选择。由于它是 LangChain 的一部分，它很容易适应，现在我们可以使用链式结构来管理 SQL 生成和验证，从而最大程度地减少我们需要做的工作。
性能挑战
使用 Claude V2 并经过适当的提示工程（我们在下一章节中讨论），我们能够生成高质量的 SQL。考虑到所生成的 SQL 的质量，我们开始思考验证阶段是否真的添加了多少价值。通过进一步分析结果，我们清楚地看到所生成的 SQL 的质量始终是准确的，这使得添加 SQL 验证阶段产生了成本/效益不利的结果。最终，我们取消了 SQL 验证阶段，而不会对我们的输出质量产生负面影响，并缩短了 SQL 验证往返时间。
除了为摘要步骤优化更具成本效益和性能效率的 LLM 外，我们还能够使用 Titan Text Express 获得更好的性能和成本效益。
进一步的性能优化包括使用高效的提示工程技术来微调查询生成过程。与其提供大量的标记，我们更注重以模型训练为理解基础的正确语法和最少的输入标记，并提供最小但优化的一组指示。我们将在下一章节中详细讨论这个重要的主题，它不仅适用于这里，还适用于其他用例。
提示工程和优化
如果采用正确的提示工程技术，您可以在亚马逊底层平台上为各种业务用例调整 Claude。Claude 主要作为一个会话助手，利用人/助手的形式。Claude 被训练用于填写助手角色的文本。根据所需的指示和提示完成，我们可以使用多种技术来优化我们针对 Claude 的提示。
我们从一个格式良好的提示模板开始，该模板会产生有效的完成结果，然后通过用代表真实数据的各种输入优化响应。在开发提示模板时，建议获取许多输入。您还可以使用单独的提示开发数据和测试数据集。
优化 Claude 响应的另一种方式是通过添加规则、指令和有用的优化进行实验和迭代。通过这些优化，您可以查看不同类型的完成结果，例如，告诉 Claude 提到“我不知道”以防止幻觉、一步一步地思考、使用提示链、给予“思考”的空间，同时生成响应，并进行理解和准确性的双重检查。
让我们使用我们的查询生成任务，并讨论一些优化提示的技巧。优化提示有几个核心元素：
- 使用适当的人类/助手语法
- 利用 XML 标签（Claude 尊重并理解 XML 标签）
- 为模型添加清晰的指令，以防止产生幻觉
以下是一个通用示例，展示了我们如何使用人类/助手语法、应用 XML 标签，并添加指令来限制输出为 SQL，并指示模型在无法生成相关 SQL 时说“对不起，我无法帮助”。XML 标签用于包含指令、额外提示、数据库模式、额外表格说明和示例行。
"""Human: 您是一个 SQL 专家。您的任务是根据提供的指令生成一个 SQL 语句。<instructions>理解输入问题，参考数据库模式，并查看示例行，生成代表问题的 SQL 语句。</instructions><database_schema>"在这里您可以包含您的表格模式"</database_schema><table_description>"Comp-Nam" 代表公司名称，"Own-Hist" 代表所有权历史</table_description><example_rows>"在这里您可以插入 2-5 个示例数据库行"</example_rows><question>{input}</question><additional_hints>在您的回答中仅提供 SQL ，不要加入其他注释。SQL 必须遵循正确的数据库模式。如果问题与数据库无关或无法生成相关的 SQL，请说“对不起，我无法帮助”。不要编造答案，不要使用除 SQL 外的任何答案</additional_hints>助手: """最终的工作解决方案
在我们解决概念验证期间确定的所有挑战后，我们已经满足了所有解决方案的要求。Q4 对 LLM 生成的 SQL 质量非常满意，无论是简单的任务只需要一个 WHERE 子句来过滤数据，还是需要基于上下文的 GROUP BY 和数学函数进行复杂的任务。整个解决方案的端到端延迟在使用案例中定义的可接受范围内，仅为个位数秒。这一切都归功于在每个阶段选择了最优的 LLM，正确的提示工程，消除了 SQL 验证步骤，并在摘要步骤中使用了高效的 LLM（Titan Text Express 或 Claude Instant）。
<p amazon="" api="" bedrock="" llm。通过这种灵活性，q4="" llm，可以进行实验并无缝切换="" llm，无论是查询生成、验证还是摘要。
总结
没有一个解决方案适用于所有使用案例。在 RAG 方法中，输出的质量高度依赖于提供正确的上下文。提取正确的上下文是关键，每个数据集都具有其独特的特点。
在本文中，我们演示了对于数值和结构化数据集，使用 SQL 提取用于增强的上下文可以获得更好的结果。我们还证明了像 LangChain 这样的框架可以最小化编码工作量。此外，我们讨论了在同一个使用案例中能够在不同的 LLM 之间切换以实现最佳的准确性、性能和成本的需求。最后，我们强调了 Amazon Bedrock 的无服务器特性以及其底层的各种 LLM，为构建安全、高性能和成本优化的应用程序提供了所需的灵活性。
开始您的建立生成式 AI 应用程序的旅程，通过确定对您的业务有价值的使用案例。正如 Q4 团队所学到的，SQL 生成可以成为构建智能应用程序的一个改变游戏规则的因素，这些应用程序与您的数据存储集成，释放出收入潜力。