使用大模型完成Text-to-SQL的综述

最新推荐文章于 2025-03-17 20:06:45 发布

程序员笑武

最新推荐文章于 2025-03-17 20:06:45 发布

阅读量3.4k

点赞数 16

文章标签： sql 人工智能 python 1024程序员节神经网络深度学习知识图谱

本文链接：https://blog.csdn.net/m0_59164304/article/details/143349617

版权

摘要：这篇论文是一篇关于利用大型语言模型（LLMs）进行文本到SQL任务的综述。作者首先介绍了文本到SQL任务的背景和重要性，以及LLMs在这项任务中的优势。然后，文章将LLMs应用于文本到SQL任务的方法分为两种：提示工程和微调。在提示工程方面，作者深入探讨了提示的基本结构、知识补充方法、示例选择和推理过程。在微调方面，作者阐述了微调的基本步骤，包括数据准备、预训练模型选择、模型微调和模型评估，并将这些步骤与文本到SQL任务相结合进行了详细讨论。此外，文章还回顾了现有的文本到SQL任务基准，并详细探讨了适合大型语言模型时代的基准数据集。最后，作者展望了未来研究方向，并分享了自己的观点。总而言之，这篇论文旨在帮助读者深入了解文本到SQL领域最新的进展，并提供对未来发展趋势的洞察。

一、引言

Text-to-SQL 任务旨在将自然语言查询转换为可在关系数据库中执行的 SQL 查询。 随着存储在关系数据库中的数据量不断增加，高效查询和利用这些数据已成为各个行业提高竞争力的关键因素。然而，编写 SQL 查询需要专业知识，这对非专业用户来说是一个挑战。Text-to-SQL 解析通过将自然语言查询转换为 SQL 查询来解决这个问题，从而使非专家用户更容易访问和查询数据库。

大语言模型 (LLM) 非常适合 Text-to-SQL 任务，因为它们具有强大的自然语言理解能力和代码生成能力。 LLM 在大型语料库上进行训练，这使它们能够学习丰富的语言知识和语法规则。此外，LLM 具有涌现能力，例如少样本学习和指令遵循能力，这使得它们能够在没有额外训练的情况下执行下游任务，例如 Text-to-SQL。

提示工程是一种利用 LLM 能力的关键技术，它涉及设计有效的提示词来引导 LLM 生成所需的输出。 在 Text-to-SQL 任务中，提示工程可以用于：

将自然语言问题、数据库模式和其他相关信息以结构化的方式呈现给 LLM。
引导 LLM 进行多步骤推理，例如模式链接、查询分解和自我修正。
提供少样本演示，以帮助 LLM 学习任务模式和提高性能。

通过精心设计的提示词，我们可以有效地利用 LLM 的能力来解决 Text-to-SQL 任务。

二、提示工程

2.1 预处理

预处理阶段的目标是在将问题提交给 LLM 之前，以一种清晰、全面的方式组织所有必要的信息。这有助于 LLM 更好地理解问题并生成更准确的 SQL 查询。预处理阶段主要包含三个方面：问题表示、模式链接和知识补充。

2.1.1 问题表示

问题表示指的是如何将自然语言问题和相关数据库信息呈现给 LLM。这部分主要涉及布局设计和示例数据的使用。

布局

布局是指问题和数据库结构的书写格式。常见的布局有两种：OpenAI 模板布局和 “Create Table” 布局。

OpenAI 模板布局： 这种布局使用 SQLite 的注释符号 # 开头，然后以 Table (Column1, Column2, ...) 的形式描述表格结构。表格描述完成后，最后一行提供 SELECT 关键字。许多研究都采用了这种布局。
“Create Table” 布局： 这种布局使用 CREATE TABLE 语句来表示数据库结构，并明确包含每个列的数据类型以及可能的主键和外键关系。这种布局更接近数据工程师编写 SQL 的实际情况，一些研究也采用了这种布局。

示例数据

除了布局之外，来自真实数据库内容的示例数据也有助于问题表示。

