1. NL2SQL现状

自然语言转SQL（nl2sql）技术是指自然语言查询转化为SQL查询，降低普通用户和专家用户在访问海量数据集和获取数据分析结果时的门槛。

1.1 我们目前处于何方？

上图展示了过去二十年nl2sql方法的演进历程，从基于规则的方法，到基于深度神经网络的方法，再到可调的预训练语言模型（PLMs），直至大型语言模型（LLMs），整个过程伴随着数据集的发展，比如Spider和BIRD等基准测试的发展。

LLMs（如GPT-4和Llama2）相较于PLMs（如GPT-2和BART）是规模更大的语言模型，展现出更深层次的语言理解能力。在nl2sql 任务中应用PLMs需要在特定任务的数据集上进行微调，而利用LLMs则可以通过提示（上下文学习）或仅对开源LLMs进行微调（即SFT）。

上图对比了基于PLM（蓝点）和基于LLM（绿点）的nl2sql模型在Spider排行榜上的准确率。

可以看出基于LLM的nl2sql模型自2023年2月（DINSQL + CodeX）起便与基于PLM的模型展现出相当的准确率。

然而，随着LLMs的迅猛发展，基于LLM和PLM模型之间的性能差距正在扩大，表明了基于LLM方法优势十分明显。

1.2 基于LLM的模型是否明显胜出？

根据上图，是否可以断定基于LLM的模型是所有nl2sql应用的“首选”？换句话说，总是选择排行榜首位的模型是否总是最佳策略？

讨论这一问题前，作者分析了商业化场景的一些特征：

• 多样化的数据领域（Various>• 复杂的SQL操作（Complex SQL operations） ：实际应用中往往需要执行包含多个JOIN、嵌套查询和聚合函数等高级操作的复杂SQL查询。准确生成这些复杂查询的能力是衡量nl2sql模型性能的重要指标。

• 新兴的语言现象（New Linguistic Phenomena） ：对于同一查询意图，不同用户可能会使用不同的缩写、同义词和问题风格提出问题。因此，nl2sql模型准确解读各种自然语言查询变体的能力至关重要。

上图从多个维度对比了Spider开发数据集上的SOTA PLM和LLM模型，评价指标是执行准确性（Execution-Accuracy）。

• 多样化的数据领域（Various> •复杂的SQL操作（Complex SQL operations）：上图(b)比较了仅包含JOIN操作符的SQL查询用例中的不同模型。基于PLM的方法RESDSQL-3B+NatSQL位居榜首，超越了所有基于LLM的方法。然而，当比较仅包含嵌套SQL查询的用例时，基于LLM的方法通常优于基于PLM的方法。

•新兴的语言现象（New Linguistic Phenomena）：比较了不同语言现象下方法的平均准确率（例如，“ 返回所有消费总额超过1000的客户”与“消费超过1000的客户名单是什么？”）。上图(d)显示，尽管两种类型的方法都表现良好，但微调的LLM和PLM在nl2sql任务上优于基于提示的LLM。主要是因为微调模型能更好地将不同的查询变体与数据库架构相匹配。

所以，并非所有情况都适用同一解决方案；也就是说，即使是目前最强大的LLM GPT-4支持的模型，也没有一个nl2sql模型能在所有不同的使用场景中都成为明显的赢家。真实应用场景远比公共nl2sql基准测试（如Spider和BIRD）所能考察的要复杂得多。因此，迫切 需要能够从不同角度系统评估给定基准上nl2sql模型的工具 。

1.3 全局视角看NL2SQL

根据文章最开始的进化树，NL2SQL可以分为四大流派：

• 基于规则的方法：早期研究依赖于预设规则或语义解析器。例如，NaLIR利用句法解析器和手工规则将自然语言查询转换为SQL查询。但这些方法在适应性、扩展性和泛化力上存在局限。

