Firecrawl pdf-inspector を開きました: PDF で Markdown ミリ秒、OCR はなし

ウェブサイトからデータを抽出するツールを作成する Y Combinator のスタートアップである Firecrawl は、pdf-inspector のソースを公開しました。これは、目の前にあるテキストが PDF かスキャンであるかをミリ秒単位で判断し、OCR をまったく含まずにテキスト文書を純粋な Markdown に変換する Rust ライブラリです。チームの推定によると、実際の問題の PDF の約 54% はテキストベースであり、遅くて高価な OCR を実行することにまったく意味がありません。

ニューラル ネットワーク PDF に契約書、報告書、本などを与えたことがある人なら、この感覚がわかるでしょう。ファイルは開いているように見えますが、そこに含まれるテキストはコピーされていないか、おかゆのようにコピーされています。古典的なパーサーは、テーブルで窒息するか、各ページを OCR まで実行して、数秒とお金を無駄にします。 pdf-inspector はまさにこの問題を解決します。まず、ファイルの種類をすばやく確認し、実際のスキャンである場合にのみ OCR を接続します。

最初に分類し、次に抽出する

1 回のパスで、ライブラリは 4 つのタイプ (TextBased、Scanned、ImageBased、または Mixed) のいずれかに PDF を割り当て、0 から 1 に加えてページ ルート (どれをテキストとして読み取るか、どれを OCR に送信するか) の信頼度を与えます。分類には 10 ～ 50 ミリ秒かかります。次に、テキスト ページの場合、座標、フォント、読み上げ順序を使用して抽出が行われ、見出し、リスト、表、リンクを含む出力が Markdown になります。

印象的な数字

opendataloader-bench では、200 個の PDF pdf-inspector のうちケース全体が 0.47 秒で逆アセンブルされました。比較: pymupdf4llm - 17 秒、markitdown - 16 秒。同時に、品質も最高です。全体スコアは 0.875 であるのに対し、pymupdf4llm では 0.735、markitdown では 0.589 です。テーブルの認識がはるかに優れています (0.401 および 0.273 に対して 0.814)。

彼には他に何ができるでしょうか？

新聞の複数段レイアウト、右から左へのテキスト、CID フォント、壊れたエンコードの検出。個別 - 選択的 OCR: スキャンした個々のページが PDF でスタックしている場合は、ドキュメント全体ではなく、OCR を介してローカルで、PP-OCRv6 Small を介してそれらのページのみを実行できます。

どこに問題があるのでしょうか？

正直に言うと、書類の実際のスキャンや写真には OCR が必要ですが、ここでは pdf インスペクターは魔法ではありません。必要のないものに OCR を費やさないだけです。数式やレイアウトがテキストと混在する複雑なレイアウトも機能します。これはライブラリであり、既製のサービスではありません。これを使用するには、少しコードを記述する必要があります。

Python、Node.js、ブラウザベースの WASM 用のバインディングがあり、同じ Rust パーサーがサーバーなしでブラウザで直接動作します。 GitHub 上のリポジトリには、すでに約 17,000 個のスターが付いています。ニューラル ネットワークで PDF を頻繁に使用する場合は、一見の価値があります。