从零构建RAG系统：基于LangChain的检索增强生成实战指南

1. 项目缘起：为什么RAG是当前AI应用落地的“最优解”？

最近和不少做AI应用落地的朋友聊天，大家普遍有个共识：直接拿大模型（LLM）去处理私有知识库或者回答专业问题，效果总是不尽如人意。要么是模型一本正经地“胡说八道”，编造出看似合理但完全错误的答案；要么就是对最新的、非公开的信息一问三不知。这其实就是大模型固有的“幻觉”和“知识截止日期”问题。为了解决这个痛点，检索增强生成（RAG）技术迅速成为了连接大模型通用能力和垂直领域知识的桥梁。它不像微调那样需要高昂的成本和漫长的周期，却能实时地为模型注入最新、最相关的上下文，让回答既准确又有据可查。

我这次决定从零开始，手把手构建一个RAG系统，核心工具选用了目前生态最成熟的LangChain。选择LangChain，不是因为它完美无缺，而是因为它提供了一个足够灵活和模块化的框架，让我们可以清晰地拆解RAG的每一个环节——从文档加载、切分、向量化存储，到检索、重排，再到最终的提示工程和生成。通过这个项目，你不仅能得到一个可运行的RAG应用，更重要的是，你能透彻理解每个组件背后的设计逻辑和潜在的“坑”，这对于未来设计更复杂的AI工作流至关重要。无论你是想为自己的团队搭建一个智能知识库助手，还是想深入理解RAG的技术内核，这篇从零开始的实践指南都值得你花时间跟着走一遍。

2. 核心组件拆解：一个RAG系统到底由哪些部分组成？

在动手写代码之前，我们必须先像搭积木一样，把RAG系统的各个核心组件及其职责理清楚。一个典型的RAG流程可以抽象为三个主要阶段：索引（Indexing）、检索（Retrieval）和生成（Generation）。LangChain的强大之处就在于它为每个阶段都提供了丰富的“积木块”，我们可以根据需求自由组合。

索引阶段的目标是把非结构化的原始文档（如PDF、Word、网页）变成模型能够高效查询的格式。这个过程通常包含三步：

1. 文档加载（Document Loading）：使用各种Loader（如PyPDFLoader,UnstructuredFileLoader）将不同格式的文件加载成统一的Document对象，每个对象包含页面内容和元数据。
2. 文本分割（Text Splitting）：这是至关重要且容易被低估的一步。大模型有上下文长度限制，我们不能把整本书扔进去。需要根据语义，使用RecursiveCharacterTextSplitter或更高级的SemanticTextSplitter，将长文档切割成大小适中、语义相对完整的“块”（Chunks）。块的大小和重叠度是需要精心调优的超参数。
3. 向量化与存储（Embedding & Storage）：将文本块通过嵌入模型（Embedding Model）转化为高维向量（Vector），然后存入向量数据库（Vector Database）。这个过程的核心是，语义相近的文本，其向量在空间中的距离也相近。我们常用的嵌入模型有OpenAI的text-embedding-ada-002，或者开源的sentence-transformers模型。向量数据库则可以选择Chroma（轻量、易上手）、Pinecone（云服务、高性能）或Weaviate（功能全面）等。

检索阶段发生在用户提问时。系统将用户的问题（Query）同样转化为向量，然后在向量数据库中进行相似性搜索（Similarity Search），找出与问题向量最接近的若干个文本块。这里常见的搜索方式有：

• 相似度搜索：直接计算余弦相似度或点积，返回最相似的K个结果。
• 最大边际相关性（MMR）：在保证相关性的同时，增加结果之间的多样性，避免返回内容重复的片段。
• 自查询（Self-query）：让LLM根据用户问题自动生成过滤条件（元数据过滤），再结合向量搜索，实现更精准的检索。

