Text-to-SQL最新综述：一篇文章讲透任务方法和未来10个发展方向

2022-09-30 10:09

©PaperWeekly 原创 · 作者 | 殷智超

学校 | 中国科学技术大学硕士

研究方向 | 自然语言处理

表格是当前存储大型结构化数据的主流方式，虽然可以通过设计 SQL 查询来有效访问表格数据，但是提供自然语言形式的查询接口可以使更广泛的用户能够利用这些庞大的关系型数据。因此，text-to-SQL 的解析任务旨在将自然语言描述的问题转换为机器可以执行的 SQL 语句。这可以让普通用户也可以轻松的查询表格。

在这篇论文中，来自阿里巴巴达摩院、中科院的几位研究者对自然语言处理中 text-to-SQL 领域的 100 多篇论文进行了全面回顾。作者旨在全面回顾 text-to-SQL 解析任务，对当前具有代表性的 text-to-SQL 方法进行分类，然后介绍当前 text-to-SQL 面临的挑战并探索该领域未来的潜在方向。

论文标题：

A Survey on Text-to-SQL Parsing: Concepts, Methods, and Future Directions

论文作者：

Bowen Qin, Binyuan Hui, Lihan Wang, Min Yang, Jinyang Li, Binhua Li, Ruiying Geng, Rongyu Cao, Jian, Sun, Luo Si, Fei Huang, Yongbin Li

论文链接：

https://arxiv.org/abs/2208.13629

引言

早期由数据库社区展开的 text-to-SQL 相关工作需要通过大量人工和用户交互，而近年来随着深度学习的发展和大规模开源数据的公布，由神经生成式模型构建的 text-to-SQL 模型得到了迅速发展。

典型的神经生成式方法通过 Seq2Seq 模型来自动建模输入的自然语言问题和输出的 SQL 语句间的映射关系，其关键思想为构建一个编码器来理解数据库表格模式和输入的自然语言问题，然后再通过一个解码器来预测目标 SQL 语句。Seq2Seq 方式由于其端对端的建模特性以及对领域知识的弱依赖，成为了 text-to-SQL 任务的主流方法。到目前为止，已有大量不同的神经生成式模型被提出并分别应用于编码器和解码器。

主流方法

通常，text-to-SQL 可以分为单轮（上下文无关）和多轮（上下文相关）两类。在单轮 text-to-SQL 解析中，我们需要生成指定数据库模式和自然语言问题对应的 SQL 查询。而在多轮解析中，则要将一系列的自然语言问题转换为相应的 SQL 查询，其中问题内还可能包含省略和回指，即当前问题可能涉及到先前问题中的某些项。

▲ 图1 全面概述text-to-SQL解析数据集、预训练表格语言模型、下游text-to-SQL的解析方法。

2.1 单轮解析方法

2.1.1 编码器

编码器的第一个目标是学习自然语言问题和表模式的联合表示，第二个目标是建模结构信息，因此 text-to-SQL 任务是一个高度结构的任务。

2.1.1.1 输入的联合表示

基于 LSTM 的方法：通过 LSTM 学习自然语言问题和数据库模式的上下文表示，然后传递给解码器进行解码并生成对应的 SQL 查询。一种方式是采用双向 LSTM 来学习自然语言问题与表格列名拼接后的序列的语义表示。另一种方式是使用两个双向 LSTM 编码器分别对自然语言问题和表模式进行编码，并且两个双向 LSTM 编码器将词和对应的模式链接类型作为输入，其中模式链接类型通过 n-gram 匹配获得，以识别自然语言问题中提到的表和列名。

基于 transformer 的方法：由于 transformer 已经在多个 NLP 任务上取得了不错结果，因此，在 text-to-SQL 任务中也有很多方法采用了 transformer 架构。

通常基于 transformer 的方法都采用了以下三个步骤：首先将自然语言问题和模式拼接作为编码器的输入，并加上 [CLS] 和 [SEP] 两类特殊 token。然后，将预训练语言模型如 BERT 或 RoBERTa 最后一层输出的隐藏状态作为问题的上下文表示，而对于每个表格模式，将其前方的 [SEP] token 位置所对应输出的隐藏状态作为其表示。最后在预训练语言模型基础上添加不同架构来增强编码器的表示能力。一种架构是在 BERT 模型上添加了两层双向 LSTM，另外一种则在双向 LSTM 上添加额外的注意力层来获取更优表示。

