【nl2sql综述】2025最新综述解读

论文地址：https://arxiv.org/pdf/2408.05109

解读：迈向数据民主化------大型语言模型时代下的Text-to-SQL技术综述

近期，一篇名为《A Survey of Text-to-SQL in the Era of LLMs》的综述论文系统性地梳理了自然语言到SQL查询（Text-to-SQL）技术的发展脉络、核心挑战与未来方向。该技术旨在将用户的自然语言问题直接翻译成可在关系型数据库上执行的SQL查询，从而极大地降低了数据访问的技术门槛。随着大型语言模型（LLMs）的崛起，Text-to-SQL的性能得到了显著提升，使其成为学术界和工业界关注的焦点。

这篇综述提出了一个覆盖Text-to-SQL任务全生命周期的分析框架，从模型、数据、评估和错误分析四个维度展开。

一、 Text-to-SQL的演进之路：从规则到智能

论文通过一张"模型演进流图"清晰地展示了Text-to-SQL技术的发展历程，这个过程与自然语言处理（NLP）方法的进步紧密相连。

1. 规则驱动阶段（~1990s）： 早期的Text-to-SQL系统依赖于预定义的规则和语义解析器，使用N-gram等统计语言模型进行关键词匹配和转换。这类方法虽然直接，但泛化能力、可扩展性和适应性都非常有限，主要处理单表查询。

2. 神经网络阶段（~2013-2018）： 为了克服规则方法的局限性，研究者引入了神经网络，特别是基于LSTM的序列到序列（sequence-to-sequence）架构和图神经网络。这些模型提升了对同义词和用户意图的理解能力，使研究从单表查询进入了更复杂的多表场景。然而，模型的性能依然受限于模型规模和训练数据的数量。

3. 预训练语言模型（PLM）阶段（2018~）： 以BERT和 T5为代表的预训练语言模型（PLMs）的出现，为Text-to-SQL领域带来了重大突破。这些在海量文本上预训练的模型极大地增强了对自然语言的理解能力，在如Spider等基准测试上取得了优异的成绩。尽管如此，它们在处理极其复杂的查询和数据库模式时仍会遇到瓶颈。

4. 大型语言模型（LLM）阶段（2020~）： 当前，我们正处于由LLM主导的新阶段。以GPT-4为代表的LLMs展现出了超越传统PLMs的"涌现能力" (emergent capabilities)。这些能力使得LLMs可以通过提示（Prompting）直接执行Text-to-SQL任务，而无需进行专门的微调。研究焦点也随之转向数据库特有的挑战，例如处理海量数据和特定领域的解决方案，这催生了像BIRD这样的新基准测试。

二、 核心挑战：横亘在自然语言与结构化查询之间的鸿沟

尽管技术取得了长足进步，但Text-to-SQL任务依然面临着三大固有挑战和一系列技术难题。

固有挑战：

• 自然语言的不确定性： 用户提问中普遍存在词汇歧义（一个词有多种含义）、句法歧义（句子结构可被多种方式解析）以及信息不充分（under-specification）的问题。例如，论文中提到"2023年的劳动节"在美国指9月4日，而在中国则指5月1日。
• 数据库的复杂性： 现代数据库模式可能包含数百张表和复杂的相互关系。此外，数据库中可能存在模糊的属性名、不一致或缺失的"脏数据"，这都给准确生成SQL带来了困难。
• 从"自由"到"严谨"的转换鸿沟： 将形式自由、灵活多变的自然语言，精确翻译成语法严格、逻辑严谨的SQL查询，本身就是一个巨大的挑战。同一个自然语言问题，可能对应多种逻辑等价的SQL写法，这增加了任务的复杂性。

技术挑战：

• 成本效益与效率： 部署基于LLM的解决方案需要巨大的硬件资源或API调用成本，如何在模型性能和成本之间取得平衡是一个关键问题。
• 数据稀缺与噪声： 高质量的Text-to-SQL训练数据难以获取，公开数据集规模有限且可能包含标注错误。
• 可信度与可靠性： Text-to-SQL系统必须能够持续稳定地产生正确结果，并提供一定的透明度，以便用户理解和验证生成的SQL查询。

三、 LLM时代下的两大主流技术路径

在LLM时代，研究者主要通过两种方式来利用其强大能力解决Text-to-SQL任务：

