https://mp.weixin.qq.com/s/5XD4hx25bATVbfWHq8GGGA

Text-to-SQL系统将自然语言问题转化为SQL查询，使得数据访问更具包容性和直观性。这对于组织中不懂如何编写SQL的非技术用户尤其有价值。通过连接自然语言和数据库查询，Text-to-SQL使分析师和业务用户无需掌握复杂的SQL语法即可访问和分析数据。

实际上，它实现了数据访问的民主化——不同部门的用户可以使用简单的语言获取洞察，而不是依赖技术团队或学习查询语言 [3]。这降低了数据分析的门槛，促进了更加以数据为导向的文化。随着更多员工能够直接查询数据，组织可以在各个层面做出更快、更明智的决策。

此外，允许人们用自然语言提问加快了数据检索过程，因为业务用户可以立即获得答案，而无需等待SQL专家编写查询 [4]。通过简化用户与数据库的交互方式，Text-to-SQL系统帮助释放企业数据的全部价值，并提高决策过程中的生产力。

Text-to-SQL开发中的挑战
尽管前景广阔，开发有效的Text-to-SQL系统仍面临诸多挑战和复杂性：

•
语言的歧义性和多样性：人类语言本质上是模糊的且依赖上下文，而SQL则是精确和结构化的 [4]。用户可能会用不明确或对话式的方式提出问题（例如“显示顶级订阅者”），这些表述并不能直接映射到数据库模式 [3]。在实践中，查询也可能是不完整的，或者在一个对话中跨越多个回合，增加了系统必须解释的上下文 [4,5]。处理这种模糊性和多样化的表达方式对Text-to-SQL系统来说是一项非同小道的任务。最近的一项研究发现，大约

th@datrics.ai"">*th@datrics.ai, kk@datrics.ai
的用户向Text-to-SQL系统提出的问题存在困难——通常模棱两可甚至无法回答，除非澄清 [6]。

•
领域特定术语：每个组织或数据集可能使用独特的词汇、缩写或业务术语，这些术语并不完全匹配数据库中表或列的名称 [7, 8]。当领域术语或同义词与模式标签不一致时，Text-to-SQL模型会遇到困难，要求系统融入领域知识以做出正确的关联 [9, 10, 11]。确保模型理解上下文是至关重要的，但也是具有挑战性的。

•
复杂的模式和查询：现实世界的数据库通常有许多具有复杂关系的表，而用户的问题可能需要连接多个表或应用高级SQL功能。在这种情况下生成正确的SQL是很困难的。跨多个表编写高效的连接，或处理嵌套查询和分析函数（例如窗口函数）是Text-to-SQL的一大挑战 [12]。大型模式还引入了许多名称相似的字段，增加了模型混淆表或列名的风险。没有指导的LLM可能会产生幻觉——生成语法错误的SQL，或者选择错误的表——特别是在面对许多名称相似的表或列时 [13]。确保生成的查询使用正确的数据库实体并针对性能进行优化并非易事。
这些挑战意味着现成的语言模型可能在企业Text-to-SQL任务中表现不佳。处理模糊的措辞、理解领域上下文以及应对复杂、多表数据库都需要精心设计的解决方案，而不仅仅是基于示例查询训练模型那么简单。

Datrics Text2SQL 框架
本文档介绍了一种新的Text-to-SQL框架Datrics Text2SQL（GitHub仓库），该框架通过采用结合领域知识、数据库结构和示例学习的增强生成（RAG）方法来解决上述挑战，从而提升准确性和可靠性。我们框架的核心是一个基于数据库文档和成功查询示例构建的知识库。我们将这些信息存储在一个向量数据库中，并使用检索技术为每个用户问题找到最相关的上下文，从而帮助我们生成准确的SQL。

所描述的方法解决了SQL生成中的常见问题，包括选择了错误的表、创建了错误的连接以及误解了业务规则。通过遵循一个简单的过程：知识收集、上下文检索和SQL生成，我们设法产生了可靠的结果，同时适应了不同类型的问题和数据库结构。

以下各节将解释我们如何训练知识库、检索相关信息以及生成SQL代码，提供实现此解决方案的清晰指南。我们提供了关于训练知识库、检索相关上下文和生成SQL代码的方法的详细描述，为在实际应用中实施有效的Text-to-SQL解决方案提供了清晰的指南。

Datrics Text2SQL. 总体概念
Text2SQL系统旨在通过使用先进的RAG（增强生成）框架将自然语言查询转换为准确的SQL代码。该框架基于包含多种信息源的全面知识库运行：

1
数据库文档：对数据库表、列及其在整个系统中的关系的详细描述。这为理解数据库模式提供了基础。

2
问答示例：用于作为将自然语言问题映射到特定SQL语法和数据库操作参考的一组问题-SQL对。

3
领域特定规则：捕捉那些未显式存储在向量数据库中但对准确查询生成至关重要的业务逻辑和关系的专门指令。
该系统通过三个主要阶段运作：

4
知识库训练：通过对文档、示例和模式信息进行分析来建立对数据库的全面理解的过程。这包括将非结构化描述转换为结构化元数据和向量嵌入。

5
内容检索：此阶段包括使用语义相似性匹配用户的请求来从知识库中检索最相关的文档和示例。

6
SQL生成：最后阶段是系统利用检索到的信息生成满足用户意图的正确SQL查询，利用表描述和类似的查询示例。
这种方法确保了Text2SQL系统能够处理复杂查询，通过结合数据库的结构知识和查询模式的实际示例，同时尊重支配数据关系和访问模式的领域特定业务规则。

