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

做过 RAG 项目的人都有一个共同体会：模型选型、向量库调优、检索策略这些看起来"高级"的环节，往往不是最耗时间的。真正让人熬夜的，是数据导入和解析这一段——尤其是当你的知识库里混着扫描件、截图、带复杂表格的 PDF、双栏排版的论文、甚至手机拍的合同照片时。

我在过去两年里帮团队搭过好几个 RAG 知识库，从最开始的"纯文本 Markdown 一把梭"，到后来不得不面对一堆 PDF 和图片，踩的坑足够写一本书。这一篇就专门聊图文与 PDF 解析这条链路：OCR 怎么选、多模态大模型在什么场景下值得上、九种主流 PDF 解析工具各自适合什么活。核心关键词 RAG、OCR、多模态大模型、PDF、工具选型会贯穿全文，我会尽量把每个选择的"为什么"讲清楚，而不是甩一张对比表就完事。

先说清楚这篇适合谁看：如果你正在搭 RAG 知识库，手里有一批 PDF 和图片要处理；或者你已经跑通了纯文本流程，现在卡在"扫描件识别不准""表格全乱""公式丢失"这些问题上；再或者你在做技术选型，想知道什么场景该用传统 OCR、什么场景该上多模态大模型——那这篇就是给你写的。全文基于我自己的实操经验，参数和步骤都可以直接抄作业，但请结合你的数据特点做调整。

2. RAG 数据导入的整体设计与解析链路拆解

2.1 一条完整的解析链路长什么样

很多人一上来就问"用哪个 PDF 工具最好"，这个问题本身就问错了。PDF 解析从来不是单点工具的事，而是一条链路。我习惯把它拆成五段：

1. 格式探测：先判断这个文件是"原生电子 PDF"还是"扫描件/图片 PDF"。这一步决定了后面走哪条路。原生 PDF 里文字是可提取的，扫描件里文字是像素，必须 OCR。
2. 版面分析：识别出标题、正文、表格、图片、页眉页脚、脚注、双栏结构。这一步做不好，后面提取出来的文字顺序就是乱的。
3. 内容提取：文字走文本层或 OCR，表格走表格识别，图片走图像描述或直接存图。
4. 结构化重组：把提取出来的碎片按阅读顺序拼回有语义的块（chunk），保留层级关系。
5. 元数据标注：给每个 chunk 打上来源、页码、章节、类型（正文/表格/图注）等标签，方便检索时过滤和溯源。

这五段里，第一段和第二段是最容易被忽略、却最影响最终效果的。我见过太多人直接拿 PyPDF2 把文字抽出来就丢进向量库，结果检索出来的内容顺序错乱、表格串行，模型答非所问，然后回头怪 embedding 模型不行。

2.2 为什么解析质量直接决定 RAG 上限

打个比方：RAG 就像一个开卷考试的学生，向量库是他的参考书，检索是翻书，生成是答题。如果参考书本身是错乱的、缺页的、表格串行的，那这个学生翻得再准也答不对。解析就是"编参考书"的过程，它决定了知识的上限。

具体来说，解析质量影响三个环节：

• 切块（chunking）：如果解析出来的文字没有正确的段落和标题边界，切块就会把一句话切成两半，或者把两个不相关的段落塞进一个 chunk。检索时要么召回不全，要么召回噪声。
• 检索命中：表格如果被解析成一行行错位的文字，用户问"某年某月的营收是多少"，检索根本匹配不到。
• 生成溯源：如果没保留页码和章节元数据，模型答完你没法验证它是不是在胡说，也没法给用户展示引用来源。

所以我的原则是：宁可解析慢一点、贵一点，也要保证质量。后面讲工具选型时，这个原则会反复出现。

2.3 方案选型的三个核心权衡维度

面对一堆工具，怎么选？我一般看三个维度：

这三个维度不是独立的。比如你有一批扫描的财务报表，那"扫描件 + 复杂表格 + 大批量"三个条件叠加，基本就排除了纯本地轻量方案，要么上商用 OCR API，要么自建带表格识别的多模态管线。

