NL2SQL基础系列(1)：业界顶尖排行榜、权威测评数据集及LLM大模型（Spider vs BIRD）全面对比优劣分析[Text2SQL、Text2DSL]

Text-to-SQL（或者Text2SQL），顾名思义就是把文本转化为SQL语言，更学术一点的定义是：把数据库领域下的自然语言（Natural Language，NL）问题，转化为在关系型数据库中可以执行的结构化询语言（Structured Query Language，SQL），因此Text-to-SQL也可以被简写为NL2SQL。

• 输入：自然语言问题，比如“查询表t_user的相关信息，结果按id降序排序，只保留前10个数据”
• 输出：SQL，比如“SELECT * FROM t_user ORDER BY id DESC LIMIT 10”

使用 NL2SQL 的技术方案，用户与数据库之间的距离可以进一步缩短，用户可以更自由地查询更多信息、表达自己更丰富的查询意图，还可以减轻目前技术方案的繁琐，解放开发人员。

1.NL2SQL情况

1.1 NL2SQL的发展历史

NL2SQL的历史要追溯到1973年，Woods等人开发了一个名为LUNAR的系统，主要用来回答从月球带回来的岩石相关的问题。1978年，Hendrix设计了一个名叫LIFER/LADDER的接口，可以通过自然语言查询数据库。但是上面提到的系统都是针对特定数据库开发的，而且只支持单表操作。2008年，Siasar等人基于句法和语义知识的基本概念提出了专家系统，并提出一个能够从多个结果中选择一个合适查询语句的算法。2010年，Rao等人提出了一个包含简单和隐式查询的系统。2013年，Chaudhari使用原型技术实现了一个能够处理简单查询和聚合函数的系统。虽然这些系统能够生成不同的查询语句，但依然无法支持多表关联的问题。2014年，Ghosh等人基于Chaudhari的研究成果，在其基础上又开发了一个自动查询生成器，它采用语音或自然语言文本作为输入，支持简单的嵌套查询和聚合操作，同时系统还能够处理那些明确指出的属性。同年，Reinaldha和Widagdo使用了不同的方法来研究用户不同形式的输入，他们采用语义规则来找出问题中出现的词与数据库中的属性之间的关系。2015年，Palakurthi等人提供了与属性类型和分类特征相关的信息，描述了不同属性出现在句子中的处理方式也是不一样的。2016年，Ghosal等人提出了一个系统，能够很好地处理多表简单查询，不过系统使用的数据字典有限。同年，Kaur and J, Jan 强化了系统的简单查询和连接操作，但不支持聚合函数、GROUPBY和HAVING等高级子句。Singh and Solanki也提出了一种将自然语言转为sql查询的算法。他们使用动词表、名词表和规则将属性和表映射到句子中的单词，系统还灵巧地处理了文本的模糊输入。2017年，Google开发了Analyza系统，一个以自然语言为人机交互的接口的系统，支持用户用自然语言做数据探索与数据分析。该系统已在Google两个产品中投入使用，一是Online Sheet产品的QA问答模块，二是提供了一个库存和收入数据数据库的一个访问入口。同年，Sukthankar, Nandan等人开发了nQuery系统，一个自然语言到SQL的查询生成器，支持聚合函数，以及where子句中的多个条件、高级子句（如order by、group by和having）操作。2018年，Utama, Prasetya等人开发了DBPal工具，一个面向数据库的端到端的自然语言接口。DBPal主要有两大特性，一是采用深度模型将自然语言语句转为SQL，二是在用户不知道数据库模式和查询特性的情况下，支持短语提问，同时支持用户查询扩展提示，有助于提高查询效果。

1.2 NL2SQL 业内情况

1.2.1 测评指标

Text-to-SQL任务的评价方法主要包含两种：精确匹配率（Exact Match, Accqm）、执行正确率（Execution Accuracy, Accex）

• Execution Accuracy (EX) [paper]

  • 定义：计算SQL执行结果正确的数量在数据集中的比例，结果存在高估的可能。

• Exact Match (EM) [paper]

  • 定义：计算模型生成的SQL和标注SQL的匹配程度，结果存在低估的可能。

