LangChain 中文入门：概念与常见实战

LangChain 是一个用于构建大语言模型应用的开发框架。它把模型调用、文档加载、文本切分、向量检索、链式调用、工具使用和记忆管理等能力封装起来，让开发者更容易搭建问答、摘要、搜索和 Agent 应用。

如果只调用一次模型，直接使用模型 API 就够了。LangChain 更适合处理多步骤任务，比如读取文档、切分文本、建立索引、检索相关内容，再把检索结果交给模型回答。

LangChain 适合做什么

常见场景包括：

单次问答。
联网搜索并回答。
总结长文本。
本地知识库问答。
构建向量索引。
YouTube 视频问答。
工具调用。
结构化输出。
SQL 查询。

这些场景的共同点是：模型不是孤立工作，而是要和数据、工具、检索结果或外部系统配合。

基础概念

Loader 加载器

Loader 用来读取外部数据。数据来源可以是文本文件、网页、PDF、视频字幕或数据库。

它的作用是把不同来源的数据统一加载进 LangChain。

Document 文档

Document 是 LangChain 内部常用的数据结构。它通常包含两部分：

page_content：正文内容。
metadata：来源、标题、路径等元信息。

Text Splitter 文本分割器

长文档不能直接塞给模型。Text Splitter 会把长文本切成较小片段，方便后续检索和问答。

切分时要平衡两个问题：片段太大，检索不准；片段太小，上下文不完整。

Vectorstore 向量数据库

Vectorstore 用来保存文本片段的向量表示。用户提问时，系统会把问题也转成向量，再检索相似片段。

常见用途是本地知识库问答。

Chain 链

Chain 把多个步骤串起来。比如先把问题整理成查询语句，再检索资料，最后让模型生成回答。

Agent 代理

Agent 可以根据任务选择工具。它不只是按固定流程执行，而是会判断下一步该搜索、计算、查询还是直接回答。

Embedding

Embedding 是把文本转换成向量的过程。向量越接近，通常表示语义越相近。

图 1：LangChain 常见组件关系

flowchart TD
  A["外部数据"] --> B["Loader"]
  B --> C["Document"]
  C --> D["Text Splitter"]
  D --> E["Embedding"]
  E --> F["Vectorstore"]
  G["用户问题"] --> H["检索"]
  F --> H
  H --> I["模型生成回答"]

实战一：单次问答

单次问答是最基础的模型调用。

from langchain.llms import OpenAI

llm = OpenAI(temperature=0)
result = llm("Explain LangChain in one sentence.")
print(result)

这种方式适合简单问答，但无法处理外部文档和复杂工具调用。

实战二：联网搜索

Agent 可以结合搜索工具处理需要外部信息的问题。

from langchain.agents import load_tools, initialize_agent
from langchain.llms import OpenAI

llm = OpenAI(temperature=0)
tools = load_tools(["serpapi"], llm=llm)

agent = initialize_agent(
    tools,
    llm,
    agent="zero-shot-react-description",
    verbose=True
)

agent.run("What's the date today? What great events have taken place today in history?")

开启 verbose=True 后，可以看到 Agent 如何判断任务、选择搜索工具、调整查询并生成回答。

实战三：总结长文本

长文本通常需要先切分，再分段总结，最后合并结果。

from langchain.text_splitter import CharacterTextSplitter

text_splitter = CharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=100
)

docs = text_splitter.create_documents([long_text])

长文本摘要的关键是切分策略。chunk_overlap 可以保留片段之间的连续性，减少上下文断裂。

实战四：本地知识库问答

本地知识库问答通常包括五步：

加载文档。
切分文本。
生成 Embedding。
写入向量数据库。
根据问题检索并回答。

文档 -> 切分 -> 向量化 -> 检索 -> 模型回答

这种结构适合 FAQ、产品文档、内部手册和知识库问答。

实战五：构建向量索引

向量索引可以使用本地方案，也可以使用在线向量数据库。

方案	特点
Chroma	适合本地持久化和快速实验
Pinecone	适合在线向量检索服务

本地实验可以先从 Chroma 开始，确认检索效果后再考虑更复杂的部署方案。

实战六：视频问答

YouTube 视频问答的思路是先获取字幕或转写文本，再按文档问答流程处理。

视频字幕 -> 文本切分 -> 向量化 -> 检索相关片段 -> 生成回答

这类应用的效果取决于字幕质量、切分方式和检索结果。

实战七：工具调用

Agent 可以连接工具。例如搜索、计算器、接口查询、自定义函数等。

工具调用适合处理模型自身不能完成的任务：

查实时信息。
做精确计算。
查询数据库。
调用业务接口。

工具越多，越要写清楚每个工具的用途和触发条件。

拓展示例

执行多个 Chain

