图文混排的 PDF 和扫描件，是 RAG 数据导入环节里最容易翻车的一类输入。纯文本 PDF 用常规解析库就能搞定，但一旦文档里塞满了截图、流程图、表格扫描件、公式图片，或者整份文件就是扫描生成的，传统解析器要么直接吐出一堆乱码，要么把图片位置留成空白，检索时用户问的问题恰好落在那张图上，系统就彻底哑火。这篇内容聚焦的就是这个卡点：怎么把图文混排和扫描型 PDF 里的信息完整抠出来，OCR 在什么场景下够用、什么时候必须上多模态大模型，以及市面上九种主流 PDF 解析工具各自适合什么活。如果你正在搭 RAG 知识库、做文档智能处理，或者单纯被一堆扫描合同、产品手册、技术白皮书折磨过，这篇应该能帮你少走不少弯路。
1. 图文混排 PDF 为什么是 RAG 导入的硬骨头
1.1 传统文本解析器在图片面前的失效逻辑
先说清楚问题出在哪。常规的 PDF 文本提取工具，底层逻辑是读取 PDF 文件里的文本层——也就是 PDF 规范里那些带有字符编码、字体信息、坐标位置的文本对象。一份由 Word 导出的 PDF，文字部分通常保留完整文本层，提取出来干净利落。但图片不一样，图片在 PDF 里就是一个二进制流对象，解析器能拿到它的位置和尺寸，却拿不到里面的内容。
这就导致一个很尴尬的局面：一份产品说明书，正文写着"接线方式如下图所示"，然后配一张接线图。文本解析器提取出来的结果是"接线方式如下图所示"，后面什么都没有。用户问"这个设备怎么接线"，检索系统召回了这段文本，但答案在图上，模型只能干瞪眼。更麻烦的是扫描件，整页都是图片，文本层完全是空的，解析器返回的结果可能是一串空白或者乱码。
我实测过不少文档，最坑的是那种"半扫描"PDF——前几页是电子版文字，中间夹了几页扫描的签字页或附件，最后又是电子版。这种文档用单一策略处理必然出问题，必须做页面级的类型判断，再分流到不同的解析通道。
1.2 图片信息丢失对检索质量的实际影响
很多人低估了图片信息丢失的严重程度。我做过一个粗略统计，在技术手册、医疗器械说明书、金融合同这三类文档里，关键信息分布在图片中的比例相当高。技术手册里的接口定义图、参数表格截图，医疗器械说明书里的操作流程图、禁忌症图示，金融合同里的印章、手写签名、附件表格扫描件，这些内容一旦丢失，RAG 系统的回答质量会断崖式下跌。
具体表现是：检索能召回相关段落，但段落里缺少关键细节，模型只能给出模糊回答，或者干脆编造。用户体感就是"这个知识库不太聪明的样子"。而实际上问题不在模型，在数据导入阶段就把信息弄丢了。所以图文混排 PDF 的解析，不是锦上添花的功能，是决定 RAG 系统可用性的基础设施。
1.3 三类典型难处理文档的特征拆解
把难处理的文档归归类，处理策略会清晰很多。
第一类是扫描型 PDF，整份文档由扫描仪或拍照生成，没有文本层，页面就是一张大图。这类文档必须走 OCR 或视觉模型路线，没有捷径。
第二类是图文混排型 PDF，有完整文本层，但关键信息以图片形式嵌入，比如截图、图表、公式。这类文档需要文本提取和图片理解双通道并行，最后做信息融合。
第三类是复杂版式 PDF，比如多栏排版、表格跨页、脚注旁注混排。这类文档文本层是有的，但提取顺序会乱，表格结构会散，需要专门的版式分析能力。
三类文档的处理难度和工具选型完全不同，后面会分别展开。先记住一个原则：不要用一把锤子敲所有钉子，页面级判断加分流处理，是工程上最稳的做法。
2. OCR 与多模态大模型的分工边界
2.1 OCR 能解决什么、解决不了什么
OCR 的本质是图像到文本的转换，它擅长的是"把图里的字认出来"。对于印刷体、清晰扫描件、规范排版的文档，现代 OCR 引擎的准确率已经相当高，中文场景下主流引擎在干净扫描件上做到 95% 以上的字符准确率并不难。
但 OCR 的天花板也很明显。它只输出文字，不输出结构。一张表格扫描件，OCR 出来是一堆按行排列的文字，行列关系、合并单元格、表头对应关系全部丢失。一张流程图，OCR 只能认出框里的文字，箭头指向、层级关系、流程顺序一概没有。一张带标注的工程图，OCR 认得出标注文字，但文字对应哪个部件、标注指向哪里，它不知道。
还有一个容易被忽略的点：OCR 对版式复杂的文档，阅读顺序经常出错。多栏排版它会按行横着读，把左栏和右栏的文字混在一起。所以 OCR 的定位应该是"文字提取器"，不是"文档理解器"。它能帮你把字抠出来，但理解文档在说什么、信息之间什么关系，得靠后面的环节。
2.2 多模态大模型补上了哪块能力
多模态大模型的出现，恰好补上了 OCR 缺失的那块——理解。它不只是认字，还能看懂图里的结构、关系、语义。给它一张表格截图，它能输出结构化的 Markdown 表格；给它一张流程图，它能描述流程步骤和分支条件；给它一张带标注的产品图，它能说明每个标注对应的部件和功能。
在 RAG 场景下，多模态大模型的价值体现在两个层面。一是图片转结构化文本，把图里的信息转成可检索、可引用的文字描述，直接进知识库。二是图片内容问答，在检索阶段直接把相关图片喂给模型，让它基于图片内容回答。
但多模态大模型也不是万能药。它的成本比 OCR 高一个数量级，推理速度慢，对超长文档或大批量处理不友好。而且它对细小文字、密集表格的识别精度，在某些场景下反而不如专门的 OCR 引擎。所以实际工程里，常见做法是 OCR 打底做文字提取，多模态模型做结构理解和图片描述，两者配合使用。
2.3 什么场景必须上多模态，什么场景 OCR 就够
给一个实用的判断标准。
OCR 就够的场景：纯文字扫描件、文字为主的合同、书籍扫描页、票据凭证。这些文档信息主体是文字，OCR 提取后配合简单的后处理就能用。
必须上多模态的场景：图表密集的技术文档、带流程图的说明书、表格结构复杂的报表、带标注的工程图纸、幻灯片导出的 PDF。这些文档的核心信息在结构和关系里，光有文字没用。
混合策略的场景：大部分实际文档都是混合的。我的做法是先做页面级分类，文字为主的页面走 OCR，图表为主的页面走多模态，最后统一融合。这样成本和效果能取得比较好的平衡。
还有一个折中方案值得提：对图片先做 OCR 提取文字，再把 OCR 结果和图片一起喂给多模态模型做理解。这样模型既有文字参考，又有视觉信息，对密集文字的识别准确率会更高。这个技巧在处理表格截图时特别管用。
3. 九种 PDF 解析工具的选型对照
3.1 工具选型的三个核心维度
选工具之前先明确评估维度，不然容易被各种宣传带偏。我看三个维度。
解析能力维度：能不能处理扫描件、能不能识别表格结构、能不能提取图片、能不能保留版式信息。这是硬指标。
工程集成维度：部署难度、依赖复杂度、是否支持批量处理、API 是否友好、输出格式是否规整。这决定了你能不能把它塞进现有流水线。
成本维度：开源免费还是商业收费、本地部署还是云服务、大批量处理的单页成本。RAG 数据导入往往是批量的，成本敏感度很高。
三个维度里没有全能选手，每个工具都有它的甜区。下面按类型分组说。
3.2 开源解析库阵营：PyMuPDF、pdfplumber、PDFMiner
这三个是 Python 生态里最常用的 PDF 处理库，定位偏底层。
PyMuPDF（也叫 fitz）是我用得最多的一个。速度快，能提取文本、图片、坐标信息，还能渲染页面为图像。它的优势是全能且高效，一份几百页的 PDF 几秒钟就能遍历完。提取图片特别方便，可以直接把每张图导出成独立文件。缺点是它不做 OCR，扫描件提取出来是空的，需要配合其他 OCR 引擎。另外它的文本提取对复杂版式支持一般，多栏文档顺序会乱。
pdfplumber的强项是表格提取。它基于 pdfminer 做了封装，能识别表格的线条和单元格，输出结构化的表格数据。处理财务报表、数据表格这类文档时，pdfplumber 的表现比 PyMuPDF 好。缺点是速度慢，大文档处理起来比较吃力，而且对没有明显边框线的表格识别效果会打折扣。
PDFMiner是老牌库，文本提取的精细度高，能拿到字符级的坐标和字体信息。适合做深度版式分析的场景。缺点是 API 比较繁琐，学习曲线陡，速度也不快。现在很多新项目会直接用它的封装版本，而不是裸用。
这三个库的共同点是：只处理有文本层的 PDF，扫描件搞不定。所以它们通常作为流水线的第一环，负责判断页面类型和提取文本层内容。
3.3 OCR 引擎阵营：Tesseract、PaddleOCR、云端 OCR
扫描件必须靠 OCR，这块的选择也很多。
Tesseract是开源 OCR 的老前辈，支持多语言，社区资源丰富。中文识别需要下载对应的语言包。它的优点是免费、可本地部署、离线可用。缺点是准确率在复杂场景下一般，对倾斜、模糊、低分辨率图像的处理能力有限，版式分析能力弱。适合对成本敏感、文档质量较好的场景。
PaddleOCR是国产开源 OCR 里表现很突出的一个。中文识别准确率高，对表格、版面分析有专门的支持，还提供了轻量级模型适合部署。它的 PP-Structure 模块能做版面分析和表格识别，输出结构化结果。实测下来，在中文文档场景下 PaddleOCR 明显优于 Tesseract。缺点是依赖相对重，环境配置偶尔会踩坑。
云端 OCR比如各家云服务商提供的通用文字识别、表格识别、合同识别接口。优势是准确率高、开箱即用、有专门的行业模型（比如合同字段抽取、票据识别）。缺点是按调用量收费，大批量处理成本不低，而且数据要上传到云端，涉及数据合规的文档要谨慎。适合对准确率要求高、数据敏感度低、量不大的场景。
选 OCR 引擎的核心考量是：文档语言、文档质量、数据合规要求、处理量级。中文场景优先考虑 PaddleOCR，英文场景 Tesseract 够用，追求极致准确率且不差钱就上云端。
3.4 多模态与智能解析阵营：视觉模型与文档 AI 服务
这一阵营是近两年的新势力，代表是各类多模态大模型和专门的文档智能解析服务。
多模态大模型做 PDF 解析，思路是把页面渲染成图片，直接喂给模型，让它输出结构化的文本描述。优势是理解能力强，能处理复杂版式、图表、公式，输出质量高。缺点是成本高、速度慢、对超长文档不友好，而且输出有不确定性，同一张图两次调用可能结果不完全一致。
专门的文档智能解析服务，比如一些厂商提供的文档解析 API，针对表格、版面、阅读顺序做了优化，输出结构化的 Markdown 或 JSON。这类服务在特定文档类型上表现很好，但通用性和灵活性不如自己组合方案。
我的建议是：多模态模型不要用来处理全部文档，成本扛不住。用它处理那些 OCR 搞不定的硬骨头——图表页、复杂表格页、公式页。其余页面走 OCR，整体成本和效果最平衡。
3.5 九种工具的能力对照表
把上面提到的工具整理成对照表，方便快速选型。
| 工具 | 类型 | 扫描件支持 | 表格识别 | 版式分析 | 部署方式 | 成本 | 适用场景 |
|---|---|---|---|---|---|---|---|
| PyMuPDF | 开源库 | 否 | 弱 | 中 | 本地 | 免费 | 文本层提取、图片导出 |
| pdfplumber | 开源库 | 否 | 强 | 中 | 本地 | 免费 | 表格密集文档 |
| PDFMiner | 开源库 | 否 | 中 | 强 | 本地 | 免费 | 深度版式分析 |
| Tesseract | 开源OCR | 是 | 弱 | 弱 | 本地 | 免费 | 英文、质量好的扫描件 |
| PaddleOCR | 开源OCR | 是 | 强 | 强 | 本地 | 免费 | 中文文档、表格 |
| 云端通用OCR | 云服务 | 是 | 中 | 中 | 云端 | 按量 | 高准确率、小批量 |
| 云端合同/票据OCR | 云服务 | 是 | 强 | 强 | 云端 | 按量 | 特定行业文档 |
| 多模态大模型 | 云/本地 | 是 | 强 | 强 | 两者皆可 | 高 | 图表、复杂版式 |
| 文档智能解析API | 云服务 | 是 | 强 | 强 | 云端 | 按量 | 结构化输出需求 |
这张表不是让你选一个，而是让你组合。实际流水线里，通常是 PyMuPDF 做页面分类和文本提取，PaddleOCR 处理扫描页，多模态模型处理图表页，pdfplumber 兜底表格。工具之间是协作关系，不是替代关系。
4. 从零搭一条图文 PDF 解析流水线
4.1 页面级类型判断：分流的第一道闸
流水线的第一步是判断每一页属于什么类型，这决定了后续走哪条通道。判断逻辑可以这样设计。
先用 PyMuPDF 打开文档，遍历每一页。对每一页做两个检测：一是提取文本层，看字符数量；二是提取图片对象，看图片数量和覆盖面积。
如果文本层字符数很少（比如少于 50 个字符）但页面有覆盖大部分区域的大图，判定为扫描页，走 OCR 通道。
如果文本层字符数正常，但页面包含多张图片或大尺寸图片，判定为图文混排页，走文本提取加图片理解双通道。
如果文本层字符数正常且图片很少，判定为纯文本页，走常规文本提取。
如果页面有大量表格线条或检测到表格结构，标记为表格页，走表格专用解析。
这个判断逻辑不复杂，但能覆盖绝大多数情况。实际调参时，字符数阈值和图片面积阈值需要根据文档特点微调。我一般把字符阈值设在 50 到 100 之间，图片面积占比阈值设在 30% 到 50% 之间。
4.2 文本层提取与图片导出的并行处理
对纯文本页和图文混排页，用 PyMuPDF 做文本提取。提取时要注意保留段落结构，不要简单地把所有文字拼成一坨。PyMuPDF 的get_text("blocks")能拿到文本块，每个块有坐标信息，可以据此判断段落边界和阅读顺序。
图片导出用get_images()或get_page_images()，把每张图导出成独立文件，同时记录它在页面上的位置和尺寸。位置信息很重要，后面做图文关联时要用到——知道某张图在哪个段落附近，才能把图片描述和对应文本关联起来。
这里有个细节：PDF 里的图片可能是被多个页面引用的同一张图，导出时要做去重，不然会重复处理。另外有些图片是作为背景或装饰存在的，尺寸很小，可以设一个最小尺寸阈值过滤掉，减少无效处理。
4.3 扫描页的 OCR 处理与结果清洗
扫描页的处理流程是：渲染页面为高分辨率图像，送 OCR 引擎，拿回文字，做后处理。
渲染分辨率很关键。太低 OCR 认不准，太高处理慢。我一般用 200 到 300 DPI，这个区间对大多数文档够用。PaddleOCR 对输入图像尺寸有要求，太大会自动缩放，所以渲染时控制在合理范围就行。
OCR 结果清洗是容易被忽略的环节。原始 OCR 输出通常有这些问题：多余空格、错误换行、识别错的字符、页眉页脚混入正文。需要做规则清洗：合并被错误断开的行、去除页眉页脚、修正常见错字。如果文档有固定版式，可以针对性地写清洗规则。
对于表格扫描页，直接用 PaddleOCR 的表格识别能力，输出结构化的表格数据，比先 OCR 再自己拼表格靠谱得多。
4.4 图表页交给多模态模型的具体做法
图表页是 OCR 的盲区，交给多模态模型处理。做法是把页面渲染成图片，配上精心设计的提示词，让模型输出结构化的描述。
提示词的设计很关键。不要简单地说"描述这张图"，要明确要求输出格式。比如处理表格时，要求模型"以 Markdown 表格形式输出图中表格内容，保留表头和行列对应关系"；处理流程图时，要求"按步骤列出流程，说明每步的输入输出和分支条件"；处理带标注的图时，要求"列出每个标注及其对应的部件和说明"。
输出结果要做校验。多模态模型偶尔会幻觉，编造图中不存在的内容。对关键文档，建议人工抽检或者用规则做一致性校验。另外，模型输出的描述文本要保留图片的引用信息，方便后续检索时能定位回原图。
成本控制上，不要每张图都调模型。可以先判断图片类型，简单的装饰图、logo 直接跳过，只处理信息量大的图表。批量处理时做好并发控制和失败重试。
4.5 图文关联与结构化输出的组装
所有通道处理完后，要把结果组装成统一的结构。核心是建立图文关联——每张图的描述要和它附近的文本关联起来，形成一个完整的语义单元。
关联逻辑基于位置信息：图片在页面上的坐标，和文本块的坐标做比对，距离最近的文本块就是关联对象。如果图片在某个段落下方，那这个段落就是它的上下文。组装时把图片描述插入到对应段落之后，形成"文本加图片描述"的完整内容块。
最终输出建议用结构化格式，比如 JSON 或 Markdown。每个内容块包含：文本内容、图片描述、图片来源、页码、坐标信息。这样后续做分块、向量化、检索时，信息是完整的，不会丢。
分块策略也要相应调整。图文混排的内容块，分块时不要把图片描述和它的上下文文本拆开，否则检索时又会丢失关联。我一般把"段落加其关联图片描述"作为一个整体分块单元。
5. 实操中踩过的坑与调优经验
5.1 OCR 识别韩文失败的排查过程
有次处理一批多语言文档，PaddleOCR 识别中文和英文都正常，但韩文识别结果全是乱码。排查过程记录一下，因为这类问题很典型。
第一步，确认语言包。PaddleOCR 的多语言支持需要指定对应的语言模型，默认加载的是中文模型，识别韩文自然不行。检查代码发现确实没指定韩文模型。
第二步，换用韩文模型后，发现识别率还是很低。进一步排查发现，文档里的韩文是竖排的，而默认模型针对横排文本训练。竖排文本需要额外的方向分类和特殊处理。
第三步，加了方向分类模型后，横排韩文识别正常了，竖排的还是有错。最后是做了图像预处理——把竖排文本区域旋转 90 度再识别，问题才解决。
这个案例的教训是：OCR 不是加载个模型就完事，语言、排版方向、字体、图像质量都会影响结果。处理多语言文档前，先确认语言模型，再检查排版方向，必要时做图像预处理。
5.2 表格跨页断裂的修复思路
表格跨页是另一个高频问题。一份长表格从第一页延续到第二页，解析出来变成两个独立表格，第二页的表头丢失，数据对不上。
修复思路分两步。第一步是识别跨页表格：如果上一页末尾是表格且没有结束线，下一页开头是表格且第一行不是表头，大概率是跨页表格。第二步是合并：把第二页表格的数据行接到第一页表格后面，表头沿用第一页的。
实现上，可以在解析时记录每个表格的起止位置和表头信息，做跨页判断后合并。如果表格结构复杂，合并后还要做列对齐校验，防止列错位。
更稳的做法是用支持跨页表格识别的工具，比如 PaddleOCR 的版面分析或者专门的文档解析服务，它们对跨页表格有专门处理。自己写合并逻辑容易在复杂表格上翻车。
5.3 多模态模型输出不稳定的应对
多模态模型输出不稳定是实际使用中的痛点。同一张图，两次调用可能输出格式不同、详略不同，甚至内容有出入。
应对方法有几个。一是固定提示词模板，把输出格式要求写得非常明确，减少模型自由发挥空间。二是设置低温度参数，让输出更确定。三是做输出校验和重试，如果输出不符合预期格式，自动重试。四是关键内容人工复核，对准确性要求高的文档，模型输出后人工过一遍。
还有一个技巧是给模型提供参考信息。比如把 OCR 提取的文字一起喂给模型，让它基于文字和图像双重信息输出，结果会更稳定，也能减少幻觉。
5.4 大批量处理的性能与成本平衡
大批量处理时，性能和成本是绕不开的。几个实用经验。
分级处理：不是所有页面都值得用重武器。先用轻量方法判断页面类型，简单页面走快速通道，复杂页面才上重武器。这样整体成本能降下来。
缓存复用：同一份文档重复处理时，缓存中间结果。图片去重后，相同图片只处理一次。
并发控制：OCR 和模型调用都可以并发，但要控制并发数，避免触发限流或压垮本地资源。我一般根据服务端的 QPS 限制来设并发数，留一定余量。
失败重试与断点续传：批量处理难免有失败，做好重试机制。处理进度要持久化，中断后能从断点继续，不用从头再来。
成本监控：如果用了云端服务，做好调用量和成本监控，设置预算告警，避免意外超支。
5.5 解析结果的质量校验清单
最后给一份质量校验清单，处理完文档后过一遍，能提前发现大部分问题。
- 文本完整性：随机抽几页，对比原文和解析结果，看有没有大段丢失。
- 图片覆盖率：统计文档图片总数和成功处理的图片数，看有没有漏处理的。
- 表格结构：抽查表格，看行列对应关系是否正确，有没有错位。
- 阅读顺序：检查多栏文档，看文字顺序是否连贯。
- OCR 准确率：抽样对比 OCR 结果和原文，估算准确率。
- 图文关联：检查图片描述是否和上下文文本正确关联。
- 编码问题：检查有没有乱码、特殊字符异常。
- 分块合理性：检查分块后内容是否完整，有没有把关联内容拆散。
这份清单不复杂，但坚持做能避免很多低级错误。RAG 系统的效果，很大程度上取决于数据导入阶段的质量，这一步偷懒，后面怎么调模型都补不回来。
我在实际项目里的体会是，图文 PDF 解析没有一劳永逸的方案，文档类型在变，工具在迭代，唯一不变的是"先分类、再分流、后融合"这个思路。把页面类型判断做扎实，把各通道的输出质量控住，把图文关联建好，剩下的就是根据具体文档特点调参和优化。这套流水线搭起来之后，后面接入新的文档类型，基本就是加规则、换模型的事，不用推倒重来。
