最近在做企业级 RAG 知识库，发现很多人卡在最前面那一步：PDF 文档导进去之后，检索出来的内容驴唇不对马嘴。排查到最后，绝大多数问题都出在图文解析上——扫描件、图片型 PDF、带表格的复杂版面，解析层一旦偷懒，后面 RAG 的召回和生成质量就是空中楼阁。这篇文章是 RAG 数据导入与解析系列的第二篇，专门聊图文与 PDF 解析，覆盖 OCR、多模态大模型方案，以及我实际测过的九种 PDF 解析工具选型。内容偏实战，适合正在搭知识库、或者被 PDF 解析虐过的同学参考。

1. 为什么图文与 PDF 解析是 RAG 的“第一道生死关”

1.1 非结构化数据里，PDF 是最难啃的骨头

很多人以为 RAG 的难点在 embedding 模型选型或者向量检索调参，其实真正决定知识库好不好用的，是数据进库之前那个“解析”环节。文本类数据（TXT、Markdown、HTML）还算友好，但 PDF 是个大杂烩：有天生就是文本的矢量 PDF，有扫描后生成的图片型 PDF，有图文混排的营销手册，还有各种复杂嵌套表格的财报。同一个 PDF 文件里，可能第一页是扫描图片，第二页是矢量文本，第三页是图文混排，第四页直接给你来个三栏报表。

这种异构性导致一个结果：没有任何一种单一的解析工具能通吃所有 PDF。用纯文本抽取工具去解析扫描件，抽出来的是空字符串；用 OCR 去解析正常文本 PDF，不仅浪费算力，还可能把清晰的文字识别出错。所以第一步不是选工具，而是先弄清楚你的 PDF 属于哪种形态，这决定了后续整个解析管线的走向。

以我手上的真实项目为例：我们知识库里有一批产品手册，总量 3000 多份 PDF，混合了三种类型——早期扫描版（纯图片）、后期矢量版（文字可选中）、以及设计稿导出的高保真版（文字+装饰性图形+表格）。如果统一用一种方案处理，结果就是一半以上的文档解析质量不达标。

1.2 解析质量直接决定召回上限

RAG 的基本流程是：文档切块（chunking）→ 向量化（embedding）→ 检索（retrieval）→ 生成（generation）。很多人忽略了一个链条关系——embedding 的质量取决于 chunk 的质量，chunk 的质量取决于解析的质量。解析阶段把表格拆乱了、把文字识别错了、把版面顺序搞反了，后面所有环节都是在错误的基础上做优化。你换个更强的 embedding 模型、调半天检索参数，都救不回来。

打个比方，解析阶段相当于给图书馆做图书编目。你把一本书的页码倒着贴、把图注当成正文、把表格里的数字漏抄了几个，那读者（大模型）来查资料的时候，找到的“相关章节”一定是错位的。RAG 项目里常说的“召回不准”，很多时候不是检索算法的问题，而是解析环节埋下的雷。

所以我的建议是：在 RAG 项目里，解析阶段至少要投入 30% 以上的精力。别急着调向量数据库，先把你手头文档的解析质量测明白——随机抽 20 份文档，人工核对解析出来的文本和原文档的吻合度，如果你自己都觉得没法看，那后面的 RAG 效果也不用期待。

1.3 图文 PDF 的五种典型形态与应对思路

我把实际工作中遇到的图文类 PDF 归纳为五种形态，每种形态对应不同的解析策略：

• 纯扫描图像型：整页都是图片，文字完全不可选中。这类必须走 OCR 流程，识别出文字之后再做版面还原。
• 文字+图片混排型：文字是矢量可选的，图片是嵌入的位图。这类优先用文本抽取工具，图片部分单独提取，需要用多模态模型或者 OCR 补充图片内的信息。
• 复杂表格型：有横竖线框的表格（lattice）、没有线框靠排版对齐的表格（stream）。这类是 PDF 解析的重灾区，需要专门的表格抽取工具。
• 多栏排版型：论文、杂志常见的双栏/三栏布局。解析时要注意阅读顺序，按栏切块而不是按视觉位置切块。
• 表单/票据型：发票、合同、订单，字段位置固定但内容各异。这类适合用 OCR+字段规则或者多模态模型做结构化抽取。