生成阶段是最后一步。我们将检索到的相关文本块（作为上下文）和用户原始问题，一起精心构造成一个提示（Prompt），发送给大语言模型（如GPT-4、Claude或本地部署的Llama 2），让它基于给定的上下文生成最终答案。这里的Prompt工程非常关键，需要明确指令模型“仅根据提供的上下文回答问题”，并设定好回答的格式和风格。

理解了这套流程，我们就能明白，构建RAG不是调用一个魔法函数，而是像组装一条精密的流水线，每个环节的选型和参数都会直接影响最终效果。

3. 环境搭建与工具选型：如何为你的RAG系统选择趁手的“兵器”？

工欲善其事，必先利其器。在开始编码前，我们需要搭建好开发环境并做出关键的技术选型。我的选择基于两个原则：一是足够流行，社区支持和资料丰富；二是兼顾效果与成本，适合个人开发者或中小团队起步。

3.1 基础环境与安装

首先，确保你有一个Python环境（建议3.8以上）。创建一个干净的虚拟环境是个好习惯。然后，通过pip安装核心库：

pip install langchain langchain-community langchain-openai chromadb pypdf

• langchain: 核心框架。
• langchain-community&langchain-openai: LangChain将很多第三方集成移到了社区包中，langchain-openai则专门用于OpenAI模型集成。
• chromadb: 轻量级、开源的向量数据库，非常适合本地开发和原型验证。
• pypdf: 用于读取PDF文件。

如果你打算使用开源的嵌入模型或LLM，可能还需要安装sentence-transformers或transformers等库。为了简化起步，我们第一阶段先使用OpenAI的API，因为它稳定、效果有保障，方便我们聚焦于RAG流程本身。

3.2 关键组件选型深度解析

接下来，我们详细聊聊几个核心组件的选型理由和备选方案：

• 嵌入模型（Embedding Model）：我们首选OpenAI的text-embedding-ada-002。理由如下：1）它生成的向量维度是1536，在效果、速度和成本之间取得了很好的平衡；2）作为闭源模型，其输出稳定，无需担心本地部署的版本差异和性能问题；3）对于英文和代码的语义理解非常出色。当然，如果你对数据隐私有极高要求或希望零成本，可以选用sentence-transformers库中的all-MiniLM-L6-v2模型，它体积小、速度快，虽然效果略逊于ada-002，但对于很多场景已经足够。

  注意：嵌入模型一旦选定，后续所有存入和查询的向量都必须由同一模型生成，否则相似度计算将毫无意义。这意味着你不能中途随意更换模型。

• 向量数据库（Vector Database）：我们选择ChromaDB。对于从零开始的教程，Chroma有不可替代的优势：1）它可以直接在内存或本地磁盘中运行，无需安装复杂的服务，pip install即可使用；2）API与LangChain集成度极高，几行代码就能完成存储和查询；3）完全免费。它的缺点是持久化能力相对简单，不适合生产环境的海量数据。当你需要升级时，可以考虑Pinecone（全托管，性能强，但收费）或Weaviate（开源可自建，功能丰富）。

• 大语言模型（LLM）：生成阶段我们使用OpenAI的gpt-3.5-turbo。选择它而不是更强大的GPT-4，主要是出于成本和教育意义考虑。在RAG系统中，由于我们已经提供了精准的上下文，gpt-3.5-turbo完全有能力生成高质量的回答。这能证明RAG的核心价值——用高质量的检索来弥补模型本身知识或能力的不足。在实际项目中，你可以根据对回答质量、速度和成本的权衡，在gpt-3.5-turbo、gpt-4-turbo乃至开源模型之间灵活切换。

• 文本分割器（Text Splitter）：这是最容易出问题的地方。我强烈推荐使用RecursiveCharacterTextSplitter，并配合from tiktoken import get_encoding来按Token数量精确分割。为什么不用简单的按字符分割？因为LLM是以Token为单位理解文本的，中英文混合场景下，字符数和Token数差异很大。按Token分割能更精准地控制输入模型上下文窗口的实际大小。你需要设置两个关键参数：chunk_size（每个块的最大Token数，例如500）和chunk_overlap（块之间的重叠Token数，例如50）。重叠部分是为了防止一个完整的句子或概念被生硬地切断，确保检索时上下文连贯。