• 基于神经网络的方法：利用神经网络将自然语言查询译为SQL查询。随之发布了若干大规模基准数据集，例如WikiSQL和Spider。相继开发了诸如IRNet的序列到序列nl2sql方法。IRNet通过编码器对自然语言查询和数据库架构进行编码，并借助解码器生成SQL查询。

• 基于PLM的方法：随着Transformer的问世和Spider数据集的推出，基于神经网络的方法迅速崛起，BERT和T5等模型开启了预训练语言模型的新纪元，在基准数据集上屡创佳绩。例如，RESDSQL，作为Spider排行榜的佼佼者，采用两阶段框架：先从自然语言查询中识别相关架构元素，再构建SQL查询。

• 基于LLM的方法：ChatGPT和GPT-4等大型语言模型的出现，彻底革新了nl2sql解决方案。如今，基于LLM的方法已在nl2sql领域占据主导地位。以DAIL-SQL为例，它借助GPT-4和提示工程，在Spider数据集上取得了不俗的成绩。

NL2SQL系统的关键组件

上表根据核心模型和若干关键组件对当前领先的nl2sql方法进行了分类。

2. NL2SQL360：NL2SQL的全方位测试平台

为了更好的、系统性的测评NL2SQL任务，作者推出了NL2SQL测评平台。

上图展示了NL2SQL360测试平台框架，由六个核心组件构成：

• 基准数据集。汇集了多种广泛采用的基准数据集，包括Spider 、BIRD 、Spider-Realistic 、Dr.Spider 、KaggleDBQA 、WikiSQL 等。

• 模型库。收录了一系列在Spider和BIRD排行榜上表现出色的竞争性开源NL2SQL模型，主要包括基于LLM和PLM的方法。

• 数据集筛选器。传统评估方法通过计算整个基准数据集的平均性能，忽略了不同场景下NL2SQL的细微差别。为弥补这一不足，精心挑选了特定的基准数据集子集，包括特定的数据库、自然语言查询和SQL查询，以凸显查询复杂性、数据库架构多样性以及SQL特性（如JOIN操作或嵌套查询）等独特要素。因此，在NL2SQL360中引入了数据集筛选机制。这使得测试数据集能够根据不同的标准被划分为更加专注的子集：

• (1) 场景一：SQL复杂度。根据复杂度对SQL查询进行分类，从简单查询到包含多个子句和条件的复杂查询。分类标准遵循Spider的准则，目的是评估NL2SQL方法处理不同难度SQL的能力。

• (2) 场景二：SQL特性。检验主要利用特定特性的SQL查询，例如JOIN操作、子查询或聚合函数。通过基于这些特性对查询进行分类，评估NL2SQL系统处理不同SQL功能的能力。例如，商业智能平台经常需要处理包含嵌套子查询的分析型查询。

• 评估标准。采纳了广受认可的评估标准。

• 采用执行准确度（EX）与完全匹配准确度（EM）来评价生成的SQL查询的效果。

• 利用有效效率得分（VES）来衡量生成有效SQL查询的效率。

• 查询变异性测试更全面地评估nl2sql解决方案处理自然语言查询变化时的稳定性与适应性

• 评估工具。根据日志中的数据，评估工具自动生成定量评估报告，并以表格或排行榜等直观格式展示。配备了可视化工具和仪表板，支持用户进行交互式分析，轻松比较不同nl2sql解决方案在数据库领域和SQL特性等方面的性能表现。

3. LLM好还是PLM好？

作者采用了Spider 和 BIRD 的开发数据集进行实验，分别包含1034和1534个自然语言与SQL样本。BIRD数据集的SQL结构更为复杂，涵盖了Spider未包含的CASE、IIF等关键字，增加了对模型自然语言转SQL能力的挑战。此外，BIRD中的数据库结构也比Spider更为复杂。

3.1 测评基准

3.1.1 4种基于LLM提示工程的基准方法

• (1) DINSQL：将SQL查询生成分解为多个子任务，并为每个子任务设计了特定的提示，以指导GPT-4生成最终的SQL查询。

