文献阅读：Next-Generation Database Interfaces: A Survey of LLM-Based Text-to-SQL

下一代数据库接口：基于大语言模型的文本转SQL技术综述

洪子瑾、袁征、张庆刚、陈浩、董俊楠、黄飞然（IEEE高级会员）、黄潇

（综述论文）

摘要

由于用户问题理解、数据库模式解析和SQL生成过程中存在诸多复杂性，从用户自然语言问题中生成准确的SQL语句（文本转SQL）仍是一项长期挑战。结合人工工程与深度神经网络的传统文本转SQL系统已取得显著进展，随后预训练语言模型（PLM）被应用于文本转SQL任务并取得了良好效果。然而，随着现代数据库和用户问题的复杂度不断提升，参数量有限的预训练语言模型往往会生成错误的SQL语句，这就需要更复杂、更定制化的优化方法，也因此限制了基于预训练语言模型的系统的实际应用。近年来，随着模型规模的扩大，大语言模型（LLM）在自然语言理解方面展现出卓越能力，因此融合基于大语言模型的解决方案能为文本转SQL研究带来独特的机遇、改进思路和解决方法。本文对现有基于大语言模型的文本转SQL相关研究进行了全面综述：简要介绍了文本转SQL技术的挑战与发展历程，阐述了用于评估文本转SQL系统的数据集和评价指标，系统分析了基于大语言模型的文本转SQL技术的最新研究进展，最后总结了该领域仍存在的挑战，并对未来研究方向进行了展望。

关键词：文本转SQL；大语言模型；数据库；自然语言理解

一、引言

文本转SQL是自然语言处理领域的一项长期研究任务，旨在将自然语言问题转换为可在数据库中执行的SQL查询语句。图1展示了一个基于大语言模型的文本转SQL系统实例：当用户提出"能否告诉我历史上比赛场次最多的5个联赛名称及其对应的比赛场次？"这一问题时，大语言模型将该问题及对应的数据库模式作为输入，生成SQL查询语句；在数据库中执行该SQL语句，即可提取出回答用户问题所需的相关信息。该系统借助大语言模型构建了数据库的自然语言接口（NLIDB）。SQL是目前应用最广泛的编程语言之一，超过半数（51.52%）的专业开发人员都会使用该语言，但仅有约三分之一（35.29%）的开发人员接受过系统的SQL培训⁽¹⁾。数据库自然语言接口让非专业用户也能像专业数据库工程师一样访问结构化数据库⁽²⁾⁽³⁾，同时提升了人机交互的效率⁽⁴⁾。此外，在大语言模型成为研究热点的背景下，文本转SQL技术可通过融合数据库中的真实内容填补大语言模型的知识空白，有望缓解其普遍存在的幻觉问题⁽⁵⁾。

文本转SQL技术的重要价值推动了大量关于其与大语言模型融合优化的研究⁽⁶⁾⁽⁷⁾⁽⁸⁾，因此基于大语言模型的文本转SQL技术至今仍是自然语言处理和数据库领域的研究热点。

传统方法在文本转SQL的落地应用中已取得显著进展，其实现方式经历了漫长的发展过程（见图2）。

早期研究多基于精心设计的规则和模板⁽⁹⁾，适用于简单的数据库应用场景。近年来，由于规则化方法的人力成本过高⁽¹⁰⁾，且数据库应用环境的复杂度持续提升⁽¹¹⁾⁽¹²⁾⁽¹³⁾，为每个应用场景设计专属规则或模板的方式愈发困难且不切实际。深度神经网络的发展推动了文本转SQL技术的进步⁽¹⁴⁾⁽¹⁵⁾，该技术可自动学习从用户问题到对应SQL语句的映射关系⁽¹⁶⁾⁽¹⁷⁾。随后，具备强大语义解析能力的预训练语言模型成为文本转SQL系统的新范式⁽¹⁸⁾，将系统性能提升到了新高度⁽¹⁹⁾⁽²⁰⁾⁽²¹⁾。针对预训练语言模型的增量优化研究（如表内容编码⁽¹⁷⁾⁽¹⁸⁾⁽²²⁾、预训练优化⁽¹⁸⁾⁽²³⁾等）进一步推动了该领域的发展。近期，基于大语言模型的方法通过上下文学习⁽⁷⁾和微调⁽²⁴⁾两种范式实现文本转SQL任务，借助精心设计的框架和更强的语义理解能力，取得了超越预训练语言模型方法的当前最优精度。

基于大语言模型的文本转SQL技术的整体实现细节可分为三个方面：1.问题理解：自然语言问题是用户意图的语义表达，生成的SQL查询语句需与用户意图精准匹配；2.模式解析：数据库模式定义了数据库的表和列结构，文本转SQL系统需识别出与用户问题匹配的目标数据库组件；3.SQL生成：结合上述解析结果，预测正确的SQL语法，生成可执行的SQL查询语句以提取所需答案。得益于丰富的训练语料赋予的强大语义解析能力⁽²⁶⁾⁽²⁷⁾，大语言模型已实现了文本转SQL的基础落地⁽⁶⁾⁽²⁵⁾。目前，针对增强大语言模型的问题理解⁽⁷⁾⁽⁸⁾、模式解析⁽²⁸⁾⁽²⁹⁾和SQL生成⁽³⁰⁾能力的相关研究正不断涌现。

尽管文本转SQL研究已取得显著进展，但仍存在诸多挑战，阻碍了鲁棒、通用的文本转SQL系统的发展⁽⁹²⁾。现有相关研究已对基于深度学习的文本转SQL系统进行了综述，并为此前基于深度神经网络和预训练语言模型的研究提供了思路⁽³⁾⁽²⁷⁾⁽⁹³⁾⁽⁹⁴⁾。本文旨在追踪该领域的最新进展，全面综述基于大语言模型的文本转SQL技术的当前最优模型和方法：首先介绍文本转SQL的基本概念和挑战，阐明该任务在各领域的重要性；随后梳理文本转SQL系统实现范式的发展历程，探讨该领域的关键进展和突破；在此基础上，详细介绍并分析大语言模型与文本转SQL技术融合的最新研究成果。具体而言，本文的核心内容包括以下方面：

基准数据集与评价指标：介绍评估基于大语言模型的文本转SQL系统的常用数据集和基准测试集，分析其特征、复杂度及带来的开发和评估挑战，并阐述相关评价指标。
方法策略：系统分析基于大语言模型的文本转SQL技术的各类方法，包括上下文学习和微调两种范式，从技术实现角度分类梳理其细节、优势及针对性适配方案。
总结与展望：总结基于大语言模型的方法与传统方法的优劣，同时对比基于大语言模型的不同方法的特点；探讨该领域仍存在的挑战，如实际场景的鲁棒性、计算效率、数据隐私及潜在的扩展方向；此外，梳理未来的研究方向和优化机遇。

本文的技术贡献可总结为：在论文发表时，首次在学术界完成了基于大语言模型的文本转SQL技术综述，建立了该技术的系统分类体系，从技术实现角度展开分析，明确了各类方法对优化SQL生成效果的贡献；结合分析结果，总结了基于大语言模型的方法与传统方法、上下文学习与微调范式之间的权衡关系，为未来研究提供参考；最后，指出了该领域在鲁棒性、实际落地、效率和领域适配方面仍存在的挑战，并提出了具有可操作性的未来研究方向。

图3展示了本文的研究分类体系。

二、概述

文本转SQL任务旨在将自然语言问题转换为可在关系型数据库中执行的SQL查询语句，该技术有望实现数据访问的平民化------用户可通过自然语言与数据库交互，无需掌握专业的SQL编程知识⁽⁹⁵⁾。这一能力能让非专业用户轻松从数据库中提取目标信息，提升数据分析效率，因此在商业智能、客户服务、科学研究等领域具有重要应用价值。