1. 上下文学习（In-Context Learning）： 这种方法将LLM视为一个"开箱即用"的工具，通过精心设计提示（Prompt）来引导模型生成正确的SQL，而不改变模型本身的参数。例如，DAIL-SQL就是通过有效的提示工程技术在GPT-4上取得了强大的性能。

2. 预训练与微调（Pre-train and Fine-tune）： 对于拥有充足数据和计算资源的场景，可以通过在特定领域或任务相关的大规模语料上对LLM进行预训练或微调，从而打造出专门用于Text-to-SQL的模型。一个典型的例子是CodeS，它通过在一个大型Text-to-SQL相关语料库上预训练StarCoder模型，在BIRD等基准测试中表现出色。

四、 现代Text-to-SQL系统的模块化架构

现代基于PLM和LLM的解决方案通常将复杂的Text-to-SQL任务分解为三个核心阶段：预处理（Pre-processing）、翻译（Translation）和后处理（Post-processing）。这种模块化设计不仅反映了任务日益增长的复杂性，也顺应了多代理（multi-agent）或多模块协同工作的研究趋势。

• 预处理（可选）： 该阶段旨在优化输入信息，为核心翻译模块提供最相关、最精简的上下文。它包括模式链接、数据库内容检索和额外信息获取等子模块。
• 翻译： 这是系统的核心，负责将经过处理的自然语言查询转换为SQL代码。这一阶段涉及编码策略、解码策略以及针对LLM的特定提示策略等关键技术。
• 后处理（可选）： 此阶段用于检验和优化初步生成的SQL查询，以提升其准确性和可执行性。常见方法包括语法修正、一致性投票和基于执行结果的重排序等。

基于这种模块化思想，研究者进一步提出了多代理协作框架 。例如，MAC-SQL 设计了一个包含三个独立代理的架构，分别负责模式链接、查询生成和执行引导优化；而CHASE-SQL 和 Alpha-SQL 则采用"分而治之"和动态规划的策略，让不同的模块或代理协同解决问题。

五、 深度剖析：预处理策略

预处理是提升Text-to-SQL性能的关键第一步，尤其是在LLM存在输入长度限制的背景下，其重要性愈发凸显。

1. 模式链接（Schema Linking）：

   此模块旨在从庞大的数据库模式中识别出与用户问题最相关的表和列。其技术演进分为三个阶段：

   • 基于字符串匹配： 早期方法如 IRNet 通过精确或模糊的字符串匹配技术来建立链接，但在处理同义词和拼写变体时能力有限。
   • 基于神经网络： RESDSQL 和 FinSQL 等模型利用深度神经网络来理解查询和数据库模式之间的复杂语义关系，显著提升了链接的准确性。
   • 基于上下文学习（In-Context Learning）： LLM的强大推理能力被直接用于模式链接。C3-SQL 和 CHESS 等工作通过设计零样本（zero-shot）提示，引导GPT-3.5或GPT-4直接识别出相关的数据库组件。

2. 数据库内容检索（Database Content Retrieval）：

   该模块专注于高效地从数据库中提取与查询条件（如WHERE子句）相关的单元格值。主要方法包括：

   • 基于字符串匹配： BRIDGE 等方法通过启发式规则和序列匹配技术从自然语言中提取单元格值。
   • 基于神经网络： TABERT 和 RAT-SQL 等模型通过注意力机制或图结构来捕捉查询、列名和单元格值之间的语义关系。
   • 基于索引策略： 为了处理大型数据库，CHESS 和 CodeS 等现代方法采用索引技术来加速检索。例如，CodeS 使用BM25算法建立索引进行粗粒度搜索，再通过最长公共子串算法进行精细匹配。

3. 额外信息获取（Additional Information Acquisition）：

   通过引入领域知识、示例或其他外部信息，可以显著增强模型对查询意图的理解。

   • 基于样本的方法： 在LLM的上下文中，研究者常将额外的知识或"少样本"（few-shot）示例直接整合到提示中。例如，DIN-SQL 通过在提示中包含多个阶段的示例来处理复杂的查询。
   • 基于检索的方法： 为避免提示过长导致成本和效率问题，PET-SQL 等方法会从一个知识库中检索与当前问题最相似的k个示例，并将其用于构建提示。REGROUP 则能从外部知识库中检索公式化知识并将其转换为自然语言描述。

