网站开发使用什么工具,石家庄微信网站建设,生产企业网站建设,男生可以做网站编辑工作吗NL2SQL基础系列(1)#xff1a;业界顶尖排行榜、权威测评数据集及LLM大模型#xff08;Spider vs BIRD#xff09;全面对比优劣分析[Text2SQL、Text2DSL]
Text-to-SQL#xff08;或者Text2SQL#xff09;#xff0c;顾名思义就是把文本转化为SQL语言#xff0c;更学术一…NL2SQL基础系列(1)业界顶尖排行榜、权威测评数据集及LLM大模型Spider vs BIRD全面对比优劣分析[Text2SQL、Text2DSL]
Text-to-SQL或者Text2SQL顾名思义就是把文本转化为SQL语言更学术一点的定义是把数据库领域下的自然语言Natural LanguageNL问题转化为在关系型数据库中可以执行的结构化询语言Structured Query LanguageSQL因此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-AA 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查询完全相同。WikiSQLSQL查询和表的数量显著增多。但所有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 策略包括数据库中每个表的三个示例行。 此附加信息旨在提供每个表中包含的数据的具体示例以补充模式描述。1SL1-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 上的性能有所改进。 例如使用 1SLGPT-3.5 在 GeoQuery 数据集上的性能从 15.4% 提高到42.3%而使用 5SLLLaMA 在同一数据集上的性能也从 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 Text2SQLhttps://github.com/eosphoros-ai/Awesome-Text2SQL/blob/main/README.zh.mdNL2SQL https://github.com/yechens/NL2SQL语义解析 (Text-to-SQL) 技术研究及应用 上篇 https://mp.weixin.qq.com/s/FtsA4O_VTUqhhYS3Gq3G8QBattle 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调研2TableQA Text2SQLhttps://zhuanlan.zhihu.com/p/409001681https://bird-bench.github.io/https://yale-lily.github.io/spider
更多优质内容请关注公号汀丶人工智能会提供一些相关的资源和优质文章免费获取阅读。
