最近在帮朋友做一套企业内部知识库问答，绕不开的都是同一个问题：大模型虽然能聊，但一涉及私有资料、最新文档就完全不在状态。不是编答案，就是答非所问。后来我把方案固定到了基于 RAG（检索增强生成）架构上，用 LangChain 把这套流程串成了一条可复用的开发链路，效果立竿见影。这篇文章就是围绕“LangChain + RAG”这个组合，把架构思路、关键参数、实现细节、踩坑记录一次性讲清楚，适合正准备做知识库问答、文档对话、私有数据问答的开发者参考。内容不空谈理论，会直接给出我实际在用的拆分方案、检索策略和代码骨架。
1. RAG架构的定位与选型思路
1.1 为什么需要RAG：大模型的能力边界
大模型是“记性差但想象力丰富”的典型代表。训练数据的截止时间决定了它天生不知道最近发生的事，内部参数也记不住你手里的几百份私有合同、产品手册、内部规范。更麻烦的是，当它不确定时，它会一本正经地“合理推测”，也就是我们常说的幻觉。RAG 解决的就是这两件事：先根据用户问题去外部知识库检索到真实相关内容，再把检索结果和原始问题一起交给模型去生成答案。这样答案不是模型背出来的，而是基于你提供的文档现场组织出来的，可信度完全不一样。
从实现角度看，RAG 不要求你重新训练模型、微调参数，也不需要昂贵的 GPU 长期跑训练任务。它只需要把文本数据切碎、向量化、存进向量库，查询时做一次相似度检索，然后把命中的文本片段拼进提示词里即可。这种轻量、可迭代的方式，让知识库问答从“只能演示”变成了“能上生产”。我现在的所有内部问答项目，第一版都是 RAG，而不是微调。先让模型把答案说对、说准，再考虑后续成本优化。
1.2 RAG标准流水线：索引、检索、生成
RAG 并不是一个复杂的数学模型，它更像一条流水线，分左右两段：左边是离线的索引构建，右边是在线的检索问答。
离线索引阶段要做的事情很固定：文档加载、文本切分、向量化、写入向量库。你可能会问，为什么不直接把整个文档塞给模型？因为模型上下文窗口有上限，且塞入无关内容会干扰回答。所以必须把文档切成适当大小的片段，转成向量，检索时只捞最相关的几个片段，这样既省 token，又提高准确率。
在线检索问答阶段，流程是：用户提问 → 把问题同样向量化 → 在向量库里做相似度搜索 → 取出 TopK 个相关片段 → 和问题一起拼到 Prompt 中 → 交给大模型生成答案。这个流程的关键点在于“检索”和“生成”的衔接。检索不准，模型再聪明也没用；生成不好，检索再准也白搭。所以在 LangChain 里，我会把检索器和 LLM 链分开配置，方便单独调优。
1.3 为什么选LangChain来实现
说实话，RAG 的各个环节都有成熟的开源库，完全可以自己拼，但你很快就会陷入胶水代码的维护地狱：文档格式要适配各种解析器，切分策略要反复试，向量库换来换去，提示词模板改来改去。LangChain 最大的价值在于把这些步骤统一成了Document、Splitter、Embedding、VectorStore、Retriever、Chain这类抽象，换一个组件只需要改一两行代码，不用重写整条链路。
LangChain 生态里还集成了很多开箱即用的链，比如RetrievalQA、ConversationalRetrievalChain，哪怕你刚接触 RAG，也能在十几分钟内搭一个能跑的 Demo。对于想深入做工程化的人来说，你也可以不直接用高层链，而是用 LangChain 的底层LCEL表达式语言来自定义组装流程。调参、加逻辑、插中间层，都比裸代码要顺手。这也是我一直推荐先用 LangChain 起步的原因：前期快，后期又不限死。
2. 核心细节拆解：数据准备与检索链路
2.1 文档加载：格式杂是头一道坎
RAG 的上限不是模型决定的，而是数据准备的精度决定的。我实际接触的知识库，很少是干净的 Markdown 文件，更多是 PDF、Word、Excel 表格、PPT、扫描件，甚至网页。LangChain 的文档加载器覆盖了大多数常见格式，我自己用得最多的是PyPDFLoader、TextLoader、UnstructuredFileLoader。但注意，每个加载器都有脾气。
PDF 文件要看是文字版还是扫描图。文字版 PDF 用PyPDFLoader可以直接抽文本，表格会乱掉；扫描版 PDF 必须先做 OCR，否则加载出来是一堆空白。Word 和 PDF 类似，段落和表格混排时要留意Document的元数据，特别是页码和标题，最好在加载阶段把这些元数据保留下来，后面做引用溯源时非常关键。
注意：不要盲目把 PDF 转成 TXT 再加载。很多 PDF 转换工具会把字体编码、超长行、页眉页脚混进正文，导致切分后满是噪音。宁可多花时间在加载器选型和清洗上，也不要让脏数据流进向量库。
我的习惯是：先加载 3~5 页样本，打印出前 200 个字符检查格式，确认正常之后再全量加载。这个小动作能避免之后所有环节的错误都是因为源头脏。
2.2 文本切分：chunk_size和overlap怎么定
文本切分是 RAG 开发里最容易被低估的环节。切太碎，语义单元被切断，检索时匹配不到完整含义；切太长，片段里混入大量无关内容，向量表示被平均掉，召回精度下降，生成时还浪费 token。
通用经验是，先用RecursiveCharacterTextSplitter，按“段落优先”的思路切分。它默认通过分隔符列表（比如\n\n、\n、空格、字符）依次尝试，能最大程度保持段落语义完整。我的常规起点是：
- chunk_size = 500 字符左右；
- chunk_overlap = 50～100 字符。
这个区间为什么合适？因为对我们常见的中文技术文档，500 字大约是一个小节或者 3~5 个自然段，语义足够完整，又不会让向量太“糊”。overlap 的作用是让相邻 chunk 之间有交叠，避免一句话正好被切到边界上，导致前后各剩一半，检索时两边都匹配不上。
不过这个参数不是死的。如果你的文档是代码、JSON、法律条款这种结构性较强的，要改用PythonCodeSplitter、MarkdownHeaderTextSplitter或者按章节标题切。我见过有人把一份 80 页的产品说明书按固定长度硬切，结果一句话被断成两半丢到两个 chunk，问“这个产品支不支持某种安装方式”时，检索出来的两块内容都不完整，模型自然答不准。
实操技巧：切分之前，先用正则把无用的页眉页脚、目录、重复的版权声明清理掉。切完之后，手动抽查几条 chunk 的开头和结尾，确认没有半句话。
2.3 向量化：Embedding模型不能乱选
向量化是把文本变成一组浮点数，文本越相似，向量距离越近。Embedding 模型的选择直接决定“相似”这个概念在语义上站不站得住。如果你用词向量级别的旧模型，检索结果基本是字面匹配，“苹果手机”和“iPhone”可能被认为不相似；而用好的语义模型，则能理解同义表达。
在 LangChain 中，你可以通过Embeddings接口接入任何向量化模型。我强烈建议不锁死某一家的服务，而是用自定义类封装公司内部的向量服务或开源模型接口。原因很现实：线上环境经常要换模型供应商，或者自建推理服务，抽象层能省很多事。开发期我会先接一个“随便能跑的 Embedding”，然后花时间对比几个候选模型在同一批测试问题上的召回效果。
选择 Embedding 时需要关注维度：常见的有 384、768、1024、1536 等维度，维度高并不绝对更好，维度越高存储和计算成本也越大。对中文场景，要特别留意模型是否针对中文优化，否则同样一句话，英文和中文混杂时会明显偏科。我的评估方法是找 20 条典型业务问答，手动标注最相关文档片段，然后用召回率（Recall@K）对比不同 Embedding 模型的效果，选一个性价比高的。
2.4 检索优化：相似度计算、TopK与重排
向量检索的默认操作是余弦相似度，LangChain 里的向量库一般默认用余弦距离。简单说，向量方向越接近，语义越接近。这里要小心，有些向量库默认用 L2（欧氏距离），如果你没把归一化打开，距离数值会受向量长度影响，检索结果不稳定。所以我一般会在写入向量前做归一化，或者统一采用余弦相似度。
TopK 的取值同样要权衡。K 太小，可能丢掉关键内容；K 太大，无关片段混进来，模型反而会被带偏。我常用的起步值是 4，也就是每次检索取 4 个 chunk 拼进上下文。如果问题涉及多步骤操作，可以加大到 8，但千万不要爆掉模型上下文。实际项目中，我还发现一个问题：向量检索 Top4 中偶尔会出现两个 chunk 几乎重复，等于浪费了 2 个名额，所以后面的重排步骤很必要。
重排（Rerank）是检索优化里回报很高的一个环节。向量检索先粗筛出 Top20，再用一个交叉编码器对 query 和每个候选文本做精细打分，最后取分数最高的前 4 个。在 LangChain 里，这对应ContextualCompressionRetriever，配合一个重排器实现“先粗后精”。这一步之后的答案质量和直接向量检索相比，提升非常直观。
3. 实操过程：用LangChain实现一个最小RAG系统
3.1 第一步：加载文档并建立索引
先说我常用的目录结构：data/放原始文档，index/放向量库，app.py放主流程。代码先用一个本地向量库做演示，相关向量化接口用自定义类封装，你接入实际服务时只需要改一行加载逻辑。
from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 加载文档，保留元数据 loader = PyPDFLoader("data/产品手册.pdf") documents = loader.load() # 切分文本 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=80, separators=["\n\n", "\n", "。", "；", "，", " ", ""] ) docs = text_splitter.split_documents(documents) # 自定义Embedding封装，避免绑定具体供应商 from langchain_core.embeddings import Embeddings class MyEmbedding(Embeddings): def embed_documents(self, texts): # 调你自己的文本向量服务，返回 List[List[float]] return get_embedding_batch(texts) def embed_query(self, text): return get_embedding_batch([text])[0] # 初始化向量库并写入索引 from langchain_community.vectorstores import FAISS vectorstore = FAISS.from_documents(docs, MyEmbedding()) vectorstore.save_local("index/product_manual")这里值得提一下separators的配置。我在默认分隔符后面加了中文句号和分号，原因是英文文本里按空格切没问题，但中文如果不按标点兜底，很容易把一整个段落切得七零八落。chunk_overlap取值 80，既保证语义衔接，又不至于让重叠部分太多造成冗余。
注意：
FAISS.from_documents会把所有文档向量一次性算完并写入内存，文档量大时建议改用批量写入方式，分批构建索引，防止内存爆掉。
3.2 第二步：构建检索问答链
索引建好之后，在线部分就简单多了。加载本地向量库，创建检索器，然后用ConversationalRetrievalChain把它和模型绑定起来。下面的代码是一个可以直接跑通的骨架。
from langchain_community.vectorstores import FAISS from langchain.chains import ConversationalRetrievalChain from langchain_community.llms import MyLLM # 替换为你项目中使用的LLM封装 vectorstore = FAISS.load_local( "index/product_manual", MyEmbedding(), allow_dangerous_deserialization=True # 仅在你的索引可信任时开启 ) retriever = vectorstore.as_retriever(search_kwargs={"k": 4}) chain = ConversationalRetrievalChain.from_llm( llm=my_llm, retriever=retriever, return_source_documents=True, ) # 问答测试 result = chain.invoke({ "question": "这个产品的最大防护等级是多少？", "chat_history": [] }) print(result["answer"])这里的allow_dangerous_deserialization=True是 LangChain 较新版本的安全提示，只有在你确信向量索引文件没有被篡改时才打开。生产环境的规范做法是不加载他人提供的索引文件，或者用自己的序列化方案。
我记得第一次测试时，模型答得不错，但我打开result["source_documents"]一看，检索出来的内容有两段是重复的。问题就出在文档里同一章节被导出了两遍。如果你也遇到类似情况，记得在索引写入之前做一次去重，比如按文本内容的哈希值过滤一遍。
3.3 第三步：增加引用溯源
知识库问答里，用户最想要的其实不只是答案，而是“哪里来的”这个依据。没有引用的 RAG 和一张嘴胡说没有区别。LangChain 的链已经默认把命中的源文档放在source_documents里，你只需要在显示答案时把它们带出来。
source_refs = [] for doc in result["source_documents"]: page = doc.metadata.get("page", "未知页") source = doc.metadata.get("source", "未知文档") source_refs.append(f"{source} (第{page}页)") print("参考来源：") for ref in source_refs: print("-", ref)如果 PDF 加载时元数据里没有page，则需要回到文档加载步骤，检查PyPDFLoader返回对象的metadata字段。我遇到过一些扫描版 PDF，加载后没有页码，这时候就必须先 OCR 再重排文档顺序。引用溯源不仅是给用户看的，也是给开发人员调试用的。当某个问题答错时，第一件事不是调模型，而是看一眼检索到的是不是真的相关。如果召回内容本身就不相关，后面的回答再流畅都是空中楼阁。
3.4 第四步：上下文压缩与结果追问
直接拼 TopK 的 chunk 有一种隐患：检索到的 4 个片段可能只有 2 个真正有用，剩下的会带偏模型。我建议在检索器和 LLM 之间加一层上下文压缩，用 LangChain 的ContextualCompressionRetriever先过滤一遍。
from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import LLMChainExtractor compress_retriever = ContextualCompressionRetriever( base_retriever=retriever, compressor=LLMChainExtractor(llm=my_llm), ) chain = RetrievalQA.from_chain_type( llm=my_llm, retriever=compress_retriever, return_source_documents=True, )不过要提醒一句：LLMChainExtractor会额外调用一次大模型，把原文本压缩成更精简的内容，延迟和成本都会上升。如果对实时性要求高，建议用轻量的“重排器”而不是压缩器。也可以把compress_retriever在离线阶段跑一次，把检索结果缓存起来，线上直接读缓存，效果和速度都能兼顾。
追问场景也是知识库问答的高频需求。比如用户先问“支持哪些安装方式”，再追问“第二种的步骤是什么”，如果只把当前问题拿去检索，链会找不到上下文。推荐用ConversationalRetrievalChain而不是RetrievalQA，因为它会把前几轮问答的chat_history一起传给检索器做重新表述，这一步在 LangChain 内部已经处理，你只需要把history传进来，或者自己维护一个会话列表。
4. 常见问题与排查技巧实录
4.1 召回结果不相关
如果检索回来的片段和问题完全对不上，先不要调模型。按下面顺序排查：第一步，检查切分是否合理，比如说一段很长的文本被切到 chunk 里只留了一个句尾，那语义肯定不完整；第二步，检查 Embedding 是否匹配，中文内容用英文为主的模型，经常会出现“看着像，实际不相关”；第三步，检查查询向量化是否正确，确保embed_query和embed_documents用的是同一个模型和同一个预处理逻辑；最后，检查向量库里是否混入大量空文本或格式脏数据。
这里有个小规律：如果某类问题总是召回到固定错误章节，大概率是文档里出现了相似的关键词但语义不同。建议给向量检索后的结果做一层重排，或者把问题里的关键词提取出来做一次“关键词+向量”混合过滤。LangChain 的EnsembleRetriever可以把 BM25 关键词检索和向量检索结果融合，对这类问题很有效。
4.2 模型回答对不上文档
检索到了正确答案，模型却给了别的说法，通常是 Prompt 里对“只依据文档内容回答”的约束不够强。LangChain 默认的 Prompt 其实比较温和，模型容易顺着自己的先验知识跑偏。我的做法是自定义 Prompt，明确两点：一是“如果检索内容不够，直接说不知道，不要猜测”；二是“回答必须引用检索原文中的句子”。
from langchain_core.prompts import ChatPromptTemplate prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个严谨的客服助手，只能依据给定的文档片段回答。" "如果片段中没有答案，请回复：根据现有资料无法回答。" "回答中需要指出依据的片段。"), ("human", "资料：{context}\\n\\n问题：{question}") ])注意把{context}和{question}这两个变量名和链的参数名保持一致，否则会报 KeyError。调试时建议先把context内容打印出来看一眼，你手动都能判断有没有答案，才能判断是模型问题还是 Prompt 问题。
4.3 中文文本切分导致语义割裂
中文没有空格，切分器如果按固定字符数硬切，经常出现把一个成语、术语或者关键否定词切成两段的情况。比如“不一定支持”被切到两个 chunk，检索时模型只拿到“定支持”，意思就反了。解决方案是：把分隔符列表里加入中文标点，并且把chunk_overlap设得略大一点，比如 100~150 字符。如果你处理的文档标题层级强，改用MarkdownHeaderTextSplitter或者自定义“按章节标题切”的逻辑，让每个 chunk 对应一个完整主题。
我之前处理过一份中英混排的产品规格表，纯字符切分后，同一行的中文和英文被拆到不同 chunk，错误率高得离谱。最后我用行级切分，一行或两行作为最小语义单元，问题才消失。这提醒我：切分策略不是“一个参数打天下”，要根据文档的物理结构选择。
4.4 长文档与性能问题
文档特别长时，索引构建会非常慢，回答也会变慢。慢的瓶颈通常不在 LLM，而在 Embedding 计算和向量检索。先说 Embedding，把文档切片逐条调用在线 API 会很痛苦，建议做成异步并发批量提交，同时做好失败重试；如果文档量大到百万级，离线任务应该做成带分布式调度的批处理，而不是单机脚本。
向量检索的慢通常是因为没有建立索引或者每次检索都全量扫描。FAISS 这类本地库在小规模数据时没问题，但超过几十万条就建议换用专门的向量数据库，支持分区、索引类型选择和 GPU 加速。在 LangChain 中，切换向量存储只需要替换初始化的那一段代码，检索链完全不用动。
性能调优的另一个技巧：把检索到的内容先做去重和压缩，再丢给模型，这样模型输出的 token 数会减少，首字延迟也明显降低。
4.5 私有数据与权限控制
基于 RAG 的企业知识库天然会把私有文档内容暴露给模型，如果你用的是外部大模型 API，必须确认数据脱敏和合规要求。最稳妥的做法是在检索阶段就做权限过滤，让用户能访问的文档才进入向量检索范围，而不是把所有内容都检索到之后再做限制。LangChain 的Retriever支持传入过滤条件，比如根据用户 ID 或部门编码过滤 metadata，这一步应该在设计阶段就定好，而不是开发完再补。
我见过一个团队因为把所有文档都放入同一个向量库，上线后普通用户提问竟然检索出了核心业务数据，后来被迫全量重建索引。这个教训说明，RAG 不只是一个技术组件，还是数据安全的一部分。至少要做到：索引隔离、元数据权限标定、回答内容脱敏。
关于LangChain+RAG开发的一些个人体会
做 RAG 项目这段时间，我最大的感受是：这个架构本身不复杂，复杂的是数据质量和检索效果之间的反复拉锯。每次模型答错，我都会先把责任归到检索链路上，而不是急着换大模型。LangChain 帮我把“加载、切分、向量化、检索、生成、引用”这些环节串成了一条可以快速改动的流水线，省掉了很多重复造轮子的时间。
如果你现在正准备做自己的知识库问答，我的建议是：不要第一步就追求炫酷的重排、混合检索、多轮 Agent，先跑通一个最简单的 RAG 闭环，然后把数据清洗和切分细节一点点补上。等你把文档的物理结构、检索召回的长短板摸清楚了，再上重排和多路召回这些高级玩法，效率和稳定性都会好很多。希望这篇基于 LangChain 的 RAG 开发经验分享，能帮你少踩一些我踩过的坑。