训练知识库
Text2SQL模型的训练分为两个部分——基于文本上下文（包括文档、数据库模式、DDL和用户请求的正确答案（SQL代码）的向量数据库训练以及领域特定规则的提取。后者并未存储在向量数据库中——它们被用作额外的上下文（与业务规则一起）以提高AI代理响应的准确性。

基于文档的训练
Text2SQL模型知识库的训练，即Text2SQL RAG框架的核心部分，最终将有价值的文档内容保存到向量数据库中。这一过程始于文档的训练。每份文档以JSON格式表示，并包含有关特定数据库表的详细描述，包括有关列和其他数据库集中字段连接的信息。文档应具有以下结构：

•
name: 表名
•
summary: 关于表内容的简要描述
•
purpose: 解释表的角色及其存在的原因
•
dependencies_thoughts: 关于该表字段与其他表字段之间关系的非正式注释
•
keys: 用于连接或关联其他表的关键列列表
•
connected_tables: 相关表名数组
•
columns: 每个元素都是描述列的对象的数组（包含其名称和描述）
•
entities: 从文档中提取的关键概念列表
•
strong_entities: 被认为特别重要的entities的一个子集
您不需要手动创建这个结构定义。系统可以通过分析任何包含表及其列描述的自由形式文本自动生成它。这种自动化方法节省了时间，并减少了手动创建过程中可能出现的潜在错误。系统可以从自然语言描述中提取有关表关系、列定义和数据类型的必要信息，并将其转换为正式结构，而无需人工干预。
I. 文档处理
通过LLM处理文档来执行所需字段的自动提取，该过程分为两个步骤：

1
提取表名、摘要、表用途、列及其描述、关键列和连接表
2
提取可能从此表推断出的概念，基于它的用途
对于第二步，我们采用了投票策略——我们为相同的输入内容生成多个LLM响应，并评估多个运行中概念出现的频率。这使得我们可以从概念列表中提取强概念。
文档自动生成
假设用户的数据库包含命名良好的表，其列也有明确的名称（名称反映了列和表的意义）。在这种情况下，我们可以根据可用数据的领域和一般知识来假设它们的目的和依赖关系。因此，如果我们有一个数据库模式，我们可以使用LLM生成表描述，但需有一定的合理限制。一般来说，生成的描述在第一近似上是适用的，但复杂数据结构需要领域专家验证。

以下是生成数据的最重要特征：

1
自动生成的描述遵循清晰的格式，包括“表描述”，“列描述”和“潜在依赖项”等部分，使其易于导航和审查。
2
提供详细的列描述，经常尝试解释它们的可能角色和关系。
3
强调主键、排序键和潜在的表依赖项，这有助于理解数据库结构和优化查询。
局限性：
1
虽然自动生成的描述试图定义表的角色，但有时它们可能会过于宽泛地描述它，而不是关注其特定功能。
2
在某些情况下，描述建议的表之间的依赖关系可能未被明确定义，这可能导致对不存在的关系的假设。
3
虽然一般的列描述是有用的，但它们可能并不总是能捕捉到特定的细微差别，如预定义的状态码或有意未使用的字段。
文档结构表示
对于简单的数据结构，生成的描述提供了足够的上下文，使Text2SQL代理能够在不需要专家评审的情况下理解表的目的和关系。表和列名称通常提供了足够的清晰度，使得额外的手动验证变得不必要。然而，对于具有复杂关系或特定字段约束的复杂模式，专家评审可能是至关重要的。
img-0.jpeg

表文档结构的概念视图。
为了更灵活地操作表描述的全文描述，我们需要从中提取本地概念，比如表名、简短摘要、表的目的等。此外，我们需要总结与此表相关的实体类型，以便在文档检索时定位搜索空间。
因此，在文档处理的第一步中，我们将非结构化（原始）表示转换为半结构化：

1
name: 表名
2
summary: 关于表的简短摘要
3
purpose: 表的目的
4
dependencies: 描述中提到的数据库中其他表的关系，考虑带有id标记的列
5
keys: 用于与数据库中其他表连接的列列表（通常它们遵循id模板）
6
connectedtables: 与当前表相关的表名，依据先前检测到的键
完成之后，我们可以在RAG模型调整和SQL生成阶段独立地操作所有这些属性。
接下来，我们需要通过分析表的内容和基本目的来提取推断出的实体。不是直接列出表的数据，目标是生成未明确提及但可以根据表的上下文逻辑推断出的有意义的复杂实体。

实体提取过程开始于让语言模型同时生成多个响应。与仅依赖单一输出不同，生成多个响应是为了捕捉各种解释。每个响应预计都包括在输入文本中识别出的实体列表。
一旦收到所有响应后，下一步是将每个响应中提取的实体合并成一个综合集合。这种聚合允许系统分析每个唯一实体在多个输出中出现的频率。其基本假设是，持续被提及的实体更有可能是准确的或重要的。那些在一系列LLM调用中仅出现一次的实体被认为是无关紧要的。这种方法利用多个模型输出的多样性来增强实体提取的可靠性。通过聚合和基于频率的过滤，该过程减少了异常或信心不足响应的影响，从而产生更稳健和一致的提取实体集。

示例
让我们来看一个例子。假设我们有一个记录详尽的数据库，其中每个表都有详细的描述，如下所示：

短信状态
sms_statuses表包含有关哪些活动家订阅了正在镜像的群组（或网络中的儿童）的移动消息列表及其当前状态（已订阅、未订阅、反弹或垃圾邮件投诉）的数据。
此表包含有关移动订阅状态的数据，例如活动家当前的状态，以及有关移动订阅状态的元数据，例如创建时间。

