text2sql(NL2Sql)综述《The Dawn of Natural Language to SQL: Are We Fully Ready?》

《The Dawn of Natural Language to SQL: Are We Fully Ready?》(github)出自2024年6月的NL2SQL(Natural language to SQL )综述论文。这篇论文尝试回答如下三个问题：

问题1:NL2SQL的现状是什么？(Q1:Where Are we Now?)

论文图1总结了近20年NL2SQL方法的演变，从基于规则的方法，基于深度神经网络的方法，基于预训练模型(PLMs)的方法，演变到了基于大语言模型的方法(LLMs)。
论文图2比较了PLM-based NL2SQL方法(蓝色的点)和LLM-based NL2SQL方法的在Spider数据集上的准确率对比，这个图表明在2023年2月时两者的准确率差不多，但是随着LLM的演进，两者的差距逐渐拉大。

问题2: LLM-based方法是完胜者吗？(Are LLM-based Models the clear Winner?)。
基于论文图2，我们就能得出结论说LLM-base方法就是NL2SQL应用的唯一选择了吗？
考虑一下传统BI(Business Intelligence)场景，有如下特点：

不同的数据领域(Various Data Domains), BI平台如Tableau通常有不同的数据领域如电影和运动，每个数据域涉及到不同的schemas和术语。理想的NL2SQL必须能够在不同的领域有泛化效果且满足即席查询要求。
复查的SQL操作(Complex SQL operations),实际应用通常包括复杂SQL查询如多个JOIN操作，嵌套查询，聚合函数等。所以NL2SQL模型需要能够生成复杂的SQL查询语句。
新语言表述(New Linguistic Phenomena)，对于同一个查询意图，不同的用户可能会用不同缩写、问题风格、同义词来提出自然语言问题。所以NL2SQL模型需要准确地理解自然语言问题描述的变化。

论文图3比较了SOTA PLM-based和LLM-based方法在上面提出的三个BI应用特点上的执行准确率，结果表明没有任何一个模型或方法能够在所有应用特点上都是最优的。
在这里插入图片描述

问题3：能够组合PLM-based和LLM-based方法并设计出一个super NL2SQL模型吗？(Q3: Can we combine the best of both worlds and design a super NL2SQL model?)。

NL2SQL定义：设 $\mathcal{N}$ 是一个自然语言问题， $\mathcal{D}$ 是一个有n个表的关系数据库。NL2SQL就是基于 $\mathcal{N}$ 和 $\mathcal{D}$ 生成一个SQL查询 $\mathcal{Q}$ 。

论文表1归纳了一些PLM-based和LLM-basedNL2SQL模型和它们包含的关键组件(后面会介绍各个组件)。
在这里插入图片描述

论文作者认为之前的NL2SQL的实验和评估有如下几个限制：

忽视了使用场景：通常只有在整个基准数据集如Spider数据集上整体的评估，缺少在数据子集上进行详细比较(参考论文图3)
缺少直接和综合比较：没有在已有基准和自建数据集上的系统比较。
NL2SQL设计空间的有限探索：缺少对LLM-based和PLM-based模块框架设计空间的探索，就限制了对它们协同使用来解决NL2SQL的理解。

为了解决这些现有限制，论文提出了一个测试平台(testbed)，NL2SQL360，如论文图4所示，一共包含6个关键模块。
在这里插入图片描述

基准数据集(Benchmark Datasets): 包括被广泛使用的基准Spider, BIRD , Spider-Realistic, Dr.Spider , KaggleDBQA, WikiSQL。
模型动作园(Model Zoo)：包括在Spider和BERT排行榜上领先的模型，主要是LLM-based和PLM-based模型。
数据集过滤器(Dataset Filter)：引入数据集过滤机制，将基准数据集划分成不同的子集。
- 场景1:SQL复杂度(SQL Complexity)。通过复杂度来区分SQL，从简单的SQL到有多个条件和子句的复杂SQL。分类标准与Spider一致，主要评估不同的NL2SQL方法能否处理不同难度的SQL。
- 场景2:SQL特色(SQL Characteristics)。检查SQL是否使用了如JOIN操作、子查询、聚合函数等特性。主要评估NL2QL能否处理不同的SQL功能。
- 场景3:数据领域(Data Domain)。在不同的数据领域如金融、健康或零售来探索NL2QL的表现。主要评估NL2SQL领域相关的能力和限制。
- 场景4:查询语句变化测试(Query Variance Testing)。测试在自然语言查询不同的短语描述和结构下NL2QL的鲁棒性和灵活性。
评估指标(Evalutation Metrics)：
- Execution Accuracy (EX)，与Spider一样
- Exact Match Accuaracy (EM)，与Spider一样
- Valid Efficiency Score (VES)，评估生成可用SQL的效率，与BIRD一样。用预测SQL执行时间除以标准SQL执行时间。
- Query Variance Testing(QVT)，论文新提出的指标用来评估模型在不同形式的自然语言查询上的适应性有多好。给定一个SQL查询 $Q_i$ ，它对应着多个自然语言查询语句，记为 $\{(N_1, Q_i),(N_2, Q_i),\ldots,(N_m, Q_i) \}$ ，在评估模型时，这些自然语言查询与SQL对中至少有一个被模型正确处理。QVT准确率的定义如下：
  $T=\frac{1}{M} \sum_{i=1}^M\left(\frac{\sum_{j=1}^{m_i} \mathbb{1}\left(\mathcal{F}\left(N_{i j}\right)=Q_i\right)}{m_i}\right)$
  上式中M是测试集中SQL查询的总数， $m_i$ 是每个SQL查询 $Q_i$ 对应的自然语言查询语句形式数目。 $\mathcal{F}(N_{ij})$ 表示NL2SQL模型对 $Q_i$ 的第 $j$ 个自然语言查询语句形式生成的SQL查询。 $\mathbb{1}(\cdot)$ 是指示函数，如果两个sql相等则返回1否则返回0。
