基于大语言模型的文本到SQL技术综述

在当今数字化时代,数据库在各个领域的信息存储与管理中扮演着核心角色。然而,传统的数据库查询方式要求用户具备专业的SQL知识,这对普通用户构成了较高的门槛。文本到SQL技术的出现,旨在打破这一障碍,允许用户通过自然语言与数据库交互,从而更便捷地获取所需信息。本文将深入探讨基于大语言模型( LLM )的文本到SQL技术,包括其技术挑战、发展历程、数据集与评估指标、实现方法以及未来展望,希望能为相关领域的研究人员和从业者提供全面而深入的理解。

01.引言

在人工智能与数据库技术深度融合的时代背景下,如何让用户以自然语言便捷地与数据库交互成为研究热点。Text-to-SQL 技术,作为连接自然语言与数据库的桥梁,应运而生。其旨在将自然语言问题精准转化为数据库可执行的 SQL 查询,这一技术的发展历程犹如一部技术进化史,见证了从早期的简单规则尝试到如今借助强大的大语言模型( LLM )实现更智能、高效转换的跨越。

早期的 Text-to-SQL 系统多基于规则构建,研究人员精心设计规则和模板,以应对相对简单的数据库场景。然而,随着数据库环境日益复杂,规则的局限性逐渐显现。随后,深度学习技术的兴起为该领域带来了新的曙光,深度神经网络被引入,推动了 Text-to-SQL 技术的进一步发展。预训练语言模型(PLM)的出现更是提升了系统性能,但面对现代复杂数据库和多样化用户问题,仍存在改进空间。近年来, LLM 凭借其卓越的自然语言理解和生成能力,为 Text-to-SQL 研究注入了新的活力,展现出巨大的潜力和应用前景。

基于 LLM 的文本转 SQL 的整体实现细节可以分为 3 个方面:1. 问题理解:自然语言问题是用户意图的语义表示,相应的生成的 SQL 查询期望与之保持一致;2. Schema 理解:Schema 提供了数据库的表列结构,需要 text-to-SQL 系统来识别与用户问题匹配的目标组件;3. SQL生成:这涉及合并上述解析,然后预测正确的语法以生成可检索所需答案的可执行 SQL 查询。

此图清晰呈现了一个典型的基于 LLM 的 Text-to-SQL 系统工作流程。当用户提出如“能否告知我史上比赛场次最多的 5 个联赛及其比赛场次?”这样的自然语言问题时, LLM 会获取该问题以及对应的数据库 Schema 信息。例如,数据库中包含 “Country”“League”“Match” 等表,各表有其特定的字段结构。LLM 基于这些输入,运用其强大的语义理解和生成能力,输出如

SELECT League.name, count(Match.id) FROM Match` `INNER JOIN League ON Match.league_id = league.id` `GROUP BY League.name` `ORDER BY count(Match.id) DESC` `LIMIT 5

这样的 SQL 查询。该查询在数据库中执行后,便能准确检索出用户所需的信息,如 “西班牙 LIGA BBVA”“法国 Ligue 1” 等联赛及其比赛场次,从而实现了自然语言与数据库之间的有效交互,让非技术用户也能轻松获取数据库中的数据。

02.概述

2.1 Text-to-SQL 任务定义

Text-to-SQL 任务的核心在于构建自然语言与数据库之间的无缝连接。给定一个用户以自然语言表达的问题,例如在商业智能场景中,用户可能询问 “过去一个季度销售额排名前十的产品有哪些?”,或者在客户支持场景下,“查询购买了特定产品且在最近一个月内有投诉记录的客户信息”,Text-to-SQL 系统需要将这些问题准确转换为数据库能够理解和执行的 SQL 查询。这一转换过程涉及对用户意图的精准理解,以及对数据库结构和数据的有效映射,最终目的是从数据库中检索出符合用户需求的内容,实现数据的高效获取和利用,推动各领域业务的智能化发展

2.2 Text-to-SQL 的挑战

2.2.1 语言复杂性和歧义性

自然语言的灵活性和多样性在 Text-to-SQL 任务中成为了巨大挑战。用户问题可能包含复杂的语法结构,如嵌套子句 “查找那些既参加过国际比赛又在国内联赛表现出色的球队”,其中涉及多层逻辑关系。指代不明现象也颇为常见,例如 “它的销量比去年同期增长了多少”,这里的 “它” 指代不明,需要结合上下文才能确定。此外,问题省略也增加了理解难度,像 “查询最高价格,最低价格”,省略了查询的对象范围等关键信息。这些因素使得准确解析用户意图并映射到SQL 查询变得困难重重,要求系统具备强大的自然语言理解能力,能够深入分析语义、结合上下文信息,并运用领域知识进行准确判断。

2.2.2 schema 理解与表示

数据库 schema 是 Text-to-SQL 系统生成准确查询的关键依据。然而,数据库 schema 往往复杂多样,包含多个表、众多列以及复杂的表间关系。例如,在一个包含产品、订单、客户、库存等多个表的电商数据库中,要准确理解各表之间的关联关系,如订单表与产品表通过产品 ID 关联,与客户表通过客户 ID 关联等,并非易事。如何将这些复杂的 schema 信息有效地表示和编码,使其能够被 Text-to-SQL 模型充分利用,是当前研究面临的重要挑战之一。