3. OCR 与多模态大模型：到底该用哪个

3.1 传统 OCR 的能力边界在哪里

传统 OCR（比如 Tesseract、PaddleOCR、以及各家云厂商的通用 OCR）本质上是"检测文字框 + 识别字符"两阶段。它在规整的印刷体、清晰扫描件上表现非常好，速度快、成本低、可本地部署。

但它的边界也很明显：

• 版面理解弱：它告诉你"这一块是文字"，但不告诉你"这是标题还是正文""这是表格的第几行第几列"。表格识别需要额外的表格结构识别模型。
• 手写体吃力：印刷体识别率能到 99%，手写体可能掉到 70% 以下，尤其是连笔。
• 公式和特殊符号：数学公式、化学结构式基本无能为力。
• 多语言混排：中英混排还行，但小语种、竖排文字容易翻车。我实测过某些 OCR 对韩文的识别，直接返回空或者乱码，这种情况要么换模型，要么换方案。

所以传统 OCR 的定位很清楚：大批量、规整、以纯文字为主的扫描件，它是性价比之王。

3.2 多模态大模型补上了哪块短板

多模态大模型（能同时理解图像和文字的模型）在解析场景里的价值，不是"识别得更准"，而是"理解得更深"。它能把一张图或一页 PDF 直接"看懂"，输出结构化的 Markdown，包括：

• 正确的阅读顺序（双栏、多栏都能处理）
• 表格转成 Markdown 表格
• 公式转成 LaTeX
• 图片生成描述文字
• 甚至能理解图表里的趋势并写成一句话

我拿同一页双栏论文做过对比：传统 OCR 输出的是左右两栏文字交错的一坨，多模态模型直接输出结构清晰的 Markdown，标题、正文、公式、图注各归各位。这个差距在 RAG 场景里是决定性的。

但多模态大模型也有代价：

• 成本高：按 token 或按页计费，大批量处理时账单很吓人。
• 速度慢：一页可能要几秒到几十秒，不适合实时。
• 有幻觉风险：它可能"脑补"出原文没有的内容，尤其是模糊的扫描件。这点在 RAG 里很危险，因为错误内容会被当成事实检索出来。

3.3 混合策略：什么场景用什么

我的实操建议是分层处理，而不是二选一：

• 第一层：格式探测。原生电子 PDF 优先走文本层提取，根本不用 OCR，又快又准。
• 第二层：规整扫描件走传统 OCR。清晰、印刷体、纯文字的，用 PaddleOCR 或云 OCR 批量跑，成本可控。
• 第三层：复杂版面/表格/公式走多模态。只把那些 OCR 搞不定的页面挑出来，送给多模态模型，控制成本。
• 第四层：人工抽检。对多模态输出的结果做抽样校验，尤其是数字和金额，防止幻觉。

提示：多模态模型输出的内容，凡是涉及数字、金额、日期、专有名词的，务必做二次校验。我吃过亏，模型把"1,234"识别成"1,284"，检索出来直接导致答错。

3.4 一个容易被忽略的点：图片本身要不要入库

热词里有人问"RAG 知识库能存储图片嘛"。答案是能，但要分情况：

• 装饰性图片（logo、背景图）：直接丢弃，别浪费存储和检索额度。
• 信息性图片（流程图、架构图、截图）：用多模态模型生成文字描述，把描述入库，原图存对象存储，chunk 里放图片链接。这样检索时能命中描述，展示时能调出原图。
• 图表（柱状图、折线图）：让多模态模型把数据点读出来转成表格，比纯描述有用得多。

这个策略的核心是：入库的是可检索的语义，原图只是附件。别指望向量库直接检索像素。

4. 九种 PDF 解析工具选型实战

4.1 选型前先明确你的文档画像

在列工具之前，先做一件事：抽样 20 份文档，人工标注它们的类型。统计一下原生电子版占比、扫描件占比、含表格占比、含公式占比、多栏占比。这个画像直接决定选型。我见过团队上来就买最贵的商用方案，结果发现 90% 的文档是原生电子版，用免费库就够了，纯属浪费。

