Langchain读取数据库

LangChain 提供了多种内置工具和模块化组件，能够轻松连接大语言模型（LLM）与各类结构化数据源。针对数据库交互，LangChain 主要提供以下核心能力：

1. 传统关系型数据库（SQL）交互

LangChain 提供了SQLDatabaseChain等实用工具，能够将用户的自然语言问题自动翻译成 SQL 命令并执行。

• 通用 SQL 数据库：支持 PostgreSQL、MySQL 等主流数据库。例如，你可以配置该链连接数据库，让用户用自然语言提问（如“上个月销售额是多少”），系统会自动生成 SQL、执行查询并将结果以可读格式返回。
• Databricks SQL 代理：针对 Databricks 平台，LangChain 提供了SQLDatabase包装器和Databricks SQL 代理，允许用户直接与 Unity Catalog 中的指定架构交互，生成数据洞察（注：该代理仅支持查询表，不支持创建表）。

2. 向量数据库（Vector Store）交互

对于需要语义搜索或构建 RAG（检索增强生成）系统的场景，LangChain 支持多种文档导向的向量数据库（如 Chroma），用于存储和检索文档嵌入。

• Azure Database for PostgreSQL：支持通过pgvector扩展，在单个数据库中同时管理关系数据和数百万个向量嵌入。LangChain 提供了专门的AzurePGVectorStore，支持使用余弦距离、L2 距离等算法执行相似性搜索。
• Databricks Vector Search：作为无服务器向量数据库，可通过DatabricksVectorSearch组件集成，支持从 Delta 表自动创建向量索引并进行相似性查询。

3. 图数据库（Graph Database）交互

针对知识图谱等复杂关系数据，LangChain 同样提供了专门的集成方案。

• Kùzu 图数据库：这是一个可嵌入的图数据库，LangChain 提供了KuzuGraph和KuzuQAChain。通过LLMGraphTransformer，你可以利用 LLM 从非结构化文本中提取节点和关系并写入图数据库，随后通过 Text2Cypher 管道使用自然语言查询图数据。

4. 文档型/NoSQL 数据库交互

LangChain 也支持通过文档加载器（Document Loaders）读取非结构化或半结构化数据。

• Notion 数据库：通过NotionDBLoader，可以连接 Notion 数据库，检索页面内容及其元数据，并将其转换为 LangChain 的 Document 对象列表，方便后续处理。
• MongoDB：LangChain 提供了与 MongoDB Atlas 的集成方案，支持在 MongoDB 中实现 LLM 缓存、图存储等功能。

5. 大数据框架交互

• Spark DataFrame 代理：LangChain 中的 Spark DataFrame 代理允许 LLM 直接与 PySpark 数据帧进行交互，针对大数据场景下的问题解答进行了专门优化。

此外，开发者还可以基于 SQLAlchemy 等 ORM 库编写自定义的数据库包装器，以扩展 LangChain 的数据库支持范围。

你主要想用哪种数据库？我可以给出对应的接入示例：

1. PostgreSQL/MySQL（关系型，适合结构化业务数据）
2. Chroma/PGVector（向量数据库，适合RAG知识库）
3. MongoDB（文档型，适合灵活Schema）

一、PostgreSQL/MySQL（关系型，适合结构化业务数据）

接入 PostgreSQL 或 MySQL 等关系型数据库，是让大模型（LLM）直接理解和分析结构化业务数据（如订单、用户表、财务报表）的关键步骤。在 LangChain 中，最核心且常用的方式是使用SQLDatabaseChain或SQL Agent，它们能够充当“翻译官”，将用户的自然语言自动转换为 SQL 查询语句，执行后并把结果总结为人类可读的文本。

以下是接入并实现自然语言查询的完整实战指南：

第一步：安装核心依赖

除了 LangChain 核心库和 LLM 驱动外，还需要安装对应数据库的 Python 连接器：

