docTR vs Docling on Receipts
シングルパス速度 vs ドキュメントパイプライン（2026）

Doclingとは何か（そして何でないか）：シングルパスOCRと解析パイプラインの比較

この2つのエンジンは、基本的なアーキテクチャの分岐点で正反対の立場にあります。その分岐点こそが、コードの違いやチューニングの違いではなく、このページ全体の主題です。docTRはシングルパスニューラルOCRエンジンです。検出段階でテキストのバウンディングボックスを特定し、認識段階でその中の文字を転写し、これらを1つのOCR予測器に統合して、フロントからバックへのフォワードパスで生のテキスト行を生成します。レイアウトモデルも、テーブルパーサーも、読み順の再構築もありません。印刷されたものが、認識器が読み取る順序でそのまま出力されます。DoclingはOCRエンジンでもビジョンランゲージモデルでもなく、ドキュメント解析パイプラインです。その技術レポート（アーキテクチャの文脈として引用されており、このページの数値の根拠ではありません）によると、ページごとに一連のモデル（レイアウト解析、テーブル検出、読み順推論）を段階的に実行し、それらを集約して中間ドキュメントオブジェクトを組み立ててからテキストを出力します。そのため、その出力にはdocTRの行にはない構造（ラベル、順序、ゾーン）が含まれます。

このメカニズムがベンチマークにとって重要な理由：Doclingのチェーン内の各段階モデルは、レイアウト構造を活用するために存在します。解析するテーブル、2段組のフォーム、語彙順ではない読み経路などです。プレーンな英語のレシートには、そのような構造はほとんどありません。単一カラム、少数のゾーン、ほぼ予測可能な上から下への経路、テーブルなし。段階的なメカニズムはすべてのページで実行されます（だから遅く、コストがかかるのです）が、活用する構造がないため、そのオーバーヘッドをより良いテキストに変換することはできません。このページは、まさにそのコストを切り出し、それが何をもたらすのか、もたらさないのかを示します。

文字精度：生テキストに対するパイプライン税

SROIE 2019では、生テキストの差は僅差ではありません：CER 0.1971（docTR）対 0.5909（Docling）— 3.0× のペナルティ — そしてWER 0.3199 対 0.7596。文字誤り率は、挿入・削除・置換を正解文字数で割った値です — CER 0.197 は100文字あたり約19.7文字の誤読を意味します。単語誤り率は同じ編集距離ロジックを単語単位で適用します。Doclingの0.5909は、基盤となる実行における8エンジン中7位で、Unlimited-OCR（0.6552、summary_metrics.csvのcer列、sroie_2019行）のみを上回ります — docTR対Surya2の兄弟比較では、docTRがこの同じベンチマークで最高の認識エンジン2つのうちの1つであることが示されており、このページは同じエンジンがテキスト精度テーブルの反対側にいるのは、認識エンジン群が弱いのではなく、パイプラインであることを示しています。

出典：summary_metrics.csv — cerおよびwer列、sroie_2019行。docTR cer 0.19707 / wer 0.31990；Docling cer 0.59092 / wer 0.75961。低いほど良い。エンジンあたり361サンプル；error_rateは両方とも0.0。

表：summary_metrics.csv — cer / wer / error_rate列、sroie_2019行。正確な値：docTR cer 0.19707 / wer 0.31990；Docling cer 0.59092 / wer 0.75961。DoclingのSROIE CERは、基盤となる実行の8エンジン中2番目に悪い値です（Unlimited-OCRの0.6552のみを上回る）— 生の文字精度は、パイプライン税が最初に現れる場所です。

逆転：正規表現によるフィールド抽出が結果を覆す