4.2 九种工具逐一拆解

下面这九种是我实际用过或深度评估过的，按"轻量到重量"排序。

1. PyPDF2 / pypdf

最基础的纯 Python 库，只能提取原生 PDF 的文本层。优点是零依赖、快；缺点是遇到扫描件直接返回空，版面信息基本没有，表格会串行。适合做格式探测的第一道筛子，不适合做主力解析。

2. pdfplumber

同样是 Python 库，但比 PyPDF2 强在能提取表格和字符坐标。它的表格提取基于线条和文字位置，对规整表格效果不错。缺点是速度慢，复杂表格容易漏。适合原生电子版、表格结构规整的场景。

3. PyMuPDF（fitz）

速度和功能平衡得最好的本地库。文本、图片、坐标、页面渲染都能做，还能把 PDF 页渲染成图片喂给 OCR 或多模态模型。我几乎每个项目都会装它，作为"万能工具"。缺点是表格结构识别需要自己写逻辑。

4. pdfminer.six

老牌库，文本提取的精细度高，能拿到每个字符的位置和字体信息。适合需要深度分析版面的场景，但 API 比较难用，速度也一般。新手不太推荐直接上手。

5. Tesseract

老牌开源 OCR 引擎，支持多语言。优点是免费、可本地、社区大；缺点是中文识别率一般，版面分析弱，需要配合预处理（去噪、纠偏、二值化）才能出好效果。适合预算为零、文档规整的个人项目。

6. PaddleOCR

国产开源 OCR，中文识别率明显优于 Tesseract，自带版面分析和表格识别模块。我实测下来，规整的中文扫描件识别率能到 95% 以上。缺点是部署稍重，需要装 PaddlePaddle。适合中文为主、需要本地部署的场景。

7. 云厂商通用 OCR API

各家云都有通用 OCR 和文档解析服务，识别率高、支持表格和版面、按量计费。优点是省心、准；缺点是数据要出本地、长期成本高、有并发限制。适合对准确率要求高、数据敏感度低、批量不算特别大的场景。

8. 商用文档解析 API（专门做 PDF 结构化的）

这类服务专门针对复杂 PDF，能输出结构化 Markdown，表格、公式、多栏都处理得不错。适合金融、法律这类对结构要求极高的行业。成本最高，但省下的开发时间往往值这个价。

9. 多模态大模型 API

前面讲过，适合复杂版面、表格、公式、图文混排。用法是把 PDF 页渲染成图片，直接丢给模型，让它输出 Markdown。适合作为"兜底方案"，处理其他工具搞不定的硬骨头。

4.3 工具选型对照表

4.4 我的组合拳方案

实际项目里我很少只用一种，通常是组合：

• PyMuPDF 做格式探测和页面渲染：先判断有没有文本层，没有就渲染成图。
• 原生电子版走 pdfplumber + PyMuPDF：文本和表格分别提取。
• 扫描件走 PaddleOCR：批量、本地、成本低。
• 复杂页面走多模态大模型：只处理 OCR 效果差的页面。
• 最后统一做结构化重组：把各路结果拼成一致的 chunk 格式。

这套组合的核心思想是分级处理、按需升级，把贵的资源用在刀刃上。

5. 实操过程与核心环节实现

5.1 环境准备与依赖安装

先装基础环境。我习惯用 conda 建独立环境，避免依赖冲突。

conda create -n rag-parse python=3.10 conda activate rag-parse pip install pymupdf pdfplumber pypdf pillow pip install paddlepaddle paddleocr

如果要用多模态模型，再装对应 SDK。注意 PaddleOCR 首次运行会下载模型，国内网络可能需要配置镜像源。

5.2 第一步：格式探测与分流

这一步的目标是给每个 PDF 打标签：原生电子版还是扫描件。

import fitz # PyMuPDF def detect_pdf_type(pdf_path, sample_pages=5): doc = fitz.open(pdf_path) total_chars = 0 pages_to_check = min(sample_pages, len(doc)) for i in range(pages_to_check): page = doc[i] text = page.get_text() total_chars += len(text.strip()) doc.close() avg_chars = total_chars / pages_to_check # 经验阈值：平均每页少于 50 个字符，基本可判定为扫描件 if avg_chars < 50: return "scanned" return "digital"