pipinstalllangchain langchain-openai mysql-connector-python psycopg2-binary

第二步：连接数据库并构建查询链

版本一：使用Chain实现基础查询

这里以 MySQL 为例（PostgreSQL 的连接字符串格式略有不同，但用法一致）。

importosfromlangchain_openaiimportChatOpenAIfromlangchain.sql_databaseimportSQLDatabasefromlangchain.chainsimportcreate_sql_query_chain# 1. 建立数据库连接# MySQL 格式: mysql+mysqlconnector://user:password@host:port/database# PostgreSQL 格式: postgresql://user:password@host:port/databasedb=SQLDatabase.from_uri("mysql+mysqlconnector://root:yourpassword@localhost:3306/mydatabase")# 2. 初始化 LLMllm=ChatOpenAI(model="gpt-4o-mini",temperature=0)# 3. 创建 SQL 查询链（推荐使用新版 API）chain=create_sql_query_chain(llm,db)# 4. 运行自然语言查询response=chain.invoke({"question":"上个月销售额最高的产品是什么？"})print(response)

版本二：使用 SQL Agent 替代 Chain

在实际生产环境中，强烈建议使用SQL Agent而不是基础的 SQL Chain。Agent 具备自我纠错能力，如果生成的 SQL 语法报错，它会自动查看错误信息并重新生成正确的查询。要将基础的 SQL 查询链升级为使用“执行 SQL 语句工具”的 Agent 架构，核心是引入SQLDatabaseToolkit。这个工具包不仅包含了执行 SQL 的工具，还内置了查询检查器、错误修复等辅助工具，让 Agent 具备自我纠错能力。以下是改进后的代码：

importosfromlangchain_openaiimportChatOpenAIfromlangchain.sql_databaseimportSQLDatabasefromlangchain_community.agent_toolkitsimportSQLDatabaseToolkitfromlangchain.agentsimportcreate_sql_agent# 1. 建立数据库连接db=SQLDatabase.from_uri("mysql+mysqlconnector://root:yourpassword@localhost:3306/mydatabase")# 2. 初始化 LLMllm=ChatOpenAI(model="gpt-4o-mini",temperature=0)# 3. 创建 SQL 数据库工具包# 该工具包包含: sql_db_query(执行SQL), sql_db_schema(获取表结构), sql_db_list_tables 等工具toolkit=SQLDatabaseToolkit(db=db,llm=llm)# 4. 创建 SQL Agentagent=create_sql_agent(llm=llm,toolkit=toolkit,verbose=True,# 开启详细日志，方便观察 Agent 的思考和工具调用过程agent_executor_kwargs={"handle_parsing_errors":True}# 自动处理解析错误)# 5. 运行自然语言查询result=agent.invoke({"input":"上个月销售额最高的产品是什么？"})print(result["output"])

核心改进点

1. 工具化执行：Agent 会先调用sql_db_schema获取表结构，再生成 SQL，最后通过sql_db_query工具执行。如果执行报错，Agent 会自动读取错误信息并重新生成 SQL。
2. 安全隔离：工具执行机制天然支持权限控制，你可以在数据库层面为连接账号设置只读权限，防止 LLM 执行破坏性操作。
3. 可扩展性：你可以向toolkit中注入自定义工具，比如在执行 SQL 前先进行业务规则校验。

这套代码已经可以直接替换你原来的链式调用，在生产环境中表现会稳定得多。

版本三：加上提示词限制

给 SQL Agent 加上提示词，关键是告诉它业务背景、表结构含义和输出规范，这样它生成的 SQL 和最终回答才会更准、更符合业务需求。

以下是加入自定义系统提示词的完整代码：

