NL2SQL现状

通过大语言模型进行的NL2SQL发展很快，近两年的几个项目是：

• QueryGPT（Uber 2024年），是个端到端的系统，使用LLM（GPT-4）构建了多步骤的管道，并结合检索和代理模块。整体架构类似RAG方法，给定一个问题，首先对实例查询以及架构信息的向量库进行相似性搜索，获取上下文。这些示例和架构片段作为小样本提示提供给 LLM，指导其生成 SQL。由于 Uber 的数据生态系统非常复杂（有些表有 200+ 列），因此 QueryGPT 结合了专门的Agent来处理这些复杂的场景。意图Agent 将用户的请求分类成特定的业务域（例如“手机”或“广告”），从而缩小相关的表和示例查询的范围。然后， 表Agent 会建议查询应使用的特定表，从而允许用户反馈以更正表选择中的任何错误。在生成之前， 列修剪Agent 从这些表的结构中修剪不相关的列，以减少提示词长度（在使用具有有限上下文窗口的模型时至关重要）。最后，通过LLM生成一个 SQL查询（以及对应的解释），该查询将结果返回给用户。这种分层设计结合了检索、域过滤和迭代优化，使QueryGPT能够在128K Token的GPT-4上下文中处理Uber的大型架构，并可靠地生成复杂的多表查询。QueryGPT 体现了一种 混合架构 ，其中多个对模型的调用专注于子任务（如意图分类、架构选择等），从而最终生成准确的SQL。值得注意的是，它作为生产服务运行，到 2024 年中，它为数千名 Uber 员工在制定运营查询方面节省了大量时间。
• DIN-SQL （2023），利用了一些最先进的提示词策略，而不是新的模型架构。关键思想是利用 思维链分解 ：DIN-SQL 不是提示 LLM 直接输出最终的 SQL，而是将生成分解为更小的子问题，并逐步将中间解决方案反馈到模型中，例如，可能首先提示 LLM 确定哪些表和列是相关的，然后制定部分子句（SELECT、WHERE），最后组合和验证完整的查询。DIN-SQL 还引入了 自我纠正循环 ，其中分析 LLM 的初始答案，如果检测到错误（例如，与 schema 或执行结果不匹配），则提示模型修改其查询。这种 分解的提示 + 反馈 方法在小样本情况下 产生了显著的准确率提升 （~+10%）。在 Spider 基准测试中创下了新纪录，测试集的执行准确率为 85.3%，超过了之前的所有微调模型。它还在较新的 BIRD 基准测试中达到了最先进的水平（55.9% 的执行准确率）。DIN-SQL 系统强调了提示工程如何释放 LLM 的推理能力：通过引导模型完成类似于人类解决查询的推理过程（逐步和反射），它无需额外培训即可缩小性能差距。
• SQLCoder**（Defog， 2023–2024）** 代表了一系列专门用于 NL2SQL 的微调 LLM，展示了将模型专门用于此任务的能力。SQLCoder 模型由 Defog 公司开发，基于开源LLM（Meta 的最新版本为 CodeLlama），并使用了大量文本到 SQL示例进行微调。他们发布了各种比例的模型（7B、15B 和高达 70B 参数的模型）。最大的 SQLCoder-70B 在许多基准测试中都取得了接近人类的性能，在新的的数据架构和问题上达到 93% 的准确率。在公司的评估套件上的表现甚至超过了 GPT-4 和 Claude。由于微调，它通常可以为领域内的查询生成具有非常高精度的正确 SQL。其中的较小的版本（SQLCoder-7B 和 15B）以一定的准确性换取了速度和可部署性，例如，7B 模型足够小，可以在消费类硬件 （≈8 GB GPU）上运行，支持本地和实时用例。通过开源这些模型，SQLCoder 使研究人员能够试验最先进的 NL2SQL，而无需依赖封闭的 API。例如，据报道，SQLCoder-70B 模型可以处理涉及日期、分组、联接和嵌套逻辑的复杂查询，在许多情况下的准确性高于 GPT-4。

NL2SQL架构发展趋势

当前架构发展来看，几乎所有性能最好的方法都在使用大语言模型。这是因为LLM在理解自然语言和生成结构化文本方面具有卓越的能力。部分架构是端到端的（直接使用LLM转换SQL），另一部分架构是混合多个组件或阶段的混合pipeline。现代 NL2SQL 架构将强大的序列模型与特定于问题的增强功能相结合：大型 LLM 提供了强大的生成 SQL 的先验能力，而检索、结构化架构表示和基于搜索的优化解决了特定于数据库的解析的细微差别。

Uber的QueryGPT

第一版： ![[Pasted_image_20250629232734.png]]

当前版本： ![[Pasted_image_20250629232701.png]]