pdf-inspector 评测：先本地解析 PDF，再按页调用 OCR

pdf-inspector 是本地 PDF 解析器和 OCR 路由器，不是 OCR 引擎。Firecrawl 开源的 Rust 库会把文档判断为文本型、扫描型、图像型或混合型，直接把可用的原生文本提取成 Markdown，并返回仍需 OCR 的页码。它的商业价值就在这一步：已经有机器可读文本的页面，不再走最慢、最贵的处理路径。

社交媒体帖子写的是每页 0.002 秒。仓库确实公布了很亮眼的 benchmark，但它并没有证明所有 PDF 页面都能达到这个速度。本文把实测结果与传播标题分开，说明原生解析的边界，并给出适用于 RAG 入库、发票提取、合同搜索和 AI 智能体的生产决策框架。

pdf-inspector 到底做什么？

它在渲染页面或调用模型之前，先读取 PDF 的内部结构。检测器会检查页面树里的文本与图像操作符，提取器再根据位置、字体、分栏、链接、列表、标题和表格重建内容。输出不仅有 Markdown，还包括置信度、复杂版式标记，以及需要 OCR 的页面。

这个库不包含 OCR 模型，这是有意的边界。pdf-inspector 官方 README把它定义为纯 Rust 解析器，不依赖机器学习模型或外部服务。Firecrawl 托管的 Fire-PDF 流水线则是更完整的产品：先用 pdf-inspector 分类和提取原生文本，再对必要区域做版式检测和 GLM-OCR。评估时必须分清这两层。

200 份 PDF 真能在 0.470 秒内处理完吗？

在 Firecrawl 公布的直接文本 benchmark 中可以，但这不等于任意 PDF 的每一页都只需两毫秒。

这组结果在 2026 年 7 月 31 日更新，比较了 pdf-inspector 0.2.6、LiteParse、OpenDataLoader、PyMuPDF4LLM 与 MarkItDown，仓库还提供配置和结果分支。可靠的采购结论不是“任何场景都最快”，而是“它很适合作为原生文本 PDF 的本地候选，需要用自己的文档集复测”。

Firecrawl 还表示，它自己的工作负载中约 54% 的 PDF 不需要 OCR。这个比例只代表厂商的文档分布，不是行业常数。先对过去 30 至 90 天的真实文档运行分类，再计算商业收益。

生产架构：先分类，再升级处理

1. 安全接收：限制文件大小和页数，检查文件签名，不信任 MIME header，替换用户提供的文件名，并存放在 webroot 之外。
2. 隔离解析：设置 CPU、内存和超时预算。供应商 PDF、邮件附件和公开上传都属于不可信输入。
3. 只分类一次：记录文档类型、置信度、页数、编码警告、复杂版式，以及需要 OCR 的页面。
4. 走低成本路径：高置信度原生文本不经过网络，直接转换成 Markdown。
5. 按需升级：只渲染被标记的页面或区域，再送入获批的 OCR 服务或本地模型。
6. 带来源合并：按原页序组装，保留页码、解析器版本、处理路线、置信度和人工更正。
7. 输出设闸：入库或触发智能体动作之前，检查空页、字符质量、表格、合计、日期、标识符和必填字段。

预计路由收益 = 避免的 OCR 页数 × 每页 OCR 边际成本，再减去解析计算、工程与更正成本。

失败文档必须留在分母里。我们的 AI 智能体单次行动成本框架解释了为什么后续需要人工修复的低价提取，并不是一次成功行动。如果 Markdown 接下来要进入知识索引，请继续查看欧盟企业 RAG 生产就绪清单。那篇文章负责检索、权限、评测和答案引用，本文负责分块前的 PDF 入口。

选择 Node.js、Python、Rust，还是浏览器 WebAssembly？

官方 WebAssembly 文档说明，PDF bytes 不会上传，构建为单线程，CMaps 已嵌入，纯图片文档仍需单独 OCR。浏览器版本很适合隐私预检，但并不会自动变成完整的文档智能平台。

const result = classifyPdf(pdfBuffer)

if (result.pdfType === "TextBased" && result.confidence >= 0.9) {
  return processPdf(pdfBuffer).markdown
}

const native = processPdf(pdfBuffer).markdown
const scanned = await ocrOnly(pdfBuffer, result.pagesNeedingOcr)
return mergeByPage(native, scanned)

ocrOnly 与 mergeByPage 是应用代码，不是 pdf-inspector API。0.9 这个阈值也不能凭感觉照抄。先优化扫描页漏判，尤其要识别看似含文本、实际解码成乱码的页面。发票或合同流程里，漏掉一页的代价可能高于数千次成功避免的 OCR 调用。

哪些场景不适合 pdf-inspector？

• 扫描件、手写与照片：它能把这些页面路由出去，但没有其他 OCR 或视觉组件就无法读取。
• 未编码成文本的视觉语义：图表、复选框、签名、印章和空间关系可能需要版式或视觉模型。
• 要求完美还原：标题和表格依赖字体、绘图操作与对齐方式推断，启发式规则可能出错。
• 无限制的公开上传：Rust 能降低部分内存安全风险，但仍需限制、隔离和依赖更新。项目的安全策略明确把恶意 PDF 引发的内存与拒绝服务问题列入范围。
• 要求零运维：开源库给你控制权，但不会自动提供 SLA、人工审核队列和故障恢复。

OWASP 的文件上传安全指南建议采用多层防护：类型白名单、签名校验、大小限制、隔离存储、及时更新解析器、恶意软件检查和沙箱。数据留在本地可以减少传输，但不会让外部 PDF 自动可信。

PDF 流水线应该自建、采购，还是混合？

投入开发前，先做十天评测

1. 抽样真实文档：至少选择 200 份代表性 PDF，覆盖语言、来源、页数和失败类型，另建恶意与损坏文件集。
2. 人工标注路线：确认哪些页面有可靠原生文本，哪些需要 OCR、复杂版式处理或直接拒绝。
3. 建立基线：记录现有方案的质量、p50、p95、OCR 页数、人工更正分钟数和每份验收文档成本。
4. 运行 pdf-inspector：固定版本和机器，先测 OCR 路由召回率，再测 Markdown 结构和端到端吞吐。
5. 给例外定价：计算避免的 OCR 页数、额外工程、人工修复，以及漏判扫描页的成本。
6. 攻击处理边界：在隔离环境测试超大、加密、损坏、误导和高资源消耗 PDF。
7. 用闸门决策：只有在成本或延迟改善，同时满足提取质量与安全阈值时才上线。

如果这层会成为产品基础设施，我们的 AI enablement 服务可以帮助评测文档集、构建路由层并加入质量评估。Twinsoft AI展示了同一个生产原则：用质量闸门和可追溯证据约束模型输出。MVP 技术栈选择指南则帮助你在架构固化前决定哪些层应自持，哪些层更适合采购。

一手来源与 benchmark 日期

• Firecrawl pdf-inspector 仓库与 benchmark，2026 年 7 月 31 日更新。
• Node.js 与 Bun 官方 API 文档。
• Python 官方 API 文档。
• 浏览器 WebAssembly 官方文档。
• Firecrawl 对 Fire-PDF 架构的发布说明。
• OWASP 文件上传安全指南。