执行器和日志(Executor and logs)：用户可以定制NL2SQL模型的评估流程，设置超参数和评估指标。测试平台会在测试基准如Spider上自动运行这些模型并对输出进行记录。
评估器(Evaluator)：利用日志中的数据，评估器自动生成量化评价，以表格或者排行榜的形式来展示这些结果。

论文的实验

实验设置：

数据集：以Spider 和 BIRD作为实验数据集，分别包括1034和1054个(NL, SQL)对。BIRD数据集的SQL结构和数据库都更复杂，统计信息如论文表格2。
NL2SQL方法：评估了开源的LLM-based和PLM-based NL2SQL 方法。
比较了4种基于prompt的LLM-based方法
- (1) DINSQL：将SQL语句的生成分解成不同的子问题，对每个子问题使用不同prompt让GPT-4生成最终的SQL语句。
- (2) DAILSQL：在prompt中将问题和数据库schema表示成代码风格，通过结构(骨架)相似性和问题相似性来选择few-shot例子。这些元素作为prompt来指导GPT-4生成SQL。
- (3) DAILSQL(SC)：用Self-Consistency (SC)策略进行后处理的DAILSQL版本。
- (4) C3SQL用了schema linking过滤和calibration bias prompt让GPT-3.5来生成sql，也用了Self-Consistency (SC)策略进行后处理。
比较了9中基于微调的LLM-based方法
- (5-8) SFT CodeS (1B/3B/7B/15B)：CodeS是在SQL相关语料集上对StarCoder进行增量预训练得到的模型，在Spider或BIRD数据集上对CodeS进行指令微调(SFT)得到SFT CodeS，一共有四个不同大小的版本。
- (9) Llama2-7B
- (10) Llama3-8B
- (11) StarCoder-7B: StarCoder是用GitHub上有许可的数据训练得到的Code LLM，训练数据包括超过80种编程语言的代码，Git mommits， GitHub issues， Jupyter notebooks。
- (12) CodeLlama-7B
- (13) Deepseek-Coder-7B: 在项目级代码语料上训练，用fill-in-the-blank任务来提升代码补全能力。
比较了7中PLM-based 方法
- (1) Graphix-3B+PICARD，用T5-3B加上graph-aware来进行SQL生成，并用PICARD解码来提升性能。
- (2-4) RESDSQL(Base/Large/3B)，用ranking-enhanced编码和skeleton-aware解码将schema linking从骨架解析中分离。
- (5-7) RESDSQL(Base/Large/3B)+NatSQL，用NatSQL来提升RESDSQL的性能。
指标，包括Exact Match Accuracy (EM), Execution Accuracy (EX), Query Variance Testing (QVT), Valid Efficiency Socre (VES), Token Efficiency, Latency。

评估准确性的实验

如下的每一个实验对应着一个实验发现。

Exp-1: Accuracy vs. SQL Complexity。评估了前面提到的所有方法在Spider和BIRD测试集上改变SQL复杂度时的准确率。论文表3和表4是实验结果，将EX的SOTA结果用橙色标记，EM的SOTA结果用蓝色标记。（注意RESDSQL在BIRD测试集上从头训练了，但没有因为缺少源码没有包括NatSQL）
- LLM-based方法在不同难度的SQL数据子集上的EX指标都超过了PLM-based方法。在表4中，DAILSQL(SC)方法可能受益于GPT-4d的推理能力在Challenging子集上超过了SFT CodeS 15B。
- 表格3中微调之后的LLM-based方法普通性能要比prompt-based LLM方法的EM指标更好。在微调之后，LLM-based和PLM-based模型的输出更接近数据集的数据分布，使它们输出与数据集更相似的SQL结构。
- 发现1：微调是提高性能的重要策略，微调后的LLM-based方法在EX指标上普遍取得最好的结果，微调后的PLM-based在EM指标上总体而言表现最好。

