🔥 项目详情

pdf-inspector

纯 Rust 写的 PDF 分类 + 文本提取库,零 ML 模型,200 文档 0.47 秒搞定

firecrawl/pdf-inspector MIT Rust 11.4k★

更新于 2026-08-06 · v0.2.6

← 返回汇总
项目速览

一句话定位

PDF 处理流水线的"智能路由器"——先判断要不要 OCR,再决定怎么走

Firecrawl 出品的纯 Rust PDF 库。不做 OCR,不用任何 ML 模型,只干一件事:10-50ms 判断 PDF 是原生文本还是扫描件,原生文本的直接提取成 Markdown,扫描件的标记出来交给 OCR 引擎。核心洞察:约 54% 的 PDF 根本不需要 OCR,对它们调用重型 OCR 引擎纯属浪费。

项目速览

核心数据

0.47s
200 文档耗时
~50ms
单文档分类
0.875
综合得分
0
ML 模型依赖

基准 opendataloader-bench(200 PDF),Apple M4 Pro,OCR 关闭。综合得分满分 1.0。

🔥 核心洞察

54% 的 PDF 不需要 OCR

这是 pdf-inspector 存在的核心理由。Firecrawl 在生产环境中发现,超过一半的 PDF 是原生文本 PDF(电子版报告、论文、合同),文字层完整存在,根本不需要任何 OCR。

原生文本 PDF

Word/LaTeX 导出的 PDF,文字可选中复制。pdf-inspector 直接提取,亚秒级。

扫描件 PDF

纸质扫描/拍照转的 PDF,文字是图像。需要 OCR 引擎(MinerU/DeepSeek-OCR)。

混合型 PDF

部分页文本、部分页扫描。pdf-inspector 做逐页路由。

🔥 核心机制

PDF 处理流水线的"守门员"

pdf-inspector 不是 MinerU/DeepSeek-OCR 的竞品,而是它们的前置智能路由层。正确架构是组合使用:

任意 PDF 文本/扫描/混合 ROUTER pdf-inspector 10-50ms 分类 text/scanned/mixed 逐页路由决策 FAST PATH pdf-inspector 提取 直接解析文字层 → Markdown 亚秒级 · 零 GPU SLOW PATH OCR 引擎接管 MinerU / DeepSeek-OCR 需 GPU · 秒级 Markdown 结构化输出 ~54% 是文本 扫描/混合
路由决策点 两条处理路径 输入/输出
核心机制

技术能力清单

性能数据

本地解析器基准对比

引擎综合阅读顺序 (NID)表格 (TEDS)标题 (MHS)200 文档耗时
pdf-inspector0.8750.9150.8140.7880.470s
liteparse0.8730.9130.6930.8110.750s
opendataloader0.8310.9020.4890.7392.569s
pymupdf4llm0.7350.8860.4010.42417.117s
markitdown0.5890.8440.2730.00016.165s

opendataloader-bench 语料(200 PDF),仅本地无模型引擎,OCR 关闭。pdf-inspector 综合分、阅读顺序、表格、速度均第一。比 markitdown 快 34 倍。

快速上手

三行 Python 搞定

# 安装(Rust 编译,需 maturin)
pip install maturin
maturin 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(@firecrawl/pdf-inspector)和浏览器 WASM(@firecrawl/pdf-inspector-wasm)绑定,同一套 Rust 核心。

适用场景

谁该用它

🔥 横向对比

PDF 解析光谱:四层不是竞品

项目层次技术路线扫描件速度关系
pdf-inspector规则解析 + 路由纯 Rust,零 ML❌极快— 本页 —
MinerU端到端产品VLM+OCR 双引擎✅慢下游互补:pdf-inspector 把扫描件交给它
DeepSeek-OCRVLM 模型单一视觉语言模型✅慢下游互补:扫描件的另一选择
Apache Tika通用解析器Java,1000+ 格式✅中平行互补:非 PDF 全部交给它 · 看 11 维横评打分表 →

三者组合 > 单选:pdf-inspector 做网关 → 原生文本自己处理 → 扫描件按需转交 MinerU 或 DeepSeek-OCR。

风险提示

局限与边界

潜力评估

未来空间

PDF 解析"成本优化"赛道的标杆。当 LLM 应用大规模处理真实文档时,先用规则吃掉 54% 的简单情况,再把贵的 GPU 留给真正需要 OCR 的部分——这是生产环境的工程常识。Firecrawl 自身已验证这条路径。

评分
8.5 / 10
状态:watching(实用但需搭配 OCR 引擎)
总结

一句话带走

不是所有 PDF 都值得上 OCR——pdf-inspector 帮你把简单的先解决掉。

如果你的系统在批量处理 PDF,加一层 pdf-inspector 做前置路由,能省掉一半以上的 GPU 成本。它和 MinerU、DeepSeek-OCR 是搭档关系,不是替代关系。


上一个
MinerU
下一个
DeepSeek-OCR
1 / 14