RAG入门：用LangChain搭建你的第一个知识库问答系统

引言：如果你受够了AI一本正经地胡说八道，这篇文章能帮你给它装上"外接大脑"。

一、从"幻觉"到"有据可查"：为什么需要RAG

去年秋天，我帮一家咨询公司做了一个内部知识库问答工具。他们的需求很直接：把积攒了五年的行业报告、客户方案、内部培训材料喂给AI，让销售团队能快速查到需要的信息。

我一开始想得简单。直接把几百份PDF转成文本，拼成一个超长Prompt，扔给GPT-4。结果？

销售问："我们去年给某金融客户做的风控方案，核心架构是什么？"

AI回答得头头是道，从微服务架构讲到数据中台，听起来很专业。但销售去翻原始文档发现------AI说的那些内容，文档里根本没有。 它把训练数据里关于"金融风控"的通用知识和公司内部方案混在了一起，编了一个看似合理但完全虚构的答案。

这就是大模型的幻觉问题。LLM的知识来自训练数据，不是来自你的私有文档。它擅长"生成"，但不擅长"查证"。

RAG（Retrieval-Augmented Generation，检索增强生成）就是来解决这个问题的。

它的思路很朴素：用户提问时，不直接让模型瞎编，而是先从你的文档库里检索出最相关的几段内容，把这些内容作为"参考资料"一起塞进Prompt，再让模型基于这些资料生成答案。模型看到的不再是"我脑子里关于金融风控的知识"，而是"这份文档的第37页明确写了......"

从"凭记忆回答"变成"开卷考试"，这就是RAG的本质。

二、RAG五步法：从文档到答案的完整链路

用LangChain搭建一个RAG系统，可以拆解为五个标准步骤。每一步都有坑，每一步都值得仔细琢磨。

第一步：文档加载------把各种格式的文档变成文本

RAG的第一步，是把PDF、Word、Markdown等各种格式的文档，统一转换成纯文本。LangChain提供了一系列Document Loader，覆盖常见格式。

加载PDF：

python 复制代码

from langchain_community.document_loaders import PyPDFLoader

loader = PyPDFLoader("产品手册.pdf")
pages = loader.load()
print(f"共加载 {len(pages)} 页")

PyPDFLoader会按页拆分文档，每页生成一个Document对象，包含page_content（文本内容）和metadata（页码、文件名等）。

加载Markdown：

python 复制代码

from langchain_community.document_loaders import UnstructuredMarkdownLoader

loader = UnstructuredMarkdownLoader("技术文档.md")
docs = loader.load()

UnstructuredMarkdownLoader的优势在于它能识别Markdown的标题层级、代码块、列表等结构，把这些结构信息保留在metadata里，后续分块时可以利用。

一个小技巧 ：如果你的文档库里有多种格式，可以用DirectoryLoader批量加载：

python 复制代码

from langchain_community.document_loaders import DirectoryLoader

loader = DirectoryLoader(
    "./docs", 
    glob="**/*.{pdf,md,txt}",
    show_progress=True
)
docs = loader.load()

文档加载看似简单，但有个隐性成本：格式解析的质量直接决定后续RAG的效果。PDF扫描件、图文混排、表格嵌套，这些复杂格式如果解析不干净，后续切出来的chunk会包含大量乱码或断句，检索质量大打折扣。生产环境中，建议对加载后的文档做一轮质量检查，过滤掉解析失败的页面。

第二步：文本分割------这是RAG的"胜负手"

文档加载完成后，下一步是分块（Chunking）。这一步是整个RAG链路中最关键、也最被低估的环节。

为什么必须分块？因为Embedding模型和LLM都有输入长度限制。你把一本200页的手册直接转成向量，得到的向量是一个"大杂烩"------既包含产品介绍，又包含售后政策，还有技术参数。用户问"保修期多久"，这个向量和"产品重量"的向量混在一起，检索时根本分不清。

分块的核心目标是在"信息完整性"和"检索精准度"之间找平衡。 切得太碎，上下文断裂，模型看不懂；切得太大，噪声太多，检索不精准。

LangChain最常用的分块工具是RecursiveCharacterTextSplitter。它的工作逻辑很聪明：按优先级尝试不同的分隔符，直到切出来的块满足大小要求。

python 复制代码

from langchain_text_splitters import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,        # 每个块的最大字符数
    chunk_overlap=100,     # 相邻块的重叠字符数
    separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""]
)

chunks = text_splitter.split_documents(docs)
print(f"原始文档数：{len(docs)}，切分后块数：{len(chunks)}")

参数调优是分块策略的核心。 三个关键参数怎么选？

chunk_size：决定每个块的"信息量"。

太小（如100字符）：语义过于碎片化，一个完整的句子可能被切成两半，模型拿到后理解困难。
太大（如2000字符）：一个块里包含多个主题，Embedding向量变成"混合表示"，检索时噪声增加。
推荐起点：中文场景下500-1000字符（约对应300-600 token），FAQ类可偏小（256 token），需要深度理解的技术文档可偏大（1024 token）。

chunk_overlap：相邻块之间的重叠区域，用来缓解"边界断裂"问题。