在这里插入图片描述

Exp-2: Accuracy vs. SQL Characteristics。将SQL查询按照四个标准来分类：(1) 子查询的存在，(2)逻辑连接符的个数 (3) ORDER BY的个数 (4) JOIN的数据。在这四个SQL查询子集上测试模型并计算EX指标。论文图5显示了在Spider和BIRD数据集上EX表现分布。论文图6和图7是详细结果。
- Exp-2.1: #-Subquery。如图6和图7所示，所有方法在包括子查询的SQL上都表现最差。图5显示没有子查询时，LLM-based方法在Spider数据集上比PLM-based方法好一点点，而在BIRD数据集上好很多。而有子查询的场景下，LLM-based方法在两个数据集上表现都好很多。因为带子查询的SQL要求模型先考虑子查询再生成整个SQL，对模型的推理能力要求很高。在LLM-based方法中，用prompt GPT-4方法效果更好，超过了基于微调的LLM-based方法和PLM-based方法，表明模型的内在推理能力对处理带子查询的SQL很重要。
- 发现2：在SQL子查询场景下，LLM-based方法总体超过PLM-based方法，用GPT-4的基于prompt的LLM-based方法表现最好，模型的内在推理能力对处理带子查询的SQL可能很关键。
- Exp-2.2: #-Logical Connector。没有逻辑连接符时，LLM-based方法在Spider数据集上没有超过PLM-based方法，在更复杂的BIRD数据集上LLM-based方法是领先的。当有逻辑连接符时，LLM-based方法在两个数据集上都超过PLM-based方法。
- 发现3：在逻辑连接符是必需的场景下，LLM-based方法比PLM-based方法更好。
- Exp-2.3: #-JOIN。在不带JOIN的SQL场景下，LLM-based方法和PLM-based方法在两个数据集上表现还是不一致，没有完胜者。在带JOIN的SQL场景下，LLM-basd方法在两个数据集上都比PLM-based方法更好，可能是因为JOIN操作需要理解数据库schame，而LLM因为其上下文理解能力而获胜。在图6中，用了NatSQL的DINSQL和RESDSQL-3B+NatSQL的方法在它们对应的模型类别中都是表现最好的，说明使用NatSQL可能会使带JOIN的SQL场景更简单。
- **发现4：**在带JOIN操作的SQL场景中，LLM-based方法比PLM-based方法更好。用NatSQL作为中间表示可减少预测JOIN操作的复杂度并提升模型性能。
- Exp-2.4: #-ORDER BY。在没有ORDER BY语句时，LLM-based方法比PLM-based方法更好；在有ORDER BY语句时，LLM-based方法在Spider数据上的性能更差。
- 发现5：在有ORDER BY的SQL场景下，LLM-based方法的性能在不同数据集中变化，普遍来说，LLM-based方法的泛化性更好。
- Exp-3: Query Variance Testing。

在这里插入图片描述

Exp-3: Query Variance Testing。基于Spider Dev数据集构建了QVT数据集并根据前面QVT的公式计算得分。实验结果如下图所示，LLM-based方法和PLM-based方法没有赢家。但是微调LLM-based方法比prompt LLM-based的的QVT得分更高，可能因为微调之后对数据分布进行了对齐。Graphix+PICARD方法在EX上比所有prompt-based方法低，但是在QVT上超过了它们。
发现6： 在QVT对比上，LLM-based方法和PLM-based方法没有赢家，用任务相关数据集微调模型可能使模型在自然语句变化上表现得更稳定。
Exp-4: Database Domain Adaption。将Spider训练集里的140个数据库和开发集的20个数据库划分为33个领域。将基于微调的LLM-based方法和PLM-based方法在测试集上进行训练。论文图9是实验结果。图9(a)表明不同的方法在不同领域表现不一样，LLM-based和PLM-based方法里没有赢家。图9(b)表明在有更多数据集的领域(College,Competition,Transportation)微调方法表现更好，相反地，在有更少训练数据的领域，prompt-based方法表现更突出。
发现7：不同的方法在不同领域表现不一样，LLM-based和PLM-based方法里没有赢家。在特定领域，微调过程中的可用领域训练数据对模型性能很关键。
Exp-5: Supervised Fine-tuning of LLM-based Methods。验证了开源LLM经过指令微调之后在NL2SQL任务上的表现。采用的prompt与DAILSQL类似，如论文图10所示，比较的LLM大小都为7B，实验结果如论文图11所示，经过SFT之后，不同模型的EX指标都有提升但是提升效果不同。在模型固有的编码能力与SFT前后性能提升大小存在正相关。
发现8：在对开源 LLM 进行 NL2SQL 任务的监督微调 (SFT) 后，SFT 后的性能与 SFT 之前模型固有的编码能力呈正相关。这表明具有高级编码能力的基础 LLM 对于适应 NL2SQL任务非常重要。