importosfromlangchain_openaiimportChatOpenAIfromlangchain.sql_databaseimportSQLDatabasefromlangchain_community.agent_toolkitsimportSQLDatabaseToolkitfromlangchain.agentsimportcreate_sql_agent# 1. 建立数据库连接db=SQLDatabase.from_uri("mysql+mysqlconnector://root:yourpassword@localhost:3306/mydatabase")# 2. 初始化 LLMllm=ChatOpenAI(model="gpt-4o-mini",temperature=0)# 3. 创建 SQL 数据库工具包toolkit=SQLDatabaseToolkit(db=db,llm=llm)# 4. 自定义系统提示词（核心改进）SYSTEM_PROMPT="""你是一个专业的电商数据分析师。请根据用户的自然语言问题，生成并执行 MySQL 查询语句。 【业务背景】 - 数据库包含：users（用户表）、orders（订单表）、products（商品表） - orders 表中的 status 字段：'pending'=待支付, 'paid'=已支付, 'shipped'=已发货, 'completed'=已完成 - 所有金额字段单位为：人民币（元） 【执行规范】 1. 优先使用 `sql_db_schema` 工具确认表结构，不要凭空猜测字段名 2. 生成的 SQL 必须使用标准 MySQL 语法 3. 涉及时间查询时，默认使用当前系统时间作为基准 4. 如果查询无结果，请明确告知用户，不要编造数据 【回答规范】 - 直接给出清晰、简洁的业务结论，不要输出 SQL 语句本身 - 如果涉及金额，保留两位小数并加上“元”单位 - 如果涉及多条记录，最多展示前 5 条，并告知总数量 """# 5. 创建 SQL Agent 并注入提示词agent=create_sql_agent(llm=llm,toolkit=toolkit,verbose=True,agent_executor_kwargs={"handle_parsing_errors":True},system_message=SYSTEM_PROMPT# 注入自定义提示词)# 6. 运行自然语言查询result=agent.invoke({"input":"上个月销售额最高的产品是什么？"})print(result["output"])

提示词设计要点

1. 业务背景前置：明确告诉 Agent 表名、关键字段的枚举值（如订单状态），避免它生成WHERE status = '已发货'这种中文匹配的错误 SQL。
2. 执行规范约束：强制它先查表结构再生成 SQL，从根源上减少字段名幻觉。
3. 回答规范兜底：防止 Agent 把 SQL 代码直接吐给用户，同时规范了金额、列表的展示格式，让最终输出可以直接面向终端用户。

你可以根据实际业务，把【业务背景】里的表结构和字段含义替换成你真实的数据库字典，Agent 的准确率会大幅提升。

⚠️ 生产环境避坑指南

1. 防止大模型“自作聪明”：大模型有时为了“友好”，会将具体的数据库记录（如具体的患者ID或订单号）自动总结为数量（如“共找到10条记录”）。如果遇到这种情况，需要在 Prompt 中明确强调：“请直接返回查询到的原始字段值，不要进行总结或解释。”
2. 安全与权限控制：务必为 LLM 连接数据库使用只读账号，或者通过自定义DatabaseQueryTool限制 LLM 只能查询特定的表，防止大模型执行危险的DROP或UPDATE操作。
3. 开启 Verbose 模式：在调试阶段，将verbose=True打开，这样你可以在控制台清晰地看到大模型生成的真实 SQL 语句，便于排查逻辑错误。

现在你的 AI 已经能够直接“看懂”你的业务数据库了！接下来你想怎么升级？

1. 结合 LangGraph：将数据库查询作为一个工具节点，整合到之前的多智能体客服系统中（比如用户问“我的订单到哪了”，Agent 自动查库并回复）。
2. 结合 RAG 知识库：实现“结构化数据（SQL）”与“非结构化文档（PDF/TXT）”的混合检索，让 AI 既能查表，又能查文档。

二、Chroma/PGVector（向量数据库，适合RAG知识库）

