1. 为什么图文与 PDF 解析是 RAG 系统最容易被低估的环节做过 RAG 项目的人都有一个共同体会文本类数据的导入和切分其实不难真正让人头疼的是那些带图、带表、带扫描件的 PDF 文档。你从业务方拿到一批产品手册、合同扫描件、技术白皮书兴冲冲地丢进流水线结果解析出来一堆乱码、错位的表格、丢失的图片说明检索效果自然惨不忍睹。这个环节之所以容易被低估是因为很多人把 PDF 当成另一种 txt来处理。实际上 PDF 从设计之初就是一种打印描述格式它关心的是每个字符画在纸上的哪个坐标位置而不是内容的逻辑结构。这就导致同样一个 PDF 文件可能是原生数字生成的也可能是扫描件还可能是图文混排、多栏布局、带复杂表格的。不同的来源解析策略完全不同。这篇内容聚焦的就是 RAG 数据导入流程中图文与 PDF 解析这一段。我会把 OCR 识别、多模态大模型解析、以及九种主流 PDF 解析工具的选型逻辑讲透包括每种方案的适用边界、参数配置、踩坑经验。适合正在搭建 RAG 知识库的工程师、做文档智能处理的开发者以及需要把大量 PDF 资料变成可检索知识库的技术负责人。读完你应该能判断手上这批 PDF 到底该用哪条技术路线以及为什么。2. 图文与 PDF 解析的整体设计思路拆解2.1 先搞清楚你的 PDF 属于哪一类在动手写代码之前我建议先花十分钟把待处理的 PDF 分个类。这一步做对了后面能省掉大量返工。我通常按两个维度来分内容来源和版面复杂度。按内容来源分PDF 大致有三类原生数字 PDF由 Word、LaTeX、网页打印等直接导出文字层是真实可提取的文本选中就能复制。扫描件 PDF纸质文档经过扫描仪或拍照生成本质是一张张图片没有文字层。混合型 PDF部分页面是原生文字部分页面是扫描图片常见于拼接而成的合同或报告。按版面复杂度分又可以分为单栏纯文本、多栏排版、含表格、含公式、含图表说明等。版面越复杂对解析工具的要求越高。提示判断一个 PDF 是不是扫描件最快的办法是用阅读器打开后尝试选中文字。如果整页都选不中基本就是扫描件如果部分能选中就是混合型。为什么要先分类因为原生数字 PDF 和扫描件的处理成本差了一个数量级。原生 PDF 用文本提取工具几秒钟就能搞定扫描件则要走 OCR 或视觉大模型耗时可能是前者的几十倍。如果你不分类就统一走 OCR等于白白浪费算力反过来如果扫描件走了纯文本提取拿到的就是空内容。2.2 三条技术路线的取舍逻辑分类完成后解析方案基本就收敛到三条路线上第一条纯文本提取路线。适用于原生数字 PDF工具直接读取 PDF 内部的文字对象。优点是速度快、成本低、保真度高缺点是对扫描件完全无效对复杂表格和公式支持有限。第二条OCR 识别路线。适用于扫描件和图片。传统 OCR 引擎如 Tesseract、PaddleOCR把图片转成文字再配合版面分析还原阅读顺序。优点是成熟稳定、可离线部署缺点是对复杂版面、手写体、低质量扫描的鲁棒性一般。第三条多模态大模型路线。直接把 PDF 页面渲染成图片喂给具备视觉理解能力的大模型让模型输出结构化的文本或 Markdown。优点是能理解版面语义、处理表格和图表说明缺点是成本高、速度慢、有幻觉风险。实际项目中我很少只用一条路线而是组合使用先用文本提取快速处理原生页面扫描页面走 OCR 或视觉模型最后统一做后处理清洗。这种分流处理的思路是控制成本和保证质量的关键。2.3 解析质量如何影响下游 RAG 效果很多人以为解析只是把内容读出来其实解析质量直接决定了 RAG 的上限。举个具体例子一份产品规格 PDF 里有个表格列是型号、行是参数。如果解析时表格结构丢失变成一串型号A 参数1 参数2 型号B 参数1 参数2的流水文本那么用户问型号A的参数2是多少时检索很可能召回错误片段大模型也就答不对。再比如多栏排版的学术论文如果解析时按坐标从上到下逐行读取会把左栏和右栏的文字交错拼在一起语义完全错乱。这类问题在检索阶段表现为召回了相关文档但内容读不通最终答案质量自然差。所以我的经验是在解析环节多花的时间会在检索和生成环节成倍地省回来。宁可解析慢一点、清洗细一点也不要指望下游用更复杂的检索策略去弥补上游的脏数据。3. OCR 识别的核心细节与实操要点3.1 OCR 引擎选型Tesseract、PaddleOCR 与云服务怎么选OCR 是扫描件处理的基础能力选对引擎能省很多事。我按实际使用体验把常见方案对比一下方案部署方式中文效果版面分析成本适用场景Tesseract本地一般弱免费英文为主、质量较好的扫描件PaddleOCR本地好中免费中文文档、需要离线部署云 OCR 服务在线很好强按量计费合同、票据等结构化字段提取多模态大模型在线/本地很好很强较高复杂版面、图表混排Tesseract 是最老牌的方案胜在轻量和免费但中文识别需要单独下载语言包而且对倾斜、噪点、复杂版面的容忍度较低。我早期用它处理过一批英文技术文档效果还行但换成中文合同就明显吃力。PaddleOCR 是我目前本地部署的首选。它对中文的支持明显更好自带方向分类和版面分析模块而且模型可以按需裁剪。安装上有个小坑不同版本的 API 差异较大网上很多教程是旧版本的写法直接抄会报错。建议锁定官方文档对应版本的用法。云 OCR 服务在结构化字段提取上优势明显比如从合同里抽取金额、签约方、日期这类关键字段很多云服务提供了专门的模板或自定义抽取能力。代价是数据要出本地涉及敏感文档时需要评估合规性。3.2 图像预处理OCR 效果的一半在识别之前我踩过最大的坑就是拿到扫描件直接丢给 OCR然后抱怨识别率低。后来才明白图像预处理做得好OCR 准确率能提升一大截。常见的预处理步骤包括灰度化与二值化把彩色图转成黑白减少干扰。但要注意二值化阈值选不好会丢失浅色文字建议用自适应阈值。去噪扫描件常有椒盐噪声或压缩噪点中值滤波能有效去除。纠偏扫描时纸张歪斜很常见用霍夫变换检测文本行角度后旋转校正。分辨率调整OCR 对分辨率敏感一般建议把图像缩放到 300 DPI 左右。太低识别不清太高反而增加噪声和耗时。注意预处理不是越多越好。过度二值化会把印章、手写批注等有用信息一起抹掉。如果文档里有这些内容建议保留灰度图或做多路处理。3.3 版面分析还原正确的阅读顺序OCR 只负责认字但文字在页面上的阅读顺序需要版面分析来还原。多栏文档、带页眉页脚的文档如果不做版面分析识别出来的文字顺序是乱的。版面分析的核心任务是检测出文本块、图片块、表格块的位置然后按人类阅读习惯排序。对于单栏文档按从上到下、从左到右排序即可对于多栏文档需要先分栏再在每栏内排序。PaddleOCR 自带的版面分析模型能识别标题、正文、表格、图片等区域输出带坐标的结果。你可以基于这些坐标自己写排序逻辑。我的做法是先按栏切分通过检测竖直空白区域再在每栏内按 y 坐标排序最后拼接。这套逻辑对大多数双栏论文和报纸排版都管用。3.4 一个可复现的 OCR 处理流程把上面的要点串起来一个完整的 OCR 处理流程大致是这样# 伪代码示意具体 API 以所用库的官方文档为准 def process_scanned_pdf(pdf_path): # 1. 将 PDF 每页渲染为高分辨率图片 images render_pdf_to_images(pdf_path, dpi300) results [] for img in images: # 2. 图像预处理 img to_grayscale(img) img denoise(img) img deskew(img) # 3. 版面分析得到各区域坐标和类型 layout analyze_layout(img) # 4. 对文本区域做 OCR text_blocks [] for region in layout.text_regions: cropped crop(img, region.bbox) text ocr_recognize(cropped, langch) text_blocks.append((region.bbox, text)) # 5. 按阅读顺序排序并拼接 ordered_text sort_by_reading_order(text_blocks) results.append(ordered_text) return results这段流程里渲染 DPI 和排序逻辑是两个最影响结果的地方。DPI 我一般设 300特殊小字文档会提到 400。排序逻辑则要根据文档类型调整没有万能方案。4. 多模态大模型解析 PDF 的实战方法4.1 什么情况下该上多模态大模型多模态大模型不是万能的也不是所有 PDF 都值得用它。我的判断标准是当文档的语义结构比文字内容更重要时才值得上视觉大模型。具体来说以下几种情况我会优先考虑多模态方案文档里有大量表格且表格结构对理解至关重要如财务报表、参数对比表。文档是图文混排图片本身携带关键信息如产品结构图、流程图。版面极其复杂传统 OCR 加版面分析很难还原如杂志排版、多栏带侧边栏。需要直接输出结构化格式如 Markdown、JSON省去后处理。反过来如果只是普通的单栏扫描文档用 OCR 就够了没必要花大模型的成本。4.2 页面渲染与提示词设计多模态解析的第一步是把 PDF 页面渲染成图片。这里有个细节渲染分辨率要匹配模型的视觉输入要求。太低模型看不清小字太高会超出模型的图像处理上限还可能被压缩导致失真。一般 150 到 200 DPI 是个平衡点具体要看模型文档。提示词设计是决定输出质量的关键。我常用的提示词结构包含三部分角色设定、任务描述、输出格式约束。比如你是一个文档解析助手。请将这张文档图片转换为结构化的 Markdown 文本。要求1保留标题层级2表格用 Markdown 表格还原保持行列对应3图片位置用占位符标注并简要描述图片内容4不要添加原文没有的内容。这里最后一条不要添加原文没有的内容非常重要因为视觉大模型有幻觉倾向会脑补一些看起来合理但原文没有的文字。加上这条约束能减少一部分幻觉但不能完全消除所以输出后仍需抽检。4.3 表格与图表的还原技巧表格是多模态解析里最难的部分。我的经验是简单表格直接让模型输出 Markdown 表格效果通常不错。合并单元格表格Markdown 表格不支持合并单元格需要让模型用特殊标记如空单元格或重复值来表达或者直接输出 HTML 表格。跨页表格需要把相邻页面一起送入模型并在提示词里说明这是跨页表格的连续部分。图表如柱状图、折线图的还原更麻烦。模型能描述图表大意但精确数值往往读不准。如果图表数据很关键我建议单独用专门的图表识别工具或者干脆保留原图在 RAG 里用图片检索的方式处理。4.4 成本与速度的平衡策略多模态大模型解析的成本主要来自 token 消耗而图片输入的 token 消耗远高于纯文本。一份几百页的 PDF 如果全走视觉模型成本可能高得离谱。我的平衡策略是分级处理先用文本提取判断每页是否有文字层。有文字层的页面走文本提取几乎零成本。无文字层的页面先用轻量 OCR 试一遍如果识别质量达标比如置信度高、版面规整就用 OCR 结果。只有 OCR 效果差或版面复杂的页面才送多模态大模型。这样能把大模型的调用量压到最低同时保证关键页面的质量。实测下来一份混合型 PDF 里真正需要视觉模型的页面往往不到三成。5. 九种 PDF 解析工具选型对比5.1 工具清单与定位市面上 PDF 解析工具很多我挑九种在 RAG 场景下最常被用到的按定位分成三组文本提取组PyPDF2 / pypdf纯 Python 库轻量适合简单原生 PDF。pdfplumber能提取文字和表格坐标信息完整适合需要精细控制的场景。pdfminer.six底层库控制力强但 API 较繁琐。综合解析组PyMuPDFfitz速度快支持文字、图片、渲染是我最常用的全能选手。Unstructured专为 RAG 设计能输出分块后的结构化元素开箱即用。Marker基于深度学习的 PDF 转 Markdown 工具对学术文档效果好。OCR 与视觉组PaddleOCR中文 OCR 首选可离线。Tesseract老牌 OCR英文场景够用。多模态大模型 API处理复杂版面的终极方案。5.2 关键维度横向对比工具原生文本扫描件表格速度部署难度推荐场景pypdf好不支持弱快低简单原生 PDF 快速提取pdfplumber好不支持较好中低需要表格和坐标pdfminer.six好不支持中慢中需要底层控制PyMuPDF很好不支持中很快低通用首选Unstructured好需配合 OCR好中中RAG 分块直出Marker好部分支持好慢中学术文档转 MarkdownPaddleOCR不支持好中中中中文扫描件Tesseract不支持一般弱中低英文扫描件多模态大模型好很好很好慢低复杂版面兜底5.3 选型决策树面对一个具体项目我会按下面的顺序做决策PDF 是原生数字的吗是的话优先 PyMuPDF 提取文本需要表格再加 pdfplumber。是扫描件吗中文走 PaddleOCR英文走 Tesseract质量要求高就上多模态。版面复杂吗复杂版面直接上多模态或 Marker别在传统工具上死磕。需要直接输出 RAG 分块吗用 Unstructured 能省掉自己写分块逻辑的功夫。有成本约束吗优先本地工具把大模型留给最难的那部分页面。提示不要迷信一个工具解决所有问题。我见过太多项目因为强行用单一工具处理所有 PDF最后在某个特殊文档上翻车。组合使用才是常态。5.4 各工具的实操注意事项PyMuPDF提取文字时get_text()默认按块返回顺序可能不符合阅读习惯。建议用get_text(dict)拿到带坐标的详细结构自己排序。它渲染页面的速度非常快很适合做先渲染再判断的分流逻辑。pdfplumber的表格提取依赖线条检测对于没有边框的表格靠空白对齐的效果一般。遇到这类表格可以调table_settings里的参数或者干脆走视觉模型。Unstructured的优势是直接输出带类型的元素Title、NarrativeText、Table 等非常适合 RAG 分块。但它的依赖较重安装时容易遇到系统库缺失的问题建议用官方提供的容器镜像。Marker对学术论文的公式和引用处理得不错但速度慢适合离线批处理不适合实时场景。PaddleOCR的坑主要在版本和模型下载。首次运行会自动下载模型网络不通时会卡住建议提前把模型文件准备好。6. 常见问题与排查技巧实录6.1 解析结果乱码或空白这是最常见的问题原因通常有三类编码问题PDF 内部用了非标准编码提取出来是乱码。解决方法是换工具试试PyMuPDF 对编码的兼容性通常比 pypdf 好。字体未嵌入有些 PDF 用了系统字体但没嵌入导致文字无法正确映射。这种情况只能走 OCR 或视觉模型。扫描件走了文本提取拿到的自然是空白。回到第 2 节先做分类。6.2 表格结构错乱表格错乱的表现是行列对不上、单元格内容串位。排查思路先确认表格有没有边框线。有线的用 pdfplumber 的线条检测无线的考虑视觉模型。检查是否有合并单元格。合并单元格是传统工具的重灾区。跨页表格要单独处理把相邻页合并后再解析。6.3 OCR 识别率低识别率低的排查清单现象可能原因解决方向整体模糊分辨率不足提高渲染 DPI 到 300文字倾斜扫描歪斜加纠偏预处理中文错字多语言包不对确认加载了中文模型数字混淆字体特殊换引擎或加后处理规则表格串行缺版面分析加版面分析模块6.4 多模态模型幻觉视觉大模型的幻觉表现为编造原文没有的内容。缓解手段提示词里明确要求只输出图中可见内容。对关键字段做交叉验证比如用 OCR 结果和模型输出比对。降低温度参数减少随机性。对输出做抽检发现幻觉率高的文档类型就换方案。6.5 处理速度太慢速度慢通常是因为全量走了重方案。优化方向做页面级分流能走文本提取的绝不走 OCR。OCR 和视觉模型调用做并发但注意控制并发数避免被限流。对重复文档做缓存相同哈希的文档不重复解析。我在实际项目里踩过最深的坑就是一开始没做分流把所有 PDF 都丢给视觉模型结果一份两百页的文档跑了大半个小时成本也高得吓人。后来改成文本提取优先、OCR 兜底、视觉模型只处理疑难页的三级分流同样的文档几分钟就跑完了质量还没下降。这个教训值得每个做 RAG 数据导入的人记牢解析策略的精细化程度直接决定了整个流水线的性价比。