精确匹配率指,预测得到的SQL语句与标准SQL语句精确匹配成功的问题占比。为了处理由成分顺序带来的匹配错误，当前精确匹配评估将预测的SQL语句和标准SQL语句按着SQL关键词分成多个子句，每个子句中的成分表示为集合，当两个子句对应的集合相同则两个子句相同，当两个SQL所有子句相同则两个SQL精确匹配成功；

执行正确指，执行预测的SQL语句，数据库返回正确答案的问题占比。

1.2.2 业界排行榜

1.3 相关论文综述

• (2023-International Conference on Very Large Data Bases, VLDB, CCF-A）A survey on deep learning approaches for text-to-SQL [paper]
• (2022-IEEE Transactions on Knowledge and Data Engineering, TKDE, CCF-A) A Survey on Text-to-SQL Parsing: Concepts, Methods, and Future Directions [paper]
• (2022-International Conference on Computational Linguistics, COLOING, CCF-B) Recent Advances in Text-to-SQL: A Survey of What We Have and What We Expect [paper]
• (2022-arXiv)Deep Learning Driven Natural Languages Text to SQL Query Conversion: A Survey [paper]

2.业内标准数据集介绍

2.1 数据集汇总

• 根据包含领域数量，数据集分为单领域和多领域。
• 根据每个数据库包含表的数量，数据集分为单表和多表模式。在多表模式中，SQL生成涉及到表格的选择。
• 根据问题复杂度，数据集分为简单问题和复杂问题模式，其中问题复杂度由SQL查询语句涉及到的关键词数量、嵌套层次、子句数量等确定。
• 根据完整SQL生成所需轮数，数据集分为单轮和多轮。
• 若SQL生成融进渐进式对话，则数据集增加“结合对话”标记。当前只有CoSQL数据集是融进对话的数据集。

• WikiSQL [paper] [code] [dataset]

  • 2017年9月，Salesforce提出的一个大型的Text-to-SQL数据集，数据来源于Wikipedia，属于单领域，包含了80654个自然语言问题，77840个SQL语句，SQL语句形式比较简单，不包含排序、分组、子查询等复杂操作。包含了 24,241张表，80,645条自然语言问句及相应的SQL语句。由于该数据集的sql形式简单，不支持多列选择，or、group by、order by、limit等操作，而且只支持单表操作，所以相对而言任务比较简单，目前学术界的预测准确率最高可达93%+。
  • WikiSQL的问题长度8~15个词居多，查询长度8~11个词居多，表的列数5~7个居多，另外，大多数问题是what类型，其次是which、name、how many、who等类型。

  

• Spider [paper] [code] [dataset]

  • 2018年9月，耶鲁大学提出的多数据库、多表、单轮查询的Text-to-SQL数据集，也是业界公认难度最大的大规模跨领域评测榜单，包含了10181个自然语言问题，5693个SQL语句，涉及138个不同领域的200多个数据库，难易程度分为：简单、中等、困难、特别困难。2024年2月，耶鲁大学开源了Spider1.0排行榜单的test数据集，并且他们将在3月开源Spider 2.0数据集。

  

• SParC [paper] [code] [dataset]

  • 2019年6月，耶鲁大学提出了一个大型数据集SParC，用于复杂、跨域、上下文相关（多轮）语义解析和Text-to-SQL任务，该数据集由4298个连贯的问题序列组成（有12k+个自然语言问题到SQL标注的Question-SQL对，由14名耶鲁大学学生标注），通过用户与138个领域的200个复杂数据库的交互获得。

  

• CSpider [paper] [code] [dataset]

  • 2019年9月，西湖大学提出了一个大型中文数据集CSpider，用于复杂和跨领域的语义解析和Text-to-SQL任务，由2位NLP研究人员和1位计算机专业学生从数据集Spider翻译而来，其中包含200个数据库上的10181个问题和5693个独特的复杂SQL查询，具有涵盖138个不同领域的多个表的数据库。

  

• CoSQL [paper] [code] [dataset]

  • 2019年9月，耶鲁大学和Salesforce Research提出了一种跨域数据库CoSQL，它由30k+轮次和10k+带注释的SQL查询组成，这些查询是从Wizard-of-Oz (WOZ)集合中获得的，该集合包含3k个对话，查询跨越 138个域的200个复杂数据库。它是Spider的升级版本，包含3w+轮对话和1w+带注释的SQL查询，这些查询来源于138个域的200个复杂数据库，每一轮对话都模拟了一个实际的数据库查询场景。因此需要结合多轮对话的内容生成最终的sql，是目前最复杂难度也最高的数据集之一。

  

• TableQA [paper] [dataset]

  • 2020年6月，追一科技公司提出了一个大规模跨领域Text-to-SQL数据集TableQA，其中包含64891个问题和6000多个表的20311个唯一SQL查询。

  

• DuSQL [paper] [dataset]

  • 2020年11月，百度针对跨域文本到SQL任务提出了一个大规模、实用的中文数据集DuSQL，它包含200个数据库、813个表和23797个Question-SQL对。

  

• CHASE [paper] [code] [dataset]

  • 2021年8月，西安交通大学和微软等提出了首个跨领域、多轮Text-to-SQL中文数据集，包含了5459个多轮问题组成的列表，17940个<query, SQL>二元组。

    

• BIRD-SQL [paper] [code] [dataset]

  • 2023年5月，香港大学和阿里巴巴提出了一个大规模跨域数据集BIRD，其中包含超过12751个独特的问题 SQL、95个大数据库，总大小为33.4GB。它还涵盖区块链、曲棍球、医疗保健和教育等超过37个专业领域。

  

• KaggleDBQA [paper] [code] [dataset]

  • 2021年6月，华盛顿大学和微软研究院提出了KaggleDBQA，这是一个真实Web数据库的跨域评估数据集，具有特定领域的数据类型、原始格式和不受限制的问题。 它包括跨 8 个数据库的 272 个示例，每个数据库平均有 2.25 个表。 该数据集以其真实世界的数据源、自然的问题创作环境以及具有丰富领域知识的数据库文档而闻名。 主要统计数据：8.7% WHERE 子句、73.5% VAL、24.6% SELECT 和 6.8% NON-SELECT。

  

2.2 在Spider 和BIRD榜单情况

• Spider

Spider 1.0与大多数先前的语义解析任务不同，因为：ATIS、Geo、Academic：它们各自仅包含一个数据库，SQL查询数量有限，且训练和测试集中SQL查询完全相同。WikiSQL：SQL查询和表的数量显著增多。但所有SQL查询都很简单，每个数据库仅是单一表，没有外键。Spider 1.0在图中占据最大面积，是首个复杂且跨领域的语义解析和文本到SQL数据集！

Leaderboard - Execution with Values

Leaderboard - Exact Set Match without Values

• BIRD

案例：

LLM排名：

3.大模型在NL2SQL上对比

基于论文：Battle of the Large Language Models: Dolly vs LLaMA vs Vicuna vs Guanaco vs Bard vs ChatGPT - A Text-to-SQL Parsing Comparison (2023.10)结果进行对比

本文对六种语言模型进行了综合评估：Dolly、LLaMA、Vicuna、Guanaco、Bard 和 ChatGPT，利用五种不同的提示策略，直接比较它们在九个基准数据集上的性能。

我们的主要发现是：

• 在大多数文本到 SQL 数据集中，开源模型的性能明显低于闭源模型。
• 虽然LLM在生成语法上有效的 SQL 语句方面表现出熟练程度，但他们通常很难生成语义上准确的查询。
• 事实证明，LLM 对用于小样本学习( few-shot learning)的示例高度敏感。

3.1 提示词策略

• Informal Schema (IS) ：非正式模式 (IS) 策略以自然语言提供表及其关联列的描述。在这种方法中，模式信息以不太正式的方式表达。
• API Docs (AD) ：相比之下，Rajkumar (2022)等人进行的评估中概述的 API 文档 (AD) 策略，遵循OpenAI 文档4中提供的默认 SQL 翻译提示。此提示遵循稍微更正式的数据库模式定义。
• Select 3 ：Select 3 策略包括数据库中每个表的三个示例行。 此附加信息旨在提供每个表中包含的数据的具体示例，以补充模式描述。
• 1SL：1-Shot Learning (1SL)，在提示中提供 1 个黄金示例。
• 5SL ：5 Shot Learning (5SL) ，在提示中提供 5 个黄金示例。

3.2 在Spider和8大传统数据集表现

• 数据集简介

• 在spider 数据集表现

  

* 开源模型在 Spider 数据集上遇到了困难：尽管参数数量和模型性能之间存在正相关关系，但开源模型在 Spider数据集上实现高精度方面面临着挑战。 例如，尽管 Vicuna 7B 和 13B 已证明比原始预训练的 LLaMA 7B 和 13B模型有所改进，但与 Bard 和 GPT-3.5 相比，性能仍然存在显着差距。 此外，与 LLaMA 的 13B 版本相比，Dolly模型在不同的提示策略上也表现不佳。

* LLM的表现对提示风格高度敏感：我们的实证研究结果证实，不存在适用于所有模型的通用提示策略。 虽然 IS 提示策略对于GPT-3.5、Bard、Vicuna 和guanaco 被证明是有效的，但对于 Dolly 和 LLaMA 来说却产生了次优的准确度。令人惊讶的是，LLaMA 在使用 S3 提示时实现了最佳结果，相比之下，GPT-3.5 的性能显著恶化。

* 使用随机示例的小样本学习提供的性能提升有限：从 1SL 和 5SL获得的大多数结果往往表现不佳，或者充其量只能达到与其他提示策略相当的结果。 然而，这种趋势也有一些例外。 Dolly 模型是一个例外，与12B 变体中的其他提示策略相比，该模型显示 1SL 提示策略的性能有所提高。 这个结果似乎是反常的，因为在其他 1SL 和 5SL结果中没有观察到类似的性能提升。 另一个例外是 LLaMA 模型，其中少样本提示策略优于一些零样本策略。 例如，30B LLaMA模型仅用 5 个给定示例就实现了 22.4% EX 和 19.9% TS 准确率，这接近于guanaco 模型的性能（24.4% EX 和19.0% TS）。

更多模型的表现：

闭源模型如GPT和BARD在NL2SQL任务中显著优于开源模型，这得益于它们接受了更多的参数训练。通过额外的监督微调，模型性能得到显著提升，例如Alpaca-7B模型相比其前身Llama-7B改进了近16%，突显了微调对性能增强的潜力。与此同时，较新的开源模型如Mistral-7B和Llama2性能更优，正逐步缩小与闭源模型的差距。

• 经典数据集下情况

  

* LLM在大多数经典数据集上表现不佳：特别是，与之前研究中报告的基线性能相比，这些数据集上达到的最高准确率分别仅为 2.9% 和 2.4%，明显低于使用 LSTM 或 BERT 的传统 seq2seq模型的其他研究中观察到的基线结果 34.0% 和 45.2%（Devlin 等人， 2019）。此外，即使进行了指令调整，Vicuna、Guanaco 和 Dolly 在经典数据集上也面临着相当大的挑战。它们在各种提示策略和数据集组合中的执行精度通常几乎为零。

* 不同模型的少样本学习的有效性有所不同：与 Spider 数据集的发现相比，我们观察到 LLaMA 和 GPT-3.5 在 1SL 和5SL 上的性能有所改进。 例如，使用 1SL，GPT-3.5 在 GeoQuery 数据集上的性能从 15.4% 提高到42.3%，而使用 5SL，LLaMA 在同一数据集上的性能也从 12.1% 显着提高到 15.4%。 然而，我们没有看到 Dolly、Vicuna 和 Bard 的 1SL或 5SL 具有类似的性能改进。

* 附加数据库示例行是无效的：就像使用Spider数据集观察到的结果一样，S3 提示策略在应用于不同模型的经典数据集时会产生低于标准的结果。因此，很明显，S3 提示策略在 Text-to-SQL 环境中可能并不有效。

3.3 大模型在SQL生成效果分析

大型语言模型在生成SQL语句时常表现不佳，可能因为它们难以理解提示背后的真实意图。我们在多个数据集上测试了不同模型，发现除Dolly外，大多数模型在特定提示策略下能生成90%以上的有效SQL。尽管LLaMA未经指令数据集的微调，它仍能生成有效SQL。然而，开源模型如Vicuna和Dolly在达到高有效SQL百分比方面存在挑战。值得注意的是，LLaMA通过小样本学习提升性能，而guanaco则随着示例增多性能下降。另外，某些提示策略并不理想，尤其是S3策略，它显著降低了GPT-3.5在多个数据集上的有效SQL生成率。尽管模型能生成SQL，但语义不准确，导致执行精度低。

更多分析结果见原始论文

参考链接

https://blog.csdn.net/sinat_3...

更多优质内容请关注公号：汀丶人工智能；会提供一些相关的资源和优质文章，免费获取阅读。