一些研究将示例数据直接放入提示词中，目的是使 LLM 能够理解数据库中的示例数据，并在生成 SQL 时符合数据本身的格式。
还有研究使用 SELECT * From Table LIMIT X 语句及其执行结果作为提示词，其中 X 是一个整数，通常取值为 3。

主键和外键描述

许多研究强调主键和外键描述的重要性，试图增加 LLM 对表之间关系的关注。研究表明，移除外键描述会导致性能显著下降。

观察和总结

结构化布局 (例如 OpenAI 模板布局和 “Create Table” 布局) 比非结构化布局效果更好，而不同的结构化布局之间效果相当。
示例数据是有效的，可插入的，并且在上下文长度足够的情况下值得考虑。
主键和外键描述非常重要，在复杂场景中至关重要且适用

2.1.2 模式链接

模式链接是指识别数据库中与给定查询中的短语相对应的表和列。

在基于 LLM 的 Text-to-SQL 中，模式链接很重要，因为它可以缩短 token 长度，提高 LLM 的注意力和效率，并改善性能。
许多 LLM-based Text-to-SQL 系统无法正确识别列名、表名或问题中提到的实体，导致性能下降。模式链接可以解决这个问题。

基于 LLM 的模式链接方法

使用专门为模式链接设计的步骤提示 LLM。 例如，C3 将模式链接分为两个步骤：首先指示 ChatGPT 回忆表，然后检索候选表中的列；Reboost 采用与 C3 相同的方法，但通过包含查询描述和列解释来丰富表和列的选择；DEA-SQL 首先识别查询中的元素，然后使用它们过滤模式；CHESS 遵循“列过滤、表选择和最终列过滤”的三步范式；PET-SQL 首先组成相应的 SQL 查询，然后从这些查询中提取表和列。
利用通用的 LLM 技术来提高基于 LLM 的模式链接性能。 例如，DIN-SQL 随机选择一些示例来指导模式链接，并使用 “Let’s think step by step” 来进一步提高性能；C3 使用自我一致性来提高性能稳定性；QDecomp 和 ACT-SQL 也使用少样本学习来指导模式链接，但更侧重于示例构建。

传统模式链接方法

相似度方法： 通过计算查询和模式信息之间的相似度来检索相关模式。例如，De-semanticization 通过识别问题中每个标记与模式中每个项目之间的直接匹配，以及识别问题词与特定数据库值之间的对应关系来计算相似度。
连通性方法： 考虑表和列之间的关系或连接。例如，DBCopilot 构建一个图来表示所有数据库及其表的基础模式结构，然后训练一个 Seq2Seq 模型作为路由器，在海量数据库上进行路由以获取一组模式；PURPLE 基于外键-主键连接创建图，以增强检索到的相关模式的互连性。

2.1.3 知识

除了问题表示和模式链接方法之外，为 LLM 提供相关知识也很有益。这些知识可以被视为对当前任务描述的校准，为后续的 SQL 生成铺平道路。

SQL 知识

SQL 相关的知识主要包括 SQL 关键字、SQL 语法和常见的 SQL 编写习惯。将 SQL 相关的知识添加到提示中，就像为初级 DBA 提供了一本经验手册，可以避免语义错误。

C3 专门校准了模型在 SQL 样式方面的偏差，并在提示中添加了以下说明：仅在特定情况下使用 COUNT(*)，避免使用 LEFT JOIN、IN 和 OR，而是使用 JOIN 和 INTERSECT，并推荐使用 DISTINCT 和 LIMIT 关键字。
DIN-SQL 和 DEA-SQL 注意到 JOIN、INTERSECT 和 IN 等一些关键字表明了 SQL 查询的难度，因此他们根据自己的判断设计了关于当前问题难度级别的不同规范和提示。
Meta-SQL 设计了三种查询元数据来表示查询的高级语义：运算符标签、难度值和正确性指标。
SQLfuse 补充了枚举常见错误的校准提示，以预先解决潜在的错误步骤，增强模型生成高质量 SQL 查询的能力。

