论文解读 | A survey on deep learning approaches for text-to-SQL

歧义性：包括词汇歧义、句法歧义、语义歧义和上下文相关歧义。

释义：自然语言中不同表达方式可能表示相同意思，这对系统理解用户意图提出挑战，同时也涉及同义词问题。

推理：系统需根据上下文推断查询中缺失的信息，包括省略部分和后续问题。

用户错误：用户在输入查询时可能出现拼写错误、句法或语法错误，这些错误使得系统更难准确翻译查询，因为系统需要尝试纠正错误或在错误存在的情况下理解用户的真实意图。

SQL语法：SQL具有严格的语法规则，其表达能力相对自然语言有限。有些在自然语言中容易表达的查询，转换为SQL时可能变得复杂。此外，自然语言中的一些表述即使存在错误仍可能被人类理解，但SQL查询必须在语法和语义上完全正确才能在数据库上执行，否则将返回错误结果或无法执行。

数据库结构：用户概念模型与数据库模式可能不匹配，包括词汇差异、模式歧义、隐式连接操作和实体建模问题。

WikiSQL：大规模众包数据集，包含大量Wikipedia表和NL/SQL查询对，但SQL查询复杂度低，存在错误和歧义，可能限制模型性能。

Spider：复杂且跨领域的高质量数据集，包含多种领域的数据库和查询，广泛用于构建能生成复杂SQL查询的系统。

其他：如Spider-DK、Spider-Syn、SQUALL、KaggleDBQA等，分别关注文本到SQL问题的不同方面，可作为补充基准。

字符串匹配：将预测查询和真实查询视为简单字符串，仅当两者完全相同时认为匹配，不考虑SQL查询中部分内容可等效书写的情况，是最简单的准确性评估指标。

执行准确性：通过在数据库上执行预测查询和真实查询，比较结果是否相同来判断预测是否正确，但可能出现误报，即两个查询返回相同结果但在语义上不同。

组件匹配：旨在更细致地了解SQL查询中各部分的预测准确性，例如考虑SELECT列的准确性，即预测查询中SELECT子句的列与真实查询中相同列的比例，对于某些部分比较时需采用更复杂方法避免错误分类。

精确集匹配：考虑所有可能的组件匹配，只有当所有组件匹配都正确时，才认为预测正确。

精确集匹配无值：与精确集匹配类似，但不考虑预测查询中出现的值是否与真实查询中的值相同，简化了评估但忽略了文本到SQL问题中预测正确值的挑战，在Spider数据集中常用。

子树元素匹配：为避免精确集匹配指标因部分正确而得零分的情况，考虑查询的SELECT、WHERE和FROM等子句，计算每个子句预测属性的F1分数，最终预测查询的PCMF1分数是所有子句F1分数的平均值，能更好地评估系统性能，尤其在大型查询中，即使部分错误也能给出相对合理的评估。

查询候选发现技术：方法包括将单个单词视为查询候选；考虑多词n - gram 作为查询候选；通过命名实体识别发现候选；ValueNet还提出改进流程生成额外值链接候选。

数据库候选发现技术：表和列名是常见来源，因数量相对少可全部作为候选；值可通过查找数据库存储的值或知识图谱获取。

候选匹配技术：比较查询和数据库候选以确定链接，方法有精确和部分匹配、模糊/近似字符串匹配、学习嵌入、分类器以及神经注意力机制。

词嵌入：将单词映射到数值向量，早期text-to-SQL系统常用GloVe等预训练词嵌入，通过大规模文本语料训练得到，可捕捉单词关系，其向量用于构建模型。

预训练语言模型

单独的NLQ和列编码：早期系统（如Seq2SQL、SQLNet和IncSQL）常用，将NLQ和表列分别编码，原因是二者形状不匹配。编码后通过交叉串行点积注意力等方式合并，这些系统未使用额外特征，可能因它们是早期基于神经网络的文本到SQL提案，未进行模式链接且针对较简单数据集。

输入序列化：使用PLMs时常见，将所有输入序列化为单个序列后编码，简化编码过程且受益于PLMs的上下文表示能力，但会丢失模式结构信息和输入间关系。

按列编码NLQ：HydraNet采用，为每个表列构建不同输入并分别预测其在SQL查询中的相关信息，虽在WikiSQL基准上表现出色，但存在不能全面了解问题实例、难以推广到复杂数据库和复杂SQL查询、基于特定解码器难以扩展等问题。