• (2) DAILSQL：以SQL代码风格对问题和数据库架构进行编码，根据结构和查询的相似性选择少量示例，这些元素被整合成一个高效的提示，引导GPT-4进行操作。

• (3) DAILSQL(SC) ：DAILSQL的自我一致性（SC，Self Consistence）策略后处理版本。

• (4) C3SQL ：结合了模式链接过滤（schema linking filterin）和为GPT-3.5定制的校准偏差提示，用于生成SQL查询，并采用自我一致性策略（SC，Self Consistence）进行后处理。

33.1.2 9种基于finetune的LLM方法

• (5-8) SFT CodeS (1B/3B/7B/15B) 是基于StarCoder ，使用大量SQL相关语料库逐步预训练的，在后续实验中，使用了与Spider或BIRD数据集微调的SFT CodeS。实验中包含了SFT CodeS家族的四个版本。

• (9) Llama2-7B 采用优化的Transformer作为自回归语言模型，由Meta在庞大的语料库上预训练。

• (10) Llama3-8B 在超过15T的令牌数据上训练，训练数据集规模是Llama 2的7倍，包括4倍多的代码。

• (11) StarCoder-7B 是一个代码LLM，已在GitHub上许可的数据上进行训练，包括超过80种编程语言的代码。

• (12) CodeLlama-7B 是Llama2的增强版，通过在代码库数据集上进行额外训练进行了优化。

• (13) Deepseek-Coder-7B 在项目级代码语料库和填空任务上进行训练，以提升代码补全能力。

3.1.3 7种基于PLM的自然语言转SQL方法

• (1) Graphix-3B+PICARD 将预训练的T5-3B变换器与图感知增强集成，用于自然语言转SQL任务，并利用PICARD 提高性能。

• (2-4) RESDSQL(Base/Large/3B) 引入了排名增强编码和骨架感知解码，将模式链接与骨架解析分离。

• (5-7) RESDSQL(Base/Large/3B)+NatSQL 结合了NatSQL 以获得更好性能的版本。实验中使用了六个版本的RESDSQL家族模型。

3.2 实验一：微调是否必要？

从执行准确度（EX）的视角来看（上面两图分别展示了Spider数据集和Bird数据集上结果），基于LLM的方法在不同难度的子集中均超越了基于PLM的方法。特别是在BIRD测试数据集中，DAILSQL(SC)在挑战性子集上的表现超过了基于LLM的最新最佳方法SFT CodeS15B，这可能是由于GPT-4在推理能力上的显著优势。

从精确匹配准确度（EM）的角度分析，经过监督微调的基于LLM的方法通常比基于提示的LLM方法展现出更高的EM性能。微调之后，无论是基于LLM还是PLM的模型，其输出都更加贴近特定数据集的数据分布，从而能够预测出与该数据集中相似的SQL结构。

洞察1 ： 微调是提升性能的必由之路 。特别是，经过微调的基于LLM的方法在执行准确度（EX）指标上取得了最优的整体表现，而基于PLM的方法在精确匹配准确度（EM）指标上整体表现最为出色。

3.3 实验二：精确度与SQL特性的较量

在真实场景中，经常需要构建包含诸如子查询、逻辑连接器、排序（ORDER BY）以及多重连接（JOIN）等高级操作的SQL查询。

因此，将检验自然语言转SQL模型在生成具有不同特性的SQL查询方面的精准度。

所以，根据四个维度对SQL查询进行分类：

• (1) 是否包含子查询

• (2) 逻辑连接器的数量

• (3) 是否使用排序功能

• (4) 连接操作的次数

NL2SQL360能够根据单个SQL子句、它们的组合或用户自定义的条件来过滤SQL查询。展示了四个具有代表性的维度。

3.3.1 实验2.1：子查询的挑战

从上面两个可以看出，在涉及子查询的情况下，所有方法的表现都不尽如人意，表明 通过子查询进行逻辑推理是一个难题 。

