前情提要

做这个对比分析，是为了更好地学习RAG文档解析环节。
之前盲目地相信AI coding，没了解PDF解析原理，在批量解析PDF构建向量数据库后，通过检索发现并没有得到有效解析。用的工具是MinerU，进行版面分析，后退策略（若是MinerU不可用，现在看来根本没必要）使用PyMuPDF，在解析过程中一直反馈依赖安装问题，也就是magic-pdf一直报错（不存在，即使我已经安装了，但是因为版本原因读取不到），所以全程使用的PyMuPDF。
所以痛定思痛，打算认真学习一下PDF的解析工具。了解到，最常用的就是MinerU、PyMuPDF以及unstructured（当然这是针对版面分析的），所以对于这三种工具，我需要了解其工作原理以及处理方式。
我打算对比五种工具：

① PyMuPDF（使用find_tables函数识别表格）
② PyMuPDF（与①不同的是，使用get_drawings识别所有图片/图形（包括表格），这里是因为曾看到一个博主指出的观点，find_tables函数固然是PyMuPDF中标准的表格识别函数的选择（通过水平线和垂直线的密集区域来识别表格），特别是标准的表格，但是不同类型的PDF的表格差别很大，许多表格并不符合标准。）
③ Docling
④ MinerU + Camelot（MinerU用于版面检测，Camelot用于表格检测）
⑤ Unstructured（只做版面分析）

先明确几个概念：
①OCR（Optical Character Recognition）
专门识别图片里的文字，例如 PaddleOCR、Tesseract、EasyOCR
输入：图片（通常是表格截图、段落截图）
输出：文字内容 + 可选坐标信息（每个字符/单词的 bbox）
②视觉模型（多模态模型）
更通用，既可以识别文字（OCR功能），也可以做图像理解（描述图片、推理关系等）
如果你的视觉模型能做到“看一张表格图 → 输出文字 + 表格结构”，那它就是一个增强版 OCR
GPT-4o、Qwen-VL、Yi-VL、InternLM-XComposer 都可以充当 OCR

值得一讲的是，MinerU 本质上是阿里巴巴开源的多模态文档理解工具链，主要功能是：PDF/图片版面分析（Layout Analysis）、表格检测与结构化、OCR 文本提取。

① PDF/图片版面分析（Layout Analysis）
目的：找到文档页面上不同类型的内容块及其位置（坐标）
输入：PDF 页面（或渲染后的图片）
输出：一组矩形区域（bounding boxes）+ 每个区域的类别（表格、段落、标题、图片等）
它的布局分析部分底层用的就是 docling（DoclingLayout），docling 是阿里基于 detectron2 / layoutparser 等做的文档版面检测模型。
例如：
[
{“type”: “table”, “bbox”: [x0, y0, x1, y1]},
{“type”: “text”, “bbox”: [x0, y0, x1, y1]},
{“type”: “figure”,“bbox”: [x0, y0, x1, y1]}
]
② 表格检测与结构化
目的：找到表格位置，并将其转为机器可读的表格结构（行列）
输入：可能是 PDF 页面的表格区域（图片或 PDF 矢量数据）
输出：表格的边框线和单元格坐标、表格结构化后的数据（CSV、HTML、Markdown）
步骤：
表格检测 （找到整张表格的外边框（bbox））—> 表格结构化 （识别表格里的行列、合并单元格关系
、需要知道每个单元格的文字（依赖 OCR 或 PDF 矢量文字提取））
特点：
检测表格位置 ≠ 得到表格内容
如果是扫描 PDF，必须 OCR 才能填充内容
③ OCR 文本提取
目的：将图片中的文字变成可编辑的文本
输入：图片（表格截图、段落截图、整页）
输出：字符串 + 可选的坐标信息
例如：
[
{“text”: “营业收入”, “bbox”: [x0, y0, x1, y1]},
{“text”: “100,000”, “bbox”: [x0, y0, x1, y1]}
]
特点：
只解决“图变字”，不负责判断文字属于哪一块区域（那是版面分析的任务）
对于矢量 PDF（文字是直接存储的），可以跳过 OCR

我觉得可以这样理解：

版面分析：告诉你“哪里有一张表格”
表格检测与结构化：告诉你“这张表格有几行几列，每格内容是什么”
OCR：告诉你“这张格子里写的字是什么”

5个工具的版面识别特征：