II. 基于文档的训练
如果我们拥有一个结构良好且全面的数据库描述，包括表名、描述、关系和元数据，那么我们可以利用这些数据来增强使用向量数据库（Vector DB）的增强生成（RAG）。

向量数据库将文档存储在一个高维向量空间中，将每个文档转换为捕获语义含义的数值表示（嵌入）。这些嵌入允许进行更智能和上下文感知的搜索，显著提高了信息检索的效果。每个代表表信息的文档都被存储为向量嵌入。嵌入是基于多个文档特征生成的。
img-1.jpeg

数据库文档的向量数据库存储方法。
这些嵌入伴随着包括完整表信息、关系和嵌入来源的元数据。元数据确保可以精确控制搜索空间，从而实现高效且准确的相关数据库细节检索。

训练过程涉及将文档数据结构化为多个嵌入，以捕捉数据库的不同方面：

1
表提取 - 函数利用大型语言模型（LLM）来识别并提取文档中提到的表名。
2
描述生成 - 它使用预定义模板动态创建短和长的结构化描述。
3
列处理 - 它处理表列的详细信息并将其附加到训练数据中。
4
多个训练条目 - 每个文档被转换为不同类别的嵌入：
•
包含表描述的完整文档。
•
基于依赖关系和关系的嵌入（用于跟踪表是如何链接的）。
•
表元数据嵌入（名称、描述和键）。
•
连接的表及其关联。
•
实体关系以理解数据库对象之间的交互。
基于示例的训练
虽然文档提供了对数据库的全面概述，包括关系、连接和其他复杂情况，但这并不能保证仅凭这些信息就足以准确解读领域特定的细微差别，并生成正确的SQL查询以回应用户的请求。这就是为什么能够处理问答示例的能力非常关键。

每个示例由一个“问题 - SQL查询”对组成，我们将其存储在向量数据库（Vector DB）中。这些示例作为参考点，使系统能够在生成SQL查询以回应用户请求时检索相关模式和结构。通过利用这些存储的示例，模型可以提高准确性，并更有效地适应复杂的、特定领域的查询。

为了增强SQL查询生成和自然语言理解，我们实施了一个结构化的规范化和提取过程。此过程将用户请求（伴有SQL代码的答案）转换为结构化的JSON格式，捕获关键元素，如规范化的问题、请求的实体、数据源和计算。
img-2.jpeg

带向量表示的示例数据库结构。
每个存储的示例被表示为结构：

其中：

  • 第个示例的初始用户查询。
  • 对应的SQL查询（如果有的话）。
  • 初始问题的规范化形式。
  • 与查询相关的提取实体。
  • 查询的主要子句。
  • 已识别的数据源（表和列）。
  • 查询中存在的操作（聚合、过滤、分组）。
  • 第个表，来自数据库，在第个示例中使用
    来自的列集合，在第个示例中使用

I. 示例规范化和结构化
首先，我们将自然语言查询转换为标准化格式，同时删除不必要的细节。这确保了不同数据库查询之间的一致性和适应性。此外，我们分析（自然语言查询，SQL代码）对，以提取与该请求相关的实体并识别数据源和操作。

此过程由大型语言模型（LLM）执行，同时执行以下任务：

以下规则定义了LLM如何转换和从自然语言输入中提取结构化信息。

  1. 规范化问题
    LLM必须通过删除不必要的细节并确保结构化格式来标准化用户查询。规范化过程遵循以下步骤：

•
删除数据库特定名称（例如，表名，列名）。
•
删除显示指令（例如，“显示”，“展示”，“生成图表”）。
•
泛化条件（例如，“在2023年” → “在某个时间段”）。
•
抽象过滤细节（例如，用通用术语替换特定ID、名称或数字）。
•
维持指示形式（例如，“显示销售数据” → “销售数据”）。

  1. 请求的实体
    LLM识别查询中引用的关键数据元素。这些实体定义了正在检索的核心信息。

•
识别请求的核心数据（例如，“每个地区的交易数量”）。
•
保留重要的分类定义（例如，“移动应用程序”，“电子邮件活动”）。
•
如果不影响实体身份，则去除时间过滤器和特定约束。
•
最终，我们得到了一个结构化的实体集合：
•
，其中- 实体的标签；- 实体的类型（类别、指标或标识符）；- 提供背景的任何附加属性。

  1. 数据源
    LLM必须确定哪些表和列提供必要的数据。

•
如果提供了SQL片段，则从其中提取表名和必要的列。
•
如果没有给出SQL代码，则保持数据源字段为空以避免假设。
数据源的结构化输出表示为：

  1. 提取计算和过滤器
    LLM必须识别和结构化任何数学运算、分组字段或过滤条件。

•
识别聚合操作（例如，SUM，AVG，COUNT）。
•
提取分组字段（例如，BY department）。
•
将所有过滤器和条件转换为人类可读的形式（例如，“where region = ‘US’” → “按地区过滤（美国）”）。
操作的结构化输出表示为：
(operation, target, condition)
II. 提取主要子句和细节
此外，我们通过使用多镜头学习扩展了示例描述，将请求的核心从附加细节中分离出来。这有助于有效结构化SQL查询。

LLM通过将输入查询拆分为两个不同部分来处理输入查询：

其中:

