1,923 讀數

如何构建生产级 Text2SQL 引擎

经过 DataStax11m2024/08/13

太長; 讀書

了解 LLM 在 text2SQL 中的作用，讨论此功能固有的挑战，并探索 Skypoint 团队推出的新型 text2SQL 引擎 SherloQ。

与数据库交互通常需要一定的技术专业知识，而这会让很多人无法轻易获取数据。假设有一位财务主管需要了解公司的财务数字和趋势。传统上，这位主管必须依靠 SQL 分析师从数据库中提取必要的数据。这种依赖性可能会导致延迟和沟通障碍，尤其是当主管需要多次优化他们的查询才能获得所需的见解时。

但 text2SQL（一种将自然语言转换为结构化查询语言语句的功能）改变了这一局面。借助 text2SQL，财务主管可以使用自然语言直接与数据库交互。例如，用户可以输入面向业务的问题，例如“上个月每个客户的平均订单价值是多少？”

文本到 SQL AI 引擎将处理该问题，并生成相应的 SQL 查询：

Select customer_id, AVG(order_value) AS average_order_value FROM orders WHERE order_date >= DATE_SUB(CURRDATE(), INTERVAL 1 MONTH) GROUP BY customer_id;

然后针对数据库执行它并将结果显示给用户。

在本文中，我们将解释 LLM 在 text2SQL 中的作用，讨论此功能固有的挑战，并探索由Skypoint团队开发的高度准确且强大的 text2SQL 引擎 SherloQ。

法学硕士 (LLM) 在 text2SQL 中的作用

借助大型语言模型(LLM)，将文本转换为 SQL 的能力得到了显著提升。这些模型使用大量数据和强大的神经网络架构来理解和生成类似人类的文本。通过对各种数据集进行训练，LLM 可以泛化到各种任务，包括将自然语言转换为 SQL 查询。

例如，论文“ 语言模型是少样本学习器”展示了 LLM 如何用最少的示例执行任务，突出了它们用有限的数据适应新任务的能力。这种方法大大减少了对大量特定任务数据的需求，使 LLM 更容易在各种应用中部署。

“ Spider：用于复杂和跨域语义解析和文本到 SQL 任务的大规模人工标记数据集”提供了全面的数据集，用于训练和评估跨不同域的复杂 SQL 查询模型。该数据集通过为模型性能提供强大的基准，在推动 text2SQL 的最新发展方面发挥了关键作用。

此外，“ PALM：使用路径扩展语言建模”探讨了如何通过先进的训练技术（例如扩大模型大小和优化训练路径）来增强包括 text2SQL 在内的各种应用中的模型性能。

虽然这些 LLM 在受控环境中非常有效，但它们在生产环境中经常面临挑战。这些挑战包括处理模糊提示、管理复杂的数据库模式以及确保实时性能。此外，将这些模型集成到现有系统中需要付出大量努力并持续维护，以适应不断变化的数据和用户需求。以下是三种适合此任务的 LLM：

SQL编码器

SQLcoder 的主要目的是将自然语言输入转换为 SQL 查询。与其他通用模型不同，SQLCoder 已针对特定于 SQL 的数据进行了改进，因此它在理解和生成 SQL 查询方面特别有效。SQLCoder 在 Spider 数据集上表现出色，该数据集是 text2SQL 系统的复杂跨域基准。

SQLCoder 以64.6% 的准确率生成了训练中未见过的新模式的正确 SQL 查询。它的表现优于 GPT-3.5-turbo 和 text-davinci-003，这两个模型的大小是它的 10 倍多。这凸显了 SQLCoder 处理多样化和复杂 SQL 查询的能力，这对于生产环境至关重要。

GPT 3.5/GPT 4

GPT-3.5 和 GPT-4（生成式预训练 Transformer）是最先进、最有效的通用语言模型之一。这两种模型在少样本学习方面都表现出色，可以用最少的示例快速适应新任务，非常适合从有限的输入创建 SQL 查询。

例如，在 Spider 数据集上进行评估时，GPT-3.5-turbo 对训练中未见过的新模式正确生成的 SQL 查询的百分比为 60.6%，而 GPT-4 则达到了 74.3%。

这些模型表现出了强大的性能，特别是在理解上下文和从复杂的自然语言输入生成准确的 SQL 查询方面。然而，它们的通用设计有时需要额外的微调才能在 SQL 生成等专业应用中获得最佳结果。

帕尔默SQL

PaLM（Pathways 语言模型）SQL 是 Google 开发的另一个强大的模型。PaLM SQL 的先进功能和架构使其能够高效地将自然语言转换为 SQL 查询，并更准确地处理复杂多样的数据库模式。