编号	工具 & 方法	主要思路	提取对象	预期优势	预期劣势
①	PyMuPDF + find_tables()	规则法（检测表格线条、单元格边界）	表格	对清晰规则表格识别快，坐标精确	无法处理扫描件或无线条表格
②	PyMuPDF + get_drawings()	规则法（矢量图形提取）	图片/图形/形状	可提取所有矢量绘图、logo、图表框架	无法直接获取文字，且位图图片检测有限
③	Docling	深度学习布局检测模型（detectron2）	段落、表格、图片、公式等	对扫描件、非规则布局鲁棒，分类细粒度	推理速度慢，需GPU，表格结构化需OCR
④	MinerU	Docling布局检测	全类型版面	表格检测更准，结构保留好	表格提取依赖 PDF 矢量，扫描件无效
⑤	Unstructured	规则+模型混合（pdfplumber + layoutparser）	块级段落、图片、表格	对长文档切分自然，去页眉页脚能力好	坐标精度不一定稳定，表格提取不强

为什么 Docling 表格结构化需要 OCR？

Docling 的表格检测是版面分析模型（Detectron2 / LayoutParser 训练的对象检测模型），它只给出表格的 bounding box，并不直接产出单元格里的文字。
真正的单元格文字获取，Docling 会把表格区域裁剪成图片，然后送进 OCR（比如 PaddleOCR / EasyOCR / Tesseract），最后再用表格结构化模型重建表格。
所以如果是扫描 PDF 或表格是图片，必须 OCR 才有内容；如果是矢量 PDF，可以直接从 PDF 提取文字，跳过 OCR，这样显存占用会小很多。

如果想要在 Docling 里替换成自己的视觉模型，首先要知道docling的流程（表格部分）：

PDF → 渲染成图片 → 检测表格 bbox（Docling） → 裁剪表格图 → OCR（默认PaddleOCR） → 表格结构化（合并行列、输出CSV/HTML）

那么，替换成自己选择的视觉模型后，流程为：

PDF → 渲染成图片 → 检测表格 bbox（Docling） → 裁剪表格图 → 送入视觉模型 → 直接返回文字 / 或文字+结构 → 再结构化输出

值得注意的是：

①成本与速度
视觉大模型 API 成本可能比 PaddleOCR 高
大模型推理速度可能比本地 OCR 慢（尤其是大 PDF）
②坐标精度
默认 OCR 可以返回每个单词的坐标，方便对齐
有些视觉模型只输出纯文本，没有坐标 → 这会影响精确结构化
③批处理能力
如果你要跑几百个表格图块，要确认 API 限制（并发 / 速率）

OCR与表格结构化的顺序不是固定的
①流程 A — 结构优先（先结构化再 OCR）
步骤（针对单页或表格区域）：

版面分析 → 得到表格的 bbox（Docling / layout model）
对表格区域做表格结构识别（检测表格线、单元格格线或用 TSR 模型得到 cell bbox）
对每个 cell 做 OCR（或从矢量 PDF 直接提取该 cell 的文字）
把 OCR 结果填入对应 cell 输出表格（CSV/HTML）

优点：

cell 边界清晰时，能精确把文字放到正确单元格，结构还原度高。
OCR 可按 cell 并行或按需执行（节省后续对齐工作）。

缺点：

依赖可靠的 cell 检测（线条弱、跨列合并复杂时容易失败）。
对无格线或复杂布局的图像表格效果差。

适用场景：带明显表格线的矢量 PDF 或高质量扫描件；需要高精度单元格还原时首选。

②流程 B — 先 OCR（全文 OCR）再做结构重建
步骤：

对整页（或整张表格图）做 OCR → 得到词/行的文本 + 每个词的 bbox
版面分析得到表格 bbox（可选）
用空间聚类 / 行检测 / 排列规则把 OCR 出的词按行/列分组，推断单元格边界与合并关系 → 输出表格结构

优点：

对无格线的表格（仅靠排版和空白区分列）更稳健。
只需一次 OCR（整页），实现上更简单（少量图像裁剪/IO）。

缺点：

依赖 OCR 返回准确的坐标信息；若 OCR 坐标精度差或文字识别错误，结构重建会受影响。
列对齐/跨列单元格的自动识别需复杂规则或后处理。

适用场景：无或弱格线的表格、OCR 能返回精确位置时（或矢量 PDF 可直接提取文字坐标）。

③混合/折中方案
先检测表格 bbox + 全表 OCR + 将 OCR 词映射到检测到的 cell/网格：结合 A 和 B 的优点，常用于实际工程里。

总结来说就是：

有格线：结构优先（detect cells → OCR per cell） 通常更准。
无格线：OCR-first（整表 OCR → 通过位置聚类重建结构） 通常更稳。

