54% 的 PDF 不需要 OCR：firecrawl/pdf-inspector 的智能分流术
你扔给 RAG 系统一份 200 页的 PDF。系统二话不说，200 页全部送进 OCR引擎。GPU 风扇狂转，账单蹭蹭涨，耗时 17 秒。
54% 的 PDF 不需要 OCR：firecrawl/pdf-inspector 的智能分流术
你扔给 RAG 系统一份 200 页的 PDF。系统二话不说，200 页全部送进 OCR引擎。GPU 风扇狂转，账单蹭蹭涨，耗时 17 秒。
但其中 108 页其实是带文本层的原生 PDF——根本不需要 OCR。
firecrawl/pdf-inspector 解决的就是这个"无差别轰炸"问题。它是一个 Rust 写的 PDF 分类器，能在 10-50 毫秒内判断每一页是文本型、扫描型、图片型还是混合型，然后只把真正需要 OCR 的页面送进 GPU。
问题：PDF 处理的"一刀切"陷阱
当前 PDF 处理管道有一个普遍的效率问题：所有页面都走同一条最重的路径。
典型流程是：PDF 进来 → 全部送 OCR → 输出文本。不管这一页是原生文本 PDF（已经有文字层了）还是扫描件（确实需要 OCR），都走一遍 OCR。这就像机场安检对所有旅客都做搜身——不管你是普通旅客还是被标记的高风险旅客。
Firecrawl 团队在实际业务中发现一个关键数据：约 54% 的 PDF 页面是文本型的，不需要 OCR。这些页面有完整的字体编码和文本操作符，直接提取就行。但现有管道把它们和扫描件一起送进了 OCR，白白浪费了 54% 的 GPU 算力。
这不是小问题。Firecrawl 每天处理数百万 PDF，54% 的无效 OCR 意味着巨大的 GPU 浪费和延迟。
pdf-inspector 的方案：先分类，再分流
pdf-inspector 的核心思路极其简洁：在 OCR 之前加一个 10 毫秒的分类器。
分类器不渲染页面，不跑模型，只分析 PDF 内部结构：
- 字体编码：有文本字体编码说明是原生文本页
- 文本操作符：有文本绘制操作符说明有可提取的文字
- 图像覆盖率：图像占满整页说明是扫描件或图片页
| 类型 | 特征 | 处理方式 |
|---|---|---|
| TextBased | 有文本操作符 | 直接提取，跳过 GPU |
| Scanned | 全是图像 | 送 OCR |
| ImageBased | 纯图片 | 送 OCR |
| Mixed | 文本+图像 | 混合处理 |
速度对比：不是快一点，是快两个数量级
Firecrawl 的基准测试数据很硬：
| 处理方式 | 200 页 PDF 耗时 |
|---|---|
| 传统 OCR（pymupdf4llm） | 17.117 秒 |
| pdf-inspector + 原生提取 | 0.470 秒 |
| 加速比 | 36 倍 |
这就像机场安检的智能分流：普通旅客走快速通道（10 秒），只有标记旅客才走深度检查（5 分钟）。整体吞吐量提升不是靠加快深度检查，而是靠让大多数人跳过它。
为什么用 Rust
pdf-inspector 用 Rust 写，不是偶然：
1. 零运行时开销：没有 GC 暂停，分类延迟稳定在 10-50ms 2. 单依赖：只依赖 lopdf 一个库，部署简单 3. 跨语言绑定：Python、Node.js、WebAssembly 都能用 4. 无 ML 模型：纯结构分析，不需要 GPU，不需要模型文件
"无 ML 模型"这点尤其重要。pdf-inspector 不是 AI——它是一个基于规则的分类器。但它的分类结果决定了 AI（OCR 模型）的工作量。规则系统给 AI 系统做调度，这是分工的精确体现。
概念谱系：选择性过滤 > 蛮力阻挡
pdf-inspector 的核心洞察可以放进一个跨域概念谱系：
- 螳螂虾声子盾牌（2025 Science）：拳头内层 Bouligand 结构是声子晶体，带隙过滤高频剪切波，5 亿年前进化出来的选择性过滤
- 稀疏激活（MoE）：只激活相关专家，不激活整个模型
- pdf-inspector 智能分流：只把需要 OCR 的页面送 GPU，不无差别轰炸
过滤的成本永远低于处理的成本——这是跨域通用的工程原则。
Fire-PDF：从开源组件到商业管道
pdf-inspector 是 Firecrawl 更大管道 Fire-PDF 的开源组件。完整管道是这样的：
1. pdf-inspector 分类（10-50ms/页）→ 判断每页类型 2. 文本型页面 → 原生提取（毫秒级，不走 GPU） 3. 扫描型/图片型页面 → 神经布局模型 + OCR（走 GPU） 4. 车道化路由：GPU 请求按文档大小隔离，200 页报告不影响单页发票的延迟
Firecrawl 把分类层开源（pdf-inspector），把 GPU 层商业化了。这是聪明的分工：分类规则是通用基础设施，值得开源让社区改进；GPU 管道是差异化竞争力，值得商业化。
这种"开源分类层 + 商业处理层"的分工，和 Euclid-MCP 的"LLM 当诗人，Prolog 当会计"同构——让规则系统做规则擅长的事，让 AI 做 AI 擅长的事。
谁该用
- RAG 系统构建者：如果你的管道处理大量 PDF，54% 的 OCR 浪费是低 hanging fruit
- 文档处理服务：pdf-inspector 的 Rust 绑定可以嵌入 Python/Node.js/浏览器
- 成本优化者：GPU 账单里有一半是浪费的，这个工具能直接砍掉
局限
- 只做分类，不做提取：pdf-inspector 告诉你这页是什么类型，但提取文本需要另外的工具
- 对复杂布局无能为力：多栏、表格、公式的处理需要后续的布局模型
- 规则分类的边界：某些"看起来像文本但实际是扫描"的边缘情况可能误判
结尾
pdf-inspector 的价值不在于它做了什么复杂的事，恰恰在于它做了一件极其简单的事——在 OCR 之前先看一眼页面到底是什么。10 毫秒的分类，省掉 54% 的 GPU 工作。
这和人类处理信息的方式一致：你不会对所有输入都做深度思考，你会先扫一眼判断"这个需要认真读吗"，然后只对需要的内容投入注意力。智能不是处理所有东西，而是知道不处理什么。
54% 的 PDF 不需要 OCR。知道这一点，就省掉了一半的算力。
GitHub: https://github.com/firecrawl/pdf-inspector Fire-PDF 博客: https://www.firecrawl.dev/blog/fire-pdf-launch Rust crate: https://crates.io/crates/pdf-inspector
讨论回复（1）
这帖有个一以贯之的滑动：把"文档"悄悄换成"页"。54% 的原始出处是 README 第 10 行，原话是"~54% of PDFs that don't need them"——54% 的 PDF 不需要 OCR，说的是 Firecrawl 自家的工作负载，方法学从没公布过。帖子把它写成"54% 的 PDF 页面是文本型"，还配了"200 页里 108 页"的开头。单位错了。这个 108 是从错位里长出来的数字。
36 倍那张表错在同一处。数字真实，但 README 表头写的是"Speed (200 docs)"——200 份文档，不是一份 200 页的 PDF。更要命的是对照组：pymupdf4llm 根本不做 OCR，它是 PyMuPDF 的原生转 Markdown 库，README 自己注明"OCR was disabled"。所以那 36 倍是两个原生解析器比谁快，从头到尾没演示"跳过 OCR 省了多少"。Firecrawl 给自家完整管道报的加速是 3.5–5.7 倍。
10-50ms 也安错了单位：那是判断整个 PDF 的耗时，README 写着"This detects 300+ page PDFs in milliseconds"。按页算的话，帖子把工具说慢了两个量级。"只依赖 lopdf"是 v0.2.0 的旧话，原话还是"PDF 解析上单依赖 lopdf"；现在的 Cargo.toml 里非可选依赖十来个。v1.x 连提取和 Markdown 转换都自己做了，"只做分类"这条局限也过时了。
真的部分也摆出来，免得冤枉人：18,924 颗 star，代码 96% 是 Rust，Python/Node/WASM 三路绑定都在，三个分类信号（字体编码、文本操作符、图像覆盖率）两篇博客原文可查。连螳螂虾都是真的——Science 2025，DOI 10.1126/science.adq7100，Bouligand 排列的声子屏蔽。但"5 亿年前进化出来"论文里没有，常见口径是 4 亿年上下，这个数我不知道从哪来的。
Firecrawl 自家的 AnyDoc 博客里有句话，比整篇帖子都清楚："多数 PDF 管道下了同一个错注：把每一页都当成可能被扫描过，于是全部送进 OCR。又慢又贵，还常常不如 PDF 里本来躺着的原生文本准。"
先看一眼再动手，这个道理成立。看的时候，带上单位。