2.1 文本转SQL的技术挑战

文本转SQL的技术挑战可总结为以下四点：

语言的复杂性与模糊性：自然语言问题往往包含嵌套从句、指代关系、省略表达等复杂语言形式，难以精准映射到SQL查询语句的对应部分⁽³⁸⁾。此外，自然语言本身具有模糊性，同一个用户问题可能存在多种表达形式⁽⁹⁶⁾⁽⁹⁷⁾。要解决这些模糊性问题、准确理解用户问题背后的意图，需要系统具备深度自然语言理解能力，且能融合上下文和领域知识⁽¹⁾。
数据库模式的理解与表示：要生成准确的SQL查询语句，文本转SQL系统需全面理解数据库模式，包括表名、列名及各表之间的关联关系。数据库模式的表示和编码具有挑战性，因为实际的数据库模式通常较为复杂，且在不同领域间存在显著差异⁽¹¹⁾。
稀有且复杂的SQL操作：在复杂场景下，部分SQL查询语句会涉及嵌套子查询、外连接、窗口函数等稀有或复杂的操作和语法。这些操作在训练数据中出现的频率较低，给文本转SQL系统的准确生成带来了挑战。因此，设计能对各类SQL操作（包括稀有和复杂场景）实现泛化的模型，是该领域的重要研究方向。
跨领域泛化能力：文本转SQL系统往往难以在不同的数据库场景和领域间实现泛化。在特定领域训练的模型，面对其他领域的问题时性能会显著下降，这是由于不同领域的词汇、数据库模式结构和问题表述模式存在差异。如何让系统在仅使用少量领域专属训练数据或微调适配的情况下，有效适配新领域，是该领域的一大挑战⁽⁹⁸⁾。

2.2 发展历程

在自然语言处理领域，文本转SQL研究历经了显著发展，从基于规则的方法逐步演进到基于深度学习的方法，近期又发展到融合预训练语言模型（PLM）和大语言模型（LLM）的阶段，其发展历程如图2所示。

基于规则的方法

早期的文本转SQL系统高度依赖基于规则的方法⁽⁹⁾⁽¹⁰⁾⁽²³⁾，通过人工设计的规则和启发式算法实现自然语言问题到SQL查询语句的映射。基于规则的系统依托预定义模板和严格的语法规则，能生成语法正确的SQL语句，保证SQL语法和结构的规范性；其确定性特征使特定输入模式能得到一致的输出结果，降低了查询生成的变异性。但这类方法难以解析包含嵌套从句、指代关系、省略表达等复杂或模糊的自然语言问题，也往往无法将这些语言元素映射到数据库表、列等模式组件；对人工规则的依赖使其难以泛化到未见过的问题模式或数据库模式结构，针对新领域需要频繁更新规则；此外，将包含多表关联的复杂数据库模式编码为可用规则的过程耗时费力，且容易出错。
基于深度学习的方法

随着深度神经网络的兴起，序列到序列模型和编解码结构（如长短期记忆网络⁽⁹⁹⁾、Transformer模型⁽¹⁵⁾）被应用于从自然语言输入生成SQL查询语句的任务⁽¹⁷⁾⁽¹⁰⁰⁾。典型的如RYANSQL⁽¹⁷⁾，该方法引入中间表示和基于草图的槽位填充技术，处理复杂问题并提升跨领域泛化能力。近期，研究人员利用模式依赖图捕捉数据库元素间的关联关系，将图神经网络应用于文本转SQL任务⁽¹⁶⁾⁽¹⁰¹⁾。尽管这类方法具有灵活性，但由于对SQL结构的感知能力有限，往往会生成语法错误或不完整的SQL语句，如缺失从句、嵌套不当等；同时，由于嵌套子查询、窗口函数等复杂SQL操作在训练数据中占比偏低，系统难以准确处理这类操作。
基于预训练语言模型的实现方法

预训练语言模型凭借预训练过程中捕捉的海量语言知识和语义理解能力，成为解决文本转SQL问题的有效方案。预训练语言模型在文本转SQL领域的早期应用，主要聚焦于在标准文本转SQL数据集⁽¹¹⁾⁽¹²⁾上对BERT⁽¹⁰²⁾、RoBERTa⁽¹⁰³⁾等通用预训练语言模型进行微调⁽¹¹⁾⁽¹²⁾。这些预训练语言模型基于大规模训练语料训练而成，具备丰富的语义表示能力和语言理解能力，研究人员希望通过在文本转SQL任务上的微调，借助其语义和语言理解能力生成准确的SQL语句⁽¹⁸⁾⁽¹⁰⁰⁾⁽¹⁰⁴⁾。另一类研究则聚焦于将数据库模式信息融入预训练语言模型，提升其对数据库结构的理解能力，从而生成更易执行的SQL语句⁽¹⁹⁾。面向模式感知的预训练语言模型被设计用于捕捉数据库结构中的关联关系和约束条件。尽管预训练语言模型生成的SQL语句比基于深度学习的方法更准确，但在处理外连接、聚合操作等复杂操作时仍存在不足，往往会生成语法有缺陷的查询语句；此外，当数据库模式结构或词汇与训练数据存在差异时，模型的跨领域性能会显著下降，需要耗费大量资源进行微调。
基于大语言模型的实现方法

近年来，GPT系列⁽¹⁰⁵⁾⁽¹⁰⁶⁾⁽¹⁰⁷⁾等大语言模型因能生成连贯、流畅的文本而备受关注。研究人员开始探索大语言模型在文本转SQL领域的应用潜力，借助其丰富的知识储备和卓越的生成能力完成任务⁽⁶⁾⁽⁸⁾。这类方法通常通过提示工程引导闭源大语言模型生成SQL语句⁽¹⁰⁸⁾，或在文本转SQL数据集上对开源大语言模型进行微调⁽⁸⁾。

大语言模型与文本转SQL技术的融合仍是一个新兴研究领域，具有巨大的探索和优化潜力。目前，研究人员正致力于探索更有效的方式，以充分利用大语言模型的知识和推理能力、融合领域专属知识⁽¹⁾⁽⁷⁰⁾，并开发更高效的微调策略⁽²⁴⁾。随着该领域的不断发展，预计将出现更先进、更优秀的基于大语言模型的实现方案，推动文本转SQL技术的性能和泛化能力迈上新台阶。

三、基准数据集与评价体系

本节将介绍文本转SQL的基准测试体系，包括主流数据集和评价指标。

3.1 数据集

如表1所示，根据数据集是否随原始数据库一同发布，或是否通过对现有数据集和数据库进行特殊设置适配开发而成，我们将其分为"原始数据集"和"后标注数据集"。对于原始数据集，我们将详细分析其样本量、数据库数量、单数据库表数量和单数据库行数量；对于后标注数据集，我们将明确其源数据集，并描述所采用的特殊设置。为了凸显每个数据集的潜在应用价值，我们根据其特征进行了标注，标注信息列于表1最右侧，并将在下文详细说明。

数据集特征分类