両エンジンのテキストを、SROIEの4つのレシートフィールド（会社名、日付、住所、合計金額）に対する同じ固定正規表現パターンでベンチマークします — 従来のOCR＋ルールベースのキー情報抽出（KIE）アプローチ — すると順位が逆転します：Doclingは0.2237のフィールドF1を達成し、docTRの0.0766に対して2.9倍の優位性を示します。これらはベンチマークのpostprocessed_sroie_receipt_regex_*メトリクスです：各エンジンのOCRテキストに適用される固定パターン — 両エンジンともネイティブの構造化出力ではなく後処理であり、Doclingのネイティブなドキュメントモデルはここでは評価されません。

フィールド値のF1は、抽出されたフィールド値の適合率と再現率の調和平均であり、正解データと比較します — 1.0はすべてのレシートフィールドが完全に復元されたことを意味し、0は何も抽出できなかったことを意味します。この逆転の背後にあるメカニズムは、CERの差を生んだのと同じアーキテクチャの違いが、逆方向に働いたものです：Doclingのドキュメントモデルはテキストを読み順に並べ替え、ラベルと値を関連付けるため、出力されるテキストは固定パターンが期待する形状により近くなります。一方、docTRのクリーンだが生の行テキスト — CERでは正確ですが、元の大文字小文字や区切り文字のノイズが残り、ラベルによる枠組みもありません — はパターンを打ち負かします。docTRの正規表現フィールドF1である0.0766は、基礎となる実行において、最良クラスのCERにもかかわらず8エンジン中で最悪です（summary_metrics.csvのfield_f1_regex列とcer列、すべてのsroie_2019行）。Doclingの0.2237は6番目です。精度ラダーの最上位で兄弟対決が文書化したのと同じ断絶（docTR vs Surya2）が、ここ最下位でも再発します：テキスト精度はフィールド精度ではない。

出典：field_method_comparison.csv — regex_field_value_f1 / llm_field_value_f1列、sroie_2019行（0–1の小数を%で表示）。LLM後処理：deepseek-v4-flash（llm_model列）。エンジンあたり361サンプル（llm_ok_count）。

表: field_method_comparison.csv — 正規表現列、sroie_2019 行。これらは postprocessed_sroie_receipt_regex_* メトリクスです。各エンジンのOCRテキストに固定パターンを適用したもので、ネイティブな構造化抽出ではありません。どちらのエンジンも、正規表現ではいずれのSROIEレシートでも4つのフィールドすべてを正確に取得できません（0.0000、CSVに記録された文字通りのゼロ）。docTRの正規表現フィールドF1 0.0766は、基盤となる実行における全8エンジン中で最低です。

LLM後処理でランキングが部分的に回復

両エンジンのテキストを構造化抽出プロンプト付きのLLM後処理（deepseek-v4-flash、温度0）に通すと、docTRが再びリードします：フィールドF1は0.6171対0.5685 — 0.049ポイントの差で、生のCERギャップに比べれば小さいものの、消えてはいません。よりクリーンなベーステキストからは回復可能なフィールド値が多く現れます。LLMはDoclingのレイアウトアーティファクトを部分的に補正しますが、完全に排除するわけではありません。

これは、全8エンジンのベンチマーク全体で見られるのと同じ収束帯です — LLM後処理は、文字形状のマッチングではなく意味（数値、日付、名前）を理解するため、健全なエンジン同士を引き寄せます — そして残差ギャップは重要です：docTRの0.6171は全8エンジン中で最高のLLMフィールドF1であり、Doclingの0.5685は6位です（field_method_comparison.csv llm_field_value_f1、すべてのsroie_2019行）。より厳しい基準 — 4つすべてのフィールドが完全に一致する文書 — では、両者は2.7倍に分かれます：docTR 0.1496 対 Docling 0.0554。このレバーには2つのコストが伴います：LLM呼び出しにより文書あたりの中央レイテンシがOCR時間に加えて約2.0–2.4秒増加し（docTRのテキストでは1,996.3 ms、Doclingでは2,365.1 ms — API起因で種類は同一）、また、エンジンが根本的に読み取れなかったテキストを救うことはできません。