多个 Chain 可以组合成更复杂的处理流程。单个 Chain 只负责一个明确步骤，多个 Chain 串起来后，就能处理“先加工输入，再检索，再生成结果”的任务。

一个常见用法是先把用户问题转换成更适合检索的查询，再从知识库中取回相关内容，最后生成回答。

用户问题
-> 查询优化 Chain
-> 检索 Chain
-> 回答生成 Chain
-> 最终答案

这种方式适合企业知识库、技术文档问答和客服 FAQ。它的好处是每一步都比较清楚，出问题时也更容易定位：是查询转换不准，还是检索结果不对，还是最后生成回答时遗漏了重点。

结构化输出

当模型结果要交给程序继续处理时，结构化输出比自然语言更可靠。比如页面抽取、信息分类、工单生成、简历解析，都需要固定字段。

可以把输出格式提前写清楚：

{
  "title": "文章标题",
  "summary": "摘要",
  "keywords": ["关键词1", "关键词2"],
  "risk_level": "low | medium | high"
}

结构化输出要注意两点。

第一，字段不要太多。字段越多，模型越容易漏项或混淆。第二，字段含义要明确。比如 risk_level 要说明可选值，否则模型可能输出“较高”“严重”“高风险”等不一致结果。

爬取网页并输出 JSON

网页抽取任务适合把非结构化网页整理成固定字段。比如从上市公司简介页面中抽取公司名称、英文名、发行价、成立日期、注册资本、办公地址和公司简介。

基本流程可以拆成：

加载网页
-> 提取正文
-> 清理无关导航和广告
-> 让模型抽取字段
-> 输出 JSON

字段抽取时，不要让模型自由发挥。页面里没有的信息，应返回空值或 null，而不是补一个看起来合理的答案。

{
  "company_name": "",
  "english_name": "",
  "issue_price": "",
  "founded_date": "",
  "registered_capital": "",
  "office_address": "",
  "description": ""
}

自定义 Agent 工具

内置工具无法覆盖所有业务场景。遇到库存查询、订单查询、内部接口调用、规则计算这类任务，可以封装自定义工具，让 Agent 在需要时调用。

自定义工具要写清楚三件事：

工具能做什么。
输入参数是什么。
返回结果是什么。

比如订单查询工具可以定义为：

工具名称：query_order
输入参数：order_id
返回结果：订单状态、物流状态、预计送达时间

工具描述越具体，Agent 越不容易误用。不要把多个不相关能力塞进一个工具里，否则模型很难判断什么时候调用它。

Memory 记忆对话

Memory 用于保存对话历史，让模型在多轮交流中保留上下文。它适合客服、学习助手、个人助理和连续任务处理。

比如用户先说“我想学 Python”，后面继续问“那第一周怎么安排”，如果没有记忆，模型可能不知道“那”指的是什么。有了 Memory，就可以把前面的学习目标带入后续回答。

Memory 也要控制边界。对话越长，历史内容越多，成本和噪声都会增加。实际使用时，通常需要摘要历史、保留关键信息，或者只保存与任务相关的内容。

Hugging Face 模型

LangChain 可以连接不同模型来源，不限于单一模型提供方。Hugging Face 上有许多开源模型，适合做本地实验、模型替换或特定任务验证。

常见流程是：

选择 Hugging Face 模型
-> 配置推理接口或本地运行环境
-> 接入 LangChain
-> 与 Chain、Agent 或检索流程组合

选择模型时要看任务类型。文本生成、Embedding、分类和问答对应的模型并不完全一样。把生成模型拿去做向量检索，或者把 Embedding 模型当聊天模型使用，通常不会得到预期效果。

自然语言执行 SQL

自然语言转 SQL 可以让用户用普通问题查询数据库。例如用户输入“上个月销售额最高的 10 个商品是什么”，系统把问题转换成 SQL，查询数据库后再把结果解释给用户。

这个场景的基本链路是：

用户问题
-> 读取数据库表结构
-> 生成 SQL
-> 执行查询
-> 整理查询结果

它对安全要求很高。至少要注意三点：

风险	处理方式
生成危险 SQL	限制只读查询，禁止 `DELETE`、`UPDATE`、`DROP`
查询越权数据	控制表和字段权限
SQL 结果误读	返回 SQL、结果和解释，方便人工核对

自然语言 SQL 适合做内部数据助手，但不应该直接暴露给不受控用户。先限定查询范围，再逐步开放能力，会更稳。

小结

LangChain 的价值在于把大语言模型应用拆成组件：加载数据、切分文本、生成向量、检索资料、调用模型、选择工具和管理上下文。

单次问答适合入门，本地知识库问答和 Agent 工具调用更接近实际应用。真正影响效果的，往往是文档质量、切分策略、检索准确性和工具边界。