跨领域数据集：此类数据集的各数据库背景信息来自不同领域。由于实际的文本转SQL应用往往涉及多领域数据库，因此大多数原始文本转SQL数据集⁽¹⁾⁽¹¹⁾⁽¹²⁾⁽³¹⁾⁽³²⁾⁽³³⁾和后标注数据集⁽³⁴⁾⁽³⁵⁾⁽³⁶⁾⁽³⁷⁾⁽³⁸⁾⁽³⁹⁾⁽⁴⁰⁾均采用跨领域设置，以满足跨领域应用的需求。
知识增强数据集：近年来，将领域专属知识融入文本转SQL任务的研究受到广泛关注。BIRD数据集⁽¹⁾由数据库领域专家为每个文本转SQL样本标注外部知识，分为数值推理知识、领域知识、同义词知识和数值说明四类；类似地，Spider-DK数据集⁽³⁶⁾为人工整理的Spider数据集⁽¹¹⁾定义并添加了五类领域知识，包括省略提及的查询列、需简单推理的内容、单元格值词汇的同义词替换、单个非单元格值词汇生成的条件、易与其他领域混淆的内容。两项研究均发现，人工标注的知识能显著提升需要外部领域知识的样本的SQL生成性能。此外，SQUALL数据集⁽⁴¹⁾人工标注了自然语言问题中的词汇与SQL中实体的对齐关系，相比其他数据集提供了更细粒度的监督信息。
上下文依赖数据集：SParC数据集⁽⁴⁰⁾和CoSQL数据集⁽³²⁾通过构建对话式数据库查询系统，探索上下文依赖的SQL生成任务。与传统文本转SQL数据集不同（单个样本仅包含一对问题-SQL语句），SParC数据集将Spider数据集中的问题-SQL样本分解为多个子问题-子SQL对，构建具有实际意义的模拟交互场景，既包含有助于SQL生成的关联子问题，也包含提升数据多样性的无关子问题。CoSQL数据集则通过自然语言的对话交互模拟实际应用场景，提升了任务的复杂度和数据多样性。此外，Spider-SS&CG数据集⁽³⁵⁾将Spider数据集中的自然语言问题拆分为多个子问题和子SQL语句，研究表明，在这些子样本上训练能提升文本转SQL系统对分布外样本的泛化能力。
鲁棒性数据集：利用被污染或扰动的数据库内容（如模式、表）评估文本转SQL系统的精度，是检验系统鲁棒性的关键。Spider-Realistic数据集⁽³⁸⁾删除了自然语言问题中明确的模式相关词汇，Spider-SYN数据集⁽³⁷⁾则将这些词汇替换为人工选择的同义词；ADVETA数据集⁽³⁴⁾引入对抗性表扰动技术，通过将原始列名替换为具有误导性的名称、插入语义关联度高但等价性低的新列，实现对表的扰动；基于大规模预训练语言模型的生成能力，Dr. Spider数据集⁽⁴⁴⁾提出了17种针对数据库、自然语言查询和SQL语句的扰动策略，用于衡量文本转SQL系统的鲁棒性。这些扰动会导致系统精度显著下降，因为鲁棒性差的系统容易被自然语言问题中的词汇与数据库实体的错误匹配所误导。
跨语言数据集：SQL的关键字、函数名、表名和列名通常以英文书写，这给非英语场景的应用带来了挑战。CSpider数据集⁽³⁹⁾将Spider数据集翻译为中文，发现了中文问题与英文数据库内容之间的分词和跨语言匹配新挑战；DuSQL数据集⁽³¹⁾构建了实用的文本转SQL数据集，其中自然语言问题为中文，数据库内容同时提供英文和中文版本；Spider-Vietnamese数据集⁽⁴³⁾将Spider数据集翻译为越南语，通过实证研究提出了提升越南语场景下文本转SQL方法性能的多种策略。
长上下文数据集：在实际的数据库应用中，诸多复杂场景需要生成令牌长度极长的复杂SQL查询语句（通常超过100个令牌），且涉及多种复杂操作。Spider 2.0数据集⁽⁴²⁾是该类复杂场景的典型代表，其提出的企业级文本转SQL问题需要对各类SQL查询语句和方言进行高级推理。与早期基准数据集不同，Spider 2.0数据集包含大量来自BigQuery、Snowflake等实际生产数据库的真实任务，其工业级模式规模庞大，包含数百甚至数千列，且存在嵌套结构，单个实例对应多个模式。每个任务不仅需要处理复杂的SQL逻辑，还需要融合项目代码库、数据库元数据和方言专属文档的信息，高度贴合企业场景下的数据工作流。该基准数据集中的标准SQL查询语句平均令牌数接近150个，在长度和复杂度上远超以往的数据集。值得注意的是，所有SQL语句均经过精心标注和审核，保证了语义的准确性和执行的正确性，确保数据集的挑战具有现实性和鲁棒性。因此，Spider 2.0数据集凸显了当前大语言模型的能力与真实长上下文数据库场景需求之间的巨大差距。与此同时，BIRD-CRITIC数据集⁽¹⁾引入了诊断维度，包含600个任务，用于评估大语言模型在不同SQL方言下解决实际用户问题的效果。这些数据集共同推动了文本转SQL研究的边界，凸显了复杂长上下文SQL环境带来的挑战。
专属领域数据集：尽管文本转SQL研究取得了诸多进展，但针对领域专属分析的数据集仍十分匮乏。为填补这一空白，BULL数据集⁽⁴⁵⁾构建了面向金融领域的专用文本转SQL基准数据集，包含基金、股票、宏观经济数据相关的数据库，为评估和提升文本转SQL方法在金融领域的应用效果提供了全面平台，有效解决了金融领域文本转SQL任务的独特挑战。

3.2 评价指标

本文介绍四种文本转SQL任务的主流评价指标，分为基于SQL内容匹配的组件匹配、精确匹配，以及基于执行结果的执行精度、有效效率分数。

基于内容匹配的指标
基于内容匹配的SQL评价指标，通过对比预测SQL语句与标准SQL语句的结构和语法相似度进行评估。

组件匹配（CM）⁽¹¹⁾：通过计算预测SQL语句与标准SQL语句的核心组件（查询列、筛选条件、分组、排序、关键字）的精确匹配度（F1值），评估文本转SQL系统的性能。该指标将每个组件分解为若干子组件进行精确匹配，且不考虑SQL组件的顺序。
精确匹配（EM）⁽¹¹⁾：计算预测SQL语句与标准SQL语句完全一致的样本占比。只有当预测SQL语句的所有组件（如组件匹配指标所定义）与标准SQL语句完全匹配时，才判定该预测结果正确。

基于执行结果的指标
基于执行结果的评价指标，通过将生成的SQL语句在目标数据库中执行，对比执行结果与预期结果，评估SQL语句的正确性。

执行精度（EX）⁽¹¹⁾：将预测SQL语句在对应数据库中执行，对比其执行结果与标准SQL语句的执行结果，以此衡量预测SQL语句的正确性。
有效效率分数（VES） ⁽¹⁾：用于衡量可有效执行的SQL语句的效率，有效SQL语句 指执行结果与标准SQL语句完全一致的预测SQL语句。该指标同时评估预测SQL语句的效率和准确性，对于包含N个样本的数据集，其计算公式为：

其中，(\hat{Y}{n})和(\hat{V} {n})分别为预测SQL语句及其执行结果，(Y_{n})和(V_{n})分别为标准SQL语句及其执行结果；(\mathbb{1}(V_{n}, \hat{V}_{n}))为指示函数，其定义为：

(R(Y_{n}, \hat{Y}{n})=\sqrt{E(Y {n}) / E(\hat{Y}{n})})表示预测SQL语句相对标准SQL语句的执行效率，其中(E(\cdot))为SQL语句在数据库中的执行时间。为保证该指标的稳定性，BIRD基准数据集⁽¹⁾对每个样本的(R(Y{n}, \hat{Y}_{n}))值进行100次运行并取平均值。

近期大多数基于大语言模型的文本转SQL研究均以BIRD和Spider系列数据集为基准，并采用基于执行结果的评价指标，具体细节见表3。

四、方法策略

随着性能强大的闭源大语言模型和架构优秀的开源大语言模型的大量涌现⁽¹⁰⁷⁾⁽¹¹⁴⁾⁽¹¹⁵⁾⁽¹¹⁶⁾⁽¹¹⁷⁾⁽¹¹⁸⁾，当前基于大语言模型的文本转SQL方法主要依托上下文学习（ICL） ⁽¹⁰⁹⁾⁽¹¹⁰⁾⁽¹¹¹⁾和微调（FT）⁽¹¹²⁾⁽¹¹³⁾两种范式实现。本节将对这两种范式进行详细分类和探讨。

