把 PDF 转文字速度有多快?200份PDF,0.47秒,关键还是本地处理

点了一个"提取 PDF 内容"的按钮，进度条开始转。5 秒。10 秒。你端起杯子喝了口水——然后看着它在调 OCR一点点转换。

但这份 PDF 从头到尾都是 Word 导出来的纯文本文档，每一行字都老老实实在文件流里。却用 OCR 逐像素地"看"它，就像用放大镜检查一本字迹清晰的印刷书：明明翻一下就能读，偏要先拍照→识别→抄录一遍。

约 54%的 PDF 是纯文本型的。你有一半以上的 PDF 提取，OCR 都在做无用功。

Firecrawl 团队前两天开源了一个东西，专门治这个问题。叫 pdf-inspector，Rust 写的，逻辑简单到你会觉得"为什么之前没人这么干"——先花 20 毫秒判断 PDF 类型，文本型的直接本地提取（~150 毫秒），只有扫描件和图片型才送去 OCR。

54% 的 PDF，OCR 纯属添乱

pdf-inspector 的核心思路不是"做更好的 OCR"，而是"先问一句：这 PDF 真的需要 OCR 吗？"

它拿到一个 PDF 后，先采样内容流，检测里面有 Tj/TJ（文本操作符）还是有 Do（图像操作符）。有文本操作符→纯文字 PDF→直接提取，一轮下来 ~20 毫秒就能出结果。没有→扫描件→送去 OCR。一个 300 页的 PDF，分类判断一样在毫秒级完成。

结果就是：处理 200 个 PDF，总耗时 2.8 秒。这是 Nicolas Camara（发帖人，Firecrawl 团队成员）在原推文里给的数字。

光说快不够，把 pdf-inspector 和市面上几个常用方案放在一起跑 opendataloader-bench 基准（200 个 PDF，Apple M4 Pro，2026 年 7 月 31 日测试），差距肉眼可见：

四个维度的分数（0–1，越高越好），pdf-inspector 在总分、阅读顺序、表格提取三项上全部领先。更关键的是速度那一列——pdf-inspector 跑完 200 个文档耗时 0.47 秒，而 pymupdf4llm 要 17.1 秒，markitdown 要 16.2 秒。差了 30 多倍。

有人问和 docling 比怎么样，其实质量差不多，但速度快了 300 倍。

能快到这个程度，原因就藏在分类逻辑里——纯文本 PDF 根本不走 OCR 管道，直接走 Rust 写的本地提取器，没有 HTTP 调用、没有 GPU 排队、没有模型加载。单次文档加载，检测和提取共享同一次解析，不重复读文件。

装好就能用，四行命令

Python 用户最简路径：

pip install maturinmaturin develop --release

装好之后：

import pdf_inspector
result = pdf_inspector.process_pdf("document.pdf")
print(result.pdf_type)   # "text_based", "scanned", "image_based", "mixed"print(result.markdown)   # Markdown 字符串，扫描件返回 None

Node.js 用户用 npm 也一样直接——npm install @firecrawl/pdf-inspector，导入processPdf函数，把 PDF 的 Buffer 扔进去就行。

但最快上手的方式是 CLI 。如果你本地有 Rust 环境：

cargo install pdf-inspectorpdf2md document.pdf

一句话，PDF 变 Markdown。加--json出结构化数据，加--pages输出页分隔标记，加--compact压缩 token 消耗——这几个参数对喂给大模型的场景非常实用。

日常就两件事

装完之后，平时用到的核心场景不外乎这两个。

第一件：把 PDF 转成 Markdown 喂给 AI。

这是 pdf-inspector 最原生的使用场景——它的分类器本来就为 agent pipeline 设计的。拿到的 PDF 先分类，文本型直接提，扫描件才路由到 OCR 服务：

# 先看一眼类型detect-pdf document.pdf
# 文本型 → 直接出 Markdownpdf2md document.pdf
# 想看每个文本块的位置信息（含坐标、字体、是否下划线）pdf2md document.pdf --items-json

输出质量在表格上尤其能打。pdf-inspector 用了两套表格检测机制：一套基于 PDF 绘图操作里的矩形指令（rectangle-based），一套基于文本对齐的启发式检测。财报、发票、法律文件里那种密集表格，两套互补着抓，比单纯靠文本缩进猜准得多。

第二件：批量处理 PDF，先筛出哪些值得 OCR。

如果你有一个文件夹塞了几百个 PDF，不知道哪些能直接用、哪些得上 OCR，pdf-inspector 的分类功能可以当筛子：

# 批量检测 + 版面分析detect-pdf document.pdf --analyze --json

返回结果会告诉你 pdf_type 是 text_based、scanned、image_based 还是 mixed，还会标记出具体哪些页需要 OCR（pages_needing_ocr）。不用整本扔去 OCR，只送真正缺文本的那几页就行。按 ~54% 的比例，你一半以上的 PDF 根本不用进 OCR 队列。

前提是你真在批量处理 PDF

pdf-inspector 对一类人改变最大：日常 pipeline 里要过大量 PDF、且 OCR 是个瓶颈的开发者。如果你一个月只处理两三个 PDF，手动复制粘贴可能更省事——装一个工具去优化一个你不会重复做的动作，意义不大。

它也有自己的边界。扫描件和纯图片型 PDF 的识别很准，但提取仍然依赖 OCR——它不做 OCR 本身，它帮你判断"这个该不该交给 OCR"。对那些"混合型"PDF（正文是文本、插图是扫描），它会把需要 OCR 的页号标注出来，但不会自动帮你调用 OCR 服务——这一环要你自己接。

另外，虽然它支持 WASM（浏览器端高性能字节码）在浏览器里跑，但目前还是初期阶段——@firecrawl/pdf-inspector-wasm的 API 和原生 Rust 版对齐了，但和 Node.js 版的成熟度还有距离。能在浏览器里不经过服务器就解析 PDF 这件事本身足够酷，只是别把它当生产依赖。

回来看这个工具的核心哲学，其实就一句：先判断，再决定。绝大多数 PDF 提取流程都缺这一步——上来就 OCR、上来就调 API、上来就排队。而加一个 ~20 毫秒的分类判断，就能把一大半的等待时间砍掉。不是技术多难，是之前没人停下来问："这份 PDF，OCR 真的非做不可吗？"

[pdf-inspector GitHub]：https://github.com/firecrawl/pdf-inspector

「点赞」「转发」「小心心」+欢迎在评论区留下你的想法！