前几天一个做 IT 的朋友来找我，说他们解析 PDF 跨页表格的时候卡住了。他们第一反应是上 OCR，结果效果稀烂，问我有没有更好的路子。

我做了一轮调研给他，这里把结果脱敏后分享出来。

OCR 识别的坑

朋友团队一上来选 OCR，这不怪他们，挺自然的一个误判——PDF 解析嘛，先把字认出来不就行了？

但跨页表格的难点根本不在「认字」，在结构。它要解决的是两件事：跨页的表格要不要拼成一张，跨页被切断的单元格要不要接回去。

OCR 干的活是把图像里的像素认成字符，它无法判断两页上的表格是不是属于同一个表格。所以你会看到我下面的评测里，纯 OCR 在所有数据上全军覆没——不是字认得不准，是它根本不管这事。

评测集构建

很多人测工具，随手抓几个 PDF 跑一下就下结论。问题是 PDF 跨页表格压根不是一个场景，是一堆场景，不同情况下工具的表现能差出十万八千里。你评测集要是没覆盖到客户的真实场景，结论一上线就翻车。

我按两个维度来拆。

第一个是 PDF 从哪来——原始 PDF，还是扫描件 PDF。这俩对工具来说难度完全不是一回事：原始 PDF 自带文本层，扫描件就是张图，得先过一遍识别。

第二个是有没有干扰——页眉页脚、印章这些。这些玩意儿在真实的业务文档里基本跑不掉，尤其 B 端，合同也好报告也好图纸也好，哪个上面没盖章没页脚？而它们恰恰最容易把工具搞晕，让它认错表格的边界。

这么一组合，我搭了 5 个评测数据：

1. 1. 原始 PDF，无页脚
2. 2. 原始 PDF，含页脚
3. 3. 扫描件 PDF，无页脚
4. 4. 扫描件 PDF，含页脚
5. 5. 扫描件 PDF，含印章

三类方案

第一类，文档解析工具（MinerU、PaddleOCR-VL-1.6）。这类是专门干「看懂文档结构」的，照理说最对口。

第二类，OCR（PP-OCRv6），纯当对照组。我基本料定它会挂。

第三类，多模态大模型（Qwen、DeepSeek、Claude）。它把「看图」和「理解」揉到一块了，值得验一验。

还有一类专门啃原始 PDF 的 Python 库（pdfplumber 那种），我没放进来。一是它们单独处理扫描件还不太行，二是扫描件恰恰是 B 端的主流形态。

评测结果

文档解析工具

MinerU原始 PDF 和扫描件，不管带不带页脚，都能合并跨页表格、合并跨页单元格。唯一翻车的就是含印章的扫描件——合并失败了。

PaddleOCR-VL-1.65 个数据都能合并跨页表格，但跨页的单元格合不上。也就是说大的表格层面对了，更细的单元格还差一点意思。

OCR（对照组）

PP-OCRv65 个数据全挂。单元格没合，表格也没整。跟我预判的一样，它就不解决结构这事。

多模态大模型

每个大模型的提示词都只有一句话：识别文件中的表格并输出。

Qwen3.7大部分场景能合并跨页表格，但有个稳定复现的毛病——合并完的单元格里缺了「往返」俩字。含页脚的原始 PDF 和扫描件还会把表格切成两块。

DeepSeek 识图原始 PDF 能合并（一样缺「往返」俩字）；可一到扫描件，第二页的表格直接识别不出来，跨页合并更无从谈起。

Claude Opus 4.8原始 PDF 和含页脚的扫描件，能合并表格、能合并单元格、内容还完整。最狠的是含印章那个评测数据——它直接自动生成了 Excel，跨页表格和单元格全合对了。

一句话：Claude 最好，MinerU 第二，OCR 垫底。大模型里面 Claude 明显甩开一截，Qwen 和 DeepSeek 不光效果差，还不稳定。

B 端落地选哪个

评测分高，跟适合落地，完全是两码事。落地得同时看效果、成本、稳不稳、合不合规。

大模型

效果天花板最高，但有三道坎。

一是效果两极分化。只有头部的（Claude）效果稳，Qwen、DeepSeek 这种会缺字、会漏页，你根本没法跟客户拍胸脯说能到多少准确率。

二是有 token 费用，文档量一上来，这是笔按量算的持续开销，得算进账里。

三是数据出域——你调公有云大模型的 API，等于把客户文档发出去了，B 端客户尤其是涉密的、金融的、政企的，大概率不答应。这一条经常直接把方案毙了，跟你效果好不好半毛钱关系没有。

OCR

这个场景直接出局。

文档解析工具

效果还没到满分，但落地的性价比最高。每天有免费额度，成本扛得住；私有化部署成本低，数据不出域——这一点在 B 端经常比「效果高那么几个点」还管用。代价是当前效果还没好到能直接交付，含有印章的场景会失败，得补点后处理。

所以碰上这类技术选型，先问约束，再看效果。约束——数据能不能出域、成本上限多少、对稳定性要求多高——先圈定了你能选的范围，效果只是在这个范围里排个序。