4.1 上下文学习

大量公认的研究表明，上下文学习（也称为提示工程）对大语言模型在各类任务中的性能起着决定性作用⁽²⁶⁾⁽¹¹⁹⁾，因此也影响着不同提示风格下的SQL生成效果⁽⁸⁾⁽¹²⁰⁾。基于大语言模型的文本转SQL技术在上下文学习范式下生成预测SQL语句(\hat{Y})的过程可表示为：

其中，(I)为文本转SQL任务的指令，(Q)为用户问题，(\mathcal{S})为数据库模式/内容，可分解为(\mathcal{S}=<C, T, K>)（(C={c_{1}, c_{2}, ...})为所有列的集合，(T={t_{1}, t_{2}, ...})为所有表的集合，(K)为潜在的补充知识，如外键关系⁽⁶⁸⁾、模式链接⁽²⁸⁾⁽²⁹⁾、外部知识⁽¹⁾⁽⁷⁰⁾等）；(\pi(\cdot | \theta))为带有参数(\theta)的大语言模型(\pi)。在上下文学习范式中，基于大语言模型的方法通常直接使用成熟的文本转SQL模型（即冻结模型参数(\theta)）生成预测SQL语句。

我们将上下文学习范式中的提示工程策略进一步分为零样本提示 和少样本提示 。大语言模型经过海量数据训练，在零样本和少样本提示下对不同下游任务具有强大的泛化能力⁽¹¹²⁾⁽¹²¹⁾⁽¹²²⁾，这一点已得到广泛认可并应用于实际场景。形式上，文本转SQL任务的零样本提示整体输入(P_{0})由上述的指令(I)、模式(\mathcal{S})和问题(Q)拼接而成：

而少样本提示（特指k样本）的整体输入(P_{k})是零样本提示输入的扩展：

其中，(k)为少样本提示中提供的实例（样本）数量，(\mathcal{E}{i})为第(i)个少样本实例，可分解为(\mathcal{E}{i}=(S_{i}, Q_{i}, Y_{i}))（(Y_{i})为问题(Q_{i})对应的标准SQL语句），索引(i \in{1, ..., k})同时对应(S_{i})、(Q_{i})、(Y_{i})的序号。OpenAI的官方示例⁽³⁾为基于大语言模型的文本转SQL提示过程提供了指导性案例和规范，本文综述的大部分上下文学习方法均基于该规范设计提示方案和格式，且多数方法将零样本和少样本提示融入其文本转SQL框架。

作为基于大语言模型的文本转SQL技术的主流研究方向，上下文学习范式下涌现了多种精心设计的方法以提升大语言模型的SQL生成能力。本节将现有方法分为五大类（(C_{0: 4})），包括基础提示（(C_{0})）、分解策略（(C_{1})）、提示优化（(C_{2})）、推理增强（(C_{3})）和执行优化（(C_{4})），各类别的代表性方法见表2，并将在下文逐一介绍，且在每个类别开头总结其特征。

4.1.1 基础提示（(C_{0})）

本文发现一类未设计专属上下文学习框架的提示策略，这类策略仅基于零样本和少样本提示实现，虽形式简单，但为基于大语言模型的文本转SQL技术的上下文学习范式提供了有价值的见解和发现，我们将其称为基础提示策略，并进一步分为零样本研究和少样本研究。

零样本研究：基于零样本的上下文学习策略主要研究提示表示风格的影响，以及各类大语言模型在文本转SQL任务中的基准性能⁽⁶⁾⁽²⁵⁾⁽¹²⁰⁾。作为一项实证评估研究，文献⁽⁶⁾评估了多款早期大语言模型⁽¹⁰⁶⁾⁽¹²³⁾⁽¹²⁴⁾的文本转SQL基础能力，以及其在不同提示风格下的性能，实验结果表明提示设计对性能至关重要；通过误差分析，该研究进一步指出，融入过多数据库内容可能会降低文本转SQL的整体精度。ChatGPT⁽¹⁰⁶⁾凭借在对话场景和代码生成方面的出色表现问世后，文献⁽²⁵⁾⁽¹²⁵⁾评估了其在Spider数据集⁽¹¹⁾及其变体数据集⁽³⁶⁾⁽³⁷⁾⁽³⁸⁾上的性能，结果表明，在零样本设置下，ChatGPT的文本转SQL性能优于当前最优的基于预训练语言模型的系统。除上述闭源模型外，同类评估研究表明，开源大语言模型也能完成零样本文本转SQL任务⁽⁸³⁾⁽¹¹⁴⁾⁽¹²⁰⁾，尤其是面向代码生成的专用模型⁽⁸⁰⁾⁽¹²⁰⁾。

主键和外键承载着不同表之间的关联知识，是零样本场景下的有效提示风格。文献⁽⁶⁸⁾研究了将主键和外键融入不同提示表示风格（结合不同数据库内容）对模型性能的影响；一项基准评估研究⁽⁸⁾也利用五种不同的提示表示风格，评估了外键的作用，每种风格均可视为指令、规则隐含信息和外键元素的组合。除使用外键外，该研究还探索了结合"无解释"规则隐含信息的零样本提示，以生成简洁的输出结果；借助领域专家标注的外部知识，在BIRD基准数据集⁽¹⁾上的评估结果表明，融入人工标注的先验知识能显著提升模型性能。

在零样本提示优化方面，文献⁽¹²⁰⁾指出，为大语言模型设计有效的提示模板存在挑战，以往简单的提示构建方式往往缺乏结构一致性，难以确定提示模板中影响模型性能的具体元素。为解决该问题，该研究探索了一套更统一的提示模板，包含各类前缀、中缀和后缀；为保证对比的公平性，文献⁽¹⁰⁸⁾通过研究不同的提示表示风格，探索大语言模型的有效提示构建方式，并指出表结构、表内容、提示长度和最优表示形式在有效提示中的关键作用。

少样本研究：少样本提示策略的研究聚焦于少样本实例的数量和选择方法。实证研究通过各类大语言模型，在多个数据集上评估了文本转SQL任务的少样本提示效果⁽⁷⁾⁽³⁰⁾，结果表明其性能相比零样本提示有显著提升。文献⁽¹⁾提供了详细的1样本示例，用于引导文本转SQL模型生成准确的SQL语句；文献⁽⁷⁵⁾探索了少样本示例数量对模型性能的影响；文献⁽⁶⁵⁾聚焦于采样策略，分析了不同演示样本之间的相似度和多样性，将随机采样作为基准，评估了多种采样策略及其组合的效果。此外，除基于相似度的选择方法外，文献⁽⁸⁾还评估了掩码问题相似度选择方法，以及不同少样本示例数量下基于相似度方法的性能上限。

一项针对难度级别样本选择的研究⁽⁴⁷⁾，在按难度分类的数据集⁽¹¹⁾⁽³⁸⁾上，对比了少样本Codex模型⁽¹²⁴⁾在随机选择和基于难度选择少样本实例时的性能，并基于按难度选择的样本设计了三种采样策略。文献⁽⁶⁸⁾采用混合选择策略，将静态示例和基于相似度的动态示例结合用于少样本提示，并在该设置下评估了不同输入模式风格、不同数量的静态和动态示例对模型性能的影响。

跨领域示例的影响也受到研究关注⁽⁶⁷⁾，当融入不同数量的域内和域外示例时，域内演示样本的性能优于零样本和域外示例，且性能随示例数量的增加而提升。为探索提示的详细构建方式，文献⁽⁷⁴⁾对比了简洁型和详细型提示设计策略：前者将模式、列名、主键、外键分离展示，后者则将其组织为自然语言描述形式。