2.2.3 罕见和复杂的 SQL 操作

在实际应用中,SQL 查询可能涉及一些不常见或复杂的操作和语法。例如,在处理复杂数据分析时,可能需要使用

嵌套子查询

SELECT * FROM orders` `WHERE customer_id IN``(SELECT customer_id FROM customers WHERE region = 'North')

链接查询

SELECT customers.name, orders.order_date FROM customers` `LEFT JOIN orders ON customers.customer_id = orders.customer_id

窗口函数

SELECT product_name, sales,` `AVG(sales) OVER(PARTITION BY category) AS average_sales` `FROM sales_data

这些操作在训练数据中出现频率较低,增加了模型学习和准确生成此类 SQL 查询的难度,需要设计更具泛化能力的模型来应对。

2.2.4 跨域泛化

不同领域的数据库在词汇使用、schema 结构和问题模式上存在显著差异。以医疗领域和金融领域为例,医疗领域可能涉及疾病名称、治疗方案、患者信息等专业词汇,数据库模式围绕患者病历、诊断结果、医疗资源等构建;而金融领域则更多涉及金融产品、交易记录、风险评估等词汇,数据库模式侧重于账户信息、交易流水、市场数据等。当模型在一个领域训练后应用于另一个领域时,往往表现不佳,如何使 Text-to-SQL 系统能够在不同领域间有效泛化,仅需少量特定领域训练数据或微调就能适应新领域,是亟待解决的问题。

03.T2SQL 的演进

3.1 基于规则的方法

早期的 Text-to-SQL 系统主要依赖于规则和模板。研究人员通过深入分析自然语言问题与 SQL 查询之间的对应关系,手动制定大量规则。例如,对于特定的查询意图,如 “查询所有员工的姓名和工资”,会制定相应的规则来构建 SQL 查询。这些方法在简单、特定的数据库场景中取得了一定成功,能够快速准确地生成一些常见查询的 SQL 语句。然而,其局限性明显,面对多样化、复杂的用户问题,需要不断添加和修改规则,灵活性和泛化能力较差,难以适应大规模、复杂的数据库环境。

3.2 基于深度学习的方法

随着深度学习技术的蓬勃发展,深度神经网络被引入 Text-to-SQL 领域。序列到序列模型(如 LSTMs)和编码器 - 解码器结构(如 transformers)成为主流技术手段。例如,通过对大量自然语言问题和对应的 SQL 查询进行训练,模型学习从自然语言序列到 SQL 查询序列的映射关系。RYANSQL 引入中间表示和基于草图的槽填充技术,有效处理复杂问题,提高了跨域泛化能力。此外,图神经网络(GNNs)也被应用于该任务,通过构建模式依赖图来捕捉数据库元素之间的关系,进一步提升了系统对复杂数据库结构的理解和处理能力。

3.3 基于 PLM 的实现

预训练语言模型(PLM)的出现为 Text-to-SQL 带来了新的突破。PLM 在大规模语料上进行预训练,积累了丰富的语言知识和语义理解能力。早期研究主要集中在对现成的 PLM(如 BERT、RoBERTa)进行微调,使其适应 Text-to-SQL 任务。例如,在标准数据集上对这些模型进行微调,利用其预训练过程中学习到的语义表示,提高生成 SQL 查询的准确性。同时,为了更好地结合数据库模式信息,研究人员还探索将模式信息融入 PLM,增强其对数据库结构的理解,从而生成更符合数据库要求的可执行 SQL 查询。

3.4 基于 LLM 的实现

近年来,大语言模型( LLM )如 GPT 系列因其强大的文本生成能力备受关注。研究人员开始探索利用 LLM 实现 Text-to-SQL,主要通过两种方式:一是精心设计提示工程,引导专有 LLM 生成 SQL 查询,例如通过巧妙设计提示语,让 LLM 理解用户问题并生成正确的 SQL;二是对开源 LLM 进行微调,使其在 Text-to-SQL 任务上表现更优。不过,目前 LLM 在 Text-to-SQL 中的应用仍处于探索阶段,如何更好地挖掘其潜力,充分发挥其知识储备和推理能力,仍是未来研究的重要方向。

此图生动展示了 Text-to-SQL 系统从早期基于规则的方法,逐步发展到基于深度学习、预训练语言模型,再到当前基于大语言模型的演进轨迹。清晰地呈现了技术的不断迭代和创新,反映出随着时间推移,研究人员为提高 Text-to-SQL 系统性能所做出的不懈努力,以及技术发展的趋势和方向。

04.基准与评估

4.1 数据集

4.1.1 原始数据集

