Kreuzberg v4.5、Rust-nativeで文書レイアウト抽出を高速化

r/LocalLLaMAの投稿は、クロール時点で50ポイント、21コメントだった。投稿によれば、KreuzbergはMITライセンスのopen-source document intelligence frameworkで、Rust実装を中心にPython、TypeScript/Node.js、PHP、Ruby、Java、C#、Go、Elixir、R、C、WASMを含む12言語向けbindingを提供する。88以上のformatからtext、structure、metadataを抽出し、OCRとembeddingsまで処理できることを基本機能としている。

v4.5の最大の変更点は、文書を単なるtext sourceではなく、layoutとtableを持つ構造化オブジェクトとして扱うようになったことだ。投稿では、DoclingのRT-DETR v2 layout model、いわゆるDocling HeronをRust-native pipelineに組み込んだと説明している。tableを含むページでは、検出領域を切り出してTATR(Table Transformer)を実行し、推定されたcell gridをPDF text positionと突き合わせてmarkdown tableを再構成する。

benchmarkの説明はかなり具体的だ。academic papers、government/legal docs、invoices、OCR scans、edge casesを含む171件のPDFで、KreuzbergはStructure F1 42.1%、Text F1 88.9%、平均処理時間1,032 ms/docを記録したという。比較対象として示されたDoclingは41.7%、86.7%、2,894 ms/docで、投稿の主張をそのまま受け取れば、品質は同等以上で平均2.8倍前後高速ということになる。

速度改善の理由として、Kreuzbergはnative text layerがあるPDFではpdfiumを使って文字単位の位置情報とfont metadataを保持し、text layerがない場合はTesseract OCRへ自動fallbackする。推論にはONNX Runtime、ページ並列化にはRayonを使う。さらにbroken font CMap tablesによる"co mputer"のような崩れを修正するpage-level respacingで、影響テスト文書のgarbled linesを406から0へ減らしたと説明している。multi-backend OCR、PaddleOCR v2の18,000+文字多言語モデル、extraction result cachingも追加された。

• binding: 12言語
• 対応format: 88+
• benchmark: 171 PDFs, 1,032 ms/doc, Structure F1 42.1%, Text F1 88.9%

このリリースが重要なのは、document AIが単なるOCR競争ではなく、layout understanding、table recovery、多言語fallback、運用効率を同時に求めるsystems problemになっているからだ。KreuzbergはそれをPython中心ではなくRust-nativeな配布形態で解こうとしている。すでにDoclingを使っているチームにとっても、v4.5は単なるwrapperではなく、実測比較に値するアップデートと言えそうだ。