docTR vs Docling：レシートOCR
シングルパス速度 vs ドキュメントパイプライン（2026）

Doclingとは（そしてそうでないこと）：シングルパスOCR vs パーサーパイプライン

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）は、正解文字数に対する挿入、削除、置換の割合を測定します — CERが0.197ということは、100文字あたり約19.7文字の誤読を意味します。単語誤り率（WER）は、単語粒度で同じ編集距離ロジックを適用します。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にのみ先行） — 生文字精度は、パイプライン税が最初に現れる場所です。

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

4つのSROIEレシートフィールド（会社名、日付、住所、合計）において、同じ固定正規表現パターンで両エンジンのテキストをベンチマークします。これは従来の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後処理器（temperature 0のdeepseek-v4-flash）に渡すと、docTRがリードを奪い返します。フィールドF1は0.6171対0.5685 — 0.049ポイントの差。生のCER差と比較すると小さいですが、消えてはいません。よりクリーンなベーステキストは、回復可能なフィールド値をより多く浮き彫りにします。LLMはDoclingのレイアウトアーティファクトを部分的に補償しますが、完全には除去しません。

これは、全8エンジンのベンチマーク全体で見られる収束帯と同じです。LLM後処理は、文字形状の照合ではなくセマンティクス（数値、日付、名前）を理解するため、健全なエンジンを引き寄せます。そして、残差の差は重要です。docTRの0.6171は、全8エンジンの中で最高のLLMフィールドF1であり、Doclingの0.6585は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（temperature 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/hrの料金で、docTRは449.3ページ/分を維持し、1ページあたり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料金（$0.76/hour、実行マニフェストにタイムスタンプ付き）で計算され、モデル初期化を含みます。これは、GPU時間に対して実際に支払う金額です。スループットは、同じ初期化を含む壁時計のページ/分です。レイテンシp50/p95は、ウォーム後にスコアリングされた定常状態の1ページあたり推論時間（モデル読み込みは除外）です。docTRは、SROIEの基本実行にある8つのエンジンの中で最も高速で最も安価なエンジンです。Doclingは、56.7ページ/分、1,000ページあたり$0.398で、動作エンベロープ表（summary_metrics.csv、latency_p50_ms / pages_per_minute / cost_per_1000_pages、すべてのsroie_2019行）の下半分に位置します。

出典：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。定常状態レイテンシ（warm_then_scored測定モード、モデル読み込みは除外）。

出典：summary_metrics.csv — cost_per_1000_pages列、sroie_2019行。docTR 0.0479、Docling 0.3978。コスト = 壁時計実行時間 × $0.76/hr（モデル初期化を含む、実行マニフェストにタイムスタンプ付き、2026年8月）。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 (field F1)、cord_v2 行。CORD の数値を SROIE のランキングに統合しないでください: CORD の CER は、正解データにおける言語の不一致とアノテーション構造による膨張を組み合わせたものであり、正規表現パターンは英語のフォーマット用に作成されています。docTR の CORD 正規表現 field F1 は 0.0000 で、CSV に記録された文字通りのゼロであり、欠損値ではありません。

Who Wins When: The Recap Grid

“Better” はワークロードに依存し、このヘッド・トゥ・ヘッド比較は軸を明確に分割しています: 通常の英語レシートでは、すべての速度/コスト軸と生テキスト軸で docTR が有利です。箱から出してすぐに使える正規表現のフィールド反転では Docling が有利です。LLM ポストプロセッサーにより、docTR が 0.049 ポイントの優位に立ちます。そして、Docling が存在する理由であるレイアウト、テーブル、読取順序、長文書といった機能は、ここでは測定されておらず、否定されたわけでもありません。

よくある質問

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

いいえ — 生の文字精度では、doclingは3.0倍低いです：SROIE CER 0.5909 対 0.1971、WER 0.7596 対 0.3199（summary_metrics.csv、cer / wer、sroie_2019行）。Doclingが「勝つ」のは測定軸の1つだけです：箱から出して使える正規表現によるフィールド抽出（0.2237 対 0.0766 フィールドF1）— そしてLLMポストプロセッサがそれをdocTRに引き戻します（0.6171 対 0.5685）。

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

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

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

ページごとに段階的なドキュメントパイプライン — レイアウト分析、テーブル検出、読み取り順序の再構成、中間ドキュメントモデル — を実行するためです。たとえそのページが構造を活用できないプレーンなレシートであってもです。SROIEでは、このコストはp50で6.7倍（108.7 対 732.0 ms）、p95で11.5倍、スループットが7.9倍低い（449.3 対 56.7 ページ/分）、1,000ページあたりのコストが8.3倍高い（$0.048 対 $0.398）と測定されています — 同じGPU、同じプロトコル（summary_metrics.csv、sroie_2019行）。

LLMポストプロセッサーはdocTRとDoclingの差を埋めますか？