外部知识

外部环境中也存在一些可能对 Text2SQL 任务有帮助的杂项知识，因为有些术语或特定领域的词语如果没有解释就很难理解。

Open-SQL 利用 BIRD 数据集提供的每个查询附带的额外描述信息，作为人类理解和数据库结构之间的桥梁。
CHESS 使用上下文检索方法提取数据库目录、表和列的描述和缩写，以获得更好的性能。
SQLfuse 专门设计了一个 “SQL Critic” 模块来确定最佳候选 SQL 查询。该模块从 GitHub 中的一系列复杂的 SQL 语句和模式构建外部 SQL 知识库，以便更好地提取外部环境中的知识。

总结

预处理阶段是提示工程的关键步骤，它涉及以一种清晰、全面的方式组织所有必要的信息，以便 LLM 更好地理解问题并生成更准确的 SQL 查询。问题表示、模式链接和知识补充是预处理阶段的三个重要方面，每个方面都有多种不同的方法和技术。选择合适的方法和技术取决于具体的应用场景和 LLM 的能力。

2.2 推理

推理阶段的目标是根据用户的问题和相应的数据库模式生成对应的 SQL 查询。这一阶段可以逻辑上分为两个部分：工作流程设计和演示使用。从预处理到 SQL 生成，大多数工作将在自定义或基于推理模式的方式下设计推理工作流程，并决定是否使用演示。

2.2.1 工作流程

最简单的工作流程是直接从构造的问题和模式生成 SQL，这在某种程度上高估了通用 LLM 在专业领域的能力。就像人们倾向于将复杂的任务分解成几个简单的子任务或步骤一样，基于提示工程的方法通常会设计特定的推理工作流程，以使用 LLM 生成对查询的响应。Text2SQL 任务中的工作流程可以根据不同的推理模式进行分类。

思维链（CoT）

最著名的推理风格是思维链（CoT），它涉及一系列中间推理步骤，通常以短语“让我们一步一步地思考”开始，以引发链式思维。这种方法特别适合复杂的逻辑任务，例如 Text2SQL。

DIN-SQL 在其复杂类别的问题中采用了 CoT 人工设计的步骤。对于非嵌套复杂问题，CoT 步骤包括模式链接和单个中间表示。相反，对于嵌套复杂问题，CoT 步骤包含几个子问题及其对应于原始问题的子查询。
Divide-and-Prompt 以子句逐句的方式生成 SQL，这是 CoT 模式的一种变体。
CoE-SQL 也提出了一种 CoT 的变体，即“编辑链”，它描述了 SQL 语句的 14 条编辑规则：编辑“选择”项、编辑“where”逻辑运算符等。
此外，ACT-SQL 提出了 Auto-CoT来自动生成 CoT 示例，解决了手动标记 CoT 提示的高成本问题。
Open-SQL 设计了 CoT 模板，该模板采用基于框架的查询框架作为中间表示。
SQLfuse 以 CoT 模式组织其 SQL 生成提示，以合并先前的模式信息，并在单个提示内迭代执行 SQL 检查和错误纠正。

最少到最多

最少到最多推理风格是 Text2SQL 工作流程设计中另一种广泛使用的方法，它将一个复杂问题分解成一系列更简单的子问题，并在与 LLM 的一次交互中完成。

LTMP-DA-GP 就是这种类别的一个例子。该论文采用最少到最多的方法来分解自然语言查询，将 NatSQL 映射到分解，并从 NatSQL 生成 SQL。

分解

除了上述推理方法外，还存在一种简单而有效的工作流程，它主要将生成任务分解为与 LLM 的自定义交互，并采用各种技术来解决每个阶段的挑战。