BIRD:于 2023 年 5 月发布,包含 12,751 个示例,涵盖 95 个数据库,每个数据库平均有 7.3 个表,数据量约为 549K 行。其突出特点是具有跨域和知识增强特性,通过邀请人类数据库专家为每个 Text-to-SQL 样本标注外部知识,包括数值推理知识、领域知识、同义词知识和值说明等,显著提升了模型在处理需要外部知识的样本时的 SQL 生成性能。

KaggleDBQA:2021 年 6 月发布,规模相对较小,仅有 272 个示例和 8 个数据库,每个数据库平均 2.3 个表,约 280K 行数据,主要用于跨域场景的研究,为跨域 Text-to-SQL 任务提供了数据支持。

DuSQL:2020 年 11 月推出,包含 23,797 个示例和 200 个数据库,每个数据库平均 4.1 个表,是一个跨域且跨语言的数据集,在研究多语言环境下的 Text-to-SQL 任务中具有重要价值。

SQUALL:2020 年 10 月发布,包含 11,468 个示例和 1,679 个数据库,每个数据库 1 个表,通过手动标注自然语言问题中的单词与 SQL 中的实体之间的对齐关系,提供了更精细的监督信息,有助于模型更好地学习语义映射。

CoSQL:2019 年 9 月发布,包含 15,598 个示例和 200 个数据库,专注于探索上下文相关的 SQL 生成,通过构建模拟的自然语言对话场景,增加了数据的复杂性和多样性,为研究上下文感知的 Text-to-SQL 系统提供了丰富的数据资源。

Spider:2018 年 9 月发布,是一个广泛应用的数据集,包含 10,181 个示例和 200 个数据库,每个数据库平均 5.1 个表,约 2K 行数据,为跨域 Text-to-SQL 任务的研究提供了大量基准数据。

WikiSQL:2017 年 8 月发布,规模较大,有 80,654 个示例和 26,521 个数据库,每个数据库 1 个表,17 行,在早期跨域 Text-to-SQL 研究中发挥了重要作用。

4.1.2 后注释数据集

ADVETA:2022 年 12 月发布,基于 Spider 等数据集构建,通过引入对抗性表扰动技术,如替换原始列名和插入误导性列,评估 Text-to-SQL 系统在面对数据库内容被污染或扰动时的鲁棒性。

Spider-SS&CG:2022 年 5 月发布,源于 Spider 数据集,将示例中的自然语言问题拆分为多个子问题和子 SQL,研究发现基于这些子示例进行训练可提高系统对分布外样本的泛化能力。

Spider-DK:2021 年 9 月发布,在 Spider 数据集基础上添加了领域知识,通过定义和添加五种类型的领域知识,有效提升了模型在处理需要领域知识的样本时的 SQL 生成性能。

Spider-SYN:2021 年 6 月发布,对 Spider 数据集进行手动同义词替换操作,用于评估 Text-to-SQL 系统对词汇变化的鲁棒性,即系统在面对同义词替换时能否准确生成 SQL 查询。

Spider-Realistic:2020 年 10 月发布,通过去除自然语言问题中的显式模式相关词,模拟实际应用中用户问题可能不规范的情况,测试系统在这种情况下的鲁棒性和准确性。

CSpider:2019 年 9 月发布,是 Spider 数据集的中文翻译版本,主要用于研究中文环境下的 Text-to-SQL 任务,在跨语言研究中具有重要意义,有助于发现中文问题与英文数据库内容匹配过程中的挑战。

SParC:2019 年 6 月发布,对 Spider 数据集的问题 - SQL 示例进行分解,构建模拟的多轮对话交互,包括相关和不相关的子问题,以研究上下文相关的 SQL 生成,为提高系统在复杂对话场景下的性能提供了数据支持。

4.2 评估指标

4.2.1 基于内容匹配的指标

组件匹配(CM):通过将预测的 SQL 查询与真实 SQL 查询分解为组件(如 SELECT、WHERE、GROUP BY、ORDER BY、KEYWORDS 等),并计算这些组件之间的精确匹配 F1 分数来评估系统性能。这种评估方式考虑了 SQL 组件的多样性和无顺序约束性,能够更细致地衡量系统生成 SQL 查询的准确性。

精确匹配(EM):该指标直接衡量预测 SQL 查询与真实 SQL 查询完全相同的示例所占的百分比,是一种较为严格的评估标准,要求预测的 SQL 在结构、语法和语义上与真实 SQL 完全一致。

4.2.2 基于执行结果的指标

执行准确性(EX):通过在实际数据库中执行预测的 SQL 查询,并将执行结果与真实 SQL 查询的执行结果进行比较,判断预测 SQL 查询的正确性。这种评估方式更贴近实际应用场景,能够直接反映系统生成的 SQL 查询是否能够准确获取所需数据。

有效效率分数(VES):该指标综合考虑了预测 SQL 查询的有效性和效率。具体计算时,首先判断预测 SQL 查询的执行结果是否与真实结果完全匹配,若匹配则为有效 SQL 查询,然后通过计算预测 SQL 查询与真实 SQL 查询的相对执行效率(基于执行时间)来评估其效率,最终得出一个综合分数,全面衡量系统性能。