假设一段文字是"我们的产品采用最新技术，性能卓越，广泛应用于金融、医疗、教育行业。"如果恰好在"性能卓越"后面切开，前一个块以"性能卓越"结尾，后一个块以"广泛应用于"开头，两个块单独看都语义不完整。
overlap就是让这个句子同时出现在两个块里，保证无论检索命中哪个块，上下文都是完整的。
推荐值：chunk_size的10%-20%。500字符的块配50-100字符的overlap。太小起不到衔接作用，太大会导致存储膨胀和检索结果重复。

separators：分隔符优先级列表。

RecursiveCharacterTextSplitter会按列表顺序尝试：先用\n\n（段落）切，如果块还太大，再用\n（换行）切，接着用标点符号切，最后用空格或字符切。
中文文档建议把中文标点（。、！、？、；）加进去，避免在句子中间切断。

分块策略对检索质量的影响有多大？ 我做过一个实测：同一套产品手册，用chunk_size=200, overlap=0和chunk_size=800, overlap=150分别建库，然后问"这款产品的保修政策是什么"。

小窗口、无重叠的配置，检索出来的片段要么只包含"保修"两个字，要么把"保修期一年"切成"保修期"和"一年"两个块，模型根本拼不出完整答案。而大窗口、有重叠的配置，检索出来的片段包含了完整的保修条款段落，答案准确率直接翻倍。

这就是为什么说分块策略是RAG的"胜负手"------它不在模型层，但在效果层。

第三步：向量化------给文本块发"身份证"

分块完成后，每个chunk还是纯文本。要让计算机"理解"这些文本的语义，需要把它们转换成向量（Embedding）------一种高维空间中的数字表示。语义相近的文本，在向量空间中的距离也相近。

LangChain中，向量化通过Embeddings模型完成，存储通过VectorStore完成。

方案一：OpenAI Embedding（效果最好，成本最高）

python 复制代码

from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import Chroma

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db"  # 持久化到本地
)

OpenAI的text-embedding-3-large在语义理解上目前仍是第一梯队，但按token收费。如果你的文档库有上百万字， embedding费用可能不低。

方案二：本地模型（零成本，效果够用）

python 复制代码

from langchain_ollama import OllamaEmbeddings

embeddings = OllamaEmbeddings(model="qwen2.5:7b")
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db"
)

用Ollama跑本地Embedding模型，完全免费。qwen2.5:7b或nomic-embed-text在中文场景下的表现已经能满足大部分需求。缺点是速度比OpenAI慢，且需要本地GPU或足够的内存。

方案三：混合策略

我的建议是：先用本地模型跑通整个流程，验证效果后再决定是否升级到OpenAI。RAG系统的迭代成本主要在分块策略和检索逻辑上，Embedding模型反而是最容易替换的组件。

第四步：检索------RAG的核心瓶颈在这里

向量数据库建好后，用户提问时，系统会把问题也转成向量，然后在向量空间里找"离得最近"的几个文本块。这一步叫检索（Retrieval）。

LangChain提供了两种常用的检索策略：

策略一：相似度检索（similarity_search）

python 复制代码

retriever = vectorstore.as_retriever(
    search_type="similarity",
    search_kwargs={"k": 3}
)
docs = retriever.invoke("保修期是多久？")

这是最基本的检索方式，按余弦相似度排序，返回最相似的k个块。优点是简单直接，缺点是容易"扎堆"------如果文档里某一段反复提到"保修"，检索结果可能全是这一段的不同切片，丢失了其他维度的信息。

策略二：最大边际相关性检索（MMR）

python 复制代码

retriever = vectorstore.as_retriever(
    search_type="mmr",
    search_kwargs={"k": 3, "lambda_mult": 0.5}
)

MMR在相似度的基础上，增加了多样性 考量。它不仅选"最相关"的块，还会刻意选一些"相关但角度不同"的块。lambda_mult控制平衡：越接近1越看重相似度，越接近0越看重多样性。

举个例子，用户问"这款产品的优缺点"。纯相似度检索可能返回三段都在讲"优点"的内容，MMR则会强制混入一段讲"缺点"的内容，让模型看到的视角更全面。

但检索最大的瓶颈，不是检索算法本身，而是"用户问法"和"文档表述"之间的语义鸿沟。

比如文档里写的是"本产品提供一年有限质保服务"，用户问的是"这东西保修多久"。"质保"和"保修"在语义上相近，但Embedding模型可能把它们映射到不同的向量区域，导致检索失败。

这就是MultiQueryRetriever要解决的问题。

它的思路是：让LLM帮用户"改写"问题，从一个问题生成多个语义等价但措辞不同的查询，然后对每个查询分别检索，最后合并去重。

python 复制代码

from langchain.retrievers.multi_query import MultiQueryRetriever
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o", temperature=0)

base_retriever = vectorstore.as_retriever(search_kwargs={"k": 2})

multi_retriever = MultiQueryRetriever.from_llm(
    retriever=base_retriever,
    llm=llm,
)

docs = multi_retriever.invoke("这东西保修多久？")

当用户问"这东西保修多久？"时，MultiQueryRetriever可能会生成：