4.1.2 分解策略（(C_{1})）

基于分解的方法通过将文本转SQL任务或问题拆分为多个易处理的子组件，降低任务复杂度，主要采用两种策略：

多模块协同：将文本转SQL任务拆分为多个专属阶段（如模式链接、SQL生成、SQL优化），由不同的模块或智能体负责处理。C3⁽²⁸⁾采用三模块流水线架构，包括基于精准提示的模式链接、基于校准偏差提示的SQL引导，以及基于一致性投票的结果最终选择；类似地，MAC-SQL⁽⁴⁸⁾和CHESS⁽⁵⁶⁾采用多智能体框架，由专属智能体分别处理模式选择、任务分解和结果优化；以工作流为核心的方法（如Distillery⁽⁵⁸⁾、DEA-SQL⁽⁴⁹⁾）将任务拆分为检索、生成、修正阶段；迭代优化和结构分解也是常用策略，DIN-SQL⁽⁷⁾融合了四阶段流水线架构，包括模式链接、分类、SQL生成和自校正；Coder-Reviewer⁽⁴⁶⁾将SQL生成和验证拆分为两个独立模型；PET-SQL⁽⁵²⁾通过多阶段提示优化输出结果；MCS-SQL⁽⁵⁵⁾在多次SQL生成后，将基于执行结果的引导选择作为最终模块。随着近期提出的基准数据集复杂度不断提升，ReFoRCE⁽⁶¹⁾、LinkAlign⁽⁶²⁾、Spider-Agent⁽⁴²⁾等智能体框架借助为大语言模型设计的分步行动计划，实现了面向最终SQL语句的系统性推理。
问题分解：通过问题分解将复杂的用户问题拆分为多个中间子问题，降低任务复杂度。QDecomp⁽⁴⁷⁾采用由浅入深提示法，将复杂问题拆分为分步的子问题，辅助SQL生成；SGU-SQL⁽³⁰⁾采用基于图的结构链接和元操作，分解符合语法规则的子问题；基于元数据的方法（如MetaSQL⁽⁵⁰⁾、TA-SQL⁽⁵⁴⁾）通过元数据条件约束和任务对齐的模式链接，进一步分解问题。同时，DIN-SQL⁽⁷⁾、MAC-SQL⁽⁴⁸⁾等框架将问题分解作为辅助模块，核心仍聚焦于模块级协同。

4.1.3 提示优化（(C_{2})）

面向文本转SQL的提示优化方法聚焦于提升提示工程的质量，主要分为三大策略：

高级少样本采样：通过语义相似度、多样性或领域对齐优化示例选择。DESEM⁽⁶³⁾和基于检索增强的框架⁽⁵⁸⁾⁽⁶⁶⁾⁽⁷¹⁾对问题进行去语义化处理，检索意图框架匹配或向量嵌入相似的示例；DAIL-SQL⁽⁸⁾通过掩码领域专属令牌、基于问题与SQL语句的欧氏距离排序示例，平衡样本的质量和数量；SAFE-SQL⁽⁷³⁾将框架掩码与自增强结合；ODIS⁽⁶⁷⁾融合域外示例和合成域内示例，提升模型鲁棒性；FUSED⁽⁶⁹⁾通过迭代演示样本合成提升多样性；ACT-SQL⁽⁶⁸⁾和MCS-SQL⁽⁵⁵⁾探索了动态选择策略，基于定义的相似度分数或掩码相似度分数自适应检索示例。
模式增强：优化数据库模式的表示形式，降低冗余并提升相关性。C3⁽²⁸⁾通过删除无关的表或列，提取与问题相关的模式；RSL-SQL⁽⁵⁹⁾采用自然语言描述简化模式；ReFoRCE⁽⁶¹⁾通过表压缩和列探索，处理长上下文模式的复杂度；Gen-SQL⁽⁶⁰⁾通过生成与用户问题对齐的伪模式，弥补自然语言与SQL之间的差距；QDecomp⁽⁴⁷⁾和SD+SA+Voting⁽⁶⁵⁾进一步为提示融入基于模式感知的语义和结构提示信息；对于更复杂的数据库，LinkAlign⁽⁶²⁾提出基于模式的问题重写策略，并结合"检索-过滤"模式选择机制，提升链接的准确性。
外部知识融合：为提示融入领域专属知识或反馈机制。Knowledge-to-SQL⁽⁷⁰⁾训练深度增强大语言模型（DELLM），将用户问题与数据库的关联外部知识注入模型；ICRL⁽⁷²⁾将强化学习与基于模式图的知识库融合；MAC-SQL⁽⁴⁸⁾和DIN-SQL⁽⁷⁾将分解模式作为过程知识隐式融入，引导SQL生成；C3⁽²⁸⁾和SAFE-SQL⁽⁷³⁾分别融入校准偏差和自增强反馈循环，实现输出结果的迭代优化。

4.1.4 推理增强（(C_{3})）

推理增强方法通过结构化推理和一致性机制，提升大语言模型处理复杂SQL语句的能力，主要聚焦于三大关键策略：

基于思维链（CoT）的推理：基于思维链的方法引导大语言模型在生成SQL语句前，先生成中间推理步骤。尽管标准的思维链提示（如"让我们分步思考"）在文本转SQL任务中的效果有限⁽¹⁾⁽⁸⁾，但经过适配后的思维链方法能有效弥补这一不足。ACT-SQL⁽⁶⁸⁾通过相似度匹配将问题片段与数据库列链接，实现思维链示例的自动生成；QDecomp⁽⁴⁷⁾将SQL从句按执行流程重组为逻辑步骤，相比通用思维链方法降低了误差传播；CHASE-SQL⁽⁷⁷⁾进一步扩展为基于"分治"思维链策略的多路径推理，实现候选SQL语句的生成。
基于一致性的推理：这类方法通过增加候选SQL语句的多样性、引入一致性度量，在执行前提升结果的可靠性。C3⁽²⁸⁾、DAIL-SQL⁽⁸⁾、SuperSQL⁽⁵⁷⁾等框架采用自一致性策略⁽¹²⁶⁾，基于语法或结构相似度的多数投票选择出现频率最高的SQL候选语句；SD+SA+Voting⁽⁶⁵⁾对该策略进行优化，在投票前通过基于模式感知的规则（如有效连接、从句顺序）过滤候选语句。与依赖执行结果的方法不同，这类策略更注重逻辑一致性和语法有效性，而非运行时反馈，因此模型轻量化但对语义错误的鲁棒性较差。
基于工具增强和智能体的推理：混合技术将SQL生成与外部计算或工具结合。SQL-CRAFT⁽⁷⁵⁾采用思维程序（PoT）提示法⁽¹²⁷⁾，要求大语言模型在生成SQL语句的同时生成Python代码，处理涉及大量算术运算的查询问题，提升了在BIRD数据集⁽¹⁾上的性能；FUXI⁽⁷⁶⁾融合了用于模式链接和语法检查的专属工具，在生成过程中动态调用；与纯提示策略不同，这类方法将大语言模型的推理能力与外部符号系统明确结合。此外，ReFoRCE⁽⁶¹⁾、Spider-Agent⁽⁴²⁾等近期框架采用分步智能体推理，让大语言模型作为专属智能体，通过迭代规划操作处理复杂的数据库场景。

4.1.5 执行优化（(C_{4})）

执行优化方法利用数据库的执行反馈，通过重新生成或最优SQL选择提升语句精度，主要分为两种范式：

