企业处理的文档中,90%根本不在网上。合同、季度报告、发票、用户上传的PDF — 全部躺在硬盘里,而它们的处理链路一直是独立的另一条流水线。
Firecrawl 在 4月14日 推出 Fire-PDF,14天后又在 4月28日 上线了 /parse 端点,这种割裂就此结束。网页抓取(Web Scrape)与本地文件首次共用同一个引擎。
为什么要把这两个一起看?
Firecrawl 4月份发布的两个版本,如果分开看,意义只剩一半。
4月14日 — Fire-PDF。 基于 Rust 的 PDF 解析器。相比之前的流水线,平均每页处理时间低于400ms,速度提升3.5~5.7倍。关键技巧在于:并不把所有页面都丢给 GPU。开源的 pdf-inspector 在毫秒级把页面分类为文本型/扫描型,文本页走原生(native)抽取,只有扫描/图像页才被送到 GPU 版面模型 + OCR 。
4月28日 — /parse 端点。 把同一个引擎直接用在本地文件上的入口。通过 multipart/form-data 上传文件字节,就能一次性拿到 Markdown、JSON、摘要、结构化抽取。支持的格式有 PDF、DOCX、DOC、ODT、RTF、XLSX、XLS、HTML — 单文件最大 50MB 。
两者合在一起,意思很简单。网页和企业内部文件,首次进入同一条 RAG 流水线。之前的格局是:网页用 Firecrawl,PDF 用 PyMuPDF/Unstructured,扫描件用 Tesseract/Textract — 三股分叉。输出格式不一,表格/公式处理质量不一,计费结构也不一。
之前的PDF流水线为什么那么贵?
Fire-PDF 标榜的5倍速度不是营销话术,有两个原因。
- 原生抽取优先 — 文本型页面根本不经过 GPU。
pdf-inspector不渲染文档,直接读 PDF 内部结构(字体、文本 operator、图像覆盖率),在毫秒级判定后直接抽出文本。 - 基于 lane 的 GPU 路由 — 只把需要 GPU 的页面送进去,而且按文档大小分隔 lane。即使有200页报告进来,1页发票的处理 latency 也不会被拖累。
- 区域调优 OCR — 把表格、公式、文本块识别为独立 region,每种用不同的 token 预算和 prompt。表格最多让出25秒,公式以 LaTeX 保留,文本则切成12秒·256 token,优先效率。
想象一下金融报告这种混合(mixed)文档,差异就很清楚了。如果150页是文本型,只有60页是扫描件,以前是把全部210页都跑 OCR。Fire-PDF 只把60页送上 GPU。速度和成本几乎按比例同步降低。
那到底有什么不同?
比成本更大的变化是流水线的简化。企业运行 RAG/智能体(Agent)时,过去通常是这种格局。
| 处理对象 | 之前 — 分裂的技术栈 | 之后 — Firecrawl 统一 |
|---|---|---|
| 网页 | Firecrawl /scrape |
/scrape + Lockdown 选项 |
| 网页上的 PDF/DOCX | 下载 → 单独的解析器 | /scrape 扔个 URL 就自动识别 → 交给 Fire-PDF 处理 |
| 本地文件 / 用户上传 | PyMuPDF + Unstructured + Tesseract 组合 | 一次 /parse 文件上传搞定 |
| 结构化抽取(合同方、发票合计) | 解析 → LLM 调用 → JSON 规范化(三步) | 调用 /parse 时一并传 schema(一步) |
| 输出格式 | 每个工具不同 — 必须后处理 | 全部统一为 Markdown / JSON |
| 敏感文档(合同·医疗) | 自建基础设施 + 单独安全审查 | Enterprise ZDR — 响应后立即销毁 |
从运维过 RAG 流水线的角度看,表格最后两行才是真正的价值。把「解析 → LLM 调用 → JSON 规范化」压成一步,不只是减少几行代码,而是让错误面收缩到原来的 1/3。每个中间步骤的重试/降级/校验逻辑都消失了。
/parse 每次调用都会重新解析 — 没有缓存。同一个文件多次上传会被重复计费。如果你的服务接受用户上传,在前面加一层基于文件 hash 的自建缓存层是合理做法。
上手指南
- 第1步 — 先决定分支
公开的网页 URL 用/scrape,本地文件或登录后才能拿到的文件用/parse。Firecrawl 官方指南也是从这个分支开始的 。 - 第2步 — 明确 PDF 模式
扫描件多就用parsers: [{type:"pdf", mode:"ocr"}]。文本型 PDF 用mode:"fast"。混合型默认auto即可。 - 第3步 — 把 schema 一起传过去
合同、发票这种字段固定的场景,在formats里一并塞{type:"json", schema:{...}}。后续的一次 LLM 调用就省掉了。 - 第4步 — 大 PDF 用 maxPages 限制
真正需要整本200页报告的场景很少。设个maxPages: 50这样的上限,把成本和延迟绑住。同时把 timeout 也调高(默认30秒 → 最多5分钟)。 - 第5步 — 敏感文档用 ZDR 套餐隔离
合同、医疗、内部报告用开了 ZDR 的 Enterprise 密钥调用,普通 RAG 用标准密钥分开。数据留存策略按密钥分割。
常见问题
已经在用 Unstructured.io 或 LlamaParse,值得切换吗?
速度和成本上 Fire-PDF 占优,但坦白说答案是「现有技术栈没坏就别动」。真正切换的价值在于 网页抓取和文件解析共用同一个引擎 这件事。如果你的 RAG/智能体同时用到网页数据,输出格式、计费、SDK 全部统一带来的运维简化收益很大。如果只是处理文件的工作流,迁移的优先级不高。
Fire-PDF 在表格/公式处理上,质量到底提升多少?
Firecrawl 没有公开正式的精度基准,但结构本身就不一样 — 表格让出最多25秒的 token 预算,公式用专门的 LaTeX 保留 prompt,多栏阅读顺序由神经模型预测、XY-cut 作为 fallback 。学术论文、金融报告、法律文书这类「过去 OCR 把表格搅乱所以没法用」的文档,是第一波受益领域。
有50MB限制,大 PDF 怎么办?
有两种模式。(1) 在客户端把 PDF 按页拆分(比如 PyPDF2 split),再并行调 /parse — 原则上是一次一个文件,没有 batch upload 。(2) 用 maxPages 选项只抽前 N 页 — 报告摘要、元信息抽取的场景这就够了。几百MB的单个PDF,基本只能走方案(1)。
能和 Lockdown Mode 一起用吗?
目前 Lockdown 只对 /scrape 生效。/parse 本身没有出站(outbound)请求(直接接收文件字节),所以像 Lockdown 这种 cache-only 保护没有意义。不过通过 ZDR 选项 可以做到响应后立即销毁数据,成为安全工作流的另一层。两个能力堵的是不同的威胁模型 — Lockdown 防的是「出站泄露的信息」,ZDR 防的是「留在供应商那里的信息」。
深入了解
Fire-PDF launch (Eric Ciarla, 4/14) 把 Rust 引擎的5阶段流水线和 pdf-inspector 分类技巧讲得最详细的一手资料。表格、公式、多栏处理的细节都有 firecrawl.dev
Introducing /parse (Eric Ciarla, 4/28) 端点发布公告。简短地讲了代码示例(Python)、RAG 接入模式以及 ZDR 应用场景 firecrawl.dev
/parse 官方文档 一页讲清选项、PDF 模式、结构化 JSON、限制条件。开始用之前必看的 reference docs.firecrawl.dev
PDF Parser v2(前作) Fire-PDF 上一代——PDF Parser v2 的发布背景。能看清楚是哪些限制让团队决定用 Rust 推倒重来 firecrawl.dev