明确这五种形态之后，你会发现“PDF 解析”其实不是一个任务，而是一个任务族。下面的内容，我会按这条线索展开：OCR 怎么选型、多模态模型怎么用、九种 PDF 工具分别适合哪种形态。

2. OCR 解析：从引擎选型到一条可落地的识别管线

2.1 OCR 不是“一个库”，是一整套流程

很多初学者以为 OCR 就是把图片扔给一个识别引擎，然后拿回字符串。真实项目里完全不是这么简单。一套能用的 OCR 管线至少包含五个环节：图像预处理 → 版面分析 → 文字检测 → 文字识别 → 后处理纠错。

图像预处理解决“图不清”的问题。扫描件常见的毛病是歪斜、偏暗、有噪点、分辨率不足。预处理阶段要做的是：用自适应阈值或去噪算法处理阴影和噪点，检测文本行的倾斜角度并做旋转校正，必要时把低分辨率图片做超分处理。我自己惯用一个标准：OCR 输入图片的 DPI 至少要达到 300，低于 200 的识别准确率会明显下降。

版面分析解决“先读哪块”的问题。一页 PDF 扫描件往往包含标题、正文、页眉页脚、图片、表格多个区域。如果不做版面分析直接整页识别，识别结果就是一团乱序的文字流。正确的做法是先把页面拆成若干区域，给每个区域打上类型标签（标题/正文/表格/图片/页眉页脚），然后再按阅读顺序拼接。

2.2 主流 OCR 引擎对比与选型逻辑

目前 OCR 引擎的选择，基本围绕三个方向：开源自部署、商业云 API、以及离线商用 SDK。我基于实际项目经验做了一张对比表：

中文场景我首选 PaddleOCR，原因很直接：它对中文文本的识别精度在一众开源方案里是明显领先的，而且自带方向分类器和文本检测模型，对倾斜、竖排、多栏都有专门的优化。Tesseract 的定位是轻量级英文识别，中文效果差一些，语言包也相对粗糙。

商业 API 的优势是省心，版面分析、表格识别都集成好了，缺点是数据要过云，很多企业内部知识库的数据合规这关就过不了。我的建议是：能自部署就自部署，PaddleOCR 的部署成本在可接受范围内；如果只是临时处理几百份文件，用云 API 先跑通流程没问题。

2.3 一个可直接复用的 OCR 识别流水线

这里给出一套我实际在 RAG 项目里用过的 PaddleOCR 流水线，代码结构可以直接抄作业。核心思路是：先对 PDF 页面做渲染转图，再逐页送入 OCR 管线，最后按页输出 Markdown 格式文本。

import fitz # PyMuPDF，负责将PDF页面渲染为图片 from paddleocr import PaddleOCR ocr = PaddleOCR( use_angle_cls=True, # 启用方向分类，处理旋转文本 lang="ch", # 中文模型 ocr_version="PP-OCRv4", # 较新的识别模型，精度更高 show_log=False ) pdf_path = "scan_sample.pdf" doc = fitz.open(pdf_path) output = [] for page_idx in range(len(doc)): page = doc[page_idx] # 设置渲染分辨率，约200 DPI mat = fitz.Matrix(200 / 72, 200 / 72) pix = page.get_pixmap(matrix=mat) img_path = f"page_{page_idx}.png" pix.save(img_path) # PaddleOCR识别 result = ocr.ocr(img_path, cls=True) lines = [] for line in result[0]: # 每条结果是 [框坐标, (文本, 置信度)] lines.append(line[1][0]) output.append("\n".join(lines)) # 将识别结果合并为Markdown段落 full_text = "\n\n".join(output)