ほぼ、しかし完全には：LLMでポストプロセスされたフィールドF1は、SROIEにおいてdocTRが0.6171、Doclingが0.5685と、docTRが0.049ポイントのリードを保っています。これは、Doclingのレイアウトアーティファクトに対するLLMの部分的な補正を生き残っています（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レシートでそれほど低いスコアを取るのですか？

2つの複合的な原因が、プロトコルによってSROIEランキングから分離されています：言語の不一致（インドネシアのレシートが両エンジンの訓練焦点の外にあること）と、CORDのグランドトゥルーステキスト内のアノテーション構造の膨張です — CERはdocTRが0.9101、Doclingが0.9219となります（summary_metrics.csv、cer、cord_v2行）。LLMポストプロセッサーの下では、docTRのフィールドF1は0.5500を維持し、Doclingの0.4695に対し、SROIEの順序が圧縮されます。CORD行は引用され、統合ランキングにプールされることはありません。

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

コスト課金方式の大量レシートテキストの場合、docTRの性能は圧倒的です。p50レイテンシ108.7ms、スループット449.3ページ/分、1,000ページあたり$0.048 — 8つのエンジンの総合ベンチマークで最も高速かつ低コストです。パイプラインが後処理なしで箱から出して使える構造化テキストを消費するなら、Doclingの正規表現フィールド精度（0.2237対0.0766）は実質的な初期優位性です。LLMによる後処理を設計に含める場合、docTRは0.049ポイントリードを維持し、入力コストも安価です。ワークロードがレイアウト中心の文書 — テーブル、フォーム、長文レポート — である場合、このベンチマークは判断のための適切な根拠ではありません。これはレシートのみを測定しています（制約事項を参照）。

このページの数値はどこから来たものですか？

すべての数値は、一次ベンチマークの公開CSV — results/summary_metrics.csv（CER/WER、正規表現フィールドF1、レイテンシ、コスト、スループット）およびresults/field_method_comparison.csv（正規表現対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経由で使用。決定論的な出力のためにtemperature 0を設定（field_method_comparison.csvのllm_modelカラム）。両エンジンの全LLMフィールド行で使用された単一モデル。
• コスト基準: 実行時間 × $0.76/hr（モデル初期化を含む）— バッチ処理により1ページあたりのコストが低減。
• フィールド後処理: 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はフィールド値が1つも復元されなかったことを意味する。
• フィールド値F1（LLM）: LLM後処理出力（OCRテキスト → deepseek-v4-flash → フィールド）に対する同一指標。カラム：llm_field_value_f1。2つのパイプラインは異なり、混合されない。
• ドキュメントフィールド完全一致: すべての対象フィールドが完全に一致したドキュメントの割合 — フィールドごとのF1よりもはるかに厳しい基準。
• レイテンシ p50/p95 ＆ ページ/分: 安定状態の1ページあたり推論時間（ウォーム後にスコアリング、モデルロードを除く）およびモデル初期化を含む実行時間ベースのスループット。異なるクロックを測定。
• 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 field-value accuracy and F1, document-fields-exact, llm_median_latency_ms, token counts。すべてのregex/LLM フィールドF1数値は、このファイルのdoctrおよびdocling行（およびランキングコンテキストのすべての8つのsroie_2019行）に由来しています。
3. ImageToTableai/benchmark-ocr リポジトリ。結果CSV、編集済みランマニフェスト、固定プロトコル、および再現用のデータセットサンプルリスト（固定テスト分割）をホストするパブリックリポジトリ。
4. results/manifests/ (GitHub)。公開された各ラン（16ラン）に対し、モデルバージョン、GPU/ドライバー、torch/CUDA/Pythonバージョン、価格タイムスタンプ付きコストメタデータ、アーティファクトハッシュを含む編集済みmanifest.jsonが1つ。
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ティアと単一価格： すべての数値は、ランマニフェストに記載の2026年8月時点の価格である、1時間$0.76のRTX 4090 1台から得られたものです。他のGPU、マルチGPUサービス、バッチスケジューリング、または価格変動は、レイテンシ、スループット、コストを変動させます — 予算策定前に、現在のレートでコストを再計算してください。
• 単一LLMポストプロセッサー： すべてのLLM行は、temperature 0のdeepseek-v4-flashを使用しています。異なるLLMは絶対的なフィールドF1を変動させます。docTRの0.049ポイントのリードは、マージンで変動する可能性があります。LLMレイテンシ（SROIEで中央値約1,996–2,365 ms、field_method_comparison.csv llm_median_latency_ms）はAPIによるものであり、いずれのエンジン自体のレイテンシの一部ではありません。
• 正規表現チューニング： パターンセットはデータセットごとに1回作成されました。フォーマットごとに、高度にチューニングされたパターンライブラリは、独自のレイアウトでより高いスコアを出す可能性があります — それは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 vs 従来のOCRの精度 · AI画像データ抽出 vs 従来のOCR · AIドキュメント抽出の価格設定（2026）