思考未来

2026年8月4日

pdf-inspector：先判断 PDF 是否真需要 OCR，再交给 AI

做知识库、RAG 或文档智能时，PDF 往往被统一送进 OCR。问题是，大量报告、论文和合同本来就带文本层：全量 OCR 不仅更慢、更贵，还可能引入识别错误。Firecrawl 开源的 pdf-inspector 提供了一条更克制的路径——先在本地判断 PDF 类型，只把确实需要

做知识库、RAG 或文档智能时，PDF 往往被统一送进 OCR。问题是，大量报告、论文和合同本来就带文本层：全量 OCR 不仅更慢、更贵，还可能引入识别错误。Firecrawl 开源的 pdf-inspector 提供了一条更克制的路径——先在本地判断 PDF 类型，只把确实需要识别的页面交给 OCR。

📌 它解决什么问题

pdf-inspector 是一个 Rust 编写的 PDF 分类与文本提取库。它会检查页面内容流中的文本和图像操作符，将文档识别为文本型、扫描型、图像型或混合型，并返回置信度及需要 OCR 的具体页码。

对于已有文本层的页面，它还能直接提取文字并转换为 Markdown，处理标题、列表、代码块、链接、多栏阅读顺序和表格。整个核心不依赖模型或外部服务，数据可以留在本地；同时提供 Python、Node.js、Rust、浏览器 WebAssembly 和命令行接口。

🔍 为什么值得关注

它的价值不在于“又一个 PDF 转 Markdown”，而是给 AI 文档管线增加了低成本路由层：文本型 PDF 走本地快速提取，扫描页再进入 OCR，混合文档则按页处理。这样能减少无效 OCR，也更容易控制延迟、费用和隐私边界。

官方在 200 份 PDF 的开源基准上公布了可复现实验，覆盖阅读顺序、表格、标题和速度。不过这些结果来自 Apple M4 Pro，且关闭了 OCR，只适合用来判断本地文本解析能力，不能直接等同于所有中文 PDF 或生产环境表现。

🧪 谁适合试，怎么开始

适合在做 RAG 入库、报告归档、论文解析、票据或合同处理的开发者。Python 用户可以先拿一批真实文档验证：

pip install pdf-inspector
import pdf_inspector

result = pdf_inspector.process_pdf("document.pdf")
print(result.pdf_type)
print(result.pages_needing_ocr)
print(result.markdown)

若只想做路由，可调用 detect_pdf，避免完整提取。建议分别准备原生文本、纯扫描、双栏论文、复杂表格和中英混排样本，统计分类正确率、Markdown 结构完整度与单页耗时，再决定是否接入现有 OCR 服务。

⚠️ 使用提醒

“不需要 OCR”只代表 PDF 存在可提取文本，不代表结构一定正确。缺失 ToUnicode 映射、特殊字体、公式、手写内容和复杂嵌套表格仍可能解析失败；项目会标记部分编码问题，但业务侧仍要保留质量检测与 OCR 回退。官方目前没有 GitHub Release，Python、npm 与 crates.io 包版本也不一致，生产使用应固定依赖版本，并用自己的文档集做回归测试。项目采用 MIT 许可证。

🔗 参考资源