表: field_method_comparison.csv — llm_*列、sroie_2019の行。LLMモデル: deepseek-v4-flash、温度0（llm_model列）。LLMレイテンシはAPIによるもので、エンジンのレイテンシ（summary_metrics.csvのlatency_p50_ms）とは別です。両方の行でllm_ok_countは361でした。

動作環境: 6.7倍のレイテンシ、7.9倍のスループット、8.3倍のコスト

パイプラインの負荷は、スループット計画が行われる場で最も顕著です。同じRTX 4090、同じ記録済みの$0.76/時間のレートにおいて、docTRは449.3ページ/分のスループット、108.7 ms p50のページあたりレイテンシ、1,000ページあたり$0.048のコストを維持します。一方Doclingは56.7ページ/分のスループット、732.0 ms p50のレイテンシ、1,000ページあたり$0.398のコストです。これは6.7倍のレイテンシ差、7.9倍のスループット差、そして8.3倍のコスト差に相当します。テール側はパイプラインにとってさらに悪く、p95は281.4 ms対3,239.8 msで11.5倍の差があります。これはDoclingの段階的モデルが、ページごとに最悪ケースのタイミングを累積させるためです。

コストは、ウォールクロック実行時間×RunPod RTX 4090レートとして計算され、モデル初期化を含みます。これは実際にGPU時間に対して支払う価格です。スループットは、同じ初期化を含むウォールクロックの1分あたりのページ数です。レイテンシp50/p95は、ウォームアップ後にスコアリングされた定常状態のページあたり推論時間です。docTRは、SROIEでの基礎となる実行における全8エンジンの中で最速かつ最安です。Doclingは56.7ページ/分、1,000ページあたり$0.398で、動作環境テーブルの下半分に位置します。

出典: summary_metrics.csv — latency_p50_ms / latency_p95_ms列、sroie_2019行。docTR p50 108.72 / p95 281.38、Docling p50 732.00 / p95 3239.79。定常状態のレイテンシ。

出典: summary_metrics.csv — cost_per_1000_pages列、sroie_2019行。docTR 0.0479、Docling 0.3978。コスト = ウォールクロック実行時間×$0.76/時間、価格は実行マニフェストにタイムスタンプ記録。docTRは基礎となる実行における全8エンジン中最安です。

表: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages、sroie_2019 行。両エンジンとも GPU（RTX 4090、マニフェストに記録された $0.76/hr の価格）を使用。コストにはモデル初期化を含む。正確な値: docTR p50 108.72 / p95 281.38 / 449.31 pg/min / $0.0479; Docling p50 732.00 / p95 3239.79 / 56.66 pg/min / $0.3978。

CORD（インドネシアのレシート）：両エンジンとも低下、docTRのLLMフィールド復元が依然リード

どちらのエンジンもインドネシアのレシートを主に学習していないため、CORD v2（100サンプル、ネストされたフィールド menu/sub_total/total）は言語横断的なストレステストとして機能し、両エンジンとも生のCERで低下します：0.9101（docTR）および0.9219（Docling）、これは言語不一致による差です。ベンチマークプロトコルに従い、CORDの数値はSROIE比較から隔離され、いかなるランキングにも統合されません。CORDの正解テキストには注釈構造が埋め込まれており、言語不一致に加えて全エンジンの生のCERを膨らませるためです。

フィールド指標では、Doclingの唯一の利点はほぼ消滅します：正規表現パターンを通じて、両エンジンともCORDフィールドをほとんど復元できません（docTR 0.0000 — CSV上の文字通りのゼロ — 対Doclingの0.0612。英語形式のパターンはインドネシア語テキスト用に書かれたものではないため）。LLM後処理は両側で言語ショックを吸収しますが、docTRがリードを維持します：フィールドF1 0.5500 対 0.4695。CORDは言語堅牢性の文脈としてここに記載されており、SROIEの数値と単一のリーダーボードに統合されることは意図的にありません。

