编写查询来解决分析问题是某些项目的核心任务。然而，在大量数据分布在不同领域的快节奏环境中，找到正确的数据并将分析问题转换为正确且高效的 SQL 代码可能是一项具有挑战性的任务。

我们以大型语言模型 (LLM) 可用性的提高为契机，探索是否可以通过开发文本到 SQL 功能将这些分析问题直接转换为代码来帮助数据用户完成此任务。

文本转 SQL 的工作原理

大多数数据分析都是通过Querybook进行的，这是我们内部的开源大数据 SQL 查询工具。该工具是我们开发和部署新功能以帮助我们的数据用户（包括文本到 SQL）的自然场所。

实施文本转 SQL初始版本：使用 LLM 的文本到 SQL 解决方案

第一个版本采用了 LLM 的简单文本到 SQL 解决方案。让我们仔细看看它的架构：

用户提出分析问题，选择要使用的表。

从表元数据存储中检索相关表模式。问题、选定的SQL语句和表模式被编译到 Text-to-SQL 提示中。该提示将被输入到 LLM 中。生成流式响应并将其显示给用户。

表元数据

从元数据存储获取的表模式包括：

表名表说明列列名称列类型列说明

低基数列

某些分析查询，例如“‘web’平台上有多少活跃用户”，如果简单地生成，可能会生成不符合数据库实际值的 SQL 查询。例如，响应中的 where 子句可能是 where platform='web'，而不是正确的 where platform='WEB'。为了解决这些问题，经常用于这种过滤的低基数列的唯一值被处理并合并到表模式中，以便LLM可以利用这些信息来生成精确的SQL查询。

上下文窗口限制

极大的表模式可能会超出典型的上下文窗口限制。为了解决这个问题，我们采用了一些技术：

表模式的简化版本：仅包括关键元素，例如表名称、列名称和类型。列修剪：列在元数据存储中被标记，我们根据它们的标签从表模式中排除某些列。响应流

LLM 的完整响应可能需要数十秒，因此为了避免用户等待，我们使用 WebSocket 来传输响应。考虑到除了生成的 SQL 之外还需要返回各种信息，正确结构化的响应格式至关重要。虽然纯文本很容易流式传输，但流式传输 JSON 可能会更复杂。我们采用Langchain的部分 JSON 解析在我们的服务器上进行流式传输，然后解析后的 JSON 将通过 WebSocket 发送回客户端。

Prompt

以下是我们用于 Text2SQL 的当前提示：

评估与学习

我们对文本到 SQL 性能的初步评估主要是为了确保我们的实现具有与文献中报告的结果相当的性能，因为该实现主要使用现成的方法。我们发现与 Spider 数据集上其他地方报告的结果相当，尽管我们注意到该基准测试中的任务比我们的用户面临的问题要容易得多，特别是它考虑了少量预先指定的表，这些表很少且良好标记的列。

一旦我们的文本到 SQL 解决方案投入生产，我们还能够观察用户如何与系统交互。随着我们实施的改进以及用户对功能的更加熟悉，我们对生成的 SQL 的首次接受率从 20% 增加到了 40% 以上。实际上，生成的大多数查询在最终确定之前都需要人工或人工智能生成的多次迭代。为了确定文本到 SQL 如何影响数据用户的工作效率，最可靠的方法是进行实验。通过这样的方法，此前的研究发现， AI辅助可以将任务完成速度提高50%以上。在我们的现实世界数据中（重要的是不控制任务差异），我们发现使用 AI 辅助编写 SQL 查询的任务完成速度提高了 35%。

第二次迭代：结合 RAG 进行表选择

虽然第一个版本表现良好（假设用户知道要使用的表），但在数据仓库中的数十万个表中识别正确的表实际上对用户来说是一个重大挑战。为了缓解这一问题，我们集成了检索增强生成 (RAG)，以指导用户为其任务选择正确的表。以下是对包含 RAG 的完善基础设施的回顾：

