开头我先说个事。上个月有个朋友找我调一个知识库问答项目，他折腾了两周，向量检索的召回率始终上不去，最后发现根子不在向量模型、不在Embedding微调，而是最前端的文档解析和切片那一层就做歪了——PDF里的表格被识别成一段连续文本，固定长度切片后一句话被拦腰切断，这样的数据喂进去，后面你用什么模型都救不回来。这正好应了那句話：地基打歪了，后面全白搭。今天这篇就专门聊文档解析与切片，讲清楚这两步到底怎么做才算合格，以及在实操里你一定会遇到的坑。
很多项目团队习惯把精力放在模型选型和Prompt调优上，却把文档解析当成一个"装个库就能跑"的预处理步骤，这是很危险的想法。文档解析解决的是"文件内容怎么变成干净、结构完整的文本"，切片解决的是"这段文本怎么切成适合向量化的片段"，两者决定了后续Embedding、检索、重排的数据质量上限。我的经验是，这两步值得投入整个RAG项目至少40%的时间去做验证和调优，否则后期每改一次切片参数，前面解析的返工成本都会让你痛不欲生。
1. 解析和切片出错时，后续环节是怎么被"传染"的
1.1 每个环节的错误会一路放大，而不是被纠正
先建一个直观的模型。一条数据从原始文档走到最终回答，会经过：文档解析 → 清洗归一 → 切片 → 向量化 → 存储 → 召回 → 重排 → 生成。大多数人以为这是一个线性流水线，每个环节独立工作，前面的小错误后面能"自动消化"，但实际情况恰恰相反——这是个误差放大器。
举个例子。一份PDF里有一个三列的报价表格，解析工具把表格转成了纯文本，三列数据被强行拼接成一串："型号A价格1200库存充足型号B价格800库存不足"（我就用真实的错误格式来说明）。此时切片器不知道这是表格，按固定窗口500字符去切，恰好把"型号A价格1200"切到上一个块，把"库存不足"切到下一个块。向量化阶段，这两个块各自在向量空间里跟其他文本混在一起，检索时用户问"哪个型号有库存"，系统无法从任何单一块里拿到完整信息，召回结果自然谬以千里。更麻烦的是，重排模型拿到的也是残缺片段，它没有能力去把分散在两个块里的信息拼起来——它不是推理器，它只是在排序。
所以你要接受一个事实：后续环节没有纠错能力，它们只会把你的错误变成更难排查的问题。
1.2 "能读出来"不等于"解析对了"：质量标准的重新定义
很多初次接触文档解析的人，验证解析效果的方式是打开输出文本看一眼，"哎，文字都在啊，行了"。这远远不够。"能读出来"只是第一关，真正的解析质量标准包括：
- 文本完整性：内容没有缺页、缺块、缺字符。扫描件尤其容易出这个问题。
- 结构保留：标题层级、段落边界、表格行列、列表编号在文本格式里仍然可辨识。
- 阅读顺序：多栏PDF、图文混排的页面，内容必须按人眼阅读的顺序输出，而不是按物理坐标输出。
- 非文本元素处理：图片里的关键信息有没有OCR，图表标题是否被保留，页眉页脚是否被合理处理或剔除。
我习惯用一个很笨但有效的验收方法：解析完成后，随机抽10页原文，对着解析后的文本逐段核查，记录每一类错误（表格错乱、栏序颠倒、字符丢失、多空行乱入）的数量。只要结构类错误（表格错乱、栏序颠倒）出现次数超过抽检页数的10%，这批数据的解析就不合格，必须换方案重跑。不要凑合，后面你会为这个"凑合"付出十几倍的时间。
2. 文档解析的选型逻辑：不同格式，不同战场
2.1 先按文档格式分类，再定解析路线
文档解析第一个要摆脱的思维是"一个工具打天下"。不同类型的文档，底层结构完全不同，适合的解析工具也南辕北辙。我个人会把常见文档分成四类：
| 文档类型 | 典型格式 | 主要难点 | 推荐解析路线 |
|---|---|---|---|
| 排版型文本 | PDF（非扫描）、Word、Markdown、HTML | 多栏、表格、嵌入图片 | 规则解析 + 结构感知工具（如LlamaParse、Marker） |
| 扫描影像 | 扫描PDF、图片、传真件 | OCR识别率、版面还原 | OCR引擎（PaddleOCR、Tesseract）+ 版面分析 |
| 表单类 | 带固定栏位的表格、填报表 | 单元格对齐、跨行跨列 | 表格识别专用工具（Table Transformer等） |
| 网页长文 | 在线文档、微信公众号文章、博客 | 正文抽取、噪音去除 | Readability类算法 + 链接结构补全 |
这里有一个很容易踩的坑：很多人拿到一份混合类型的文档——比如一份包含扫描页的PDF，前面30页是电子排版，最后10页是纸质扫描——直接用单一工具跑到底。正确做法是先做页面类型探测，把扫描页识别出来分流给OCR路线，其他页面走排版解析路线，最后再按页码顺序合并。
2.2 扫描件OCR的两个痛点：识别率与版面还原
扫描件文档解析，最核心的指标不是"字符识别率"，而是"识别结果能不能用"。字符识别率95%看起来很高，但落在实际操作里，每20个字符就错1个，一个包含产品编号、价格、库存的表格字段密集区域，错误率会成倍凸显。
处理扫描件我一般走两层：
第一层是图像预处理。在喂给OCR引擎之前，先做灰度化、二值化、去噪、倾斜校正。倾斜超过2度的扫描页，直接进OCR引擎，识别率会肉眼可见地下降。这一步PaddleOCR有内置的预处理管线，但如果你的扫描件质量很差（比如手机拍的纸张照片），建议先用OpenCV做一次自适应阈值和透视校正，能明显减少后续的识别错字。
第二层是版面分析。OCR引擎输出的结果默认是一坨带坐标的文字块，你需要用版面分析模型识别出哪些文字块组成标题、段落、表格、页眉页脚，然后按区块重新组织。PaddleOCR的PP-Structure V2在这一步表现不错，它能把表格结构还原成HTML格式返回，比拿到纯文本再手动切列要可靠得多。
实测经验：扫描件解析的耗时往往是非扫描件的5到10倍。如果你的项目需要处理大量扫描件，一定要在架构设计阶段就考虑异步处理队列。我在一个项目里用过异步任务池，一个小时内处理了3000页扫描件，是同步处理完全做不到的量级。
2.3 表格解析：看起来最像技术题，其实最像语文题
表格是文档解析里最常见的翻车现场。市面上很多解析工具在"识别出表格"这个层面做得不错，但"还原表格的结构"就不行了。我举一个真实场景：一份产品说明PDF里有个四行五列的表格，某工具解析后输出了一大段连续文本，单元格内容用空格分隔，但源码设计复杂，我把它简化成：第一行的表头"型号 价格 库存 状态"和第一列"型号"混在一起，根本分不清哪些内容属于哪个单元格。
处理表格有两条路线，我两个都在用，互为兜底：
- 基于坐标的单元格切割：利用解析工具输出的文本框坐标，按行列聚类，这种方式适合规整的表格，速度快，处理简单表格是首选。
- 基于模型的表格结构识别：用专门训练的表格结构模型（比如Table Transformer）把表格识别成HTML结构，再解析HTML拿结构化内容。适合有合并单元格、复杂嵌套、跨行跨列的表格。
我的建议是，对于数据密度高、价值高的表格（比如合同清单、报价表、参数对照表），直接走模型路线，别省这个算力。这种表格一旦解析错误，下游切片和召回阶段的连锁反应会特别严重。
3. 切片的真正难点：让文本块对齐用户的提问粒度
3.1 切片粒度：一个"对齐"问题，不是"大小"问题
切片的本质不是把文本切成一段段，而是让生成的每一个文本块，在语义上足够自洽，能够独立回答某类问题。
这里有一个关键概念：提问粒度。不同的用户问题，需要的信息范围完全不同。问"这台手机支持5G吗"需要的是一个包含规格参数的小片段，可能两句话就够；问"这款产品在哪些市场表现最好"需要的是跨多个章节的数据汇总。固定长度切片最难处理的就是这种粒度差异——你切的尺寸偏小，长上下文类问题信息不足；尺寸偏大，短问题检索时又引入太多噪音。
我常打一个比方：切片是给文本做"裁衣"，不是为了把布裁成等大的方块，而是为了让人（检索系统）拿到一件能直接穿的衣服。你的Embedding模型决定了"衣物布料"的纹理质量，但裁剪方式直接决定穿不穿得出去。
3.2 三种主流切片策略的适用边界
根据文本特征和检索需求，切片策略可以分成三类，每类的适用场景差异很大：
固定长度切片（Fixed-size Chunking）
按预设字符数（token数）切块，块与块之间加重叠（overlap）。这是最省事、最通用的方案，但它的缺点是语义边界经常被拦腰切断——一个完整段落、一个完整表格，可能在中间被切成两半。它的适用场景是：你的文本本身结构不复杂、内容比较"均匀"（如新闻资讯、产品评论），或者你只是需要一个快速可用的基线版本。
段落/标题感知切片（Structure-aware Chunking）
先识别文档的标题层级和段落边界，再以段落为单位进行聚合或合并。标题是天然的语义分割点，用标题来约束切片边界，能让每个块保持语义完整。适用场景是：长文档、技术手册、政策文件、教学讲义——这些文本有清晰的章节层级，用户的问题通常围绕某个章节的内容展开。我在多个项目里实际体感是，这类切片的检索效果比固定长度切片稳定得多。
语义切片（Semantic Chunking）
利用语义相似度或Embedding的边界特征，在语义"断点"附近切块，保证每一块内部的语义连贯。这种策略最适合内容主题频繁切换、口语化、非结构化程度高的文本（如会议纪要、客服对话记录）。但它有一个成本问题：需要在切块时做一次Embedding计算，耗时是前两种的几倍。用了它，你要做好离线处理时间变长的心理准备。
3.3 结构化感知切片：一个兼顾"语义完整"和"检索效率"的折中
我在实际项目中搭建了一套"结构化感知"的切片管线，原则很简单：先识别文本的结构骨架，再沿着骨架切，具体步骤为：
- 解析文档时，同步输出每个段落的标题层级（H1、H2、H3）。
- 以最低层级标题（比如H3）为最小切片单元，把同属于上一个H2标题下的多个H3段落合并为一个候选切片。
- 对候选切片做长度检查——如果超过设定的上限（我常用1200 token），再按段落边界二次切分；如果低于下限（我常用200 token），与相邻切片合并。
- 切片与切片之间允许保留5%到10%的重叠，确保跨块的关联信息能被向量检索捕捉到。
这套管线看起来很朴素，但它把"标题层级"这个廉价到几乎免费的结构信息用起来了，效果却常常好于昂贵复杂的语义切片方案。在一个企业知识库项目中，用这套管线对比普通固定长度切片（512字符），检索命中率（Recall@5）提升了大概9个百分点。谁的功劳？大半是"沿着标题切"这个动作，让每个切片变成了一个语义自洽的单元。
4. chunk_size 与 overlap：参数背后是召回逻辑
4.1 两个参数到底在控制什么
很多人把chunk_size和overlap当成两个"调参手感"参数，随意试探。但它们的本质是硬约束：
- chunk_size决定"每个检索单元的信息容量"。容量太小，信息不完整，语义密度不够；容量太大，检索单元内噪音增多，向量相似度被稀释，检索精度下降。
- overlap决定"边界信息的跨块保留程度"。它补偿的是切断带来的上下文丢失，但也带来了两个副作用：向量库存储膨胀（通常增加10%~20%），以及相邻块之间的检索结果重复（重排时要去重）。
关于chunk_size和token数，还有一个常见的误解：chunk_size设的token数，不是字符数。在中文场景，1个token大约等于0.5~1.5个汉字（取决于分词器和模型词典），所以"512 token"不等于"512个汉字"。我见过有人把512 token当成512字来设，结果切片比预期的小了一半，信息碎片化严重。
4.2 一个从512调到256再调回400的真实案例
我有一个实际调参案例，可以完整呈现参数调整的逻辑链。
项目背景：一份企业内部规章制度合集，共2000多页，内容以条列式、段落式为主，用户的问题是"申请年假需要提前几天""报销差旅费的流程"。初始设定我选的是chunk_size=512 token、overlap=50 token。
实测效果：检索结果经常出现"只召回半段流程，后半段内容在下一个块里"的情况——用户问流程，回答到一半就断了。把chunk_size降到256后，情况更糟：短文本的检索精度略有提高，但长流程类问题因为信息被切得更碎，召回质量下降明显，因为一个完整流程本来就需要400多token，切成256后必然被切两段。
最终方案：把chunk_size调到400 token、overlap设为60 token，同时配合结构化感知切片（优先按标题切，标题长内容超过400 token才强制切）。最终，长流程类问题的完整性从62%提升到91%。
这个案例给到的经验是：chunk_size的初始设定不要拍脑袋，先统计你文档里完整语义单元（段落、小节）的平均长度，把chunk_size设为这个长度的1.2到1.5倍，通常是个稳妥起点。如果文档本身杂，建议多跑几组参数做评测对比，而不是凭感觉定值。
4.3 判断切片质量的两个量化指标
切片切得好不好，不能靠肉眼"看着顺不顺"。我用了两个量化指标来把关，推荐给所有做这个环节的人：
一是语义完整率（Semantic Completeness）。抽样200个切片，逐一判断每个切片是否包含至少一个完整的语义单元（一个完整段落、一个完整小节、一个完整的表格）。语义完整率=完整切片数/抽样总数。我要求的及格线是90%以上，低于80%说明切片粒度或边界策略有严重问题。
二是单块召回准确率（Single-chunk Hit Rate）。构造一组测试问题，每个问题的标准答案都包含在某一个特定切片内，检索系统能否直接命中这个切片。这个指标衡量的是"切片是否与问题对齐"。如果这个指标低于70%，通常不是Embedding的问题，而是你切片切得跟用户提问方式不对齐。
这两个指标设置起来不难，但在项目早期能帮你快速发现"地基本来就是歪的"。
5. 一次完整事故复盘：PDF表格错乱如何拉低准确率12%
5.1 问题的暴露：用户问"哪个型号有货"，系统答非所问
这个事故发生在三个月前。当时我负责的一个产品知识库已经上线，基础检索效果看着还行。直到有一天业务同事反馈：用户问"哪个型号有货"，系统回答了一堆产品介绍，但就是没有"有货/没货"的信息。
这个问题的诡异之处在于，系统看起来在正常工作——它召回了一段关于库存状态的产品文本，内容也"相关"，但没有直接回答用户的问题。如果你只看粗粒度指标（比如召回内容与问题主题是否一致），你会觉得没毛病。可用户真正想要的"哪个型号有货"，在召回片段里根本不存在。
5.2 排查链路：从向量检索一路回溯到文档解析
我开始定位。先检查向量检索的中间结果：用户问"哪个型号有货"，召回的Top5里有两个是产品介绍页，一个是产品参数表，两个是FAQ。看起来覆盖面还行，但仔细看，参数表里"库存"那一列全是空的——哦，不是空的，是解析出来后库存字段跟"状态"字段的内容拼接在一起了，根本没法形成独立语义。
回到文档解析那一步。原始文档里的产品规格表是PDF里的一张表格，解析工具输出的结果是"型号 价格 库存 状态"+每行单元格内容，但表头与单元格的对应关系丢失了，库存状态就混在了一大段连续文本里。再把这段连续文本喂给固定长度切片器，它按256字符切块，恰好把一个型号的"库存充足"信息切到上一个块，另一个型号的"库存不足"信息切到下一个块，于是每个块都变成"半截答案"。我拉出这条链路后跟团队复盘，结论很简单：不是模型选错了，不是切得太小，而是表格解析这一步就崩了，导致切片边界永远切不到正确的信息单元上。
5.3 修复动作与效果验证
修复动作我拆成了三步：
第一，替换表格解析策略。对含表格页面走专用的表格结构识别模型，输出HTML表格结构，再做结构化提取，确保"型号、价格、库存、状态"各归其位。此处排查了一个常见坑：表格模型输出的坐标框在个别页面上偏移严重，需要加一个边缘校验逻辑——如果单元格坐标跟文本内容归属冲突，人工标记后重跑。
第二，在切片管线里增设"表格感知"规则。切片前先识别页面中的表格区块，表格区块默认不参与普通文本流切片，每个表格作为一个独立切片单元；表格过大时按行分组切分，保证每行内部完整。这一步彻底解决了"表格被拦腰截断"的问题。
第三，重跑评测集。我构造了50个"型号+属性"的问题，比如"型号A的库存""型号B的保修期"。修复前，单块召回准确率只有58%；修复后达到了87%。整体RAG问答准确率从原来的74%回升到86%，比最初的基线还高了几个点——因为表格结构提取出来后，知识库的整体数据质量也顺带提升了。
这次复盘给我留下的最深印象是：一次糟糕的文档解析，害得前后端团队白白排查了两周，而问题真正的根源只藏在最开始的一个参数里。所以我现在做项目，文档解析和切片一定是最先进入验收环节的部分，绝不再让基础数据带着隐患往下游走。
6. 参数调优和工具替换之外，容易被忽略的三件小事
6.1 统一文本清洗规则，先清洗再切片
在解析和切片之间，还有一道容易被跳过的工序：清洗归一。不要小看这一步。实际文档里会混入全角半角混乱、多余换行、无意义字符、页眉重复内容、OCR误识别产生的标点噪声。如果不做清洗，切片时换行符和空格可能干扰Embedding的语义建模。
我建议在解析输出后，先跑一个统一的清洗脚本，做的事包括：统一换行符为\n、折叠连续空行、剥离页眉页脚的重复模板内容、把全角数字和标点转半角（中文标点保留全角）、清理HTML/XML残留标签。清洗完再切片，切片效果会更干净。
6.2 切片后加一步"语义指纹"去重
切片之后、向量化之前，强烈建议做一次精确的语义指纹去重。文档集合里经常出现重复内容——同一段文字在多个文档中重复出现、OCR误输出重复行、表格行被重复解析。这些重复会造成检索时同一信息被多次召回，不仅浪费存储空间，还扰动重排结果。
做法不复杂：对每个切片计算一个短文Hash（比如MD5+SimHash），在库内做一次去重。SimHash的汉明距离小于3的切片视为重复，保留最早出现的一条即可。这一步对长文档库收益明显——一个去重跑下来，向量库里少了17%的冗余切片，检索性能和准确率都有提升。
6.3 给切片号编上"来源脉络"，排查时救命
最后一个小但极其实用的建议：切完的每一片，都必须保留来源元数据——原始文件名、页码、标题路径（比如"H2-产品参数 > H3-规格表"）、切片序号。这些元数据不参与向量化，但会作为检索结果返回的辅助信息。
它最常用的场景是排查。当用户反馈"答案不对"时，你查一下命中的切片来源，马上能定位是解析问题还是切片问题还是模型问题。我在事故复盘里能快速梳理出表格错乱链路，很大程度上就是靠这些来源元数据撑起来的。没有这个，排查链路至少要慢一倍。
这个内容后续我还会写"篇三：向量化与检索排序"，不过那已经是建立在地基打好的基础上了。如果你正在做RAG相关项目，我的建议是：耐心一点，把解析和切片做得笨但扎实，后面你会感谢现在的自己。