表: summary_metrics.csv（cer / cost_per_1000_pages / pages_per_minute）および field_method_comparison.csv（フィールドF1）、cord_v2行。CORDの数値をSROIEのランキングに混ぜないでください：CORDのCERは、実際の言語不一致と正解データのアノテーション構造による膨張が組み合わさったものであり、正規表現パターンは英語形式向けに書かれています。docTRのCORD正規表現フィールドF1の0.0000は、CSVに記録された文字通りのゼロであり、欠損値ではありません。

いつ勝つのか：結果まとめ表

「優れている」はワークロード次第であり、この直接比較は軸を明確に分けています：通常の英語レシートでは、速度・コストの全軸と生テキスト軸のすべてでdocTRが有利です。標準の正規表現フィールド反転ではDoclingが有利。LLM後処理を加えると、0.049ポイント差でdocTRが再びわずかに優勢になります。そしてDoclingが存在する理由である機能（レイアウト、テーブル、読み順、長文書）は、ここでは測定されておらず、否定されたわけでもありません。

よくある質問

DoclingはdocTRよりもレシートの精度が高いですか？

いいえ — 生の文字精度では、doclingは3.0×悪いです: SROIE CER 0.5909 vs 0.1971、WER 0.7596 vs 0.3199（summary_metrics.csv、cer / wer、sroie_2019行）。Doclingが“勝っている”のは測定された1つの軸のみ：標準のregexフィールド抽出（0.2237 vs 0.0766フィールドF1）— そしてLLM後処理により、それはdocTRに戻ります（0.6171 vs 0.5685）。

生のテキストがはるかに悪いのに、なぜDoclingはregexでフィールドをより良く抽出するのですか？

2つの指標は異なるものを評価しており、Doclingの出力形式がたまたまパターンに適合するからです。Doclingのドキュメントパイプラインはテキストを読み順に再配置し、ラベルと値を関連付けるため、出力されるテキストは固定のregexパターンが期待する構造に近くなります。docTRは正確な生の行テキストを出力しますが、CERでは正確でもパターンを満たしません（0.0766フィールドF1、8エンジン中最悪、最高クラスのCERに対して）。これらはpostprocessed_sroie_receipt_regex_*スコア — 固定パターンを通したOCRテキスト — であり、ネイティブの構造化出力ではありません（field_method_comparison.csv、regex_field_value_f1、sroie_2019行）。このテキスト精度 ≠ フィールド精度の分離は、このベンチマーク全体に現れています。

Doclingはなぜ1ページあたりこれほど遅く、コストが高いのですか？

レイアウト分析、テーブル検出、読み順再構築、中間ドキュメントモデル — という段階的なドキュメントパイプラインを、構造を活用する余地のない単純なレシートでも毎ページ実行するからです。SROIEでは、その負担はp50で6.7×（108.7 vs 732.0 ms）、p95で11.5×、スループットは7.9×低く（449.3 vs 56.7ページ/分）、1,000ページあたりのコストは8.3×高くなります（$0.048 vs $0.398）— 同じGPU、同じプロトコル（summary_metrics.csv、sroie_2019行）。

LLM後処理でdocTRとDoclingの差は埋まりますか？

ほぼ埋まりますが、完全ではありません: SROIEにおけるLLM後処理後のフィールドF1は、docTRが0.6171、Doclingが0.5685で、docTRが0.049ポイントリードしています。これは、LLMがDoclingのレイアウトアーティファクトを部分的に補正してもなお維持される差です（field_method_comparison.csv、llm_field_value_f1、sroie_2019行）。収束にかかるコストは、文書あたり約2.0〜2.4秒の追加LLMレイテンシ中央値です（llm_median_latency_ms、同様の行）。

このベンチマークはDoclingが劣っていることを意味しますか？

