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 的研究方向多样性较高，个人粗略梳理了以下几个方面的路线：
- 信息表示（information representation）
- 语境学习（in-context learning）
- 流程优化（监督学习、智能体等）
在逐步分解介绍上述思路前，先介绍下大概的一般性思路。
一般我们使用大语言模型的步骤是输入问题 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 对形式加入到输入提示词中。
此外，数据库各个列的样本值采样也是比较有用的信息，例如
- 某些列名带有枚举值特点，可以在提示词中加入抽样后的各个枚举值信息
- 对于时间类型，时间格式通常需要给予额外信息提示，可以根据建表信息列名类型判别，并抽取 n 个时间类型的样本，加入进提示词中。
- 对于中英文易混淆的情况，例如人物名称，特别是外国人的名字，也可以对数据库样本值进行抽样补充。
这类样本值抽样的算法对于最终的 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 思路中建表信息关联（Schema Linking）或输入信息的过滤、压缩提出更高的要求。
- 业务逻辑中的数学计算：业务逻辑下的数学计算，例如生产缺陷率的计算需要某两列的加权值，如何在海量业务资料中快速检索关联重要信息非常重要。
- 业务逻辑的条件约束：某些业务查询逻辑，例如月统计为上月 26 日到次月 25 日，在特定问题中起到关键作用，但用户问题往往不会直接包含，需要算法自动根据问题匹配检索并补充。
- 同质化业务逻辑的作用域：例如 A 部门计算指标 1 需要列 A 的算数平均值，B 部门计算同样指标 1，需要列 B + 列 A 的加权平均值。
- 要求用户在输入问题时进行关键信息补充是不现实的，因为 text2SQL 的目的是降低用户使用门槛，非技术人员的输入不一定完整，这时需要特定算法处理这类类似 N 选 1 逻辑的特殊信息。
- 上下文长度限制：如果采用学术领域下的 text2SQL 思路，往往上下文长度会超限，即使使用能够容纳更长上下文的模型，例如 Coder 类代码生成模型，大语言模型的理解能力也会下降。
卓世科技 text2SQL 的产品化过程，对以上实际转化落地可能遇到的问题进行分析整理，并形成产品化方案，例如
- 多向量数据库支持：产品支持多种向量数据库，并对业务资料进行分类管理，包括类别列名的释义、业务逻辑计算以及业务语义资料的整理。
- 用户自定义功能：用户可以自定义增删改查操作来创建向量数据库，同时我们也提供大语言模型辅助自动生成相关逻辑语义数据的功能。
- 广泛数据库兼容性：产品与市场上的主流数据库（如 MySQL、SQLite、PostgreSQL 等）兼容。我们根据不同数据库的类型，特别优化了解决 text2SQL 语法兼容性的问题。
- 智能图表摘要：text2SQL 后的数据可以自动生成可视化图表和数据分析摘要，帮助用户更直观地理解分析结果。
- 智能问题补充：系统能够智能化地补充用户问题并生成准确的 SQL 语句。用户无需完整输入业务相关的计算公式或补充表达，只需简单描述问题，系统会自动推理并补充关键业务资料。
- text2SQL 产品化定制：text2SQL 的天然特点是可以适配植入到某数据自动化中台业务流程中，降低数据查询门槛的同时，实现业务智能代理模式，卓世 text2SQL 方案采用组件化设计思路，能够灵活拆解各个子流程，能够根据用户需求灵活设计，植入到用户已存在的业务流水线中。
- 高精度应用示例：在对业务资料进行逻辑语义建模和物理数据建模后，我们以某能源领域的真实工业生产数据库为例，展示了 text2SQL 方案的高效性，其中简单 SQL 的准确率达到了 95% 以上，复杂 SQL 的准确率超过 90%。
通过这些功能，卓世科技的 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
