如果你的團隊在搭 RAG 系統或自動化文件流程，一定遇過這個斷點：網頁內容好抓，但合約、報告、發票、使用者上傳的檔案都躺在硬碟裡，格式混亂，要先寫一堆解析與清理程式才能餵給 LLM。Firecrawl 在 4 月 28 日推出的 /parse 端點補上這一塊：直接上傳本地檔案，拿回與網頁抓取完全一致的乾淨輸出——PDF 保留閱讀順序與表格、Word 濾掉 XML 噪音、試算表變成整齊的 tabular Markdown，甚至可以在同一呼叫裡要求摘要或結構化 JSON 抽取。
一個 API，同時覆蓋網頁與本地文件
/parse 的定位是 /scrape 的本地檔案版：兩者走同一套解析引擎，輸出格式一致，這代表你的下游管線（清洗、切塊、入向量庫）只需要寫一次。官方在公告裡把場景說得很直白——很多需要處理的文件（合約、報告、發票、上傳檔案）存在磁碟上而不是網路上，過去這條路要自己接 OCR 或文件庫，現在與網頁抓取收斂到同一個 API。
支援格式：PDF、DOCX、DOC、ODT、RTF、XLSX、XLS、HTML，單檔上限 50 MB。不在清單上的格式會直接回 UNSUPPORTED_FILE_TYPE 錯誤，不會猜。對既有 /scrape 使用者來說，遷移成本近乎零：差別只在檔案來源從 URL 換成上傳，參數與回應結構照舊。
Rust 引擎：不是更快地跑 OCR，而是少跑 OCR
/parse 底層是 Rust 解析引擎，平均每頁處理低於 400 毫秒。真正的設計重點是它不把每頁都丟給 OCR，而是先分類再處理：
- 純文字頁走原生抽取：開源 Rust 函式庫
pdf-inspector直接讀 PDF 內部結構（字型、文字運算子、圖片覆蓋率），毫秒級取出文字，完全不需要渲染。 - GPU 只用在需要的地方：掃描頁與圖片為主的頁面才送到 GPU 叢集，而且是 lane-based 隔離——一份 200 頁的報告不會拖慢別人單頁發票的處理。
- 版面感知準確度：神經版面模型分別偵測表格、公式、文字區塊與標題，再對各區域調參——表格拿到更高的 token 預算、公式保留為 LaTeX、多欄文件的閱讀順序由模型預測。
這種分層策略讓速度與成本務實平衡：純文字頁的成本壓在原生抽取，昂貴的 GPU 只留給真正需要它的掃描頁。
一次呼叫：Markdown 與結構化欄位同時拿
實務上最有感的是 schema 抽取可以內嵌在上傳呼叫裡。以合約為例，連同檔案一起傳入 JSON schema：
import requests
import json
with open("contract.pdf", "rb") as f:
response = requests.post(
"https://api.firecrawl.dev/v2/parse",
headers={"Authorization": "Bearer fc-YOUR_API_KEY"},
files={"file": f},
data={
"options": json.dumps({
"formats": ["markdown", "json"],
"json": {
"schema": {
"type": "object",
"properties": {
"parties": {"type": "array", "items": {"type": "string"}},
"effective_date": {"type": "string"},
"total_value": {"type": "string"}
}
}
}
})
}
)
data = response.json()["data"]
print(data["markdown"])
print(data["json"])回應裡 markdown 是保留表格與閱讀順序的全文，json 則是按 schema 抽出的 typed 欄位（當事人、生效日、總額這種）。一次呼叫拿兩種輸出，不需要再寫第二段解析。對 RAG 場景，這一步出來的結果就是 embedding-ready：結構保留、表格完整、必要時附摘要，切塊後直接進向量庫。
計費、快取與掃描品質：三個要先知道的限制
官方公告也把限制攤開來講。第一，每次呼叫都重新解析：結果不快取，同一檔案重複上傳會重複計費；計費模式與 /scrape 相同——一次呼叫，加上你要求的 LLM 格式（如 JSON 抽取）。第二，掃描 PDF 的品質上限就是掃描品質：乾淨的掃描解析乾淨，低解析度或手寫內容輸出品質就會下降，因為這類頁面終究要走 OCR。第三，固定格式與大小上限：50 MB、八種格式，沒有灰色地帶。
另外一個合規相關的細節：Enterprise 方案可開啟 Zero Data Retention（ZDR），確保解析輸出不落地儲存——對處理合約、醫療記錄或內部報告的團隊，這是把文件管線交给第三方服務前的必要檢查項。
對 builder 的實際意義
/parse 目前對所有 Firecrawl API 使用者開放。兩個最直接的落地場景：
- 應用內的檔案上傳環節：使用者丟 PDF 或 DOCX 進你的產品，一次呼叫變成 Markdown 加結構化欄位，後續無論是進向量庫、觸發 workflow 或寫入資料庫，都是同一種格式。
- 統一文件管線：Email 附件、下載的報表、網頁內容、使用者上傳——四種來源全走 Firecrawl，輸出一致，少維護一套自製解析器。
導入建議也很簡單：先拿你實際會遇到的一批文件（尤其含掃描件與多欄表格的）跑一輪，確認輸出品質；掃描品質與版面複雜度是結果的最大變因，實測永遠比規格表準。如果工作流程會反覆處理同一批檔案，記得把「不快取、每次計費」算進成本模型——考慮在自己這層快取解析結果，讓同一份未變動的文件重複處理時不再付費，這是官方計費設計下最直接的成本槓桿。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。