六、 解构核心：翻译方法

翻译是整个系统的"心脏"，它将自然语言输入转化为结构化的SQL查询。这一过程主要涉及编码和解码两个环节。

1. 编码策略（Encoding Strategy）：

   编码器负责将自然语言和数据库模式转换成模型可以处理的内部表示。

   • 顺序编码（Sequential Encoding）： 这是最直接的策略，将自然语言查询和线性化后的数据库模式拼接成一个单一的token序列进行处理。T5 和 BRIDGE 等模型采用了此方法。
   • 基于图的编码（Graph-based Encoding）： 为了更好地捕捉数据库的内在关系结构（如外键关系），RAT-SQL 和 Graphix-T5 等模型将数据库模式表示为图结构，并使用图神经网络进行编码。
   • 分离编码（Separate Encoding）： 该策略独立地对输入的不同部分（如查询和模式）进行编码，之后再进行交互。例如，SC-Prompt 将编码过程分为"结构"和"内容"两个独立阶段。

2. 解码策略（Decoding Strategy）：

   解码器则负责将编码器生成的内部表示转换成最终的SQL查询字符串。

   • 基于贪心搜索的解码（Greedy Search-based Decoding）： 这是一种简单高效的策略，在生成SQL的每一步都选择概率最高的token。许多基于GPT的模型（如DTS-SQL）默认采用此方法。其缺点是容易陷入局部最优，可能导致全局结果不佳。
   • 基于束搜索的解码（Beam Search-based Decoding）： 相比贪心搜索，束搜索在每一步都会保留k个最可能的候选序列，从而在更广阔的搜索空间中寻找最优解，通常能生成更高质量的结果。

除了贪心搜索和束搜索，为了保证生成SQL的语法正确性，研究者还提出了更精密的解码策略。

• 约束感知的增量解码 (Constraint-aware Incremental Decoding): 该策略在解码的每一步都强制应用SQL语法规则，从根本上杜绝语法错误的产生。代表性工作 PICARD 在解码循环中集成了SQL语法检查器，确保生成的每个token都符合语法规范。BRIDGE 则更进一步，引入了模式一致性引导，确保生成的查询与数据库模式保持一致。

4. 面向LLM的任务特定提示策略

   在LLM时代，提示工程（Prompt Engineering）成为引导模型行为的关键技术。

   • 思维链提示 (Chain-of-Thought, CoT): CoT通过向LLM展示解决问题的推理过程，显著提升了生成结果的准确性和可解释性。例如，CHESS 利用CoT来指导其从模式选择到SQL生成与修正的整个流程。CoT还可以与上下文学习、多代理系统等技术结合，形成更强大的Text-to-SQL框架。
   • 分解策略 (Decomposition Strategy): 该策略将复杂的Text-to-SQL任务分解为一系列更简单的子任务。例如，TKK 将SQL解析分解为分别处理SELECT、FROM、WHERE子句的子任务；MAC-SQL 则引入了一个"分解器"代理，专门负责将用户问题拆分为多个易于处理的子问题。

5. 中间表示 (Intermediate Representation, IR)

   为了弥合自然语言的"自由形式"与SQL的"严格约束"之间的鸿沟，研究者引入了中间表示（IR）作为桥梁。

   • 类SQL的语法语言 (SQL-like Syntax Language): 这是一种简化的、语法更宽松的SQL方言。SyntaxSQLNet 和 SemQL 通过移除SQL中的部分子句来简化语法。其中，NatSQL 是目前广泛使用的一种IR，它去除了不常见的SQL操作符和关键字，简化了模式链接过程，并取得了优异的性能。
   • 类SQL的草图结构 (SQL-like Sketch Structure): 该方法利用SQL的结构特性，将不同的自然语言查询映射到一个预定义的"草图"或"模板"空间中，从而降低解析的复杂性。CatSQL 构建了带有"插槽"的通用模板，模型的核心任务就是填充这些插槽。RESDSQL 则采用"骨架感知"的解码框架，先生成SQL的骨架，再填充具体内容。

七、 精益求精：后处理策略

在生成初步的SQL后，后处理步骤可以进一步修正和优化结果。