模式图编码：用图表示数据库元素及其关系，少数系统（如GNN和Global - GNN）使用。节点表示数据库表、列或NLQ单词，边表示关系，可包含不同类节点和边以提高表达能力。

基于序列的方法：早期系统（如Seq2SQL）采用，将预测SQL或其大部分生成为单词序列，但因未考虑SQL语法规则，易产生语法错误，逐渐被弃用。

基于草图的槽填充方法：将SQL生成任务转化为预测查询特定部分的分类任务，通过填充草图中的空槽生成查询。虽能简化任务且生成语法正确的查询，但神经网络架构可能复杂，且难以扩展到复杂SQL查询。

基于语法的方法：是序列到序列方法的演进，输出语法规则序列以创建结构化查询，常用语法规则基于代码生成的抽象语法树。该方法能有效减少生成语法错误查询的可能性，适用于生成复杂SQL查询，但近期受序列方法改进的挑战，最佳解码技术仍有待探索。

从头开始训练：最常见方法，用随机初始化算法初始化所有权重并在下游任务上训练，但预训练网络和自监督学习在NLP领域的发展表明，其性能可进一步提升。

迁移学习：在NLP社区中迅速发展，通过将在其他任务和数据集上预训练的模型应用于新的下游任务，可大幅提高性能。许多系统已采用此方法，部分系统（如HydraNet）几乎完全依赖语言模型，多数系统将其作为词嵌入和RNN的替代或增强。

附加目标：受语言模型和自监督学习成功的启发，一些研究在训练文本到SQL模型时引入额外自监督任务。

无优化：部分系统不使用输出优化技术，主要考虑时间和资源可用性，如在低延迟要求或资源有限的应用场景中。但高成绩系统大多使用优化技术。

执行引导解码：帮助系统避免预测执行错误的SQL查询，适用于基于草图的系统（如HydraNet、IESQL），可提高准确性。部分系统虽原始论文未提及，但使用后在基准测试中表现更好。

约束解码：如PICARD通过增量解析和约束自回归解码器，防止生成语法或句法错误，可使基于序列的解码器有效生成SQL查询。其他系统（如SeaD和BRIDGE）也有类似解码技术。

判别式重新排序：Global - GNN 提出，通过额外网络对主文本到SQL网络的前k个预测重新排序，基于相关性提高预测质量，但此技术在实际中未被其他系统广泛采用。

特点与优势：长期以来被视为自然语言处理的常用解决方案，能够有效处理像NLQ这样的系列输入，并生成系列输出。其中，长短期记忆网络在NLP任务中较为流行，早期text-to-SQL系统（如Seq2SQL和SQLNet）常使用LSTM进行输入编码。

当前应用情况：尽管随着Transformer和预训练语言模型的兴起，RNNs在输入编码阶段的使用有所减少，但仍用于辅助PLMs进行输入编码以及生成非自然语言系列输出。

输入编码中的应用：在text-to-SQL系统中，Transformer常用于基于Transformer的预训练语言模型进行输入编码，通过创建输入文本的上下文表示来提高模型性能，使得模型表现更稳健，因此在实际应用中，常采用如BERT这样的模型替换传统输入编码器。

其他应用情况：除了输入编码，Transformers在text-to-SQL系统中还有其他应用方式。例如，HydraNet完全依赖预训练语言模型，通过调整问题表述以适应语言模型预训练逻辑，仅用简单线性网络进行预测。

Coarse2Fine：是一种语义解析器，可生成多种程序，包括SQL。其解码过程分两步，先生成目标程序的粗略草图，再填充细节。虽能分离高低层知识以便更有效学习，但仅用于WikiSQL数据集，未扩展到复杂SQL查询，实际生成的SQL查询复杂度有限。

RYANSQL：通过将SQL查询分解为多个简单子查询的非嵌套形式，递归预测子查询类型并填充草图，能够生成如Spider数据集中的复杂SQL查询，曾在Spider基准测试中取得领先，但后来被其他系统超越，且类似方法未再达到其性能水平。

SyntaxSQLNet：遵循预定义SQL语法，通过9个槽填充模块进行预测，在生成复杂查询时能确保语法正确性，属于基于草图的解码系统，但在预测时需有效传递信息，这是其面临的主要挑战。

GNN parser 和Global - GNN parser：使用图神经网络对数据库模式进行编码，将数据库模式表示为图，节点表示表和列，边表示关系，同时结合词嵌入和LSTM网络处理NLQ，解码时使用基于语法的解码器生成SQL查询。