QDecomp 首先通过提出分解提示方法来声明此类别。QDecomp 没有使用 CoT 或最少到最多，而是指示 LLM 以简化和迭代的方式将原始复杂问题分解为推理步骤。
SQL 生成任务的分解可以是并行或顺序的。
从 SQL 语句的错误分析开始，DIN-SQL 将 SQLs 分为三个复杂度级别：简单、嵌套复杂和非嵌套复杂。这就是并行分解。
MAC-SQL 引入了一个由选择器、分解器和精炼器组成的多智能体框架。分解器智能体在预测最终 SQL 之前生成一系列中间步骤（即子问题和 SQL）。这就是顺序分解。
DEA-SQL 遵循信息确定、分类和提示、SQL 生成、自我纠正和主动学习的全局分解步骤。

其他

还有一些专门设计的工作流程。

BINDER 首先利用 LLM 生成其特定领域的语言 BINDER-SQL，该语言与 SQL 语言一致，其中一些列名和值被 API 表达式替换，对应于子问题和原始表中的一些信息。然后，BINDER 再次使用 LLM 基于 API 调用解决的子问题将 BINDER-SQL 转换为 SQL。
R3 为 Text2SQL 任务提出了一种基于共识的多智能体系统。该系统由一个 SQL 编写器智能体和几个不同角色的审阅器智能体组成。在 SQL 编写器和审阅器之间经过几轮“协商”后，将达成共识，并确定最终答案。

关键要点

大多数工作都倾向于选择思维链或分解推理作为基础工作流程。
建议与原始 CoT 相比，设计 CoT 的自定义变体。
分解可以通过顺序或并行的方式使 SQL 生成受益。
其他模式有待探索。

2.2.2 演示

在基于 LLM 的 Text-to-SQL 方法的工作流程中，经常使用演示来通过合并几个演示来增强 SQL 生成的性能。根据是否附加演示，这些方法可以分为两类：零样本方法和少样本方法。

零样本 LLM-based Text-to-SQL 方法的例子包括 C3、ReBoost、DBCopilot、Generic、SGU-SQL 和 SQLfuse。虽然零样本方法具有节省 LLM 的 token 的优点，但 Text-to-SQL 是一项复杂的任务，从模型的角度来看可能相对不熟悉。仅仅修改指令并不能有效地解决这个复杂的任务。
与零样本相比，少样本能够从示例中学习任务模式，并且不完全依赖于模型的预训练知识。这一特性增强了 LLM 的性能和适应性。

在对最近基于 LLM 的 Text-to-SQL 论文中使用的演示进行了全面调查后，我们将演示的功能分为两类，包括：

替换任务描述。 如前所述，为了处理复杂的 Text-to-SQL 任务，研究探索了不同的工作流程，这些工作流程包括特定步骤或涉及以前不存在的新定义的子任务。
例如，在为非嵌套复杂问题生成 SQL 时，DIN-SQL 遵循思维链风格的工作流程，并具有精心设计的步骤。它规定首先生成与问题对应的 NatSQL 作为中间表示。随后，基于此 NatSQL 生成最终结果。
另一个例子是 BINDER，它使用语言模型 API 调用函数来增强编程语言（例如 SQL），并使用大型语言模型将自然语言查询转换为扩展 SQL 语言。
然而，DIN-SQL 精心设计的步骤和 BINDER 的翻译从模型的角度来看都是不熟悉的，并且不容易用人类语言提示来描述。在这种情况下，它们都利用了 LLM 的上下文学习能力，并提供了一些示例。这极大地简化了提示中的指令设计。
Divide-and-Prompt、QDecomp 和 COE-SQL 也采用了这种思想。
增强 LLM 的 SQL 编码能力。 适当的演示可以极大地提高 LLM 的性能，实验发现 LLM 对样本选择非常敏感，选择不合适的样本甚至可能会产生负面影响。为了最大限度地提高性能，研究探索了如何选择合适的演示。
DAIL-SQL 考虑了准确性和 token 成本之间的权衡，并提供了三种示例样式，即查询、模式和相应 SQL 的组合，查询和相应 SQL 的组合，以及仅 SQL。DAIL-SQL 选择查询和相应 SQL 的组合来减少示例的 token 长度。
ACT-SQL 就是一个例子。它使用随机选择的示例以及与当前问题类似的示例。
检索和修订通过使用指令提示 LLM 来简化自然语言问题，并利用原始问题和简化问题来检索示例，从而避免了不寻常的提问风格带来的挫折，并增强了存储库中的语法和措辞多样性。
DAIL-SQL 利用自然语言问题和相应的 SQL 查询来检索示例，而 Open-SQL 利用自然语言问题、数据库模式和相应的 SQL 查询来检索示例。
其中，PURPLE 进一步设计了四个级别的 SQL 框架抽象，并侧重于更粗粒度的检索。
最简单的方法是检索问题具有相似语义的示例。然而，即使不同数据库方案的问题的底层意图相似，并且相应的 SQL 查询也显示出相似性，但它们的问题也可能存在很大差异。
为了弥合这一差距，诸如 De-semanticization、检索和修订、DAIL-SQL、DEA-SQL 和 PURPLE 等研究首先屏蔽原始问题中特定领域的词语以获得查询的框架。然后，他们检索问题框架具有相似语义的示例。
一些研究尝试使用更多信息来检索示例。
除了检索类似的示例之外，不同的示例也可能会有所帮助。
除了示例选择之外，token 成本也是另一个考虑因素。

