5 种 PDF 解析工具做财报 RAG 的对比报告

同一份腾讯 2025 年中报，119 页，我拿五个工具各跑了一遍。最快的 pdftotext -layout，0.5 秒跑完全文；最慢的 MinerU，3 到 5 分钟。慢出来的几百倍时间买回来的是什么、什么时候值得买，是这篇要回答的问题。【待核实：全文耗时均为旧成稿基准数字（统一口径：M1 Pro 32GB + 119 页腾讯中报），发布前以同环境重跑记录为准】

先交代口径：这不是跑 benchmark，是我处理这份中报时的工程记录，每个结论背后都有真实出错案例。前提也限死：单一一份文件，港股格式、繁体横排、文本型 PDF，结论不能平移到所有财报——哪些场景我手里根本没数据，正文里会老实标出来。

先给尺子：七个评估场景

问“哪个工具好“不成立，成立的只有“哪个工具在哪个场景好“。所以评测之前先定义场景。我用七个，每个在财报里都有真实长相：

多栏布局。 “公司資料“页那种左右两栏、栏高还不齐的页面。抽取时按物理位置读，低栏见底之后，高栏底部的文字就和低栏文字交错进同一段文本流。

竖向合并单元格。 利润表里“收入“这个大类合并了 5 行，下面挂着增值服务收入、网络广告收入等子项。

跨页表格。 一张利润表跨三页，表头只在第一页顶部，后两页只剩数据行和一个“（续）“。

扫描件。 整页是图片，没有文本层，靠读文本流的工具直接出局。【待补：五个工具均无扫描件实测，素材仅有一句“扫描版要换 PaddleOCR 或多模态模型“的提示】

图文混排。 多层嵌套表格、图片、注释挤在同一页。【待补：仅 MinerU 有一句定性描述，缺逐工具实测数据】

大文件性能。 百页以上文件的耗时和资源消耗。【待补：现有耗时均来自 119 页单一文件，若按“大文件“定义需补更大体量样本】

中文竖排。 竖排繁体，阅读顺序从上到下、从右到左，和横排是两套坐标逻辑。【待补：素材零覆盖——腾讯中报是繁体横排，需先准备竖排测试文件再补测】

这七个场景就是第三章那张矩阵的行。场景定义清楚，结论的一半就有了。

五个工具逐个过

每个工具回答三件事：吃什么场景，死在哪，出错长什么样。篇幅不均分，能说的多少不一样。

pdftotext -layout：用速度换覆盖率

pdftotext -layout '腾讯 -2025-中期报告.pdf' '腾讯 -2025-中期报告.raw.txt'

关键在 -layout：按页面物理布局保留对齐信息，单栏页面的 reading order 接近 100%，119 页 0.5 秒跑完。全文文本抽取的首选。

软肋是多栏。左右栏高度不一致时，低栏文本会和高栏底部在文本流里交错——“公司資料“页抽出来就是这个效果，左右栏交叉拼接，语义彻底乱掉。按这份中报实测，多栏页面里大约两到三成的文本流出现明显栏间交错——页面级口径：分母是这份中报里的多栏页数，分子是抽出来顺序明显不可用的页数，不是字符级准确率。对表格，它只输出文本流、不识别结构：简单表格的文本顺序通常对，合并单元格和跨页表格经常乱。

pypdf：纯 Python 退路

全篇最短的一节，因为它能说的最少。不带 layout 模式，多栏页面文本顺序完全乱掉；数字和货币符号在高版本里有改进，但仍不可靠；中文支持尚可，可能丢部分标点。119 页约 1 秒。

定位一句话：环境里装不了命令行工具时，它是纯 Python 备选。装得了 poppler 就用不上它。（名字交代一句：PyPDF2 2022 年后停更，合并回 pypdf，新代码装 pypdf。）

pdfplumber：规则表格首选，和它的临界点

对完整边框的表格，page.extract_tables() 准确率很高，规则表格首选。但它的崩溃机制值得讲透，因为三类崩溃是同一个根因：它靠检测水平线和垂直线，反推单元格边界。

于是：竖向合并单元格，合并区域没有线，提取出来是空值或重复值；无边框表格，财报里大量靠对齐和空白暗示结构的“隐形表格“，线条检测引擎根本看不见；跨页表格，每页独立推断，不会自动拼接。

代价也在机制里：每页都要做一遍线条推理，119 页约 25 秒，比 pdftotext 慢约 50 倍。所以它在我这儿的角色很明确：不碰全文，只做规则表格的专项提取。文本抽取它也能做（extract_text(layout=True) 对单栏页面效果不错；多栏页面它和 pdftotext 一样会交错，矩阵里只给“一般“），但没有必要——0.5 秒能做完的事，不必花 25 秒。

MinerU：有 GPU 时的统一首选