以下为我学习时的疑问以及ChatGPT的回答：

MinerU也是先将PDF转换成图片的形式吗？
unstructured使用的是langchain框架吗？
unstructured为什么要使用PyMuPDF呢？PyMuPDF的作用是什么？PyMuPDF在MinerU中也起作用了吗？
PyMuPDF单独可以对PDF进行版面分析吗？PyMuPDF也是输出划分的坐标吗？PyMuPDF也是通过模型来划分版面的吗？

1. MinerU 是否也先把 PDF 转成图片再做检测？流程是否相同？
   • 是的，MinerU 的高精度版面检测流程与 Unstructured 的 “hi_res” 策略非常类似：先把每页 PDF 渲染(通常用 PyMuPDF 或 pdf2image 等库)成高分辨率 PNG，再将图片送入目标检测模型(如 YOLOv5/YOLO-X 派生模型)识别文字块、表格、图片等区域，最后再回写到 PDF/JSON 中。
   • 区别主要在于 MinerU 自带了针对中文财报/研报训练的专用模型和一整套后处理规则，而 Unstructured 默认用开源的 yolo_x_layout 模型，并把后处理逻辑暴露给用户自定义。
2. Unstructured 是否基于 LangChain？
   • Unstructured 本身并不依赖 LangChain，也不是 LangChain 的一部分；它是独立的文档解析与版面分析库。
   • LangChain 里有一个 UnstructuredFileLoader／UnstructuredPDFLoader，只是把 Unstructured 的解析结果封装成 LangChain 的 Document 对象，方便后续走 LLM Chain。这属于“可选集成关系”，不是强制依赖。
3. 为什么还要用 PyMuPDF？PyMuPDF 的作用是什么？
   • PyMuPDF(Fitz) 是一个高性能 PDF 渲染与解析库，它能：
   a) 把 PDF 页面渲染成位图(我们用它生成背景 PNG 方便画框)。
   b) 读取页面尺寸、坐标系并把检测到的 bbox 精准转换回 PDF 坐标。
   c) 直接在 PDF 上画矢量矩形并重新保存(如需导出带框 PDF 时用)。
   • PyMuPDF 负责渲染背景、计算坐标、最终保存结果 PNG。
   • 在 MinerU 的底层管线里，也常见到 PyMuPDF(或 MuPDF 的 C 绑定)用于同样的页渲染与坐标换算，因此它也“起作用”。
4. PyMuPDF 能否单独完成版面分析？会输出坐标吗？需要模型吗？
   • PyMuPDF 自身不做机器学习意义上的“版面分析”，也不会给出文本块/表格的检测结果；它提供的只是：
   – 页面对象树(文字行、字符、图像流等)
   – 渲染 API
   • 你可以通过 PyMuPDF 的文字提取接口拿到每个字符/行的 bbox，但这属于简单的“文字分组”，远不如目标检测模型的分区效果。
   • 所以如果仅靠 PyMuPDF，不需要模型，但分区结果有限；若要获得类似 MinerU/Unstructured 的高质量分区，仍需外部目标检测模型。
5. PyMuPDF 会输出划分坐标吗？是否通过模型？
   • 若你调用 PyMuPDF 的 page.get_text("dict") 会返回文字块、行、字的 bbox；这些坐标来自 PDF 内嵌文字流本身，不需要任何模型。
   • 但 PDF 中的表格边框、图片区域、标题区块等结构并不总能通过文字流直接推导。所以 PyMuPDF 提供的坐标只覆盖“文字元素”，无法完整替代基于模型的版面分析。

总结对比

功能	MinerU	Unstructured (hi_res)	PyMuPDF
是否渲染为图片	是	是	可渲染
是否依赖检测模型	是(内置)	是(YOLO-X Layout)	否
输出 bbox 范围	有	有	仅文字
是否可独立视觉化	支持(命令行)	需自行画框(PIL/PyMuPDF)	可画框

MinerU的解析

MinerU依赖的安装

MinerU的依赖安装比较复杂，这里单独提出来说一下。
首先要确认软硬件设施是否符合，以及根据自己的需求来选择。

以防万一，安装全程参考的是 一位up主的安装方法。
安装方法中，有pip也有uv，这里简短介绍一下不同依赖安装工具（ChatGPT生成）：

工具	作用	安装来源	特点
conda install	Conda 的包管理	Conda 镜像（如 Anaconda Cloud、conda-forge）	包含预编译的 C/C++/CUDA 依赖，安装快且稳定
pip install	Python 官方包管理	PyPI	纯 Python 包多，生态最大，但需要编译 C 扩展时容易踩坑
uv pip install	uv 工具的 pip 接口	PyPI	速度极快（Rust 实现的 resolver），可替代 pip