2.1.1.2 结构建模

大型跨域 text-to-SQL 数据集要求模型能够处理没有见过的数据库模式，同时每个自然语言问题对应着多表的数据库模式，而训练和测试集不共享重叠的数据库。这个挑战要求 text-to-SQL 解析器要能够从连接结构（linking structure）、模式结构（schema structure）、问题结构（question structure）三个方面来增强表示能力。

连接结构：如图 2 所示，连接结构旨在识别自然语言问题中对表格、列以及条件的引用。text-to-SQL 解析器需要捕获自然语言问题中所涉及的表、列等信息，而这些信息将被用来辅助生成 SQL。模式链接能够提升跨域泛化和复杂 SQL 的生成能力，而这两点也是当前 text-to-SQL 的瓶颈。

传统的模式链接方法通过规则或字符串匹配来提取，但无法捕获自然语言问题和表模式之间的综合语义关系。最近基于图的连接方法可以对问题词汇和模式实体进行推理，并对复杂输入表示进行建模。通过将问题 token 和模式项视为多类型的节点，并预定义节点间的结构关系（边），来表达不同的模式内关系、问题模式关系和问题内关系，relation-aware 的注意力机制常被用在图表示学习中来提升对图的全局推理能力。此外，一些工作致力于解决异构图的编码问题。通过考虑节点之间的连接和有向边的拓扑可以使信息传播更有效。

▲ 图2 连接结构的例子

模式结构：模型需要编码例如主键（primary key），外键（foreign key），以及列的类型等等表格模式的结构信息。主流的方法通过图神经网络（GNN）对关系数据库中的关系进行建模，将节点信息传播到其相邻节点。基于 GNN 的方法有助于聚集相邻节点的特征信息，使得获得的输入表示更强大。

问题结构：模型同时还需要理解句子的结构信息。比如句子中存在的问题序列的依赖结构和上下文结构依赖。

2.1.2 解码器

Text-to-SQL 解码器大致上可以分为两种：基于 sketch 的方法和基于生成的方法。

2.1.2.1 基于sketch的方法

基于 sketch 的方法将 SQL 生成过程分解若干个子模块，例如 SELECT-COLUMN、AGG 函数和 WHERE-VALUE 等等。SELECT、WHERE 和 AND 这些字符对应着 SQL 关键字，而后续的成分则表示要填充的预测槽的类型。例如，AGG 槽需要填充空字符或聚合运算符之一（如 SUM 和 MAX）；值槽需要填充问题的某个子字符串；列槽需要填充列名；OP 槽需要填充操作，如 >、<、=）。这些槽稍后被一起用来生成最终的 SQL。每个槽都有单独的模型，模型之间不共享可训练参数，并负责独立预测最终 SQL 的一部分。

基于 sketch 的方法通常比较快速并能够符合正确的 SQL语法规则。但这些方法很难处理复杂的 SQL语句，如多表连接、嵌套查询等。因此，基于 sketch 的方法在 WikiSQL 数据集上很流行，但很难应用于涉及复杂 SQL 的 Spider 数据集。

2.1.2.2 基于生成的方法

基于生成的方法通过 Seq2Seq 模型来解码 SQL，相比基于 sketch 的方法更适合复杂的 SQL 场景。例如一些工作使用基于 LSTM 的指针生成器（pointer generator），结合多头注意力机制和复制机制（copy mechanism）得到解码器。然而基于生成的方法可能无法生成语法正确的 SQL 查询，因此一些方法以深度优先遍历顺序将 SQL 生成为抽象语法树（AST）。

特别地，这些方法使用 LSTM 解码器来执行一系列三种类型的动作，这些动作要么将最后生成的节点扩展为语法规则（APPLY-RULE），要么在完成叶节点时从模式中选择列（SELECT-COLUMN）和表（SELECT-TABLE）。这些操作可以构造目标 SQL 的相应 AST。