MinerU 走另一条路：用版面分析模型直接“看“页面，不从绘图指令反推。多栏、竖向合并、跨页表格全面优于规则方案，输出直接是 Markdown 或 JSON，跨页表能自动识别合并。核心调用就几行：

from magic_pdf.data.data_reader_writer import FileBasedDataReader
from magic_pdf.data.dataset import PymuDocDataset
from magic_pdf.pipe.UNIPipe import UNIPipe
from magic_pdf.pipe.OCRPipe import OCRPipe

reader = FileBasedDataReader("")
pdf_bytes = reader.read("财报.pdf")
ds = PymuDocDataset(pdf_bytes)

# 文本型走 UNIPipe，扫描件走 OCRPipe
pipe = OCRPipe(ds, None) if ds.classify() == "ocr" else UNIPipe(ds, None)
pipe.pipe_classify()
pipe.pipe_analyze()
pipe.pipe_parse()

content = pipe.pipe_mk_markdown("images", drop_mode="none")

ds.classify() 先判断 PDF 类型：扫描件走 OCRPipe，文本型走 UNIPipe，版面分析藏在 pipe_analyze() 里；最后 pipe_mk_markdown() 输出结构化文本。（MinerU 1.x，即 magic-pdf 包；2.x 起 API 又改了几轮，2026 年 9 月时 mineru 包已到 4.x，照抄前对一遍你装的版本。）

边界给足：遇到极端排版——多层嵌套表格加图片加注释同页——它仍然出错，约 5–10% 的极端表格需要人工或多模态兜底。【待核实：旧成稿基准比例，发布前需交代统计方式（多少页里错几页）】依赖也重，要下载几 GB 模型权重；M1 Pro 32GB 上 119 页跑了 3–5 分钟，GPU 环境显著加速。

GPT-4o / Qwen-VL 截图方案：不是解析工具，是兜底

严格说这不是 PDF 解析工具。用法是把表格所在区域截图发给多模态模型，prompt 就一句：“把这个图片里的表格输出为 JSON，每行格式 {指标名, 数值}。“它不推断线条和单元格，直接“看“表格——对最复杂的竖向大表格和跨页表格，这是我手里效果最好的方案。

成本账必须算：一页表格的截图调用约 $0.01–0.05，119 页全量表格约 $1–5（多模态模型的定价几乎每月都在动，按你用时的价格重算）。Qwen-VL 本地部署能省掉 API 费，但要 GPU。它只做表格区域，不用于全文抽取——拿它抽全文，成本和延迟都不成立。

汇总矩阵与三档组合

七个场景乘五个工具，一张表查结论：

说明：扫描件、中文竖排两行整行待补；图文混排仅 MinerU 有一句定性记录；“大文件性能“行是 119 页单文件口径，更大体量样本待补。“待补”不是忘了填，是没数据——这篇的发布红线就是七场景实测数据补齐，不齐宁可不发。

基于矩阵，按预算分三档组合：

零成本纯 CPU 档： pdftotext 抽全文，pdfplumber 提取规则表格。复杂表格放弃自动化，留人工或后续补。

有 GPU 档： MinerU 统一处理全文和表格，pdfplumber 抽查校验规则表格。

追求上限档： MinerU 为主，多模态截图方案兜底最难的那 5–10%。

组合逻辑很直白：全文用最快的，规则表格用准的，最难的用最贵的。反过来用，就是我踩过的两个坑——拿 MinerU 做全文是过度工程，0.5 秒的事没必要花 5 分钟；拿 pdftotext 做表格是灾难，抽出来数字和指标名分家，下游全错。【待核实：三档分档系按素材成本信息（GPU 需求、速度、API 费）的推导，发布前用重跑数据校准】

会过时的和不会过时的

以上结论全部绑定具体版本：poppler-utils 24.08、pypdf 4.x（PyPDF2 已停更并入）、pdfplumber 0.11、MinerU 1.x（magic-pdf 的 pipe API）、GPT-4o（2025-06 时点）。半年后这张矩阵的格子可能要重填——MinerU 在迭代（本文实测用 1.x，2026 年 9 月时已到 4.x），多模态模型的性价比每个月都在变。再强调一次开篇的前提：结论来自一份港股文本型 PDF，不是“所有财报“的普遍规律。

不会过时的是第一章那把尺子。工具会换，场景不会：多栏还在，合并单元格还在，跨页表还在。拿这七个场景去量你手里的新工具，比抄我的结论可靠。

第 2 篇讲 PDF 解析和 reading order 时展开过多栏页面的清洗，第 3 篇讲竖向大表格和跨页表格时给了工程解法；那一篇第 5 节说“详细实测数据留给番外 A1“，这篇就是兑现。没有完美的工具，只有场景匹配的组合。