实际操作中要注意两个细节。第一，渲染分辨率不要一上来就拉满，300 DPI 是性价比很高的阈值，过高的分辨率会显著增加识别耗时，而精度的提升有限。第二，use_angle_cls=True一定要开，扫描件里经常混入个别旋转了 90 度或 180 度的页面，方向分类器能把它们先“摆正”再识别。

2.4 OCR 实战中常见的“翻车点”

OCR 这块我踩过的坑不少，挑几个最有代表性的说说。

第一个坑是表格识别被 OCR 完全打乱。OCR 输出的是一行行文本，表格的行列结构信息在识别过程中被丢掉了。比如一份报价单，四列的价格信息被 OCR 顺序输出，RAG 检索时会把“型号”和“价格”混在一起。解决思路是：检测到页面中存在表格区域时，不要走通用 OCR，而是走专门的表格识别模型或者表格抽取工具。PaddleOCR 里也有表格识别模型（TableRec），但效果只能说够用，复杂表格建议用后面要讲的 Camelot。

第二个坑是中文标点和数字误识别。OCR 引擎对“1”和“l”、“0”和“O”的区分经常出错，这在文档型知识库里是致命的——合同编号、金额数字错了，检索出来就是错的。后处理阶段需要做数字和字母的置信度过滤，甚至针对业务词库做纠错。我一般会接一层简单的规则纠错：比如检测到金额字段包含字母时，做一次基于词典的替换。

第三个坑是识别结果顺序错乱。多栏版面的 PDF 扫描件，OCR 默认的读取顺序经常先读右栏再读左栏，或者跳来跳去。解决方式是在版面分析阶段就把栏结构识别出来，然后按栏拼接。目前开源方案里，PaddleOCR 的 PP-Structure 能从版面分析层面解决一部分问题，但对于特别复杂的杂志排版，仍然需要人工校验或规则干预。

3. 多模态大模型解析：让模型直接“看图识字”

3.1 多模态模型补上 OCR 覆盖不到的短板

OCR 能识别文字，但它不“理解”文档。遇到三种情况 OCR 就很吃力：图片里嵌入了逻辑关系（比如流程图、架构图）、文字信息需要结合图表上下文才能理解、版面结构太复杂以至于纯文字抽取丢失信息。这时候多模态大模型的价值就出来了。

多模态大模型（如 GPT-4o、Qwen-VL、InternVL 这类视觉语言模型）可以直接把页面图像当作输入，输出对页面内容的理解。它们不仅能识别文字，还能理解图表的语义、梳理上下文的逻辑关系、甚至直接输出结构化的 Markdown 或 JSON。在 RAG 场景里，多模态模型通常在两条路径上发挥作用：一是作为解析引擎直接抽取页面结构化信息，二是作为 OCR 的后处理，对识别结果的逻辑关系进行整理。

这几年我观察到的趋势是：多模态模型在文档理解上的能力提升非常快，已经在不少场景里可以直接取代“OCR+规则”的复杂管线。但代价是成本高、速度慢，而且存在幻觉风险——模型可能“脑补”出文档里不存在的内容。所以实际项目中，我的策略是分场景使用，而不是全面替换。

3.2 三种典型用法：按场景对号入座

第一种是整页理解+结构化输出。把关 PDF 的关键页面转成图片，直接丢给多模态模型，让它输出 Markdown 或者 JSON。这个方案胜在简单，一条链路上搞定版面分析和内容提取。适合页面结构相对简单、对成本不敏感的场景。实操时把提示词写好是重点，我经常用这样一套模板：请将这张图表页面转化为 Markdown 格式，保持表格结构完整，对图片用 [图片描述] 占位，并在末尾输出该页的核心要点摘要。