还有一些方法在解码过程中忽略了 SQL 语法，利用大规模预训练语言模型如 T5，在 text-to-SQL 训练集上进行了微调然后生成 SQL 查询。在某些情况下，虽然最优 SQL 在 beam search 的候选列表中，但不在顶部。因此，某些工作引入了一种判别式重排序（re-Ranking）策略，从 text-to-SQL 解析器预测的候选列表中提取最佳 SQL 查询。还有一些研究引入了领域特定语言（DSL），作为连接问题和 SQL 查询的中间表示。

这些方法表明，当生成的 SQL 被处理为树形结构形式时，自然语言表达的意图与 SQL 中的实现细节之间总存在不匹配。因此，DSL 的关键思想为省略中间表示的实现细节。此外，还有的工作提出了一种受约束的解码策略，能够使解析器在每一步解码中判别不允许生成的字符来识别有效的目标序列。

2.2 多轮解析方法

相比与单轮 text-to-SQL 解析，多轮 text-to-SQL 解析需要更充分地利用上下文信息。

▲ 图3 多轮问题的不同上下文编码方法

2.2.1 解码器

2.2.1.1 输入联合表示

多轮表示学习主要集中于两个问题：

（i）如何学习高质量的上下文问题和模式表示；

（ii）如何有效地编码历史 SQL 查询。

图 3 描述了对多轮 text-to-SQL 解析的不同上下文编码方法，包括（a）将所有问题作为输入，（b）使用回合制的编码器处理每个问题，（c）通过门机制平衡每个历史问题的重要性。

通常，多轮问题之间的关系由注意力机制捕获。首先在当前回合计算当前问题和先前问题之间的点积注意力，然后将先前问题的加权平均后的表示加到当前问题表示上，以形成上下文感知的问题表示。有些工作通过学习一个控制器来维护保存连续问题累积意义的上下文存储器，并使用外部的存储机制（external memory）来表示上下文信息。

另外，有些研究将多轮 text-to-SQL 解析分解为两个流水线任务：问题重写和单轮 text-to-SQL 解析。问题重写（QR: Query Rewriting）的目标是基于最新的问题和对话历史生成简化表达。单轮 text-to-SQL 解析使用 QR 模块生成的简化表达式预测相应的 SQL 查询。同样可以将 SQL 查询的逻辑形式视为自然语言问题的另一种模态，并使用额外的 SQL 编码器捕获 SQL 查询和自然语言问题之间的语义连接。

2.2.1.2 多轮结构建模

和单轮问题不同，多轮 text-to-SQL 问题需要将上下文的归纳偏置注入到结构建模中。

连接结构：R2SQL 关注上下文连接结构的唯一性，引入了一种新的动态图框架，有效地建模上下文问题、数据库模式以及它们之间的复杂连接结构，并通过衰减机制来减轻历史连接对当前回合的影响。

模式结构：EditSQL 通过利用先前预测的 SQL，来使用会话历史并提高生成质量。它侧重于利用以前的问题文本和以前预测的 SQL 查询来预测当前回合的 SQL 查询。具体地说，前一个问题首先被编码成一系列 token，然后解码器预测一个开关（switch）来决定是否要对 token 进行修改。这种序列编辑方法可以实现 token 级别的更改，因此可以防止错误传播。

IGSQL 指出，它不仅应该考虑用户的历史输入和先前预测的 SQL 查询，还需要考虑数据库的历史信息。因此，IGSQL 提出了一种数据库模式交互图编码器，用于将数据库模式项与历史项一起学习，从而使上下文相关的 text-to-SQL 解析能够保持上下文一致性。跨越多轮问题的模式交互图层和每轮内的模式图层分别使用前一轮和当前轮来更新模式项的表示。在 IST-SQL 中，通过定义、跟踪和利用交互状态对多轮 text-to-SQL 进行解析，其中每个交互状态都基于先前预测的 SQL 查询的状态进行更新。

2.2.2 解码器