该表全面系统地对各类 Text-to-SQL 数据集进行了分类汇总。详细列出了每个数据集的发布时间、示例数量、数据库数量、每个数据库的表数量以及行数等关键信息,为研究人员选择合适的数据集提供了详细参考。同时,通过对数据集特性的标注,如跨域、知识增强、上下文相关、鲁棒性测试、跨语言等,有助于深入了解不同数据集的特点和适用场景,从而更好地支持 Text-to-SQL 系统的研究、开发和评估工作。

此表聚焦于基于 LLM 的 Text-to-SQL 中的上下文学习方法,列举了一些典型方法,如 C1-Decomposition、C2-Prompt Optimization、C3-Reasoning Enhancement、C4-Execution Refinement 等。对于每个方法,详细说明了其采用的模型、应用的 LLM 以及在哪些数据集上进行了测试,展示了不同方法在基于 LLM 的 Text-to-SQL 任务中的应用情况,为研究人员深入了解和选择合适的上下文学习方法提供了有力依据。

05.方法

在基于 LLM 的 Text-to-SQL 系统实现中,上下文学习(ICL)和 微调(FT)是两种主要的范式,它们各自具有独特的特点和优势,为实现高效准确的 Text-to-SQL 转换提供了不同的途径。

5.1上下文学习

5.1.1 简单提示(Trivial Prompt)

零样本(Zero-shot):许多研究利用 LLM 的零样本提示能力进行 Text-to-SQL 任务探索。例如,在一些研究中,直接向 LLM 提出自然语言问题,不提供额外示例,仅通过调整提示的构建方式来影响 LLM 的生成结果。研究发现,提示设计对性能影响显著,不同的提示风格和结构会引导 LLM 生成不同的 SQL 查询。同时,实验表明增加数据库内容并不一定能提高准确性,反而可能因引入过多信息导致模型混淆,降低性能。此外,在评估不同早期开发的 LLM (如 GPT - 3、GPT - 3.5、GPT - 4 等)的基线 Text-to-SQL 能力时,发现模型在处理复杂问题时仍存在一定局限性。

少样本(Few-shot):少样本提示通过在提示中提供少量示例来引导 LLM 生成更好的 SQL 查询。研究主要集中在示例数量的选择、示例的代表性以及输入提示的结构设计等方面。例如,通过对比不同数量(如 1 - shot、3 - shot、5 - shot 等)的示例对性能的影响,发现合适的示例数量能够显著提升 LLM 的表现。同时,研究人员还探索了基于相似性的示例选择策略,如选择与用户问题语义相似的示例,以及结合多种采样策略(如随机采样、难度级别采样等)来优化少样本提示的效果。

5.1.2 分解(Decomposition)

分解方法旨在将复杂的用户问题分解为更简单的子问题或多组件任务,从而降低 Text-to-SQL 整体任务的难度,提高 LLM 生成 SQL 的准确性。具体包括子任务分解和子问题分解两种方式。子任务分解如模式链接、域分类等,通过先解决一些辅助性任务,为最终的 SQL 生成提供更准确的信息。子问题分解则是将原始问题划分为多个子问题,分别求解并生成子SQL,最后整合得到最终的SQL查询。例如,对于“查询购买了电子产品且消费金额超过1000元的客户姓名和联系方式,以及他们购买的产品名称和数量”这样复杂的问题,可以分解为“查询购买了电子产品的客户ID”、“查询消费金额超过1000元的客户ID”、“根据客户ID查询客户姓名和联系方式”、“根据客户ID查询购买的产品名称和数量”等子问题。

实现框架与技术

特性

DIN-SQL

提出了一种分解式的上下文学习方法,包含模式链接、分类与分解、SQL生成和自我纠正四个模块。首先进行模式链接,建立用户问题与目标数据库之间的联系;接着对用户问题进行分解,将其分为相关子问题并进行难度分类;然后基于上述信息生成相应的SQL;最后通过自我纠正模块识别和修正预测SQL中的潜在错误

Coder-Reviewer

框架采用重排序方法,结合 Coder 模型生成和 Reviewer 模型评估指令的可能性,提高SQL生成的准确性

QDecomp

引入问题分解提示,按照从复杂到简单的顺序逐步分解问题,将其作为中间推理步骤,指导 LLM 生成SQL

C3

通过分配 ChatGPT 不同任务,包括生成模式链接和提炼与问题相关的模式作为清晰提示,利用多轮对话作为校准偏差提示,结合一致性和执行投票选择最终SQL

MAC-SQL

提出多代理协作框架,由 Selector、Decomposer 和 Refiner 等代理协同工作,Selector筛选相关表,Decomposer 分解问题并提供解决方案,Refiner 验证和优化有缺陷的 SQL

DEA-SQL

引入工作流范式,分解整体任务,使SQL生成模块具备相应的前提和后续子任务,提高生成SQL的准确性

SGU-SQL

是结构到SQL框架,构建用户问题和数据库的图结构,利用编码图进行结构链接,通过元操作分解问题并设计输入提示

MetaSQL