"这款产品的保修期是多长时间？"
"该商品提供多久的质保服务？"
"购买后保修政策是什么？"

三个查询分别检索，然后把结果合并去重。即使原始问法和文档表述有偏差，总有一个改写版本能命中。

这是RAG从"能用"走向"好用"的关键一步。 很多RAG系统效果不好，不是因为模型不够强，而是因为检索阶段就没把正确的文档片段捞出来。

第五步：生成------把检索结果变成答案

检索到相关文档片段后，最后一步是把它们和用户问题一起塞进Prompt，让LLM生成最终答案。LangChain提供了RetrievalQA链来封装这个流程。

python 复制代码

from langchain.chains import RetrievalQA
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o", temperature=0.3)

qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",  # 把所有检索到的文档直接拼进Prompt
    retriever=multi_retriever,
    return_source_documents=True  # 返回参考来源，方便溯源
)

result = qa_chain.invoke({"query": "这款产品的保修期是多久？"})
print("答案：", result["result"])
print("参考来源：", [doc.metadata for doc in result["source_documents"]])

chain_type="stuff"是最简单的策略：把检索到的k个文档片段用\n\n连接，直接拼进Prompt。优点是实现简单，缺点是如果检索结果太长，可能超出模型上下文窗口。

其他策略如map_reduce（每个片段单独生成中间答案，再汇总）和refine（迭代精炼答案）适合处理超长文档，但调用次数更多、成本更高。对于入门场景，stuff通常够用。

三、一个完整的可运行示例

把上面的五步串起来，就是一个完整的RAG系统：

python 复制代码

from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain.retrievers.multi_query import MultiQueryRetriever

# 1. 加载文档
loader = PyPDFLoader("产品手册.pdf")
docs = loader.load()

# 2. 分块（关键参数！）
splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=150,
    separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""]
)
chunks = splitter.split_documents(docs)

# 3. 向量化 + 存储
embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = Chroma.from_documents(chunks, embeddings, persist_directory="./db")

# 4. 检索（MultiQuery解决语义鸿沟）
base_retriever = vectorstore.as_retriever(search_kwargs={"k": 3})
multi_retriever = MultiQueryRetriever.from_llm(
    retriever=base_retriever,
    llm=ChatOpenAI(model="gpt-4o", temperature=0)
)

# 5. 生成
qa = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(model="gpt-4o", temperature=0.3),
    chain_type="stuff",
    retriever=multi_retriever,
    return_source_documents=True
)

# 提问
result = qa.invoke({"query": "这款产品的保修政策是什么？"})
print(result["result"])

这段代码可以直接运行，只需要替换PDF路径和API密钥。它涵盖了RAG的完整链路，而且每一步都是可替换的：换文档加载器、调分块参数、换Embedding模型、改检索策略------模块化程度很高。

四、RAG的核心瓶颈在"检索"，而非"生成"

做RAG项目这一年，我最大的认知转变是：不要过度迷信模型的能力，要把精力花在检索上。

很多团队一上来就纠结"用GPT-4还是Claude 3.5""temperature设0.3还是0.7"，却对分块策略随便拍脑袋、对检索逻辑不加优化。结果是：模型很强，但喂给它的参考资料是错的、碎的、不相关的，输出自然好不了。

RAG的效果公式大概是：最终答案质量 = 检索准确率 × 模型生成能力。

如果检索准确率只有60%，即使模型生成能力是100%，最终质量也只有60%。反过来，如果检索准确率能提到90%，哪怕用便宜一点的模型，最终效果也更好。

所以，优化RAG的优先级应该是：

先调分块策略。chunk_size、chunk_overlap、separators，这三个参数的组合对效果的影响，可能比你换模型还大。
再调检索逻辑。similarity还是MMR？k设多少？要不要加MultiQueryRetriever？
最后才考虑换模型。当前面的链路都优化到位后，模型升级带来的边际收益才会显现。

这也是为什么我说RAG的核心瓶颈在检索，而非生成。生成是"锦上添花"，检索是"雪中送炭"。没有好的检索，再好的模型也是巧妇难为无米之炊。

五、写在最后：从Demo到生产，还有多远

上面这套代码，一个下午就能跑通。但从能跑的Demo到能上线的生产系统，中间还隔着几道坎：

文档更新：产品手册更新了，怎么增量更新向量库？删掉旧块、重新 embedding、重新入库，还是需要更优雅的增量策略？

多格式混排：PDF里有表格、有图片说明、有页眉页脚，怎么保证解析出来的文本结构不乱？

效果评估：怎么量化RAG的效果？用什么指标？人工抽检还是自动化测试？

成本控制：Embedding费用、模型调用费用、向量库存储费用，怎么在效果和成本之间找平衡？

这些问题没有标准答案，每个团队都有自己的解法。但无论如何，理解RAG的五步链路、掌握分块策略的调优方法、认识到检索是瓶颈------这三件事，是每一个想做好知识库问答的工程师的必修课。

毕竟，让AI从"胡说八道"变成"有据可查"，靠的不是更贵的模型，而是更扎实的工程。