RAT - SQL：采用关系感知Transformer架构对输入进行图表示，创建包含数据库和NLQ信息的问题上下文模式图，通过RAT网络处理节点和边信息，实现关系感知自注意力，最后使用基于语法的解码器生成SQL查询。

IRNet：是基于语法的系统，能生成复杂SQL查询，预测SemQL程序的抽象语法树，通过特定模式链接方法和输入编码方式，将生成的SemQL程序转换为SQL。

SmBoP：在解码阶段引入创新，使用关系代数作为中间语言，因其与自然语言更对齐且已被数据库引擎使用。采用自底向上的解析器解码关系代数查询的AST，与通常的自顶向下深度优先遍历方法不同，生成的中间子树在每个时间步都是有意义且可执行的子程序。

SQLova：基于草图的方法，专注于WikiSQL数据集，使用BERT创建NLQ和表标题的上下文表示，然后传递给6个负责不同查询部分的网络，与SQLNet架构相似但更复杂，使用BERT后在WikiSQL测试集上执行准确率大幅提高。

HydraNet：也是基于草图的方法，针对WikiSQL基准，利用BERT预训练模型，通过调整自身与BERT预训练方式对齐，使用简单线性网络处理BERT输出，分别处理表标题，对每个列独立预测，在WikiSQL上取得比SQLova更好的准确率。

X - SQL：基于草图的系统，使用MTDNN预训练语言模型，编码方式与HydraNet不同，同时编码所有表标题和用户问题，并使用类型嵌入区分输入元素类型，还通过注意力层处理多词列名，性能优于SQLova，略低于HydraNet。

TypeSQL：是最早在工作流程中引入类似模式链接过程的系统之一，通过考虑NLQ中的n - gram 并尝试为其分配类型，虽主要是分类查询候选类型，但向模式链接迈出了第一步。

ValueNet：基于语法的系统，专注于模式链接和条件值发现，解码SQL查询为SemQL 2.0 AST，并通过五步流程处理条件值，包括提取、生成、验证、编码候选值，最后由神经网络决定其使用位置，还提供了Spider查询基于值发现难度的分类。

SDSQL：基于草图的系统，可视为同时处理两个任务的两个神经网络，一个预测SQL查询，另一个执行模式依赖预测。

IE - SQL：几乎完全基于模式链接解决文本到SQL问题，使用两个BERT实例分别执行提及提取和链接任务，识别SQL查询各部分提及并分组，通过提及提取器和链接器的预测生成SQL查询。

SeaD：基于BART编码器-解码器预训练语言模型，为克服序列解码器的缺点，引入侵蚀和洗牌两个额外训练任务，并使用执行引导解码技术，在WikiSQL基准上取得最佳性能，但解码技术和额外目标是针对WikiSQL数据集设计，扩展到完整关系数据库面临挑战。

BRIDGE：使用序列解码器，在Spider上工作，通过BERT和LSTM网络编码输入，并利用线性网络丰富输入表示，执行模式链接并将发现的值添加到输入序列，使用基于模式一致性引导解码的指针生成网络解码器，训练和预测时按特定SQL查询顺序执行以避免无效查询。

PICARD：是用于语言模型自回归解码器的约束技术，在推理时通过检查模型预测的置信度得分和数据库模式，在三个层面约束可能的预测，与T5 - 3B 预训练语言模型结合时在Spider排行榜上取得执行含值情况下的第一名，但增加了预测时间和计算资源需求。

与基准的关系：系统使用的解码方法与所操作的基准相关。在Spider基准上运行的系统不使用基于草图的解码器，因为其难以适应生成复杂SQL查询；而在WikiSQL基准上，早期以草图式解码器为主，近期序列式解码器表现出色，在两个基准上均占据领先地位。

对系统的影响：输出解码器决定了系统的SQL表达能力以及扩展到新SQL查询类型的难易程度。基于语法的解码器实现难度较大，需要广泛的语法覆盖各种可能的查询；扩展到新查询类型时，不同解码器所需的努力程度不同，草图式或语法式解码器需扩展草图或语法，而序列式解码器在有训练示例时可有效生成新查询类型，但也可能因生成能力过强而导致问题。

