图文混排的 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 解析没有一劳永逸的方案文档类型在变工具在迭代唯一不变的是先分类、再分流、后融合这个思路。把页面类型判断做扎实把各通道的输出质量控住把图文关联建好剩下的就是根据具体文档特点调参和优化。这套流水线搭起来之后后面接入新的文档类型基本就是加规则、换模型的事不用推倒重来。