•

  • 主要子句，代表主要的数据请求。保留查询的基本意义。排除非关键修饰符，如过滤器、分组和排序。
    •
  • 扩展主要子句的细节，包含上下文细化和约束。保留所有辅助条件而不改变核心请求。明确保留分组、过滤和排序约束。
    示例转换：
    用户查询
    提取的主要子句
    提取的细节
    ‘Show me a list of sales transactions for Q4, including product details and revenue’
    ‘list of sales transactions’
    ‘for Q4, including prod- uct details and revenue’
    ‘Display the number of active users by country over the past month’
    ‘number of active users’
    ‘by country over the past month’
    ‘Get the total revenue for each depart- ment last year’
    ‘total revenue for each department’
    ‘over a defined time- frame’
    III. 丰富示例的问题变化
    为了增加覆盖示例的嵌入数量，我们生成与规范化初始问题类似的问题，同时将SQL代码视为答案。
    img-3.jpeg

生成问题变体以丰富示例的过程。
让我们看一个例子：

问题
显示过去一个月内的事件列表，包括名称、永久链接、开始日期， 结束日期和RSVP计数
SQL代码
SELECT title AS name, permalink, start_at AS start_date,
end_at AS end_date, rsvp_count
FROM events
WHERE
start_at >= DATEADD (month, -1, GETDATE())
AND start_at < GETDATE();

规范化后的形式是“在定义的时间范围内检索事件列表，包括它们的名称、永久链接、开始日期、结束日期和RSVP计数”。

•
包含所有必须检索的实体

•
包含请求包含特定时间范围引用的标识符

•
不包含与泛化原则相矛盾的具体细节
请求的实体和主要子句分别是“事件及其特性的列表”和“过去一个月内的事件列表”。为了提供更广泛的覆盖范围，我们生成了三组额外的问题，类似于请求的规范化表示：

•
提供一个指定时间段内的事件列表，包括它们的名称、永久链接、开始日期、结束日期和RSVP数量。

•
您能否给我特定时期内事件的详细信息，列出它们的名称、永久链接、开始日期、结束日期和RSVP数量？

•
生成一份报告，显示特定时期内事件的名称、永久链接、开始日期、结束日期和RSVP数量。
因此，该示例将通过七个嵌入来描述，这些嵌入增加了当用户询问相同概念时对请求特定性的不变性。

让我们看一下下面的图表。左侧的图表显示了两个示例的文本嵌入PCA可视化。每种颜色编码的组对应一个示例，该示例由来自初始问题的嵌入表示。每个标记的点对应一个文本嵌入，名称如“MainClause”、“Entity”、“Normalized”、“Similar 1”、“Similar 2”、“Similar 3”和“Init”。我们可以看到这些组是明显区分的——同一组（同一个示例）内的嵌入往往彼此靠近。

右边的图表显示了添加类似问题前后簇内距离的比较。它提供了关于嵌入分布如何随新数据变化的见解。根据提供的箱线图，我们可以看到在添加类似问题之前，嵌入更为紧凑，这意味着问题及其变体在嵌入空间中密切相关。添加类似问题后，距离的增加表明嵌入变得更加分散，可能引入了更多的多样性并减少了表示中的冗余。
img-4.jpeg

两个示例簇的文本嵌入PCA可视化。

添加类似问题前后的簇内距离比较。

嵌入的更广泛分布表明，新（类似）问题并不是训练语料库中存在的问题的精确副本。相反，它们是对查询的改写或不同表述，这使得嵌入更加多样化。这表明模型改进了处理相同查询不同形式的能力，从而使模型在检索任务中更加稳健。中位数距离的增加表明，模型学会了更好地区分相似问题，从而增强了整个表述中的编码泛化能力。这一改进使得检索步骤在增强生成（RAG）系统内部较少依赖于请求中使用的特定词语，因此无论使用何种短语，相似的查询都将始终返回相关结果。

最后，每个示例都通过为初始问题及其变体、规范化问题、主要子句和其他提取实体创建的嵌入云存储在向量数据库中。

领域特定说明
除了将总体和全面的问答示例描述存储在Text2SQL模型中外，我们还进行了领域特定说明的自动生成，这些说明是从示例中推断出来的，包含了用户以自然语言表达的问题与底层数据库模式之间的推理桥梁。通过对问题SQL对的系统分析，我们获得了将领域实体与相应数据库表关联的结构化映射。

领域特定映射可以描述为一个多阶段过程，从每个问题SQL对中提取知识，以创建完整的映射框架：

I. 表的选择和理由
对于每个问题SQL示例，我们确定回答问题所需的有关表。这个选择过程由一个大语言模型（LLM）执行，该模型不仅确定必要的表，还提供明确的理由。此过程的输入包括：

•

  • 第个示例的自然语言问题形式（规范化形式）
    •
  • 第个示例中的数据库表集合
    •
  • 指导表选择的一组业务规则。
    •
  • 正确的SQL查询（用于验证）
    基于LLM的表选择功能表示为：

其中
是模型选择的表集合。

  • 解释为何每个表是必要的理由
    语言模型生成一个必需表的列表，并附上解释为何每个表对回答问题是必要的理由。然后，将输出结构化为一致的JSON格式以供进一步处理。
    II. 领域特定实体的提取和分类
    从收集的示例和表选择中，我们得出了一个全面的领域实体集合，将它们归类为次要（具体属性）或主要（概念分组）：

1
次要实体：领域内的具体属性或离散数据点，例如“事件名称”，“事件开始日期”或“事件RSVP数量”。这些实体通常直接映射到表列或简单连接。
2
主要实体：通常需要多个表或复杂关系才能表示的广义概念，例如“步骤参数”或“订阅电子邮件的活动家”。这些实体通常封装业务逻辑或领域工作流程。
实体分类过程由一个大型语言模型（LLM）执行，该模型分析检索到的表、元数据和业务规则以分配实体。这个过程公式化为：

