Docling: An Efficient Open-Source Toolkit for AI-driven Document Conversion
| 項目 | 内容 |
|---|---|
| 論文ID | D04 |
| 区分・分類 | 業界資料・文書解析・表 |
| 著者・所属 | Nikolaos Livathinos, Christoph Auer, Maksym Lysak, Ahmed Nassar, Michele Dolfi, Panagiotis Vagenas, Cesar Berrospi, Matteo Omenetti, Kasper Dinkla, Yusik Kim, Shubham Gupta, Rafael Teixeira de Lima, Valery Weber, Lucas Morin, Ingmar Meijer, Viktor Kuropiatnyk, Peter W. J. Staar（IBM Research, Rüschlikon, Switzerland） |
| 発表先 | IBM Research（技術報告、arXiv） |
| 発表日 | 2025-01-27 |
| 引用数 | -（OpenAlex 2026-10-06時点） |
| 言語 | 英語 |
| URL | https://doi.org/10.48550/arXiv.2501.17887 |
| 論文/pdf/D04.pdf | |
| 読んだ範囲 | 全文 |
論文タイプ
新技術：OSSの文書変換ツールキット Docling（v2）の設計・構成と変換速度のベンチマークを示す技術報告。中核のAIモデル（レイアウト解析モデル、TableFormer）は同チームの既発表成果。
研究の目標
- 背景：PDF・Office・スキャン画像は形式がばらばらで標準化が弱く、印刷向けのため構造やメタデータが失われている。LLMやRAGの普及で、これらを機械処理できる統一形式に戻す必要性が高まった
- 既存の問題：商用ソフト・SaaS・VLM（GPT-4o、Claude、Gemini、LLaVA-next等）はライセンスや推論の費用がかかり、ローカルで動かしにくい。生成系モデルは原文に無い内容を出力する（ハルシネーション）おそれがある。OSSでPDF・Word・PowerPoint・画像・HTMLを扱えるツールは少なく、商用との機能・品質差が大きい
- 到達点：MIT ライセンスで、一般的なハードウェア上で完全にローカル実行でき、多様な形式を1つの構造化表現に変換するツールキットを提供する
技術的なやり方
構成は pipelines、parser backends、データモデル DoclingDocument の3つ。テキストはPDF内のテキスト情報かOCRから取り、AIモデルは構造の復元だけを担う（内容を生成しないので誤った内容が入らない）。
| 構成要素 | 内容 |
|---|---|
| DoclingDocument | Pydantic データモデル。Text・Tables・Pictures・Captions・Lists、セクションの階層、本文とヘッダー・フッター（furniture）の区別、bounding box、provenance（ページ番号・出所）を表現。JSONは可逆、Markdown・HTMLは不可逆の出力。chunker でRAG用のチャンクに分割 |
| Parser backends | PDF：qpdf ベースの自社製 docling-parse（既定）、代替に pypdfium。HTML：BeautifulSoup、Markdown：Marko、Word・PowerPoint・Excel：python-docx・python-pptx・openpyxl の拡張 |
| Pipelines | StandardPdfPipeline（PDF・画像）と SimplePipeline（Office・HTML・AsciiDoc）。サブクラス化でモデルの追加・差し替えが可能 |
| レイアウト解析モデル | RT-DETR 由来の物体検出器を DocLayNet と独自データで再学習。検出枠をPDFのテキストトークンと突き合わせ、段落・見出し・表・図などにまとめる |
| TableFormer | vision-transformer。表の画像から行・列の構造と、列見出し・行見出し・本体の区別を予測。予測結果をPDFのセルに戻すため言語に依存しない |
| OCR・統合 | OCRは EasyOCR（代替 Tesseract）。最後に docling-core で全ページの結果を統合し、読み順の補正や図とキャプションの対応付けを行う |
ベンチマーク：DocLayNet と CCpdf から作った89件のPDF（4008ページ、表1842、画像4676）で、Docling 2.5.2・Marker 0.3.10・MinerU 0.9.3・Unstructured 0.16.5 の変換速度を3環境（AWS EC2 g6.xlarge のCPU 8スレッド、同 Nvidia L4 GPU、MacBook Pro M3 Max）で比較。
結果
変換品質（精度）の数値は無く、速度のみ。
| 項目 | x86 CPU | M3 Max | L4 GPU |
|---|---|---|---|
| 1ページの変換時間（5%点／中央値／95%点） | 0.6／0.79／16.3 秒 | 0.26／0.32／6.48 秒 | 57／114／2081 ミリ秒 |
| 1ページ平均 | 3.1 秒 | 1.26 秒 | 481 ミリ秒 |
| EasyOCR（1ページ、OCR対象578ページ） | 13 秒 | 5 秒 | 1.6 秒 |
| レイアウトモデル（1ページ） | 633 ミリ秒 | 271 ミリ秒 | 44 ミリ秒 |
| TableFormer fast（1表） | 1.74 秒 | 704 ミリ秒 | 400 ミリ秒 |
| docling-parse（1ページ） | 81 ミリ秒 | 44 ミリ秒 | GPU非対応 |
- OCRを切ると所要時間がCPU・M3 Maxで60%、L4で50%減る。表構造認識を切るとCPU・M3 Maxで16%、L4で24%減る。両方切ると全環境で約75%減る
- 他ツール比較（秒／ページ）：CPUでは Docling 3.1（x86）・1.27（M3 Max）が最速、MinerU 3.3（x86）、Unstructured 4.2（x86）・2.7（M3 Max）、Marker 16超（x86）・4.2（M3 Max）。MinerU は M3 Max で一度も完走せず。L4 GPU では MinerU 0.21 が最速で、Docling 0.49、Marker 0.86。Unstructured はGPUで速くならない
- GitHubで1か月足らずで1万スター、2024年11月に世界のトレンド1位
限界・課題
- OCR（EasyOCR）はCPUでかなり遅く、パイプラインで最大の計算コスト
- GPUによる高速化の効果はモデルごとに差があり（L4はx86 CPU比でOCR 8倍、レイアウト14倍、表構造4.3倍）、最適化の余地がある
- 構造だけを復元する方式のため、数式や図など要素ごとに別々のモデルを維持する必要がある
- Markdown・HTMLへの出力は不可逆で、メタ情報をすべては保持できない。Word・HTMLは描画しないと要素の位置情報が得られない
- 今後の課題：図の分類・数式認識・コード認識のモデル追加と、DP-Bench・OmniDocBench 等を使ったOSSの品質評価フレームワークの構築（品質評価の結果は今後の更新で公開予定）
要点
PDF・Office・HTML等をローカルで1つの構造化表現（DoclingDocument）に変換する、MIT ライセンスのOSSツールキット。 テキストは生成せずPDFのテキスト情報かOCRから取り、AIモデルはレイアウトと表構造の復元だけに使うことで誤った内容の混入を避ける。 CPUでは比較したOSSツール中で最速だが、GPU環境では MinerU に及ばず、品質評価は未公表。