自然语言到 SQL 的曙光:我们准备好了吗?

发布于:2024 年 10 月 08 日

各位读者,国庆假期已过,我们打工人要开启奋斗新征程了,今天小编也是刚上班假期综合征还没过去,就被抓过来读论文,还好我在假期没闲着,整理了几篇关于 NL2SQL 的最新论文跟大家分享。

在当今数字化时代,将用户的自然语言问题转换为SQL查询(nl2sql)对于降低访问关系数据库的门槛具有重要意义。随着大型语言模型(LLM)的出现,nl2sql任务的性能得到了显著提升,但这也引发了一个关键问题:我们是否已经完全准备好在生产环境中部署nl2sql模型?

一、nl2sql的发展历程与研究背景

(一)nl2sql方法的演进

![](https://img-blog.csdnimg.cn/img_convert/3c5e6e7d305329e8b1407ab51a167439.png)

从图1和图2可以看出,nl2sql 方法在过去二十年中经历了从 基于规则 的方法、**基于神经网络 **的方法、基于可调节预训练语言模型(PLM )到基于大型语言模型(LLM)的演变。早期的基于规则的方法如 NaLIR,依赖于预定义规则或语义解析器,适应性、可扩展性和泛化能力有限。随着神经网络的发展,出现了像IRNet这样的序列到序列方法。2017年左右,Transformer和Spider数据集的引入推动了基于PLM的方法的兴起,例如BERT和T5等模型在基准数据集上取得了很好的结果。而近年来,ChatGPT和GPT - 4等大型语言模型的出现使基于LLM的方法占据了主导地位。

(二)现有研究的局限性

  1. **忽视使用场景:**现有评估通常报告在整个基准数据集(如 Spider)上的总体结果,缺乏对特定数据子集的详细比较。例如,没有根据不同的 SQL 特性或数据库领域进行区分,无法深入了解不同 nl2sql 模型对于特定 SQL 查询类型或特定领域场景的相对有效性。 2. **缺乏直接和全面的比较:**许多基于 LLM 和 PLM 的 nl2sql 解决方案没有在成熟的基准和定制数据集上进行系统的比较。 3. **对 nl2sql 设计空间的探索有限:**当前的 nl2sql 研究和实践在使用 LLM 和 PLM 模块探索 nl2sql 框架的设计空间方面存在局限,限制了我们对如何协同整合不同架构和功能模块以增强 nl2sql 解决方案的理解。

二、NL2SQL360 评估框架

(一)框架概述

![](https://img-blog.csdnimg.cn/img_convert/3267fb2253f336c1ae6c43a32c12a730.png)

为了解决上述问题,本文提出了一个多角度的nl2sql评估框架NL2SQL360,其框架如图4所示,包含六个核心组件。

  1. 基准数据集(Benchmark Datasts)
    维护了广泛使用的基准数据集,如Spider、BIRD、Spider-Realistic、Dr.Spider、KaggleDBQA、WikiSQL 等。
  2. 模型库(Model Zoo)
    包含了在 Spider 和 BIRD 排行榜上的一系列有竞争力的开源 nl2sql 模型,主要包括基于 LLM 和基于 PLM 的方法。
  3. 数据集过滤(Dataset Filter)

引入了数据集过滤机制,可根据不同标准将测试数据集分离为更有针对性的子集。例如:

  • SQL 复杂性(SQL Complexity)**:从简单到复杂的查询进行分类,以评估nl2sql方法处理不同难度SQL的能力。

  • SQL 特性(SQL Characteristics)** :针对主要使用特定功能(如JOIN操作、子查询或聚合函数)的SQL查询进行分类,评估系统处理不同SQL功能的能力。

  • 数据领域(Data Domains)**:探索系统在不同数据领域(如金融、医疗保健和零售)的性能,评估领域特定的能力和潜在限制。

  • 查询方差测试(Query Variance Testing)** :评估nl2sql系统在处理自然语言查询变化时的稳健性和灵活性。

  1. 评估器(Evaluator)

利用日志数据自动生成定量评估,并以易于理解的表格或排行榜形式呈现。还提供可视化工具和仪表板进行交互式分析,方便用户比较不同维度的nl2sql解决方案。

  1. 评估指标(Evaluation Metrics)

采用了一系列广泛接受的指标,包括执行准确率(Execution Accuracy,EX)和精确匹配准确率(Exact Match Accuracy,EM)来评估生成的 SQL 查询的有效性,使用有效效率得分(Valid Efficiency Score,VES)来衡量生成有效 SQL 查询的效率。此外,还提出了查询方差测试(Query Variance Testing)这一新指标,用于评估模型对不同形式的自然语言查询的适应能力。

  1. 执行器和日志(Executor and Logs)

用户可以定制 nl2sq l模型的评估工作流程,设置超参数和指标等参数。测试床会自动在基准数据集和自定义子集上运行模型,并记录所有结果,这些日志为模型分析提供了详细的见解。

(二)实验设置与结果分析

  1. **实验设置** 使用 Spider 和 BIRD 数据集的开发集作为实验数据集,包含1034和1534个(nl,sql)样本。评估了 13 种基于 LLM 和 7 种基于 PLM 的 nl2sql 方法,比较了不同方法在准确性、效率等方面的性能。 2. **准确性实验结果**![](https://img-blog.csdnimg.cn/img_convert/437c8b0797bb7f10f70f58135923a3d6.png)![](https://img-blog.csdnimg.cn/img_convert/fcab03e570607c57a0efcbe4896fe2dc.png) - **准确性与SQL复杂性** 从表3和表4可以看出,在不同难度的SQL子集上,基于LLM的方法在执行准确率(EX)指标上超过基于PLM的方法,而基于PLM的方法在精确匹配准确率(EM)指标上总体表现更好。这表明微调是提高性能的重要策略,基于LLM的方法微调后在EX指标上表现最佳,基于PLM的方法在EM指标上表现最佳。 - **准确性与SQL特性**![](https://img-blog.csdnimg.cn/img_convert/c509ecf946e082d75c5c8c2fa0736283.png) - ![](https://img-blog.csdnimg.cn/img_convert/c4a431531310095c017ec41c3803db23.png) * **子查询(Subquery)**:如图5、图6和图7所示,所有方法在处理子查询时表现最差,但基于LLM的方法在有子查询的场景中总体上优于基于PLM的方法,尤其是使用 GPT-4 的方法表现更好,这表明模型的内在推理能力对处理子查询至关重要。 * **逻辑连接器(Logical Connector)**:在需要逻辑连接器的场景中,基于LLM 的方法优于基于PLM的方法。 * **JOIN操作**:在涉及JOIN操作的场景中,基于LLM的方法也表现出优势,将NatSQL作为中间表示可以降低预测JOIN操作的复杂性并可能提高模型性能。 * **ORDER BY**:在有ORDER BY子句的场景中,基于PLM和LLM的方法在不同数据集上的性能有所不同,一般来说基于LLM的方法具有更强的泛化能力。 - **查询方差测试**:![](https://img-blog.csdnimg.cn/img_convert/1fcdab48a5bd623eb44578beea556065.png)从图8可以看出,在查询方差测试(QVT)指标上,基于LLM和基于PLM的方法没有明显的胜者,但微调后的LLM通常比提示的LLM具有更高的QVT,这可能是由于微调后模型输入与特定数据分布对齐,减少了自然语言变化对性能的影响。 - **数据库领域适应性**:![](https://img-blog.csdnimg.cn/img_convert/06ceee93625ea1c43fca79e2eff03a67.png)如图9所示,不同的 nl2sql 方法对不同领域表现出不同的偏向,基于LLM和基于PLM的方法之间没有明显的胜者。但微调后的方法在有更多训练数据库的领域表现更好,而提示的方法在训练数据库较少的领域表现出色,这表明微调过程中的领域内数据对特定领域的模型性能至关重要。 3. **效率实验结果** - **基于LLM的方法的经济性**:从表5可以看出,基于提示的LLM方法中,调用GPT-3.5-turbo的方法在执行准确率与平均成本的比率上更高,具有更高的成本效益。虽然 DAILSQL(SC)在执行准确率上有所提高,但成本也增加,降低了成本效益。 - **基于PLM的方法的效率**:从表6可以看出,随着模型大小的增加,GPU内存和延迟也会增加。不同的基于PLM的方法在执行准确率、延迟和GPU内存使用方面表现不同,模型选择应考虑延迟和硬件资源。

三、nl2sql设计空间探索与SuperSQL模型

(一)设计空间探索

  1. **预处理(Pre - Processing)** 包括模式链接和数据库内容模块。模式链接将自然语言查询引用映射到数据库模式元素,增强跨领域通用性和复杂查询生成;数据库内容模块将查询条件与数据库内容对齐。 2. **提示策略(Prompting Strategy)** 分为 zero-shot和 few-shot策略。PLM-based方法通常使用 zero-shot,而 LLM-based 方法则有所不同,如C3SQL采用 zero-shot,DAILSQL和DINSQL使用 few-shot。 3. **SQL生成策略(SQL Generation Strategy)** 包括多步、解码策略和中间表示三个关键方面。不同的方法采用不同的策略,如PLM - based的RESDSQL采用"sql skeleton-sql"的多步策略,LLM-based的 DINSQL 采用"Subquery-sql"的多步策略;PLM-based 的 PICARD 采用强制 SQL 语法合规的解码策略,而 LLM-based 方法缺乏这种解码级别的限制;一些方法采用 NatSQL 作为中间表示来解决自然语言到 SQL 翻译的不匹配问题。 4. **后处理(Post - Processing)** 包括自我纠正、自我一致性、执行引导的SQL选择器和 N-best重排器等策略。

(二)NL2SQL360 - AAS 算法与 SuperSQL 模型

  1. **NL2SQL360 - AAS 算法** 受到神经架构搜索(NAS)算法的启发,在 NL2SQL360 框架内设计了 nl2sql 自动化架构搜索算法(NL2SQL360 - AAS)。该算法包括初始化、个体选择、nl2sql 模块交换和 nl2sql 模块突变四个主要步骤,旨在自动探索 nl2sql 解决方案的预定义设计空间,以找到更好的 nl2sql 个体。 2. **SuperSQL模型** 通过 NL2SQL360 - AAS 算法在 Spider 开发集上搜索得到的 SuperSQL 模型,其组成如下: - **预处理**:采用 RESDSQL 的模式链接和 BRIDGE v2 的数据库内容模块。 - **提示**:使用 DAILSQL的 Few-shot模块按相似性选择上下文示例。 - **SQL生成**:采用OpenAI的贪婪解码策略,不使用多步或NatSQL。 - **后处理**:采用DAILSQL的自我一致性策略。 SuperSQL在Spider和BIRD测试集上分别取得了87.0%和62.66%的执行准确率,在执行准确率、效率和经济性等方面均表现出色,优于其设计空间内的所有基线模型。

四、研究机会与未来方向

(一)提高nl2sql方法的可信度

  1. **处理模糊的自然语言查询** 可以探索查询重写器自动优化自然语言查询,以及查询自动完成帮助用户制定查询的策略。 2. **解释nl2sql解决方案** 开发nl2sql调试器检测错误的SQL查询,以及SQL和查询结果解释方法帮助用户评估结果是否符合要求。

(二)开发具有成本效益的nl2sql方法

基于LLM的nl2sql方法在令牌消耗方面成本较高,探索模块化nl2sql解决方案和多智能体框架,结合LLM优化准确性和效率是未来的研究方向。

(三)自适应训练数据生成

nl2sql方法的有效性很大程度上取决于训练数据的质量和覆盖范围,动态生成(nl,sql)对使用模型评估反馈是一个有前途的研究方向,可以解决领域适应问题并确保训练数据的多样性和高质量。

五、结论

本文提出了NL2SQL360评估框架,从多个角度对nl2sql方法进行了评估和分析。通过实验研究得出了一系列关于nl2sql方法性能的新发现,并利用NL2SQL360探索了nl2sql解决方案的设计空间,自动搜索得到了SuperSQL模型。SuperSQL模型在不同的数据集和测试指标上表现出色,为nl2sql任务提供了一种有效的解决方案。同时,本文还指出了未来nl2sql研究的几个方向,包括提高方法的可信度、开发成本效益高的方法和自适应训练数据生成等。这些研究成果为nl2sql领域的进一步发展提供了重要的参考和指导。


:::info

论文地址:https://arxiv.org/pdf/2406.01265

The Dawn of Natural Language to SQL: Are We Fully Ready?

代码地址:https://github.com/HKUSTDial/NL2SQL360

原文链接:https://mp.weixin.qq.com/s/BCxFZ2EV1xh-VlYYyR1FgQ

:::

希望这篇文章能让您对论文的核心内容有更深入的了解,如果您有任何问题或建议,欢迎在评论区留言。

相关推荐
野猪亨利6678 分钟前
Qt day1
开发语言·数据库·qt
Juchecar22 分钟前
给AI装上“手脚”:大模型如何自动执行复杂任务?
人工智能
本就一无所有 何惧重新开始25 分钟前
Redis技术应用
java·数据库·spring boot·redis·后端·缓存
isaki13728 分钟前
qt day1
开发语言·数据库·qt
长鸳词羡32 分钟前
LoRA微调
人工智能·深度学习·机器学习
流星白龙37 分钟前
【Qt】4.项目文件解析
开发语言·数据库·qt
小钻风336637 分钟前
HTTPS是如何确保安全的
网络·数据库
jerryinwuhan1 小时前
Transformer ViT 架构(转载)
人工智能·深度学习·transformer
码农阿豪1 小时前
【征文计划】码上分享:基于 Rokid CXR-M SDK 构建「AI远程协作助手」实战全记录
人工智能·kotlin·sdk·rokid
mahuan1688881 小时前
ITVDesk
人工智能