其中：
•
表示提取的实体集合。
•
特定规则，帮助完善分类。
•
对于每个提取的实体，模型生成一个结构化映射，定义其角色、关联的表和提取方法。这个映射表示为：
•
, class
•
其中：
•

  • 实体名称及其在领域内的概念角色。
    •
  • 访问此实体所需的数据库表。
    •
    class- 分类类型，指示实体是次要还是主要
    •
  • 从示例派生的领域特定实体的完整集合
    •
    领域特定映射是基于每个示例的领域特定实体联合创建的全文指令：
    •
    Instr_Domain
    示例
    让我们考虑一个简化的示例，以说明上面描述的过程。
    问题：“上个月有多少人报名参加了气候游行活动？”

SQL查询：
SELECT COUNT(rsvps.id)
FROM rsvps
JOIN events ON rsvps.event_id = events.id
WHERE events.name LIKE ‘%climate march%’
AND events.start_date BETWEEN DATE_SUB(CURDATE(), INTERVAL 2 MONTH)
AND DATE_SUB(CURDATE(), INTERVAL 1 MONTH)

选定的表格：
•
‘events’ - 识别特定的气候游行活动及其时间
•
‘rsvps’ - 统计报名参加活动的人数
衍生的实体映射：
次级实体：
•
‘event name’ → 表：events，列：name
•
‘event start date’ → 表：events，列：start_date
•
‘RSVP count’ → 表：rsvps，聚合：COUNT(id)
主要实体：
•
‘event participation’ → 表：events + rsvps，通过event_id连接
基于DB模式的训练
基于DB模式的训练过程是通过生成全文描述来进行文档创建，随后基于文档进行训练，如上所述。
img-5.jpeg

基于数据库模式的训练流程。

结论
知识库的训练为Text2SQL模型奠定了基础，使其能够准确且具有上下文意识地生成SQL查询。通过将知识库结构化为数据库文档、示例查询和领域特定映射，系统确保了高效的检索和高度可靠的响应生成：

•
文档驱动的训练创建了数据库表、关系和依赖项的结构化表示，使模型能够有效地理解数据库模式。
•
基于示例的训练通过利用存储的问题SQL对增强了SQL查询生成，提高了系统解释自然语言查询和检索相关模式的能力。查询规范化、实体提取、数据源识别和操作结构化的过程完善了查询构建，带来了更高的准确性和适应性。
•
领域特定的指令充当自然语言查询和底层数据库模式之间的推理桥梁，确保正确的表选择、属性映射和关系定义。
从知识库中检索内容
知识库包含关于数据库和问答示例的整体和全面信息，为我们的代理提供了通过SQL提示回答用户问题所需的上下文。内容检索程序基于以下单元：

1
检索适当的示例 - 使用相似性搜索方法从知识库（向量数据库）中检索类似的SQL相关问题。它还包括可选的重新排序以细化结果。此阶段的结果用作直接的代码示例，要么直接修改使用，要么作为灵感来生成回答问题的SQL。
2
检索相关表的文档 - 确定给定自然语言查询的最相关数据库表。它是基于向量数据库中的语义搜索，随后的结果使用基于推理的大语言模型和纳入领域特定业务规则进行细化。文档为我们提供了输出SQL代码中使用的表的整体视野，包括列的详细描述及其依赖关系，从而最小化了错误答案的风险。
检索适当的示例
为了找到生成回答问题的SQL代码的适当示例，我们实施了迭代方法，通过逐步扩大搜索空间由于连续请求的特定性，减少并降低相似性阈值。

其中

  • 用户问题或其衍生品的向量表示
  • 存储的示例描述符的向量表示，例如全文问题，其规范化形式，提取的实体等。
  • 是所有检索到的示例的集合
  • 相似性阈值
    适当的示例检索过程可以用下图表示。
    示例检索流可以分为两个全局阶段：

•
提取完美匹配用户请求的示例
•
提取被视为文档支持的额外支持的示例，以减少SQL代码编写阶段的错误风险
在第一种情况（如果我们成功找到合适的示例），文档检索阶段可能会被跳过，因为生成SQL所需的所有必要信息已经在提取的示例中。第二阶段应该执行文档检索程序作为生成SQL的主要信息来源。
img-6.jpeg

具有渐进阈值的示例检索流程。

I. 寻找确切的示例
因此，我们首先尝试在知识数据库中找到已经回答的确切问题。为此，期望非常高的相似性- 在极限情况下，这一步等于用户请求与知识库中问题的直接匹配。这里的想法是，如果我们已经回答了这个问题，就避免额外的计算 - 我们可以直接返回存储的SQL示例作为答案。

其中

  • 用户请求的初始表示
  • 生成的SQL查询

II. 基于规范化表示的搜索
下一步是尝试找到由几个视角描述的类似问题的示例 - 规范化表示和主子句。为此，我们需要将用户的请求转换为规范化形式，并按照模型训练期间使用的相同过程提取主子句。

由于规范化的问题受“规范化问题规则”的制约（参见示例规范化和结构化），我们可以预期即使不同问题在具体细节或写作风格上有所不同，只要它们从一般角度看传达相同的含义，不同问题的规范化版本之间会有很高的相似性。

下面的箱形图说明了这个概念。这些图表显示了规范化问题之间的成对距离分布。这些图表比较了相同示例内的最近邻（组内）和不同示例之间的最近邻（组间）的距离（对于左边的全动态范围，右边限制为）。
img-7.jpeg

规范化问题之间的成对距离分布（全范围）。
img-8.jpeg

规范化问题之间的成对距离分布（限制为0.05）。

同一示例内的最近邻（不同示例之间）指的是基于余弦相似性，属于同一问题答案示例或不同问题答案示例的最接近匹配问题。给定一个由多个问题表示组成的示例，同一示例内的最近邻定义为：