基于反馈的重生成：这类方法利用执行错误或中间结果，迭代优化SQL查询语句。Self-Debugging⁽⁸⁰⁾让大语言模型通过自然语言解释执行失败的原因，自主修正错误；DESEM⁽⁶³⁾采用针对错误类型的专属提示，并设置终止条件，防止无限循环；MAC-SQL⁽⁴⁸⁾、CHASE-SQL⁽⁷⁷⁾等多智能体框架利用智能体（如优化器、查询修正器）诊断SQLite错误，并重新生成修正后的SQL语句；SQL-CRAFT⁽⁷⁵⁾引入自适应控制，平衡修正的深度，防止过度优化；RSL-SQL⁽⁵⁹⁾、DIN-SQL⁽⁷⁾等基于模式的方法采用通用或温和的提示，帮助大语言模型在重生成过程中识别模式不匹配问题；Knowledge-to-SQL⁽⁷⁰⁾通过从执行反馈中进行偏好学习，优化深度增强大语言模型；FUXI⁽⁷⁶⁾将错误反馈融入基于工具的推理过程；E-SQL⁽⁸¹⁾通过基于执行结果的候选预测，增强用户问题的表达；智能体框架⁽⁴²⁾也融入了基于反馈的重生成策略，由专属智能体迭代分析执行反馈，规划修正操作以优化SQL语句。
基于执行结果的选择：这类策略利用数据库的执行结果，对候选SQL语句进行选择或排序。ReFoRCE⁽⁶¹⁾和PET-SQL⁽⁵²⁾先剔除执行失败的无效SQL语句，再采用基于偏差感知的投票（如基于难度加权、MCS-SQL⁽⁵⁵⁾中的效率优先）确定最终结果；概率验证是该类方法的重要特征：MRC-EXEC⁽⁷⁸⁾通过对比执行结果与预期结果，最小化贝叶斯风险；LEVER⁽⁷⁹⁾训练验证器，从执行轨迹中预测SQL语句的正确概率；基于检索增强的框架⁽⁶⁶⁾等混合方法，通过语义差距分析，将执行反馈用于SQL语句的迭代修正，实现生成与选择的结合。

4.2 微调

**有监督微调（SFT）**是微调范式中训练大语言模型的主流方法⁽²⁷⁾⁽¹¹³⁾。对于LLaMA⁽¹¹⁷⁾、通义千问⁽¹¹⁸⁾系列等开源大语言模型，使其适配特定领域的最直接方式，是在收集的领域专属数据上进行有监督微调。在精心设计的训练流水线中⁽¹²⁸⁾⁽¹²⁹⁾（包括基于大语言模型的文本转SQL训练），有监督微调阶段通常是初始步骤。将公式(4)和(5)中定义的提示记为(P)，目标标准SQL语句记为(Y=[y_{1}, y_{2}, ..., y_{T}])，则大语言模型(\pi)基于提示(P)生成(Y)的概率(Pr)可形式化表示为：

与上下文学习范式中的大语言模型不同，该范式下模型(\pi)的参数会被调优。有监督微调过程通过在训练数据集(D)上最小化交叉熵损失实现模型训练：

作为基于大语言模型的文本转SQL技术的基础微调方法，有监督微调被广泛应用于各类开源大语言模型的文本转SQL研究⁽⁸⁾⁽²⁴⁾⁽¹²⁰⁾。在学术界，微调范式相比作为主流方法的上下文学习范式，在基于大语言模型的文本转SQL技术中更具基础性，这主要是因为开源大语言模型对复杂数据库内容的理解能力远不如闭源模型。对于微调范式下现有精心设计的方法，我们根据其训练机制分为不同类别（见表4）。

4.2.1 架构增强

目前广泛使用的生成式预训练Transformer（GPT）框架⁽¹⁰⁵⁾采用仅解码器的Transformer架构和传统的自回归解码方式生成文本。随着GPT框架的发展，基于大语言模型的文本转SQL技术的架构增强主要体现为对标准Transformer骨干网络的改进，通过融入定制化架构，高效处理SQL语句的结构和语法复杂性。在传统的文本转SQL研究中，这类定制化架构已有效提升了基于预训练语言模型的系统性能，相关技术包括面向模式感知的编码⁽²⁰⁾、优化的注意力机制⁽¹³⁰⁾、目标解码⁽¹³¹⁾等，且通常依托图结构实现。近期研究发现，大语言模型生成SQL语句的速度明显慢于传统的基于预训练语言模型的方法⁽¹⁹⁾⁽²⁶⁾，这给构建高效的本地数据库自然语言接口带来了挑战。

为解决该问题，CLLMs⁽⁸²⁾通过专属解码设计提升SQL生成的速度效率，降低高延迟问题，成为应对该挑战的有效方案。

4.2.2 预训练优化

预训练是完整训练过程的基础阶段，旨在通过对海量数据的自回归训练，让模型获得文本生成能力⁽¹³²⁾。CodeLLaMA⁽⁸⁷⁾、StarCoder⁽¹³³⁾等面向代码生成的大语言模型基于代码数据预训练，支持多种编程语言，能根据用户指令生成代码⁽¹²⁴⁾⁽¹³⁴⁾。针对SQL专属的预训练优化，核心挑战在于SQL/数据库相关内容在预训练语料中的占比极低，导致开源大语言模型在预训练阶段无法充分掌握从自然语言问题到SQL语句的转换能力。

基于预训练语言模型的方法已在预训练范式中做出初步尝试，如STAR⁽¹³⁵⁾和多任务方法⁽¹³⁶⁾，通过基于SQL引导的预训练和多任务预训练策略提升SQL生成性能。对于近期的基于大语言模型的文本转SQL技术，CodeS模型⁽²⁴⁾的预训练阶段包含三阶段增量预训练：以面向代码的大语言模型⁽¹³³⁾为基础，在融合了SQL相关数据、自然语言到代码数据、自然语言相关数据的混合训练语料上进行增量预训练，显著提升了模型对文本转SQL任务的理解能力和性能。

4.2.3 数据增强

在微调过程中，训练标签的质量是影响模型性能最直接的因素⁽¹³⁷⁾，基于低质量或缺失标签的训练无异于"巧妇难为无米之炊"。研究表明，使用高质量或增强后的数据集进行微调，其效果始终优于基于低质量或原始数据的精心设计方法⁽²⁷⁾⁽⁹³⁾。面向文本转SQL的基于数据增强的微调技术，通过聚焦于提升有监督微调过程中的数据质量和效率，取得了显著进展。

DAIL-SQL⁽⁸⁾作为上下文学习框架，采用采样策略优化少样本实例，将这些采样实例融入有监督微调过程，能提升开源大语言模型的性能；Symbol-LLM⁽⁸³⁾提出了用于基于数据增强的指令微调的注入和融合阶段；CodeS⁽²⁴⁾借助ChatGPT实现双向生成，完成训练数据增强；StructLM⁽⁸⁴⁾在多个结构化知识任务上训练，提升模型的综合能力；Dubo-SQL⁽⁷¹⁾为微调设计了简洁的提示模板，在降低成本的同时取得了创纪录的性能；Distillery⁽⁵⁸⁾采用基于失败感知的迭代方法，根据误差分析选择新的训练样本；XiYan-SQL⁽⁸⁵⁾采用基础语法有监督微调和生成增强有监督微调，结合混合增强训练数据优化SQL生成器；SHARE⁽⁸⁶⁾设计了基于规则的错误扰动方法，基于分解的轨迹增强模式链接和最终SQL推理的训练数据。

4.2.4 多任务微调

如4.1.2节的上下文学习范式所述，将复杂任务拆分为多个子任务或使用多个模型协同处理，是解决复杂问题的直接方法。上下文学习方法中的闭源模型参数量庞大，远超微调范式中使用的开源模型，且借助少样本学习等机制⁽²⁸⁾⁽⁴⁸⁾，能高效完成分配的子任务。为让开源模型实现同等效果，需要为其合理分配子任务（如生成外部知识、模式链接、基于执行结果的优化）并进行针对性训练，这包括构建专属的微调数据集，最终辅助生成目标SQL语句。

