RAG实战：使用LangChain搭建企业知识库问答系统-北京尧图网络

前一段时间我在做一个内部知识库问答项目几百页的制度文档、产品手册、技术规范堆在一起直接丢给通用大模型去聊结果它一本正经地给你编答案还编得特别流畅。这就是典型的幻觉问题。最后我选择了RAG检索增强生成路线用LangChain把整个流程串了起来折腾了大概三周从看起来能跑到真的能答好中间踩了不少坑。这篇文章就把整个实战过程拆开讲一遍包括架构选型、文档切分、向量检索、Prompt设计、前后端串接以及一批实测下来的参数经验和避坑记录。RAG解决的核心问题很简单大模型有两个硬伤一是知识截止它不知道你昨天刚更新的制度二是习惯性编造不知道的事也会给你生成一段像模像样的内容。RAG的思路是先在你自己的文档库里把相关内容检索出来再把这些内容塞进Prompt里让模型对着资料回答。这样答案有依据、可溯源知识库更新也只是重新跑一遍索引成本低得多。这篇文章适合谁看打算用LangChain搭企业私域问答应用的人已经搭了demo但检索不准、回答乱编想找解法的人以及刚接触RAG想搞清全链路的人都适用。我会把整个链路从文档加载、切分、向量化、存储、检索、重排到生成全部过一遍附上能直接改用的核心代码和一批实测参数。先说明一点我用的数据是某公司的人力资源制度汇编已脱敏场景是员工问休假、报销、考勤这类问题但你完全可以替换成自己的文档。1. 先把RAG这件事想清楚1.1 为什么我最终选RAG而不是微调做知识库问答最常被问到的问题就是你为什么不直接微调一个模型我最初也考虑过这条路后来算了一笔账就放弃了。先说成本。微调一个像样的模型光准备训练数据就要花大量时间。你要把文档写成问答对一个几百页的文档库整理下来少说几百条高质量样本还得有专人做质量审核。训练环节本身也贵即便用开源模型也需要GPU资源。相比之下RAG只需要把文档切块、向量化、存进向量库一台普通服务器就能跑起来后续文档更新也只是增量处理不需要重训模型。再说效果边界。微调本质上是把知识记进模型参数里但模型仍然不知道哪些内容它没记牢照样可能编造。RAG不同它每次都先从库里检索真实片段模型的任务只是在给定材料的基础上做归纳总结幻觉空间被大幅压缩。而且RAG的答案能溯源我可以直接告诉用户这个回答基于《考勤管理制度》第三章第二条这在企业内部场景非常重要出了问题能追责用户也更信任。当然RAG不是没有代价。它的效果上限取决于检索质量——如果相关片段没被检索出来后面再怎么生成都是白搭。所以整个项目的核心矛盾其实是怎么把检索这一环做到极致。这一点我后面会花大量篇幅讲。1.2 一条完整的RAG链路由哪几段组成很多人以为RAG就是向量检索套Prompt跑起来之后才发现远没那么简单。我把整条链路拆成七个环节每一个都不能马虎文档加载把PDF、Word、Markdown等格式的文档读进来变成纯文本。这一步的坑在于格式解析质量参差不齐尤其是PDF里的表格和扫描件。文档清洗去页眉页脚、去重复标题、处理乱码、统一编码。这一环很多人跳过但文档脏的时候后面所有环节都会跟着遭殃。文本切分把长文档切成语义完整的块chunk。切得太大检索粒度粗上下文还容易超长切得太小语义断裂检索召回率下降。向量化把每个chunk用Embedding模型转成向量。这一步的模型选型直接决定检索效果不同的模型对中文语义的理解差异非常大。向量存储与索引把向量存进向量数据库建好索引保证检索性能。数据量大之后还要考虑分区、过滤等策略。检索与重排根据用户问题召回Top K个相关块再用重排序模型精排。这是RAG效果优化的核心战场。生成把检索结果和用户问题组装成Prompt交给大模型生成最终答案。这七个环节任何一个出问题最终表现都是用户看到回答得不对或回答得不像话。但有趣的是用户反馈的问题往往是后端的回答得不对实际病根却常常在前端的根本没召回该召回的内容。所以排查问题时要养成一个习惯先查检索再查生成。2. 整体架构与关键选型解析2.1 技术栈选型背后的取舍直接说我最后定下来的方案再逐个解释为什么这么选。语言框架Python LangChain。LangChain生态最全Loaders和Chain封装得很方便社区踩坑案例也多缺点是有一定抽象成本出问题时要会看底层代码。Embedding模型BAAI的bge-m3。中文语义理解能力是实测下来最好的开源方案之一支持8192长度输入还能做稠密检索。如果你用的是OpenAI生态也可以直接上text-embedding-3-small效果稳但需要联网且按量计费。考虑到企业内部文档往往涉密我倾向于本地部署开源模型。向量数据库数据量在百万级以内用Chroma或FAISS就够。我这边数据量不大起初用了Chroma图省事后来要部署到服务器改成了FAISS本地持久化因为FAISS不强制走服务端轻量、部署简单。如果数据量再上一个量级或者需要并发服务多团队使用我会换Milvus或pgvector。大模型考虑到数据安全用私有化部署的开源模型。如果对回答质量要求高也可以接GPT-4o等商用API但要注意Prompt里会被塞进检索到的文档内容存在数据出域风险。重排序模型用了bge-reranker-base。这一步是效果提升的利器后面详细说。选型时有一个原则容易被忽略不要一味追求效果最强的模型要看你团队的维护能力。你可能花了一周把Milvus集群搭起来但没人会运维出一次故障就瘫半天那还不如用FAISS存本地文件简单可靠。我在中间踩过一次这种坑后来把团队能维护放在选型优先级的第一位。2.2 代码结构设计项目代码我按功能做了模块化避免把所有逻辑堆在一个文件里。目录结构如下rag_app/ ├── config.py # 全局配置模型路径、切分参数、向量库路径等 ├── document_loader.py # 文档加载与清洗 ├── text_splitter.py # 文本切分 ├── embedder.py # Embedding模型封装 ├── vector_store.py # 向量库构建与检索 ├── retriever.py # 检索链向量检索重排 ├── chain.py # LangChain问答链组装 ├── query.py # 对外查询接口封装 └── main.py # 命令行/API入口这么拆分的好处是出问题时定位快。比如检索结果不对直接查retriever.py文档读进来有乱码查document_loader.py。另外每个模块都尽量做成可替换的换向量库时只改vector_store.py不会把整个项目推翻重来。LangChain的抽象层比较多如果直接把所有逻辑写在Chain里后面排查问题会非常痛苦。3. 核心环节拆解切分、向量化与检索3.1 文档加载与清洗坑比想象中多文档加载看似简单实际是翻车重灾区。我处理的那份制度汇编里有PDF也有WordPDF里还有一堆表格和扫描件Loader选不好后面全白搭。先说说用到的Loader。普通文本和Markdown用TextLoader和MarkdownLoader就行注意指定UTF-8编码千万别依赖默认编码Windows环境下经常给你读出GBK乱码。Word文档我用Docx2txtLoader对中文支持不错能保留段落结构。复杂PDF我用了PyPDFLoader它能按页读取并保留一些元数据但遇到扫描件图片型PDF就废了那需要OCR环节我用的是PaddleOCR离线识别识别完再走后续流程。清洗阶段容易被忽略。制度文档里全是页眉页脚、目录、重复的空行、奇怪的制表符如果不洗掉切分时会出现大量无意义的chunk检索时还会干扰语义。我写了一个简单的清洗函数主要做这些事删除页眉页脚根据正则匹配页码、公司名等固定模式合并多余换行把段落压缩成一个连续块去掉目录区和第X页共X页这类噪音统一中文标点、全半角转换经验是清洗规则不要写得太死因为不同文档的格式差异很大。我当时做了一份针对性清洗函数换了另一批文档之后马上失灵后来改成配置化的清洗规则按文档类型选择清洗策略才算是稳定下来。3.2 文本切分与参数计算chunk_size不是拍脑袋定的文本切分是RAG里参数影响最直接的一环。chunk_size和chunk_overlap两个参数几乎决定了检索召回的上限。LangChain里最常用的切分器是RecursiveCharacterTextSplitter它会根据字符列表比如先按段落分隔符、再按句号、逗号递归切分尽量保持语义完整。我最终用了chunk_size500、chunk_overlap100这是多次试出来的下面说说这个参数是怎么定的。chunk_size的确定要考虑三个因素Embedding模型的最大输入长度、大模型的上下文窗口长度、以及你检索粒度的需求。bge-m3支持8192个token但千万不能按上限切。因为每次检索会召回多块拼接进Prompt如果每块太长几块就把上下文占满了大模型没有余量去理解用户的问题。我这边模型上下文是8K检索召回Top 5每块留出约500字拼接下来约2500到3000字加上Prompt模板和用户问题整体在可控范围内。更关键的是内容本身的语义边界。制度文档里的条通常是一个完整语义单元大约300到800字。切分时如果一条被拦腰截断检索到的那一半往往包含不完整信息。所以我做了一步优化先按文档的章节标题和条款编号做结构化切分把每一条当作一个候选块长度过长的再用RecursiveCharacterTextSplitter细分。这样比一股脑按字符切的效果好很多。如果你的文档有明确章节结构强烈建议用这种方式哪怕代码多写一点。chunk_overlap的作用是防止语义刚好被切断在边界上。100字的overlap相当于每块的首尾都有一些重叠内容查询词落在交界处时不容易漏掉。但overlap不是越大越好太大会导致相邻块高度重复检索出来好几块内容几乎一样浪费上下文空间。3.3 向量化与存储能把数据管住才算数Embedding模型选好后剩下的关键点在于怎么把向量高效地存起来、查起来。我用的FAISS分两部分持久化存储用IndexFlatIP内积相似度配合归一化后的向量效果等同于余弦相似度检索时的索引直接加载到内存中。FAISS的好处是纯本地、轻量几百万向量也能撑住缺点是内存占用随数据量线性增长而且自身没有元数据管理能力。所以我额外维护了一份JSON或SQLite映射表把chunk_id、内容、来源文档、页码、章节标题都存进去检索返回向量索引后再从映射表里取元数据。这一步非常重要否则你没法告诉用户答案来自哪份文档的哪一页。受限于部署环境我没有上Milvus。但如果你数据量大、并发高建议用Milvus。它支持动态schema、标量过滤、分区管理能直接存元数据查询时一次返回省掉自己维护映射表的麻烦。Chroma则介于两者之间适合中小项目快速验证但它的部署形态和性能在会上生产环境时显得有些尴尬我最终没有选它。Embedding时有一个容易被忽视但很影响效果的细节批量入库前先把文本做清洗拼装前缀。bge系列模型建议在查询时和入库时都加上为这个句子生成表示以用于检索相关文章这样的指令前缀这是官方推荐的做法能明显提升检索效果。如果不加性能会掉3到5个点。实测下来确实如此。3.4 检索与重排80%的效果问题出在这一环节向量检索本身只是召回候选真正决定问答质量的是后面的精排。LangChain里默认的vectorstore.as_retriever()返回的是向量相似度最高的top k个块。最初我用k4测试时发现了一个现象用户问年假没休完怎么办搜回来的4块里有2块在讲事假和病假流程它们是字面上有重合词但语义不相关。这就是纯向量召回的典型问题——字面相似和语义相关是两回事。我的解法是引入两阶段检索架构先用向量检索召回Top 20候选再用重排序模型精排取Top 5。重排序模型会把用户问题和候选块拼在一起算相关性分数比单纯的向量相似度要准得多。这一步提效非常明显在我测试集上的准确率大概从68%提升到85%以上。检索参数上top_k的选择也很有讲究。Top 20是召回阶段的数量太少容易漏太多会把不相关的也带进来增加重排负担。精排后取Top 5基本能覆盖绝大多数问题的答案分布。如果你的大模型上下文窗口很小可以压缩到Top 3不然拼接内容太长。另外很多教程会教你直接用similarity_search_with_score看相似度分数但我要提醒一句不同Embedding模型的分数分布差异巨大bge-m3打出的分普遍偏低不代表结果差。千万别拿固定阈值硬卡否则要么召回为空要么召回过满。阈值调试要结合你自己的测试集观察分数分布后再定。3.5 Prompt设计把模型的嘴管住检索做对了Prompt就能决定最终答案的形态。我早期犯过的错是把Prompt写得过于简单比如根据以下内容回答问题结果模型还是忍不住自由发挥。后来我把Prompt模板改成了这样你是一个企业知识库问答助手。请严格基于以下从知识库中检索到的文档片段回答问题。要求如下 1. 答案必须来自给定的文档片段禁止编造。 2. 如果片段中没有明确答案请直接回答根据现有资料无法回答不要猜测。 3. 回答时先给出结论再引用文档中的具体条款或章节作为依据。 4. 如果问题涉及多个条款请分点列出。 5. 保持语言简洁、准确不要输出与问题无关的内容。文档片段 {context} 用户问题 {question}这段Prompt的价值在于它明确告诉模型不知道就是不知道。实测下来模型胡说八道的概率大幅下降。此外我把引用依据做成了硬性要求回答里必须带上据《员工考勤管理制度》第三章第二条这对企业用户来说比什么都重要。还有一个小技巧Prompt里加一句如果问题不是知识库范围内的问题请礼貌地引导用户咨询对应业务部门。因为内部问答里经常有人问食堂今天吃什么电脑坏了找谁修模型如果强行拿文档答效果会很奇怪。加一句引导话术体验好很多。4. 实操过程从零搭一个文档问答Demo4.1 环境准备与数据准备先列一下我用到的环境做一个参考Python 3.10LangChain、langchain-openai如果你接兼容OpenAI协议的本地模型服务sentence-transformers加载bge-m3模型FAISSbge-reranker-base跑重排Flask用来封装查询接口数据准备阶段我把某公司的人力资源制度汇编整理成了一份hr_policies/目录里面有Word和PDF文件总大小约80MB清洗后大约20万字的有效文本。我写了一个准备脚本把清洗后的纯文本按文件输出方便后续处理。这个时候最值得检查的一点是清洗后能否看懂原文结构。如果清洗完的文本读起来像一坨乱麻后面的切分也好不到哪去。4.2 核心代码实现我直接贴核心代码每一步都加注释说明。先看文档加载与清洗from langchain_community.document_loaders import PyPDFLoader, Docx2txtLoader import re import os def load_documents(folder_path): docs [] for fname in os.listdir(folder_path): fpath os.path.join(folder_path, fname) if fname.endswith(.pdf): loader PyPDFLoader(fpath) elif fname.endswith(.docx): loader Docx2txtLoader(fpath) else: continue docs.extend(loader.load()) return docs def clean_text(content): # 去掉页眉页脚页码可根据自己的文档调整正则 content re.sub(r\n\s*\d\s*\n, \n, content) content re.sub(r第\s*\d\s*页.*?共\s*\d\s*页, , content) # 合并多余空行 content re.sub(r\n{3,}, \n\n, content) return content.strip()然后是切分。我采用结构化切分递归切分兜底的策略from langchain.text_splitter import RecursiveCharacterTextSplitter def smart_split(docs): # 先按一级标题切出大段再对超长段做递归切分 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap100, separators[\n\n, \n, 。, , , , ], ) chunks [] for doc in docs: cleaned clean_text(doc.page_content) # 按第X条等模式切出语义块 sections re.split(r(?第[一二三四五六七八九十百千0-9][条款]), cleaned) for sec in sections: if not sec.strip(): continue if len(sec) 500: chunks.append(sec.strip()) else: sub_chunks splitter.split_text(sec) chunks.extend(sub_chunks) return chunks接下来是向量入库。这里的关键点是用了bge-m3的指令前缀from sentence_transformers import SentenceTransformer import faiss import numpy as np import json model SentenceTransformer(/path/to/bge-m3) # 官方推荐指令前缀 instruction 为这个句子生成表示以用于检索相关文章 def embed_texts(texts): # 入库时拼接指令前缀 inputs [instruction t for t in texts] embeddings model.encode(inputs, normalize_embeddingsTrue) return embeddings def build_index(chunks): embeddings embed_texts(chunks) dim embeddings.shape[1] index faiss.IndexFlatIP(dim) index.add(embeddings) # 保存meta信息方便溯源 meta [{index: i, text: chunks[i]} for i in range(len(chunks))] faiss.write_index(index, hr_index.faiss) with open(hr_meta.json, w, encodingutf-8) as f: json.dump(meta, f, ensure_asciiFalse) print(f索引构建完成共 {index.ntotal} 个向量)然后是检索加重排from sentence_transformers import CrossEncoder reranker CrossEncoder(/path/to/bge-reranker-base) def retrieve_with_rerank(question, top_k20, final_k5): index faiss.read_index(hr_index.faiss) with open(hr_meta.json, r, encodingutf-8) as f: meta json.load(f) q_emb model.encode([instruction question], normalize_embeddingsTrue) scores, indices index.search(q_emb, top_k) candidates [meta[i] for i in indices[0]] # 重排打分 pairs [[question, cand[text]] for cand in candidates] rerank_scores reranker.predict(pairs) ranked sorted(zip(candidates, rerank_scores), keylambda x: x[1], reverseTrue) return ranked[:final_k]最后是问答链组装from langchain.prompts import PromptTemplate from langchain_community.llms import OpenAI # 或者你用的本地模型封装 def build_chain(): prompt PromptTemplate( templatePROMPT_TEMPLATE, input_variables[context, question], ) llm OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY, modelyour-model) def answer(question): candidates retrieve_with_rerank(question) context \n\n.join([c[text] for c, _ in candidates]) final_prompt prompt.format(contextcontext, questionquestion) resp llm.invoke(final_prompt) return {answer: resp, sources: [c[index] for c, _ in candidates]} return answer把answer函数包成一个Flask接口就能对外提供服务了。注意Flask接口里要处理好CORS否则前端页面调用会报跨域错误。4.3 把Demo串起来后的运行效果数据入库后我拿年假未休完离职时是否折算工资这类问题做了测试。流程是这样的用户提问后系统先向量召回20块候选重排后选5块拼接进Prompt最后模型给出的答案会引用具体的制度条款然后附带来源索引。后期的运行效果基本稳定回答内容能够追溯到文档原文用户反馈看起来真的有用。这里要提醒一下刚开始跑通demo只是第一步真正能上线还需要做一轮又一轮的badcase复盘。我建议每个测试问题都保存成一条记录包含用户问题、召回的chunk、模型回答、人工标注是否满意这样迭代起来才有数据支撑。5. 常见问题与排查技巧实录5.1 高频翻车场景与解法我整理了这段时间里出现频率最高的六类问题放进一个速查表问题现象根本原因排查思路解决要点回答内容与文档无关像在瞎编Prompt约束不足模型自由发挥检查召回的chunk是否真的有相关内容强化Prompt禁止编造指令检查是否召回为空答案不是用户想要的但看起来相关检索粒度不对召回块太大或太小打印召回chunk人工判断语义匹配度调整chunk_size和Overlap引入重排模型问什么都能答但答案模糊空泛综合了太多不相关chunk观察拼接后的上下文是否噪音过大降低final_k加阈值过滤低分块换一批文档后效果大幅下降清洗规则和切分策略不具通用性检查新文档的结构与原始文档的差异按文档类型配置清洗和切分策略检索速度慢向量索引全量扫描数据量大后性能下降查看索引类型和数据量换HNSW等近似最近邻索引或上Milvus中文乱码、格式丢失Loader或编码设置不对检查加载后的原始文本指定UTF-8编码扫描件走OCR这些问题的排查顺序有一个规律永远先看输入再看输出。如果召回的chunk里根本没有正确答案那不管模型多强都答不对如果召回chunk正确但答得不对那才是Prompt或生成链路的问题。把这个逻辑理清楚排查效率会提升很多。5.2 踩坑后的参数速查表分享一份我在实际测试中调出来的参数参考值可以直接作为起点。注意这些值会随着文档类型、模型、业务场景变化别当死规矩用。参数我的取值调整方向说明chunk_size500字文档语义块大则调大过大检索粒度粗过小语义断裂chunk_overlap100字随chunk_size同步调整过大会造成大量重复内容召回Top K20数据量大可调至30保证候选池有足够覆盖率精排Top K5上下文窗口小调至3太大占上下文太小覆盖不足温度temperature0.1严禁调高知识问答场景要低温度避免发散score阈值不设置固定值观察分数分布后按分位数不同模型分数分布差异极大再说一个细节温度参数直接影响问答的靠谱程度。我见过有人在RAG里把temperature设成0.7理由是让它更自然结果就是模型开始自由发挥。知识问答场景温度设0.1到0.2足够了你要的是准确不是创作。5.3 检索质量持续优化方向项目上线之后我还在持续做优化方向大致有三个。第一个是对话记忆。目前的实现是单轮问答用户追问细节时就丢了上下文。可以引入历史对话压缩把之前的问答压缩成摘要再追加到当前问题里。第二个是流式输出。长答案等待太久前端体验差配合SSE实现流式输出会好很多。第三个是建立评估集。我整理了约100条有标准答案的问题每次改动后用这批问题跑一遍准确率防止优化了A类问题却破坏了B类问题。推荐了解一下RAGAS评估框架里面的忠实度、答案相关性、上下文精度三个指标基本覆盖了RAG效果的核心维度。最后再分享一个我反复踩过的坑升级LangChain版本时API变化非常频繁有时候一个小版本升级旧代码就跑不起来了。所以项目里一定要锁住版本号或者在升级后跑一遍完整的评估集确认没有问题再上线。在这个领域能稳定复现的效果才算真正可靠的效果。

RAG实战：使用LangChain搭建企业知识库问答系统

相关推荐

基于BP神经网络的车牌识别系统Matlab实现全解析

RAG完整落地链路：从原理到代码，从Demo到生产

从零啃Spark架构与RDD：核心机制、依赖关系与实操避坑指南

更多资讯

自动驾驶生态报告深度拆解：从技术架构到商业落地

少儿信息学竞赛复赛真题解析：循环、前缀和与模拟题高分攻略

Spark从打包到提交全流程：本地测试与YARN集群实战避坑指南

K8S调度核心：nodeSelector、亲和性与污点容忍实战

RETOUCH排行榜实战：视网膜OCT液体分割的避坑指南

TypeScript+Canvas实战：构建完整贪吃蛇游戏及核心逻辑剖析

今日更新

NetSpot 实战：用信道分析与频宽优化解决 Wi-Fi 卡顿

C++ split() 字符串分割的五种实现与性能实测

R语言坐标轴范围设置：从xlim/ylim到coord_cartesian的完整指南

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？