GitHub 17.2K Star！Firecrawl 又开源了一个 AI 文档神器

现在做 AI 应用，PDF 怎么处理几乎是个绕不开的难题。论文、财报、合同、技术文档、发票、扫描件……各种各样的 PDF 涌进来，最终通常都会走一条固定路线：PDF → OCR → 文本 → Markdown → 交给 AI。但这里有个被很多人忽略的问题——真的每一个 PDF 都需要 OCR 吗？

Firecrawl 最近开源了一个叫pdf-inspector的项目，思路非常简单：先检查 PDF 是什么类型，再决定要不要 OCR。这是一个用 Rust 编写的开源 PDF 解析工具，能判断 PDF 类型、提取文本、分析页面布局、识别多栏内容、检测表格、转换成 Markdown，并且只对真正需要处理的页面进行 OCR。目前 GitHub 已经获得超过1.7 万+ Star。

PDF 处理，很多时候第一步就错了

现在很多 PDF 处理流程就是拿到 PDF 直接 OCR，但其实 PDF 并不只有一种。有些是真正的文本 PDF，比如技术文档、财报、Word 或网页导出的 PDF，这些文件本身就已经包含文字、字体、坐标和布局，根本不需要 OCR。还有一些是扫描件，里面其实是一张张图片，这时候才需要 OCR。

Firecrawl 的 pdf-inspector 做的第一件事情，就是先判断你手里的 PDF 到底是什么。它能识别 TextBased（文本 PDF）、Scanned（扫描 PDF）、ImageBased（图片型 PDF）和 Mixed（混合 PDF）四种类型，而这一步分类通常只需要大约 10 ～ 50ms。

先花几十毫秒，可能省掉几秒 OCR

这才是这个项目最聪明的地方。传统流程是所有 PDF 一律 OCR，等上几秒才能得到文本。pdf-inspector 的做法是先快速检测，如果是文本 PDF 就直接本地提取，只有扫描件才送去 OCR。

PDF 到达 → pdf-inspector 分类（≈20ms）→ 文本 PDF？YES → 本地提取（≈150ms）→ 完成→ 扫描件？NO → OCR（2～10秒）

以前所有 PDF 都走最慢的流程，现在只有真正需要 OCR 的才走 OCR。Firecrawl 提到，大约 54% 的 PDF 不需要 OCR，这些文件本身就包含完整文本。如果全部送到 OCR API、云端服务或 AI 文档解析服务，不仅速度慢，还意味着更多成本、更多延迟和更多服务器资源。pdf-inspector 的思路是"能本地解决，就不要送出去"，对于文本型 PDF，它可以在本地200ms 以内完成处理。这对于需要批量处理大量论文、企业文档、财务报告或法律文件的系统来说，非常实用。

它不只是提取文字，还会理解 PDF 布局

普通 PDF 文本提取经常会把左右两栏内容混在一起。比如双栏论文，正常阅读顺序应该是左栏读完再读右栏，但普通提取可能变成"左栏第一行、右栏第一行、左栏第二行、右栏第二行"——AI 看到以后直接乱了。

pdf-inspector 会根据文字的 X 坐标、Y 坐标、字体信息和页面布局重新分析阅读顺序，包括多栏布局、报纸布局和文档分栏，尽可能恢复人类真正阅读 PDF 的顺序。这对后面的 PDF → Markdown → LLM 流程非常重要。

表格，也是 PDF 解析最容易翻车的地方

如果你经常处理 PDF，一定遇到过表格解析后直接变成一堆文字的情况。原 PDF 里整整齐齐的表格，解析后产品、2025、2026、A、100、120、B、200、250 全部混在一起，表格结构直接没了。

Firecrawl 的 pdf-inspector 专门做了 Table Detection，结合 PDF 矩形结构、表格线、文本位置和对齐关系来判断表格，并且支持财务表格、多页表格、表格延续和脚注，最终尽可能转换成标准的 Markdown 表格格式。对于财报加 AI 分析这种场景，这个功能非常重要。

PDF 最终直接变成 Markdown

Markdown 可能是现在 AI 应用最喜欢的输出格式，因为它非常适合直接交给 LLM。pdf-inspector 会尝试识别标题（H1/H2/H3/H4）、列表、代码块、粗体、斜体、链接、表格和分页，然后转换成结构化 Markdown。最终形成 PDF → pdf-inspector → Markdown → LLM 的链路，直接用于 RAG、AI Agent、文档问答、知识库、AI 搜索和 PDF Chat。

最有意思的是：OCR 可以只处理几页