关键要点

在提示中进行任务描述的一种直接方法是利用演示。工作流程越复杂，这种方法的优势就越大。
问题框架比原始问题能够更有效地捕捉问题意图。
需要权衡准确性和 token 成本之间的关系。

2.3 后处理

为了进一步提高基于 LLM 的 Text-to-SQL 方法的性能和稳定性，研究将后处理应用于生成的 SQL。在全面调查之后，我们将这些方法总结为两类：自我修正和一致性。

2.3.1 自我修正

LLM 生成答案后，自我修正方法使用特定问题和任务下的规则让 LLM 检查答案的正确性；在 Text2SQL 场景下，自我修正方法可以使用 SQL 相关的规则进行检查，也可以为 LLM 提供运行 SQL 语句产生的结果或错误日志进行检查。

注意到表值中额外空格的细微差别，并让 LLM 重新检查它们。
的方法是将原始提示词中的少量模式更改为完整数量的模式，如果 LLM 生成的 SQL 无法运行，则再次生成 SQL。
在中，不正确的 SQL 和指示执行错误的信息将用作 LLM 重新生成 SQL 的提示。
分析了字段匹配和 SQL 语法的几个重要错误点，然后设计了专门的提示来纠正它们。
为模型设计了单元测试、代码解释和执行结果，以改进其响应。
提出了 SQL 评论家模块，并采用了一种少样本上下文学习策略，该策略利用来自外部 SQL 知识库的示例，并丰富了事后反馈。

洞察力

在 Text2SQL 任务中，大多数配备自我修正的工作都集中在“改进”部分，比如一些手工制作的模式修改规则和执行日志，而像代码解释和答案判断这样的“评论家”部分还有更多的探索空间。

2.3.2 一致性方法

自我一致性 方法主要采用多数投票策略，通过设置一定的温度，让同一个 LLM 对同一个问题生成多个答案。然后 LLM 选择出现频率最高的答案作为最终答案。

在中，直接使用自我一致性方法对 LLM 生成的 SQL 进行主要投票，取得了良好的性能提升。
提出对多个答案重新排序，并训练了一个验证器来检查生成的代码。
PURPLE 利用基于生成 SQL 执行结果的多数投票。

与自我一致性不同，交叉一致性 方法使用几个不同的 LLM 或代理分别生成答案或检查 SQL 的有效性。

PET-SQL 提出这种方法来指示几个 LLM 在较低的温度下生成 SQL，然后对 SQL 的执行结果进行投票。
为了利用各自优势，在其后处理阶段依次使用了自我修正和自我一致性。
R3 采用多智能体框架，以循环的方式从具有不同专业知识的智能体提供 SQL 建议，就像交叉一致性和自我修正的结合。

关键要点