いいえ — ここではDoclingの強みが測定されていないだけです。 Doclingは文書解析パイプラインであり、その価値提案（レイアウト構造、テーブル、読み順、フォーム、長文書）は、レシートのみのベンチマークではテストできないものです。このページが示すのはより限定的なことです：単純な単一ページのレシートでは、パイプラインのオーバーヘッドはコストに見合いません（CERで3.0倍悪化、コストで8.3倍）。そして、測定された唯一の利点（正規表現フィールドF1で2.9倍）は、LLM後処理によって打ち消されます。正直な捉え方は、評価ではなくスコープの問題です。

なぜ両エンジンはCORDレシートでこれほど低いスコアなのですか？

プロトコルがSROIEランキングから分離している2つの複合的な原因があります：真の言語ミスマッチ（両エンジンのトレーニング焦点外のインドネシア語レシート）と、CORDのグラウンドトゥルーステキスト内のアノテーション構造のインフレーションです — CERは0.9101（docTR）と0.9219（Docling）に達します（summary_metrics.csv、cer、cord_v2行）。LLM後処理下では、docTRのフィールドF1は0.5500を維持し、Doclingは0.4695です — SROIEの順序が圧縮された形です。CORD行は引用のみで、統合ランキングにはプールされません。

レシートパイプラインはdocTRとDoclingのどちらのエンジンを選ぶべきですか？

大量のレシートテキストを従量課金で処理する場合、docTRのエンベロープが決定的です：108.7 ms p50、449.3 pages/min、1,000ページあたり$0.048 — 基盤となる8エンジン実行の中で最速かつ最安のエンジンです。パイプラインが後処理なしで構造化テキストをそのまま利用する場合、Doclingの正規表現フィールドの優位性（0.2237 vs 0.0766）は実際の初期アドバンテージです。LLM後処理を設計に含める場合、docTRは0.049差で先行し、投入コストも低くなります。ワークロードがレイアウト中心のドキュメント — 表、フォーム、長文レポートの場合、このベンチマークは判断の根拠として適切ではありません。レシートのみを測定しているためです（制限事項を参照）。

このページの数値はどこから来ていますか？

すべての数値は、ファーストパーティベンチマークの公開CSVの行です — results/summary_metrics.csv（CER/WER、正規表現フィールドF1、レイテンシ、コスト、スループット）およびresults/field_method_comparison.csv（正規表現 vs LLM後処理、llm_model = deepseek-v4-flash）— はImageToTableai/benchmark-ocrでホストされており、実行ごとに環境フィンガープリント用の編集済みmanifest.jsonが1つ含まれています。データセット定義は、以下に引用するSROIE 2019およびCORDの論文に基づいています。

方法論と情報源

プロトコル

このページは、独立した再現可能なベンチマーク実行（公式ティア）の直接比較スライスを報告しています — 第三者による主張の調査ではなく、ベンダー比較ページでもありません。固定テスト分割のみ：SROIE 2019テスト（英語レシート361件、フラットフィールド：会社名/日付/住所/合計）およびCORD v2テスト（インドネシア語レシート100件、ネストフィールド：メニュー/小計/合計）。トレーニング分割は評価されていません。両エンジンは同じ画像、同じグラウンドトゥルース、同じ測定プロトコル（warm_then_scored：スコアリングパスの前に固定ウォームアップパスを実行するため、レイテンシ数値は定常状態）を使用しました。両実行とも両データセットでerror_rate 0.0で完了しました（summary_metrics.csvのerror_rate列）。基盤となる実行には合計8エンジンが含まれます。このページでは指定された2エンジンのみを比較し、他のエンジンはランキングの文脈としてのみ引用しています。完全な8エンジンの結果は、Traditional OCR vs Document Parsing VLMsで別途公開されています。

実行環境