采用离线作业来生成表摘要的向量索引以及针对它们的历史查询。如果用户未指定任何表格，则他们的问题将转换为嵌入，并针对向量索引进行相似性搜索以推断前N 个合适的表格。前N 个表以及表模式和分析问题被编译为 LLM 的提示，以选择前K 个最相关的表。前K 个表将返回给用户进行验证或更改。使用用户确认的表恢复标准文本到 SQL 过程。离线向量索引创建

向量索引中有两种类型的文档嵌入：

表总结查询汇总表总结

需要进行一些表格标准化工作，以增加表格的分层。我们仅对顶级表建立索引，以促进这些更高质量数据集的使用。表汇总生成过程包括以下步骤：

从表元数据存储中检索表架构。利用该表收集最新的示例查询。基于上下文窗口，将尽可能多的示例查询与表架构一起合并到表汇总提示中。将提示转发给LLM以创建摘要。生成嵌入并将其存储在向量存储中。

表摘要包括表的描述、表中包含的数据以及潜在的使用场景。这是我们用于表汇总的当前提示：

查询汇总

除了在表汇总中的作用之外，还单独汇总与每个表关联的示例查询，包括查询的目的和使用的表等详细信息。这是我们正在使用的提示：

NLP 表搜索

当用户提出分析问题时，我们使用相同的嵌入模型将其转换为嵌入。然后我们对表和查询向量索引进行搜索。我们使用 OpenSearch 作为向量存储并使用其内置的相似性搜索功能。

考虑到多个表可以与一个查询关联，单个表可能会在相似性搜索结果中出现多次。目前，我们使用简化的策略来汇总和评分。表摘要比查询摘要具有更大的权重，这是一种将来可以调整的评分策略。

除了用于 Text-to-SQL 之外，这种基于 NLP 的表搜索还用于 Querybook 中的通用表搜索。

表重选

从向量索引中检索前N 个表后，我们聘请LLM通过评估问题和表摘要来选择最相关的K个表。根据上下文窗口，我们在提示中包含尽可能多的表。这是我们用于重新选择表的提示：

重新选择表后，它们将返回给用户进行验证，然后再转换到实际的 SQL 生成阶段。

评估与学习

我们使用之前表搜索的离线数据评估了文本到 SQL 功能的表检索组件。这些数据在一个重要方面是不够的：它在用户知道基于 NLP 的搜索可用之前就捕获了用户的行为。因此，这些数据主要用于确保基于嵌入的表搜索的性能不会比现有的基于文本的搜索差，而不是试图衡量改进。我们使用此评估来选择方法并为表检索中使用的嵌入设置权重。这种方法向我们揭示，通过我们的数据治理工作生成的表元数据对于整体性能非常重要：嵌入中没有表文档的搜索命中率为 40%，但性能随着表文档的权重线性增加，最高可达90%。

下一步

虽然我们当前实施的文本到 SQL 显着提高了数据分析师的工作效率，但仍有改进的空间。以下是进一步发展的一些潜在领域：

NLP 表搜索元数据增强

目前，我们的向量索引仅与表摘要相关联。一项潜在的改进可能是包含更多元数据，例如分层、标签、域等，以便在检索类似表时进行更精细的过滤。

预定或实时索引更新

目前向量索引是手动生成的。每当创建新表或执行查询时实施计划甚至实时更新将提高系统效率。

相似性搜索和评分策略修订

我们当前聚合相似性搜索结果的评分策略是相当基本的。微调这方面可以提高检索结果的相关性。

查询验证

目前，LLM生成的SQL查询未经验证直接返回给用户，存在查询可能无法按预期运行的潜在风险。实施查询验证（也许使用约束束搜索）可以提供额外的保证。

用户反馈

引入用户界面来有效收集用户对表搜索和查询生成结果的反馈可以为改进提供有价值的见解。可以处理此类反馈并将其合并到向量索引或表元数据存储中，最终提高系统性能。

评估

在从事这个项目时，我们意识到现实环境中文本转 SQL 的性能与现有基准测试中的性能有很大不同，现有基准测试往往使用少量规范化良好的表（也是预先指定的）。对于应用研究人员来说，制定更现实的基准（其中包括大量非规范化表并将表搜索视为问题的核心部分）将很有帮助。