第二种是版面分析先行，OCR 兜底。用多模态模型判断页面里有哪些区域、这些区域属于什么类型、阅读顺序是什么，然后把文字识别交给 OCR 引擎去做。这种做法的好处是准确率高——版面顺序经过语义理解是准的，文字内容经过 OCR 是稳的。缺点是流程长，适合对质量要求高的票据类、合同类 PDF。

第三种是选择性增强。OCR 处理完之后，把识别文本连同页面缩略图一起发给多模态模型，让它校验和纠错。比如 OCR 对数字、金额识别不确定的地方，模型可以直接看图纠正。这种做法成本可控，只对少量存疑页面做二次确认。

3.3 效果、成本与时延的平衡策略

多模态模型解析一个页面，先说成本。以主流商用模型为例，一张页面图像按 token 计费，成本远高于纯 OCR。一千页的文档处理下来，费用是看得见的。所以我的建议是做个“难度分级”：先用规则或轻量模型判断页面的复杂度，简单页面走 OCR，复杂页面才走多模态模型。实际测试中，一般文档集里 70% 的页面是普通文本或简单表格，OCR 完全够用；只有 30% 的页面需要多模态模型来处理。

时延方面，多模态模型的单页推理时间通常需要数秒到十几秒不等，批量处理时要做好队列和重试机制。我处理过一份 500 页的扫描书，用多模态模型跑完大概需要四五个小时，而纯 OCR 四十分钟就能跑完。所以批量任务的策略是：先跑 OCR，把高分置信度的结果直接用，低置信度的页面再排队进入多模态模型做二次解析。这个“先快后慢”的组合方案，兼顾了质量、成本和时间。

还有一个容易忽略的点：多模态模型输出要设定强格式约束。我一般请求 JSON 输出，并做后置校验，JSON 解析失败就重试。别让模型自由发挥，否则下游切块和 embedding 会疯掉。

4. 九种 PDF 工具选型：按场景对号入座

4.1 全文索引派：pdfplumber 与 PyPDF2

pdfplumber是我处理“文本型 PDF”的首选工具。它的底层基于 PDFMiner，但对表格和字符位置的暴露做得更好。用它提取文本时，可以拿到每个字符的坐标、字体、大小，这意味着你可以根据坐标恢复版面结构。我用它做过一个双栏论文 PDF 的重排——基于 x 坐标把每行文本分配到左栏或右栏，再按栏拼接，阅读顺序完全正确。

import pdfplumber with pdfplumber.open("paper.pdf") as pdf: pages_content = [] for page in pdf.pages: # extract_text(layout=True) 保持相对位置排版 text = page.extract_text(layout=True) pages_content.append(text)

extract_text(layout=True)这个参数值得单独强调。它输出的文本会保留页面上的相对缩进和换行，对于保留代码块、诗歌、会议纪要这类对缩进敏感的内容非常有用。默认的extract_text()容易把同行不同列的内容混在一起，所以处理 RAG 数据时尽量开启 layout 模式。

PyPDF2（及其维护分支 pypdf）是最普及的 PDF 文本抽取库，胜在轻量、无依赖、简单。但它的文本抽取质量比较原始，几乎不做版面还原，抽取结果经常是“从左上到右下”的原始文本流。我的建议是：PyPDF2 只作为快速预览和简单的文本兜底，不适合正式 RAG 数据处理。举例来说，同一份双栏 PDF，pdfplumber 能恢复出左右分栏的阅读顺序，PyPDF2 输出的则是两栏文字交错堆叠，根本没法直接切块。

4.2 版面还原派：PyMuPDF 与 PDFBox

PyMuPDF（fitz）是 PDF 工具里的瑞士军刀。它最核心的能力是把 PDF 页面渲染成高分辨率图像，同时也可以做文本提取和元素定位。在 OCR 流程里，我基本都用它做“转图片”这一步——渲染速度快、清晰度高、内存占用可控。