做好这些选择，我们的技术栈就清晰了：LangChain（流程框架） + OpenAI Embeddings（向量化） + Chroma（向量存储） + OpenAI LLM（答案生成）。下面，我们就用这套组合拳，开始真正的构建。

4. 实战第一步：构建文档索引流水线

现在，让我们进入实战环节。假设我们有一个名为knowledge_base.pdf的PDF文件，里面包含了我们想要让AI学习的知识。我们的目标是为它建立索引。

4.1 文档加载与解析

首先，我们使用LangChain的PDF加载器来读取文档。

from langchain_community.document_loaders import PyPDFLoader # 指定PDF文件路径 loader = PyPDFLoader("path/to/your/knowledge_base.pdf") # 加载文档，pages是一个列表，每个元素对应一页 pages = loader.load() print(f"共加载了 {len(pages)} 页文档。") print(f"第一页的内容预览：{pages[0].page_content[:200]}...")

PyPDFLoader会将PDF的每一页转换成一个Document对象。每个Document对象有两个主要属性：page_content（文本内容）和metadata（元数据，如页码、来源文件路径等）。元数据在后续检索和溯源时非常有用。

4.2 精细化文本分割

加载后的文档可能很长，我们需要将其切割。这里演示如何使用基于Token的分割器。

from langchain.text_splitter import RecursiveCharacterTextSplitter import tiktoken # 定义一个函数来统计Token数（针对OpenAI模型） def tiktoken_len(text): # 使用cl100k_base编码，这是gpt-3.5-turbo和gpt-4使用的 tokenizer = tiktoken.get_encoding("cl100k_base") tokens = tokenizer.encode(text, disallowed_special=()) return len(tokens) # 创建文本分割器 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, # 每个块最大500个token chunk_overlap=50, # 块之间重叠50个token length_function=tiktoken_len, # 使用token计数函数 separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""] # 分割优先级 ) # 执行分割 documents = text_splitter.split_documents(pages) print(f"原始文档被分割成了 {len(documents)} 个文本块。")

踩坑提示：chunk_size的设置需要权衡。太小（如100）会丢失上下文，导致检索到的片段信息不完整；太大（如2000）可能让单个块包含过多无关信息，稀释核心内容，并且可能超过模型上下文限制。通常，500-1000是一个不错的起点。chunk_overlap通常设置为chunk_size的10%-20%，用于保持语义连贯。

4.3 向量化与持久化存储

文本块准备好后，我们需要将它们转化为向量并存入Chroma数据库。

from langchain_openai import OpenAIEmbeddings from langchain.vectorstores import Chroma import os # 设置你的OpenAI API Key（请替换成你自己的） os.environ["OPENAI_API_KEY"] = "your-openai-api-key-here" # 初始化嵌入模型 embeddings = OpenAIEmbeddings(model="text-embedding-ada-002") # 指定持久化目录 persist_directory = './chroma_db' # 创建向量数据库。split_documents得到的documents直接传入，embedding模型会自动为每个块生成向量。 # 如果目录已存在，Chroma会尝试加载已有数据；否则创建新的。 vectordb = Chroma.from_documents( documents=documents, embedding=embeddings, persist_directory=persist_directory ) # 显式持久化到磁盘 vectordb.persist() print(f"向量数据库已创建并保存到 {persist_directory}。共存储了 {vectordb._collection.count()} 个向量。")

这段代码完成了索引流水线的闭环。Chroma.from_documents方法内部依次做了三件事：1）用embeddings模型为每个document生成向量；2）将向量和对应的document对象（包含文本和元数据）存入集合（Collection）；3）将数据持久化到本地目录。现在，你的知识库已经“数字化”并准备好了。