采用三阶段方法,包括分解、生成和排序,先对用户问题进行语义分解和元数据组合处理,再生成候选SQL查询,最后通过两阶段排序管道得到全局最优SQL查询

PET-SQL

提出提示增强的两阶段框架,第一阶段生成初步SQL,基于相似性选择少量示例,然后根据初步SQL找到模式链接,再次提示 LLM 生成最终SQL,并利用多个 LLM 确保一致性

5.1.3 提示优化(Prompt Optimization)

在基于 LLM 的 Text-to-SQL 中,提示质量对 SQL 生成性能至关重要。由于现成 LLM 生成 SQL 的准确性在很大程度上依赖于输入提示的质量,因此当前研究聚焦于优化提示,以提高 LLM 在 Text-to-SQ 任务中的表现。这涉及多个方面,如改进少样本组织的质量和数量、增强用户问题与少样本实例之间的相似性、整合外部知识或提示等。

实现框架与技术

特性

DESEM

是一种具有去语义化和骨架检索功能的提示工程框架。它先使用特定模块去除用户问题中的语义标记,保留问题意图,再通过可调提示模块检索具有相同问题意图的少样本示例,并结合模式相关性过滤,引导 LLM 生成SQL

QDecomp

框架引入 InterCOL 机制,逐步将分解后的带相关表和列名的子问题纳入提示,且其少样本示例采用难度级别采样

SD+SA+Voting

策略先利用语义相似性和 k-Means 聚类多样性进行少样本示例采样,然后通过模式知识增强提示(语义或结构增强)

C3

框架的清晰提示组件以问题和模式为输入,生成包含去除冗余信息和模式链接的清晰提示,校准组件提供提示, LLM 将其组合作为上下文增强提示用于SQL生成。检索增强框架通过简化原始问题并提取问题骨架,根据骨架相似性从存储库中检索样本,将其与原始问题组合进行少样本提示

ODIS

引入从混合源(域外演示和域内合成数据)选择样本的方法,扩充提示表示

DAIL-SQL

提出一种解决少样本采样和组织问题的新方法,通过屏蔽用户和少样本示例问题中的领域特定单词,计算候选示例的嵌入欧几里得距离进行排序,同时计算预预测SQL查询之间的相似性,根据预设标准选择相似性排序的候选人,确保少样本示例与问题和SQL查询具有良好的相似性

ACT-SQL

提出在少样本提示中根据相似性分数选择动态示例

FUSED

通过无人工多次迭代合成构建高多样性演示池,提高少样本演示的多样性,其管道通过聚类采样演示,融合采样演示构建池以增强少样本学习

Knowledge-to-SQL

框架旨在构建数据专家 LLM (DE LLM ),通过监督微调使用人类专家注释训练 DE LLM ,并通过偏好学习结合数据库反馈进一步优化,DE LLM 生成四类知识,其他方法(如DAIL-SQL、MAC-SQL等)可整合这些知识提高性能

5.1.4 推理增强(Reasoning Enhancement)

LLM 在涉及常识推理、符号推理和算术推理等任务中展现出一定能力,在 Text-to-SQL 任务中,数值和同义词推理也较为常见。因此,通过整合精心设计的推理增强方法,提高 LLM 处理复杂问题和生成SQL的能力,成为当前研究的重要方向。CoT 提示技术 通过引导 LLM 进行全面推理过程,促使其准确推导,激发推理能力。在 Text-to-SQL 研究中,将 CoT 作为规则暗示,在提示构建中设置“让我们逐步思考”等指令。然而,原始 CoT 策略在 Text-to-SQL 任务中的效果不如在其他推理任务中显著,对其进行适应性研究仍在进行中。由于 CoT 提示通常使用带有人工注释的静态示例进行演示,需要经验判断选择有效的少样本示例,且手动注释工作量大。

实现框架与技术

特性

ACT-SQL

提出一种自动生成 CoT 示例的方法,对于给定问题,截断问题切片并枚举相应SQL查询中的列,通过相似性函数将列与最相关切片链接并添加到 CoT 提示中

QDecomp

通过利用SQL查询切片构建 CoT 推理中的逻辑步骤,并使用自然语言模板表述切片,按逻辑执行顺序排列,解决 CoT 中如何提出推理步骤预测SQL查询的挑战

Least-to-Most

提示技术将问题分解为子问题并依次解决,但在 Text-to-SQL 解析中,详细推理步骤可能导致更多错误传播问题

PoT

Program-of-Thoughts (PoT)提示策略作为 CoT 的变体,通过要求模型同时生成 Python 代码和 SQL 查询,增强算术推理能力,在复杂数据集上的评估表明PoT可提升 LLM 的SQL生成能力,尤其是在需要复杂推理的情况下

SQL-CRAFT

通过整合PoT提示和 Python 增强推理,提高基于 LLM 的 SQL 生成能力

Self-Consistency

是一种提高 LLM 推理能力的提示策略,利用复杂推理问题通常有多种思考方式但答案唯一的直觉,在 Text-to-SQL 任务中,通过采样不同SQL并根据执行反馈投票选择一致 SQL