除了渲染，PyMuPDF 还能提取页面中的图片元素，这在 RAG 场景里特别有用。知识库里如果希望保留文档中的配图信息，可以用page.get_images()把内嵌图片导出，再配合多模态模型做图片内容摘要，最后把摘要文本连同正文一起入库。

import fitz doc = fitz.open("document.pdf") for page in doc: # 提取图片 for img_index, img_info in enumerate(page.get_images(full=True)): xref = img_info[0] base_image = doc.extract_image(xref) with open(f"img_{page.number}_{img_index}.png", "wb") as f: f.write(base_image["image"])

PDFBox是 Java 生态的老牌 PDF 库，功能覆盖面很广。如果你的 RAG 服务端是 Java 技术栈，PDFBox 是绕不开的选择。它支持文本抽取、PDF 转图片、表单填写等，社区成熟、坑少。但它的 API 风格偏底层，文本抽取的智能程度不高，复杂版面同样需要自行处理坐标信息。

从跨语言角度看，Python 生态做 RAG 数据解析有天然优势——后续直接接 embedding 和向量库很方便，所以我个人主推 Python 工具链。PDFBox 更适合已有 Java 服务、需要内嵌 PDF 处理能力的团队。

4.3 复杂表格派：Camelot 与 tabula-py

表格是 PDF 解析公认的“硬骨头”，专门说说。

Camelot是我用过的表格抽取工具里效果最好的。它有两种工作模式：lattice（格子模式）用于处理有明显框线的表格，stream（流模式）用于处理没有框线、靠空白对齐的表格。lattice 模式基于线条检测还原单元格，精度极高；stream 模式基于文本坐标流划分列，对无框线表格效果不错但需要调参。

import camelot # lattice 模式：适合有线框的表格 tables = camelot.read_pdf("table_with_lines.pdf", flavor="lattice") # stream 模式：适合无线框、按空白对齐的表格 tables = camelot.read_pdf("table_no_lines.pdf", flavor="stream") for table in tables: df = table.df markdown_table = df.to_markdown()

用 Camelot 的时候，我最常遇到的坑是pdfplumber 提取的文本里表格内容丢失。原因很简单：pdfplumber 的extract_text()对复杂表格的单元格内容经常漏项，而 Camelot 是专门为表格设计的维度，不会漏。所以凡是检测到页面里有表格，我会直接走 Camelot 分支，而不是混在通用文本流里。

tabula-py是另一个表格抽取工具，底层用的是 Java 的 tabula-java。它的优势是简单易用，tabula.read_pdf()一行代码就能输出 DataFrame。缺点是对有线框表格的还原能力不如 Camelot 的 lattice 模式，复杂嵌套表头的处理容易出错。我的经验是：表格结构简单、线框完整，用 tabula-py 节省时间；表格复杂、线框断裂或者有合并单元格，用 Camelot。

4.4 文档智能派：Unstructured 与 LlamaParse

如果你不想自己拼装 OCR、表格抽取、版面分析这条管线，可以考虑Unstructured。它是一个专门为 RAG 数据解析设计的开源库，把 PDF 解析封装成了一套统一接口。它能自动识别文本型 PDF 和图片型 PDF，图片型自动走 OCR，输出则是分好块的文档元素列表。

