做文档解析和切片这一行干得久了你会发现一个很残酷的规律大部分RAG检索增强生成项目上线后效果稀烂问题往往不出在模型、不出在向量库而是出在最前端那一步——文档解析和切片。这个环节要是没做好后面不管怎么调参、怎么换模型、怎么优化Prompt都是往歪了的地基上砌墙砌得越高塌得越快。这篇是系列的第二篇上一篇我们把整个知识库管线的整体架构捋了一遍这篇专门把“文档解析”和“切片”这两块拆开来揉碎了讲。名字我叫它“篇二”因为它确实是整个管线里最容易被轻视、但回报率最高的两个环节。我会结合我自己做过的几个实际项目把工具选型、处理流程、参数设置、踩坑记录都摆出来尽量做到你看完就能直接用。1. 文档解析——先把“纸面信息”翻译成“机器能读的语言”1.1 解析这件事到底在解决什么问题很多人一提文档解析第一反应就是“不就是把PDF里的文字提取出来吗PyPDF2一调就完事了”。如果你也是这么想的那后面整套系统吃瘪的时候别意外。文档解析的真实任务是把PDF、Word、PPT、扫描件这类“给人看”的格式转成“给机器看”的干净文本。这话听起来简单但难点在于给人看的东西里充满了排版噪声、视觉结构、多栏布局、页眉页脚、水印、脚注、跨页表格……机器分不清哪些是正文、哪些是干扰。我见过太多项目解析完的文本里全是这种玩意目录页的“....................5” 混进了正文页眉的“XX公司内部资料”重复出现三百遍表格单元格里的数据被拆得七零八落检索的时候你想找“2023年营收”结果向量里存的是“2023”“年”两个孤零零的词。所以解析的本质是做减法和翻译把视觉上的人类排版逻辑还原成线性的、语义完整的文本序列同时把没用的装饰信息剔除掉。这一步做得好不好直接决定下游切片和检索的天花板。1.2 常见文档类型的解析方案与工具选型不同类型的文档解析的难点完全不一样。我按实际项目中出现频率从高到低排个序文档类型常见难点推荐工具适用场景PDF电子版带文本层排版还原、多栏、表格PyMuPDFfitz、pdfplumber报告、论文、说明书PDF扫描件OCR识别、版面分析PaddleOCR、Tesseract合同、盖章文件、传真件Word.docx段落结构、标题层级、表格python-docx制度文档、SOP、方案PPT.pptx文本框位置、图文混排python-pptx汇报材料、课件HTML/网页正文抽取、标签噪声BeautifulSoup、Readability帮助中心、在线文档拿PDF来说选工具要看具体需求。PDF解析工具链里有个很重要的分水岭你要的是“文本流”还是“版面结构”。如果只是单纯把文字抠出来拼在一起PyMuPDF已经够用了速度快、文本提取质量高但如果你要处理的是多栏排版、要定位图片和表格的位置那就得上pdfplumber或者更重的版面分析方案比如LayoutParser。我自己在处理大量PDF时常用的组合是PyMuPDF做快速文本抽取和元数据读取pdfplumber处理表格密集的文件。后者对表格的还原能力比前者强很多能保住单元格的边界和行列关系这在后面做“表格问答”或者“结构化检索”时非常有用。扫描件又是另一个故事。遇到扫描件第一步就得做OCR这时候得选PaddleOCR这类中文优化的模型它在这两年对中文手写体和印刷体的识别准确率已经相当能打了。但说实话OCR识别出来的内容天然带错纯靠模型没有绝对保障所以后边清洗环节必须重一些这个我放到后面踩坑篇讲。1.3 解析实操带结构的PDF怎么处理拿一份典型的多栏学术PDF举例我按实际项目里的处理顺序拆给你看第1步预扫描PDF结构。拿到PDF先不要急着抽文本用PyMuPDF把每一页的文本块信息拉出来看看文档是单栏还是双栏、是否有目录页、总页数多少。这一步叫做“摸底”花不了几毫秒但能让你对后续处理策略心里有数。import fitz with fitz.open(示例文档.pdf) as doc: for page_num in range(min(3, doc.page_count)): page doc[page_num] blocks page.get_text(blocks) print(f第{page_num 1}页共{len(blocks)}个文本块) for block in blocks[:5]: # block结构: (x0, y0, x1, y1, 文本, 块ID, 块类型) print(f坐标: ({block[0]:.1f}, {block[1]:.1f}) - 文本预览: {block[4][:30]})这一步看着简单但价值很大。文本块的坐标信息是后续判断这是正文还是页眉页脚的关键依据。比如页脚一般出现在页面下方固定区域正文块的y坐标不会越过某个阈值这些规则都可以靠坐标筛选出来。第2步抽取正文并剔除噪声。用page.get_text(dict)拿到更细粒度的文本块信息然后按坐标规则过滤页眉页脚、页码、水印。我实际用的过滤规则有这么几条都是从项目里反复试出来的页码文本内容只含数字且位于页面顶部或底部固定区域直接丢弃页眉页脚在同一批文档中文本内容跨页重复出现的直接丢弃水印字体透明度异常高提取时带透明度信息或颜色值接近背景色的直接丢弃目录页页码区域出现大量点状引导符“....”的页面整页跳过第3步按阅读顺序重组文本。多栏PDF最坑的地方在于默认提取顺序经常是“先从左栏上半部分跳到右栏上半部分”顺序完全错乱。这时候要按文本块的坐标信息重新排序。我的办法是先按y坐标粗略分行再按x坐标分左右栏最后按“从上到下、从左到右”规则拼接。这段逻辑不复杂但值一段代码因为几乎每个PDF项目都得重写一遍# 按页处理文本块按阅读顺序排序 def sort_blocks_by_layout(blocks, page_width, threshold_ratio0.5): # 先按y坐标(行)分组再按x坐标(列)排序 sorted_blocks sorted(blocks, keylambda b: (round(b[1], 1), b[0])) # 更精细的做法检测双栏布局 mid_x page_width / 2 left_blocks [b for b in blocks if b[0] mid_x] right_blocks [b for b in blocks if b[0] mid_x] left_blocks.sort(keylambda b: (b[1], b[0])) right_blocks.sort(keylambda b: (b[1], b[0])) # 双栏文档按 左栏→右栏 顺序输出 return left_blocks right_blocks if len(left_blocks) 0 and len(right_blocks) 0 else sorted_blocks提示判断单栏还是双栏不能只看一页要多取几页做统计。我见过一份文档前10页是单栏突然中间插入3页双栏的图表附录比例差异很大。第4步表格与图片的兜底处理。如果发现页面里含大量表格我会单独切出来用pdfplumber走表格识别如果是扫描版表格就切出来单独跑OCR再叠一层表格还原。这块是文档解析工作量最大的部分我愿意把它单独拎出来写一节因为它太容易被低估了。2. 切片策略——别把文档切成“散装废纸”2.1 切片的基本矛盾粒度越细越精确粒度越粗越有上下文切片这个环节本质上是在跟一个不可调和的矛盾搏斗。切得太细每个块儿都很纯粹检索召回时命中的内容非常精准但问题是没有上下文——你检索到一句话不知道这句话是在什么语境下说的前后的逻辑链断了。切得太粗上下文完整了但块儿里混入了大量无关内容向量化之后语义被稀释得厉害召回精准度直线下降。我先用一个生活化的类比把你带进来切片就像切西瓜。你切成一牙一牙的方便吃但每一口都是独立的体验你要是直接抱半个西瓜拿勺挖每口都能吃到不同位置的瓜肉但你就说不出自己在吃的是哪个部位。检索系统里用户的问题对应的往往是文档中的某一个具体知识点这个知识点恰好落在某个块儿里你想要的理想状态是每个块儿刚好是一个语义完整的“知识点”不多也不少。这个目标说起来容易做起来很难因为天然的语言单元段落、章节、句子和知识点的边界并不总是重合。2.2 切片参数chunk_size和overlap到底怎么设不管用哪种切片方案有两个基础参数绕不开块儿大小chunk_size和重叠长度overlap。这两个参数怎么定得结合你后续用的embedding模型来考虑。市面上主流的向量模型比如OpenAI的text-embedding-3-small、BGE系列、m3e系列都有各自的最大输入长度限制。比如有些模型最长支持512个token有些能到2048。如果你的chunk_size超过模型上限向量化的过程中就会发生截断块尾信息直接丢失检索效果直接打折。我实际项目里的经验取值是场景chunk_sizetokenoverlaptoken设计理由知识库问答制度文档300~50050~100中等粒度保留完整语义长文报告检索800~1200100~200报告段落长粗粒度更合适代码库检索200~40025~50代码块独立性强过长的块儿反而稀释语义金融研报数据密集500~80080~150兼顾表格与上下文overlap存在的意义是解决“边界切穿语义”的问题。你切成300 token一块很可能把一个完整的意思表达拦腰截断一半落进上一块一半掉进下一块。overlap让这一部分内容在相邻的两个块里各出现一次检索时不管从哪个角度问都能找到上下文。但要提醒一句overlap不是越大越好。overlap过大会造成大量重复内容向量库里存储冗余暴增检索时同一份内容反复命中反而干扰排序结果。我一般控制在chunk_size的10%~20%并且要求没有特殊原因不要超过这个区间。2.3 主流切片方案对比固定窗口切片是最基础的方案按字符数或token数硬切不管内容语义。优点是代码简单、开销小、完全可预测缺点也很明显——完全不考虑内容边界一句话会被拦腰切断。我管这个叫“盲切”只适合那些结构非常规整、段落长度均匀的文档比如高质量的英文维基类内容。递归字符切片是目前最常用的方案思想是先按段落切分段落还是太长再按句子切句子还太长再按固定长度切。这种多级降级策略的目的就是尽量让切分边界落在自然的语义断点上。LangChain里有个RecursiveCharacterTextSplitter就是干这个事儿的它是用一个分级分隔符列表从上到下依次尝试[\n\n, \n, 。, , , , , , ]一级一级拆下去。固定分隔符分割是在文档结构固定时最推荐的做法比如Markdown文件按#标题、按二级标题、按列表项来切分。这种方案的颗粒度完全贴合内容结构切出来的每个块儿天然对应一个语义单元后面做检索的召回质量非常稳定。但前提是文档格式必须规整如果是乱七八糟的扫描PDF这条路走不通。基于语义的切片是这两年比较新的方向用模型通常是embedding模型或专门的语义分割模型计算句子间的相似度相似度低的句对位置就是切分边界。这种方式最智能但也是计算开销最大的方案。语义切片适合长文档、语义跳跃明显的文档比如你处理一本几百页的教材章节内部的段落之间往往有紧密关联用固定规则反而容易切错。结合我最近在几个项目中的经验我的默认策略是这样的文档能转成Markdown比如用前面说的解析方案把PDF先转成带标题结构的Markdown那就用固定分隔符标题层级切质量最高文档结构不规整但段落相对完整用递归字符切分分隔符优先级从上到下文档特别长且语义跳跃明显用语义切片但会先做一层预切分控制计算量无论用哪种方案都保持chunk_size约束在embedding模型上限的70%以内留足余量。提示我见过不少团队为了“省事”直接用固定窗口硬切结果后面做检索评测时有一大堆recall问题是因为“上下文不完整”引起的。建议你不管用什么高级方案至少先跑一遍固定窗口的baseline拿真实标注数据把基线分数打出来再往上做优化。2.4 长文档与短文档的差异化处理还有一类情况文档长度差异大得可怕。同一个知识库里可能有一篇三百字的FAQ也有一本几十万字的操作手册。这类混合场景下固定一套切片参数注定水土不服。我的做法是按文档总长度做分流短文档小于chunk_size不切整个作为一条知识入库。短文档本身语义就集中切了反而破坏完整性。中等长度文档chunk_size到数倍之间用递归字符切分overlap按20%设置。超长文档先做“结构化预切分”比如按章节拉出骨架再逐章递归切分。超长文档最怕的是全局切片把章节关系切乱。你想检索“设备维护周期”这个问题时理想结果应该是运维手册“第三章第二节”的内容而不是把整本手册切成几百块后每一块都没头没尾。所以对超长文档我强烈建议先抽章节结构再按结构去切。这样即便是切出来的块儿你也能在metadata里保留“来源章节”的标签后面召回结果可以按章节聚合展示用户观感会好很多。3. 解析到切片的完整流水线怎么搭3.1 一个最小可运行的Docx到切片流水线技术方案聊了这么多我直接用一段实际项目的代码演示从Word文档到切片的全流程。这里我选Docx做例子是因为它比PDF简单结构信息也更规整适合新手跟着跑通PDF的额外处理逻辑我在前文已经讲了你替换入口就行。from docx import Document import re from langchain.text_splitter import RecursiveCharacterTextSplitter def parse_docx_to_blocks(filepath): 按段落和标题层级抽取docx文本 doc Document(filepath) blocks [] current_h1 None current_h2 None for para in doc.paragraphs: text para.text.strip() if not text: continue style_name para.style.name if para.style else Normal if style_name.startswith(Heading 1): current_h1 text current_h2 None elif style_name.startswith(Heading 2): current_h2 text else: blocks.append({ text: text, h1: current_h1, h2: current_h2, style: style_name }) return blocks def slice_blocks(blocks, chunk_size400, overlap80): 结合章节信息的切片逻辑 splitter RecursiveCharacterTextSplitter( chunk_sizechunk_size, chunk_overlapoverlap, separators[\n\n, \n, 。, , , , ] ) chunks [] for block in blocks: if len(block[text]) chunk_size: chunks.append({ text: block[text], metadata: { h1: block[h1], h2: block[h2], source_style: block[style] } }) else: # 长段落单独切分 sub_chunks splitter.split_text(block[text]) for sub in sub_chunks: chunks.append({ text: sub, metadata: { h1: block[h1], h2: block[h2], source_style: block[style] } }) return chunks这段代码的逻辑很直白先解析出每个段落的正文和它所属的层级信息h1标题、h2标题然后判断段落长度。短段落整个入库长段落再走递归切分。每个切出来的块儿都会带上metadata标记它属于哪个章节这一设计在后面做检索过滤和结果展示时特别重要。3.2 元数据块儿的“身份证”得配齐聊到metadata我多说两句。很多人切片只存了正文文本向量化之后啥也不带检索结果出来是一段孤零零的话根本没法定位原文在哪一页、属于哪一章。这在实际落地中是个大问题。你在切片时应该尽可能把以下信息塞进metadata文档来源文件名、路径、文档ID章节路径h1层级h2层级三级以下可以合并段落在原文中的页码如果解析阶段有保留坐标信息文档类型PDF/DOCX/HTML入库时间戳原始切分策略标识方便后续排查有了这些信息你能做的事就多了。比如用户问“2023年营收是怎么算的”召回结果里有三个块儿分别来自不同年份的财报。这时候你可以用metadata里的“文档来源”做去重或者加权排序优先返回最新年度的内容而不是让三个结果互相打架。3.3 切片质量怎么验证切片做完了不能直接扔进向量库里就完事。你得给自己留一套质量验证手段。我比较常用的检查方法是“召回合规率”加“人工抽查”。第一步是标准客观指标统计块长分布全部块的token长度直方图看看有多少块儿超标文本完整性检查切分后的文本有没有明显的断句残缺比如块尾以“的”“了”这类虚词结尾且后面没有标点重复度相邻块的重叠文字占比是否在预期范围内第二步是人肉抽查。我一般会随机抽20个块儿打开原始文档对照检查每个块儿的内容是否语义完整、是否混入了页眉页脚残留、是否丢失了关键数字或表格内容。这招听起来土但效果比任何自动化指标都强很多奇葩问题只有靠人眼才能发现。我还见过一种更“讲究”的做法造一套检索测试集准备50~100个标准问题每个问题标注出它在原文档中对应的标准答案段落然后跑到检索环节去测RecallK。这能在切片阶段提前暴露问题。4. 真实踩坑与排查实录4.1 三个高频问题的定位与解法我挑三个出现频率最高的问题对应给到排查思路。这三个是我在多个项目里反复遇到且修复后效果立竿见影的。问题一切片后文本全是“半句话”。现象召回的内容总是断在一半语义不完整有时直接是一句话被切成了两瓣。排查路径第一先看切分逻辑用的是哪种方案如果是固定字符切大概率就是它的问题。第二看chunk_size设置如果设得比平均段落长度小很多比如段落平均800字你设200 token一块那肯定到处乱切。第三看递归切分器的分隔符列表如果列表里没有“。”这类句子终结符它会一直切到字符级边界自然就歪了。解决思路把chunk_size调到段落均长的60%~80%确认分隔符列表里有中文标点并且显式地把“按段落优先”写在切分逻辑里。还有一个更稳妥的办法切分后加一个“补完”步骤如果一个块儿的结尾是明显不完整的句子就往后再吞一句直到句子完整为止。问题二召回结果里混入了大量页眉页脚。现象用户问“公司对员工考勤的规定”结果返回的内容反复出现“XX咨询有限公司”或“第X页共X页”整页正文被噪声淹没了。排查路径检查解析阶段有没有做坐标过滤。如果你用PyMuPDF提取后没有筛页眉页脚那这些内容一定会在块里反复出现。解决思路回到解析阶段用文本块的坐标信息做一个白名单/黑名单过滤。白名单思路是先统计出全文档每个文本块的位置和内容凡是出现在页面顶部区域5%~15%、底部区域85%~95%且内容跨页重复的全部剔除。黑名单思路更省事把页眉页脚的具体文本内容列出来直接删。白名单更通用黑名单更精准建议两个都用。问题三同一个内容在检索结果里出现太多次。现象用户问一个问题100条结果里有20条都是同一个章节能容互几乎相同的内容。排查路径检查overlap是不是设得太大导致同一句话出现在多个块儿里再看是不是切片时没有去重逻辑或者文档本身存在大量重复表述。解决思路overlap控制在20%以内并且在写入向量库之前对相邻切片做一次“编辑距离相似度”检测相似度过高的块只保留一个。另外要意识到文档本身重复比如手册里在不同的章节都粘贴了同一段安全注意事项这种重复是合理的不应该删除建议保留并在metadata里标注章节让检索阶段去处理。4.2 一个完整案例财报PDF的解析与切片最后用一个真实项目串一遍完整流程把前面所有零散的东西收拢到一个场景里。背景客户需要搭建一个针对上市公司年报的问答系统输入是一摞几百页的PDF财报用户会问“某公司去年毛利率是多少”“研发费用比前年增长了多少”这类问题。这套系统一开始就跑了两个桩解析端用了简单的PyMuPDF文本提取结果文本里全是年报页眉的“年度报告”和页码数字切片端直接按512字符固定切把“主营业务分行业情况”表格的内容腰斩成了行级碎片。检索效果简直是灾难。我介入后改了三条线解析线上按坐标过滤掉页眉页脚和水印区域同时把“会计数据和财务指标摘要”等关键章节所在的页面单独标记出来因为这些页面表格密集需要走pdfplumber的表格还原逻辑。切片线上先用章节标题年报里一般有一级章节是固定的比如“第四节 经营情况讨论与分析”抽出文档骨架在骨架的约束下去做递归切分。每个块儿的metadata里标注它属于哪个章节、是哪一年的报告、是原文还是表格数据。这样一来如果用户问“2023年毛利率”系统可以靠metadata过滤掉其他年份的数据直接定位到对应块。最后加了小段缓存把年报里那些固定格式的表格识别的结果单独存了一份结构化JSON字段名就是表头值就是单元格内容。这两个表格走结构化检索跟纯文本块走了完全不同的通道这样表格类问题基本不会再挂。这轮优化做完之后我在自建的测试集上跑了一遍Recall5从原来的0.52提到了0.79提升幅度相当可观。而这个过程中模型端、向量库端、Prompt端全都没动过纯粹是解析和切片的修正带来的收益。4.3 最后说几句实在话做了这些年文档处理和检索系统的项目我越来越觉得解析和切片这两个环节真正难的不是写出代码而是养成一种“顺着文档本身的结构去处理”的思维方式。每种文档都有它自己的一套叙事逻辑论文靠章节推进论点财报靠项目分列披露数字制度文档靠条条款款约束行为。解析和切片的本质其实就是先识别出这套逻辑再用技术手段把逻辑保留下来让机器在检索时也能顺着这套逻辑找到要找的东西。如果你现在正准备搭一个知识库问答系统或者已经搭好但效果不如预期我的建议是别急着去换模型、调Prompt先把你的解析结果打开看看——如果看到的是满屏噪声、无头无尾的句子、被切碎的表格那答案就已经很明确了。先回头把地基建扎实后面每一层的效果都会自然好起来。