5. 实现检索与问答链：让RAG“活”起来

索引建好后，我们就可以接受用户查询了。这一步的核心是构建一个“检索问答链”（RetrievalQA Chain），它封装了检索、上下文组装和生成三个步骤。

5.1 基础检索与问答

首先，我们加载已保存的向量数据库，并进行一次简单的相似度检索。

# 加载已存在的向量数据库 vectordb = Chroma( persist_directory=persist_directory, embedding_function=embeddings ) # 用户提出一个问题 query = "LangChain中的Text Splitter有什么作用？" # 进行相似度搜索，返回最相关的3个文档块 docs = vectordb.similarity_search(query, k=3) print(f"检索到 {len(docs)} 个相关片段：") for i, doc in enumerate(docs): print(f"\n--- 片段 {i+1} ---") print(doc.page_content[:300]) # 打印前300个字符预览 print(f"来源：{doc.metadata}")

这演示了最核心的检索功能。但直接把这些片段扔给LLM还不够好，我们需要一个更智能的流程。

5.2 构建完整的RetrievalQA链

LangChain提供了RetrievalQA链，它帮我们自动化了整个流程。我们需要定义两个核心部分：检索器（Retriever）和LLM。

from langchain.chains import RetrievalQA from langchain_openai import ChatOpenAI # 1. 从向量库创建检索器 # as_retriever方法可以将向量数据库转换为一个检索器对象，并可以配置搜索参数 retriever = vectordb.as_retriever( search_type="similarity", # 使用相似度搜索 search_kwargs={"k": 4} # 检索返回4个最相关的片段 ) # 2. 初始化用于生成答案的LLM llm = ChatOpenAI(model_name="gpt-3.5-turbo", temperature=0) # temperature=0 使输出更确定、更专注于上下文，减少随机性。 # 3. 创建RetrievalQA链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", # 最常用的类型，将所有检索到的文档“塞”进提示词 retriever=retriever, return_source_documents=True, # 非常重要！返回源文档用于溯源 verbose=True # 设置为True可以在运行时看到链的中间步骤（调试用） ) # 4. 运行链，进行问答 result = qa_chain.invoke({"query": query}) print("\n=== AI生成的答案 ===") print(result["result"]) print("\n=== 支持答案的源文档 ===") for doc in result["source_documents"]: print(f"- {doc.metadata['source']} (页码: {doc.metadata.get('page', 'N/A')})") print(f" 内容摘要: {doc.page_content[:150]}...")

这段代码是RAG应用的核心。RetrievalQA链在幕后做了以下工作：

1. 接收用户query。
2. 调用retriever，从向量库中检索出k个最相关的文档片段。
3. 将这些片段和原始问题，按照chain_type指定的方式，组合成一个完整的提示（Prompt）。“stuff”方式最简单，就是把所有片段拼接起来作为上下文。
4. 将组装好的提示发送给llm。
5. 解析llm的返回，得到最终答案。

设置return_source_documents=True是最佳实践，它让我们能知道答案来源于哪些原文，这对于验证答案准确性、建立用户信任至关重要。

5.3 理解不同的Chain Type

chain_type参数决定了如何处理检索到的多个文档。除了“stuff”，还有几种常见策略：

• “map_reduce”: 先将每个文档单独与问题组合，分别让LLM生成一个摘要答案（Map），然后再将这些摘要答案组合起来，让LLM生成最终答案（Reduce）。适合处理大量文档，但调用LLM次数多，成本高、速度慢。
• “refine”: 迭代处理文档。用第一个文档生成初始答案，然后用后续文档不断去“精炼”和“完善”这个答案。质量可能更高，但速度慢且顺序依赖性强。
• “map_rerank”: 先让LLM为每个文档的相关性打分，然后只选用分数最高的文档来生成答案。

对于大多数知识库问答场景，“stuff”在效果、速度和成本上是最平衡的选择，只要确保所有检索到的文档总长度不超过LLM的上下文窗口限制即可。