上图揭示了在没有子查询的情况下，基于LLM的方法在Spider数据集上略微领先于基于PLM的方法，而在BIRD数据集上则平均表现显著更佳。

当存在子查询时，基于LLM的方法在两个数据集上都大放异彩。这是因为构建带有子查询的SQL语句要求模型先深入理解子查询，再生成完整的SQL语句，这对模型的逻辑推理能力提出了高要求。

所有基于LLM的方法， 尤其是那些由GPT-4驱动的，处理子查询时更为出色 ，不仅超越了经过微调的基于LLM的方法，也超过了基于PLM的方法。模型内在的推理能力对于处理含子查询的SQL至关重要。

洞察2 ：在包含子查询的场景中，基于LLM的方法总体上超越了基于PLM的方法，尤其是那些采用GPT-4的（即基于提示的LLM）方法，表现尤为突出。 模型的内在推理能力可能是准确预测子查询的关键所在 。

3.3.2 实验2.2：逻辑连接符的运用

逻辑连接符（如AND、OR）用于连接条件、筛选查询结果及其他操作，因此评估模型处理逻辑连接符的性能至关重要。

在未涉及逻辑连接符的情况下，基于LLM的智能体在Spider数据集上并未明显超越基于PLM的方法。但在结构更复杂的BIRD数据集中，基于LLM的智能体则表现出色。

一旦涉及到逻辑连接符，基于LLM的智能体在两个数据集上均持续领先于基于PLM的智能体。

洞察3 ：在需要逻辑连接符的情境下， 基于LLM的智能体相较于基于PLM的智能体，展现出更优的性能 。

3.3.3 实验2.3：多表连接的艺术

实际应用中，经常需要构建涉及多表连接的SQL查询，对模型准确把握复杂数据库架构的能力提出了挑战。

在不涉及连接操作的情况下，基于LLM和PLM的方法在Spider和BIRD数据集上的表现参差不齐，难分伯仲。

当涉及到需要执行连接操作的场景时，基于LLM的在两个数据集中均显著优于基于PLM的。可能是因为连接操作要求深入理解数据库的复杂结构，而LLM在这方面通常表现出色，得益于其卓越的上下文理解能力。

NatSQL的积极作用也不容忽视。在处理包含连接的SQL查询时，DINSQL在基于提示的智能体中表现最佳，而RESDSQL-3B+NatSQL则在基于PLM的智能体中独占鳌头。两者都采用了NatSQL 作为中间表示层，这可能得益于其简化的形式，省去了连接关键字并减少了架构项的预测，从而在连接场景中简化了SQL的预测过程。

洞察4 ：在需要执行连接操作的场景中，基于LLM的智能体比基于PLM的智能体表现更佳。采用NatSQL作为中间表示层，不仅降低了预测连接操作的复杂性，还可能进一步提升模型的性能。

3.3.4 实验2.4：排序指令

在缺乏ORDER BY指令时，基于LLM的在Spider与BIRD两个数据集上均优于基于PLM的方法。但当引入ORDER BY指令后，情况在Spider数据集上发生了逆转，基于LLM的方法表现稍逊一筹，而在BIRD数据集上则依旧保持领先。这种差异可能源于BIRD数据集的复杂度高于Spider。

洞察5 ：在涉及ORDER BY指令的场景中，基于PLM和LLM的智能体在不同数据集间的表现呈现出差异。大体来看， 基于LLM的智能体展现出了更优越的泛化能力 。

3.4 实验3：查询变异性测试（Query Variance Testing，QVT）

检验nl2sql系统对多样化自然语言表述和结构的适应力，模拟实际应用中可能遇到的丰富场景。

在BIRD数据集中，很少有SQL查询与多个不同的自然语言表达相对应。因此，选用了Spider开发集来构建QVT数据集，它包含了469个SQL查询，每个都对应着两个以上的不同自然语言查询，这正符合QVT的初衷。