SD+SA+Voting

框架消除执行错误的预测,选择多数投票的结果

FUXI

此外,受扩展 LLM 能力工具研究的启发,FUXI 通过有效调用精心设计的工具增强 LLM 的 SQ L生成能力

5.1.5 执行细化(Execution Refinement)

在设计准确 SQL 生成的标准时,首要考虑的是生成的 SQL 能否成功执行并正确检索回答用户问题所需的内容。由于生成正确 SQL 具有挑战性,将执行反馈纳入 SQL 生成过程可帮助系统适应数据库环境,提高生成 SQL 的准确性。执行感知方法主要通过两种方式整合执行反馈:一是将反馈用于第二轮提示再生,二是利用执行结果进行选择策略确定最终 SQL。

实现框架与技术

特性

MRC-EXEC

引入自然语言到代码(NL2Code)翻译框架并执行,执行每个采样的SQL查询,选择具有最小执行结果的贝叶斯风险的示例

LEVE R

提出通过执行验证 NL2Code 的方法,利用生成和执行模块分别收集采样 SQL 集和执行结果,然后使用学习的验证器输出正确性概率

SELF-DEBUGGING

框架教 LLM 通过少样本演示调试预测 SQL,模型通过检查执行结果并自然语言解释生成的 SQL 来纠正错误,无需人工干预

C3

框架通过去除错误并识别最一致的 SQL 来提高准确性;检索增强框架引入动态修订链,结合执行消息和数据库内容提示 LLM 将生成的 SQL 查询转换为自然语言解释,以便识别语义差距并修订 SQL

DESEM

生成的 SQL 不可执行问题时,通过回退修订根据不同错误类型修订和再生 SQL,并设置终止标准避免循环

DIN-SQL

在自我纠正模块中设计通用温和提示,分别请求 LLM 识别和纠正错误以及检查潜在问题

MAC-SQL

Refiner 代理能够检测和自动纠正 SQL 错误,根据 SQLite 错误和异常类重新生成固定 SQL

SQL-CRAFT

引入交互式校正,通过自动化控制确定过程避免过度校正或校正不足

FUXI

在工具-基于推理的 SQL 生成中考虑错误反馈

Knowledge-to-SQL

引入偏好学习框架,结合数据库执行反馈通过直接偏好优化改进 DE LLM

PET-SQL

提出交叉一致性,包括朴素投票(指示多个 LLM 生成SQL查询,根据不同执行结果多数投票确定最终SQL)和精细投票(根据难度级别改进朴素投票以减轻投票偏差)

5.2 微调

5.2.1 增强架构(Enhanced Architecture)

在基于 LLM 的 Text-to-SQL 中,广泛使用的生成式预训练 Transformer(GPT)框架利用仅解码器的转换器架构和传统的自回归解码来生成文本。然而,随着数据库复杂度增加,生成 SQL 查询的速度明显慢于传统语言建模,成为构建高效本地自然语言接口数据库(NLIDB)的挑战。例如,在处理大型企业级数据库的复杂查询时, LLM 可能需要较长时间才能生成 SQL,影响系统的实时性和可用性。

CLLMs 旨在解决这一问题,通过改进模型架构提高SQL生成速度。其具体改进措施可能涉及优化注意力机制、调整模型参数设置或采用更高效的计算策略等,以减少生成SQL查询时的延迟,从而在保证准确性的同时,提高系统的整体效率,满足实际应用对速度的要求。

5.2.2 数据增强(Data Augmentation)

在微调过程中,训练标签的质量对模型性能有着至关重要的影响。低质量或缺乏训练标签会使微调效果大打折扣,而使用高质量或增强的数据进行微调往往能取得更好的效果。

DAIL-SQL 设计为上下文学习框架,通过采用特定采样策略选择更好的少样本实例,并将其纳入监督微调(SFT)过程,有效提高了开源 LLM 在 Text-to-SQL 任务中的性能。

实现框架与技术

特性

Symbol-LLM

提出在数据增强指令调整中采用注入和输注阶段,增加数据多样性和信息量,帮助模型更好地学习语义映射关系。

CodeS

借助 ChatGPT 通过双向生成扩充训练数据,丰富了数据的多样性和复杂性,使模型能够接触到更多不同类型的样本,从而提高泛化能力

StructLM

通过在多个结构化知识任务上进行训练,提升模型对结构化数据的理解和处理能力,进而提高整体性能,使其在处理与数据库相关的结构化信息时更加准确和高效

5.2.3 预训练(Pre - training)

预训练是完整微调过程的基础阶段,旨在通过在大规模数据上进行自回归训练,使模型获得强大的文本生成能力。当前强大的专有 LLM (如ChatGPT、GPT - 4、Claude等)通常在混合语料上进行预训练,对话场景的数据对其文本生成能力的提升起到了重要作用。而代码特定的 LLM(如CodeLLaMA、StarCoder等)则在代码数据上进行预训练,多种编程语言的混合训练使其能够根据用户指令生成相应代码。