在多轮背景下，大多数方法采用了带有注意力机制的 LSTM 解码器，这能够更好的利用历史问题、当前问题和表格模式的信息。解码器将当前问题、SQL 状态、模式状态和最后预测的 SQL 查询的编码表示作为输入，并在解码过程中使用查询编辑机制来编辑先前生成的 SQL 查询，同时合并自然语言问题和数据库模式的上下文。通过单独的层预测 SQL 关键字、表名和问题token，这可以减轻词汇表中的 token 和 SQL 查询可能完全不相关带来的问题。解码器最后一般通过 softmax 来输出概率分布。

预训练

使用 PLM 可以提升 text-to-SQL 的解析能力，然而表格数据和普通文本之间的分布不同常导致最终的结果是次优的，通过构建表格预训练模型可以缓解这个问题。

3.1 输入编码

3.1.1 文本数据编码

文本编码可以分为动态编码和静态编码。一些方法采用 GloVe 可以在没有上下文的情况下查找字典来初始化每个输入项的词嵌入。静态方法的缺点是其不能解决多义问题。此外，特征还受到预定义窗口大小的限制。预训练模型也可以用来编码文本数据。如一些工作通过 BERT 来获得上下文化的表示，同时 BERT 的参数随着训练过程而更新。

3.1.2 表格数据编码

表格数据通常是二维结构。表格预训练方法需要先将二维表格数据转换为一维序列，然后输入到语言模型中。一种常见的串行化方法是将表格数据逐行展开为一系列 token，然后在表的 token 前拼接问题 token 作为输入。也有一些研究仅将表格标题作为输入，而不考虑数据单元。

虽然 NLP 模型通常将一维序列作为输入，但位置编码对于表格数据至关重要，模型可以根据位置信息更好地捕获结构信息。大多数预训练方法都探索了扁平表格序列的全局位置编码策略。然而，除了一维顺序位置之外，表还具有由二维结构以及层次化信息。一些工作通过基于列或行的 ID 来对行和列进行编码。另外可以考虑两个单元格是否在同一列或行以及列标题中，而不是考虑表中列和行的绝对顺序信息。

3.2 预训练目标

预训练目标可分为五个主要类别：MLM、模式链接、SQL 执行器、SQL 生成和上下文建模。

3.2.1 MLM

MLM 可分为三个主要类别：重建遮掩的语句、表头或单元格值，以及从遮掩的语句和表中恢复原始输入。大多数使用 MLM 作为预训练目标的 PLM 都是通过从语句或表格标题中随机掩蔽部分输入 token，然后预测被掩蔽的部分，并通过最小化交叉熵损失来计算 MLM 损失。此外，一些工作还提出了掩蔽列预测和单元值恢复来学习表的列表示以及列恢复目标（根据采样的单元值预测其对应列名）。

3.2.2 模式链接

模式链接是 text-to-SQL 解析中的关键部分，它学习自然语言问题和给定表之间的对齐关系，特别是识别问题中对列、表和条件值的引用。这对于复杂的 SQL 生成和跨域泛化尤其重要，因为 text-to-SQL 解析器应该知道问题中涉及哪些表和列，即使在引用来自任意域的表建模自然语言问题和 SQL 查询间的复杂语义依赖关系时也是如此。

通过设置预训练目标可以使模型学习自然语言问题和表格间的相关性来建模模式链接信息。一些工作提出 SQL 语义预测目标，即预测 SQL 查询中是否出现某个列名，以及根据问题和给定的表头需要触发哪种 SQL 操作。SQL 语义预测可以通过将 SQL 序列标记转换为每个列上的操作分类来实现。

3.2.3 SQL执行器

TAPEX 提出 SQL 执行器目标，通过预训练模型来模拟表上的 SQL 执行器，也就是学习一个 SQL 执行器来执行 SQL 查询并输出相应的正确结果，这需要模型对 SQL 查询和表有深入的理解。

3.2.4 SQL生成

GAP 提出 SQL 生成的预训练目标，通过在适当的位置生成特定的 SQL 关键字或列名，而不仅仅是预测是否提到列。

3.2.5 上下文切换

