阿里妹导读
本文系统性地阐述了自然语言转SQL（NL2SQL） 技术如何让非技术背景的业务分析师实现数据自助查询，从而提升数据驱动决策的效率与准确性。
一、引言
数据驱动决策一直在各行各业中至关重要，业务分析师常常面临繁重的数据查询任务。通过自然语言生成结构化查询语言（SQL）的技术，即NL2SQL，业务分析师不再需要掌握复杂的编程技能，便能够轻松访问和处理数据。这篇文章将探讨如何利用NL2SQL技术来自动化处理常见的数据查询任务。
想象一个典型的场景：一位业务分析师需要提供上个月销售额最高的前10个商品。如果用传统方法，首先分析师需要知道销售额相关的基础数据表是哪些，接着得确认销售额的具体口径定义，最后需要按照一定方式编写复杂的SQL查询得到结果。这不仅需要对SQL语言有深刻的理解，还要对指标的定义、业务数据来源非常熟悉。
如果将NL2SQL技术和日常数据分析结合。可以帮助业务分析师显著减少完成数据分析所需的时间，同时还可以借助NL2SQL纠正发现语法问题减少人为错误，甚至即使没有技术背景的用户也能通过自然语言简单地进行复杂的数据查询，提高运营自助分析查询的效率。
二、技术背景与发展历程
2.1 问题定义
NL2SQL是"Natural Language to SQL"的缩写，指的是将自然语言查询转化为SQL查询语句的技术。它主要用于将用户以自然语言提出的问题自动转换成能够被数据库系统理解并执行的SQL查询，从而实现从数据库中检索相关信息的目的。
什么是NL2SQL
问题拆解
语义理解
自然语言通常具有很高的复杂性和多义性。语义理解要求系统能够准确地捕捉用户查询的意图，并处理自然语言中的模糊和歧义。这包括理解自然语言中的上下文、处理指代、识别关键实体和关系，以及解析复杂的句子结构。
Schema映射
Schema映射涉及将自然语言查询映射到数据库模式中的具体表和列。数据库的模式通常非常结构化，而自然语言查询可能没那么直接地指明这些结构。例如，一个查询可能使用同义词或间接提及而不是明示的列名或表名。系统需要具备将自然语言中提到的概念正确映射到数据库结构上的能力。
SQL生成
SQL生成是将处理过的自然语言意图和映射到数据库元素的信息转换为合法的SQL查询的过程。生成的SQL不仅需要语法正确，而且在语义上准确地代表原始的用户需求。挑战在于生成的SQL需要处理不同的查询形式和复杂度，包括聚合、嵌套查询、连接等功能。此外，生成的SQL必须满足高性能、合规性和安全性问题。
核心挑战
语法正确
数据库架构本身的复杂性和庞大体量的数据对NL2SQL构成了明显的挑战，比如数据库语法的多元性、表之间的关系复杂性、列名的相似性、以及大数据量的不完整性。
语义正确
自然语言可能因歧义和不明确性而含有不确定性，例如词义歧义、句法歧义、信息不足和用户错误。与此同时，当实际应用到业务场景时，不同团队对同一术语的定义也可能不同。比如“成交”可能意味着产生订单，也可能意味着必须支付。
效果稳定
NL2SQL与编程语言不同，因为输入的NL和输出的SQL查询之间通常存在一对多的映射。即使是完全一样的问题，也可能输出各种不同的SQL结果。
2.2 发展历史
基于规则的方法
早期研究主要集中在使用预定义规则或语义解析器来理解自然语言查询并将其转换为SQL查询。
基于神经网络的方法
为了解决基于规则的方法的局限性，研究者开始利用神经网络来解决NL2SQL，例如使用序列到序列模型或图神经网络。
基于预训练语言模型的方法
随着BERT和T5等预训练语言模型的出现，基于PLM的NL2SQL方法在多个基准数据集上取得了显著的性能提升。
大型语言模型时代
随着LLMs的出现，NL2SQL技术取得了显著进展，LLMs具有卓越的语言理解和新出现的能力，例如使用提示来执行NL2SQL任务。
三、关键技术挑战与解决方案
3.1 Schema Linking（模式链接）
Schema Linking旨在理解自然语言查询与数据库模式（schema）之间的语义关系，以帮助生成准确的SQL查询。
自然语言问题 → 表选择器 → 相关表集合 → 列选择器 → 最终SQL
检索模块
用户提问—>含有小样本的命名实体识别prompt+LLM—>得到关键词和实体—>根据关键词的语义相似性匹配top k列 | 基于局部敏感哈希 (LSH) 和语义相似性的两阶段检索策略检索值—>得到最终列和值
表选择器
表选择器的作用是识别哪些表与查询最相关，并需要在SQL查询中用到。
表选择器通常通过以下几步实现：
1.自然语言理解：分析用户的查询，提取关键实体和操作动词。
2.Schema 分析：了解数据库模式中有哪些表、字段以及它们之间的关系。
3.语义匹配：将用户查询的关键部分与数据库的表和字段进行匹配，以识别相关的表。
4.表优先级排序：根据相关性对表进行排序，优先选择最相关的表参与SQL构建。
列选择器
含有小样本的prompt+LLM—>仅选择与用户提问最相关的最少列
3.2 复杂查询理解
Chain-of-thought（CoT）
思维链（CoT）与大型语言模型（LLM）相结合，能在复杂的推理任务上取得了不错的结果。
Divide and Conquer CoT（分而治之CoT）：让模型把查询任务拆解成更细粒度的任务，然后用SQL伪代码写出对这些子任务的查询，最终将结果合成一个完整的SQL。直接写SQL效果不好是因为模型可能没有见过这样的数据分布，但是它肯定见过简单任务的数据分布，在SQL子语句都写出来了的前提下，SQL的组合就显得没那么复杂了。
Query Plan CoT（查询/执行计划CoT）：让模型先把SQL的执行计划描述出来，再通过执行计划来生成SQL。这么做可以让模型换个角度思考问题，将数据分布切换到了另外一个领域，能让模型更多地关注具体要用的表、列，能补足“分而治之”方法对细节把控不足的缺点。
3.3 提示词工程
在利用LLM完成NL2SQL任务时，提示工程的关键在于将自然语言问题与必要的数据库信息转化为适用于LLM的自然语言序列输入，即问题表示。同时，当允许输入一些样例以利用LLM的in-context learning能力时，还需要考虑如何选择样例以及如何将这些样例有机地组织到输入序列中。
基本提示
基本提示（Basic Prompt）是一种简单的Prompt模板，它由表模式、以 Q: 为前缀的自然语言问题、以及提示LLM生成SQL的响应前缀 A:SELECT 组成。之所以命名为基本提示，是因为它并未包含任何指令内容。
文本表示提示
文本表示法提示（Text Representation Prompt）相比于基本提示，在提示的开头添加了指导LLM的指令。
OpenAI范式提示
OpenAI示范提示（OpenAI Demostration Prompt）首次在OpenAI的官方NL2SQL演示中使用，它由指令、表模式和问题组成，其中所有信息都用“#”进行注释。与文本表示提示相比，OpenAI示范提示中的指令更具体，而且还有一条规则约束，“仅完成sqlite SQL查询，无需解释”。
代码表示提示
代码表示提示（Code Representation Prompt）是一种基于SQL语法实现NL2SQL任务的方式。具体来说，它直接将表创建语句“CREATE TABLE …”放到Prompt中。相较于其他的问题表示方法，代码表示提示的独特之处在于，它能够提供创建数据库所需的全面信息，例如列名、列类型、主键/外键等。
通用方案总结
综合考虑上述Prompt策略，可以总结出一套通用且有效的NL2SQL Prompt策略。这一策略由六个关键要素构成，每个要素在提升模型生成SQL的准确性和效率中发挥着重要作用。以下是各个要素的详细说明：
1.指令（Instruction）：为模型提供清晰而具体的指导方针。例如，"你是一个SQL生成专家。请参考如下的表格结构，直接输出SQL语句，不要提供多余的解释。"
2.数据结构（Table Schema）：类似于语言翻译中的“词汇表”，这是你需要嵌入到Prompt中的数据库表结构。由于大模型无法直接访问数据库，你需手动提供包括表名、列名、列的类型、列的意义，以及主键和外键信息。
3.参考样例（Sample）：这是一种启发模型生成SQL的可选技巧。你可以提供一个类似任务的SQL样例作为参考，以帮助模型更好地理解应该如何构建查询。
4.其他提示（Tips）/约束条件（Constraint）：这些是你认为必要的额外指示。例如，要求生成的SQL中不允许出现某些表达式，或者要求列名必须采用“table.column”的形式。
5.领域知识（Knowledge）：在某些特定问题中，这是一个可选要素。例如，如果用户的问题涉及“谁是这个月最厉害的销售”，你需要告诉模型，“最厉害”是指“销售单量最多”还是“销售金额最多”。
6.用户问题（Question）：这是以自然语言形式表达的查询需求，如“统计上个月的平均订单额”。这一部分用于明确用户的意图和需求，以便模型生成正确的SQL语句。
3.4 多轮对话
SQL 候选生成和优选
候选生成（Candidate Selection）是为了从候选SQLs中选出最好、最正确的一个，常见方法包括：
self-consistency。以N个候选SQL中最常见的（非空）答案为准；
selection Agent。用模型来挑选最好的SQL，可以用提示词或fine-tuning等技术；
基于Unit test。参照AI coding，生成Unit Tests，用来评估每个candidate SQL的得分；
SQL 语法微调
采用SFT方法，通过微调小参数量模型来生成可控的SQL查询。然而，参数限制使得复杂的推理和领域的迁移变得困难。此时可以聚焦于生成高精度、多样化的SQL候选语句。
基础语法训练：这一阶段专注于使用简单且通用的SQL模式和语法对预训练模型进行微调，不涉及具体SQL方言。其目标是开发一个能够激活SQL生成能力的基础模型。
生成增强训练：在基础训练后，通过多任务和句法偏好数据增强模型能力。除了标准的查询生成，还可以额外设计SQL转换任务以深化SQL与问题间的关系。这包括从SQL推断问题、从SQL选择证据及其优化任务。这些任务加强了SQL与上下文信息的关联性，提高了SQL生成的广泛性和多样性。通过不同风格的句法特征，扩展训练样本，使模型从多样化数据中学习，从而生成更丰富的SQL查询。
SQL 查询优化
生成的候选SQL查询不可避免地包含逻辑或语法错误。通过利用这些SQL查询缺陷中的线索，进行一定程度的修正。为此，可以引入一个SQL优化器来优化生成的SQL。在实际应用中，基于与架构相关的上下文、生成的SQL查询以及执行结果（包括潜在的错误信息），可以使模型能够进行第二轮的修正。原始SQL和重新生成的SQL还可以进一步通过选择模型进行最优选择，这一过程可以迭代执行。
3.5 检索增强生成（RAG）
简单来讲，RAG技术就是通过检索获取相关的知识并将其融入Prompt，让大模型能够参考相应的知识从而给出合理回答。因此，可以将RAG的核心理解为“检索+生成”。而在上文的「提示词工程」章节我们可以看到，为了提高NL2SQL生成的SQL质量，需要在提示词中加入业务领域知识、表知识（Scheme）和列知识（Indicator），甚至是一些样例（Examples）问题便于query改写。而这往往又会造成提示词过多造成的上下文token不够的问题。因此，如果能将这些知识都转换成即时查询的方式，可以有效解决上下文token过大的问题。
在NL2SQL场景中，以下关键步骤可以借助RAG提高效率：
领域知识查询：
RAG可以利用预训练模型和检索技术相结合，帮助理解用户的查询所涉及的领域或上下文。通过从相关文档或数据库检索信息，RAG可以为生成更精确的SQL语句提供背景知识。
具体应用包括根据领域特定的术语或概念检索相关信息，从而帮助系统更好地理解和处理复杂或专业的查询。
表查询：
在生成SQL查询时，正确选择和理解数据库中的表是至关重要的。
RAG可以通过检索数据库的元数据或相关文档，帮助识别合适的表及其结构。
指标查询：
对于用户查询中涉及的各种指标，例如计算平均值、总和、最大值等，RAG可以帮助检索相关的计算逻辑或历史数据。
RAG能够从过去的查询实例或相关文档中提取信息，帮助提高生成查询的准确性和效率，尤其是在复杂计算的场景中。
3.6 NL2Semantic2SQL
除了从数据库和SQL层面思考如何提高NL2SQL的准确性，还可以从增加语义理解层来思考解决方案。因为如何将用户模糊、多变的业务意图如何精准、高效地映射到企业复杂的数据资产中？这一问题本身就是数据工程问题，而非单纯的 AI 问题。
可以通过如果额外引入一层语义层来更好的解决NL2SQL问题。语义层需要有以下特征：
统一的业务语义抽象层，作为Agent和开发人员共同理解的“数据语言”；
强大的元数据管理能力，确保指标定义的唯一性、透明性和可追溯性；
NL2Semantic2SQL 技术路线通过引入语义层作为中间抽象，大幅提升了系统的灵活性和可解释性。指标平台采用"度量"和"维度"两大基础要素，并运用"基础度量"、"业务限定"、"时间限定"和"衍生方式"四大要素，灵活定义和组合具有明确业务含义的指标，打造了一个统一的语义模型。自然语言查询首先被转换为语义表示，然后由系统基于语义模型生成最优SQL查询。
这种语义与表结构的解耦设计，使系统能够理解指标的业务意义，而不仅仅是表结构，确保在不同场景下，同一指标的口径保持一致性。随着业务规则的变化，只需调整语义定义，无需修改所有相关表或查询，显著提高了系统的适应性。
语义层的引入是 NL2Semantic2SQL 相对于传统NL2SQL的核心优势。它不仅提升了查询的准确性，还增强了系统的可解释性，赋予业务人员更强的自助能力。通过构建统一的业务语义模型，指标平台有效地跨越了技术与业务之间的鸿沟，使业务人员可以直接理解和使用数据，而无需深刻掌握SQL语法。
3.7 半结构化的数据库表达
scheme LLM专属注释
正如上文所说，在使用基于LLM的NL2SQL技术时，为了使模型能够准确理解数据表的含义和列名的表示，建议为常用的数据表及其列添加注释。
表注释有助于模型更好地理解表的基本信息，从而在生成SQL语句时准确定位相关表。注释应简单明了，概括表的核心内容，如订单、库存等，并建议控制在10字以内，以避免过多解释。
列注释通常由常用名词或短语构成，例如订单编号、日期、店铺名称等，以准确表达列名的意义。此外，可以在列注释中包含列的示例数据或映射关系。例如，对于列名“isValid”，注释可以写成“是否有效。0：否。1：是。”以清楚地表示该列的含义和数值对应关系。
但是传统的数据库表注释和列注释可能已有一定的含义和上下游对接规范，所以目前有些数据库可支持scheme维度LLM专属的注释，用于提供NL2SQL时获取表和列的提供便利。比如阿里的PolarDB，开源的M-Schema项目。
LLM配置表
在解决语义不清的问题时，往往需要我们对原始的问题进行改写符合底层数据的要求。一方面我们可以通过知识库的方式解决，另外一方面也有一些数据库层面提供的解决方案，比如阿里的PolarDB提供了「配置表」功能，通过全局生效的固定表名，存储了诸如「问题文本条件判断」、「问题处理」、「问题补充与具体业务/概念相关的信息」等前置文本转换功能，「模型生成的SQL条件判断」、「处理SQL，用于对业务逻辑中的值映射进行强制处理」等后置文本转换功能信息。
参考文献：《LLM驱动的NL2SQL方法论：现状、难点、优化》：https://lengm.cn/post/20240908_nl2sql_general/
《不要只盯着 Agent，AI-Ready 的数据底座才是 Chat BI 的关键》：https://www.infoq.cn/article/Z3Pq5xTyaGRaHQ7rjhqL
《大模型落地的关键：如何用 RAG 打造更智能的 AI 搜索——阿里云 AI 搜索开放平台》：https://xie.infoq.cn/article/bcfb968ffcf43e5f57399f37a
《[Text2SQL]DIN-SQL、DAIL-SQL、C3、MAC-SQL、MCS-SQL、CHESS多种Text2SQL方案》：https://zhuanlan.zhihu.com/p/12278520272
文档智能与 RAG 构建 LLM 知识库
本方案介绍了如何实现将文档智能和检索增强生成（RAG）结合起来构建强大的 LLM 知识库，包括清洗文档内容、文档内容向量化、问答内容召回后通过特定的 Prompt，提供给 LLM 足够的上下文信息，以此来满足对于企业级文档类型知识库的问答处理。
点击阅读原文查看详情。
