★ FEATURED ARTICLE 说实话我见过太多 跑通了 的 RAG Demo 最后死在生产环境里。本地 PDF 问答跑得欢一接上企业真实的几百份合同、几十个知识库检索结果就开始胡说八道。这也是我写这篇东西的原因——用 Python 和 LangChain 搭企业级 RAG 知识库真正的难点从来不是调用一个大模型 API而是数据接入、切分策略、向量检索质量、权限隔离和评估体系这一整套工程问题。这是一篇实战向的长文目标读者是已经能跑通 LangChain 基础 Demo、但想在内部落地一个真正能被业务使用的知识库系统的开发者。我会从架构差异讲起把每个选型背后的理由和计算过程讲清楚最后给出可以直接抄走的代码框架和评估方案。1. 企业级 RAG 和 Demo 级 RAG 的差异先想清楚再动手很多团队把 RAG 想简单了——无非是文档切块 - 存向量库 - 检索 - 丢给大模型回答。这个链路在小规模、单一格式、无权限要求的场景下确实成立可一旦加上企业级三个字整个系统的复杂度会成倍上涨。1.1 企业级到底多要什么对照一下 Demo 和企业级系统的差异你会发现差的不是一个量级的事维度Demo 级企业级数据源几个 PDF/Markdown 文件内部 Wiki、OA 附件、数据库、邮件、图片扫描件数据更新手动重跑一次索引增量更新、文档回收、版本管理检索精度能用就行需要可量化指标并持续迭代权限控制无千人千面按部门/角色过滤幻觉治理无必须有引用溯源答错可追责可观测性无每次查询可回放、可分析性能单用户几十并发、几百 QPS 的检索量我参与过的某项目初期团队信心满满花了两周就把索引链路搭好了。结果第一次内部公测业务同事丢进去一份扫描版合同——里面全是图片和表格切分出来的 chunk 几乎全是乱码。这就是典型的数据环节没想透。1.2 一张架构全景图里的各个角色一套完整的企业级 RAG 系统至少由六个模块组成数据接入层负责从各种源拉取文档做格式解析、去重、清洗。文档切分层把长文档切成适合检索和喂给模型的文本块chunk并抽取元数据。向量化层将文本块转换成向量这是语义检索的基础。存储与索引层向量数据库、倒排索引支撑快速检索和元数据过滤。检索与重排层负责查询改写、多路召回、重排序保证召回准、排序精。生成与安全层把检索结果和用户问题拼装成 Prompt交给大模型生成同时做好权限校验和内容过滤。这六层每一层都可能成为瓶颈。Demo 只关注第 3 到第 6 步而企业级要花 60% 以上的精力在前两层和最后的评估闭环上。1.3 我见过砸在数据环节上的项目举几个真实教训扫描件没做 OCRPDF 是图片切出来全是空白。后来不得不加了 OCR 管线解析速度慢了三倍但总算能用。版本冲突同一份合同的 V1 和 V2 都在库里检索经常返回过期条款。后来加了文档版本的元数据并在查询时强制按版本过滤。表格被切碎一个跨两页的报价表格被固定窗口切成了几块语义完全断裂。这是最经典的切分翻车现场。每次复盘都指向同一个结论企业级 RAG 的成败一半以上在数据工程而不在大模型。2. 数据接入与文档切分检索质量的第一道分水岭2.1 多格式解析别迷信一个库打天下企业内部文档格式的多到吓人Word、PDF、PPT、Excel、Markdown、HTML还有扫描件。没有哪个单一库能完美解析所有格式我的建议是分格式用专业工具组合PDF文本型用 PyMuPDF速度快对文本布局还原度好。PDF扫描型先用 OCR 工具转成文本再走后续流程。Word/PPT用 python-docx 和 python-pptx 解析注意提取表格时要按行列结构拼接而不是把单元格内容暴力拼成一个字符串。HTML/网页用 BeautifulSoup 提取正文去掉导航、页脚、脚本等噪声。Excel把每个 sheet 按表格名 每行数据转成描述性文本否则检索模型很难理解一个二维表格的语义。一个实用的做法是写一个统一的DocumentLoader类根据文件后缀自动分发到对应解析器解析结果统一封装成 LangChain 的Document对象——对象里包含page_content文本内容和metadata来源、页码、标题等。这样后面的切分和向量化就不用关心文件类型了。2.2 切分策略选型固定窗口、递归切分还是父子文档切分是整个 RAG 系统里最容易被低估的环节。切得太粗chunk 里塞了太多无关信息向量检索的精确度下降切得太细语义可能被截断单个 chunk 的信息量不足大模型答不到位。常见的几种切分策略对比如下策略思路适用场景缺点固定字符切分按固定长度和 overlap 硬切快速验证格式杂乱文档割裂句子和段落语义损坏严重递归结构切分按换行、段落、标点、字符逐级回退切分通用文本大多数场景首选对表格、代码这类结构化内容仍不够好父子文档切分小 chunk 负责检索命中后回取大块父文档喂给模型需要回答跨段问题的知识类文档存储开销翻倍实现复杂一些语义切分通过 embedding 相似度变化寻找天然边界内容主题变化明显的文档计算成本高难度大从实际效果看LangChain 的RecursiveCharacterTextSplitter是最稳的默认选择。它维护了一组分隔符列表从上到下依次尝试切分能尽量保持段落完整。2.3 chunk_size 和 overlap 怎么定经验区间与调试方法切分参数没有标准答案但我给出一组经过多次验证的初始值chunk_size500 到 800 个字符按中文字符算大约对应 300 到 500 个汉字。overlap50 到 100 个字符约为 chunk 大小的 10% 到 20%。嵌入模型的最大输入长度一定要先确认。比如某个模型最大支持 1024 token你把 chunk 切到 2000 字效果必然打折。调试方法不复杂先跑一批有代表性的文档肉眼检查切分结果——看断句是否自然、表格是否被拆散、同一主题是否被切到两个 chunk。你可以写一个简单的统计脚本输出每个 chunk 的字数和首尾字符串快速发现问题。提示切分是一种结构化折损操作无论怎么调都会丢失一部分上下文。这也是父子文档切分的价值所在——检索用小块定位生成用大块补充两者配合能显著提升回答质量。2.4 元数据是后续一切能力的基石我见过不少人把元数据当作可有可无的附属品。实际上企业级 RAG 的权限隔离、时效过滤、来源回溯全部依赖元数据。每个Document至少应该带上这些元数据source文件原始路径或 URLfile_typedocx/pdf/html/xlsxtitle文档标题chunk_indexchunk 在文档中的序号created_at/updated_at文档时间信息department或permission_group权限组标识关键version文档版本号元数据不仅能做过滤还能在生成阶段帮大模型理解这段内容出自哪里、是什么时间的资料对减少幻觉非常有帮助。3. Embedding 与向量库选型先算一笔存储和性能的账3.1 中英文混合场景的 Embedding 选型思路Embedding 模型决定了一个知识库的语义嗅觉。我的经验是在中文为主的企业场景里通用闭源模型的赢面不一定比开源中文模型大但稳定性通常更好。两个方向都可用闭源接口类调用第三方平台的 embedding API效果稳定、接入简单缺点是费用和数据的合规性要评估。开源本地部署类像 bge-m3 这类模型对中文支持不错且支持 8000 的输入长度向量维度 1024本地部署后可以大规模离线批处理长期成本更低。选型时不要只看论文指标直接用你自己的文档做一次召回测试才是靠谱方法。抽 50 个问题跑一轮 top-5 召回人工看命中率比看任何榜都有说服力。3.2 向量存储口碑分化FAISS、pgvector、Milvus、Qdrant向量库选择取决于你的规模、已有基础设施和运维能力。FAISS一个高效的向量索引库单机内存型方案中小规模百万级 chunk 以下首选无额外服务部署极简。pgvector如果公司已经有 PostgreSQL强烈推荐。好处是业务数据和向量数据在同一个库里事务一致性强还能直接用 SQL 做元数据过滤。适合千万级以下的数据量。Milvus分布式向量数据库适合亿级向量、高并发、复杂过滤的场景。但部署和运维成本不小团队没有运维余量时慎上。QdrantRust 写的性能好支持 payload 过滤和内置重排接口中等规模团队用起来很顺手。特性FAISSpgvectorMilvusQdrant部署难度极低低高中规模上限百万级千万级亿级千万级元数据过滤需自己管理SQL 原生支持丰富支持丰富运维成本无低高中适合团队个人/小团队有 PG 的企业大厂/专业 DBA中型团队我的建议不要一开始就上重型向量库。先用 FAISS 或 pgvector 跑通业务、验证指标等到数据量和并发真的上来了再平滑迁移到 Milvus 或 Qdrant 也不迟。很多项目死在过度设计上。3.3 存储与并发用量估算表选型前先做一道简单的估算题。假设你有 10 万份文档平均每份切出 20 个 chunkchunk 总数约 200 万条。如果向量维度是 1024用 float32 存储每条向量占 1024 × 4 字节 4KB再加上文本和元数据总存储大概在 15GB 到 20GB 之间。文档数平均 chunk 数chunk 总数向量存储空间1024 维推荐方案1 万份2020 万约 1.5GBFAISS / pgvector10 万份20200 万约 15GBpgvector / Qdrant100 万份202000 万约 150GBMilvus / Qdrant 集群并发方面单机 FAISS 的查询延迟在几个毫秒到十几毫秒之间但它是内存型几十路并发查询还可以超过 100 路并发就需要考虑更专业的方案了。至于 embedding 接口的调用入库阶段是批量的真正的瓶颈在查询阶段——如果你有大量实时数据要入库分批 限流是必须的否则会直接把 embedding 服务的配额打满。4. LangChain 搭建 RAG 全链路的核心代码这一节给出可以直接跑的完整代码骨架。我用 FAISS 做存储embedding 模型和 LLM 都采用本地/兼容 OpenAI 接口的方式方便你在不同环境里切换。4.1 环境与依赖清单建议 Python 3.10 以上创建一个虚拟环境安装以下包pip install langchain langchain-community langchain-openai langchain-text-splitters pip install faiss-cpu pypdf pymupdf beautifulsoup4 pip install tiktoken如果你用本地 embedding 和 LLM加上 Ollama 作为推理服务LangChain 可以通过 OpenAI 兼容接口直接连接代码上不需要大改。4.2 索引阶段从文件夹到向量库import os from langchain_community.document_loaders import DirectoryLoader, PyMuPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import FAISS # 1. 加载文档 loader DirectoryLoader( ./docs, glob**/*.pdf, loader_clsPyMuPDFLoader, show_progressTrue, ) documents loader.load() # 2. 清洗与元数据补充 for doc in documents: doc.page_content doc.page_content.replace(\x00, ) doc.metadata[source] doc.metadata[source] doc.metadata[permission_group] detect_permission_group(doc.metadata[source]) # 自定义函数 # 3. 切分 text_splitter RecursiveCharacterTextSplitter( chunk_size600, chunk_overlap80, separators[\n\n, \n, 。, , , ., !, ?, , ;, , ,, , ], ) chunks text_splitter.split_documents(documents) # 4. 向量化与存储 embeddings OllamaEmbeddings(modelbge-m3) # 或替换为 OpenAI 兼容接口 vectorstore FAISS.from_documents(chunks, embeddings) # 5. 持久化 vectorstore.save_local(./faiss_index)这里的detect_permission_group需要你根据公司目录结构或文档属性自行实现。切分器的separators我特意按中文标点的优先级排了序效果会比默认的英文分隔符友好得多。4.3 查询阶段检索链与回答生成from langchain_openai import ChatOpenAI from langchain.chains import create_retrieval_chain from langchain.chains.combine_documents import create_stuff_documents_chain from langchain_core.prompts import ChatPromptTemplate # 加载向量库 vectorstore FAISS.load_local(./faiss_index, embeddings) # 定义 Prompt PROMPT 你是一名企业内部知识库助手。请基于以下检索到的文档片段回答问题。 要求 1. 只依据给定文档内容回答不编造信息。 2. 如果文档内容不足以回答明确回答资料不足。 3. 引用来源时标注文档名和页码。 context {context} /context 用户问题{input} prompt ChatPromptTemplate.from_template(PROMPT) # 组装链 llm ChatOpenAI( base_urlhttp://localhost:11434/v1, # Ollama 的 OpenAI 兼容端点 api_keyollama, modelqwen2.5:14b, temperature0.1, ) retriever vectorstore.as_retriever(search_kwargs{k: 5}) combine_docs_chain create_stuff_documents_chain(llm, prompt) rag_chain create_retrieval_chain(retriever, combine_docs_chain) # 查询 result rag_chain.invoke({input: 采购流程中超过多少金额需要招投标}) print(result[answer])这段代码里的temperature0.1是有讲究的——知识库问答要的是稳定和准确不是创造性温度越低越好。超过 0.3 我就会怀疑它开始自由发挥了。4.4 新版 LCEL 链式写法如果你用 LangChain 0.3 以上的版本官方推荐用 LCEL 语法自己拼链可读性和可扩展性更强from langchain_core.runnables import RunnablePassthrough, RunnableLambda def format_docs(docs): return \n\n.join(f[{d.metadata.get(source, 未知)}] {d.page_content} for d in docs) rag_chain_lcel ( {context: retriever | format_docs, input: RunnablePassthrough()} | prompt | llm ) answer rag_chain_lcel.invoke(采购流程中超过多少金额需要招投标)这个写法更符合工程化的思维——每一个步骤都是独立的 Runnable 对象可以单独测试、单独替换。比如你以后想换检索器只需要改retriever那一行其余不用动。5. 检索质量优化三板斧多查询、假设性文档与重排序基础链路跑通之后你会发现检索质量是决定回答质量的关键。用户的问题表达往往是模糊的报销上限是多少和差旅报销最多能报多少意思一样但向量距离可能不小。这时候就需要在检索环节做文章。5.1 Multi-Query把用户一句话拆成多个检索角度Multi-Query 的思路很直接让大模型把用户问题改写成多个不同表述、不同角度的子问题分别去检索然后合并去重。from langchain.prompts import PromptTemplate from langchain.output_parsers.json import SimpleJsonOutputParser multi_query_prompt PromptTemplate.from_template( 你是检索助手。请把用户的问题改写成 3 个不同表述形式的搜索查询以 JSON 数组返回。 - 一个保留原意一个换用更口语化的表达一个从业务角度补充关键词。 用户问题{question} ) gen_queries multi_query_prompt | llm | SimpleJsonOutputParser() queries gen_queries.invoke({question: 报销上限是多少}) # 得到类似[报销上限是多少, 公司能报销多少钱, 财务制度中费用报销的金额限制]然后对每个 query 分别retriever.invoke()合并结果时按page_content去重再按相关性打分。这一招对模糊问题非常有效命中率能提高不少。5.2 HyDE先写假设答案再拿假设答案去检索HyDE 的思路是先让大模型根据问题虚拟地生成一段假设答案哪怕答案是错的也不怕然后把这段假设答案做向量化去检索。原理是假设答案比问题更接近目标文档的语言风格检索匹配度更高。hyde_prompt PromptTemplate.from_template( 假设你是一位业务专家。请针对以下问题写一段约 100 字的假设性答案不需要保证正确只需要风格接近真实答案。 问题{question} ) def hyde_retrieve(question, k5): hypothetical_doc (hyde_prompt | llm).invoke({question: question}) hyde_vector embeddings.embed_query(hypothetical_doc) return vectorstore.similarity_search_by_vector(hyde_vector, kk)实测经验HyDE 对答案藏在表述相对正式的文档里的场景效果明显但对短问题、简单查证类问题提升有限而且多一次 LLM 调用会增加延迟需要做缓存。5.3 Rerank 与上下文压缩检索出来的 top-20 chunk 里真正有用的可能只有三四个。最常见的方法是先召回 50 到 100 条用重排模型Rerank精排再取 top 5。重排模型对问题与文档的语义匹配度打分会比向量相似度准得多。LangChain 里的ContextualCompressionRetriever可以结合重排器和压缩器from langchain.retrievers.document_compressors import CohereRerank from langchain.retrievers import ContextualCompressionRetriever compressor CohereRerank(modelrerank-multilingual-v3.0, top_n5) compression_retriever ContextualCompressionRetriever( base_compressorcompressor, base_retrievervectorstore.as_retriever(search_kwargs{k: 20}) ) docs compression_retriever.invoke(采购流程中超过多少金额需要招投标)如果没有商用重排接口可以用 bge-reranker 系列模型本地部署效果也不错。重排这一步我建议一定做它带来的回答质量提升仅次于切分调优。5.4 融合检索BM25 与向量的互补向量检索擅长语义相似但精确关键词匹配合同编号、产品型号、人名往往不如 BM25。把两者融合是工程上的常见操作。LangChain 提供了EnsembleRetrieverfrom langchain.retrievers import BM25Retriever, EnsembleRetriever bm25_retriever BM25Retriever.from_documents(chunks, k5) vector_retriever vectorstore.as_retriever(search_kwargs{k: 5}) ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, vector_retriever], weights[0.3, 0.7], )融合检索对文档里包含明确编号/型号的场景几乎是刚需。比如用户问C-203 型设备的维护周期BM25 能精准命中型号向量检索能找到语义相关的维护文档合并后效果立竿见影。6. 企业落地绕不开的四个坑权限、幻觉、数据更新与可观测性代码链路跑通只是开始真正的企业级体现在这些不太显眼、但决定生死的环节上。6.1 权限隔离向量库没有 RBAC怎么做向量数据库本质上是没有行列级权限控制的。一个 5 万条 chunk 的知识库用户随便问一个 Embedding 相似度查询就能把不属于他权限范围内的内容检索出来。我的做法是两层方案索引期权限标记在元数据里写入permission_group比如finance、hr、all。查询期强制过滤在检索前拿到当前用户的权限组列表转成元数据过滤条件再查向量库。FAISS 没有原生的 metadata filter需要自己先过滤 ID 再查向量。pgvector 和 Qdrant 原生支持过滤所以这个层面它们更省心# 以 Qdrant 为例 from langchain_community.vectorstores import Qdrant qdrant Qdrant.from_documents( chunks, embeddings, location:memory:, collection_nameenterprise_kb, metadata[source, permission_group], ) # 查询时强制带上权限条件 results qdrant.similarity_search( 报销流程, k5, filter{permission_group: {in: user_permission_groups}}, )权限模型要早设计否则后期改索引成本非常高。千万别把权限校验丢给大模型自觉——Prompt 里写只回答本部门资料是不可靠的。6.2 幻觉治理引文溯源与内容校验器企业应用里AI 回答错了不是效果不好是可能造成决策失误。我至少要做三层防护引文溯源要求模型在回答末尾标注依赖的文档名称和 chunk 编号。虽然不能完全杜绝幻觉但至少能追责、能复核。prompt 约束明确告诉模型资料不足时说实话。同时把温度调到 0.1 以下。后置校验器写一个独立的校验环节把模型回答里的关键事实与检索原文做相似度比对低于阈值就拒绝输出。第三层听起来重但代码不复杂。关键句相似度可以用 jieba 分词 词重叠率实现成本低能拦截明显的编造型输出。6.3 数据更新与回收知识库不是建完就完了企业的文档每天都在变。增量更新监听文件目录或数据库变更只对新增/修改的文档重新切分和向量化。文档回收下架的文档要能按source元数据批量删除向量。定时全量重建即使有增量也建议每天凌晨跑一次全量重建避免增量累积带来的脏数据。LangChain 没有提供内置的增量索引机制需要你自己维护一个文件哈希表记录每个文件的最后修改时间 哈希值变化了就重跑对应文档删除就删向量。这个模块值得花时间写好它直接影响知识库的长期可用性。6.4 可观测性与成本控制上线之后最怕的是用户问了一个问题返回了很差的答案但团队不知道哪里出了问题。一定要在链路的每一个环节埋日志用户原始 query改写后的 queryMulti-Query检索出的 chunk ID 和相似度分数重排后的排序最终喂给 LLM 的 Prompt完整拼接后生成结果和延迟如果有条件可以直接接入 Langfuse 或 LangSmith 这类 tracing 工具查询链路一目了然。成本控制方面embedding 向量化的成本是一次性的大头在 LLM 请求。给每个问答请求加上缓存相同或相似 query 直接命中历史答案是立竿见影的省钱手段同时还能降低延迟。7. 用 RAGAS 建立评估闭环别靠感觉优化很多团队优化 RAG 全靠多试几个 prompt感觉效果好了一点。这种拍脑袋方式在小项目里能混过去企业级系统必须用量化指标来驱动优化否则你根本无法向业务方和老板证明这次改动确实变好了。7.1 四类核心指标怎么看RAGAS 框架提供了四类核心指标我实际使用中认为最实用的是前两个指标考察内容通俗理解我的经验阈值Faithfulness忠实度回答是否严格基于检索到的上下文有没有编造0.8 以上Answer Relevancy答案相关性回答是否切题有没有跑偏答非所问的程度0.7 以上Context Precision上下文精确度检索结果中真正有用的比例检出来的有没有废料无固定值Context Recall上下文召回率正确信息是否都检索到了该检的有没有漏越接近 1 越好Faithfulness 是最核心的指标低于 0.7 基本说明幻觉严重先查 Prompt 约束和数据质量。Answer Relevancy 低多半是检索召回不准。Context Recall 低说明数据切分或 embedding 模型有问题。下面是一个用 RAGAS 做评估的框架用 GPT 类模型当裁判from ragas import evaluate from ragas.metrics import faithfulness, answer_relevancy dataset { question: [...], # 测试问题列表 answer: [...], # RAG 系统的回答 contexts: [...], # 检索到的上下文 ground_truth: [...], # 人工标注的标准答案 } result evaluate( dataset, metrics[faithfulness, answer_relevancy], ) print(result)7.2 评测集的构建与迭代流程评测集是一切的基石。我的建议是至少准备 100 条覆盖不同业务方向的问题由业务方和开发团队共同标注标准答案。评测集的打磨流程从真实用户历史 query 中采样确保覆盖高频问题和边缘问题。每条问题标注ground_truth和期望检索到的文档范围。每次修改系统——不管是切分参数、重排逻辑还是 prompt——都跑一遍全量评测集记录指标变化。一旦评测集建立起来你的优化方向就不再是玄学。比如你调了 chunk_size 从 600 改成 800指标里 Context Recall 涨了但 Context Precision 跌了说明 chunk 变大导致检索结果里混入了更多不相关内容那就把重排环节的top_n调小一点。指标会告诉你下一步往哪走。7.3 从指标反推问题环节的定位思路我通常用下面这套逻辑做问题定位Faithfulness 低先看 Prompt 约束再看生成模型最后看数据质量。Answer Relevancy 低大概率是检索召回有问题检查切分和重排。Context Recall 低切分粒度可能太粗或 embedding 模型对专有词汇理解不足。Context Precision 低重排没做或向量库过滤条件太宽。这个过程很像调试程序——找到指标异常的环节针对性地改而不是盲目调 prompt。持续迭代几轮以后知识库的系统指标会稳定在一个比较健康的区间。最后再分享一点个人体会做企业级 RAG 知识库最大的感受是大模型是最简单的部分数据才是最难的。一个项目的成败往往在数据接入和切分环节就已注定模型选型反而影响不大。如果你正打算在内部启动这个项目我的建议是先用 1000 条左右的高质量文档配合 pgvector 或 FAISS 把全链路跑通建立评测集再慢慢扩张数据量。不要一上来就追求大而全企业知识库的价值不是什么都能答而是核心高频问题答得又准又稳。先把那 100 个高频问题答好比什么都重要。
阅读完成 · 觉得有帮助？