• ハードウェア: 両エンジンとも同一のNVIDIA RTX 4090（24 GB）で実行。GPUコストはRunPodのオンデマンド料金 $0.76/hr で計算し、価格は各実行の編集済みマニフェストにタイムスタンプ付きで記録（2026年8月）。
• エンジン: 追加調整なしの標準構成。バージョン固定: docTR v1.0.1（シングルパスニューラルOCR — 検出ステージと認識ステージを1つのOCR予測器に統合、GPU）および Docling 2.119.0（ドキュメント解析パイプライン — レイアウト解析、テーブル検出、読み順再構築をOCRコア周辺で段階的に実行、GPU）— 公開リポジトリのモデル表（README.md）と実行マニフェストに基づく。
• LLM後処理: deepseek-v4-flashをAPI経由で温度0に設定し、決定的な出力を生成（field_method_comparison.csvのllm_model列）。両エンジンの全LLMフィールド行に使用した唯一のモデル。
• コスト基準: ウォールクロック実行時間 × $0.76/hr、モデル初期化を含む — バッチ処理によりページあたりコストが低下。
• フィールド後処理: SROIE正規表現フィールド指標は postprocessed_sroie_receipt_regex_*（field_method_comparison.csvのregex_*列）— 固定パターンセットによりOCR テキストから抽出したフィールド。OCR + 下流抽出を測定し、いずれかのモデルによるネイティブ構造化出力は対象外。LLM_*列はOCRテキスト + LLM抽出を測定。2つのパイプラインは決して混在せず、Doclingのネイティブドキュメントモデルはこのベンチマークの採点対象外。

指標の定義

• CER（文字誤り率）: OCRテキストと正解データ間の編集距離（挿入 + 削除 + 置換）を正解文字数で除算。低いほど良好。
• WER（単語誤り率）: 同じ編集距離計算を単語単位で実施。
• フィールド値F1（正規表現）: OCRテキスト上の固定正規表現パターンによる抽出フィールド値の適合率/再現率調和平均（従来型OCR + ルールベースKIEパイプライン）。列: regex_field_value_f1。スコア0はフィールド値が一切回収されなかったことを意味。
• フィールド値F1（LLM）: LLM後処理の出力に対する同一指標（OCRテキスト → deepseek-v4-flash → フィールド）。列: llm_field_value_f1。 2つのパイプラインは異なり、決して混在しない。
• ドキュメントフィールド完全一致: すべての対象フィールドが完全一致したドキュメントの割合 — フィールド別F1よりもはるかに厳しい基準。
• レイテンシp50/p95 & ページ/分: 定常状態のページあたり推論時間（ウォームアップ後に採点、モデル読み込みは除外）と、モデル初期化を含むウォールクロックスループット。異なるクロックを測定。
• 1,000ページあたりコスト: 記録された$0.76/hrレートでの1,000ページ分の請求GPU時間（モデル初期化を含む）。

ソース一覧

1. summary_metrics.csv (GitHub raw)。16行 = 8モデル × 2データセット。列: model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate。 このページのすべてのCER/WER、レイテンシ、コスト、スループット数値は、ここに記載されているdoctrおよびdoclingの行に由来します。
2. field_method_comparison.csv (GitHub raw)。16行。列: model, dataset, llm_model (= deepseek-v4-flash)、regex/llmフィールド値の精度とF1、document-fields-exact、llm_median_latency_ms、トークン数。 すべてのregex/LLMフィールドF1数値は、ここに記載されているdoctrおよびdoclingの行（およびランキングコンテキストにおける全8つのsroie_2019行）に由来します。
3. ImageToTableai/benchmark-ocrリポジトリ。結果CSV、編集済み実行マニフェスト、固定プロトコル、再現用のデータセットサンプルリスト（固定テスト分割）をホストする公開リポジトリ。
4. results/manifests/ (GitHub)。公開された各実行（16実行）につき1つの編集済みmanifest.json。モデルバージョン、GPU/ドライバ、torch/CUDA/Pythonバージョン、価格タイムスタンプ付きコストメタデータ、アーティファクトハッシュを含む。
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019)。SROIE 2019データセットの定義、タスク構造、ライセンス（CC-BY-4.0）。
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020)。CORD v2データセットの定義、ネストされたフィールドスキーマ、ライセンス（CC-BY-4.0）。
7. Auer et al., "Docling Technical Report" (2024)。アーキテクチャの背景のみ — Doclingの段階的パイプライン（レイアウト解析、テーブル検出、読み順推論、ドキュメント組み立て）を説明。 このページのベンチマーク数値はここから取得されていません。