其中

  • 表示两个问题嵌入之间的成对余弦距离
    对于组内情况：

•

  • 是同一示例的不同表示
    •
    最近邻是在同一示例组中最接近的那个。
    对于组间情况：
    •
    和其中（问题来自不同的组）。
    •
    最近邻仅从不同的组中选择。
    在这个阶段，我们考虑的是原问题及其替代方案的规范化表示，例如措辞的变化或细微的细节，但具有相同的潜在含义 -和。
    关于问题的规范化表示，小于的余弦距离
    ，其中- 归一化问题组的组间距离，在我们的嵌入模型中，能够检测语义上等价的问题，同时降低误识别的风险。因此，通过设置相似度阈值为
    percentile，其中- 归一化问题组的组间相似度，对于用户问题的规范化形式，我们确保用户请求在保存的示例中得到正确定位。检索到的示例可以作为生成正确SQL代码的模板，无需将文档包含在上下文中，因为它已经包含了所有必要的逻辑，只是在时间范围、地理位置等方面有细微差别。
    ，其中

其中

  • 检索示例中所有表的全文描述
  • 与规范化问题完美匹配的检索示例中的SQL查询集合

III. 基于规范化表示和主子句的搜索
如果没有把握确定知识库中的示例直接匹配用户的请求，我们需要通过降低相似性阈值并将问题的主子句作为搜索引擎（向量数据库）的额外输入来扩大搜索空间。下表展示了在同一示例内最近邻之间的归一化问题及其主子句的组内和组间相似性分布——和，基于训练数据集中的示例构建。

百分位数
组内
0.99
0.99
0.98
0.98
0.95
0.95
0.94
0.93
组间
0.95
0.95
0.93
0.91
0.88
0.86
0.84
0.83
为了最大化精度同时保持适度的召回率，我们将相似性阈值设定为：

其中：
表示归一化问题组的组间相似性，通过主子句扩展。
组间相似性的为，意味着的组间距离低于此阈值。

通过应用阈值（归一化问题组的组间相似性的百分位数）而不是（归一化问题的组内相似性的百分位数），我们确保检索到的示例与用户的请求密切相关，从而有效减少假阳性并提高精度。由于只有的组间示例的相似性高于，检索错误示例的风险是最小的。然而，在这种情况下，我们还需要考虑表描述作为附加信息来源，因为示例本身可能并不总是包含特定请求的属性。
，其中

其中

  • 与规范化问题充分匹配的检索示例中的SQL查询集合

IV. 基于扩展的问题表示集的搜索
如果我们无法找到满足相似性要求的示例，我们需要降低相似性阈值以扩展搜索空间（增加召回率）。为了实现这一点，我们必须考虑完整的成对相似性集合（包括组内和组间）而不限制于最近邻：

其中:
表示完整的成对相似性集合，涵盖组内和组间的距离。
是所有示例的完整集合。
是不同的问题，意味着集合包括来自相同和不同组的距离。
是两个问题之间的余弦相似性

  • 集合包括归一化问题、主子句、实体和初始问题分别对应于示例

因为我们想要最大化相关示例的覆盖率，我们可以将相似性阈值设为
通过应用这个阈值，我们增加了检索到与用户请求相关的示例的概率，因为只有的组内示例的相似性分数低于定义的阈值。然而，这会以降低精度为代价。
，其中

其中

  • 应该用作代码模板示例的检索示例中的SQL查询集合

观察组内和组间相似性的分布，我们注意到检索到的示例集合中有的可能性包含错误匹配。

百分位数
组内
0.99
0.97
0.96
0.95
0.93
0.90
0.87
0.84
百分位数
:–
:–:
:–:
:–:
:–:
:–:
:–:
:–:
:–:
:–:
组间
0.98
0.88
0.86
0.78
0.76
0.74
0.72
0.70
这意味着，虽然检索到的示例集合包含相关信息，但它也具有高水平的噪声。因此，需要额外的步骤来检查提取的问题-代码代表的相关性，并过滤掉高度不相关的条目。

V. 重新排序
为此，我们应用了一个在Quora重复问题数据集上训练的交叉编码器模型。这种方法允许我们直接评估伴随提取示例的问题与用户请求之间的语义相似性，由于交叉编码器能够共同处理这两个输入，捕捉更深层次的上下文关系，从而提供更准确的相关性排名。Quora重复问题数据集专门设计用于同义句识别，因此交叉编码器模型能够识别两个问题是否具有相同的含义，尽管措辞不同。这正好服务于我们的目标——检测与用户请求语义相似的示例，忽略词汇和风格的变化。
getRank

其中

  • 与规范化问题充分匹配的检索示例中的SQL查询集合
  • 重新排序阈值
    如果我们成功找到了输入请求的有关示例，我们将它们放入SQL代码生成的上下文中，并预先附上相关的表描述。否则，我们需要采用代码示例和对应的表并继续检索相关表的文档。

检索相关表的文档
检索过程的检索相关表文档阶段分为两个步骤，以识别生成SQL查询的最相关表。首先，我们使用内容相似性将用户的查询与表描述和元数据进行匹配。然后，我们应用业务规则来细化这些结果。内容相似性方法在下面描述，分析用户的查询的不同版本，以找到最可能包含所需信息的表。该过程的总体架构如下面的图所示（“文档检索过程流程图”）。

