pdf-inspector：先判 PDF，再交给 OCR

RAG 文档预处理最容易被忽略的一步，是把每份 PDF 不加区分地送进 OCR。firecrawl/pdf-inspector 选了更轻的做法：Rust 库先读取 PDF 的内容流，依据文本与图像操作符把文档判为 TextBased、Scanned、ImageBased 或 Mixed，并给出逐页 OCR 路由。原生文本页留在本地做位置感知抽取、列顺序恢复、表格识别和 Markdown 转换；扫描页或异常编码页才交给 OCR。它不是 OCR 引擎，也不是“把所有 PDF 都解析好”的承诺，而是一层前置判别器和结构化文本抽取器。对于混合文档，这个边界尤其重要：同一份报告可能正文可直接读、附件扫描页却不能，按整份文件二选一会浪费时间或丢掉信息。

这恰好击中 RAG 的成本与延迟问题：报告、论文、发票和合同中大量页面本来就有可用文本，重复 OCR 既慢也可能破坏阅读顺序。README 的路由示例写的是约 20ms 分类、约 150ms 本地抽取，而 OCR 服务通常要 2-10 秒；这些是示例量级，不应外推为所有文件的统一 SLA。它在 200 份 PDF 的公开基准中列出 Overall 0.875、完整运行 0.470 秒，但测试限定于本地、禁用 OCR、Apple M4 Pro 环境。对团队而言，真正应评估的是自身 PDF 的扫描占比、表格复杂度、字体编码和 OCR 降级质量，也要拿带有多栏、页眉页脚与复杂表格的真实样本验收 Markdown。GitHub API 在本次抓取时显示约 1 万 stars；用户提供的“今日约 +2,524”说明热度很高，但属于会变化的趋势快照。

源码地址：
https://github.com/firecrawl/pdf-inspector