RAG 知识库实战LangChain 本地问答系统可落地让 AI 回答只有你公司知道的事规章制度、产品手册、私有文档。RAG检索增强生成是目前最实用的落地方案这篇用 LangChain 完整实现一套本地知识库问答代码直接跑。前言去年有客户问能不能让 AI 基于他们公司的规章制度回答问题直接问通用大模型不行——它不知道这些私有内容还容易一本正经地胡说八道幻觉。标准答案是RAG先把文档建成本地知识库提问时先检索相关段落再让大模型带着资料回答。这套方案我落地过好几个隐私安全数据不出内网、效果可控、还能随时更新文档。这篇把核心代码完整写出来你改改路径就能用。一、RAG 是什么一句话 流程图检索增强生成回答前先从你的文档里检索出最相关的几段连同问题一起交给大模型让它依据资料作答。你的文档 → 切片 → 向量化 → 存入向量库 ↑ 用户提问 → 向量化 → 检索最相关 k 段 ↓ 问题 检索段落 → 大模型 → 带依据的回答为什么效果好大模型不靠记忆回答而是现查资料回答——知识可以随时更新改文档即可还能在回答里指出依据来源幻觉大幅减少。二、技术选型组件选型说明文档加载/切片LangChain统一接口md/pdf/docx 都能读嵌入模型BAAI/bge-small-zh-v1.5中文语义检索标杆模型小效果好向量库FAISS本地轻量够用且免部署大模型本地 Ollamaqwen2.5或任意 OpenAI 兼容接口隐私场景用本地效果场景用云端全部组件都能离线跑嵌入模型和向量库都在本地LLM 用本地 Ollama 的话整个链路不出网。三、完整代码真实可跑pip install langchain0.3 langchain-community langchain-huggingface faiss-cpu sentence-transformersfromlangchain_community.document_loadersimportDirectoryLoader,TextLoaderfromlangchain.text_splitterimportRecursiveCharacterTextSplitterfromlangchain_community.vectorstoresimportFAISSfromlangchain_huggingfaceimportHuggingFaceEmbeddingsfromlangchain.chainsimportRetrievalQAfromlangchain_community.llmsimportOllama# 1. 加载文档docs 目录下的所有 md/txt 文件loaderDirectoryLoader(docs/,glob**/*.md,loader_clsTextLoader)docsloader.load()print(f加载{len(docs)}个文档)# 2. 切片500 字一段重叠 50 字重叠保证上下文连贯splitterRecursiveCharacterTextSplitter(chunk_size500,chunk_overlap50)chunkssplitter.split_documents(docs)# 3. 向量化 建库首次运行会自动下载嵌入模型约 100MBembeddingsHuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5)dbFAISS.from_documents(chunks,embeddings)# 4. 检索 大模型回答llmOllama(modelqwen2.5:7b)# 本地模型云端换 OpenAI() 等qaRetrievalQA.from_chain_type(llmllm,retrieverdb.as_retriever(search_kwargs{k:4}),# 每次取最相关的 4 段)answerqa.invoke(公司报销流程是什么)print(answer[result])跑起来之后问什么它都会先查你的文档再回答回答末尾还会带依据片段。运行验证首次运行会自动下载嵌入模型约 100MB稍等之后提问回答内容应来自你docs/目录里的文档比如问报销流程能答出你文档里写的步骤问一个文档里没有的问题模型会回答资料中没有相关信息——这正是 RAG检索增强生效的证据而不是模型瞎编。四、工程化要点从 demo 到能交付文档更新机制文档变了向量库不会自动变要重建或增量更新——db.add_documents(新切片)增量加或写个重建知识库脚本生产环境这是标配检索参数调优k每次检索的段落数默认 4文档大或问题复杂可以调到 6~8chunk_size500~800 是常见区间太大检索不准、太小上下文碎片化嵌入模型升级路线先bge-small-zh-v1.5跑通追求精度再换bge-large-zh-v1.5更准但更慢更占内存回答带来源把检索到的文档名拼进 prompt让 AI 回答时标注依据xxx.md 第 3 段客户能溯源可信度直接拉满查询改写进阶用户问题太口语时先让 LLM 把问题改写成适合检索的形式再检索命中率明显提升。五、常见坑坑解决装 langchain 依赖冲突版本很乱按文章pip install langchain0.30.3 的 API 换了用create_retrieval_chain嵌入模型下载慢/失败国内设镜像set HF_ENDPOINThttps://hf-mirror.com再运行检索答非所问chunk 大小不合适、嵌入没换中文模型、k 值太小逐一排查Ollama 连不上确认ollama serve在跑、模型名对得上ollama list回答还是胡编prompt 里强调只依据提供的资料回答资料没有就说不知道六、总结链路就一条加载 → 切片 → 向量化 → 检索 → 回答。接单角度说重点企业私有知识库问答规章制度助手、产品手册问答、客服知识库是目前需求最旺的 AI 交付类型之一很多公司愿意为让 AI 懂自己公司付费。这套代码就是内核加上界面和文档管理就是一个能卖钱的产品。觉得有用点个赞收藏有问题评论区见看到都会回。 RAG 知识库实战：LangChain 本地问答系统（可落地）
RAG 知识库实战LangChain 本地问答系统可落地让 AI 回答只有你公司知道的事规章制度、产品手册、私有文档。RAG检索增强生成是目前最实用的落地方案这篇用 LangChain 完整实现一套本地知识库问答代码直接跑。前言去年有客户问能不能让 AI 基于他们公司的规章制度回答问题直接问通用大模型不行——它不知道这些私有内容还容易一本正经地胡说八道幻觉。标准答案是RAG先把文档建成本地知识库提问时先检索相关段落再让大模型带着资料回答。这套方案我落地过好几个隐私安全数据不出内网、效果可控、还能随时更新文档。这篇把核心代码完整写出来你改改路径就能用。一、RAG 是什么一句话 流程图检索增强生成回答前先从你的文档里检索出最相关的几段连同问题一起交给大模型让它依据资料作答。你的文档 → 切片 → 向量化 → 存入向量库 ↑ 用户提问 → 向量化 → 检索最相关 k 段 ↓ 问题 检索段落 → 大模型 → 带依据的回答为什么效果好大模型不靠记忆回答而是现查资料回答——知识可以随时更新改文档即可还能在回答里指出依据来源幻觉大幅减少。二、技术选型组件选型说明文档加载/切片LangChain统一接口md/pdf/docx 都能读嵌入模型BAAI/bge-small-zh-v1.5中文语义检索标杆模型小效果好向量库FAISS本地轻量够用且免部署大模型本地 Ollamaqwen2.5或任意 OpenAI 兼容接口隐私场景用本地效果场景用云端全部组件都能离线跑嵌入模型和向量库都在本地LLM 用本地 Ollama 的话整个链路不出网。三、完整代码真实可跑pip install langchain0.3 langchain-community langchain-huggingface faiss-cpu sentence-transformersfromlangchain_community.document_loadersimportDirectoryLoader,TextLoaderfromlangchain.text_splitterimportRecursiveCharacterTextSplitterfromlangchain_community.vectorstoresimportFAISSfromlangchain_huggingfaceimportHuggingFaceEmbeddingsfromlangchain.chainsimportRetrievalQAfromlangchain_community.llmsimportOllama# 1. 加载文档docs 目录下的所有 md/txt 文件loaderDirectoryLoader(docs/,glob**/*.md,loader_clsTextLoader)docsloader.load()print(f加载{len(docs)}个文档)# 2. 切片500 字一段重叠 50 字重叠保证上下文连贯splitterRecursiveCharacterTextSplitter(chunk_size500,chunk_overlap50)chunkssplitter.split_documents(docs)# 3. 向量化 建库首次运行会自动下载嵌入模型约 100MBembeddingsHuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5)dbFAISS.from_documents(chunks,embeddings)# 4. 检索 大模型回答llmOllama(modelqwen2.5:7b)# 本地模型云端换 OpenAI() 等qaRetrievalQA.from_chain_type(llmllm,retrieverdb.as_retriever(search_kwargs{k:4}),# 每次取最相关的 4 段)answerqa.invoke(公司报销流程是什么)print(answer[result])跑起来之后问什么它都会先查你的文档再回答回答末尾还会带依据片段。运行验证首次运行会自动下载嵌入模型约 100MB稍等之后提问回答内容应来自你docs/目录里的文档比如问报销流程能答出你文档里写的步骤问一个文档里没有的问题模型会回答资料中没有相关信息——这正是 RAG检索增强生效的证据而不是模型瞎编。四、工程化要点从 demo 到能交付文档更新机制文档变了向量库不会自动变要重建或增量更新——db.add_documents(新切片)增量加或写个重建知识库脚本生产环境这是标配检索参数调优k每次检索的段落数默认 4文档大或问题复杂可以调到 6~8chunk_size500~800 是常见区间太大检索不准、太小上下文碎片化嵌入模型升级路线先bge-small-zh-v1.5跑通追求精度再换bge-large-zh-v1.5更准但更慢更占内存回答带来源把检索到的文档名拼进 prompt让 AI 回答时标注依据xxx.md 第 3 段客户能溯源可信度直接拉满查询改写进阶用户问题太口语时先让 LLM 把问题改写成适合检索的形式再检索命中率明显提升。五、常见坑坑解决装 langchain 依赖冲突版本很乱按文章pip install langchain0.30.3 的 API 换了用create_retrieval_chain嵌入模型下载慢/失败国内设镜像set HF_ENDPOINThttps://hf-mirror.com再运行检索答非所问chunk 大小不合适、嵌入没换中文模型、k 值太小逐一排查Ollama 连不上确认ollama serve在跑、模型名对得上ollama list回答还是胡编prompt 里强调只依据提供的资料回答资料没有就说不知道六、总结链路就一条加载 → 切片 → 向量化 → 检索 → 回答。接单角度说重点企业私有知识库问答规章制度助手、产品手册问答、客服知识库是目前需求最旺的 AI 交付类型之一很多公司愿意为让 AI 懂自己公司付费。这套代码就是内核加上界面和文档管理就是一个能卖钱的产品。觉得有用点个赞收藏有问题评论区见看到都会回。