如上图，基于LLM的智能体与基于PLM的智能体在QVT方面难分伯仲。

不过，经过微调的LLM智能体通常在QVT上表现更佳，可能是因为微调使得模型输入与特定数据分布更加吻合，从而减少了自然语言变化对性能的冲击。

值得注意的是，尽管Graphix+PICARD方法在整体执行准确度（EX）上不及其他基于提示的智能体，却在QVT上超越了它们。

洞察6 ：在QVT方面，基于LLM与基于PLM的智能体并无明显优劣之分。针对特定任务数据集对模型进行微调，可能有助于提高其在面对自然语言变化时的性能稳定性。

3.5 实验4：数据库领域适配

在自然语言到SQL的实际应用案例中，往往需要处理特定领域的数据库，比如电影或体育领域，各自拥有独特的架构设计和专业术语。因此，跨不同领域的细致表现评估对于模型的有效应用极为关键。

对Spider训练集中的140个数据库和开发集中的20个数据库进行了分类，共划分出33个不同的领域。所有基于微调的LLM和PLM智能体均使用训练集进行调优。

上图展示了Spider数据集中，不同数据库领域内的执行准确度（EX）表现。不同的自然语言到SQL方法对不同领域有着不同的偏好，基于LLM和基于PLM的智能体并没有明显的优劣之分。

上图展示了整体表现。在拥有较多训练数据库的领域（如大学、竞赛、交通），基于微调的方法表现更佳。而在训练数据库较少的领域，基于提示的方法则更为出色。这说明，在微调阶段引入领域内的训练数据对于提升模型在特定领域的性能至关重要。

洞察7 ：不同方法对不同领域有着不同的偏好，基于LLM和基于PLM的智能体并无绝对的胜出者。不过，在微调阶段的领域内训练数据对于模型在特定领域的表现极为重要。

3.6 实验5：LLM智能体的监督式微调

探究在自然语言转SQL任务中，对开源大型语言模型（LLM）进行监督式微调（SFT）的效果。

DAILSQL 在SFT过程中，不同样本量和提示表述的影响，但并未明确指出哪些开源LLM最适合用于自然语言转SQL任务的SFT。采用SQL风格的提示对提升效果有益，因此在零样本设置中也采取了类似的提示策略，如下图。

考虑到自然语言转SQL任务与代码编写密切相关，挑选了五款具有不同代码处理能力的开源LLM，并通过HumanEval (Pass@1) 指标进行了评估。

如上图，经过SFT，各模型的性能（EX）均有提升，但提升幅度在不同基础模型间差异显著。

性能提升与模型在SFT前的内在编码能力（HumanEval）之间存在正相关关系。这表明，选择具有优秀编码能力的LLM作为基础模型，对于适应自然语言转SQL任务大有裨益。

洞察8 ：在对开源LLM进行自然语言转SQL任务的监督式微调（SFT）后，发现SFT后的性能与模型在SFT前的固有编码能力之间存在正相关。这说明， 具备高级编码能力的LLM是适应自然语言转SQL任务的关键 。

3.7 实验6：基于LLM的方法的经济性

考虑到国内模型很便宜，这部分感觉意义不大，直接看洞察

洞察9 ：根据执行准确度（EX）与平均成本的比值，发现调用GPT-3.5-turbo的基于提示的LLM智能体具有更高的成本效益。虽然DAILSQL(SC)在Spider和BIRD数据集上相较于DAILSQL在EX上有所提升，但其增加的成本也降低了其整体的成本效益。

3.8 实验7：基于PLM方法的执行效率

对六种模型进行了三项指标的评估：

• 执行准确度（EX）

• 样本延迟

• GPU内存