缺乏真实性：WikiSQL和Spider等基准虽推动了系统评估，但不能代表现实应用场景。WikiSQL查询简单，当前系统在其上准确率已达较高水平；Spider的数据库和查询不够真实，如模式简单、数据量少。理想的新基准应采用真实行业或学术数据库及用户查询日志。

样本数量少：与其他深度学习问题的数据集相比，现有基准的示例数量相对较少，限制了系统的训练和泛化能力。可通过创建新的大规模数据集或整合现有基准来改进，但需谨慎考虑数据集的划分，以确保系统能在不同方面进行有效泛化。

查询分类不明确：当前基准缺乏清晰的查询分类，无法明确系统能理解和构建的查询类型，限制了对系统优缺点的深入理解。需要新的基准和更深入的系统评估，提供细粒度的查询类别。

假设单一正确答案的局限性：现有基准假设每个自然语言查询只有一个正确SQL查询，但实际情况可能有多种正确翻译或等价但表达方式不同的SQL查询，这限制了对系统的全面评估。

缺乏效率评估：当前系统评估多关注准确性，忽视了效率。数据库社区应开发专注于效率的基准，以全面评估系统性能。

效率问题：深度学习text-to-SQL系统依赖复杂模型，在实际应用中面临效率挑战。使用PLMs虽能提高准确性，但增加了推理时间；输出优化技术也增加了系统开销。例如，在Spider数据集上表现出色的T5 - 3B + PICARD 模型，计算资源需求高，实际应用需优化以降低资源需求。

输入编码限制：输入编码技术存在输入大小限制，对处理真实世界大型数据库模式造成困难。需要开发能有效处理大型模式的输入编码技术，提高系统技术可行性。

模式链接优化：模式链接技术在处理真实大规模数据库时的效率和可扩展性未经充分测试，虽对部分系统有益，但存在查找效率和高级匹配技术开销等问题。数据库社区应优化模式链接，使其在实际中可行。

整体性能权衡：提高翻译速度是必要的，但还需考虑文本到SQL翻译对整体查询执行时间的影响，早期系统不仅追求正确查询，还注重执行速度，未来系统应在效率和准确性间取得平衡，让用户无需关注技术细节。

数据库多样性挑战：将text-to-SQL系统应用于实际数据库时，面临数据库多样性挑战，包括大量表和属性以及特定领域术语，导致现有系统无法翻译。如SDSS数据库中的特定属性，在实际应用中需结合本体和领域知识实现可靠翻译，这需要数据库、机器学习和自然语言处理社区共同努力。

多语言支持需求：当前研究主要关注英语自然语言查询，未来需支持多种语言，以扩大系统的应用范围，提高其普遍性。

问题重要性：深度学习模型需要大量训练数据，但现有基准规模小且手动创建新示例成本高，数据增强成为重要问题。

现有方法及不足：已提出多种数据增强方法，如DBPal的模板式方法、基于模板生成SQL和NLQ的方法以及生成跨表训练示例的方法，但这些方法存在局限性，如模板和自然语言技术在新数据库上的不一致性、生成数据的质量问题等，且缺乏对不同方法影响系统的系统评估。此外，如何结合领域特定数据和通用数据进行训练也是一个研究问题。

查询解释：用户使用text-to-SQL系统时，需要确认查询结果是否符合意图，自然语言的查询解释有助于此。目前这方面研究不足，未来可从现有文本到SQL方法的迁移、评估指标的确定以及设计同时解决文本到SQL和查询解释问题的系统等方面展开研究，如T5模型在这方面有一定潜力。

查询结果解释：查询结果以表格形式呈现，缺乏自解释性，生成自然语言解释是一个开放研究领域。与数据到文本生成领域相比，查询结果解释面临更多挑战，如捕捉查询语义、缺乏合适基准、处理多表连接结果等。

查询推荐：用户在查询数据库时可能不清楚可询问的查询类型，查询推荐可根据用户偏好、历史或其他用户行为帮助用户找到有趣查询。将深度学习模型应用于查询推荐面临诸多挑战和机遇，如如何有效结合用户信息和数据特征进行推荐。

会话式文本到SQL：开发会话式数据库接口是一个有前景的任务，能让用户通过自然语言和会话访问数据。CoSQL和SParC等数据集的发布推动了该领域进展，但会话式问题面临新挑战，如系统需考虑用户历史交互、处理模糊问题和多种解释等，现有系统需大量修改才能有效编码会话历史和SQL预测，该领域的发展将通向 “智能数据助手”，提供更强大的用户体验。