uv 是近年新出的超快 Python 安装器，能替代 pip/pip-tools，速度比 pip 快 10~100 倍。
很多项目开始在安装指令中同时给出：
uv pip install -r requirements.txt
这样用户在任意 Python 环境（包括 conda）都能快速装包。

先升级pip是为了防止安装依赖的时候发生版本冲突。然而尽管如此，我在安装的时候依旧遇到了版本冲突，依然是magic-pdf和其他依赖的版本冲突，这里我的解决方法是首先卸载和magic-pdf发生冲突的依赖，然后安装符合的版本。

使用MinerU进行版面识别和Markdown的转换

安装成功后，可以通过以下命令行来进行解析：

mineru -p <input_path> -o <output_path>

我使用的PDF来源于科大讯飞和Datawhale联合创办的多模态RAG图文问答挑战赛，当然，也可以通过魔搭下载。
运行结束后，会生成对应PDF的输出文件夹，其中有MinerU对该PDF的版面识别以及转换成的Markdown文件。

可以看见，MinerU的版面分析能力很强，可以轻松识别文本、图片以及表格位置，并进行划分，接着将PDF转换成Markdown。

docling的解析

docling整体提取还不错，不过这里明显有点问题的就是图片提取得过于详细了（每一个logo都被提取出来了），以及目录被识别成了表格。

unstructured的解析

unstructured一般用于文本类的解析，这里为了方便比较，我同样将其可视化：




可以发现，unstructured尽可能的提取PDF中的文本信息，对于结构处理得比较好，但是对于表格和图片就不太行了。

PyMuPDF（使用get_drawings函数）的解析

PyMuPDF工具可以提取文字内容以及图片，但是图片提取效果并不是很好。感觉章节结构提取效果不如unstructured，图片表格提取效果不如MinerU。当然，并不能说PyMuPDF工具就不行，其解析速度非常快，个人觉得非常适合简单PDF的解析。

PyMuPDF（使用find_tables和get_drawings函数）的解析

不难看出，find_tables函数并没有什么实际的作用，对于这种非常规结构表格。

再进一步（解析markdown中的图片和表格）

上述的几个工具最后生成的Markdown文件只是文本+表格+图片，也就是说，原PDF中的表格和图片信息还未提取。秉承能免费就不花钱的原则，这里使用的是智谱AI的视觉模型glm-4.1v-thinking-flash来进行图片的信息提取，使用文本模型glm-4.5-flash模型来对表格内容进行总结。

从 MinerU 的输出目录中读取 Markdown 文件及其伴生的 JSON 元数据，按顺序提取文本、图片和表格元素：

• 文本直接保留。
• 图片使用视觉模型生成描述。
• 表格使用文本模型生成总结。

最终生成纯文本 Markdown 文件，保留页码信息。

图片/表格处理失败

在运行过程中，发现有图片、表格无法处理（处理失败）的提示：


首先排除了API调用问题或者网络问题，这里给出的提示是“输入或生成内容可能包含不安全或敏感内容”，可是看图片并没有发现什么敏感词（敏感内容）。为了深入了解什么是大模型输入与输出的敏感内容，我首先查看了其他处理失败的图片与表格：

确实也不知道为什么，去问了ChatGPT，这是它的回答：

我看了你这三张图，LLM 之所以会反馈“含敏感内容”，主要有两个原因：

1. 第三张图涉及公司股权与自然人姓名信息
   第三张图是一个公司股权结构图，里面包含自然人姓名（如“蔡为民”“陈文佳”等）和公司持股比例，这些都属于可能识别真实个人身份的信息（PII）。
   大多数 LLM 的内容安全机制会对“个人身份信息”和“公司股东信息”触发敏感检测，因为它们有可能与隐私或商业机密相关。
2. 涉及企业控股结构、境外子公司信息
   图中还列出了境外分支机构（如美国、香港、加拿大、欧洲等地的消防设备公司），以及持股比例（92.14%、56%等）。
   这种跨国控股关系+公司名，模型可能会将其判定为企业敏感信息（尤其是在涉及投资、收购、股权变更等情境下）。
3. 前两张图本身没有明显敏感信息
   第一、第二张图只是各国乳制品消费量的对比，不涉及隐私或公司机密。
   但如果你是一次性把三张图一起发给 LLM，它可能会因为其中一张（股权结构图）触发了规则，导致整组分析都被拦截。