I. 通过内容相似性搜索表文档
在此阶段，我们尝试通过搜索知识库（文档集合）来识别与用户请求相关的表，同时考虑到文档的元数据——该过程旨在通过查询元数据类别（如描述、实体、连接的表和表名）来涵盖数据库表的不同视角。此过程包括围绕用户查询的不同表示进行搜索，包括其规范化表示、主子句和提取的概念。通过使用这种方法，我们确保了相关表的全面检索，同时最大限度地减少了遗漏条目。
img-9.jpeg

文档检索过程流程。
为了检测与用户请求匹配并在SQL代码生成阶段可能使用的表，我们执行多个查询，使用用户请求的不同表示形式。每个查询公式如下：

其中：
是从以下来源之一派生的查询文本：主子句，规范化问题，提取的概念
是应用于元数据类别的过滤条件，它限制了搜索空间。
是每次查询检索的结果数量。
查询参数集定义为：

其中每个查询应用不同的过滤器：

1
匹配描述 & 实体与规范化问题和主子句
2
匹配连接的表 & 实体与提取的概念
3
匹配表名与所有这些类别
对于每个查询，我们从文档集合中进行检索：

其中表示检索到的元数据条目集。最终的检索集是所有查询结果的并集：

每个检索到的条目包括元数据字段：表名, 依赖关系, 连接的表

我们构建了检索数据的结构化表示：

为了确保唯一性，我们删除重复的表示：

然后将每个唯一的元数据表示转换为结构化的文档条目：

最终的表集通过合并所有文档条目获得：

最后，表示检测到的表集，确保所有相关表名及其关系都被正确识别。

在当前的实现中，我们设置，平均检索到约30个带有表描述的独特文档（对应30个独特表）。这确保了广泛的覆盖范围，考虑到典型的SQL查询涉及4到5个相关表，同时保持计算效率。检索过程的目标是最大化召回率（包含相关表）并同时减少噪声水平，确保后续步骤在经过良好整理的候选表集上运行。
img-10.jpeg

img-10.jpeg
Rand指数与检索到的唯一表数之间的关系。
基于训练数据的检索结果的经验分析提供了关于检索表分布及其重叠程度的见解。根据结果，唯一表的数量范围在23到40之间，平均每查询约30个表。这种变化证明了搜索策略适应不同查询结构和元数据分布的能力，确保候选集既多样又不过于冗长。
这一陈述反映在散点图中，该图描绘了Rand指数与检索到的唯一表数之间的关系。

通过Rand指数测量的检索集之间的适度重叠为0.36，表明不同的查询公式带来了新的相关表，同时仍然有一些共同的结果。这种平衡表明搜索策略是有效和可靠的，使用多种查询方法捕捉更多相关表而不过度重复。结果证实检索过程保持了多样性和一致性之间的良好平衡，确保重要表被包含在内，同时保持搜索效率。

II. 基于业务规则的表格文档检索
除了全自动的表格文档检索外，我们还结合领域知识来优化相关表格的选择。此过程考虑业务规则，这些规则定义了约束、依赖关系和条件，以确保表格选择符合组织需求。尽管表格描述提供了基础理解，但它们可能不会总是明确捕捉数据元素和业务特定术语之间的关系。措辞的变化、领域特定概念和隐含假设进一步导致表格选择中的潜在歧义。

为了解决这个问题，我们通过LLM查询进行表格检测，其结构如下：

其中：
表示基于业务规则选择的优化表格集
表示规范化的用户问题。
表示适用于表格选择的一组业务规则。
在此步骤之后，我们通过扩展表格候选列表到SQL代码编写步骤：

改进搜索结果
改进表格选择是通过使用LLM结合领域特定指令、业务规则和结构化元数据来提高检索准确性的过程。此过程保证表格选择与业务逻辑和数据库结构相对应，解决歧义，并确保所有表格的覆盖。

改进阶段基于以下两个方面的结果：

1
检索相关表的文档：从文档中基于元数据检索候选表。
2
检索适当的示例：检索引用类似SQL示例中的表。
初始检索在这两个阶段中分别进行，因此需要使用推理来组合、验证和改进选择，以保留最相关的表。
I. 基于LLM的表格改进
表格改进提示将LLM的推理结构化为系统的逐步分析，确保逻辑一致性和表格选择的明确理由：
, Instr_Domain,
其中：

  • 是模型选择的最终改进表集合。
  • 用户请求的规范化表示
    Instr_Domain - 领域特定映射指令
  • 业务规则
  • 在文档检索阶段获得的候选表及其描述
  • 在示例检索阶段获得的候选表及其描述

II. 改进过程与LLM推理
•
表格覆盖分析：
•
模型回顾表格描述，以确定特定情况数据放置的位置。
•
进行详细的列分析，以确定所需特征是否存在。

  • 综合表格覆盖
    •
    模型选择所有可能包含所需信息的表，尽管这些问题可能没有直接在问题中提到。
    •
    它还考虑了链接或依赖的表，这些表可能需要获得数据的完整视图。
  • 整合业务逻辑和上下文
    •
    领域特定规则直接整合到推理过程中，以改进表选择。

•
模型的决策过程与业务目标一致。因此，它会选择与需要实现的分析或操作目标相关的表。
通过结合前两个阶段的结果，这种方法保证了最终改进的表选择：

•
综合的 - 包括元数据描述和实际查询使用

•
上下文准确 - 理解领域特定映射和业务约束

•
优化SQL生成 - 确保检索到正确的数据，并准备并与用户的需求一致。
此改进过程提高了自动查询生成中表选择的精度和可靠性。此阶段的结果是一个元组- 在检索适当示例阶段接收的SQL查询示例，这对SQL编写程序具有推荐性质，以及改进的表集合及其描述。