这个功能非常实用。想象一个 100 页的 PDF，其中 90 页是文本 PDF，但 10 页是扫描图片。传统方案是 100 页全部 OCR，而 pdf-inspector 会检测每一页，90 页直接解析，只有 10 页送去 OCR。

官方称这种方式为Selective OCR（选择性 OCR），只有真正需要 OCR 的页面才会进入 OCR 流程，这样可以减少成本、减少延迟、减少资源消耗。

Rust 核心，浏览器里也能直接解析

最近越来越多 AI 基础设施开始使用 Rust，因为 AI 系统需要处理大量数据、大量文件和大量并发，要求高性能和低延迟。pdf-inspector 核心使用 Rust，然后向外提供 Python、Node.js、Browser WebAssembly 和 CLI 支持。

你可以用 pip install pdf-inspector 安装 Python 版本，用 npm install @firecrawl/pdf-inspector 安装 Node.js 版本，或者用 cargo add pdf-inspector 在 Rust 中使用。

而且通过 WebAssembly，PDF 可以直接在浏览器里处理。官网 Demo 就是上传 PDF → 浏览器本地解析 → 转换 Markdown，文件不需要上传到服务器。这对于隐私文档、企业内部文件和本地 AI 工具非常有价值，因为 PDF 始终留在浏览器里。

官方测试：速度非常夸张

项目使用 200 份 PDF 进行了本地测试，官方公开数据显示，pdf-inspector 整体速度为0.470 秒，对比 LiteParse 的 0.750 秒、OpenDataLoader 的 2.569 秒、PyMuPDF4LLM 的 17.117 秒和 MarkItDown 的 16.165 秒，优势明显。同时在 Overall、Reading Order、Tables 等指标上也表现不错。测试环境为 Apple M4 Pro，需要注意的是这些数据来自项目官方基准测试，并且测试主要针对本地 PDF 解析器，OCR 在该轮测试中关闭。

但至少说明了一件事：Firecrawl 这次不是简单做了一个 PDF 转 Markdown 工具，而是在认真做高性能 PDF Parsing。

它真正解决的是 AI 文档处理的"智能路由"问题

现在大家做 AI 应用，都会遇到 PDF、Word、Excel、PPT、网页等各种文档，然后全部转换、全部解析、全部 Embedding、全部进入 RAG。但现实情况是，不同文档应该走不同的处理方式——文本 PDF 直接提取，扫描 PDF 走 OCR，复杂表格做结构分析，图片走视觉模型。

所以未来 AI 文档处理可能不再是"一个工具处理所有文件"，而是 Document → 先判断 → 选择最佳处理方式，这其实就是智能路由，而 pdf-inspector 正是在做这件事。

Firecrawl 最近还推出了 AnyDoc，pdf-inspector 专门处理 PDF，AnyDoc 处理其他常见文档，两者合称 Document Parsing Stack。而且这些能力已经用于 Firecrawl 自己的 /parse 和 /scrape 相关文档处理能力。所以这个项目不是"随便做出来的 GitHub Demo"，而是 Firecrawl 自己实际文档处理体系中的一部分。

pdf-inspector 最值得关注的，其实不是 PDF 转 Markdown——现在做这件事的工具已经很多。它真正有意思的地方是先判断 PDF，再决定怎么处理。

以前：PDF → 全部 OCR。

现在：PDF → 检测类型 → 文本？直接提取；扫描件？OCR。

这看起来只是一个小变化，但对于 AI 知识库、RAG、AI Agent、企业文档系统和 PDF 批处理来说，可能意味着更低成本、更低延迟和更快速度。

一句话总结：Firecrawl 这次做的，不是让所有 PDF 都去 OCR，而是先让程序搞清楚：这个 PDF 到底需不需要 OCR。

如果你正在做 AI 文档解析、RAG、知识库或者 PDF Chat，这个项目非常值得关注。

GitHub：https://github.com/firecrawl/pdf-inspector 官网：https://firecrawl.github.io/pdf-inspector/

你平时处理 PDF 时，有没有遇到过"全部 OCR 导致又慢又贵"或者"表格解析后直接变成一堆文字"的情况？你觉得"先判断 PDF 类型，再决定处理方式"这种智能路由思路，会成为未来 AI 文档处理的标准做法吗？评论区聊聊～

各位互联网搭子，要是这篇文章成功引起了你的注意，别犹豫，关注、点赞、评论、分享走一波，让我们把这份默契延续下去，一起在 AI 科研的海洋里乘风破浪！