大模型 LLM 在 Text2SQL 中的应用实践

3.2 Indexes

索引和外部数据进行集成，用于从外部数据获取答案。主要的步骤包括：

• 通过 Document Loaders 加载各种不同类型的数据源
• 通过 Text Splitters 进行文本语义分割
• 通过 Vectorstore 进行非结构化数据的向量存储
• 通过 Retriever 进行文档数据检索

3.3 Chains

LangChain 通过 chain 将各个组件进行链接，以及 chain 之间进行链接，用于简化复杂应用程序的实现。其中主要有 LLMChain、SQLDatabase Chain 以及 Sequential Chain。

3.3.1 LLMChain

最基本的链为 LLMChain，由 PromptTemplate、LLM 和 OutputParser 组成。LLM 的输出一般为文本，OutputParser 用于让 LLM 结构化输出并进行结果解析，方便后续的调用。

其实现原理包含三步：

1. 输入问题
2. 拼接提示，根据提示模板将问题转化为提示
3. 模型推理，输出答案

代码如下所示：

from langchain.prompts import PromptTemplate
from langchain.chains import LLMChain
from langchain import OpenAI
import os

os.environ["OPENAI_API_KEY"] = "Your openai key"

# 定义模型
llm = OpenAI(temperature=0)

# 定义提示模板
prompt = PromptTemplate(
    input_variables=["question"], 
    template="""简洁和专业的来回答用户的问题。
如果无法从中得到答案，请说'根据已知信息无法回答该问题'或'没有提供足够的相关信息'，不允许在答案中添加编造成分，答案请使用中文。
问题是：{question}"""
)

# 定义 chain
chain = LLMChain(llm=llm, prompt=prompt, verbose=True)

# 执行 chain
print(chain.run("如何开展数据治理"))

3.3.2 SQLDatabaseChain

SQLDatabaseChain 能够通过模型自动生成 SQL 并执行，其实现原理如图所示，包含如下过程：

1. 输入问题：用户提出自然语言问题。
2. 获取数据库 Schema：Schema 包含数据库所有表的建表语句和数据示例，LangChain 支持多种关系型数据库，包括 MariaDB、MySQL、SQLite、ClickHouse、PrestoDB 等。
3. 拼接提示：根据提示模板将问题、数据库 Schema 转化为提示，并且提示中包含指示，要求模型在理解问题和数据库 Schema 的基础上，能够按一定的格式输出查询 SQL、查询结果和问题答案等。
4. 模型推理：这一步预期模型根据问题、数据库 Schema 推理、输出的答案中包含查询 SQL，并从中提取出查询 SQL。
5. 执行查询 SQL：从数据库中获取查询结果。
6. 拼接提示：和上一次拼接的提示基本一致，只是其中的提示中包含了前两步已获取的查询 SQL、查询结果。
7. 模型推理：这一步预期模型根据问题、数据库 Schema、查询 SQL 和查询结果推理出最终的问题答案。

3.3.3 SequentialChain

SequentialChains 是按预定义顺序执行的链。SimpleSequentialChain 为顺序链的最简单形式，其中每个步骤都有一个单一的输入/输出，一个步骤的输出是下一个步骤的输入。SequentialChain 为顺序链更通用的形式，允许多个输入/输出。

3.4 Memory

正常情况下 Chain 无状态的，每次交互都是独立的，无法知道之前历史交互的信息。LangChain 使用 Memory 组件保存和管理历史消息，这样可以跨多轮进行对话，在当前会话中保留历史会话的上下文。Memory 组件支持多种存储介质，可以与 Mongo、Redis、SQLite 等进行集成，以及简单直接形式就是 Buffer Memory。

3.5 Agent

Agent 字面含义就是代理，如果说 LLM 是大脑，Agent 就是代理大脑使用 Tools。目前的大模型一般都存在知识过时、逻辑计算能力低等问题，通过 Agent 访问工具，可以去解决这些问题。目前这个领域特别活跃，诞生了类似 AutoGPT、BabyAGI、AgentGPT 等一堆优秀的项目。传统使用 LLM，需要给定 Prompt 一步一步地达成目标，通过 Agent 是给定目标，其会自动规划并达到目标。