• SQL修正 (SQL Correction): 针对模型可能产生的语法错误，DIN-SQL 引入了零样本（zero-shot）的自修正模块，直接让模型识别并纠正错误的SQL。ZeroNL2SQL 则采用多级匹配方法来修正错误的列名或值。
• 输出一致性 (Output Consistency): 为提升结果的可靠性，DAIL-SQL 采用了自洽性（self-consistency）策略，即多次生成结果并选取最一致的答案。PET-SQL 更进一步提出了跨一致性（cross-consistency）策略，让多个不同的LLM共同生成SQL并根据执行结果进行投票。
• 执行引导策略 (Execution-Guided Strategies): 将生成的SQL在真实数据库上执行，并利用其执行结果（如报错信息或空值）作为反馈来指导模型的修正。CHESS 和 CodeS 都采用了这种策略来迭代优化或筛选SQL查询。
• N-best重排序 (N-best Rerankers): 该策略首先让模型生成Top-N个候选SQL，然后利用一个更强大或拥有额外知识的"重排序器"对这些候选者进行重新排序，以选出最优解。

八、 发展的基石：Text-to-SQL基准

Text-to-SQL领域的发展离不开各类基准数据集的推动。论文对这些数据集进行了系统性的梳理和分析。

• 数据集的演变：
  • 单领域: 早期的ATIS（航班信息）、GeoQuery（地理知识）等。
  • 跨领域: WikiSQL是首个大型跨领域数据集，而Spider则引入了更复杂的多表关系数据库。近期的BIRD进一步增加了对复杂SQL函数和操作的考察。
  • 多轮对话: SParC 和 CoSQL 支持交互式对话场景，考验模型的上下文理解能力。
  • 鲁棒性测试: Spider-Syn 通过引入同义词来模拟用户对模式的不熟悉，Dr.Spider 则对数据库、问题和SQL本身施加扰动来全面评估模型的鲁棒性。
  • 效率测试: BIRD 首次引入了对SQL执行效率的评估。
  • 知识增强: KaggleDBQA 和 Spider-DK 在数据集中加入了额外的领域知识文档，考验模型的知识利用能力。
  • 歧义问题: AmbiQT 是首个专注于评估模型处理歧义问题能力的数据集。

尽管数据集日益丰富，但论文指出，现有基准在SQL查询的复杂性（如嵌套查询和复杂计算）方面与真实世界场景仍有差距。

九、 成功的标尺：评估指标与工具

如何科学地评估模型性能至关重要。论文介绍了以下核心评估指标：

• 执行准确率 (Execution Accuracy, EX): 比较预测SQL与标准答案SQL的执行结果是否一致。
• 精确匹配准确率 (Exact-Match Accuracy, EM): 基于组件匹配，要求预测SQL的所有结构化组件都与标准答案完全一致。
• 组件匹配准确率 (Component-Match Accuracy, CM): 分别比较SELECT, WHERE等不同SQL组件的匹配度。
• 有效效率得分 (Valid Efficiency Score, VES): 由BIRD提出，同时衡量SQL查询的准确性和执行效率。
• 查询方差测试 (Query Variance Testing, QVT): 衡量模型在处理同一SQL对应的不同自然语言问法时的鲁棒性。

此外，为了进行更全面、低成本的评估，社区还开发了如NL2SQL360等评估工具包，以弥补标准基准评估的不足。

十、 知错能改：Text-to-SQL的错误分析

为了持续改进模型性能，理解并归类其产生的错误至关重要。

• 现有的错误分类法： 此前的研究已提出多种错误分类体系。例如，Ning等人从"句法"（错误发生在哪个SQL关键词）和"语义"（对自然语言的何种误解）两个维度进行划分。SQL-PaLM则将错误分为模式链接、数据库内容、知识证据、推理和语法五类。而NL2SQL-BUGs则专注于对语义错误进行更细致的分类。

• 构建优秀分类法的原则： 现有分类法往往与特定数据集绑定，缺乏普适性。为此，论文提出了构建一个标准化错误分类法的四项基本原则：

  1. 全面性 (Comprehensiveness): 应覆盖所有可能的错误类型。
  2. 互斥性 (Mutual Exclusivity): 每种错误类型应清晰界定，避免归类模糊。
  3. 可扩展性 (Extensibility): 能适应技术发展，纳入新出现的错误类型。
  4. 实用性 (Practicality): 便于用户在真实场景中诊断和解决问题。