自我一致性具有适应性强、使用方便、性能好等优点。然而，它需要更多与 LLM 的交互，成本更高。
交叉一致性让多个 LLM 参与进来，减少了单个 LLM 的偏见缺陷。
在后处理阶段同时使用自我修正和一致性方法是有希望的。

2.3.3 其他

DEA-SQL 发现模型更容易出现某些问题类型（例如极值问题）的错误，然后利用主动学习来表示三个固定的错误案例，并识别生成的 SQL 是否应该修改，从而更好地满足需求。

三、RAGFlow 的 text2sql 实现

3.1 RAGFlow 的 text2sql 功能和实现原理

RAGFlow 的 text2sql 功能是为了响应社区需求而引入的。传统的 Text2SQL 需要模型微调，这在企业环境中与 RAG 或 Agent 组件一起使用时，会显著增加部署和维护成本。RAGFlow 基于 RAG 的 Text2SQL 利用现有的（已连接的）大型语言模型（LLM），能够与其他 RAG/Agent 组件无缝集成，而无需额外的微调模型。

RAGFlow 中 text2sql 的实现原理基于 RAG，需要准备一个用于生成 Text2SQL 提示的知识库，其中包含各种自然语言转换为 SQL 语句的示例。用户查询首先发送到该知识库以检索类似示例。然后将检索到的示例连接到 LLM 的提示中，以生成最终的 SQL 语句。生成的 SQL 直接用于查询数据库。如果返回的结果不正确，或者更糟糕的是，没有检索到任何内容，则生成的 SQL 将被视为不正确，并且将再次调用 LLM 以重新生成 SQL 语句，直到达到预定义的上限。

3.2 RAGFlow 中使用的三种知识库

在提供的 DB Assistant 模板中，RAGFlow 使用三种类型的知识库来确保 Text2SQL 的性能：

DDL 知识库：LLM 需要准确的 DDL（数据定义语言）数据来生成 SQL 语句，例如表结构和字段信息。DDL 知识库保存正确的 DDL 数据，以便有效地查询数据库。
Q->SQL 知识库：自然语言及其对应的 SQL 语句对的示例可以提高生成 SQL 语句的质量。Q->SQL 知识库存储此类语句对。
数据库描述知识库：该知识库包含有关查询数据库的准确信息，包括但不限于数据库表的含义以及这些表中不同字段的重要性。借助数据库的详细描述，大型语言模型可以更准确地将用户问题转换为 SQL 语句。

所有三个知识库的示例都可以在以下链接中找到：https://huggingface.co/datasets/InfiniFlow/text2sql/tree/main

3.3 RAGFlow 中的循环参数和 TopN 参数

循环参数：Text2SQL 在 RAGFlow 中具有自动反射功能。如果生成的 SQL 被认为能够正确查询，则结果将直接返回。但是，如果查询失败，RAGFlow 的 Text2SQL 将根据数据库返回的错误信息自动更正 SQL 语句并重试查询。这个过程——查询失败、更正 SQL 语句和重试——将继续迭代，直到达到循环参数设置的最大限制。如果达到此最大值，Text2SQL 进程将终止，不会再次尝试。
TopN 参数：此参数限制查询中返回的记录数，因为查询通常涉及大量记录。

四、微调方法

4.1 概念和作用

尽管像 GPT-4 这样的大型语言模型 (LLM) 使用 RAG、ICL 和 CoT 等提示方法在 Text-to-SQL 任务中取得了显著成功，但重要的是要注意，这些低成本的提示方法与微调 LLM 之间存在一定差距。同时，使用 API 调用模型时经常会出现对隐私问题的担忧。因此，我们也应该关注微调 LLM 在 Text-to-SQL 任务中的应用。微调是针对特定领域和任务，在预训练模型的基础上，使用新的数据集进行训练，以提高模型在该领域的表现。

4.2 常用的微调方法

Fully Fine-tuning (FFT)：对模型的所有参数进行微调。
Parameter-Efficient Fine-tuning (PEFT)：仅微调模型的一小部分参数，例如 LoRA 和 QLoRA。