这个阈值 50 是我实测调出来的。原生电子版每页通常几百到几千字符，扫描件即使有隐藏文本层也往往很少。你可以根据自己文档调整。

5.3 第二步：原生电子版的文本与表格提取

原生电子版优先走文本层，别浪费 OCR 资源。

import pdfplumber def extract_digital_pdf(pdf_path): result = [] with pdfplumber.open(pdf_path) as pdf: for page_num, page in enumerate(pdf.pages): text = page.extract_text() or "" tables = page.extract_tables() result.append({ "page": page_num + 1, "text": text, "tables": tables }) return result

表格提取出来后，要转成 Markdown 格式再入库，这样检索和生成都友好：

def table_to_markdown(table): if not table: return "" header = table[0] rows = table[1:] md = "| " + " | ".join(str(c or "") for c in header) + " |\n" md += "| " + " | ".join(["---"] * len(header)) + " |\n" for row in rows: md += "| " + " | ".join(str(c or "") for c in row) + " |\n" return md

5.4 第三步：扫描件的 OCR 处理

扫描件先用 PyMuPDF 渲染成高分辨率图片，再喂给 PaddleOCR。渲染的 DPI 很关键，我一般用 300，太低识别不准，太高速度慢。

import fitz from paddleocr import PaddleOCR ocr = PaddleOCR(use_angle_cls=True, lang="ch") def ocr_scanned_pdf(pdf_path, dpi=300): doc = fitz.open(pdf_path) all_text = [] for page_num in range(len(doc)): page = doc[page_num] # 渲染成图片 mat = fitz.Matrix(dpi / 72, dpi / 72) pix = page.get_pixmap(matrix=mat) img_path = f"/tmp/page_{page_num}.png" pix.save(img_path) # OCR result = ocr.ocr(img_path, cls=True) page_text = "\n".join([line[1][0] for line in result[0]]) if result[0] else "" all_text.append({"page": page_num + 1, "text": page_text}) doc.close() return all_text

注意：use_angle_cls=True会做方向分类，能纠正倒置的文字，但会稍微拖慢速度。如果文档方向都正常，可以关掉提速。

5.5 第四步：复杂页面交给多模态大模型

哪些页面算"复杂"？我的判断标准是：OCR 置信度低、检测到表格线条多、页面有公式或图表、双栏排版。把这些页面挑出来，渲染成图，送给多模态模型。

import base64 import fitz def page_to_base64(pdf_path, page_num, dpi=200): doc = fitz.open(pdf_path) page = doc[page_num] mat = fitz.Matrix(dpi / 72, dpi / 72) pix = page.get_pixmap(matrix=mat) img_bytes = pix.tobytes("png") doc.close() return base64.b64encode(img_bytes).decode("utf-8") # 调用多模态模型（伪代码，按你用的 SDK 替换） def parse_with_multimodal(pdf_path, page_num): img_b64 = page_to_base64(pdf_path, page_num) prompt = """请把这页文档转成结构化的 Markdown，要求： 1. 保持正确的阅读顺序，双栏按左栏后右栏 2. 表格转成 Markdown 表格 3. 公式转成 LaTeX 4. 图片用 [图片: 描述] 标注 5. 不要添加原文没有的内容""" # response = multimodal_client.chat(image=img_b64, prompt=prompt) # return response return "模型返回的 Markdown"

这里 prompt 的最后一句"不要添加原文没有的内容"非常重要，能显著降低幻觉。我还会在 prompt 里要求它对不确定的内容标注[不确定]，方便后续人工复核。

5.6 第五步：结构化重组与切块

各路结果拿到后，要统一成一致的 chunk 格式。我的 chunk 结构长这样：