四、基于 SQLDatabaseChain 的 Text2SQL 实践

4.1 简介

LangChain 提供基于 LLM 的 SQLDatabaseChain，可以利用 LLM 的能力将自然语言的 query 转化为 SQL，连接 DB 进行查询，并利用 LLM 来组装润色结果，返回最终 answer。

在后台，LangChain 使用 SQLAlchemy 连接到 SQL 数据库。因此，SQLDatabaseChain 可以与 SQLAlchemy 支持的任何 SQL 方言一起使用，例如 MS SQL、MySQL、MariaDB、PostgreSQL、Oracle 和 SQLite。

4.2 数据准备

本案例使用 SQLite 和示例 Chinook 数据库，用户可按照 https://database.guide/2-sample-databases-sqlite/ 上的说明进行设置。Chinook 表示一个数字多媒体商店，包含了顾客（Customer）、雇员（Employee）、歌曲（Track）、订单（Invoice）及其相关的表和数据，数据模型如下图所示。

4.3 实践过程

需求：测试中文提问'总共有多少员工？'，即英文提问'How many employees are there?'。

期望：模型先给出查询 Employee 表记录数的 SQL，再根据查询结果给出最终的答案。

（1）测试中文提问

代码如下所示：

from langchain.llms import OpenAI
from langchain.utilities import SQLDatabase
from langchain_experimental.sql import SQLDatabaseChain
import os

os.environ["OPENAI_API_KEY"] = "Your openai key"

db = SQLDatabase.from_uri("sqlite:///..../Chinook.db")
llm = OpenAI(temperature=0, verbose=True)
db_chain = SQLDatabaseChain.from_llm(llm, db, verbose=True)
result = db_chain.run("总共有多少员工?")
print(result)

输出结果如下：

这里我们使用商业化的 OpenAI，并将其 temperature 设为 0，因为查询 DB 不太需要创造性和多样性。从返回的过程来看，自然语言被翻译成了 SQL，得到查询结果后，解析包装结果，最终返回我们可以理解的答案。这里 LLM 成功将'总共'转成 select count(*)，并准确地识别出表名，且最终组装出正确的结果。

注意：对于数据敏感项目，可以在 SQLDatabaseChain 初始化中指定 return_direct=True，以直接返回 SQL 查询的输出，而无需任何其他格式设置。这样可以防止 LLM 看到数据库中的任何内容。但请注意，默认情况下，LLM 仍然可以访问数据库方案（即所用方言、表名和列名）。

（2）测试英文提问

也可以得到我们想要的结果：

通过上例，我们可以借助 LangChain 提供的 SQLDatabaseChain，轻松地连接 LLM 与 Database，自然语言的方式输入，自然语言的方式输出，借助 LLM 的强大能力来理解问题、生成 SQL 查询数据并输出结果。

五、后续计划与最佳实践

随着大模型的发展，LangChain 是目前最火的 LLM 开发框架之一，能和外部数据源交互、能集成各种常用的组件等等，大大降低了 LLM 应用开发的门槛。基于 SQLDatabaseChain 实现的 Text2SQL 只是最基础的实践方式，但对于逻辑复杂的查询在稳定性、可靠性、安全性方面可能无法达到预期，比如输出幻觉问题、数据安全问题。

5.1 常见问题与解决方案

1. 幻觉问题：模型可能会生成不存在的表名或字段名。建议引入 Few-Shot Prompting，在 Prompt 中加入几个标准的 SQL 示例，约束模型的生成空间。
2. 权限控制：LLM 生成的 SQL 可能包含 DROP 或 DELETE 操作。建议在应用层增加 SQL 语法白名单校验，或者使用只读账号连接数据库。
3. 性能优化：对于复杂查询，LLM 生成的 SQL 可能效率低下。建议引入 SQL 解释器分析执行计划，必要时人工介入优化。

5.2 总结

总之，实现高稳定、高可靠的基于 LLM 的应用，是一个持续改进的过程，是一个多种技术相结合的过程。未来我们将继续探索更高效的 Schema 压缩策略以及更精准的 Prompt 工程方法，以提升 Text2SQL 在实际生产环境中的可用性。