赞
踩
Text-to-SQL(或者Text2SQL),顾名思义就是把文本转化为SQL语言,更学术一点的定义是:把数据库领域下的自然语言(Natural Language,NL)问题,转化为在关系型数据库中可以执行的结构化询语言(Structured Query Language,SQL),因此Text-to-SQL也可以被简写为NL2SQL。
使用 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,二是在用户不知道数据库模式和查询特性的情况下,支持短语提问,同时支持用户查询扩展提示,有助于提高查询效果。
Text-to-SQL任务的评价方法主要包含两种:精确匹配率(Exact Match, Accqm)、执行正确率(Execution Accuracy, Accex)
Execution Accuracy (EX) [paper]
Exact Match (EM) [paper]
精确匹配率指,预测得到的SQL语句与标准SQL语句精确匹配成功的问题占比。为了处理由成分顺序带来的匹配错误,当前精确匹配评估将预测的SQL语句和标准SQL语句按着SQL关键词分成多个子句,每个子句中的成分表示为集合,当两个子句对应的集合相同则两个子句相同,当两个SQL所有子句相同则两个SQL精确匹配成功;
执行正确指,执行预测的SQL语句,数据库返回正确答案的问题占比。
根据包含领域数量,数据集分为单领域和多领域。
根据每个数据库包含表的数量,数据集分为单表和多表模式。在多表模式中,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]
SParC [paper] [code] [dataset]
CSpider [paper] [code] [dataset]
CoSQL [paper] [code] [dataset]
CHASE [paper] [code] [dataset]
BIRD-SQL [paper] [code] [dataset]
KaggleDBQA [paper] [code] [dataset]
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
案例:
LLM排名:
本文对六种语言模型进行了综合评估:Dolly、LLaMA、Vicuna、Guanaco、Bard 和 ChatGPT,利用五种不同的提示策略,直接比较它们在九个基准数据集上的性能。
我们的主要发现是:
在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 环境中可能并不有效。
大型语言模型在生成SQL语句时常表现不佳,可能因为它们难以理解提示背后的真实意图。我们在多个数据集上测试了不同模型,发现除Dolly外,大多数模型在特定提示策略下能生成90%以上的有效SQL。尽管LLaMA未经指令数据集的微调,它仍能生成有效SQL。然而,开源模型如Vicuna和Dolly在达到高有效SQL百分比方面存在挑战。值得注意的是,LLaMA通过小样本学习提升性能,而guanaco则随着示例增多性能下降。另外,某些提示策略并不理想,尤其是S3策略,它显著降低了GPT-3.5在多个数据集上的有效SQL生成率。尽管模型能生成SQL,但语义不准确,导致执行精度低。
更多分析结果见原始论文
更多优质内容请关注公号:汀丶人工智能;会提供一些相关的资源和优质文章,免费获取阅读。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。