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

本文主要是介绍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,二是在用户不知道数据库模式和查询特性的情况下,支持短语提问,同时支持用户查询扩展提示,有助于提高查询效果。
😝有需要的小伙伴,可以V扫描下方二维码免费领取🆓

#### 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精确匹配成功;

img

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

img

1.2.2 业界排行榜

img

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 数据集汇总

img

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

img

  • 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等类型。

img

img

  • Spider [

paper

] [

code

] [

dataset

]

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

img

  • SParC [

paper

] [

code

] [

dataset

]

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

img

  • CSpider [

paper

] [

code

] [

dataset

]

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

img

  • 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,是目前最复杂难度也最高的数据集之一。

img

  • TableQA [

paper

] [

dataset

]

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

img

  • DuSQL [

paper

] [

dataset

]

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

img

  • CHASE [

paper

] [

code

] [

dataset

]

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

img

  • BIRD-SQL [

paper

] [

code

] [

dataset

]

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

img

  • 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。

img

2.2 在Spider 和BIRD榜单情况
  • Spider

img

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

Leaderboard - Execution with Values

img

Leaderboard - Exact Set Match without Values

img

  • BIRD

img

img

案例:

img

img

LLM排名:

img

img

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大传统数据集表现
  • 数据集简介

img

  • 在spider 数据集表现

img

  • 开源模型在 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)。

更多模型的表现:

img

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

  • 经典数据集下情况

img

  • 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生成效果分析

img

img

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

资源分享

图片

大模型AGI学习包

图片

图片

资料目录

  1. 成长路线图&学习规划
  2. 配套视频教程
  3. 实战LLM
  4. 人工智能比赛资料
  5. AI人工智能必读书单
  6. 面试题合集

人工智能\大模型入门学习大礼包》,可以扫描下方二维码免费领取

1.成长路线图&学习规划

要学习一门新的技术,作为新手一定要先学习成长路线图方向不对,努力白费

对于从来没有接触过网络安全的同学,我们帮你准备了详细的学习成长路线图&学习规划。可以说是最科学最系统的学习路线,大家跟着这个大的方向学习准没问题。

图片

2.视频教程

很多朋友都不喜欢晦涩的文字,我也为大家准备了视频教程,其中一共有21个章节,每个章节都是当前板块的精华浓缩

图片

3.LLM

大家最喜欢也是最关心的LLM(大语言模型)

图片

人工智能\大模型入门学习大礼包》,可以扫描下方二维码免费领取

这篇关于NL2SQL基础系列(1):业界顶尖排行榜、权威测评数据集及LLM大模型(Spider vs BIRD)全面对比优劣分析[Text2SQL、Text2DSL]的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1080463

相关文章

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门(一):登录与退出》 《Spring-Security-入门(二):基于数据库验证》 《Spring-Security-入门(三):密码加密》 《Spring-Security-入门(四):自定义-Filter》 《Spring-Security-入门(五):在 Sprin

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

Andrej Karpathy最新采访:认知核心模型10亿参数就够了,AI会打破教育不公的僵局

夕小瑶科技说 原创  作者 | 海野 AI圈子的红人,AI大神Andrej Karpathy,曾是OpenAI联合创始人之一,特斯拉AI总监。上一次的动态是官宣创办一家名为 Eureka Labs 的人工智能+教育公司 ,宣布将长期致力于AI原生教育。 近日,Andrej Karpathy接受了No Priors(投资博客)的采访,与硅谷知名投资人 Sara Guo 和 Elad G

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯,先赞后看哦~🎈🎈 🏆 作者简介:景天科技苑 🏆《头衔》:大厂架构师,华为云开发者社区专家博主,阿里云开发者社区专家博主,CSDN全栈领域优质创作者,掘金优秀博主,51CTO博客专家等。 🏆《博客》:Python全栈,前后端开发,小程序开发,人工智能,js逆向,App逆向,网络系统安全,数据分析,Django,fastapi