对于 SQL 特定的预训练技术,由于SQL / 数据库相关内容在整个预训练语料库中所占比例较小,开源 LLM 在预训练过程中对如何将自然语言问题转换为SQL的理解相对有限。CodeS 模型的预训练阶段包括三个阶段的增量预训练,从基本的代码特定 LLM 开始,依次在包含SQL-相关数据、NL-to-Code数据和 NL-相关数据 的混合训练语料库上进行训练,显著提高了模型对 Text-to-SQL 任务的理解和性能,使其能够更好地处理自然语言与 SQ L之间的转换。

5.2.4 分解(Decomposition)

在复杂的 Text-to-SQL 场景中,将任务分解为多个步骤或使用多个模型协同解决是一种有效的解决方案。在上下文学习(ICL)范式中,专有模型凭借大量参数能够通过少样本学习等机制较好地执行分配的子任务。然而,微调方法中使用的开源模型参数规模相对较小,因此需要合理分配相应子任务并进行子任务特定的微调,同时构建合适的微调数据,以辅助最终的SQL生成。

DTS SQL提出了一种两阶段分解的 Text-to-SQL 微调框架,在最终 SQL 生成之前,设计了模式链接预生成任务。通过先进行模式链接,帮助模型更好地理解数据库模式与用户问题之间的关系,为后续准确生成SQL查询奠定基础,从而提高整个系统在处理复杂 Text-to-SQL 任务时的性能。

06.展望

6.1 实际应用中的鲁棒性

尽管基于 LLM 的 Text-to-SQL 技术取得了显著进展,但在实际应用场景中,其鲁棒性仍面临诸多挑战。在实际情况中,用户问题往往具有多样性和不规范性,例如用户可能使用模糊的表达方式、包含错别字或使用非标准术语。如“查找那个啥产品的销售数据”,这种不精确的表述增加了系统准确理解用户意图的难度。

当前模型在训练过程中主要依赖于相对规范和明确的数据集,对于实际应用中多样化、不规范的问题适应性较差,导致在实际场景中出现知识差距。例如,当用户问题与训练数据中的标准表达方式差异较大时,模型可能无法准确映射到相应的数据库操作。此外,训练数据本身可能存在问题,如本地 Text-to-SQL 数据集可能包含非标准化样本和标签,表或列的名称可能无法准确反映其实际内容,这会造成训练数据内部的不一致性,进而导致数据库模式与用户问题之间的语义理解困难。

为应对这些挑战,未来研究可从多个方向展开。一是改进模型训练策略,使模型能够更好地处理不规范问题,例如通过增加对抗训练,让模型学习抵御各种干扰因素。二是设计更有效的数据增强方法,扩充训练数据的多样性,涵盖更多实际场景中的问题类型,以减少模型在实际应用中的知识差距。同时,针对微调开源 LLM 适应本地小尺寸数据集的研究也具有重要意义,这有助于提高模型在特定应用场景下的性能,使其能够更好地适应实际业务需求,最终构建更通用、更强大的数据库接口,实现自然语言与数据库之间更加稳健、高效的交互。

6.2 计算效率

随着数据库复杂度的不断提高,如数据库中包含更多的表、列以及更复杂的关系,基于 LLM 的 Text-to-SQL 技术在计算效率方面面临着严峻挑战。在当前的技术实现中,将复杂的数据库模式作为输入时,可能会遇到成本增加和冗余问题。

一方面,调用专有 LLM 处理复杂数据库模式的成本可能显著上升,甚至可能超出模型的最大令牌长度限制,尤其是在使用上下文长度较短的开源模型时,这一问题更为突出。例如,在处理大型企业级数据库时,数据库模式的信息量大,可能导致 LLM 处理时需要消耗大量的计算资源和时间。另一方面,大多数现有方法在处理时直接使用全模式作为模型输入,这往往引入了大量冗余信息,降低了计算效率。

为提高计算效率,未来可探索多种解决方案。一是研究更精确的模式过滤方法,从用户端直接为 LLM 提供与问题相关的精准过滤后的模式,减少不必要的信息输入,从而降低成本并减少冗余。二是在上下文学习范式中,权衡性能与计算效率之间的关系,探索设计性能相当甚至更好但API成本更低的方法。例如,优化提示策略,减少不必要的API调用次数,同时保持较高的SQL生成准确性。对于本地 LLM ,从架构层面入手,研究更多加速策略,如优化模型结构、改进计算算法等,以提高推理速度,满足实际应用对高效处理数据库查询的需求,确保系统在处理复杂数据库时能够快速、准确地生成SQL查询,提升整体性能。

6.3 数据隐私和可解释性

在基于 LLM 的 Text-to-SQL 研究中,数据隐私和可解释性是两个重要但尚未得到充分解决的问题。

在数据隐私方面,当前上下文学习范式中,多数研究使用专有模型,这在处理本地数据库时存在数据隐私风险,因为调用专有API可能导致数据泄露。虽然本地微调范式可以在一定程度上缓解这一问题,但目前其性能并不理想,且先进的微调框架可能仍依赖专有 LLM 进行数据增强,进一步增加了数据隐私泄露的风险。因此,未来需要更多关注适合 Text-to-SQL 任务的本地微调框架的开发,提高其性能,确保在处理敏感数据时能够有效保护数据隐私。