如上图，随着模型规模的增长，GPU内存消耗和延迟也随之上升。但是，RESDSQL-Base+NatSQL（2.2亿参数）与RESDSQL-Large（7.7亿参数）在执行准确度上表现相近（分别为80.2%和80.1%），而前者在延迟和内存使用上更为经济。同样，RESDSQL-Large+NatSQL与RESDSQL-3B在执行准确度上不相上下，但在延迟和硬件需求上存在差异。因此，在模型的选择上，需要权衡延迟和硬件资源。

洞察10 ：随着模型参数规模的扩大，其延迟和硬件资源的需求也会相应增长。此外，即便性能相近，不同模型在延迟和硬件资源需求上也可能大相径庭。

3.9 实验8：SQL效能探究 - 有效效率评分

在现实世界的运用中，不仅需确保模型产出的SQL查询准确无误，更要注重其执行的高效性。BIRD 提出了有效效率评分（VES，Valid Efficiency Score），用以衡量正确生成的SQL查询的执行效能。

上图展示了实验的成果。橙色标注了最高的VES得分。在各个难度层级的子集中，VES得分最高的方法并不固定，无论是基于LLM还是基于PLM的方法，都未见明显的优势。大体而言，同一方法在处理更为复杂的子集时，往往会有较低的VES表现，这可能与执行难度的增加和所需时间的延长有关。

洞察11 ：依据VES评分，在基于LLM和基于PLM的方法之间，并没有明显的赢家。对于同一方法而言，它在面对更具挑战性的子集时，往往会展现出较低的VES。

3.10 实验9：训练样本数量的效应

无论是基于PLM还是经过微调的LLM方法，随着自然语言到SQL训练数据的增多，性能均有所提升，并在训练样本达到0时获得满意的性能表现。然而，随着数据集规模的扩大，执行准确度（EX）的增益逐渐减少。

洞察12 ：随着自然语言到SQL训练数据的增加，基于PLM和LLM的方法性能均有所提高。但值得注意的是，随着数据集规模的增长，执行准确度（EX）的提升幅度逐渐降低。若数据隐私成为关注点或有足够的标注数据，对LLM/PLM进行微调展现出巨大的潜力。

4. NL2SQL的模块化设计

如上图，可以将NL2SQL方案大致划分为以上模块：

• (1) 预处理阶段：预处理环节涵盖了 架构关联和数据库 内容两大核心。架构关联将自然语言查询指向数据库架构元素（例如表和列），从而提升了跨领域通用性和复杂查询的生成能力。数据库内容模块通过字符串匹配，常常用于将查询条件与数据库内容相匹配，进一步丰富列的细节信息。

• (2) 提示策略：提示策略可分为零样本和少样本两种，零样本策略在模型输入中不包含任何自然语言到SQL的示例，而少样本策略则包含一定数量的示例，如“3样本”、“5样本”等。基于PLM的方法通常偏好零样本策略，而基于LLM的方法则各有千秋：C3SQL采用零样本策略，而DAILSQL和DINSQL则采用少样本策略。DINSQL的少样本示例是人工设计且固定的，相较之下，DAILSQL的示例则是基于目标问题与训练集示例间的相似度动态选择的。

• (3) SQL构建策略：语言智能体在生成SQL时采取多样化的策略，这些策略可归纳为三个核心要素：分步构建、解码技巧和中间表达形式。

• (a) 分步构建，类似于思维链（Chain-of-Thought, COT）的逻辑，通过分阶段构造SQL查询，尤其适合处理复杂查询。两种分步策略：“SQL框架 - SQL”策略源自基于PLM的RESDSQL ，“子查询 - SQL”策略则来自DINSQL 。

• (b) 解码技巧关注的是LLM在解码过程中如何确保输出结果的有效性。基于PLM的PICARD 确保其输出严格遵守SQL语法规则，而基于LLM的方法则通过OpenAI的API进行操作，不受此类解码层面的限制。

• (c) 中间表达形式策略探讨是否采用某种中介查询格式来弥合自然语言与SQL之间的差异，因为SQL面向关系数据库的设计并不总是与自然语言的语义相吻合。市场上已经出现了诸如NatSQL等多样化的解决方案。基于LLM的DINSQL 和若干基于PLM的方法都采用了NatSQL。