chunk = { "content": "正文内容", "source": "文件名.pdf", "page": 12, "section": "第三章 财务分析", "type": "text", # text / table / image_desc "parser": "paddleocr" # 记录来源，方便排查 }

切块策略上，我一般按语义边界切，而不是固定字数。标题作为分隔符，段落作为基本单位，表格单独成块。chunk 大小控制在 300 到 800 字之间，太大检索不准，太小语义不全。

5.7 参数选择背后的计算逻辑

几个关键参数我是这么定的：

• 渲染 DPI：300 是 OCR 的甜点。公式是DPI = 72 * 缩放倍数，300 DPI 对应约 4.17 倍缩放。低于 200 识别率明显下降，高于 400 收益递减还费时间。
• chunk 大小：假设 embedding 模型上下文 512 token，中文约 1 字 1.5 token，那 800 字约 1200 token 会超。所以我实际控制在 500 字左右，留出余量。
• overlap：相邻 chunk 重叠 50 到 100 字，防止边界信息丢失。

这些数字不是拍脑袋，都是根据模型能力和实测效果反推的。

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

6.1 问题速查表

6.2 几个我踩过的坑

坑一：以为所有 PDF 都有文本层。早期我直接用 pdfplumber 批量跑，结果扫描件全返回空，还以为是库的问题。后来加了格式探测才解决。教训是：永远先探测再处理。

坑二：OCR 语言参数没设对。有次处理中英混排文档，只设了lang="ch"，英文识别率暴跌。PaddleOCR 支持lang="ch"时其实也带英文，但混排复杂时最好用支持多语言的配置，或者分区域处理。

坑三：多模态模型把表格读错。一份财务报表，模型把"1,234,567"读成"1,234,567"没问题，但把某行的负号漏了，导致金额正负颠倒。这种错误在 RAG 里是灾难性的。后来我加了规则：所有数字类内容，用 OCR 结果和多模态结果交叉验证，不一致的标记出来人工看。

坑四：chunk 切太碎。一开始我按 200 字切，结果检索出来的都是半句话，模型没法答。后来改成按段落切，配合标题层级，效果好很多。

6.3 独家避坑技巧

• 先小样本验证再批量：拿 10 份文档跑通全流程，人工检查质量，再上批量。别一上来就处理几千份，错了重来成本太高。
• 保留中间产物：渲染的图片、OCR 的原始结果都存下来。后面发现解析错了，不用重新跑一遍。
• 记录 parser 来源：每个 chunk 标注是哪个工具解析的。出问题时能快速定位是哪个环节的锅。
• 数字和专有名词双重校验：这是 RAG 里最不能出错的部分，值得多花一道工序。
• 定期抽检：上线后每周抽 20 个 chunk 人工核对，防止模型或数据漂移。

6.4 关于成本和吞吐的现实考量

如果文档量在几百份以内，多模态模型随便用，成本可忽略。上千份就要算账了：假设一页多模态解析成本 0.01 到 0.05 元，一万页就是 100 到 500 元，还能接受；十万页就是几千到几万，这时候就得上分级策略，把大部分页面用便宜的 OCR 处理，只把硬骨头给多模态。

吞吐上，本地 PaddleOCR 单机大概每秒 1 到 3 页（取决于 DPI 和 CPU），多模态 API 受并发限制。批量处理建议用队列 + 多进程，别串行跑。

7. 关于解析这件事，我最后想说的

做 RAG 这两年，我越来越觉得解析是整个系统里最"脏"也最"值钱"的活。脏是因为它没有标准答案，每批数据都有新花样；值钱是因为它直接决定了下游的天花板。模型再强，检索再准，喂进去的是垃圾，出来的还是垃圾。

我的个人体会是：别追求一步到位的完美方案，先跑通再优化。先用最简单的组合（PyMuPDF 探测 + pdfplumber 提文本 + PaddleOCR 兜底）把流程跑起来，看看实际效果，再针对具体问题升级。多模态大模型是好东西，但它是"手术刀"不是"大砍刀"，用在对的地方才值。

最后分享一个小技巧：建一个"疑难杂症"文件夹，把每次解析出问题的文档存进去。攒到一定量，你会发现自己的文档其实就那么几类问题，针对性写几个处理规则，比盲目换工具有效得多。这个文件夹也是你后续优化最好的测试集。