制限事項

• ドキュメント範囲 — レシートのみ: SROIE + CORD。ここでは、Docling の価値提案を定義するレイアウト/テーブル/読み順/長文書処理は測定されていません。これらの機能は範囲外であり、否定されたわけではありません。このページを「Docling は劣っている」という結論に使用しないでください。このページの結論は、単純な単一ページのレシートでは、パイプラインのオーバーヘッドがその価値に見合わないということです。
• サンプルサイズ: 英語361件 + インドネシア語100件のレシート。フィールド F1 と CER はコーパスに依存します。ここで記録された差（CER 3.0倍、p50 6.7倍、コスト 8.3倍）はノイズ帯域をはるかに超えていますが、1%単位の差はノイズとして扱うべきであり、工学的な真実ではありません。
• 単一 GPU ティアと単一価格: すべての数値は、$0.76/時間の単一 RTX 4090 からのものであり、価格は実行マニフェストで2026年8月のタイムスタンプが付けられています。他の GPU、マルチ GPU サービス、バッチスケジューリング、または価格変更により、レイテンシ、スループット、コストが変化します — 予算を立てる前に、現在のレートでコストを再計算してください。
• 単一 LLM ポストプロセッサ: すべての LLM 行は、温度0の deepseek-v4-flash を使用しています。異なる LLM は、絶対的なフィールド F1 を変化させます。0.049ポイントの docTR リードは、わずかに変動する可能性があります。LLM レイテンシ（SROIE で中央値約1,996〜2,365 ms、field_method_comparison.csv llm_median_latency_ms）は API によるものであり、いずれのエンジン自体のレイテンシの一部ではありません。
• 正規表現チューニング: パターンセットは、データセットごとに一度だけ作成されました。フォーマットごとに高度にチューニングされたパターンライブラリは、独自のレイアウトでより高いスコアを獲得できる可能性があります — ただし、LLM が排除するメンテナンスコストがかかります。Docling の 2.9倍の正規表現エッジは、この単一の固定パターンセットに対して測定されています。
• Docling のネイティブ出力はスコアリングされていません: Docling は構造化ドキュメントモデルを出力しますが、ベンチマークはテキストとポストプロセッサをスコアリングし、ネイティブの構造化出力はスコアリングしません。Docling のネイティブフィールドをスコアリングするベンチマークバリアントは異なる実験になります。このページでは試みていません。
• CORD CER はモデル品質の読み取りではありません: CORD のグラウンドトゥルースには注釈構造が埋め込まれており、どちらのエンジンも主にインドネシア語でトレーニングされていません。CORD CER（約0.91〜0.92）は、言語ミスマッチ + グラウンドトゥルースのインフレを反映しています。CORD の行はフレーミング付きで引用され、SROIE ランキングに統合されることはありません（プロトコルルール）。
• バージョン固定: 結果は、docTR v1.0.1 と Docling 2.119.0（2026年8月）に適用されます。どちらかのエンジンの新しいリリースにより、このページのすべての数値が変わる可能性があります。

関連リファレンス: docTR vs Surya2 レシートベンチマーク · PaddleOCR vs EasyOCR レシートベンチマーク · 従来のOCR vs ドキュメント解析VLM · ルールベース抽出 vs LLM抽出 · フィールドレベル vs 文字レベル精度

関連記事: AIと従来のOCRの精度ギャップ · AI画像抽出と従来のOCRの比較 · AIドキュメント抽出の価格（2026年）