NL2SQL基础系列(1)：业界顶尖排行榜、权势巨子测评数据集及LLM大模型（Spid ...

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的问题长度815个词居多，查询长度811个词居多，表的列数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，但语义不准确，导致执行精度低。
   更多分析效果见原始论文
  参考链接

• Awesome Text2SQL：https://github.com/eosphoros-ai/Awesome-Text2SQL/blob/main/README.zh.md
  
• NL2SQL ：https://github.com/yechens/NL2SQL
  
• 语义解析 (Text-to-SQL) 技能研究及应用 上篇 https://mp.weixin.qq.com/s/FtsA4O_VTUqhhYS3Gq3G8Q
  
• 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)
  
• ODQA调研2：TableQA & Text2SQL：https://zhuanlan.zhihu.com/p/409001681
  
• https://bird-bench.github.io/
  
• https://yale-lily.github.io/spider
  

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。