做RAG也好做知识库问答也好做本地文档语义检索也好很多时候大家一上来就盯着后面的向量化、重排序、大模型生成觉得那些才是“技术含量”。我见过太多团队在前期解析和切片上随随便便结果上线一测召回结果跟开盲盒一样——该召回的内容召不回召回来的段落又是断头句子问它一个“第三季营收是多少”召回出来的是一堆表格碎片。这时候再回头调流程等于地基打歪了上面装修得再好也得推倒重来。这篇是系列“篇二”聊的就是文档解析document parsing和切片chunking这个地基工程。我默认读者是在做知识库、AI问答、企业文档中台这类方向的人手上有PDF、Word、HTML甚至扫描件要处理。这篇不会像官方文档那样只罗列API而是把我实际处理过的解析切片的坑、选型逻辑、参数计算方式和验证方法全部摊开来讲。看完你至少能自己搭一条不出大错的解析切片流水线并知道怎么量化切片质量。1. 为什么说解析和切片是RAG的“地基”1.1 解析切片的垃圾为什么会传导到最终答案你可能会想解析切片做得差一点顶多多浪费点token或者偶尔丢点内容不至于影响那么大吧。但真实情况是解析切片劣化带来的问题会在检索链路里被逐级放大最后呈现到用户面前的就是“答非所问”。先看解析环节。一份PDF如果只是用最简单的库把文本“抽出来”那表格会乱、栏体会串、上下标会混、标题层级会丢。比如我最常见的一个场景财务年报里的一页是横向的大宽表左边一列是日期右边一堆数值直接抽文本出来就变成一行行的数字跟日期交替出现压根看不出哪个数值对应哪个指标。这种文档进入切片阶段一个完整表格会被切得稀碎每个chunk里可能只有一个孤零零的数字。向量化之后这个数字既没有上下文也没法关联到表头召回时你问“某年度毛利率”它可能召回一个只有“42.7%”的碎块没有主语大模型拿这个去生成答案只能靠猜。再看切片环节。如果切片粒度太大比如把整章塞进一个chunk那这个chunk的平均向量会被“稀释”它跟用户query的相似度会被段落里大量无关内容拉低结果就是该命中却排不上如果切片粒度太小比如按句子甚至按30个字符切那单个chunk的语义信息极为单薄而且后续大模型拿到的上下文碎片化严重经常出现“主语在上一块谓语在下一块”的尴尬情况。无论是CH_800还是CH_200参数不是随便拍的它跟你的检索方式、向量模型能力、大模型上下文长度是绑在一起的。所以我把解析和切片叫做整个文档智能化处理链路里的“地基工程”。地基打歪了后面全白搭。这句话一点不夸张。1.2 结构化解析不等于“把文字抓出来”很多人理解的文档解析是用Python读一个文件然后把里面的字符串print出来。这也算解析但这不是结构化解析。行业内说的文档结构化解析指的是把文档中原有的结构信息——标题层级、段落边界、表格行列关系、列表项、代码块、图片位置、页眉页脚——尽可能无失真地抽取出来并以一种机器可用的方式表达。为什么非要做结构化解析因为切片质量的上限取决于解析质量。你想做“按标题层级切片”前提是解析器必须告诉你哪个文本属于二级标题哪个是三级标题你想做“表格单独处理成结构化记录再喂给后续模块”前提是解析器必须能识别表格线框并还原单元格内容而不是把表格文字压成一行。我用一个实际对比来说明差异。有一份50页的招股书PDF章节分明里面有大段表格和股票代码格式的段落。用pypdf这类基础的文本抽取库抽出文本后所有段落被合并成连续字符串你看不出哪里是章节边界表格变成一串用空格分隔的文本列对应关系全丢股权结构图里的文字顺序完全错乱。 但用一些带版面分析功能的解析器如PyMuPDF 版面识别逻辑或者开源的OCR/版面还原方案可以输出类似下面这样的结构化对象{ page: 12, type: heading, level: 2, text: 3. 主营业务收入构成 } { page: 12, type: table, rows: [ [产品类型, 收入万元, 占比], [A产品, 18452.30, 62.3%] ] }这种结构化输出才是后续一切操作的靠谱基础。没有它后面做的所有优化都只能靠运气。2. 文档解析实战三类常见格式的解析方案与避坑记录2.1 PDF解析PyMuPDF和pdfplumber哪个适合你PDF几乎是企业文档里绕不开的格式。它有两种截然不同的存在形式原生PDF文字可以直接提取和扫描版PDF本质是图片需要OCR。处理方式完全不同我先聊原生PDF。原生PDF解析我常用的两套工具是PyMuPDFfitz和pdfplumber。很多人让我推荐一个我说这得看场景PyMuPDF的优势是快解析一个几十页的PDF只需一两秒且能同时提取文本、矩形框、图片位置。适合做大体量文档的批处理、版面初筛、按坐标切块pdfplumber的优势是表格提取精准它针对文本坐标做了很多细腻的微调能把规则表格还原成列表结构。缺点是慢大文档加上复杂表格能慢到你怀疑人生。我在处理招股书、财报这类“表格密集”文档时通常先用PyMuPDF做快速的页面分析和文本定位遇到坐标重叠密集、有大量横竖线的区域再切换pdfplumber单独解析那一页的表格。下面是PyMuPDF解析文档基本信息与文本片段的最小示例import fitz # PyMuPDF doc fitz.open(年报.pdf) page doc[0] text page.get_text(text) blocks page.get_text(dict)[blocks] for b in blocks: if b[type] 0: # 文本块 for line in b[lines]: for span in line[spans]: print(span[bbox], span[text])这里我用了get_text(dict)拿到的不是单纯字符串而是带bbox边界框、字体、字号、颜色信息的blocks。有了坐标和字体信息我们才有资格谈“识别标题层级”通常字号最大的居中文本是章标题跟正文同字号但加粗、或者单独占据一行且编号类似“1.1”“第一章”的是二级或三级标题。如果你不想自己写规则也可以把文档转成图片后交给现成的版面分析模型去做标题检测但那种方案成本高一些。扫描版PDF就是另一套玩法了。核心思路是先渲染成图片再OCR。我个人比较推荐的做法是用PyMuPDF把页面渲染成高分辨率图片再用PaddleOCR或Tesseract做文字识别。PaddleOCR对中文财务表格的还原度明显好于Tesseract。这里有几个关键参数要注意渲染分辨率要适中。一般设200~300DPI太低文字小到OCR认不出来太高图片体积暴涨、识别速度变慢OCR前做一步图片预处理灰度化、二值化、去噪点识别率提升非常明显对于表格OCR之后最好再跑一步表格结构还原光文字识别出来还不够行列对应关系还得重建。我在一次处理“某银行十年财报扫描版”时PaddleOCR识别出的直接结果是带坐标的文本行列表随后我根据坐标里“x接近对齐”的多个文本行聚类成同一列根据y的增长切分行最终重建出1000多个表格记录。这个过程看起来土但在没有商用版式还原API的情况下它就是最可控的方案。2.2 Word解析不要只盯着python-docx的readWord解析相对友好因为.docx本质是一个zip包内部是XML结构文本、样式、表格是分离存储的。python-docx库能覆盖大多数场景但很多人用这个库只调document.paragraphs拿到段落然后调表格.tables拿表格完全忽略了一个关键结构段落大纲级别outline level。Word里的标题层级是通过“标题1”“标题2”这类样式体现的python-docx里可以这样拿到每个段落的样式名from docx import Document doc Document(产品手册.docx) for p in doc.paragraphs: style_name p.style.name if style_name.startswith(Heading) or style_name 标题 1: level style_name.split()[-1] print(level, level, text:, p.text)拿到style_name之后你就能在切片阶段做“层级感知切片”——遇到二级标题就开新chunk遇到三级标题则继续累积。没有这一步Word文档在你的系统里就跟txt没有区别。另外Word里的表格必须单独处理。python-docx里每个表格的rows和cells可以完整还原行列关系但是表格前后的空段落、正文混合情况会带来干扰。我的做法是把文档拆成“正文流”和“表格对象”两个通道正文流进入文本切分器表格对象单独做结构化存储并在正文流的对应位置打一个“此处有表格XX”的锚点标记。这样后续可以按需把表格内容取出来单独拼接进上下文而不是把表格压成文本混进正文里。2.3 HTML/网页文档解析清理噪声是第一步企业内部知识库还有大量内容是HTML形式的历史归档爬虫或旧系统导出的页面里面通常塞满了导航菜单、面包屑、侧边栏广告、版权声明。如果你直接把它当文本丢进解析流程那chunk里一半都是噪声。我处理HTML的思路分三层去掉script和style标签把可见内容提取成带结构的block识别并丢弃“重复区块”——导航栏在每一页都出现语义价值极低还得清洗掉保留h1-h3作为标题层级信号保留li的列表层级保留table的行列结构。代码层面用BeautifulSoup做清洗最顺手核心操作是连续剔除噪声节点from bs4 import BeautifulSoup html open(page.html, encodingutf-8).read() soup BeautifulSoup(html, html.parser) for tag in soup([script, style, nav, footer, aside]): tag.decompose() for header in soup.find_all([h1, h2, h3]): level int(header.name[1]) print(heading level, level, -, header.get_text(stripTrue)) for tbl in soup.find_all(table): rows [] for tr in tbl.find_all(tr): cells [td.get_text(stripTrue) for td in tr.find_all([td, th])] rows.append(cells) print(table rows:, rows)注意不同站点生成的HTML结构差异巨大靠统一规则做清洗永远会有漏网之鱼。我的经验是先做一轮粗清洗然后对剩余文本做信息密度过滤如果某个容器的文本连续超过三页都一模一样八成是导航或者模板噪声直接剔除。2.4 解析后的质量校验没有校验的解析等于没做很多人解析完文档就直接进入切片从不对结果做校验这是大忌。我建议至少做三级校验文本完整率对比原文档总字符数与解析结果总字符数正常应该在90%以上数字型表格丢失严重时可能低于这个值得排查。结构完整率人工抽查10页左右的标题、表格确认标题层级编号连续、表格行列数与原文档一致。乱码检测检测连续替换字符“”、UFFFD和异常控制字符的比例。这些校验写成自动化脚本并不难却能帮你提前发现解析器选用错误等到检索阶段才发现是解析问题成本就高了。3. 切片到底切的是什么策略、参数与Python切片原理3.1 切片的核心矛盾语义完整与检索粒度之间的拉扯切片chunking的本质是把解析后的一段长文本切分成多个固定或有边界的片段每一个片段未来都会被向量化并存储到向量库里。这里就存在一对核心矛盾切片太大向量化后语义被稀释同时检索冗余信息多浪费token切片太小单个片段语义信息不完整检索出来的片段上下文缺失大模型难以生成正确答案。这个矛盾没有标准答案只能配合你的实际场景做参数调优。但有一个底层的把握原则切片边界尽量贴合“语义自然边界”——段落结束、章节结束、表格结束而不是把一句话硬生生腰斩。所以不要一上来就写text[start:start chunk_size]这种固定步长切片虽然简单但它频繁制造半句残句。更好的做法是“固定最大长度 允许回退到最近的语义边界”。3.2 Python数组切片与列表切片文档切分背后的基础操作热搜词和大家的搜索习惯里python数组切片和列表切片是被问得很多的内容因为切片这个动作最终落到代码上其实就是在做字符串和列表的切片操作。Python的切片语法很简洁s 你好世界。今天天气不错。 # 基础切片 sub s[0:5] # 取前5个字符 sub2 s[-6:] # 取最后6个字符 sub3 s[::2] # 每隔一个字符取一个对列表而言也是一模一样的逻辑nodes [标题, 正文, 表格, 图片, 结尾] part1 nodes[0:2] # [标题, 正文] part2 nodes[-2:] # [图片, 结尾] part3 nodes[1::2] # [正文, 图片]文档切分器的本质就是对解析出的文本节点做“范围选择”从哪个字符切到哪个字符跳过哪些中间内容要包含多少重叠区域。例如按段落切分时你在一个段落列表里循环用切片的起始和终止索引决定当前chunk包含哪几个段落。所以理解列表切片语法对写出正确的切分器很重要。但文档切片不会只有这么简单因为长度是按token或字符计量的切片边界必须按语义回退。下面这段是我常用的一个“先按目标长度切再回退到句子边界”的简化实现import re def split_text_into_chunks(text, chunk_size, overlap): sentences re.split(r(?[。.!?])\s*, text) chunks [] current start_idx 0 for sent in sentences: if len(current) len(sent) chunk_size: current sent else: if current: chunks.append(current) # 计算overlap从上一个chunk尾部取overlap长度的文本 tail chunks[-1][-overlap:] if chunks else current tail sent # 防止单句过长导致死循环这里做了超长句强制切分保护 if len(current) chunk_size: current current[:chunk_size] if current: chunks.append(current) return chunks这个版本还有很多粗糙处但方向是对的以句子为最小不可切开单元以chunk_size为硬限制用尾部文本作为overlap来保持上下文衔接。3.3 三种常见的切片策略与适用场景我按工程实践中的频率把切片策略分成三种第一种是固定字符数切片。最简单对长文本按固定长度直接切适合文档没什么结构、纯叙述体、不需要模块化检索的场景。缺点前面说了语义边界破碎严重。作为兜底方案可以作为主方案不推荐。第二种是基于段落的层级切片。利用解析阶段得到的段落、标题层级、列表结构把同一二级或者三级标题下的内容归到同一个chunk。这种策略适用于手册、规范、制度文件等结构清晰的文档它的chunk与“章节”一一对应检索命中后返回的语义单元非常完整。缺点是碰到长章节单个chunk可能过长碰到无法识别结构的劣质解析结果这个方法直接崩掉所以它对前端解析有要求。第三种是递归字符切分。这是LangChain等框架里很常用的一种策略先设定最大chunk_size然后把文本切到句子列表再按句子列表累加成块若单句超过上限再做二次硬切。实际代码里用的是RecursiveCharacterTextSplitter它定义的separators列表是[\n\n, \n, 。, , ]切分时优先用段落换行符其次句子标点最后才是硬切。这种策略兼顾了语义边界和实现复杂度是大多数项目的最佳实践起点。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap150, separators[\n\n, \n, 。, , , ] ) chunks splitter.split_text(long_text)注意这个库默认按字符长度切并不统计token。如果你用的是OpenAI类模型建议加一个tiktoken的length_function做token计费否则800字符和800 token消耗差很多。中文通常1个汉字约等于0.6~1个token不同模型不一致在需要精确控token的场景里别凭感觉。3.4 chunk_size和overlap怎么定一个具体的计算示例很多人问的最实在的问题就是chunk_size到底设多少overlap设多少我直接给一个推算路径。假设你要做一个企业制度问答知识库里每篇文档平均一千到三千字用户经常问“请假超过几天要线上审批”这种明确条款型问题。这时核心诉求是一条完整的管理制度条款最好整体落在同一个chunk里。设定原则单条条款平均长度在200~400字那么chunk_size设800~1000字基本能容纳两三条款既保证单条条款不碎也不至于混入太多无关条款overlap需要覆盖“上下文依赖重”的部分通常取chunk_size的15%~20%。800字的chunk我习惯设150字overlap既保留前文的主语、背景信息又不会造成过多重复存储。具体参数计算可以这么推。假设文档总字数3200chunk_size取800overlap取150那么有效新增字符为800-150650chunk数量为第一块覆盖0~800字符第二块从650开始覆盖650~1450以此类推总数量约为 (3200-800)/650 1 ≈ 4.69向上取整是5块。如果你把overlap改成0chunk数量就变成3200/8004块少了一块但两条制度的边界处可能会把一个关键日期切到两个chunk里。多出的一块换来的是内容连续性和检索命中精度这笔账是划算的。另外如果接的是新版长上下文模型有些人喜欢把chunk_size拉到1500甚至2000塞进更多上下文。我不建议这样因为向量检索阶段的召回精度跟chunk大小不是线性关系长chunk会让单块的语义主题变多向量表示更模糊检索结果容易跑偏。除非你的场景是“整章问答”而不是“条款检索”否则800~1200是多数中文场景的安全区间。4. 全流程整合从文档入库到切片落地的一条可复现流水线4.1 流水线设计要点解析和切片不是孤立的两个步骤中间还夹着清洗、归一化、元数据提取。我习惯把流水线拆成五段文档接入与格式识别根据扩展名或文件头判断PDF/Word/HTML/纯文本路由到对应解析器结构化解析输出带类型标注heading、paragraph、table、list、code的文档对象列表文本清洗与噪声抑制去页眉页脚、去页码、合并孤立的段落碎片、修复OCR常见错误切片策略执行按文档类型选择固定切分或层级切分产出chunk列表并附加source_page、标题路径、索引序号的元数据质量校验与导出记录每个chunk字数、切片数、畸形率输出格式化为JSON或后续向量化需要的记录。每段之间我强烈建议加上监控日志尤其在第四步所有chunk都要打出源头文档ID、来自哪个章节、在文档内部的位置序号。这样线上检索出错时你能从命中chunk反查到解析环节快速定位是哪一步出了问题。4.2 一个可跑的解析加切片Pipeline我写过一个简化版的流水线核心逻辑是这样from docx import Document import fitz import json def parse_and_chunk(file_path, file_type): if file_type pdf: text_blocks extract_pdf_blocks(file_path) elif file_type docx: text_blocks extract_docx_blocks(file_path) else: text_blocks extract_txt_blocks(file_path) # 按层级保序生成带title_path的句子流 node_list [] for block in text_blocks: node_list.append({ type: block[type], level: block.get(level, 0), text: clean_noise(block[text]), page: block.get(page, 0) }) chunks [] current_chunk current_path [] for node in node_list: if node[type] heading: current_path current_path[:node[level] - 1] current_path.append(node[text]) if current_chunk: chunks.append(current_chunk) current_chunk elif node[type] paragraph: if len(current_chunk) len(node[text]) 800: chunks.append(current_chunk) current_chunk current_chunk[-150:] node[text] else: current_chunk node[text] \n if current_chunk: chunks.append(current_chunk) return chunks这个pipeline里用到的extract_pdf_blocks和extract_docx_blocks就对应前面章节里那段读取逻辑。可以说整个流水线并不复杂难点全在解析模块的“结构完整度”以及切片模块的“边界回退”。但这里必须再次强调我这个pipeline是简化版真实项目中还需要并行处理、断点续跑、失败重试因为企业文档集合动辄几万份文件单线程一分一秒地跑是熬不出成果的。4.3 如何验证切片质量而不是靠感觉切片做得好不好不能靠你看一两个例子“感觉还行”就拍板。我有两套验证方法一套偏离线人工一套偏在线评估。离线方法是人工抽检随机抽取50个chunk写一个简单的判断标准——每个chunk是否语义完整有没有一句半句被切断每个chunk是否包含明确主题一段关于预算制度的chunk里不应该混进半段招聘流程每个chunk的标题路径title_path是否准确能否让人只看元数据就判断出它在文档里的位置评分可以简单划为优良中差四档好切片的优秀率应在80%以上。达不到的话优先调chunk_size和overlap而不是马上改向量模型。在线方法是对检索结果做端到端评测准备30~50个“问题-答案-来源段”三元组把答案所属的来源段改成对应chunk跑一遍检索统计命中率。如果Q(问题)明确指向档案第某页某条款但检索返回的是同一文档里的另一个chunk那你基本可以确认是切片把条款切碎了。我个人是两种都跑。离线抽检在开发期每天做省时间在线评测在调参期每周做一轮用数据说话。5. 常见问题与排查技巧实录5.1 PDF表格解析成碎片症状解析出来的表格数据丢失表格里的多列挤在一起或者行列顺序错乱。 排查方向先判断PDF是文本型还是扫描型。文本型PDF优先检查是否走的pdfplumber的extract_table接口而不是get_text里的纯文本抽取扫描型PDF辨认文字后还要做行列重建如果直接调OCR得到的是无坐标文本等于只做了一半。经验心得是财务年报中的复杂表格合并单元格、跨行表头没有哪款开源库能百分百还原。能做的只有分级处理简单规则表格用pdfplumber直接还原复杂表格宁可整体截成图片存储检索时按整表返回也别强行把文字表打散。让大模型直接看图片在这类场景下往往比吃碎表格文本靠谱得多。5.2 标题层级识别不准导致切片跨章节症状两个不同章节的文本被合进同一个chunk或者章节开头的内容莫名其妙挂到了上一个chunk的末尾。 排查方向回看解析环节输出的heading节点是否正确。如果源头就没有把二级标题识别出来切片器当然不会按照章节边界切。这里有个非常容易被忽视的坑Word和PDF里很多“假标题”只是正文加粗或者字号稍微大一点并没有落在标准标题样式上。解析器如果只认“样式名以Heading开头”那这些假标题就被当成了普通段落。我的对策是自定义一个标题归属规则正文字号范围先统计出来凡是字号超过正文中位数1.2倍以上或带有“第X章”“X.X”这类章节编号模式的段落一律视为标题并识别其层级。规则可能不完美但配合人工抽查修错比完全依赖样式名靠谱。5.3 代码块和公式被拦腰切开症状文档里混有代码或公式时按段落切分把代码块切成了两半检索出来的代码不完整甚至出现语法残缺。 这类内容的边界往往不含段落换行符而是被缩进、块级结构或公式渲染器特殊标记包围着的。切分时对这类特殊节点要单独设定“不可分割”标记如果某个解析节点被标记为code_block或formula就永远整块保留即便长度超过chunk_size也不拆宁可这个chunk超长一点也胜过把代码切开。我之前对接过一个技术团队的操作手册里面有几百段shell命令最初切碎后检索效果极差改成代码块整存整取后回答准确率提升非常明显。5.4 chunk碎片化指数偏高症状整个库里大量chunk只有几十个字向量化后内容高度相似检索出现大量重复结果。 排查方向算一下平均chunk长度和中位数chunk长度两者差距过大说明有大量超长块和碎块并存。超长基本来自标题层级切分时的长章节章节碎块来自overlap设置不合理或长句硬切后的残留尾巴。我给自己定过一个经验阈值平均chunk长度低于chunk_size的一半时说明切分策略偏碎该返回去调解析或切分器参数。碎片化的直接后果是向量库体积变大、检索耗时上升、重复内容多而这几个问题在项目初期几乎引不起注意等用户量上来才会集中爆发。5.5 常见问题速查表症状可能原因优先排查项表格内容乱序且不完整PDF表格未被结构化解析确认是否用pdfplumber的表格提取接口扫描版确认有无行列重建HTML文档chunk里全是导航菜单未做噪声区块清洗检查是否剔除nav/footer/script/style是否做重复区块过滤检索结果跨章节标题层级识别失败回看解析阶段heading节点输出补自定义标题规则同一段内容被重复召回多次overlap过大或chunk过碎减少overlap到10%~15%检查异常碎块代码块被截断特殊节点未做不可分割保护对code/formula节点单独处理整块入chunk大模型回答“找不到相关信息”但库里明明有切片时把关键条款切碎了用目标条款做定向验证人工检查该条款所在chunk6. 一点私货关于工具选型和成本控制的体会聊到工具选型我还想多说几句。现在市面上做文档解析的轮子很多传统开源库、云服务商的文档解析API、本地部署的版面分析模型、商用AI知识库平台自带的解析器每个都有它的适用边界。我的建议是不要神化任何一个工具它们本质是“在解析质量和运行成本之间取一个平衡点”的选择。如果你处理的是几百份内部规范文档结构相对规整开源库加自写规则完全够用如果你每天要灌入上万份来源复杂、格式千奇百怪的网页和扫描件那确实值得花钱用更强的商业解析服务或者专业OCR系统。反过来如果文档量不大但包含大量复杂表格和图表商用解析服务省下的时间人力成本可能远比license贵。关于运行成本我提醒一句切片粒度直接决定向量库的存储成本和检索开销。把chunk_size从500调到1000向量条数理论上减半但检索质量可能下降超过30%。千万不要为了省钱盲目放大chunk也别为了视觉效果切得过小。我一般建议先按“检索质量优先”配好参数再根据实际体量评估是否需要优化存储而不是一上来就抠成本。到这儿解析和切片这块的核心闭环基本都走了一遍。从解析工具的选型到结构化节点的抽取从切片策略的选择到参数计算再到最后的质量校验每一步我踩过的坑都毫无保留地放在了上面。这个环节没什么花哨的模型大多时候就是基础的Python切片语法加一点工程判断力但恰恰是这段看起来没什么技术含量的代码决定了你后续检索系统到底是在平地盖楼还是在沼泽上搭积木。先花一周把地基砸实后面你会感谢自己。