评估效率的实验

如下的每一个实验对应着一个实验发现。

Exp-6: Economy of LLM-based Methods。论文表5比较了LLM-based方法消耗的平均token上和花费(美元)。
发现9：调用GPT-3.5-turbo模型的的prompt-based LLM NL2SQL方法有更高的性价比(cost-effectiveness)。尽管DAIL-SQL(SC)比DAIL-SQL在Spider和BIRD数据集上的EX都有提升，但是它的费用更高降低了其性价比。
Exp-7: Efficiency of PLM-based Methods。在Spder开发集上比较了RESDSQL-Base/Large/3B 和 RESDSQL-Base/Large/3B + NatSQL的执行准确度(EX)，每个样本的latency，GPU内存使用指标。结果如论文表6。

在这里插入图片描述

发现10：对同一种方法，模型参数越多相应的latency和硬件资源要求都会增加。相似性能的方法在latency和硬件资源要求上是不一样的。
Exp-8: SQL Efficiency - Valid Efficiency Score。NL2SQL方法在Spider和BIRD数据集上的VES如论文表7所示，最好的结果用橙色颜色标注。
发现11：在VES指标上，LLM-based方法和PLM-based方法没有赢家，对于同一种方法，在更高难度的子集上有更低的VES得分。

在这里插入图片描述

Exp-9: The Impact of the #-Training Samples。比较在不同数目训练样本，各个模型的表现，结果如图12所示，模型效果随着训练数目增加而提升，在大概4000样本左右时可实现可接受的性能。
发现12：PLM-based和LLM-based方法的性能都随着训练数据的增加而提升，但是边际效应会递减，也就是随着数据大小增加EX性能增益减小。如果有数据隐私忧虑或充足的标注数据，微调LLM/PLM是一个好选择。

在这里插入图片描述

将基于语言模型的NL2SQL方法的设计空间总结如论文图13所示（前面论文表1总结了每种方法按照这个框架定义的组件）。

预处理(Pre-Processing)：预处理模块主要包括schema linking 和DB contents。Schema linking 将自然语言查询与数据库schema元素关联，可提升跨领域泛化性和复杂查询生成，LLM-based和PLM-based方法都会使用Schema linking。DB contents模块将查询条件与数据库内容对齐，通常通过字符串匹配来丰富列细节；DB contents方法在PLM-based方法中很流行，但是很少被LLM-based方法使用。
promp策略(Prompting Strategy)：Prompt策略分为zero-shot和few-shot，zero-shot在模型输入里不包括NL2SQL例子，few-shot在模型输入中包括NL2SQL例子，根据例子的个数不同，记为"3-shot"、"5-shot"等。如论文表1显示PLM-based方法基本上使用zero-shot，而LLM-based方法有些使用zero-shot，有些使用few-shot。DINSQL的few-shot例子是人工设计且固定的，而DAILSQL是基于查询问题与训练集例子的相似度来动态选择的。
SQL生成策略(SQL Generation Strategy)：在生成SQL时，语言模型会使用多种策略，将其归类为如下三种。
- Multi-Step：主要指COT(Chain-of-Thought)过程，对于复杂查询很有效，主要包括两种类型的策略：PLM-based方法RESDSQL使用的"SQL skeleton-SQL"和LLM-Based方法DINSQL使用的"Subquery-SQL"。
- Decoding Strategy：在模型的解码过程中进行约束保证输出的有效性。PLM-Based方法PICARD在输出时强制SQL语法规则，但是利用OpenAI接口的LLM-based方法缺少解码时的限制。
- Intermediate Representation：试图通过中间查询（intermediary query）来解决自然语言到SQL翻译过程中的不匹配问题(mismatch problem, 指关系数据库的SQL设计与自然语言语义不一致)。论文只考虑NatSQL。
后处理(Post-Processing)：包括如下策略。
- Self-Correction。出自DINSQL，将生成的SQL提供给模型来修复潜在的问题。
- Self-Consistency。对单个自然语言问题生成不同的SQL查询，用投票机制来决定最后的SQL。C3SQL和DAILSQL使用了它。
- Execution-Guided SQL Selector。执行模型生成的SQL，将第一个执行成功的SQL作为可用SQL。
- N-best Rerankers。将多个候选SQL查询排序，将最可能的一个作为最后的结果。

接下来论文尝试基于NL2SQL360设计一种算法NL2SQL360-AAS来选择NL2SQL设计空间里的组件来得到一个最优的NL2SQL方法，算法基于遗传算法(Genetic Algorithm(GA))，如论文图14所示。
在这里插入图片描述