微信扫码
与创始人交个朋友
我要投稿
Text-to-SQL(简写为Text2SQL)是一项将用户的自然语句文本转化为SQL语言的技术,它的官方的定义是:把数据库领域下的自然语言(Natural Language,简写为NL)问题,转化为在关系型数据库中可以执行的结构化查询语言(Structured Query Language,简写为SQL)[1]。因此Text2SQL也常常被写为NL2SQL。
Text-to-SQL的典型任务形式是:给定一个表格信息,输入自然语言文本,输出为SQL语句。
举一个简单的例子:用户想要查询 “平均工资高于整体平均工资的部门的名称和该部门内的最低教师工资”,经过Text2SQL任务解析后,输出SQL语句,执行模块再在数据库中执行SQL,返回执行结果:
输入:自然语言问题:“What are the name and lowest instructor salary of the departments with average salary greater than the overall average?”
输出:SQL语句:“SELECT min(salary), department nameFROM instructor GROUP BY department nameHAVING avg(T1.salary) > (SELECT avq(salary) FROM instructor);"
图1 Text-to-SQL例子[2]
智鸿-共享智能决策引擎(Text-to-sql模块)演示视频:
实际上,Text2SQL 这一任务的本质就是将用户的自然语言语句转化为计算机可以理解并执行的规范语义表示,它是语义分析 (Semantic Parsing) 领域的一个子任务。Text2SQL 是由自然语言生成 SQL语句,同样的业界还有 TEXT2Bash、TEXT2Python、TEX2Java 等自然语言生成程序代码的类似研究。
Text2SQL技术的历史发展可以追溯到自然语言处理和数据库领域的结合。早在上世纪中后期,人们就开始尝试开发通过自然语言直接访问数据库中存储数据的界面(NLIDB,Natural Language Interfaces to Databases),能够支持通过一定的文本语义语言从数据库提取信息。但这种系统对自然语言问题的解析并不依赖于句子成分,这要求每一个具有特定知识的数据库都需要特定的语义语法。所以该方法存在许多问题,无法适应于大多数场景,NLIDB这项技术在那个时代的发展也是极其缓慢的。
直到 2015 年 AI 的复苏和自然语言处理的创新,人们才慢慢把关注拉回了 NLIDB。如何利用自然语言更自然更自由地与数据库交互成为了新兴的研究热点。[3]
以下是近年来Text2SQL领域的发展历程及较为常见的几种研究方法[3&4]:
早期阶段(1980s-2000s):在研究的早期阶段,研究人员主要关注自然语言接口和数据库系统的集成。这些系统通常使用预定义的语法语义,使用户能够通过自然语言查询数据库。然而,由于自然语言的复杂性和灵活性,这些系统往往难以满足用户的需求,普适性很低,并且对语言和语义规则的维护成本很高。
模版-规则匹配方法(2000s-2010s):因为输出SQL本质上是一个符合语法、有逻辑结构的序列,本身具有很强范式结构,所以可以采取基于模板和规则的方法解决问题。在这个阶段,研究人员开始尝试基于规则的Text2SQL方法。这些方法依赖于手工规则模版(如AGG表示聚合函数,完成MAX、COUNT、MIN等任务),然后通过解析自然语言查询并将其转换为SQL查询。在深度学习端到端解决方案流行之前,这一领域的解决方案主要是通过高质量的语法树和词典来构建语义解析器,再将自然语言语句转化为相应的 SQL。这种方法的优点是可解释性强,适用于简单SQL,定义后的sql准确率高。然而,由于自然语言的复杂性和多样性,这种方法对于复杂的查询和语言结构效果不佳,往往难以覆盖所有可能的查询情况,并且对规则的维护和更新成本高。
基于机器学习的方法(2010s至今):随着深度学习和神经网络技术的发展,基于机器学习的Text2SQL方法开始受到关注。这些方法利用大量的训练数据和模型来学习自然语言查询和SQL查询之间的映射关系。Text2SQL任务本质上属于自然语言处理(Natural Language Processing,NLP)。常见的机器学习方法包括序列到序列(Seq2Seq)模型等。序列到序列模型是一种基于序列到序列模型的神经网络架构,它使用编码器-解码器结构,将自然语言查询编码成一个向量,然后解码成对应的SQL语句。这种方法需要大量的训练数据和计算资源,通过训练-提问-预测实现自然语言转换SQL语句,能够拓展SQL生成能力的边界,处理更加复杂的查询。
结合大型预训练模型(2020s至今):进入21世纪20年代,随着大型预训练语言模型(如BERT、GPT等)的出现,研究人员开始探索如何将这些模型应用于Text2SQL任务中。这些大型模型基于庞大的训练数据集,能够更好地理解自然语言的语义和上下文,从而提高Text2SQL系统的性能和准确性。通常的做法是利用预训练的语言模型,通过Fine-tuning的方式来训练一个Text2SQL模型。这种方法在处理自然语言的语义和上下文理解方面表现更好,能够更准确地生成SQL查询语句。
总体而言,Text2SQL技术经历了从规则到基于机器学习的转变,并不断受益于深度学习和大语言模型等技术的进步。随着研究的深入和技术的发展,Text2SQL技术在自然语言处理和数据库查询领域的应用前景将变得更加广阔。
在实际的金融机构场景下,我们采用了结合大型预训练模型的方式对Text2SQL应用服务进行构造。利用预训练语言模型,将自然语言问题和对应的SQL查询组合成一个文本序列,然后将其输入到语言模型中进行理解与语义解析,最终生成可用于数据库内执行的SQL语句。这种方法能够捕捉自然语言问题和SQL查询之间的语义关联。
图2 Text2SQL应用服务流程
但是在将文本转换为SQL查询(Text2SQL任务)的实际应用上,通用的预训练语言模型仍有优化的空间。我们发现目前的模型中存在的一些主要问题包括:
1)输出幻觉(Hallucination):LLM在生成SQL语句时会生成一些看似合理,但实际与输入文本无关或错误的查询,这可能是由于模型尚未充分学习到数据库的信息和SQL逻辑,导致在推理阶段产生误导性的输出。
2)答案稳定性:模型生成答案不是非常稳定,偶尔需要多次提问才能找到最优答案。
为了解决这些模型问题,我们考虑了Prompt Engineering(提示工程)、Fine-tuning(模型微调)、RAG(增强检索)等方式对模型进行优化。
Prompt Engineering(提示工程)是一种通过设计特定的提示词或句子,引导模型生成更符合用户意图的输出的方法。例如,我们可以为模型添加一些关于SQL规则、语法、数据库特点的提示信息,以帮助模型更好地理解SQL语句的结构和规则。通过这种方式,我们可以有效地减少模型幻觉出现的频率,提高模型的准确性和稳定性。
Fine-tuning(模型微调)则是指在预训练模型的基础上,使用特定的数据集进行微调,以适应特定的任务需求。对于Text2SQL任务,我们可以使用包含大量SQL语句的数据集作为微调数据集,来进行模型局部的Fine-tuning微调,以提高模型对SQL语句的理解和生成能力。
以向量检索为核心的 RAG(增强检索)架构是目前大模型获取最新外部知识、消除生成幻觉问题时常采用的主流技术框架,它旨在通过加强知识检索能力,为大模型提供更有依据、更依赖事实的信息来帮助解决生成式AI的幻觉倾向、专业力弱等固有缺陷。
这三种模型优化思路的对比如下:
Prompt通过精心设计的提示词或句子,引导模型生成更符合用户需求的输出。例如,我们可以为模型添加一些关于数据库、口径、SQL语法特点的提示信息,以帮助模型更好地理解SQL语句的结构和规则。
在Text2SQL任务中,不经过Prompt,直接使用LLM对业务问题的提问:统计“去年各产品的市场规模”,得到结果如下:
由于模型对提问的背景、字段含义、口径的不熟悉,因此回答的答案符合SQL语法,但却无法满足业务场景内真实需求。
在这样的问题的基础上,我们尝试采用Prompt的方式,将场景知识预先提供给模型。我们实现并借鉴了SPIDER榜单排名前5的Prompt方式,其中对模型自定义的Prompt信息包括:结构化指令、数据库中表信息、场景案例的Few-shot Examples,并对案例问题中的题目和表结构进行对齐(Schema Linking)。通过精心调整的结构化引导,模型完成了提示工程的优化工作。
经过Prompt后,对同一问题的再次提问的效果如下:
结论:Prompt后模型生成的答案满足我们的应用需求,能够反映真实业务案例场景中的数据特点和查询要求。
目前模型微调(Fine-tuning)主流的方法包括2019年 Houlsby N 等人提出的 Adapter Tuning,2021年微软提出的 LORA,斯坦福提出的 Prefix-Tuning,谷歌提出的 Prompt Tuning,2022年清华提出的 P-tuning v2。自然语言处理领域通常使用通过一般领域数据的大规模预训练来对特定任务或领域进行适应的范式。但是随着预训练语言模型越来越大,这个范式存在以下问题:
● 当我们微调大模型时,由于训练成本太高,不太可能重新训练所有模型参数;
● 过往的方法都或多或少有其它性能问题,如 adapter 增加了模型层数,引入了额外的推理延迟;prefix-tuning 比较难训练,效果不如直接 Fine-tune。
基于上述背景,研究者基于内在维度(intrinsic dimension)的概念:“模型是过参数化的,它们有更小的内在维度,模型主要依赖于这个低的内在维度(low intrinsic dimension)去做任务适配”,假设模型在任务适配过程中权重的改变量是低秩(low rank)的,由此提出低秩自适应(LoRA)方法:LoRA 允许我们通过优化适应过程中密集层变化的秩分解矩阵,来间接训练神经网络中的一些密集层,同时保持预先训练的权重不变。
LoRA的实现如下图所示,先冻结一个预训练模型的矩阵参数,并选择用 A 和 B 矩阵来替代,在下游任务时只更新 A 和 B。[6]
图3 LoRA的实现
我们在Text2SQL任务中尝试使用LoRA方法进行模型微调。我们选择金融领域的真实业务SQL数据集,对数据集进行清洗和标注,然后对模型进行重新训练和参数调整,使模型能够深度理解金融领域数据库查询场景和专业领域知识,并对SQL常用金融统计函数、统计口径增加一定的学习和理解。
经过LoRA微调的模型提问效果如下,微调后模型生成的答案满足我们的应用需求,能够对真实业务场景中SQL的用法有更多的理解。
检索增强生成(RAG)旨在处理自然语言处理任务中的信息检索和生成问题,它结合了检索式方法和生成式方法,以提高文本处理任务的效率和质量。
RAG从已有数据源(或知识库)检索信息,作为大语言模型生成答案的依据。它通常包括两个阶段:检索上下文相关信息和使用检索到的知识指导生成过程。首先通过检索算法找到的信息作为上下文,来帮助大模型回答用户问询。然后查询和检索到的上下文都被注入发送给LLM大模型,作为问询的提示。
RAG检索增强的基础过程为:将文本分割成块,然后使用编码模型将这些块嵌入到向量中,将所有这些向量放入索引中,最后为LLM创建一个提示,告诉模型根据我们在搜索步骤中找到的上下文来回答用户的查询。[7]
图4 RAG(检索增强)基础流程[8]
我们尝试在Text2SQL的数据库问答模型中使用检索增强架构,以提高信息检索的准确性和效率,生成更贴近用户需求的SQL代码答案。结合检索和生成的优势,模型为我们提供更全面的代码查找、文本处理能力。RAG技术帮助我们更加精准地在已有SQL知识中找到用户查询问题相关的信息,使模型返回更加符合场景实际情况的答案。
通过Prompt、模型微调、检索增强等方式,我们将模型在相似的拓展问题上进行验证,最终实现效果如下:在测试的44个金融真实数据查询案例中,我们以spider数据集的分类标准将内部的SQL也进行了分类,其中模型可完成80%以上的一般查询、关联查询问题,可在保证逻辑准确的情况下完成60%以上的复杂嵌套SQL问题。模型幻想的出现频率降为7%以下。
我们通过自研的智鸿-共享智能决策引擎完成了整套Text2SQL大模型的构建、优化和部署工作。我们在智鸿平台建立了从数据接入、模型微调、提示工程、模型计算到上线应用的全流程大模型服务与管理模块,然后基于金融行业真实数据库查询数据,对预训练模型进行以上三种方式的优化,完成了大模型的训练到服务全生命周期的管理。
Text2SQL 技术可以帮助金融机构处理大量的自然语言查询问题,并将其转换为 SQL 查询,从而实现更高效的数据查询和分析。未来,在金融领域中 Text2SQL 技术将会有更广泛的应用场景:
数据分析场景:金融机构内的数据分析部门常常需要完成大量的数据分析工作,Text2SQL 技术可以让分析人员通过自然语言提出他们的分析需求,系统将其转换成 SQL查询,以更加快捷地从庞大的数据集中提取必要的信息。
业务部门和客户服务数据支持:金融机构的业务部门与客户服务部门经常需要进行业务数据查询,例如账户余额、交易记录等。Text2SQL 技术可以帮助自动处理这些查询,快速地从数据库中检索相关信息,并以易于理解的方式回答业务运营人员或客户的问题。
决策支持:公司管理者常常有关于公司内外信息的查询需求,需要进行大量的数据支持来支持决策制定。可以基于Text2SQL技术为公司管理层提供便捷、人性化的数据库智能问询服务,辅助公司战略决策。
自动化报表生成:金融机构通常需要生成各种报告,如财务报告、风险报告等。使用 Text2SQL技术,可以让用户通过文字描述他们需要的报告内容,系统通过SQL语言从数据库中提取数据并生成相应报告和图表。
风险管理与合规性监管:金融机构需要不断监控和评估各类风险,包括市场风险、信用风险等,并满足监管合规需求。Text2SQL 技术可以用于相关部门快速查询和分析与风险、合规性相关的数据,帮助机构更好地管理公司内外部风险。
53AI,企业落地应用大模型首选服务商
产品:大模型应用平台+智能体定制开发+落地咨询服务
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2024-05-28
2024-04-26
2024-08-21
2024-04-11
2024-07-09
2024-08-13
2024-07-18
2024-10-25
2024-07-01
2024-06-17