6. 效果优化与进阶技巧：从“能用”到“好用”

一个基础的RAG系统跑通后，我们往往会发现一些不尽如人意的地方：比如检索到的片段不精准、答案偶尔还是会胡编乱造、或者无法处理复杂的多跳问题。别担心，RAG的优化是一个系统工程，下面分享几个立竿见影的进阶技巧。

6.1 优化检索质量：超越简单的相似度搜索

单纯的向量相似度搜索有时会失灵，比如用户问“昨天发布的那个新政策”，而你的文档里只有“XX政策于2023年10月发布”。虽然语义相关，但“昨天”这个时间关键词无法在向量空间中被有效匹配。这时就需要引入混合搜索（Hybrid Search）。

混合搜索结合了稠密向量检索（Dense Vector Retrieval，即我们一直在用的）和稀疏向量检索（Sparse Vector Retrieval，如BM25）。简单理解，BM25更像传统搜索引擎，基于关键词匹配，对“昨天”、“最新”这类词更敏感。我们可以使用LangChain集成Chroma的混合搜索功能，或者使用Weaviate这类原生支持混合搜索的数据库。

另一个强大的工具是重排序器（Re-ranker）。它的思路是：先用向量检索快速召回100个可能相关的文档，然后用一个更精细但更耗资源的模型（通常是小型交叉编码器模型）对这100个文档进行重新打分和排序，最后只取Top-K个最相关的送入LLM。这能显著提升上下文质量。虽然LangChain原生支持有限，但你可以很容易地将Cohere或BAAI/bge-reranker等重排模型集成到流程中。

6.2 提升生成可靠性：Prompt工程的妙用

LLM的“幻觉”问题在RAG中并未完全根除。如果检索到的上下文不相关或信息不足，模型仍可能编造答案。一个强力的Prompt能极大缓解这个问题。

from langchain.prompts import PromptTemplate # 自定义一个更严格的Prompt模板 prompt_template = """ 请严格根据以下提供的上下文信息来回答问题。如果你无法从上下文中找到明确答案，请直接说“根据提供的资料，我无法回答这个问题”，不要编造任何信息。 上下文： {context} 问题：{question} 请基于上下文给出答案： """ PROMPT = PromptTemplate( template=prompt_template, input_variables=["context", "question"] ) # 在创建QA链时使用自定义的Prompt qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=retriever, chain_type_kwargs={"prompt": PROMPT}, # 传入自定义Prompt return_source_documents=True )

这个Prompt做了两件关键事：1）明确指令模型“严格根据上下文”；2）设置了明确的“拒答”路径。实测中，这能大幅减少模型在信息不足时的胡言乱语。

6.3 实现对话记忆：构建多轮对话RAG

基础的QA链是无状态的，每次问答都是独立的。但在实际对话中，用户可能会追问“上面提到的那个方法具体怎么操作？”。为了让RAG理解上下文，我们需要引入记忆（Memory）。

from langchain.memory import ConversationBufferMemory from langchain.chains import ConversationalRetrievalChain # 创建记忆对象，用于保存对话历史 memory = ConversationBufferMemory(memory_key="chat_history", return_messages=True) # 创建对话式检索链 conversational_qa_chain = ConversationalRetrievalChain.from_llm( llm=llm, retriever=retriever, memory=memory, chain_type="stuff", verbose=True ) # 第一轮问题 result1 = conversational_qa_chain.invoke({"question": "什么是LangChain？"}) print("回答1：", result1["answer"]) # 第二轮问题（可以指代上文） result2 = conversational_qa_chain.invoke({"question": "它主要能解决什么问题？"}) print("回答2：", result2["answer"]) # 此时，链在生成答案时，会考虑到第一轮的问题和答案历史。

ConversationalRetrievalChain在检索时，会将当前问题和对话历史一起加工（例如，将历史总结成一个新的问题），再去向量库搜索，从而使检索更贴合连续的对话语境。