SQL-LLaMA⁽⁴⁸⁾是基于多智能体协同的微调大语言模型框架；DTS-SQL⁽⁸⁸⁾提出了两阶段多任务文本转SQL微调框架，在最终SQL生成前融入模式链接预生成任务；类似地，KaSLA⁽²⁹⁾采用两阶段框架，将背包优化作为模式链接任务的微调策略；SHARE⁽⁸⁶⁾采用三个串行模型完成SQL语句修正；MSc-SQL⁽⁸⁹⁾训练独立模型分别处理模式链接、SQL生成和预测SQL语句的校验；ROUTE⁽⁹⁰⁾框架在噪声过滤、数据合成、续写任务上进行有监督微调，通过协同提示验证了多任务微调流水线的有效性。

五、总结

本节对比了传统方法与基于大语言模型的方法在解决文本转SQL挑战（模糊性解决、模式链接、复杂SQL生成、跨领域适配）方面的表现，同时分析了基于大语言模型的不同方法之间的差异，并指出其优势与权衡关系。

5.1 基于大语言模型的方法与传统方法的对比

语言的复杂性与模糊性

GRAPPA⁽²³⁾等传统基于规则的系统通过语法模板分解问题，但无法解决表述模糊的问题；RYENSQL⁽¹⁷⁾等神经网络模型提升了词汇匹配能力，但缺乏上下文推理能力。相比之下，DAIL-SQL⁽⁸⁾等基于大语言模型的方法借助思维链提示，分步推理语义依赖关系；C3-SQL⁽²⁸⁾通过将SQL草稿与改写后的问题进行迭代验证，提升准确性。传统方法的模糊性解决方式轻量化，但对训练数据的依赖使其难以处理未见过的表述形式；基于大语言模型的方法依托大规模预训练解决了这一问题，但计算成本随上下文长度呈二次方增长，难以在低资源边缘设备上部署。一种有前景的解决方案是采用两阶段流水线架构：先通过传统方法进行初始模糊性检测，仅在需要解决标记的模糊性问题时调用大语言模型，该混合架构能平衡效率与鲁棒性。
数据库模式的理解与表示

早期系统通过字符串相似度或模式无关嵌入对模式元素进行排序，从而截断复杂关系。基于 LLM 的方法通过上下文学习和结构化注意力增强模式链接。例如，DIN-SQL [7] 将模式序列化为带有外键提示的自然语言提示，而 KaSLA [29] 则模仿人类对模式元素的优先级排序，减少模式链接中常见的遗漏和冗余问题。虽然基于规则的方法具有可解释性，但其僵化性限制了适应性。基于 LLM 的方法在语义链接方面表现出色，但缺乏透明度：其注意力权重可能会因虚假相关性而优先考虑错误的列。为缓解这一问题，未来系统可以将符号规则与 LLM 推理相结合：首先应用基于规则的过滤器排除不相关的列，然后使用 LLM 对剩余候选列进行排序。将 LLM 与特定领域规则相结合的混合方法可以在性能和资源消耗之间提供平衡的权衡。
稀有且复杂的SQL操作

处理嵌套子查询、窗口函数等操作需要大量的模板工程工作。例如，早期基于规则的方法⁽⁹⁾需人工定义40余种SQL语法规则以映射问题模式，但这些规则无法泛化到未见过的表述形式。PICARD⁽¹³⁸⁾等神经语义解析器通过基于转换的增量解析约束解码过程，在每一步拒绝无效令牌，确保生成的SQL语句语法有效。基于大语言模型的方法则结合代码中心预训练的参数知识和少样本演示，生成稀有SQL语句。例如，DAIL-SQL⁽⁸⁾在提示中注入窗口函数示例，使模型能泛化到未见过的表述形式。PICARD⁽¹³⁸⁾等传统方法通过语法约束解码器保证语法有效性，但无法对稀有和复杂SQL操作进行创新；基于大语言模型的方法能提供新颖解决方案，但可能生成无效SQL语句。当前最先进的智能体推理⁽⁴²⁾⁽⁶¹⁾通过多智能体协作减少无效输出，但仍存在误差累积问题。一种协同方案是将大语言模型的创造性与传统验证相结合：首先通过大语言模型生成候选查询语句，然后应用类似PICARD的语法规则，在束搜索过程中拒绝无效令牌。这一模式与程序合成中的"生成-验证"范式一致------大语言模型提出解决方案，符号检查器执行约束验证。
跨领域泛化能力

基于规则的系统需要为每个领域手动调整模板，而(S^2)SQL⁽¹³⁹⁾等基于预训练语言模型的方法依赖领域专属微调。CodeS⁽²⁴⁾等基于大语言模型的方法通过代码中心预训练，适配生物医学术语等特定领域。传统领域适配方法需要适量微调数据以对齐潜在空间，但能精确控制领域专属映射；基于大语言模型的方法支持少样本适配，但存在过度泛化风险。一种可行方案是将大语言模型用作元优化器：利用领域专属规则训练大语言模型的小型适配器网络，使大语言模型能动态调整其链接策略。该方案结合了基于规则适配的高效性和大语言模型学习跨领域类比的能力。

5.2 基于大语言模型的方法内部对比

上下文学习范式内部对比

上下文学习（ICL）范式的各类方法具有互补的优势和局限性。分解策略（(C_1)，4.1.2节）通过任务模块化处理复杂查询，但多阶段流水线会引入级联误差风险；提示优化（(C_2)，4.1.3节）通过语义对齐提升输入质量，但受限于模型固有的推理能力；推理增强（(C_3)，4.1.4节）通过结构化思维提高逻辑连贯性，但显著增加计算开销；执行优化（(C_4)，4.1.5节）通过反馈循环确保运行时有效性，但严重依赖数据库的可访问性。SuperSQL⁽⁵⁷⁾、Spider-Agent⁽⁴²⁾、ReFoRCE⁽⁶¹⁾等近期方法呈现出混合集成的趋势------结合分解策略的结构严谨性与提示优化的高效性，同时叠加推理增强和执行一致性机制，通过精心设计的智能体推理实现。这一融合趋势表明，未来的上下文学习方法将越来越多地将跨类别技术整合为统一框架，通过系统协作平衡准确性、效率和鲁棒性。
微调范式内部对比

微调（FT）方法凸显了专业化与泛化能力之间的权衡。CLLMs⁽⁸²⁾等架构增强方法降低了延迟，CodeS⁽²⁴⁾等预训练优化方法提供了稳健的SQL基础能力，但两种方法均受限于对计算资源和硬件设备的高要求；DAIL-SQL⁽⁸⁾、XiYan-SQL⁽⁸⁵⁾等数据增强方法提升了数据效率，但存在过度拟合合成模式的风险；ROUTE⁽⁹⁰⁾等多任务微调方法增强了多步推理能力，但增加了训练收敛的复杂性。当前方法多聚焦于孤立优化，领域内缺乏整合架构技术贡献的整体框架。未来的微调方法需要设计有序流水线，依次优化预训练目标、数据多样性策略和任务专属适配。这种协同设计对于开源模型实现闭源大语言模型在文本转SQL领域的多维度能力至关重要。
上下文学习与微调范式对比

两种范式呈现出非对称的价值主张：上下文学习方法利用GPT-4⁽¹⁰⁷⁾等闭源大语言模型实现快速适配，但在可控性和领域定制方面存在约束；微调方法通过微调为CodeLLaMA⁽⁸⁷⁾等开源模型赋予目标SQL能力，但需要大量工程工作进行数据整理和训练优化。值得注意的是，微调方法能增强模型的基础能力：CodeS⁽²⁴⁾的增量预训练提升了问题和模式理解能力，SQL-LLaMA⁽⁴⁸⁾的多智能体微调支持复杂的组合推理。尽管如此，上下文学习方法基于提示的灵活性仍是其独特优势------无需重新训练即可适配新兴数据库环境。未来的研究格局可能呈现协同关系：微调方法构建具备通用SQL基础能力的专用模型，上下文学习方法为下游应用提供轻量化适配。这一分工与检索增强生成的趋势一致：微调构建核心能力，上下文学习处理动态上下文集成。