尽管 LLM 取得了进步，但在生产中依赖单个 LLM 进行 text2SQL 可能会出现问题。单一模型无法有效处理企业数据环境中的各种查询、数据库架构和实时延迟要求。

生产环境需要稳健性、适应性以及处理来自实际业务用户的模糊提示的能力。因此，text2SQL 引擎应具有三个属性才能被视为生产级：

理解不同查询公式的能力——语法上不同的用户提示可以简化为相同的 SQL 查询；好的 text2SQL 引擎应该能够理解用户提示背后的动机，牢记数据模型的上下文，并据此制定 SQL 查询。

处理模糊数据库模式和数据模型的能力——生产数据模型容易变得混乱，因为组织内的多个不同团队对其做出贡献，并且数据在其生命周期内多次更改所有权。

好的 text2SQL 引擎应该能够为用户消除数据模型的歧义，并确保噪音和歧义不会导致幻觉，这是当前 LLM 的一个特性，会阻碍很多生产用户。

它应该确保引擎的工作不会给查询的执行增加明显的延迟 -用户期望的实时答案应该实时返回。这意味着引擎应该最多在前三次尝试中制定最佳查询。

SherloQ 简介

SherloQ 是 Skypoint 的 text2SQL 引擎，可将查询从自然语言转换为 SQL。虽然利用自定义的内部 (LLM 进行查询生成是其架构的重要组成部分，但 SherloQ 的有效性来自于旨在增强数据查询功能的高级组件的组合。SherloQ 在查询转换方面具有高准确性、强大的错误处理能力以及与生产数据库系统的无缝集成，使其适用于大规模数据环境。

在接下来的几节中，我们将深入研究 SherloQ 的内部架构细节，并分享我们在生产环境中使用它所取得的一些成果。

SherloQ 的架构组件

SherloQ 的架构包含多个移动部件，每个部件都致力于提高系统的准确性、可靠性和延迟。以下是该架构的概述：

用户输入——用户输入是自然语言查询。

状态代理 Eeecutor -我们实现的 LangChain 接口可跟踪整个执行过程中的状态。它利用 Redis 和 DataStax Astra DB 跟踪执行过程中推理和内存的状态。执行器通过协调不同模块来管理操作流程。

它确保用户输入被正确解析、处理并转发到后续组件，维持从输入到 SQL 查询生成的流程。

状态工具- Langchain 基础工具的扩展类，具有状态变量并将该状态传递给相应的工具。通过维护状态变量，状态工具可以跟踪需要转发到相应工具的必要数据。这可确保数据流的一致性，防止代理之间转换期间出现任何信息丢失。

SherloQ 的状态工具：

查询生成工具使用检索到的少样本查询、数据模型上下文和 DB 模式来生成初始 SQL 查询。它通过使用解析的模式信息和从上下文示例中学习来增强生成的 SQL 查询的准确性和相关性。

重试工具会分析查询执行期间引发的任何错误，并重新生成解决错误的查询。

DB 工具可帮助获取数据库架构和相应的元数据（注释、评论等），这些元数据对查询生成很有帮助。检索到的架构信息使用基于时间的缓存机制进行缓存，以优化性能并减少数据库查询。它还针对数据库执行查询并返回结果或错误堆栈跟踪。

提高 SherloQ 性能的数据输入和技术

为了提高 SherloQ 的性能，我们采用了多种技术并为模型提供了重要的数据输入。这些技术包括结构化分解、少量样本示例、数据模型上下文检索、反射和重试机制。每个部分对于提高模型从自然语言输入生成精确且相关的 SQL 查询的能力都至关重要。

结构化分解

在结构化分解中，用户提示被分解成基本部分。关注并识别查询的基本组成部分有助于模型生成准确的 SQL。例如：

输入：XYZ 公司供应的所有物品当前可供供应的数量是多少？

输出：[“当前可用数量”，“所有物品”，“由 XYZ 公司供应”]

小样本示例

以几个 SQL 示例的形式向模型提供参考问题，这有助于模型根据类似的模式生成 SQL 查询。这些示例通过帮助模型识别目标查询的结构和格式，提高了模型准确生成各种提示的新 SQL 查询的能力。以下是几个示例：

示例 1

输入：显示可用数量少于 20 件的物品。

输出：SELECT * FROM stock WHERE Quantity_Available < 20;

示例 2

输入：列出商品价格超过 100 美元的供应商。

输出：SELECT * FROM vendor WHERE Vendor_ID IN (SELECT Vendor_ID FROM items WHERE Unit_Price > 100);

我们使用向量数据库Astra DB中的语义相似性匹配动态选择最相似的几个样本示例。向量数据库使我们能够找到结构和内容与新输入查询最接近的示例，从而确保模型可以利用最相关的模式来生成准确的 SQL 查询。

在我们的生产环境中，我们平均每个查询使用大约两个少样本示例。根据我们的经验，仅仅添加更多少样本示例来提高准确率并不是一个可扩展的做法。

数据模型上下文

数据模型上下文包含特定于域的详细信息，这些信息在创建 SQL 查询时非常有用。例如，在医院网络的财务数据上下文中，这些信息可以是财务指标代码及其描述等内容。模型使用此上下文来确保创建的 SQL 查询与域的数据结构相匹配。数据模型上下文的包含是可选的，只有当表很复杂并且需要域知识来形成 SQL 查询时才需要。

例如：

指标代码： “MGMTFEE”->描述：“管理物业所收取的费用——管理费”

SQL 数据库架构

SQL DB 架构是可用数据的结构化表示。通过注释表及其列，架构得到了丰富。它包括表名称和说明，以及列、其说明和数据类型。

提供模式有助于模型理解数据库结构以及与每个表和列相关的含义，确保生成的 SQL 查询在语法上正确并使用正确的数据库元素。

反射

反思是指模型评估和评估其自身过去的响应、行为或生成内容的能力。它允许模型通过识别和纠正错误或弱点来改进其响应。该过程包括考虑 Sherloq 引擎之前看到的查询以及查询生成阶段的反馈。

这些场景有助于模型复制过去遇到的类似问题的成功或避免失败。此步骤还利用 Astra DB 查找与当前查询在语义上最相似的查询。

重试机制

SherloQ 使用从数据库收到的错误的重试机制。当生成的 SQL 查询导致错误时，引擎将使用具有预定义模板的代理来更正查询：

“””

您的任务是修复问题生成的错误 SQL 查询，使其与 ANSI SQL 兼容。请遵循以下准则：仔细分析问题、数据库架构和收到的错误消息，以确保答案准确无误。使用表别名避免混淆。

例如， SELECT t1.col1, t2.col1 FROM table1 AS t1 JOIN table2 AS t2 ON t1.id = t2.id 。

计算配给量时，务必将分子转换为浮点数。使用以下格式：

任务：

生成一个 SQL 查询来解决问题 [QUESTION] {user_input} [/QUESTION] 正确的查询是：{sql_query} 上次执行期间收到的错误消息是：{error_message}

回复：

根据以上输入，以下是更正后的 SQL 查询：{response_sql} “””

比较结果：SherloQ 实施前后

通过使用先进的 LLM 和精心设计的系统，SherloQ 可以生成更精确、更贴近上下文的 SQL 查询。在这里，我们使用延迟和准确性指标比较了 SherloQ 之前和之后用户提示的结果。

使用一个生产问题进行比较

这里我们来看看我们的一个生产客户，一家知名的老年生活运营商。他们的一个用例是他们的财务团队使用 Skypoint 的平台来了解和推理不同老年生活设施的综合财务指标。

用户提示： “确定 2022 年全年设施 CM 的客房清洁费用的季度趋势。”

SherloQ 之前

生成的查询
- SELECT SUM(Total_Amount_Numerator) / SUM(Total_Amount_Denominator) AS Housekeeping_Expenses FROM skypoint_metric_fact_denormalized_vw WHERE Facility_Name = 'CM' AND Year = 2022 AND Metric_Name = 'Housekeeping Expense' GROUP BY Quarter_Number';
已发现的问题
- 查询按 Quarter_Number 分组但未选择它，这可能导致结果不完整。
- 使用 Metric_Name，而不是像 Metric_Code 这样更具体的标识符。
- SUM(Total_Amount_Denominator) 不处理可能被零除的情况。
平均延迟：29 秒
SherloQ 之前的设置使用了 GPT-3.5 与提示工程以及每个用户提示 5+ 次小样本查询的组合。

使用 SherloQ

生成的查询
- SELECT 年份、季度号、SUM(总金额分子) / COALESCE(SUM(NULLIF(总金额分母,0)),1) AS Housekeeping_Expenses FROM skypoint_metric_fact_denormalized_vwWHERE Metric_Code = 'EXPOTHHOU' AND Facility_Name = 'CM' AND 年份 = 2022 GROUP BY 季度号、年份 ORDER BY 季度号 ASC;
注意到改进
查询包括 Quarter_Number，提供必要的季度细目。
使用 Metric_Code 字段，为指标提供更精确的标识符。
COALESCE(SUM(NULLIF(Total_Amount_Denominator,0)),1) 函数处理潜在的除以零的错误。
结果按季度号排序以反映季度趋势。
平均延迟：10 秒

根据生产工作负载的基准，以下是我们报告的使用 SherloQ 之前和使用后的准确性和可靠性结果：