• (4) 后处理：考虑了以下几类后处理策略：

• (a) 自我纠错，由DINSQL 提出，它允许智能体对生成的SQL进行自我审查，以修正潜在的错误。

• (b) 自我一致性检查，涉及对单一自然语言查询执行多种有效的SQL查询，并通过比对结果的一致性，采用投票机制选出最合适的SQL作为最终结果。这一策略在C3SQL和DAILSQL中得到了应用。

• (c) 执行引导的SQL筛选器，作为一个模块，它依次执行智能体生成的SQL查询，并将首次无误的执行结果作为有效的SQL。

• (d) N-best重排器，通过为多个候选SQL查询打分，挑选出可能性最高的查询作为最终的查询。

5 SuperSQL：顶尖NL2SQL方案

基于以上结论，作者提出了SuperSQL，SuperSQL包括如下组件：

• (1) 预处理：采用RESDSQL的架构链接和BRIDGE v2的数据库内容；

• (2) 提示：DAILSQL的少量样本模块通过相似性挑选上下文中的示例；

• (3) SQL生成：采用OpenAI的贪婪解码策略，不涉及多步骤或NatSQL；

• (4) 后处理：采用DAILSQL的自我一致性模块。

SuperSQL在Spider开发集上对SuperSQL进行评估，EX达到了87.0%，超越了其他方法。

SuperSQL在中等难度、高难度以及额外难度子集上均有出色的表现，证实了其有效性。在BIRD开发集上，SuperSQL同样展现了不俗的性能。

还对Spider和BIRD的测试集进行了SuperSQL评估，在Spider上EX达到了87.0%（排名第二），在BIRD上EX达到了62.66%（排名第九）。

SuperSQL在其设计空间内超越了所有基准。具体来说，在BIRD测试集上，SuperSQL比最强的基准——DAILSQL(SC)——提高了5.25%。这一提升主要得益于我们的NL2SQL360-AAS，它有效地在设计空间内基于不同基准寻找更优的模块组合。预计通过NL2SQL360-AAS加入更多强大的基准将进一步优化SuperSQL。

SuperSQL的高效性能：SuperSQL在两个数据集上分别获得了99.18和61.99的VES总分，均优于其他方法。

6 未来研究方向

• 提升自然语言到SQL方法的可信度：现有方法可能产生不准确的SQL结果，原因可能包括：

• 1.自然语言查询含糊且不完整

• 2.数据库架构模糊且内容不规范

• 3.架构链接能力不足。

• 应对含糊和不明确的自然语言查询：考虑以下策略来改善这些问题：

• (i) 查询改写器旨在自动优化给定的自然语言查询，确保其明确性。

• (ii) 查询自动补全通过推荐与数据库高度相关的候选词汇，协助用户构建查询。

• 解析自然语言到SQL的解决方案。

• (i) 自然语言到SQL调试工具能够发现错误的SQL查询，允许用户逐步跟踪SQL生成流程，并辅助识别错误或不匹配之处。

• (ii) SQL及查询结果的解释方法使用户能够评估生成的SQL和查询结果是否符合预期。

• 打造高性价比的自然语言到SQL方法。基于LLM的自然语言到SQL方法前景广阔，但在令牌消耗上成本较高，这影响了成本和推理时间。探索在减少令牌使用的同时提升准确性的方法至关重要。特

• 自适应训练数据生成。自然语言到SQL方法的有效性极大程度上依赖于训练数据的质量和广度。这些方法在适应未知数据库时常常遇到挑战。一个充满希望的研究方向是利用模型评估反馈动态生成（自然语言，SQL）对，这种方法通过从自然语言到SQL的性能洞察中汲取经验，确保训练数据的多样性和高质量，解决领域适应问题。

本文转载自​​，作者：