结论
知识库的检索过程旨在获取与用户请求相关的示例和表文档，这是生成SQL查询过程所必需的。借助基于向量的相似性搜索，系统能够通过重新排序技术和业务规则驱动的改进，有效地检索相关的SQL查询示例及其关联的表文档。
文档中描述的多步骤方法允许在不损害表选择低错误率的情况下优化精度，从而确保结果与数据库结构和领域要求一致。基于改进的表集合和检索到的SQL示例提取的上下文，在查询生成过程中至关重要，因为它为整个过程的准确性、效率和上下文一致性提供了基础。

SQL代码生成
SQL代码生成是Text2SQL管道的最后一步，其中结构化查询信息被转换为可执行的SQL语句。生成过程依赖于先前检索到的SQL示例和表描述，这些示例和描述指导模型选择最相关的操作、过滤器和表连接。

根据检索到的数据分析，SQL代码可以通过以下方式进行生成：

  1. 直接输出SQL代码
    •
  • 一个完全形成的SQL查询，可以执行而无需进一步修改。
  1. 精确示例生成
    •
  • 一组完美匹配用户请求的SQL查询示例。
    •
    这些示例直接用于构建查询。
    •
    来自的表描述作为支持上下文。
  1. 强烈对齐的示例生成
    •
  • 一组紧密匹配用户请求的SQL查询示例。
    •
    最终的SQL查询受到这些示例的强烈影响，但表选择和结构同样取决于。
  1. 灵活模板生成
    •
  • 一组部分相似于用户请求的SQL查询示例。
    •
    这些示例作为非强制性参考模板，而表选择则遵循知识库分析得出的更广泛的改进表集合。
    基于LLM的SQL代码生成过程
    SQL代码生成遵循结构化的多步骤方法，其中LLM使用检索到的示例和结构化表描述合成SQL查询。该过程形式化为：

其中：

  • 规范化的用户查询。
  • 相关表描述的集合。
  • 检索到的SQL示例的集合。
    根据输入数据，有两种生成SQL代码的方法

I. 示例驱动的SQL生成
•
主要重点：
•
利用与用户问题相关的先前SQL查询示例或
•
使用表信息作为支持上下文，但主要依赖于示例中的模式。
•
关键步骤：
1
分析相关SQL示例以提取查询模式。
2
检查文档建议并应用直接见解。
3
确保正确处理表依赖关系。
4
最小化最终查询中包含的表数量。
•
约束：
•
不得引入额外的操作，除非问题明确要求。
•
必须严格遵守提供的模式。
II. 文档驱动的SQL生成
•
主要重点：
•
使用来自文档的表描述作为主要来源。
•
仅将SQL示例作为次要参考，确保与提供的数据集一致。
•
关键步骤：
1
从文档中识别相关表，确保正确选择表。
2
验证表依赖关系并根据关系构造有效连接。
3
验证表组合是否满足用户请求。
4
分析相关SQL示例以优化查询结构。
5
最小化不必要的表使用以优化性能。
•
约束：
•
必须仅使用提供数据集中的表，即使SQL示例包含额外的表。
•
必须严格遵守表关系和依赖规则。
•
必须始终遵守模式约束。
结论
SQL代码生成通过利用检索到的示例和表文档构造准确的查询。系统根据相关性动态选择示例驱动和文档驱动的方法，确保与用户意图和数据库模式一致。通过严格遵循表关系、依赖关系和约束，这种方法确保了强大、高效且可靠的SQL，且错误最少。

结论
本文档中提出的Text2SQL系统建立了一种综合性方法，通过使用增强生成（RAG）将自然语言查询转换为正确的SQL代码。通过整合数据库知识、查询示例和领域特定规则，该系统处理了数据库复杂性和语言细微差别的挑战。

关键架构组件
该系统结合了三个基本要素来生成准确的SQL：

1
来自数据库文档、查询示例和业务规则的全面知识库。这些知识以向量嵌入的形式存储，捕捉概念之间的关系。
2
智能检索方法根据需要调整相似性阈值，考虑用户的多种问题变体，并应用业务规则选择正确的表。
3
自适应的SQL生成方法基于检索到的示例质量，可以通过密切跟随示例或在必要时从文档构建查询来完成。
实际应用和优势
这种方法解决了一个根本性问题——允许非技术人员通过简单的问题访问数据库洞察。通过结合结构化数据库知识和灵活的语言理解，该系统在保持准确性的同时对所有人开放。基于示例的方法意味着系统随着时间的推移会随着更多成功查询的添加而改进。组织可以通过添加自定义业务、规则和示例来适应特定领域的系统。

方法论重点和局限性
本文提出了基于增强生成的Text2SQL翻译方法的框架和方法论。尽管我们详细解释了模型架构和方法，但本文并没有提供与现有Text2SQL基准或系统的任何数值比较。这项工作的重点在于架构设计、知识表示方法和检索方法，而不是基准测试系统性能。

我们专注于方法论的原因是最初的要求是在特定的组织环境中开发一个系统，该环境具有专有数据库和定制的业务规则，这些规则与公共基准测试没有直接对应关系。我们认为所描述的方法对实施类似系统的从业者提供了宝贵的见解，即使没有标准化的性能指标也是如此。

未来的工作
未来的发展应包括在公开可用的基准上进行实证评估，以量化相对于现有方法的性能。额外的研究可以集中在优化提取过程以提高效率、扩展支持的SQL结构范围以及开发自动化提取领域特定规则的方法。我们也看到了适应此框架以支持多轮交互的潜力，用户可以通过对话完善他们的查询。

参考论文：https://arxiv.org/pdf/2506.12234

文档更新时间: 2025-06-27 09:14   作者：admin