text2sql 技术是一种将自然语言(NL)转化为可被数据库执行的结构化查询语言 SQL 的技术。自然语言可以是我们熟悉的一段文本,也可以是一段语音,又或者是其它可转化为文本的输入形式。
通过该技术,能够让不懂数据库操作的非技术人员提取、分析数据,无需学习编写 SQL 语句,无需了解不同 SQL 数据库的使用软件,通过输入文本描述的问题需求,即可得到对应需求下的数据结果。
结合其它智能业务代理人模块 / 技术,还可以实现智能数据中台、智能业务流转、智能业务分析、智能业务汇报等等场景,极大降低使用门槛的同时,又提高了业务执行效能。
text2sql 技术的发展历史较长,例如上世纪六十年代,LUNAR 系统通过句式语法分析,尝试回答阿波罗任务的地质学分析问题,2013 年前后,随着人工智能技术的兴起,text2sql 的研究者也将视野拓展到此类领域。2019 年前后,基于大语言模型的技术再次将 AI 推向一个新的阶段,text2sql 技术也引来了新的技术突破。
当前基于大语言模型的 text2sql 技术现状,可以从以下几个方面简单介绍。
数据集与评价标准
衡量各个技术的优劣,首先要统一评价标准,而评价标准又需要建立在一个相对合理的数据基础上。
当前学术论文数据实验较多采用 Spider 和 BIRD 开源数据集,此外行业中也有较多各个特点的其它数据集(如下表):
以 BIRD benchmark 为例,当前排行榜前列的 text2sql 技术,最高执行准确率能够达到 75.63%,人类水平为 92.96%。
虽然 text2sql 技术经历漫长发展和技术突破,当前在一些较难的开源数据集上,仍未超过人类水平。
上图中的执行准确率,一般计算方式为 以 SQL 执行后的检索结果作为正负样本的判定依据。
但是要特别说明的是,当前学术领域的技术研究与产品化、工业化的 text2sql 技术方案落地着眼点不同。
产品化、工业化 text2sql 技术方案可以借助例如 RAG 技术、业务逻辑语义建模、物理数据建模等思路,准确率能够达到 90% 以上,简单 SQL、特定业务场景 SQL 的生成准确率能够达到 99% 以上,而学术领域研究更侧重 text2sql 算法技术本体(模型性能优化、算法思路优化等),并没有刻意使用一些外部工具建模。
思路方法
当前学术领域对 text2sql 的研究方向多样性较高,个人粗略梳理了以下几个方面的路线:
在逐步分解介绍上述思路前,先介绍下大概的一般性思路。
一般我们使用大语言模型的步骤是输入问题 query,大语言模型回复对应的 answer,即 query → answer,text2SQL 也遵循此基本概念 text → SQL。
为了让大语言模型能够生成正确的 SQL,需要在 text 中包含 query+SQL 相关的语境知识,例如数据库建表信息、参考 QA 样本等。同时还要包含大语言模型的提示词,例如对整体任务需求的描述。这部分的输入拼接在一起可能非常长,过长、描述冗余的输入,可能会增加大语言模型的幻觉,生成的 SQL 质量不高。所以如何优化问题表述的形式,这部分个人归类为 text2SQL 的信息表示相关研究。另一方面,如何提高输入的质量,尽可能的包含足够多的有效信息,减少无效信息,这部分个人放在语境知识部分。SQL 相关的语境知识,一般是建表信息、参考样例(few-shot)等内容,例如:
以上两个部分不需要对大语言模型进行监督微调,即可具备一定 text2sql 效果,还有些学术领域研究如何更好的监督微调,大体上是对业务数据的数据挖掘、处理、优化。
此外也有学者将智能代理 Agent/Multi-Agents 的思路融入进来,或者采用多轮子步骤,使得大语言模型能够更有效的推理、反思,也是流程优化中不错的创新思路。
1.信息表示(information representation)
最常见的信息表示为建表信息 + 用户问题 + 简单提示词,例如输入格式:
通常参数量超过 7B 的大语言模型能够生成简单问题对应的 SQL 语句。但是这种基本表示方法缺点同样明显,例如没有任务描述,仅以 “SELECT” 开头,对输入文本没有压缩、过滤、数据增强,大语言模型不一定能够完成补全。
优化思路可以加入特定任务描述性提示词进去:
不同大语言模型对提示词的学习理解不一样,此外生成的 SQL 种类不一,细节语法也不一样,所以在添加特定任务描述性提示词时,我们也通常会加入一些语法提示或者适配某类大语言模型的提示词格式,例如:
因为代码生成任务表现较好的大语言模型,通常能够接受更长的输入上下文长度,所以我们有时也会采用逻辑性更强的代码风格、数学模型风格等表示方法作为输入格式。例如:
TA-SQL 对不同表示方法进行了对比实验:
根据个人的实践经验和实验对比,代码风格的表示方法可能更易被大语言模型理解。
2.语境学习(in-context learning)
信息表示思路通常是输入格式、提示词格式、基本信息形式等方面的优化思路。为了增强大语言模型 text2SQL 的生成性能,通常也会加入建表信息之外的内容,增强大语言模型上下文理解能力,例如 few-shot 参考样本。
few-shot 参考样本的采样策略,较常见的是随机抽样、根据问题相似度 topK 抽样,相似度算法常见于欧几里得距离、余弦相似度等。
也有针对 text 问题或者 SQL,进行 mask 遮盖后,再进行相似度 topK 采样的思路。不过这种算法通常会额外增加算法计算成本。
这部分采样得到的 few-shot 样本会以 QA 对形式加入到输入提示词中。
此外,数据库各个列的样本值采样也是比较有用的信息,例如
这类样本值抽样的算法对于最终的 SQL 结果,特别是 SQL 中带有条件过滤的语法(例如 where)起到很大的辅助学习作用。
因为建表信息等上下文通常较长,为了增强大语言模型理解,抓住重点信息,类似 CHESS-SQL 会对原始输入进行关键词提取,搭配外部数据建模,抽取出关键信息,并在后续建表信息中进行过滤,抽取出关键的建表信息。
在上文中我们提到代码风格的表示对大语言模型推理理解有所帮助,TA-SQL 采用将初步 SQL 表示成类 PandasAPI 的风格,再转换成最终 SQL,也是一种 text2sql 生成思路。
3.流程优化(监督学习、智能体等)
监督学习的优化思路通常不在于监督微调本身,而是对高质量数据的收集和处理。这部分做法与其它思路类似,本文就略过了。
也有学者使用多智能体结构处理 text2sql 任务,例如 MAC-SQL:
作者的思路是构建智能体 Selector、Decomposer、Refiner,对原始建表信息进行信息分解,抽取高价值、高问题相关的 tables、columns、values 等内容,在对用户原始问题进行分解,生成子 SQL。最终合并以上信息生成最终 SQL。
不过 MAC-SQL 的源代码设计思路与基于 LangChain 等框架的 MA 设计思路不太一样。作者将三个智能体通过 ChatManager 类实现管理。
类方法中包含 MA 框架必要的整体流程管理类函数声明。
使用了全局变量 global 声明,特别是智能体配置方面的变量。
用户信息在 T=0 时,首先会发送给 MA 起点 SYSTEM,起点默认将信息数据传递给 Selector。Selector 的类函数实现了自身对 database、table、column、value 等的处理(见 Methodology 相关功能介绍),同时联动流程的函数是 `talk`,其将提取后的数据传递给 Decomposer。
MA 结构的 “自动对话” 机制是通过 for 循环 + user_message 字典的字段 send_to 实现的,每个智能体继承 BaseAgent 基类,调用 talk 函数更改 user_message 状态,再通过 for 循环实现自动化。
多智能体结构当前产品化的问题是响应时间较慢,用户往往需要等待较长时间才能得到结果,而 text2sql 的用户等待比对话类场景宽容度更低,因为用户最终的目的是分析、查看 SQL 执行后的数据。
因为 text2SQL 的 sql 结果最终会在 SQL 终端执行,而终端执行会反馈执行异常报错信息,这部分信息通常对 SQL 矫正非常有帮助,例如报错信息:
列名理解错误类型,可以针对性的增加一轮 LLM 模型矫正流程,提示词中加入列名解释。
SQL 语法性的错误可以在矫正流程的提示词中加入对应数据库需要注意的语法,例如 groupby 约束的列名,在某些 SQL 语法中需要显式声明在 select 约束的范围内。
DIN-SQL 的 self-correction 处理思路与所述类似,将异常报错信息收录,额外增加一轮大语言模型调用,并在这轮调用的提示词中,加入报错信息收录。
作者将 self-correction 分为 generic 和 gentle 两种思路类型,一种是加入 SQL 易错语法提示的设计,一种是加入终端执行 error 报错信息的自我矫正机制。
除了 self-correction,也有让大语言模型生成 n 个备选 SQL 答案,在终端执行后,优先选择不会报错、有数据的备选答案作为最终答案,例如 self-voting。不过这种策略需要注意大语言模型的参数配置,参数配置上需要尽可能让 n 个备选答案更有创造性。
因为通常来说 SQL 终端执行的时间成本比单次调用大语言模型的推理时间低,所以为了在时间和效果上平衡,类似 self-correction 的思路在产品化时,可以设置成条件分之,在终端执行错误后额外增加一轮 self-correction 流程。
text2SQL 技术最终还是要落地到真实业务场景中,产品化过程是必经之路。学术上的 text2SQL 思路在转型成工业产品化 text2SQL 的过程中,也需要适配、优化。
从数据出发,论文实验中较多使用的 BIRD-dev 数据集。
1534 个样本中,SQL 的平均字符串长度为 162,而以某能源领域客户真实数据为例,工业级别的真实业务问题,对应 SQL 平均字符串长度为 433,20% 的 SQL 长度超过 700,个别 SQL 长度超过 900。在处理 text 到 SQL 的生成时,随着问题难度的增加,我们需要额外考虑一些复杂性因素:
卓世科技 text2SQL 的产品化过程,对以上实际转化落地可能遇到的问题进行分析整理,并形成产品化方案,例如
通过这些功能,卓世科技的 text2SQL 产品为用户提供了高效、智能的数据库操作体验,有效提升了数据分析的准确性和便捷性。
参考资料:
Before Generation, Align it! A Novel and Effective Strategy for Mitigating Hallucinations in Text-to-SQL Generation
BIRD-SQL:https://bird-bench.github.io
CHASE-SQL: Multi-Path Reasoning and Preference Optimized Candidate Selection in Text-to-SQL
CHESS: Contextual Harnessing for Efficient SQL Synthesis
CodeS: Towards Building Open-source Language Models for Text-to-SQL
DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction
E-SQL: Direct Schema Linking via Question Enrichment in Text-to-SQL
MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL
PET-SQL: A Prompt-Enhanced Two-Round Refinement of Text-to-SQL with Cross-consistency
RSL-SQL: Robust Schema Linking in Text-to-SQL Generation
Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation
XiYan-SQL: A Multi-Generator Ensemble Framework for Text-to-SQL