构建 RAG（检索增强生成）系统是让大模型“有据可查”、解决知识盲区与幻觉问题的核心方案。在 LangChain 中，Chroma 和 PGVector 是两种最常用的向量数据库选择：Chroma 以轻量、易用著称，非常适合快速原型开发和本地测试；而 PGVector 依托于 PostgreSQL，更适合需要与业务关系型数据共存、追求高并发与生产级稳定性的企业场景。

下面为你分别梳理这两种向量数据库的接入与实战指南。

方案一：Chroma 向量数据库（轻量级、快速上手）

Chroma 是一个以 AI 为原生的开源向量数据库，无需额外配置数据库服务，只需指定本地目录即可实现数据的持久化存储。

1. 安装依赖

pipinstall-qU"langchain-chroma>=0.1.2"langchain-openai

2. 核心实战代码

fromlangchain_chromaimportChromafromlangchain_openaiimportOpenAIEmbeddingsfromlangchain_core.documentsimportDocument# 初始化嵌入模型embeddings=OpenAIEmbeddings()# 初始化向量存储并指定本地持久化目录vectorstore=Chroma(collection_name="my_docs",embedding_function=embeddings,persist_directory="./chroma_langchain_db"# 数据将保存在本地此目录下)# 添加文档documents=[Document(page_content="LangGraph 支持状态机和人工介入。",metadata={"source":"docs"}),Document(page_content="Chroma 是一个轻量级的向量数据库。",metadata={"source":"docs"})]vectorstore.add_documents(documents)# 执行相似性搜索results=vectorstore.similarity_search("LangGraph 有什么功能？",k=1)print(results.page_content)

方案二：PGVector 向量数据库（生产级、企业首选）

如果你的系统已有 PostgreSQL 数据库，使用 PGVector 是极佳的选择。它允许你在同一个数据库中同时管理结构化业务数据和向量数据。

1. 安装依赖

pipinstall-qUlangchain-postgres langchain-openai

2. 核心实战代码

fromlangchain_postgresimportPGVector,PGEnginefromlangchain_openaiimportOpenAIEmbeddingsfromlangchain_core.documentsimportDocument# 1. 配置 PostgreSQL 连接字符串（需使用 psycopg3 驱动）CONNECTION_STRING="postgresql+psycopg://user:password@localhost:5432/mydatabase"VECTOR_SIZE=1536# 根据你的嵌入模型维度设置，如 OpenAI 为 1536# 2. 初始化引擎与向量存储engine=PGEngine.from_connection_string(url=CONNECTION_STRING)embedding=OpenAIEmbeddings()# 初始化表结构（如果表不存在会自动创建）engine.init_vectorstore_table(table_name="enterprise_docs",vector_size=VECTOR_SIZE)store=PGVector.create_sync(engine=engine,table_name="enterprise_docs",embedding_service=embedding,)# 3. 插入文档并搜索docs=[Document(page_content="PostgreSQL 支持混合搜索和元数据过滤。")]store.add_documents(docs)search_results=store.similarity_search("数据库有什么高级功能？",k=1)print(search_results.page_content)

💡 生产环境避坑指南

1. 向量维度一致性：在使用 PGVector 时，务必确保建表时的vector_size与你的嵌入模型维度严格一致。如果在运行中途更换了嵌入模型，通常需要清空旧表重新生成，否则会导致维度不匹配的报错。
2. 数据持久化：使用 Chroma 时，务必在初始化时传入persist_directory，并在添加数据后调用vectorstore.persist()（或在初始化时配置自动同步），否则重启服务后数据会丢失。
3. 混合检索优化：如果追求更高的检索准确率，PGVector 支持混合搜索（Hybrid Search），可以结合关键词检索与向量检索，通过倒数排名融合（RRF）等算法返回更相关的结果。

至此，你的 AI 已经具备了强大的外部知识检索能力！接下来你想怎么升级这套 RAG 系统？

1. 结合 LangGraph 构建 RAG Agent：让 AI 自主判断是否需要检索知识库，甚至支持多步检索与自我反思。
2. 优化检索效果：引入重排序（Rerank）、元数据过滤（Metadata Filtering）或混合检索，大幅提升回答准确率。