六、未来展望

尽管基于大语言模型的文本转SQL研究已取得显著进展，但仍存在诸多需要解决的挑战。本节将探讨未来工作中有望克服的剩余挑战。

6.1 实际应用中的鲁棒性

基于大语言模型实现的文本转SQL技术需在实际应用的复杂场景中具备泛化能力和鲁棒性。尽管近期研究在鲁棒性专属数据集⁽³⁴⁾⁽³⁸⁾上取得了实质性进展，但性能仍未达到实际应用要求⁽¹⁾，未来研究需克服以下挑战：

用户层面：用户并非总能提出明确的问题，其问题可能不包含精确的数据库值，且与标准数据集存在差异，可能包含同义词、拼写错误和模糊表达⁽³⁷⁾。例如，微调范式中的模型基于表述明确、语义具体的问题训练，由于未学习现实问题与对应数据库的映射关系，应用于实际场景时会存在知识缺口⁽¹⁾。相关评估显示⁽⁶⁾⁽⁴⁷⁾，在包含同义词和不完整指令的数据集上，ChatGPT生成的SQL语句执行错误率约为40%，比原始评估高10%⁽⁴⁷⁾；在实际企业任务的评估中⁽⁴²⁾，当前最先进模型的任务解决率仅约21.3%，远低于其在早期基准数据集⁽¹⁾⁽¹¹⁾上的表现。
数据层面：基于本地文本转SQL数据集的微调可能包含非标准化样本和标签。例如，表名或列名并非总能准确反映其内容，这会导致训练数据构建的不一致性，可能造成数据库模式与用户问题之间的语义缺口。为应对这一挑战，需使大语言模型与意图偏差对齐，并设计面向噪声场景的训练策略。同时，实际应用中的数据规模通常小于研究导向的基准数据集，通过人工标注扩展大量数据会产生高昂的人力成本，因此设计数据增强方法以获取更多问题-SQL对，对大语言模型在数据稀缺场景的应用至关重要。此外，微调后的开源大语言模型对本地小规模数据集的适配研究也具有潜在价值。
场景扩展：未来研究应探索多语言⁽³⁹⁾⁽⁴³⁾和多模态场景⁽¹⁴⁰⁾的扩展，惠及更多语言群体并构建更通用的数据库接口。

6.2 计算效率

计算效率由推理速度和计算资源成本决定，是应用和研究工作中需重点考虑的因素⁽⁶⁸⁾⁽⁸²⁾。随着最新文本转SQL基准数据集⁽¹⁾⁽¹³⁾⁽⁴²⁾中数据库复杂度的提升，数据库包含的信息（表和列数量）不断增加，数据库模式的令牌长度也相应增长，带来了一系列挑战：

令牌长度与成本问题：处理超复杂数据库时，将对应模式作为输入可能导致闭源大语言模型的调用成本显著增加，甚至超过模型的最大令牌长度限制，尤其是在使用上下文长度较短的开源模型时。
冗余问题：大多数研究使用完整模式作为模型输入，引入了大量冗余⁽⁴⁸⁾。一种潜在解决方案是从用户端直接为大语言模型提供与问题精准相关的过滤后模式，以降低成本和冗余⁽²⁸⁾，但设计准确的模式过滤方法仍是未来的研究方向。
上下文学习的效率挑战：尽管上下文学习范式取得了良好的准确性，但作为计算效率的关注点，具有多阶段框架或扩展上下文的精心设计方法，在通过增加API调用提升性能的同时，也导致成本大幅上升⁽⁷⁾。近期依赖迭代多步操作的智能体推理方法，通常会使API调用次数成倍增加。虽然这类方法支持复杂任务处理并提升了鲁棒性，但优化动作规划以减少不同数据库场景下的冗余交互，仍是未来的重要研究方向。相关研究⁽⁶⁸⁾表明，需谨慎权衡性能与计算效率，设计API成本更低且性能相当（甚至更优）的上下文学习方法，仍是当前的研究热点。
推理速度优化：与基于预训练语言模型的方法相比，基于大语言模型的方法推理速度明显更慢⁽¹⁹⁾⁽²⁶⁾。对于上下文学习范式，通过缩短输入长度和减少实现阶段数量加速推理是直观有效的方向；对于本地大语言模型，可从CLLMs⁽⁸²⁾的研究出发，在未来探索更多通过模型架构增强实现提速的策略。

6.3 数据隐私与可解释性

作为大语言模型研究的一个分支，基于大语言模型的文本转SQL技术也面临大语言模型研究中普遍存在的挑战⁽¹⁴¹⁾⁽¹⁴²⁾⁽¹⁴³⁾。有望从文本转SQL视角对这些挑战进行改进，进而为大语言模型研究带来广泛收益：

数据隐私：如4.1节所述，上下文学习范式在近期研究中在数量和性能上均占主导地位，且大多数研究使用闭源模型实现⁽⁷⁾⁽⁸⁾。一个直接的挑战是数据隐私问题------调用闭源API处理包含机密信息的本地数据库，可能存在数据泄露风险。采用本地微调范式可部分解决该问题，但当前基础微调的性能并不理想⁽⁸⁾，且先进的微调框架可能依赖闭源大语言模型进行数据增强⁽²⁴⁾。基于当前现状，更多面向文本转SQL的本地微调范式专属框架值得广泛关注。
可解释性：深度学习的发展始终面临可解释性挑战⁽¹⁴³⁾⁽¹⁴⁴⁾，尽管已有大量研究致力于解决这一问题⁽¹⁴⁵⁾⁽¹⁴⁶⁾，但在文本转SQL研究中，无论是上下文学习还是微调范式，基于大语言模型的实现方案的可解释性仍未得到充分探讨。包含分解阶段的方法从分步生成视角解释了文本转SQL的实现过程⁽⁷⁾⁽⁴⁷⁾，未来可在此基础上，结合可解释性领域的先进研究⁽¹⁴⁷⁾⁽¹⁴⁸⁾，从数据库知识角度增强文本转SQL模型架构的可解释性。

6.4 扩展方向

作为大语言模型和自然语言理解研究的一个子领域，这些领域的诸多研究已被应用于文本转SQL任务，推动了其发展⁽¹²⁶⁾⁽¹⁴⁹⁾。同时，文本转SQL研究也可扩展到这些领域的更广泛研究中：

代码生成扩展：SQL生成是代码生成的一个分支，代码生成领域的精心设计方法在文本转SQL任务中也取得了良好性能⁽⁷⁹⁾⁽⁸⁰⁾，并能在多种编程语言间实现泛化。部分面向文本转SQL的定制框架有望扩展到自然语言到代码（NL-to-code）研究中，例如，融合执行输出的框架在SQL生成中表现出色⁽⁷⁾，将文本转SQL中基于执行感知的方法与其他先进模块⁽²⁸⁾⁽⁷⁰⁾结合，应用于代码生成领域，是值得探讨的方向。
问答系统扩展：如前文所述，文本转SQL技术可通过提供事实信息增强基于大语言模型的问答（QA）系统性能。数据库可将关系型知识存储为结构化信息，基于结构的问答系统（如基于知识的问答系统KBQA⁽¹⁵⁰⁾⁽¹⁵¹⁾）有望从文本转SQL技术中获益。通过数据库结构构建事实知识，再融合文本转SQL系统实现信息检索，可为问答系统提供更准确的事实知识支持⁽¹⁵²⁾。未来有望看到更多文本转SQL研究的扩展应用。