在可解释性方面,深度学习模型一直面临挑战,尽管已有大量研究致力于解决此问题,但在 Text-to-SQL 领域,基于 LLM 的实现无论是上下文学习还是微调范式,其可解释性仍未得到充分探讨。目前,具有分解阶段的方法从逐步生成的角度对 Text-to-SQL 实现过程进行了一定解释,但这还远远不够。

未来,应结合先进的可解释性研究成果,深入探究如何从模型内部机制和决策过程角度增强 Text-to-SQL 的可解释性。例如,通过可视化技术展示 LLM 在生成SQL过程中的内部推理步骤,帮助用户理解模型如何将自然语言问题转化为SQL查询。同时,从数据库知识层面解释模型架构,说明模型如何利用数据库模式信息进行决策,使系统更加透明、可信,便于用户理解和信任模型的输出结果,从而更好地应用于实际场景。

6.4 扩展

Text-to-SQL 作为 LLM 和自然语言理解研究的子领域,与其他相关领域有着紧密的联系和相互促进的关系,在未来有着广阔的扩展空间。

在代码生成领域, Text-to-SQL 与代码生成密切相关,因为 SQL 本身也是一种代码形式。目前,在代码生成中一些精心设计的方法已在 Text-to-SQL 任务中取得了良好性能,并且能够在不同编程语言之间实现一定程度的泛化。例如,某些框架在生成 SQL 时,借鉴了代码生成中处理语法结构和逻辑关系的思路,成功提高了 SQL 生成的准确性和通用性。未来,有望进一步将特定的 Text-to-SQL 框架扩展到更广泛的自然语言到代码(NL-To-Code)研究中,探索如何更好地整合两者的优势,提高系统在多种编程任务中的性能。同时,对于在 Text-to-SQL 中表现出色的执行感知方法,可以尝试扩展到其他代码生成模块中,进一步提升代码生成的质量和效率。

在问答系统方面, Text-to-SQL 可以为基于 LLM 的问答(QA)提供有力支持。数据库中存储的关系知识以结构化信息形式存在,而基于结构的问答(如知识图谱问答、知识库问答等)可以从 Text-to-SQL 中受益。通过将 Text-to-SQL 系统与问答系统相结合,可以利用数据库中的结构化信息为问答提供更准确、更丰富的事实依据。例如,在回答涉及数据查询和分析的问题时,先通过 Text-to-SQL 从数据库中获取相关数据,再将其整合到问答系统的回答中,从而提高答案的准确性和完整性。未来,有望构建更加智能、高效的问答系统,能够自动识别问题类型,当涉及数据库查询需求时,调用 Text-to-SQL 系统获取数据,为用户提供更全面、准确的答案,拓展 LLM 在问答领域的应用范围和能力边界。

综上所述, Text-to-SQL 技术在与其他领域的交叉融合中具有巨大潜力,未来的研究应积极探索这些扩展方向,推动整个自然语言处理和数据库技术领域的发展,为智能信息系统的构建提供更强大的技术支持。

如何学习大模型 AI ?

由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。

但是具体到个人,只能说是:

“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。

这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。

我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述

第一阶段(10天):初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。

  • 大模型 AI 能干什么?
  • 大模型是怎样获得「智能」的?
  • 用好 AI 的核心心法
  • 大模型应用业务架构
  • 大模型应用技术架构
  • 代码示例:向 GPT-3.5 灌入新知识
  • 提示工程的意义和核心思想
  • Prompt 典型构成
  • 指令调优方法论
  • 思维链和思维树
  • Prompt 攻击和防范

第二阶段(30天):高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。

  • 为什么要做 RAG
  • 搭建一个简单的 ChatPDF
  • 检索的基础概念
  • 什么是向量表示(Embeddings)
  • 向量数据库与向量检索
  • 基于向量检索的 RAG
  • 搭建 RAG 系统的扩展知识
  • 混合检索与 RAG-Fusion 简介
  • 向量模型本地部署

第三阶段(30天):模型训练

恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。

到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?

  • 为什么要做 RAG
  • 什么是模型
  • 什么是模型训练
  • 求解器 & 损失函数简介
  • 小实验2:手写一个简单的神经网络并训练它
  • 什么是训练/预训练/微调/轻量化微调
  • Transformer结构简介
  • 轻量化微调
  • 实验数据集的构建

第四阶段(20天):商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。

  • 硬件选型
  • 带你了解全球大模型
  • 使用国产大模型服务
  • 搭建 OpenAI 代理
  • 热身:基于阿里云 PAI 部署 Stable Diffusion
  • 在本地计算机运行大模型
  • 大模型的私有化部署
  • 基于 vLLM 部署大模型
  • 案例:如何优雅地在阿里云私有部署开源大模型
  • 部署一套开源 LLM 项目
  • 内容安全
  • 互联网信息服务算法备案

学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。

如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值