PDF 进入 RAG 前,先判断需不需要 OCR

很多文档处理链路卡住，不是因为后面的 LLM 不够强，而是因为 PDF 入口太混乱。

同样是一个 PDF，有些文件本来就有可提取文本，有些文件只是扫描图片。前者如果直接送去 OCR，会浪费时间和成本；后者如果当成文本型 PDF 处理，又会把空内容或错乱内容送进知识库。

firecrawl/pdf-inspector 切的就是这个入口问题。

这是 Firecrawl 相关的 Rust 开源项目，定位是快速 PDF 分类、文本提取与 Markdown 转换库，能智能区分文本型与扫描型 PDF，并支持智能路由。这个仓库目前约 8,131 Stars，过去 24 小时新增约 1,699 Stars，说明文档进入 RAG 和 Agent 工作流之前的基础处理，正在被更多开发者重新重视。

先看 PDF 文档管道里最容易被低估的一步。

很多 RAG 系统一开始会把注意力放在切分、向量化、检索和重排上。文档一旦进入数据库，后面的工程会变得很复杂，调参空间也很多。问题是，如果最前面的 PDF 解析已经错了，后面的优化只是在处理脏输入。

PDF 和普通文本文件不一样。

一个 PDF 可能是论文、报告、合同、扫描件、表格页，也可能是多种内容混在一起的复杂文件。开发者真正需要知道的，不只是能不能打开 PDF，而是这个 PDF 应该走哪条处理路径。

文本型 PDF 最适合快速提取。

这类文件内部已经有文本层，关键是把阅读顺序、表格和段落尽量稳定地取出来，再转成后续系统更容易消费的 Markdown。firecrawl/pdf-inspector 的价值之一，就是把文本型 PDF 的处理做得足够快，项目资料给出的信息是可在 200ms 内完成。

扫描型 PDF 是另一类问题。

扫描件没有现成文本层，继续用普通文本提取方式处理，结果通常不会可靠。真正合理的选择，是尽早识别扫描型 PDF，然后路由到需要 OCR 的链路，而不是让所有文件默认进入同一条昂贵流程。

这也是 firecrawl/pdf-inspector 的项目定位里，智能分类和智能路由比单纯转换格式更关键的原因。

第一个关键点，是纯 Rust 实现。

文档入口能力通常会被放在服务端、批处理任务、边缘处理或数据导入脚本里。Rust 对这类基础设施很合适，因为 PDF 分类和提取不是一次性 Demo，而是可能出现在大量文件的持续处理流程中。稳定、快速、可嵌入，比界面是否好看更重要。

第二个关键点，是无 OCR 依赖。

这句话不能理解成项目要替代 OCR。更准确的理解是，firecrawl/pdf-inspector 把是否需要 OCR 这一步提前本地判断出来。文本型 PDF 不必进入 OCR，扫描型 PDF 再被分到适合的路径，整个系统就少了一层不必要的消耗。

这个判断对 RAG 很现实。

知识库导入经常会面对一批来源复杂的 PDF。如果所有文件都走 OCR，成本和耗时会被扫描件拖住；如果所有文件都走文本提取，扫描件又会变成低质量输入。把分类放在本地快速完成，相当于在文档进入知识库之前先做分流。

第三个关键点，是 Markdown 转换。

RAG 和 Agent 文档管道并不喜欢原始 PDF。后续系统更常消费的是结构更清楚的文本，Markdown 在段落、标题、列表和表格表达上更容易进入切分与检索流程。firecrawl/pdf-inspector 直接面向 Markdown 转换，说明项目不是只服务单次查看，而是服务下游自动化管道。

第四个关键点，是多语言绑定。

项目提供 Python、Node 和 WASM 绑定，这对文档处理场景很重要。Python 常见于数据处理和 RAG 实验，Node 常见于 Web 服务和工具链，WASM 则方便把能力放进更灵活的运行环境。Rust 核心能力通过这些绑定扩散出去，降低了开发者接入成本。

基准测试表现也要放在一起看。

项目资料提到，firecrawl/pdf-inspector 在阅读顺序与表格提取上领先同类本地引擎。阅读顺序和表格提取不是边角能力，很多 PDF 解析失败正是失败在这里。段落顺序乱了，表格结构散了，后面的 RAG 检索就会拿到难以理解的碎片。

这里还有一个容易忽略的工程收益。

分类、提取和 Markdown 转换如果分散在不同组件里，文档管道会出现很多胶水代码。一个环节判断文件类型，一个环节抽文本，一个环节再整理格式，错误和延迟都会被分散到多个位置。firecrawl/pdf-inspector 把这些入口动作集中到同一套库里，开发者更容易把 PDF 处理作为一段明确的前置流程，而不是临时拼接的导入脚本。

我更关心 firecrawl/pdf-inspector 背后的方向。

过去很多人把 PDF 处理当成文档导入前的一步杂活，能读出文字就算完成。现在 RAG 和 Agent 工作流把这个问题放大了，因为文档入口的质量会直接影响知识库、问答、摘要、引用和任务执行。入口越混乱，后面越难靠模型补回来。

PDF 分类是一个很小但很硬的判断。

一个文件是文本型还是扫描型，决定后续要不要 OCR、是否能快速提取、能不能直接转 Markdown，也决定整个管道的成本和延迟。firecrawl/pdf-inspector 把这个判断本地化、极速化，意义不在于概念新，而在于位置非常靠前。

对做知识库的人来说，这类能力能减少导入时的不确定性。

很多团队最怕的不是单个 PDF 解析失败，而是一批文件混在一起时，不知道哪些该走快路径，哪些该走重路径。分类和路由稳定以后，系统可以把资源用在真正需要 OCR 的文件上，而不是让所有文档为最差情况买单。

对做 Agent 工作流的人来说，文档入口更像基础设施。

Agent 要读文档、查资料、生成报告、引用内容，前提是文档已经被整理成可用上下文。firecrawl/pdf-inspector 解决的不是 Agent 推理能力，而是让 PDF 先变成更可靠的输入。这个环节越早被处理好，后面越少出现看似是模型问题、实际是文档解析问题的故障。

Firecrawl 相关工作流也会需要这种前置能力。

网页抓取、文档导入和知识整理经常会在同一条链路里相遇。PDF 如果不能先被判断类型，后续系统就很难稳定决定要走快速提取、Markdown 转换，还是转给 OCR 链路。把这个判断放在本地库里，意味着文档入口可以更早给出确定信号。

这类项目也有清楚边界。

无 OCR 依赖并不等于扫描件可以被直接读懂，快速处理也主要对应文本型 PDF。firecrawl/pdf-inspector 更像文档管道入口的判断器和转换器，负责把能快速处理的文件快速处理，把不该走这条路的文件分出去。

RAG 和 Agent 文档系统接下来会越来越少依赖一条万能导入链路。

真正稳定的做法，是先判断文件类型，再选择路径。文本型 PDF 要快，扫描型 PDF 要识别出来，Markdown 要尽量保留阅读顺序和表格结构。firecrawl/pdf-inspector 适合放在这个入口位置，尤其适合已经有文档处理量、又不想把所有 PDF 都交给 OCR 的团队。

如果一个系统每天只处理少量人工挑选过的 PDF，这类基础设施可能感受不强。文件来源一旦变杂，数量一旦变多，PDF 入口就会从小工具变成质量阀门。firecrawl/pdf-inspector 的价值，就在这个阀门足够靠前，也足够快。

项目地址：https://github.com/firecrawl/pdf-inspector