图文混排的 PDF 和扫描件是 RAG 数据导入环节里最容易被低估的一块硬骨头。很多人做知识库时默认“PDF 就是文字”结果一上手发现合同是扫描件、产品手册是图文混排、财报里关键数据全在图表里、PPT 导出的 PDF 文字层错乱到没法看。纯文本抽取工具在这些场景下几乎全军覆没而 RAG 的上限恰恰由数据导入的质量决定——垃圾进垃圾出检索再强也救不回来。这篇接着上一篇的数据导入话题专门聊图文与 PDF 解析这条链路OCR 怎么选、多模态大模型在什么位置介入、九种 PDF 解析工具各自适合什么场景以及我在实际项目里踩过的那些坑。不管你是刚搭第一个 RAG 知识库还是已经在优化检索召回率这篇里的选型逻辑和实操细节都能直接拿去用。1. 为什么 PDF 解析是 RAG 数据导入的第一道分水岭1.1 文字层 PDF 与扫描件 PDF 的本质差异先把一个基础认知立住PDF 不是一种“格式”而是一个“容器”。同样后缀是 .pdf内部结构可能天差地别。第一类是原生文字层 PDF由 Word、LaTeX、排版软件导出文字以字符编码形式存储附带字体、坐标、字号信息抽取工具能直接读到文本流。第二类是扫描件 PDF本质是一堆图片按页封装没有任何文字信息必须走 OCR 或视觉模型才能拿到内容。第三类是混合型 PDF部分页面有文字层、部分是扫描图甚至同一页里正文是文字、表格是图片。这个差异直接决定了你的解析管线怎么设计。我见过太多人拿 PyPDF2 去抽扫描合同抽出来一片空白还以为是代码写错了。判断方法很简单用pdfplumber或PyMuPDF抽一页如果返回的文本长度接近零但页面明显有内容那就是扫描件。更工程化的做法是在导入阶段就做一次探测按页打标签后续分流处理。提示不要假设一个 PDF 文件内部是同质的。我处理过一份 200 页的技术手册前 30 页是原生文字后面全是扫描的附录如果整份文件走同一条管线要么浪费算力要么丢数据。1.2 解析质量如何一路传导到检索效果RAG 的链路是“解析 → 切分 → 向量化 → 检索 → 生成”解析在最上游它的误差会被后面每一环放大。举个具体的例子一份财务报表里“营业收入 1,234,567 元”如果被 OCR 识别成“营业收入 l,234,567 元”数字 1 变成字母 l向量化之后语义已经偏了用户问“营业收入是多少”时这段文本的召回概率会明显下降。再比如表格被抽成一行行错位的文字“2023 年 Q1 营收”和“2022 年 Q4 营收”的数值串位模型生成时就会张冠李戴。所以解析阶段的目标不是“把字抠出来”而是尽可能保留原文的结构和语义关系段落边界、标题层级、表格的行列对应、图表的标题与说明。这也是为什么单纯的 OCR 不够后面要引入版面分析和多模态模型。理解这一点后面的工具选型才有判断标准——不是哪个工具识别率高就用哪个而是哪个工具在你这类文档上保留的结构信息最完整。1.3 三类文档场景对应的解析策略我把实际项目里遇到的文档粗分成三类策略完全不同。第一类是规整的电子文档合同、报告、论文有文字层优先用文字抽取 版面分析OCR 只作为兜底。第二类是扫描件和图片型文档纸质档案、传真、拍照件必须走 OCR 或视觉大模型重点解决识别准确率和版面还原。第三类是富视觉文档含图表、流程图、公式、多栏排版这类最麻烦纯 OCR 会把图表信息丢光需要多模态模型或专门的版面解析工具。分类之后你会发现所谓“PDF 解析工具选型”其实是在为不同场景匹配不同工具而不是找一个万能解。下面几节我会把 OCR、多模态大模型、PDF 工具这三条线拆开讲最后再给一张选型对照表。2. OCR 引擎的选型逻辑与实战调优2.1 通用 OCR 与文档 OCR 的能力边界OCR 这个领域要分清两个层次。通用 OCR比如 Tesseract、部分云服务的通用接口擅长识别清晰的印刷体对单行文字、简单排版效果好但遇到复杂版面、表格、多栏就力不从心。文档 OCR比如 PaddleOCR 的版面分析模块、专门的文档解析服务在识别文字之外还会做版面检测、表格结构还原、阅读顺序排序输出的是带结构的文档而不是一堆散字。选型时先问自己我的文档是“一行行干净的印刷体”还是“有表格、有多栏、有图注的复杂版面”如果是后者通用 OCR 的原始输出基本没法直接用于 RAG你还得自己写一堆后处理去拼版面成本反而更高。我在早期项目里用 Tesseract 处理产品手册识别率看着不错但输出的文字顺序完全乱套双栏排版被读成左右交错最后不得不换工具重做。2.2 PaddleOCR 在中文文档上的实操配置中文场景下 PaddleOCR 是绕不开的选择它对中文的识别效果、版面分析能力都比较成熟。基础用法很直接from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch) result ocr.ocr(scan.pdf, clsTrue) for line in result[0]: text line[1][0] confidence line[1][1] box line[0] print(text, confidence)但真正影响效果的是几个参数和前置处理。use_angle_clsTrue开启方向分类处理扫描时歪斜的页面很关键我遇到过整页旋转 90 度的档案不开这个参数识别率直接归零。lang参数要按文档语言选中英混排的文档建议用ch它对英文也有不错的支持。另外det_db_thresh文本检测阈值和rec_thresh识别置信度阈值在低质量扫描件上需要调低否则会漏掉模糊的文字。注意PaddleOCR 默认按行输出丢失了段落和阅读顺序。用于 RAG 时你需要根据文本框的坐标box 里的四个点自己做行合并和段落重组按 y 坐标聚类成行、按 x 坐标排序再根据行间距判断段落边界。这一步不做切分出来的 chunk 会是断裂的。2.3 云 OCR 服务与本地部署的取舍云 OCR各家云厂商的文字识别服务的优势是开箱即用、准确率高、支持表格和版面还原缺点是按量计费、有网络依赖、数据要出本地。本地部署PaddleOCR、Tesseract的优势是数据不出域、无调用成本、可离线缺点是要自己调优、要维护环境、复杂版面处理能力弱一些。我的判断标准是看数据敏感性和文档量级。如果是企业内部合同、财务单据这类敏感数据优先本地部署哪怕多花点调优时间。如果是公开资料、文档量不大、追求快速上线云服务更省事。量级上本地部署在几万页以上时成本优势才明显小批量用云服务反而更划算。另外要注意云 OCR 的返回结构各家不同接入时要写一层适配把结果统一成你自己的文档模型否则换服务商时改动会很大。2.4 OCR 后处理从散字到可切分文本OCR 的原始输出是带坐标的文字块直接拿去切分效果很差。后处理要做三件事行合并把同一行的文字块按 x 坐标拼起来、段落重组按行间距和缩进判断段落、阅读顺序排序多栏文档要按栏读不能左右横跳。多栏排序是难点简单做法是按 x 坐标把页面切成左右两半分别处理复杂做法是用版面分析模型识别栏区域。还有一个容易被忽略的点表格处理。OCR 识别表格时单元格文字是散的你需要根据坐标还原行列结构输出成 Markdown 表格或 HTML 表格。这一步做不好表格数据在 RAG 里就是废的。我一般会用专门的表格识别模型PaddleOCR 有表格识别模块或者直接上多模态模型处理表格页。3. 多模态大模型在解析链路中的正确位置3.1 什么时候该上多模态模型多模态大模型能同时理解图像和文本的模型在 PDF 解析里的价值是处理那些传统 OCR 搞不定的页面复杂图表、流程图、公式、手写批注、版面极其混乱的扫描件。它的工作方式是把页面渲染成图片直接让模型“看图说话”输出结构化的文字描述或 Markdown。但不要一上来就全量走多模态成本太高。我的策略是分层处理先用文字抽取和 OCR 处理大部分页面只把识别置信度低、版面复杂、含图表的页面挑出来交给多模态模型兜底。这样既控制了成本又保证了难页面的质量。判断哪些页面需要兜底可以看 OCR 的平均置信度、页面文字密度、是否检测到图表区域。3.2 图表与公式的语义化提取图表是 RAG 里最容易被浪费的信息。一张营收趋势图OCR 只能抠出坐标轴上的数字图表的趋势、对比关系全丢了。多模态模型可以做到识别图表类型柱状图、折线图、饼图、提取数据系列、用自然语言描述趋势。比如把一张折线图转成“2020 到 2023 年营收从 500 万增长到 1200 万年均增长率约 34%2022 年增速放缓”。公式同理纯 OCR 会把公式识别成乱码多模态模型能输出 LaTeX 或自然语言描述。对于技术文档、学术论文这类含大量公式的场景这一步直接决定了知识库能不能回答“这个公式是什么意思”这类问题。3.3 用多模态模型做版面理解与阅读顺序还原除了图表多模态模型还能解决版面理解问题。传统方法靠坐标规则判断阅读顺序遇到不规则排版比如杂志式的图文环绕、侧边栏、脚注就失效。多模态模型可以直接理解“这一页应该先读哪里、再读哪里”输出符合人类阅读习惯的文本流。实操上我会把页面渲染成较高分辨率的图片一般 150 到 200 DPI 足够太高反而增加 token 消耗然后给模型一个明确的指令模板要求它按阅读顺序输出 Markdown保留标题层级、表格结构、图注位置。指令里要强调“不要遗漏任何文字”“表格用 Markdown 表格输出”“图表用文字描述其内容”这些约束能显著提升输出质量。3.4 成本、延迟与准确率的三角平衡多模态模型不是免费的按图片 token 计费一页复杂页面可能消耗几千 token。全量走多模态一份几百页的文档成本会很可观延迟也高。平衡的做法是能文字抽取的绝不用 OCR能 OCR 的绝不用多模态把多模态留给真正需要的页面。同时可以做缓存同一份文档解析一次后把结果存下来避免重复调用。准确率方面多模态模型也会幻觉尤其是图表数据它可能“编”出图上没有的数字。所以对关键数据财务、医疗、法律多模态的输出要有人工抽检或交叉验证。我的经验是让模型在描述图表时明确标注“图中显示”和“推测”对不确定的内容保持谨慎比让它自信地胡说八道要好。4. 九种 PDF 解析工具的横向对比与场景匹配4.1 文字抽取类工具PyMuPDF、pdfplumber、pdfminer这三个是纯文字抽取的主力。PyMuPDFfitz速度最快API 友好能拿到文字、坐标、字体信息还能渲染页面为图片是我做混合管线时的首选底层库。pdfplumber在表格抽取上更强能基于线条和文字位置还原表格结构适合表格多的文档。pdfminer最底层控制粒度细但速度慢、API 繁琐一般作为其他库的依赖出现很少直接用。选型上如果只是抽文字PyMuPDF 足够如果表格是重点pdfplumber 更合适。三者都只能处理有文字层的 PDF扫描件无能为力。实际项目里我经常两个一起用PyMuPDF 负责快速抽取和页面渲染pdfplumber 专门处理表格页。4.2 版面分析类工具LayoutParser、PP-StructureLayoutParser是基于深度学习的版面分析库能识别标题、正文、表格、图片、页眉页脚等区域输出带标签的版面结构。PP-Structure是 PaddleOCR 生态里的文档结构分析工具中文支持好能同时做版面分析、表格识别、阅读顺序还原。这类工具的价值在于把“一页 PDF”拆成“结构化的区域”为后续的精细处理提供基础。比如识别出表格区域后单独送表格识别模型识别出图片区域后单独送多模态模型。它们本身不直接产出最终文本而是解析管线里的“调度中枢”。4.3 端到端文档解析工具Unstructured、Marker、MinerUUnstructured是老牌的开源文档解析库支持 PDF、Word、PPT、HTML 等多种格式输出统一的元素列表标题、正文、表格、列表项和 LangChain、LlamaIndex 集成好适合快速搭建 RAG 导入管线。缺点是复杂 PDF 的解析质量一般表格和版面处理不够精细。Marker是近两年很火的 PDF 转 Markdown 工具基于深度学习模型能把 PDF 高质量转成 Markdown保留标题、表格、公式、图片位置对学术论文和技术文档效果很好。它内部会组合文字抽取、OCR、版面分析多个模型属于“开箱即用”的端到端方案。MinerU是国内团队做的 PDF 解析工具中文文档支持好能处理扫描件、公式、表格输出 Markdown 和 JSON对中文技术文档、论文的解析质量在开源方案里属于第一梯队。这三个工具的共同点是“端到端”你给一个 PDF它给你结构化文本省去了自己拼管线的麻烦。代价是灵活性差一些遇到特殊需求不好定制。我的建议是快速验证阶段用它们跑通流程生产环境如果对特定文档类型有更高要求再基于底层库自建管线。4.4 九种工具的能力矩阵与选型决策树把上面提到的工具加上云 OCR、多模态模型整理成一张对照表工具/方案类型中文支持表格能力扫描件版面还原适用场景PyMuPDF文字抽取好弱否弱原生 PDF 快速抽取pdfplumber文字抽取好强否中表格密集的电子文档pdfminer文字抽取好中否弱底层定制需求LayoutParser版面分析中中是强复杂版面结构识别PP-Structure版面分析强强是强中文复杂文档Unstructured端到端中中部分中多格式快速导入Marker端到端中强是强论文、技术文档转 MDMinerU端到端强强是强中文论文、扫描件云 OCR云服务强强是中敏感度低、追求省事多模态模型视觉理解强强是强图表、公式、难页面选型决策树可以这样走先判断有没有文字层有就走文字抽取PyMuPDF/pdfplumber没有就走 OCR 或多模态。再看版面复杂度简单版面 OCR 够用复杂版面加版面分析或多模态。最后看语言和场景中文优先 PaddleOCR 系和 MinerU学术文档优先 Marker多格式混合优先 Unstructured。5. 搭建一条可复用的图文 PDF 解析管线5.1 页面级探测与分流设计管线设计的第一步是页面级探测。不要按文件处理要按页处理因为同一文件内页面类型可能不同。对每一页先尝试文字抽取统计有效字符数和文字覆盖率如果字符数低于阈值比如 50 个字符但页面有图像内容标记为扫描页如果检测到大量图形区域标记为富视觉页。分流规则大致是文字页走文字抽取扫描页走 OCR富视觉页走多模态或版面分析。分流之后每类页面走各自的处理分支最后统一汇总成结构化文档。这个设计的好处是每类页面用最合适的工具不浪费算力也不丢信息。5.2 结构化输出的统一数据模型不同工具的输出格式五花八门必须统一成自己的数据模型否则下游切分和向量化没法写。我一般定义一个简单的文档模型文档包含若干页面页面包含若干块block每个块有类型标题、正文、表格、图片、公式、内容、层级、坐标、来源工具。表格块的内容用 Markdown 或 HTML 表示图片块附带描述文字。统一模型的价值在于解耦上游换工具不影响下游下游要加新处理比如给表格块单独做摘要也不用改上游。这是工程化的关键早期图省事直接用工具原始输出后面每换一个工具就要重写一遍下游逻辑非常痛苦。5.3 切分策略与解析结果的衔接解析出来的结构化文档切分时要用上结构信息而不是无脑按字数切。标题块可以作为切分边界正文块按语义段落切表格块尽量保持完整不切开图片描述和对应图注放在一起。这样切出来的 chunk 语义完整检索时召回的内容更精准。一个实用技巧是给 chunk 加上下文头比如把所属章节标题拼在 chunk 前面这样即使 chunk 本身很短向量里也带了章节语义召回率会提升。这个做法在长文档里效果尤其明显。5.4 质量校验与人工抽检机制解析管线跑通不代表质量达标必须建立校验机制。自动化校验可以看几个指标OCR 平均置信度、文字密度异常页、表格识别成功率、空页比例。低于阈值的页面自动标记进入人工抽检队列。人工抽检不用全看按比例抽样即可重点看关键文档和异常页。我一般会抽 5% 到 10% 的页面检查文字准确性、表格结构、阅读顺序。发现系统性问题比如某类版面总是解析错就回头调管线而不是一页页修。这个反馈闭环是保证长期质量的关键。6. 实战中踩过的坑与性能优化经验6.1 中文乱码、字体嵌入与编码陷阱中文 PDF 最常见的坑是字体未嵌入或编码映射错误导致文字抽取出来是乱码或空白。有些 PDF 用了自定义编码PyMuPDF 抽出来是一堆问号。遇到这种情况先检查字体是否嵌入没嵌入的话文字抽取基本没救只能走 OCR 或多模态。另一个坑是竖排文字和特殊符号。竖排中文古籍、部分海报OCR 默认按横排处理会全乱需要开启竖排识别或旋转图片。特殊符号数学符号、货币符号、单位识别错误率高关键数据要交叉验证。6.2 大文件解析的内存与并发控制几百页甚至上千页的 PDF一次性加载到内存会爆。PyMuPDF 支持按页处理要养成逐页读取、及时释放的习惯。多模态模型调用是 IO 密集型可以用并发加速但要注意 API 的速率限制别把配额打爆。本地 OCR 是 CPU/GPU 密集型并发数要按硬件来盲目开多进程反而因为资源竞争变慢。我的做法是分批处理 断点续传把文档按页分批每批处理完把结果落盘记录进度。这样即使中途失败也能从断点继续不用从头再来。大文件解析动辄几十分钟没有断点续传会非常痛苦。6.3 解析结果与向量库的对接细节解析结果进向量库前要注意几个细节。元数据要带全来源文件、页码、块类型、章节路径这些在检索过滤和结果展示时都用得上。表格和图片的描述要单独处理表格转成 Markdown 后直接向量化图片描述作为独立 chunk和图注关联。去重同一文档多次导入要能识别并更新而不是重复插入。还有一个容易忽略的点是chunk 的粒度。解析出来的块大小不一有的段落很长有的标题很短。切分时要设最小和最大长度太短的合并太长的按语义切。粒度不合适检索要么召回太碎要么召回一大段无关内容。6.4 从解析质量反推检索效果的调优闭环最后说一个方法论解析质量要用检索效果来验证。解析完不是终点要拿真实问题去测检索召回。如果某些问题总是召回不到回头看看对应内容是不是解析时丢了或错了。这个闭环能帮你发现解析阶段隐藏的问题比如某个表格被解析成了乱码导致相关问答全部失败。我一般会准备一组测试问题覆盖文档里的关键信息点每次调整解析管线后跑一遍看召回率和答案准确率的变化。解析优化不是一次性的而是随着文档类型和业务需求不断迭代的过程。把测试集建起来优化才有方向。最后分享一个我在多个项目里验证过的经验不要追求一步到位的完美解析先跑通再优化。一开始用 Unstructured 或 MinerU 这类端到端工具快速把数据灌进去验证 RAG 整体流程然后再针对解析质量差的文档类型逐步替换成定制管线。很多人卡在解析环节反复调优结果整个 RAG 项目迟迟上不了线。解析是手段不是目的能支撑业务问答的解析就是好解析。 
长河君 · 2026/10/5 9:31:21 · 阅读 1.2k RAG数据导入实战：图文混排PDF解析与OCR选型指南
图文混排的 PDF 和扫描件是 RAG 数据导入环节里最容易被低估的一块硬骨头。很多人做知识库时默认“PDF 就是文字”结果一上手发现合同是扫描件、产品手册是图文混排、财报里关键数据全在图表里、PPT 导出的 PDF 文字层错乱到没法看。纯文本抽取工具在这些场景下几乎全军覆没而 RAG 的上限恰恰由数据导入的质量决定——垃圾进垃圾出检索再强也救不回来。这篇接着上一篇的数据导入话题专门聊图文与 PDF 解析这条链路OCR 怎么选、多模态大模型在什么位置介入、九种 PDF 解析工具各自适合什么场景以及我在实际项目里踩过的那些坑。不管你是刚搭第一个 RAG 知识库还是已经在优化检索召回率这篇里的选型逻辑和实操细节都能直接拿去用。1. 为什么 PDF 解析是 RAG 数据导入的第一道分水岭1.1 文字层 PDF 与扫描件 PDF 的本质差异先把一个基础认知立住PDF 不是一种“格式”而是一个“容器”。同样后缀是 .pdf内部结构可能天差地别。第一类是原生文字层 PDF由 Word、LaTeX、排版软件导出文字以字符编码形式存储附带字体、坐标、字号信息抽取工具能直接读到文本流。第二类是扫描件 PDF本质是一堆图片按页封装没有任何文字信息必须走 OCR 或视觉模型才能拿到内容。第三类是混合型 PDF部分页面有文字层、部分是扫描图甚至同一页里正文是文字、表格是图片。这个差异直接决定了你的解析管线怎么设计。我见过太多人拿 PyPDF2 去抽扫描合同抽出来一片空白还以为是代码写错了。判断方法很简单用pdfplumber或PyMuPDF抽一页如果返回的文本长度接近零但页面明显有内容那就是扫描件。更工程化的做法是在导入阶段就做一次探测按页打标签后续分流处理。提示不要假设一个 PDF 文件内部是同质的。我处理过一份 200 页的技术手册前 30 页是原生文字后面全是扫描的附录如果整份文件走同一条管线要么浪费算力要么丢数据。1.2 解析质量如何一路传导到检索效果RAG 的链路是“解析 → 切分 → 向量化 → 检索 → 生成”解析在最上游它的误差会被后面每一环放大。举个具体的例子一份财务报表里“营业收入 1,234,567 元”如果被 OCR 识别成“营业收入 l,234,567 元”数字 1 变成字母 l向量化之后语义已经偏了用户问“营业收入是多少”时这段文本的召回概率会明显下降。再比如表格被抽成一行行错位的文字“2023 年 Q1 营收”和“2022 年 Q4 营收”的数值串位模型生成时就会张冠李戴。所以解析阶段的目标不是“把字抠出来”而是尽可能保留原文的结构和语义关系段落边界、标题层级、表格的行列对应、图表的标题与说明。这也是为什么单纯的 OCR 不够后面要引入版面分析和多模态模型。理解这一点后面的工具选型才有判断标准——不是哪个工具识别率高就用哪个而是哪个工具在你这类文档上保留的结构信息最完整。1.3 三类文档场景对应的解析策略我把实际项目里遇到的文档粗分成三类策略完全不同。第一类是规整的电子文档合同、报告、论文有文字层优先用文字抽取 版面分析OCR 只作为兜底。第二类是扫描件和图片型文档纸质档案、传真、拍照件必须走 OCR 或视觉大模型重点解决识别准确率和版面还原。第三类是富视觉文档含图表、流程图、公式、多栏排版这类最麻烦纯 OCR 会把图表信息丢光需要多模态模型或专门的版面解析工具。分类之后你会发现所谓“PDF 解析工具选型”其实是在为不同场景匹配不同工具而不是找一个万能解。下面几节我会把 OCR、多模态大模型、PDF 工具这三条线拆开讲最后再给一张选型对照表。2. OCR 引擎的选型逻辑与实战调优2.1 通用 OCR 与文档 OCR 的能力边界OCR 这个领域要分清两个层次。通用 OCR比如 Tesseract、部分云服务的通用接口擅长识别清晰的印刷体对单行文字、简单排版效果好但遇到复杂版面、表格、多栏就力不从心。文档 OCR比如 PaddleOCR 的版面分析模块、专门的文档解析服务在识别文字之外还会做版面检测、表格结构还原、阅读顺序排序输出的是带结构的文档而不是一堆散字。选型时先问自己我的文档是“一行行干净的印刷体”还是“有表格、有多栏、有图注的复杂版面”如果是后者通用 OCR 的原始输出基本没法直接用于 RAG你还得自己写一堆后处理去拼版面成本反而更高。我在早期项目里用 Tesseract 处理产品手册识别率看着不错但输出的文字顺序完全乱套双栏排版被读成左右交错最后不得不换工具重做。2.2 PaddleOCR 在中文文档上的实操配置中文场景下 PaddleOCR 是绕不开的选择它对中文的识别效果、版面分析能力都比较成熟。基础用法很直接from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch) result ocr.ocr(scan.pdf, clsTrue) for line in result[0]: text line[1][0] confidence line[1][1] box line[0] print(text, confidence)但真正影响效果的是几个参数和前置处理。use_angle_clsTrue开启方向分类处理扫描时歪斜的页面很关键我遇到过整页旋转 90 度的档案不开这个参数识别率直接归零。lang参数要按文档语言选中英混排的文档建议用ch它对英文也有不错的支持。另外det_db_thresh文本检测阈值和rec_thresh识别置信度阈值在低质量扫描件上需要调低否则会漏掉模糊的文字。注意PaddleOCR 默认按行输出丢失了段落和阅读顺序。用于 RAG 时你需要根据文本框的坐标box 里的四个点自己做行合并和段落重组按 y 坐标聚类成行、按 x 坐标排序再根据行间距判断段落边界。这一步不做切分出来的 chunk 会是断裂的。2.3 云 OCR 服务与本地部署的取舍云 OCR各家云厂商的文字识别服务的优势是开箱即用、准确率高、支持表格和版面还原缺点是按量计费、有网络依赖、数据要出本地。本地部署PaddleOCR、Tesseract的优势是数据不出域、无调用成本、可离线缺点是要自己调优、要维护环境、复杂版面处理能力弱一些。我的判断标准是看数据敏感性和文档量级。如果是企业内部合同、财务单据这类敏感数据优先本地部署哪怕多花点调优时间。如果是公开资料、文档量不大、追求快速上线云服务更省事。量级上本地部署在几万页以上时成本优势才明显小批量用云服务反而更划算。另外要注意云 OCR 的返回结构各家不同接入时要写一层适配把结果统一成你自己的文档模型否则换服务商时改动会很大。2.4 OCR 后处理从散字到可切分文本OCR 的原始输出是带坐标的文字块直接拿去切分效果很差。后处理要做三件事行合并把同一行的文字块按 x 坐标拼起来、段落重组按行间距和缩进判断段落、阅读顺序排序多栏文档要按栏读不能左右横跳。多栏排序是难点简单做法是按 x 坐标把页面切成左右两半分别处理复杂做法是用版面分析模型识别栏区域。还有一个容易被忽略的点表格处理。OCR 识别表格时单元格文字是散的你需要根据坐标还原行列结构输出成 Markdown 表格或 HTML 表格。这一步做不好表格数据在 RAG 里就是废的。我一般会用专门的表格识别模型PaddleOCR 有表格识别模块或者直接上多模态模型处理表格页。3. 多模态大模型在解析链路中的正确位置3.1 什么时候该上多模态模型多模态大模型能同时理解图像和文本的模型在 PDF 解析里的价值是处理那些传统 OCR 搞不定的页面复杂图表、流程图、公式、手写批注、版面极其混乱的扫描件。它的工作方式是把页面渲染成图片直接让模型“看图说话”输出结构化的文字描述或 Markdown。但不要一上来就全量走多模态成本太高。我的策略是分层处理先用文字抽取和 OCR 处理大部分页面只把识别置信度低、版面复杂、含图表的页面挑出来交给多模态模型兜底。这样既控制了成本又保证了难页面的质量。判断哪些页面需要兜底可以看 OCR 的平均置信度、页面文字密度、是否检测到图表区域。3.2 图表与公式的语义化提取图表是 RAG 里最容易被浪费的信息。一张营收趋势图OCR 只能抠出坐标轴上的数字图表的趋势、对比关系全丢了。多模态模型可以做到识别图表类型柱状图、折线图、饼图、提取数据系列、用自然语言描述趋势。比如把一张折线图转成“2020 到 2023 年营收从 500 万增长到 1200 万年均增长率约 34%2022 年增速放缓”。公式同理纯 OCR 会把公式识别成乱码多模态模型能输出 LaTeX 或自然语言描述。对于技术文档、学术论文这类含大量公式的场景这一步直接决定了知识库能不能回答“这个公式是什么意思”这类问题。3.3 用多模态模型做版面理解与阅读顺序还原除了图表多模态模型还能解决版面理解问题。传统方法靠坐标规则判断阅读顺序遇到不规则排版比如杂志式的图文环绕、侧边栏、脚注就失效。多模态模型可以直接理解“这一页应该先读哪里、再读哪里”输出符合人类阅读习惯的文本流。实操上我会把页面渲染成较高分辨率的图片一般 150 到 200 DPI 足够太高反而增加 token 消耗然后给模型一个明确的指令模板要求它按阅读顺序输出 Markdown保留标题层级、表格结构、图注位置。指令里要强调“不要遗漏任何文字”“表格用 Markdown 表格输出”“图表用文字描述其内容”这些约束能显著提升输出质量。3.4 成本、延迟与准确率的三角平衡多模态模型不是免费的按图片 token 计费一页复杂页面可能消耗几千 token。全量走多模态一份几百页的文档成本会很可观延迟也高。平衡的做法是能文字抽取的绝不用 OCR能 OCR 的绝不用多模态把多模态留给真正需要的页面。同时可以做缓存同一份文档解析一次后把结果存下来避免重复调用。准确率方面多模态模型也会幻觉尤其是图表数据它可能“编”出图上没有的数字。所以对关键数据财务、医疗、法律多模态的输出要有人工抽检或交叉验证。我的经验是让模型在描述图表时明确标注“图中显示”和“推测”对不确定的内容保持谨慎比让它自信地胡说八道要好。4. 九种 PDF 解析工具的横向对比与场景匹配4.1 文字抽取类工具PyMuPDF、pdfplumber、pdfminer这三个是纯文字抽取的主力。PyMuPDFfitz速度最快API 友好能拿到文字、坐标、字体信息还能渲染页面为图片是我做混合管线时的首选底层库。pdfplumber在表格抽取上更强能基于线条和文字位置还原表格结构适合表格多的文档。pdfminer最底层控制粒度细但速度慢、API 繁琐一般作为其他库的依赖出现很少直接用。选型上如果只是抽文字PyMuPDF 足够如果表格是重点pdfplumber 更合适。三者都只能处理有文字层的 PDF扫描件无能为力。实际项目里我经常两个一起用PyMuPDF 负责快速抽取和页面渲染pdfplumber 专门处理表格页。4.2 版面分析类工具LayoutParser、PP-StructureLayoutParser是基于深度学习的版面分析库能识别标题、正文、表格、图片、页眉页脚等区域输出带标签的版面结构。PP-Structure是 PaddleOCR 生态里的文档结构分析工具中文支持好能同时做版面分析、表格识别、阅读顺序还原。这类工具的价值在于把“一页 PDF”拆成“结构化的区域”为后续的精细处理提供基础。比如识别出表格区域后单独送表格识别模型识别出图片区域后单独送多模态模型。它们本身不直接产出最终文本而是解析管线里的“调度中枢”。4.3 端到端文档解析工具Unstructured、Marker、MinerUUnstructured是老牌的开源文档解析库支持 PDF、Word、PPT、HTML 等多种格式输出统一的元素列表标题、正文、表格、列表项和 LangChain、LlamaIndex 集成好适合快速搭建 RAG 导入管线。缺点是复杂 PDF 的解析质量一般表格和版面处理不够精细。Marker是近两年很火的 PDF 转 Markdown 工具基于深度学习模型能把 PDF 高质量转成 Markdown保留标题、表格、公式、图片位置对学术论文和技术文档效果很好。它内部会组合文字抽取、OCR、版面分析多个模型属于“开箱即用”的端到端方案。MinerU是国内团队做的 PDF 解析工具中文文档支持好能处理扫描件、公式、表格输出 Markdown 和 JSON对中文技术文档、论文的解析质量在开源方案里属于第一梯队。这三个工具的共同点是“端到端”你给一个 PDF它给你结构化文本省去了自己拼管线的麻烦。代价是灵活性差一些遇到特殊需求不好定制。我的建议是快速验证阶段用它们跑通流程生产环境如果对特定文档类型有更高要求再基于底层库自建管线。4.4 九种工具的能力矩阵与选型决策树把上面提到的工具加上云 OCR、多模态模型整理成一张对照表工具/方案类型中文支持表格能力扫描件版面还原适用场景PyMuPDF文字抽取好弱否弱原生 PDF 快速抽取pdfplumber文字抽取好强否中表格密集的电子文档pdfminer文字抽取好中否弱底层定制需求LayoutParser版面分析中中是强复杂版面结构识别PP-Structure版面分析强强是强中文复杂文档Unstructured端到端中中部分中多格式快速导入Marker端到端中强是强论文、技术文档转 MDMinerU端到端强强是强中文论文、扫描件云 OCR云服务强强是中敏感度低、追求省事多模态模型视觉理解强强是强图表、公式、难页面选型决策树可以这样走先判断有没有文字层有就走文字抽取PyMuPDF/pdfplumber没有就走 OCR 或多模态。再看版面复杂度简单版面 OCR 够用复杂版面加版面分析或多模态。最后看语言和场景中文优先 PaddleOCR 系和 MinerU学术文档优先 Marker多格式混合优先 Unstructured。5. 搭建一条可复用的图文 PDF 解析管线5.1 页面级探测与分流设计管线设计的第一步是页面级探测。不要按文件处理要按页处理因为同一文件内页面类型可能不同。对每一页先尝试文字抽取统计有效字符数和文字覆盖率如果字符数低于阈值比如 50 个字符但页面有图像内容标记为扫描页如果检测到大量图形区域标记为富视觉页。分流规则大致是文字页走文字抽取扫描页走 OCR富视觉页走多模态或版面分析。分流之后每类页面走各自的处理分支最后统一汇总成结构化文档。这个设计的好处是每类页面用最合适的工具不浪费算力也不丢信息。5.2 结构化输出的统一数据模型不同工具的输出格式五花八门必须统一成自己的数据模型否则下游切分和向量化没法写。我一般定义一个简单的文档模型文档包含若干页面页面包含若干块block每个块有类型标题、正文、表格、图片、公式、内容、层级、坐标、来源工具。表格块的内容用 Markdown 或 HTML 表示图片块附带描述文字。统一模型的价值在于解耦上游换工具不影响下游下游要加新处理比如给表格块单独做摘要也不用改上游。这是工程化的关键早期图省事直接用工具原始输出后面每换一个工具就要重写一遍下游逻辑非常痛苦。5.3 切分策略与解析结果的衔接解析出来的结构化文档切分时要用上结构信息而不是无脑按字数切。标题块可以作为切分边界正文块按语义段落切表格块尽量保持完整不切开图片描述和对应图注放在一起。这样切出来的 chunk 语义完整检索时召回的内容更精准。一个实用技巧是给 chunk 加上下文头比如把所属章节标题拼在 chunk 前面这样即使 chunk 本身很短向量里也带了章节语义召回率会提升。这个做法在长文档里效果尤其明显。5.4 质量校验与人工抽检机制解析管线跑通不代表质量达标必须建立校验机制。自动化校验可以看几个指标OCR 平均置信度、文字密度异常页、表格识别成功率、空页比例。低于阈值的页面自动标记进入人工抽检队列。人工抽检不用全看按比例抽样即可重点看关键文档和异常页。我一般会抽 5% 到 10% 的页面检查文字准确性、表格结构、阅读顺序。发现系统性问题比如某类版面总是解析错就回头调管线而不是一页页修。这个反馈闭环是保证长期质量的关键。6. 实战中踩过的坑与性能优化经验6.1 中文乱码、字体嵌入与编码陷阱中文 PDF 最常见的坑是字体未嵌入或编码映射错误导致文字抽取出来是乱码或空白。有些 PDF 用了自定义编码PyMuPDF 抽出来是一堆问号。遇到这种情况先检查字体是否嵌入没嵌入的话文字抽取基本没救只能走 OCR 或多模态。另一个坑是竖排文字和特殊符号。竖排中文古籍、部分海报OCR 默认按横排处理会全乱需要开启竖排识别或旋转图片。特殊符号数学符号、货币符号、单位识别错误率高关键数据要交叉验证。6.2 大文件解析的内存与并发控制几百页甚至上千页的 PDF一次性加载到内存会爆。PyMuPDF 支持按页处理要养成逐页读取、及时释放的习惯。多模态模型调用是 IO 密集型可以用并发加速但要注意 API 的速率限制别把配额打爆。本地 OCR 是 CPU/GPU 密集型并发数要按硬件来盲目开多进程反而因为资源竞争变慢。我的做法是分批处理 断点续传把文档按页分批每批处理完把结果落盘记录进度。这样即使中途失败也能从断点继续不用从头再来。大文件解析动辄几十分钟没有断点续传会非常痛苦。6.3 解析结果与向量库的对接细节解析结果进向量库前要注意几个细节。元数据要带全来源文件、页码、块类型、章节路径这些在检索过滤和结果展示时都用得上。表格和图片的描述要单独处理表格转成 Markdown 后直接向量化图片描述作为独立 chunk和图注关联。去重同一文档多次导入要能识别并更新而不是重复插入。还有一个容易忽略的点是chunk 的粒度。解析出来的块大小不一有的段落很长有的标题很短。切分时要设最小和最大长度太短的合并太长的按语义切。粒度不合适检索要么召回太碎要么召回一大段无关内容。6.4 从解析质量反推检索效果的调优闭环最后说一个方法论解析质量要用检索效果来验证。解析完不是终点要拿真实问题去测检索召回。如果某些问题总是召回不到回头看看对应内容是不是解析时丢了或错了。这个闭环能帮你发现解析阶段隐藏的问题比如某个表格被解析成了乱码导致相关问答全部失败。我一般会准备一组测试问题覆盖文档里的关键信息点每次调整解析管线后跑一遍看召回率和答案准确率的变化。解析优化不是一次性的而是随着文档类型和业务需求不断迭代的过程。把测试集建起来优化才有方向。最后分享一个我在多个项目里验证过的经验不要追求一步到位的完美解析先跑通再优化。一开始用 Unstructured 或 MinerU 这类端到端工具快速把数据灌进去验证 RAG 整体流程然后再针对解析质量差的文档类型逐步替换成定制管线。很多人卡在解析环节反复调优结果整个 RAG 项目迟迟上不了线。解析是手段不是目的能支撑业务问答的解析就是好解析。