• 论文提出的两级错误分类法： 基于上述原则，作者提出了一个两级分类体系：

  • 第一级：错误定位 (Error Localization): 识别错误发生的具体SQL组件，如SELECT或WHERE子句，以便进行针对性修复。
  • 第二级：错误原因 (Cause of Error): 探究错误的根本原因。例如，WHERE子句中的值错误可能反映了模型在数据库内容检索或理解上的缺陷。

该分类法在对DIN-SQL模型的错误进行分析时表现出了很高的实用性和有效性。

十一、 从理论到实践：开发者的实用指南

本部分为开发者在不同场景下构建和优化Text-to-SQL解决方案提供了清晰的路线图和决策流程。

1. 数据驱动的LLM优化路线图：

   论文根据数据隐私 和数据量这两个关键因素，为选择和优化LLM提供了指导。

   • 考虑数据隐私： 对于隐私敏感数据，推荐使用可本地部署的开源LLM ，以确保数据安全。对于非隐私数据，则可以使用闭源LLM的API服务。
   • 考虑数据量：
     • 对于开源LLM，若拥有海量相关数据，可进行预训练 (Pre-train) ；若有数千级别的标注数据，可进行微调 (Fine-tune)。
     • 在数据量较少的情况下，**少样本学习 (Few-shot)**是推荐策略。
     • 在完全没有标注数据时，则只能依赖零样本学习 (Zero-shot)。

2. Text-to-SQL模块选择决策流：

   针对不同的应用场景，论文推荐了相应的技术模块，并分析了其优缺点。

   • 场景1：数据库模式复杂、表和列众多
     • 建议： 采用模式链接 (Schema Linking) 模块。
     • 优势： 可以减少无关模式信息带来的噪声，并降低输入模型的token成本。
     • 劣势： 会增加额外的时间开销。
   • 场景2：可以访问SQL的执行结果
     • 建议： 采用执行引导 (Execution-Guided) 策略。
     • 优势： 能有效过滤掉无法执行的SQL，从而提升系统性能。
     • 劣势： 查询执行本身会消耗大量时间，尤其是在大型数据库上。

十二、 未来展望：局限性与开放性问题

尽管基于LLM的方法取得了巨大成功，但它们在真实世界应用中仍面临诸多挑战，这也为未来的研究指明了方向。

• 当前LLM方案的局限性：

  • 环境封闭： 模型通常在单个固定数据库上训练和运行，缺乏处理跨库查询和多源数据聚合的能力。
  • 成本高昂： LLM的推理过程消耗大量token，导致高成本和低效率。
  • 缺乏可解释性： 大多数方法像一个"黑箱"，用户难以理解其生成逻辑或调试潜在的语义错误。
  • 适应性差： 对新领域的适应能力有限，且高度依赖高质量的训练数据。

• 开放性问题与研究方向：

  1. 开放域Text-to-SQL (Open-Domain Text-to-SQL): 现实中，一个问题可能需要查询多个数据库并聚合结果。这带来了全新的挑战，包括：如何从海量数据源中检索相关数据库、处理异构的模式、规划跨库查询并聚合答案等。
  2. 高性价比的Text-to-SQL方法： 降低LLM的高昂成本是关键。一个有前景的方向是结合LLM和PLM的优势，构建模块化或多代理框架，让它们协同工作。
  3. 可信赖的Text-to-SQL解决方案： 提升系统的可靠性至关重要。这包括：
     • 可解释性： 运用可解释AI（XAI）技术来揭示模型的决策过程。
     • 调试工具： 开发能同时检测语法和语义错误的Text-to-SQL调试器。
     • 交互式工具： 为数据库管理员（DBA）等专业用户提供人机协作工具，以迭代方式构建和优化复杂的SQL查询。
  4. 自适应的训练数据合成： 研究如何根据模型的性能反馈，自动并增量地生成高质量的（自然语言，SQL）训练对，从而帮助模型弥补短板，持续学习和进化。

十三、 结论

这篇综述以LLM时代为背景，从生命周期的视角全面回顾了Text-to-SQL技术。它系统地定义了任务和挑战，总结了从预处理、翻译到后处理的各项关键技术模块，并深入分析了基准数据集和评估指标。通过提供实用的开发路线图和展望未来的开放性问题，该文为研究者和实践者在通往数据民主化的道路上提供了宝贵的导航。