6.4 元数据过滤：实现更精准的检索

如果你的文档元数据丰富（例如，有“文档类型”、“部门”、“发布日期”等字段），你可以在检索时增加过滤条件，实现精准查找。

# 假设我们的文档元数据中有 `doc_type` 字段 # 在创建检索器时，可以传入一个过滤器 retriever = vectordb.as_retriever( search_kwargs={ "k": 3, "filter": {"doc_type": "用户手册"} # 只检索用户手册类型的文档 } )

这对于拥有大型、多类别知识库的场景非常有用，可以避免从无关的文档类型中检索到干扰信息。

7. 避坑指南与生产环境考量

走通整个流程后，你会发现让一个RAG系统在生产环境中稳定、可靠地运行，还需要避开很多“坑”。这里分享几个我实践中总结的关键点。

7.1 文本分割的“语义断裂”问题

我们之前用的RecursiveCharacterTextSplitter是按字符或Token分割的，它可能在一个句子中间或一个关键表格处切断，导致检索到的片段语义不完整。解决方案是使用更智能的语义分割器。例如，可以尝试SemanticTextSplitter（基于句子嵌入聚类），或者先按自然段落（\n\n）分割，再对过长的段落进行二次分割。更高级的做法是使用LLM本身来理解文档结构并进行智能切分，当然这也会增加成本。

7.2 检索中的“丢失中间”问题

向量相似度搜索在返回Top-K个结果时，可能会忽略掉排名不高但恰恰包含关键信息的文档。特别是当问题需要综合多个文档片段（多跳推理）时，简单检索可能失效。除了前面提到的重排序，还可以尝试：

• 增加检索数量：检索时多返回一些结果（例如k=10），给后续处理留出余地。
• 父文档检索器：在分割时，同时保存大块（父文档）和小块（子文档）。检索时先找到相关的子文档，然后返回其对应的父文档作为上下文，这样可以获得更完整的背景信息。LangChain的ParentDocumentRetriever就是干这个的。

7.3 答案的溯源与可信度评估

在生成答案后，如何让用户相信这个答案？除了返回源文档，还可以做引用标注。在Prompt中要求模型在生成答案的每一句话后，标注出它所依据的源文档编号。虽然LLM不一定100%准确，但这是一个很好的实践。更严谨的做法是，在答案生成后，用一个独立的“事实核查”步骤，让另一个轻量级模型或规则系统，验证答案中的关键事实是否能在源文档中找到明确支持。

7.4 从开发到生产的部署考量

当你的RAG原型验证有效，准备投入生产时，需要考虑以下问题：

• 向量数据库升级：将本地的Chroma替换为支持分布式、高可用的生产级向量数据库，如Pinecone、Weaviate Cloud或Qdrant。
• 异步处理与缓存：文档索引（尤其是嵌入生成）是计算密集型任务，应该使用异步队列（如Celery）来处理，避免阻塞Web请求。对于常见问题的检索结果，可以引入缓存（如Redis）来加速响应、降低成本。
• 监控与评估：你需要监控系统的关键指标：检索延迟、LLM调用成本、用户反馈（如“点赞/点踩”）。更重要的是，建立一套评估体系，定期用一组标准问题测试系统，量化其答案的准确率、相关性和完整性。这能帮你持续发现系统的退化并指导优化方向。
• 安全与权限：确保你的RAG系统只能检索和访问用户有权查看的文档。这通常需要在元数据过滤中集成用户身份和权限信息，或者在检索前对查询进行重写以加入权限过滤条件。

构建RAG系统是一个迭代的过程，没有一劳永逸的“银弹”。从最简单的流水线开始，然后根据实际遇到的具体问题——是检索不准、答案有误还是速度太慢——有针对性地应用上述优化技巧。理解每个组件背后的原理，能让你在遇到新挑战时，拥有自己设计和调试解决方案的能力，这才是从零构建RAG带给你的最大价值。