三、MongoDB（文档型，适合灵活Schema）

MongoDB 作为典型的文档型 NoSQL 数据库，凭借其灵活的 Schema 设计，非常适合处理复杂、半结构化以及快速演变的非结构化数据（如用户画像、物联网信号、多变的业务日志等）。在 LangChain 生态中，MongoDB 主要作为向量数据库（Vector Store）被深度集成，用于构建 RAG（检索增强生成）应用。

以下是 MongoDB 在 LangChain 中的接入与实战指南：

1. 安装核心依赖

LangChain 提供了专门的 MongoDB 集成包。运行以下命令进行安装：

pipinstalllangchain-mongodb

2. 核心实战代码（向量存储与检索）

通过MongoDBAtlasVectorSearch组件，你可以快速将 MongoDB 实例化为向量数据库，并支持手动或自动嵌入。

fromlangchain_mongodb.vectorstoresimportMongoDBAtlasVectorSearchfromlangchain_voyageaiimportVoyageAIEmbeddings# 也可替换为 OpenAIEmbeddings 等fromlangchain_core.documentsimportDocument# 1. 初始化嵌入模型embedding=VoyageAIEmbeddings()# 2. 使用连接字符串实例化向量存储# 格式示例: mongodb+srv://<username>:<password>@<cluster>.mongodb.netvector_store=MongoDBAtlasVectorSearch.from_connection_string(connection_string="<你的MongoDB连接字符串>",namespace="my_db.my_collection",# 指定数据库名.集合名embedding=embedding,index_name="vector_index"# MongoDB 向量搜索索引名称)# 3. 写入文档（系统会自动生成嵌入向量）docs=[Document(page_content="MongoDB 支持灵活的文档模型，适合处理复杂嵌套数据。",metadata={"category":"tech"}),Document(page_content="LangChain 提供了丰富的工具链来连接各类数据库。",metadata={"category":"ai"})]vector_store.add_documents(docs)# 4. 执行语义相似性搜索results=vector_store.similarity_search("如何连接非关系型数据库？",k=1)print(results.page_content)

3. 进阶能力：Self-Querying（自查询检索）

MongoDB 的文档模型天然适合存储丰富的元数据（Metadata）。LangChain 结合 MongoDB 支持自查询检索，允许大模型在处理自然语言时，自动提取过滤条件（如年份、分类、评分等），并在执行向量搜索前进行精准的元数据预过滤。这在处理海量异构数据时极为高效。

💡 生产环境避坑与架构建议

1. 索引前置要求：在使用MongoDBAtlasVectorSearch之前，必须确保在 MongoDB 中提前创建好对应的 Vector Search Index，否则检索会报错。
2. Schema 灵活性的双刃剑：与 SQL 数据库不同，MongoDB 没有严格的表结构约束。如果让 LLM 直接生成查询语句，极易出现“幻觉”（例如查询不存在的字段）。在生产中，建议为 LLM 提供明确的 Schema 描述（Metadata Layer）作为上下文，并在执行前增加字段存在性校验。
3. 混合数据架构：MongoDB 现已支持多种数据类型（结构化、时序、向量、图）。在实际业务中，你可以将业务文档与向量嵌入存储在同一个集合中，利用其灵活的嵌套结构实现“业务数据 + 语义检索”的一体化。

至此，你已经掌握了 LangChain 中主流数据库（SQL、Vector、NoSQL）的接入方案！接下来你想怎么升级这套系统？

1. 构建混合检索 Agent：结合 SQL（查订单）+ MongoDB（查文档）+ Tavily（搜新闻），让 AI 能够跨库联合推理。
2. 生产级数据管道：探讨如何结合 LangChain 的 Document Loaders 和 Text Splitters，将海量企业文档自动化清洗并灌入 MongoDB 向量库。