PDF转Markdown工具实测：表格公式识别与Gemini跑分对比
1. 为什么我又折腾起了 PDF 转 Markdown 这件事
做技术内容这行十几年，跟 PDF 打交道的时间可能比跟家人吃饭的时间还长。厂商白皮书、论文、技术手册、合同、扫描件，几乎每天都有那么几份 PDF 需要把里面的内容抠出来复用。早些年我的做法很原始：Adobe 打开、复制、粘贴到编辑器里，然后手动收拾格式。表格错位、公式变图片、段落全糊成一坨，一篇二十页的文档整理下来，半天就没了。
后来陆续用过不少工具，有在线的、有命令行的、有商业软件的，各有各的毛病。在线的担心文档隐私，命令行的对复杂版式支持一般，商业的要么贵要么重。直到最近刷到一个开源项目，标题大意是“PDF 丢进去，干净 Markdown 出来，表格公式一个不少，跑分贴着 Gemini”，我第一反应是：又是一个标题党。但架不住好奇，clone 下来跑了一遍，结果确实有点东西。
这篇就聊聊这类 PDF 转 Markdown 工具到底是怎么工作的、为什么表格和公式是最难啃的骨头、跑分“贴着 Gemini”意味着什么、以及我自己在实测中踩过的坑和总结出来的用法。不管你是做知识库、做 RAG 检索、做文档归档，还是单纯想把一堆 PDF 变成能编辑的 Markdown，这篇应该都能给你一些能直接抄的作业。
先说清楚适用人群：如果你只是偶尔转一两页纯文字 PDF，随便找个在线工具就够了；但如果你要批量处理带表格、带公式、带多栏排版的技术文档，或者要把 PDF 喂给下游的大模型做检索，那这类工具值得你花时间研究。下面进入正题。
2. 这类工具到底在解决什么问题：PDF 与 Markdown 的鸿沟
2.1 PDF 是“打印格式”，Markdown 是“结构格式”
很多人没意识到，PDF 从设计之初就不是为了“编辑”和“结构化”而生的。它的全称是 Portable Document Format，核心目标是在任何设备上呈现完全一致的视觉效果。换句话说，PDF 里存的更多是“这个字画在坐标 (x, y)，用这个字体、这个字号”，而不是“这是一个二级标题，下面跟着一个三行两列的表格”。
Markdown 恰恰相反，它几乎不关心视觉，只关心结构：这是标题、这是列表、这是表格、这是代码块。所以 PDF 转 Markdown 的本质，是一次从“视觉坐标”到“语义结构”的重建。这个重建过程，就是所有难点和跑分差异的来源。
你可以把 PDF 想象成一张已经烤好的蛋糕照片，Markdown 是蛋糕的配方。工具要做的事情，是看着照片反推出配方——面粉多少、糖多少、几层、怎么裱花。纯文字段落还好说，遇到表格和公式，就相当于照片里有个复杂的多层裱花，反推难度直接上一个数量级。
2.2 为什么表格和公式是“地狱难度”
先说表格。PDF 里的表格通常不是以“表格对象”存在的，而是若干条横线、竖线加上一堆散落的文字。工具需要先检测出这些线条，推断出网格结构，再把每个文字块分配到正确的单元格里。麻烦在于：
- 有些表格没有边框线，靠的是对齐和留白，检测难度陡增；
- 单元格里可能换行、可能有合并单元格、可能嵌套小表格；
- 跨页表格要拼接，表头要识别并重复。
再说公式。公式在 PDF 里往往是图片或者一堆特殊字体的字符拼出来的。如果是图片，就得靠 OCR 加公式识别模型；如果是字符拼的，字体映射经常是乱的，一个积分符号可能被编码成某个奇怪的 Unicode。识别出来之后还要转成 LaTeX 或 MathML，才能被 Markdown 生态正常渲染。这就是为什么很多工具转出来的公式变成了一串乱码或者干脆丢失。
提示：判断一个 PDF 转 Markdown 工具好不好，最快的办法就是拿一份带复杂表格和数学公式的论文去测，纯文字文档测不出真实水平。
2.3 “跑分贴着 Gemini”到底在说什么
标题里提到“跑分贴着 Gemini”，这里的跑分通常指的是文档解析领域的基准测试，比如比较常见的 OmniDocBench 这类评测集，里面包含大量带表格、公式、多栏排版的真实文档，用编辑距离等指标衡量转换质量。Gemini 系列模型在文档理解上一直表现很强，所以“贴着 Gemini”意思是这个开源项目在评测分数上已经非常接近顶级闭源模型，但它是开源的、可以本地跑的。
这个意义其实挺大。闭源模型 API 按页收费，文档一多成本就上来了，而且文档要上传到别人的服务器，隐私敏感场景根本没法用。开源项目能跑到接近的水平，意味着你可以把它部署在自己的机器上，批量处理、离线处理、免费处理。对做知识库和 RAG 的人来说，这是实打实的成本下降。
3. 核心原理拆解：一份 PDF 是怎么变成干净 Markdown 的
3.1 整体流水线：从像素到语义的四步走
这类工具的内部流程，拆开看大致是四个阶段，我按自己的理解画个文字版流程：
- 版面分析（Layout Analysis）：先看整页，判断哪里是正文、哪里是标题、哪里是表格、哪里是图片、哪里是页眉页脚。这一步决定了后续所有处理的分区。
- 元素识别（Element Recognition）：对每个区域分别处理。正文走文字识别，表格走表格结构识别，公式走公式识别，图片直接裁剪保留。
- 结构重建（Structure Reconstruction）：把识别出来的元素按阅读顺序串起来，还原标题层级、列表、段落、表格的行列关系。
- 格式输出（Serialization）：转成标准 Markdown 语法，表格用管道语法，公式用 LaTeX 包裹，图片用相对路径引用。
这四步里，第一步和第二步是质量的分水岭。版面分析错了，后面全错；表格和公式识别不准，输出就是垃圾进垃圾出。
3.2 版面分析：模型怎么“看懂”一页纸
版面分析现在主流做法是用视觉模型，把 PDF 页面渲染成图片，然后用类似目标检测的思路框出各个区域。早期的做法靠规则：字体大小、行间距、坐标位置。规则法对规整文档还行，遇到多栏、图文混排、扫描件就歇菜。
视觉模型的好处是泛化能力强，但它也有代价：需要 GPU、推理慢、对扫描件质量敏感。所以很多工具会做混合策略——先用规则快速判断，规则拿不准的再交给模型。这个取舍很关键，纯模型方案质量高但重，纯规则方案轻但脆，实际项目里往往是两者结合。
3.3 表格识别：从线条到单元格的三条路线
表格识别这块，我实测下来主要有三条技术路线：
| 路线 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| 基于线条 | 检测横竖线，求交点构建网格 | 对有边框表格极准 | 无边框表格直接失效 |
| 基于文本对齐 | 靠文字块的坐标聚类推断列 | 无边框也能处理 | 列间距不均时容易错 |
| 端到端模型 | 直接输出表格的 HTML/LaTeX | 复杂表格表现好 | 需要训练数据，推理重 |
实际好用的工具通常是“线条 + 对齐”混合，再叠加一个模型兜底。这也是为什么标题敢说“表格一个不少”——它大概率在这块下了功夫。
3.4 公式识别：图片和乱码两条路都要走
公式处理分两种情况。如果公式在 PDF 里是图片，那就走图像到 LaTeX 的识别模型，这类模型现在开源的有不少，效果也还行。如果公式是字符拼的，就要处理字体编码问题——PDF 里字体子集化之后，字符到 Unicode 的映射经常是错的，需要靠字形比对或者上下文推断来纠正。
这一步的产出统一是 LaTeX，因为 Markdown 生态里数学公式基本都用 LaTeX 语法（行内用$...$，块级用$$...$$）。转成 LaTeX 之后，不管你是用 Typora、Obsidian 还是网页渲染，都能正常显示。
4. 实操：从安装到批量转换的完整流程
4.1 环境准备与依赖安装
这类项目一般是 Python 写的，我按最常见的部署方式来写。先建虚拟环境，避免污染系统环境：
python -m venv pdf2md source pdf2md/bin/activate # Windows 用 pdf2md\Scripts\activate然后装依赖。注意，这类工具通常分“轻量模式”和“完整模式”：轻量模式只装基础依赖，纯文字 PDF 够用；完整模式要装深度学习框架和模型权重，才能处理表格公式。我建议先装轻量的跑通流程，再按需补模型。
pip install -r requirements.txt # 如果需要表格公式识别，再装模型相关依赖 pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu注意：如果你没有独立显卡，模型推理会走 CPU，速度慢但能用。一份二十页的文档，CPU 上跑几分钟是正常的，别以为是卡死了。
4.2 单文件转换：先拿一份文档试水
装好之后，先拿一份文档试。命令行一般长这样：
python convert.py --input sample.pdf --output sample.md --device cpu几个关键参数我解释一下：
--input/--output：输入输出路径，输出建议用.md后缀。--device：cpu或cuda，有显卡就上cuda，速度差好几倍。--table/--formula：是否启用表格和公式识别，不需要就关掉省时间。--lang：文档语言，中英文混排的文档建议显式指定，能提升识别准确率。
跑完之后打开sample.md，重点看三处：表格有没有错位、公式有没有变成乱码、段落顺序有没有乱。这三处没问题，基本就稳了。
4.3 批量处理：写个脚本一次搞定一个文件夹
单文件转换只是验证，真正干活要批量。我一般写个简单脚本遍历目录：
import os from pathlib import Path input_dir = Path("./pdfs") output_dir = Path("./markdown") output_dir.mkdir(exist_ok=True) for pdf_file in input_dir.glob("*.pdf"): out_file = output_dir / (pdf_file.stem + ".md") cmd = f"python convert.py --input {pdf_file} --output {out_file} --device cuda" print(f"处理中: {pdf_file.name}") os.system(cmd)这个脚本很糙但够用。生产环境建议加上错误捕获、日志记录、失败重试，避免一份文档出错整个批次中断。
4.4 参数调优：几个真正影响质量的开关
实测下来，有几个参数对结果影响特别大，值得单独调：
- DPI / 渲染分辨率：PDF 渲染成图片时的分辨率。太低表格线条糊成一团，太高推理慢。我一般用 200 到 300 之间，扫描件可以适当调高。
- 表格识别阈值：控制线条检测的灵敏度。表格线很淡的文档，阈值调低一点；噪点多的扫描件，阈值调高避免误检。
- 阅读顺序策略：多栏文档的关键。有的工具支持“按栏”和“按块”两种模式，学术论文用按栏，普通文档用按块。
- 公式识别开关：纯技术文档开，普通文档关，能省不少时间。
5. 实测对比：它和 Gemini、传统 OCR 到底差在哪
5.1 测试集设计：我挑了五类“刁钻”文档
为了不空口说白话，我准备了一份测试集，覆盖五类典型场景：
- 纯文字技术手册（20 页，单栏）
- 学术论文（15 页，双栏，含大量公式）
- 财务报表（10 页，复杂合并单元格表格）
- 扫描版合同（8 页，有倾斜和噪点）
- 图文混排产品文档（12 页，图片和文字交错）
每类文档我都用这个开源工具、一个传统 OCR 工具、以及一个顶级闭源模型各跑一遍，人工核对结果。
5.2 结果对比：表格和公式是分水岭
| 文档类型 | 开源工具 | 传统 OCR | 闭源模型 |
|---|---|---|---|
| 纯文字手册 | 优秀 | 良好 | 优秀 |
| 学术论文 | 良好 | 差（公式丢失） | 优秀 |
| 财务报表 | 良好 | 差（表格错位） | 优秀 |
| 扫描合同 | 中等 | 中等 | 良好 |
| 图文混排 | 良好 | 中等 | 优秀 |
结论很清晰：纯文字场景大家都能打，表格和公式是拉开差距的地方。传统 OCR 工具在表格和公式上基本是崩的，开源工具能做到“良好”，闭源模型“优秀”。标题说“跑分贴着 Gemini”，从我的实测看，在表格和公式这两块确实接近，差距主要在扫描件和极端复杂版式上。
5.3 速度与成本：本地跑的真实账
速度方面，同一份 20 页文档：
- 开源工具（GPU）：约 40 秒
- 开源工具（CPU）：约 4 分钟
- 闭源模型 API：约 30 秒（含网络传输）
成本方面，闭源 API 按页收费，一份文档几毛到几块不等，批量处理一个月下来是笔不小的开销。开源工具一次性部署，之后零边际成本。所以如果你的文档量大、或者对隐私敏感，开源方案的优势非常明显。
6. 踩坑记录与常见问题排查
6.1 表格错位的三种典型情况和修法
情况一：无边框表格被识别成普通段落。这是最常见的。修法是调低表格检测阈值，或者手动在配置里开启“无边框表格推断”。如果还是不行，只能事后手动补 Markdown 表格语法。
情况二：合并单元格被拆散。PDF 里的合并单元格在视觉上是一个大格子，但底层可能是多个文字块。工具如果没识别出合并关系，就会拆成多行多列。这种情况目前没有完美解法，只能人工修正。
情况三：跨页表格断裂。表格跨页时，工具可能当成两个独立表格。修法是开启“跨页表格合并”选项，或者事后手动拼接。
6.2 公式变乱码的排查思路
公式乱码通常有两个原因：一是字体编码问题，二是公式识别模型没启用。排查顺序：
- 先确认
--formula参数开了没； - 看输出里公式是变成了乱码字符还是变成了图片引用；
- 如果是乱码字符，说明字体映射错了，试试换一个 PDF 渲染引擎；
- 如果是图片引用，说明公式识别没生效，检查模型权重有没有下载完整。
6.3 扫描件质量差怎么办
扫描件是老大难。我的经验是：预处理比换工具更有效。转换前先做三件事：
- 用图像工具做去噪和二值化，把灰底和噪点清掉；
- 做倾斜校正，把歪的页面摆正；
- 适当提高对比度，让文字和背景分离更明显。
这三步做完，识别率能提升一大截。工具本身对扫描件的鲁棒性有限，别指望它包治百病。
6.4 常见问题速查表
| 问题现象 | 可能原因 | 解决方向 |
|---|---|---|
| 输出为空 | 输入路径错或 PDF 加密 | 检查路径，先解密 PDF |
| 中文乱码 | 字体缺失或编码错 | 指定语言参数，换渲染引擎 |
| 表格全糊 | 未启用表格识别 | 开启表格参数，调阈值 |
| 公式丢失 | 未启用公式识别 | 开启公式参数，检查模型 |
| 速度极慢 | 走 CPU 或分辨率过高 | 上 GPU，降 DPI |
| 段落顺序乱 | 多栏阅读顺序错 | 切换阅读顺序策略 |
7. 进阶玩法：把转换结果接进你的工作流
7.1 喂给 RAG 做知识库
这是我现在最主要的用法。PDF 转成 Markdown 之后，表格和公式都保留了结构，切块（chunking）的时候可以按标题层级切，检索质量比直接切 PDF 文本高很多。尤其是表格，保留成 Markdown 表格后，模型能直接理解行列关系，回答“某年某季度营收多少”这类问题准确率明显提升。
7.2 批量归档与版本管理
Markdown 是纯文本，天然适合 Git 管理。我把转换后的文档全部纳入 Git 仓库，每次更新都能看到 diff，比二进制 PDF 友好太多。配合 CI，还能自动检查文档里的链接是否失效、图片路径是否正确。
7.3 二次加工：公式和表格的后续处理
转出来的 LaTeX 公式可以直接粘到支持数学渲染的编辑器里。表格如果想转成 Excel，可以用pandoc再转一道：
pandoc input.md -o output.xlsx图片路径默认是相对路径，迁移文档时记得把图片文件夹一起带上，否则会显示裂图。
8. 我个人在实际操作中的几点体会
折腾这类工具这么久，最大的体会是：没有万能工具，只有合适的组合。纯文字文档随便什么工具都行，别浪费时间；表格公式多的文档，值得上模型方案；扫描件质量差的，预处理比换工具管用。
另外一个心得是，别追求 100% 自动化。PDF 的版式千奇百怪，总有一些边角情况需要人工兜底。我的做法是让工具处理 90%，剩下 10% 人工快速过一遍，整体效率比追求全自动高得多。工具是帮你省时间的，不是替你背锅的。
最后分享一个小技巧：转换前先用工具跑一份“样本页”，确认参数调对了再批量跑。我早期图省事直接批量，结果参数不对，几百份文档全白跑，重来一遍的时间够我喝好几壶茶了。先小后大，这个习惯能帮你省下大量返工时间。