from unstructured.partition.pdf import partition_pdf elements = partition_pdf( "mixed.pdf", strategy="auto", # 自动选择策略 extract_images_in_pdf=True, # 提取内嵌图片 infer_table_structure=True, # 识别表格并转为HTML ocr_languages="chi_sim", ) for element in elements: print(element.category, element.text)

Unstructured 的价值在于把常见的解析逻辑“标准化”了——输出统一为按元素切分的结构，方便直接对接后续的 chunking 和 embedding。它支持strategy参数调整解析策略，比如fast模式只抽文本，hi_res模式做高精度版面分析并调用 OCR。我实测下来，hi_res模式的表格识别和版面还原明显更好，但耗时也翻了几倍。这个库非常适合 RAG 项目的 MVP 阶段，让你不用在解析层面重复造轮子。

LlamaParse是 LlamaIndex 推出的托管解析服务，能力上是一个多模态解析引擎，商业产品里效果属于第一梯队。它对复杂表格、嵌套版面、混合图文的理解能力强，输出是带结构信息的 Markdown。但这是 SaaS 服务，数据要走它的云端处理，对数据合规要求高的企业就得慎重。我一般在快速试验阶段用它验证“解析效果天花板”，确认效果之后回来自部署方案。

4.5 老牌商用派：Adobe Extract API 与 ABBYY

在企业级场景里，Adobe PDF Extract API不能忽视。它是 Adobe 的云端解析服务，输出结构化的 JSON，包含文本、表格、版面分类等信息。解析质量稳定，对复杂排版的处理尤其老练，但同样是云端服务，按页计费。

ABBYY是老牌的 OCR 与文档识别商用引擎，在扫描件识别、多语言支持上有着深厚积累。它提供离线 SDK，适合对数据私密性要求极高的金融、政务类 RAG 项目。ABBYY 的识别精度在商业引擎里属于天花板级别，尤其是对模糊扫描件和艺术字体的处理明显优于开源方案。缺点是价格不便宜，而且 SDK 的集成工作量比开源方案大。

4.6 九种工具选型速查表

把上面提到的方案汇总成一张表，方便你按场景直接选型：

表格里的选型逻辑，说白了就是“三层叠加”：文本型 PDF 用 pdfplumber 或 PyMuPDF 兜底，扫描图片型 PDF 走 OCR 管线，复杂表格单独用 Camelot 或交给多模态模型。没有银弹，只有组合。

5. 常见问题与排查技巧实录

5.1 中文乱码与 OCR 语言包问题

中文 PDF 解析最容易遇到的问题就是乱码。一种情况是文本型 PDF 用了自定义字体编码，PyPDF2 直接抽取会产生乱码。排查方法：先用 pdfplumber 抽取，把文本输出到终端看前 100 个字，如果出现大量乱码或无意义的十六进制字符，基本可以确定是字体编码问题。

解决思路是换库或者换策略：pdfplumber 遇到字体编码问题时，我会改用 PyMuPDF 的page.get_text()，它对标准 Unicode 映射的还原能力更强。如果还是乱码，说明这个 PDF 可能用了嵌入子集字体，这时候只能把页面渲染成图片，走 OCR 流程。

OCR 语言包这块也有讲究。很多人的做法是只装中文英文语言包，但业务文档里可能混有繁体字。PaddleOCR 的lang="ch"默认包含简繁中文，但特定方言或生僻字可能需要额外处理。如果 OCR 结果里频繁出现“口口口”这样的占位符，优先检查输入图片分辨率是否不足，其次检查语言包是否覆盖了目标语言。

5.2 表格数据“串行”与结构丢失

表格解析最常见的翻车是“串行”——表格的四列内容被输出成一段连续文本，RAG 检索时把第一列的标题和第二列的内容拼接起来，答非所问。这种情况我遇到多次，归根结底是表格解析没有单独处理。

我的排查流程是：先在 PDF 里定位到表格所在页面，用 Camelot 分别跑lattice和stream两种模式，对比哪种输出更接近原始表格。如果两种模式都不行，再上一个多模态模型，把页面截图直接发给模型，让它输出 Markdown 表格。实践下来，合并单元格多、无框线、内容换行多的复杂表格，多模态模型的胜率最高。

还有一个小技巧：表格解析完成后，把输出的 Markdown 表格里每行的单元格数做个校验。如果同一张表格各行单元格数不一致，基本可以判断是解析出错。这个规则简单有效，能筛出大部分“结构丢失”问题。

5.3 扫描件质量差导致 OCR 精度低

扫描件的质量参差不齐：有手机拍的、有传真机扫的、还有旧书翻拍的。常见问题包括背景发黄、文字倾斜、阴影遮挡等。开局就送 OCR 的话，结果会很惨。

我的处理顺序是：先用 OpenCV 做图像增强——灰度化、自适应阈值二值化、去除背景噪点，再做透视校正和倾斜校正。这一套预处理跑完，OCR 的准确率能提升不少。实操里注意一点：二值化操作要选对方法，全局阈值对光照不均的图片效果差，自适应阈值（如cv2.adaptiveThreshold）对扫描件的适应性明显更好。

碰到页面有折痕或者阴影，OCR 经常把阴影里的文字识别成噪点。我的一般操作是在预处理阶段用形态学操作（开运算）把细小的连接噪点去除，再把图像亮度归一化。如果你的扫描件质量实在差，建议直接上多模态模型，它对低质量图像的抗噪能力比传统 OCR 强得多。

5.4 结构化信息抽取后仍然“召回不全”

有人问过：解析结果看起来都对，文本也清晰可读，为什么 RAG 检索时还是召回不到关键信息？这个问题往往出在“解析正确但切块不当”上。

比如一张产品参数表被解析成 Markdown 表格，丢给 RAG 之后，切块工具把整个表格切成一大块文本。用户提问时，向量检索关注的是语义相似度，过长的 chunk 会稀释有效信息。这里我建议在解析阶段就做“结构化重塑”：把表格按行切分、每一行转成一个语义独立的文本块，比如“产品型号 A100 的功率是 850W，电压是 220V”，这样的块在向量检索时更容易命中精确信息。

还有一种情况是解析结果把页眉页脚都保留下来了，每个 chunk 都带着重复的页码和公司名，这会稀释向量密度，拖低召回精度。在解析后处理阶段，用规则把页眉页脚过滤掉，是非常值得的一步操作。Unstructured 里可以直接配置exclude_header_footer，自定义管线的话就需要自己在文本流里识别并剔除。

5.5 成本与性能平衡：批量解析的压测经验

最后分享一个批量解析的性能压测数据，供你做方案时参考。我用一台 8 核 16G 的 CPU 机器跑 1000 份混合 PDF（约 3000 页）：

• 纯文本型 PDF 用 pdfplumber 抽取：耗时约 5 分钟，几乎不占资源；
• 扫描图片型 PDF 用 PaddleOCR（CPU 模式）识别：耗时约 2 小时，CPU 全程吃满；
• 开启表格识别和版面分析（hi_res 模式）：耗时约 5 小时，内存峰值 8G 左右；
• 多模态模型解析：每页约 3~10 秒，单页成本按 token 计费。

从这组数据能看出，解析方案的选择对项目交付时间的影响是数量级的。我的经验是：先做“文档画像”——统计你的 PDF 集里有多少是文本型、多少是扫描型、多少含复杂表格，再按比例估算解析耗时和成本。如果时间紧、预算低，优先优化“重页面”的解析策略，比如只对复杂页面走多模态，简单页面全走 OCR。

写在最后

关于 RAG 图文与 PDF 解析，我个人在实际操作中最深的一点体会是：不要追求“一个大而全的工具”，而要搭建“按文档形态分流的管线”。文本型 PDF、扫描型 PDF、复杂表格 PDF，各自走最擅长的解析路径，最后统一输出标准化的 Markdown 或 JSON，这才是 RAG 知识库解析层的正确打开方式。

最后再分享一个我正在用的技巧：在解析层增加一个“双重校验”环节——同一批文档，用 pdfplumber 抽取文本，再用 PyMuPDF 渲染成图后跑 OCR，两类结果做重叠比对，文本重合度低于阈值的页面自动标记为“存疑”，进入人工复核队列。这个笨办法帮我发现了不少文档里的隐藏表格和图片型文字，也让我对入库数据的信心提高了一个档次。解析这层功夫下足了，后面 RAG 的检索、生成才会真正省心。