上述预训练没有考虑上下文相关的交互，导致上下文相关的 text-to-SQL 解析只能得到次优效果。SCORE 是上下文相关 text-to-SQL 解析的第一个代表性预训练方法。SCORE 设计了一个轮上下文切换（TCS）目标，通过预测两个连续的用户对话间的上下文切换标签（来自 26 个可能的操作）来建模上下文流。

未来展望

4.1 高质量数据集

当前 text-to-SQL 任务上的数据集受到规模、质量、多样性多个方面的限制。尽管可以通过基于规则的方式生成大量数据，但通常质量较差，同时缺乏多样性。因此，构建大规模、多领域以及高质量的数据集仍然是未来的重要方向。

4.2 大规模的数据库和表格

由于神经 text-to-SQL 模型的输入长度限制，当前语料库中使用的表格规模通常少于十行/列。但实际应用中通常涉及到数千行/列，这对现有模型是一个巨大挑战。特别当涉及的表的数量或大小变得太大时，对表模式的编码以及从大型表中检索合适的知识都将会变得更加困难。因此，未来还需要继续开发更有效的模型来对序列更长的表格模式进行编码，以及提高涉及大型数据库时的 SQL 生成效率。

4.3 结构化表格数据的编码

表格数据通常是二维结构，而大多数 text-to-SQL 解析方法都将二维表格数据转换为线性化的一维序列，这样的处理方式将会丢失表格的结构信息。因此，如何对二维表格的结构信息进行有效编码来提升 SQL 的生成能力也是一个重要挑战。

4.4 异构信息建模

现实应用中通常包含很多异构信息如图片，而只使用一种类型的信息显然很难满足各种应用的需要。因此，处理多模态数据以及整合不同结构的信息源也非常重要。

4.5 跨领域的text-to-SQL解析

当前大多数方法只能处理某个领域的解析任务。虽然有 Spider、DK 等跨领域大规模数据集，但还没有方法能够处理 OOD（out of distribution）的生成问题。有监督学习方法很难处理与训练数据分布不同的数据，因此如何有效处理 OOD 的生成问题无论对学术界还是工业界都是一个很有前景的方向。

4.6 Text-to-SQL模型的鲁棒性

Text-to-SQL 模型的鲁棒性是非常重要的话题，尤其当应用到现实环境中。一些研究发现即使是细微扰动都会严重影响到模型的性能。然而，当前在提高 text-to-SQL 模型鲁棒性方面的探索还很少。

4.7 Zero-shot和Few-shot下的text-to-SQL解析

预训练然后在下游继续微调已成为 text-to-SQL 领域的经典范式。然而，在处理下游任务时这些模型还需要大规模的有标签数据，因此在 zero-shot 情况下通常表现不佳。一种方法是使用预训练语言模型，通过 PLM 可以在 zero-shot 情况下不经过微调也能很好的迁移到下游 text-to-SQL 解析任务。因此，如何提高模型在 zero-shot 和 few-shot 场景下的性能也是重要的研究方向。

4.8 上下文依赖的text-to-SQL解析预训练

大多数现有的表格预训练模型只对独立的文本内容建模，而不考虑上下文相关的交互，因此常常只能得到次优性能。因此如何充分利用上下文信息来丰富问题和数据库模式的表示还需要进一步研究。

4.9 text-to-SQL模型的可解释性

神经网络模型在 text-to-SQL 解析任务上取得了 sota 结果，但缺乏可解释性。而对于金融、医疗等敏感领域，可解释性则尤为重要。因此，如何结合深度神经网络的表示能力以及符号方法的显示推理能力是一个值得探索的领域。

4.10 数据隐私问题

由于用户数据的敏感性，数据隐私保护也是一项重要并具有挑战性的任务。由于大多数 text-to-SQL 解析模型需要从大规模语料库和相关数据库模式中识别模式和关系，并将所有信息收集到一个中心站点进行学习，而不同数据库模式间的关系或模式可能由不同组织管理，因此数据隐私问题对于构建集中式架构的神经模型是一个重要问题。如何有效地将问题以及数据库模式的表示转换为本地的私有化表示，然后再上传给服务提供商使用也是一个很有前景的探索方向。