RAG 生产级架构文档解析、切片策略与召回链路设计RAG检索增强生成从概念到落地中间隔着的不是模型能力而是文档工程。很多团队在概念验证阶段跑通了 Demo——上传几篇 PDF问几个问题回答看起来不错——但一旦面对真实数据问题立刻爆发扫描件识别不了、表格解析乱掉、切片切断了关键逻辑、检索召回一堆无关内容、回答引用错误资料。这篇文章把 RAG 生产化的完整链路拆开讲文档解析、切片策略、索引构建、召回链路、检索后处理每一环给出可落地的方案和参数建议。一、文档解析RAG 的第一道质量关口很多人把文档直接丢给切片器这是 RAG 最大的错误之一。检索质量的上限由文档解析质量决定——垃圾进垃圾出。生产环境必须针对不同文档类型采用不同解析方案PDF 文本型直接用文本抽取库PyPDF、pdfplumber即可但要小心两栏排版——两栏文档按行抽取会打乱阅读顺序需要先用布局分析识别栏位再按栏序拼接。PDF 扫描件本质是图片必须走 OCR。中文 OCR 推荐 PaddleOCR 或百度 OCR识别后保留坐标信息按位置重建段落顺序。表格表格是 RAG 最容易丢信息的格式。简单方案是把表格转成 Markdown 或键值对文本复杂方案是走表格结构识别Table Transformer 等模型保留行列语义。注意不要把整个大表格塞进一个切片否则后续切片会把表头和正文切断。Word/Excel/PPT使用 python-docx、openpyxl、python-pptx 分别抽取。PPT 要注意标题 正文的层级关系讲者备注里往往有正文字幕没有的上下文值得一并入库。importpdfplumberdefparse_pdf(path):text_blocks[]withpdfplumber.open(path)aspdf:forpageinpdf.pages:# 提取带位置信息的文本行linespage.extract_text_lines()text_blocks.append( .join(l[text]forlinlines))return\n.join(text_blocks) 解析之后一定要做**质检**随机抽10%的文档人工检查是否有乱码、缺字、顺序颠倒。把解析质量做成可度量的指标如可读段落占比纳入 CI 流程防止源文档格式变化导致静默劣化。## 二、切片策略召回质量的胜负手切片是 RAG 里讨论最多、也最没有标准答案的环节。核心矛盾是**切片太小丢失上下文切片太大混入噪音**。工程上有三种主流思路各有适用场景**固定大小重叠Recursive**按字符数切相邻片留重叠。通用性强实现简单适合长文本为主的文档。**结构感知切片**按文档的标题层级切——标题1的段落、标题2的段落各成一片。适合技术文档、规章制度这类结构化内容。LangChain 的 MarkdownHeaderTextSplitter 就是这种思路切出来的每片自带章节上下文。**语义切片**用嵌入模型计算句子间相似度在语义断裂处切开。质量最好但计算成本高适合对召回质量要求极高的场景。 实际工程里没有银弹推荐的做法是**结构化文档用结构感知非结构化文档用 Recursive切片参数做网格搜索调优** pythonfromlangchain_text_splittersimportRecursiveCharacterTextSplitter splitterRecursiveCharacterTextSplitter(chunk_size700,chunk_overlap100,separators[\n\n,\n,。,,,],) 调参建议先固定 chunk_size 在500~1000之间试4~5个值同时调整 overlap 为 chunk_size 的10%~20%每组跑一遍检索评测RecallK选最优组合。永远用数据说话不要凭感觉定参数。## 三、索引构建不只存向量向量索引是最基础的但生产级索引远不止于此。推荐**双通道索引**-**向量通道**负责语义检索。嵌入模型的选择很重要——中文场景优先 bge、text-embedding-3、M3E 等对中文支持好的模型。--**关键词通道**负责精确匹配。向量检索对专有名词型号、编号、人名经常失效——RTX-5090和显卡在语义空间里距离很远但 BM25 能精确命中。 两个通道的结果合并后再统一排序就是后面要讲的混合检索。索引构建还有几个生产细节文档元数据来源、更新时间、作者要和向量一起存方便过滤和溯源删除文档时要有墓碑机制避免旧向量残留污染召回增量更新要控制在分钟级不能每次全量重建。## 四、召回链路多路召回 重排序单路向量检索的召回率通常不够生产级召回链路是多路召回 统一重排 pythondefhybrid_retrieve(query,vector_store,bm25_index,k14,k24):# 向量召回vec_docsvector_store.similarity_search(query,kk1)# 关键词召回kw_docsbm25_index.search(query,kk2)# 合并去重mergeddedupe_by_doc_id(vec_docskw_docs)returnmerged 多路召回的难点在于**如何给不同路的分数统一量纲**。最简单有效的做法是向量分数做归一化余弦相似度天然在0~1BM25 分数做min-max归一化然后按权重加权。更优的方案是**重排序Rerank**先粗召回几十条再让一个专门的重排模型bge-reranker、Cohere Rerank对查询-文档对打分取 Top-K 进入生成环节。 pythonfromFlagEmbeddingimportFlagReranker rerankerFlagReranker(BAAI/bge-reranker-v2-m3,use_fp16True)defrerank(query,docs,top_k4):pairs[[query,d.page_content]fordindocs]scoresreranker.compute_score(pairs,normalizeTrue)rankedsorted(zip(docs,scores),keylambdax:x[1],reverseTrue)return[dford,sinranked[:top_k]] 重排序带来的收益通常非常显著——粗召回20条重排后取前4往往比单路向量检索取前4的准确率高一大截。代价是多一次模型调用延迟增加几十毫秒在质量敏感场景完全值得。## 五、检索后处理过滤与压缩召回结果不能直接全塞进提示词。三个后处理步骤必不可少**元数据过滤**按时间、部门、文档类型过滤只让相关范围内的文档参与生成。比如查2026 年政策就过滤掉旧版本文档。**上下文压缩**长文档片段可能90%的内容与问题无关。用 LLM 对片段做压缩——只保留与问题相关的句子——可以显著减少 token 消耗、提升回答聚焦度。 pythondefcompress_doc(query,doc_text):promptf下面是一段资料请只保留与问题相关的信息删除无关内容。 问题{query}资料{doc_text}输出压缩后的资料如果完全无关输出无相关信息。returnllm(prompt)**去重与排序**多路召回可能返回同一个文档的不同切片要去重按重排分数排序后再交给生成模型让最相关的内容出现在上下文靠前的位置。## 六、生成环节与幻觉防线检索做得再好生成环节把关不到位前面的努力照样白费。生成侧有三道防线1.**引用溯源**要求模型在回答中标注引用了哪个片段编号用户可以直接核验。这既是体验设计也是防幻觉手段——模型知道答案可追溯编造的动力会下降。2.2.**基于资料约束**system prompt 明确只能基于提供的资料回答资料中没有就直说不知道。这条约束配合评测监控能兜住大部分幻觉。3.3.**相关度阈值**检索结果的最高分数低于某个阈值时直接返回未找到相关信息而不是硬生成。宁可不说不可错说——这条策略对客服类场景尤其重要。## 七、评测闭环让 RAG 持续变好RAG 工程最容易被忽视、也最决定成败的是评测。没有评测你无法回答这次切片的改动到底变好了没有。生产级评测包含四层-**文档解析质量**解析后文本的完整率、乱码率。--**检索质量**RecallK、MRR平均倒数排名需要有标注的问题-标准片段数据集。--**生成质量**忠实度回答是否基于资料、相关度、完整性用 LLM-as-Judge 批量打分。--**端到端指标**用户满意率、工单解决率、幻觉投诉率。 评测集要持续扩充——把线上用户反馈差的案例回流进评测集形成线上问题 → 评测用例 → 链路优化 → 回归验证的闭环。这条闭环跑起来RAG 系统才算真正进入了可演进的工程状态。## 八、小结RAG 生产化是一条从解析到评测的完整工程链路每一环都有不可回避的质量责任解析决定上限切片决定召回多路召回加重排决定准确率后处理决定成本生成约束决定可信度评测决定进化速度。建议按先建评测、再逐环优化的顺序推进——先有尺子再谈改进。把这条链路搭扎实你的 RAG 系统才能从能跑进化到好用。
RAG 生产级架构文档解析、切片策略与召回链路设计RAG检索增强生成从概念到落地中间隔着的不是模型能力而是文档工程。很多团队在概念验证阶段跑通了 Demo——上传几篇 PDF问几个问题回答看起来不错——但一旦面对真实数据问题立刻爆发扫描件识别不了、表格解析乱掉、切片切断了关键逻辑、检索召回一堆无关内容、回答引用错误资料。这篇文章把 RAG 生产化的完整链路拆开讲文档解析、切片策略、索引构建、召回链路、检索后处理每一环给出可落地的方案和参数建议。一、文档解析RAG 的第一道质量关口很多人把文档直接丢给切片器这是 RAG 最大的错误之一。检索质量的上限由文档解析质量决定——垃圾进垃圾出。生产环境必须针对不同文档类型采用不同解析方案PDF 文本型直接用文本抽取库PyPDF、pdfplumber即可但要小心两栏排版——两栏文档按行抽取会打乱阅读顺序需要先用布局分析识别栏位再按栏序拼接。PDF 扫描件本质是图片必须走 OCR。中文 OCR 推荐 PaddleOCR 或百度 OCR识别后保留坐标信息按位置重建段落顺序。表格表格是 RAG 最容易丢信息的格式。简单方案是把表格转成 Markdown 或键值对文本复杂方案是走表格结构识别Table Transformer 等模型保留行列语义。注意不要把整个大表格塞进一个切片否则后续切片会把表头和正文切断。Word/Excel/PPT使用 python-docx、openpyxl、python-pptx 分别抽取。PPT 要注意标题 正文的层级关系讲者备注里往往有正文字幕没有的上下文值得一并入库。importpdfplumberdefparse_pdf(path):text_blocks[]withpdfplumber.open(path)aspdf:forpageinpdf.pages:# 提取带位置信息的文本行linespage.extract_text_lines()text_blocks.append( .join(l[text]forlinlines))return\n.join(text_blocks) 解析之后一定要做**质检**随机抽10%的文档人工检查是否有乱码、缺字、顺序颠倒。把解析质量做成可度量的指标如可读段落占比纳入 CI 流程防止源文档格式变化导致静默劣化。## 二、切片策略召回质量的胜负手切片是 RAG 里讨论最多、也最没有标准答案的环节。核心矛盾是**切片太小丢失上下文切片太大混入噪音**。工程上有三种主流思路各有适用场景**固定大小重叠Recursive**按字符数切相邻片留重叠。通用性强实现简单适合长文本为主的文档。**结构感知切片**按文档的标题层级切——标题1的段落、标题2的段落各成一片。适合技术文档、规章制度这类结构化内容。LangChain 的 MarkdownHeaderTextSplitter 就是这种思路切出来的每片自带章节上下文。**语义切片**用嵌入模型计算句子间相似度在语义断裂处切开。质量最好但计算成本高适合对召回质量要求极高的场景。 实际工程里没有银弹推荐的做法是**结构化文档用结构感知非结构化文档用 Recursive切片参数做网格搜索调优** pythonfromlangchain_text_splittersimportRecursiveCharacterTextSplitter splitterRecursiveCharacterTextSplitter(chunk_size700,chunk_overlap100,separators[\n\n,\n,。,,,],) 调参建议先固定 chunk_size 在500~1000之间试4~5个值同时调整 overlap 为 chunk_size 的10%~20%每组跑一遍检索评测RecallK选最优组合。永远用数据说话不要凭感觉定参数。## 三、索引构建不只存向量向量索引是最基础的但生产级索引远不止于此。推荐**双通道索引**-**向量通道**负责语义检索。嵌入模型的选择很重要——中文场景优先 bge、text-embedding-3、M3E 等对中文支持好的模型。--**关键词通道**负责精确匹配。向量检索对专有名词型号、编号、人名经常失效——RTX-5090和显卡在语义空间里距离很远但 BM25 能精确命中。 两个通道的结果合并后再统一排序就是后面要讲的混合检索。索引构建还有几个生产细节文档元数据来源、更新时间、作者要和向量一起存方便过滤和溯源删除文档时要有墓碑机制避免旧向量残留污染召回增量更新要控制在分钟级不能每次全量重建。## 四、召回链路多路召回 重排序单路向量检索的召回率通常不够生产级召回链路是多路召回 统一重排 pythondefhybrid_retrieve(query,vector_store,bm25_index,k14,k24):# 向量召回vec_docsvector_store.similarity_search(query,kk1)# 关键词召回kw_docsbm25_index.search(query,kk2)# 合并去重mergeddedupe_by_doc_id(vec_docskw_docs)returnmerged 多路召回的难点在于**如何给不同路的分数统一量纲**。最简单有效的做法是向量分数做归一化余弦相似度天然在0~1BM25 分数做min-max归一化然后按权重加权。更优的方案是**重排序Rerank**先粗召回几十条再让一个专门的重排模型bge-reranker、Cohere Rerank对查询-文档对打分取 Top-K 进入生成环节。 pythonfromFlagEmbeddingimportFlagReranker rerankerFlagReranker(BAAI/bge-reranker-v2-m3,use_fp16True)defrerank(query,docs,top_k4):pairs[[query,d.page_content]fordindocs]scoresreranker.compute_score(pairs,normalizeTrue)rankedsorted(zip(docs,scores),keylambdax:x[1],reverseTrue)return[dford,sinranked[:top_k]] 重排序带来的收益通常非常显著——粗召回20条重排后取前4往往比单路向量检索取前4的准确率高一大截。代价是多一次模型调用延迟增加几十毫秒在质量敏感场景完全值得。## 五、检索后处理过滤与压缩召回结果不能直接全塞进提示词。三个后处理步骤必不可少**元数据过滤**按时间、部门、文档类型过滤只让相关范围内的文档参与生成。比如查2026 年政策就过滤掉旧版本文档。**上下文压缩**长文档片段可能90%的内容与问题无关。用 LLM 对片段做压缩——只保留与问题相关的句子——可以显著减少 token 消耗、提升回答聚焦度。 pythondefcompress_doc(query,doc_text):promptf下面是一段资料请只保留与问题相关的信息删除无关内容。 问题{query}资料{doc_text}输出压缩后的资料如果完全无关输出无相关信息。returnllm(prompt)**去重与排序**多路召回可能返回同一个文档的不同切片要去重按重排分数排序后再交给生成模型让最相关的内容出现在上下文靠前的位置。## 六、生成环节与幻觉防线检索做得再好生成环节把关不到位前面的努力照样白费。生成侧有三道防线1.**引用溯源**要求模型在回答中标注引用了哪个片段编号用户可以直接核验。这既是体验设计也是防幻觉手段——模型知道答案可追溯编造的动力会下降。2.2.**基于资料约束**system prompt 明确只能基于提供的资料回答资料中没有就直说不知道。这条约束配合评测监控能兜住大部分幻觉。3.3.**相关度阈值**检索结果的最高分数低于某个阈值时直接返回未找到相关信息而不是硬生成。宁可不说不可错说——这条策略对客服类场景尤其重要。## 七、评测闭环让 RAG 持续变好RAG 工程最容易被忽视、也最决定成败的是评测。没有评测你无法回答这次切片的改动到底变好了没有。生产级评测包含四层-**文档解析质量**解析后文本的完整率、乱码率。--**检索质量**RecallK、MRR平均倒数排名需要有标注的问题-标准片段数据集。--**生成质量**忠实度回答是否基于资料、相关度、完整性用 LLM-as-Judge 批量打分。--**端到端指标**用户满意率、工单解决率、幻觉投诉率。 评测集要持续扩充——把线上用户反馈差的案例回流进评测集形成线上问题 → 评测用例 → 链路优化 → 回归验证的闭环。这条闭环跑起来RAG 系统才算真正进入了可演进的工程状态。## 八、小结RAG 生产化是一条从解析到评测的完整工程链路每一环都有不可回避的质量责任解析决定上限切片决定召回多路召回加重排决定准确率后处理决定成本生成约束决定可信度评测决定进化速度。建议按先建评测、再逐环优化的顺序推进——先有尺子再谈改进。把这条链路搭扎实你的 RAG 系统才能从能跑进化到好用。