4.3 优缺点

4.3.1 Fully Fine-tuning (FFT)

优点
可以充分利用新的数据集来提高模型在特定任务上的性能。
缺点
计算成本高，需要大量的计算资源和时间。
容易出现过拟合现象，导致模型在未见过的数据上表现不佳。
容易出现灾难性遗忘，即在学习新任务时，模型忘记了之前学习过的知识。

4.3.2 Parameter-Efficient Fine-tuning (PEFT)

优点
训练效率高，降低了训练成本。
降低了过拟合的风险。
相比 FFT 更不容易出现灾难性遗忘。
缺点
性能提升可能不如 FFT 明显。

总结

微调方法是提高 LLM 在特定任务上性能的重要手段。FFT 和 PEFT 是两种常用的微调方法，各有优缺点。选择哪种方法取决于具体的任务需求和可用的计算资源。

五、总结

5.1 提示工程的优势和局限性

提示工程已成为将 LLM 应用于 Text-to-SQL 任务的主要方法之一。其优势在于：

无需训练: 利用 LLM 的指令遵循能力，仅通过设计适当的提示，就可以完成 Text-to-SQL 任务，无需额外的训练。
易于迁移: 提示工程方法使得 LLM 能够轻松地迁移到不同的数据库环境中，而无需进行额外的训练。
持续改进: 全球社区正在不断改进 LLM，包括扩大模型规模、创建新的提示方法和生成更高质量的数据集，这将持续推动基于提示工程的 Text-to-SQL 方法取得新的突破。

然而，提示工程也存在一些局限性：

性能限制: 尽管提示工程方法取得了显著进展，但其性能仍与微调方法存在一定差距。
提示词设计复杂: 对于复杂的 Text-to-SQL 任务，需要精心设计提示词，包括问题表示、模式链接和知识增强等多个方面。
上下文长度限制: LLM 的上下文长度有限，这限制了提示词中可以包含的信息量，尤其是在处理复杂模式时。

5.2 未来研究方向

5.2.1 隐私问题

将私有数据发送到 LLM API 提供商可能会导致商业机密泄露。未来的研究可以探索如何在保护隐私的前提下利用 LLM 进行 Text-to-SQL。一种可能的解决方案是在本地部署开源 LLM 并进行微调，但这需要权衡模型性能和其他能力。

5.2.2 自主代理

受大规模语料库训练的 LLM 具有强大的泛化能力，可以利用 ReAct 框架构建 LLM 驱动的自主代理。这些代理可以自动完成 Text-to-SQL 任务，并通过与环境交互来学习和改进。相较于传统的流水线系统，自主代理具有更高的灵活性和可探索性。未来的研究可以探索如何将自主代理应用于 Text-to-SQL，以实现更智能化和自动化的 SQL 生成。

5.2.3 复杂模式

现实世界的 Text-to-SQL 任务通常涉及复杂的表模式，这给 LLM 带来了挑战。未来研究需要开发新的方法来处理复杂模式，例如：

改进模式链接技术: 更准确地识别与自然语言查询相关的表和列。
开发新的模型架构: 能够处理更长的上下文信息和更复杂的模式结构。

5.2.4 基准测试

现有的 Text-to-SQL 基准数据集大多包含简单的表模式，无法充分反映现实世界场景的复杂性。未来研究需要构建更具挑战性和现实性的基准数据集，以推动 Text-to-SQL 领域的进一步发展。这些数据集应包含：

复杂模式: 包含大量表和列，以及复杂的模式结构。
现实场景: 模拟真实世界的 Text-to-SQL 应用场景，例如包含噪音和歧义的自然语言查询。

5.2.5 领域知识

LLM 在处理特定领域的 Text-to-SQL 任务时，需要具备相关的领域知识。未来研究可以探索如何将领域知识融入 LLM，例如：

构建领域知识库: 为 RAG 方法提供高质量的领域知识。
开发新的微调方法: 能够有效地将领域知识融入 LLM，同时避免灾难性遗忘。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述