docTR vs Surya2: レシートOCR
直接対決ベンチマーク（2026年）

文字誤り率 (CER) は古典的なOCRの評価基準です。挿入・削除・置換の合計を正解文字数で割ったもので、CER 0.197 は100文字あたり約19.7文字の誤読を意味します。単語誤り率 (WER) は同じ編集距離計算を単語単位で適用したものです。この指標では、2つのエンジンはほぼ互角です。

SROIE 2019 において、docTR と Surya2 はこのベンチマークで最強の2つの文字認識エンジンであり、その差は0.006ポイント — 361サンプルのコーパスではノイズ帯域内です。WER も同様の結果を示しています：Surya2 0.2735、docTR 0.3199。「VLMが従来のOCRを凌駕する」という主張は、英語レシートの生の文字精度という点では、この比較では成立しません。

文字精度：統計的同位

この同位が重要なのは、2つのエンジンが構造的に正反対だからです。docTR は従来型のニューラルOCRパイプラインで、2段階構成です：検出器が単語を特定し、認識器がそれを書き起こします。印刷テキストの元の大文字小文字とレイアウトを保持します。Surya2 は文書解析用の視覚言語モデル (VLM) です：文書画像全体を読み取り、理解されたテキストを出力します — 大文字小文字を統一し、ラベル/値ペアを結合し、行を並べ替えます — これは下流システムが求めるものに近い一方、正確な文字一致からは遠くなります。CER は正確な文字一致を評価するため、Surya2 に対してやや厳しめです。その非対称性にもかかわらず同位が維持されるという事実こそが、この結果を有意義なものにしています。

表：summary_metrics.csv — cer および wer 列、sroie_2019 行。正確な値：docTR cer 0.19707 / wer 0.31990；Surya2 cer 0.19147 / wer 0.27352。低いほど良好。両実行とも error_rate 0.0 で完了。

分岐点：標準設定のフィールド抽出で結果が逆転する

4つのSROIEレシート項目（会社名、日付、住所、合計金額）に対して、各エンジンの生テキストを同じ固定正規表現パターンでベンチマークします（従来のOCR＋ルールベースのキー情報抽出（KIE）アプローチ）。すると順位が逆転します。Surya2はフィールド抽出で0.3183のフィールドF1を達成し、docTRの0.0766に対して4.2倍のアドバンテージがあります。docTRはクラス最高の文字精度を持ちながら、8エンジン実行の中で最悪の正規表現フィールド抽出結果となっています。テキスト精度とフィールド精度は切り離されているのです。

フィールド値F1は、抽出されたフィールドの値と正解データに対する適合率と再現率の調和平均です。1.0はすべてのレシートフィールドが完全に復元されたことを意味し、0は何も抽出できなかったことを意味します。この逆転の背後にあるメカニズムは、前述の出力形式の違いです。正規表現はRM 12.00や14/08/2020のようなフォーマット済みの値用に書かれています。Surya2の正規化されたラベル構造化出力（小文字化、キーと値のマージ）はこれらのパターンにずっと頻繁に一致しますが、docTRの生の行テキスト（CERでは正確ですが、元の大文字小文字と区切り文字のノイズが含まれています）はそれらを打ち負かします。「正規表現フィールド抽出」列は、ベンチマークのpostprocessed_sroie_receipt_regex_*メトリクスです。これらは、OCRテキスト＋後段のルールベース抽出を測定したものであり、ネイティブな構造化出力ではありません。

出典：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 — regex 列、sroie_2019 行。これらは postprocessed_sroie_receipt_regex_* メトリクスです。各エンジンの OCR テキスト（ネイティブ抽出ではなく後処理済み）に固定パターンを適用したものです。docTR の regex フィールド F1 は 0.0766 で、基礎となる実行における全 8 エンジン中で最低であり、CER は 2 番目に良好でした。

LLM レバー：エンジン選択は重要でなくなる

両エンジンの OCR テキストを、構造化抽出プロンプト付きの LLM ポストプロセッサー（deepseek-v4-flash、温度 0）に渡すと、フィールド差はほぼ消えます：docTR 0.6171 対 Surya2 0.6139 のフィールド F1 — 従来型エンジンが 0.003 ポイント上回り、実質的に互角です。決定要因となるのは OCR エンジンではなく、ポストプロセッサーです。

これは、全 8 エンジンのベンチマーク全体で見られるのと同じパターンです。LLM ポストプロセッシングは、文字形状のマッチングではなく意味（数字、日付、名前）を理解するため、健全なエンジンを収束したフィールド F1 帯域に引き寄せます。docTR のよりクリーンなベーステキストがわずかにリードし、Surya2 の正規化された構造は LLM の下でそのわずかな利点を失います。このレバーには 2 つのコストが伴います：LLM 呼び出しにより、OCR 時間に加えて文書あたりの中央値レイテンシが約 2.0–2.3 秒 追加されます（docTR のテキストでは 1,996.3 ms、Surya2 では 2,261.7 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の下で収束する——しかし、バッチパイプラインは、数値が完了しなければどちらも気にしません。同じRTX 4090、同じ記録済みの$0.76/時間のレートで、docTRは449.3ページ/分、108.7 ms p50（1ページあたり）、1,000ページあたり$0.048を維持します。一方、Surya2は12.1ページ/分、2,668.0 ms p50、1,000ページあたり$1.061——37倍のスループット差、24.5倍のレイテンシ差、22.2倍のコスト差です。Surya2のペースに合わせたパイプラインは、docTRのペースに合わせたものとは異なるアーキテクチャの議論になります。

コストは、ウォールクロック実行時間×RunPod RTX 4090レート（$0.76/時間、実行マニフェストに価格のタイムスタンプあり）として計算され、モデル初期化を含みます——これは実際にGPU時間に対して支払う価格です。スループットは、同じ初期化を含む1分あたりのウォールクロックページ数です。レイテンシp50/p95は、ウォーム後にスコアリングされた定常状態の1ページあたりの推論時間です（モデル読み込みは除く）。Surya2のテールは比例的に悪く——5,872.2 ms p95 対 docTRの281.4 ms——これは、VLMのプリフィル/デコードのスパイクが最初のページのテールを支配するためです。

出典: summary_metrics.csv — latency_p50_ms列、sroie_2019行。docTR 108.7166、Surya2 2667.9800。定常状態のレイテンシ（warm_then_scored測定モード）。

出典: summary_metrics.csv — cost_per_1000_pages列、sroie_2019行。docTR 0.0479、Surya2 1.0609。コスト = ウォールクロック実行時間×$0.76/時間（モデル初期化を含む）、実行マニフェストに価格のタイムスタンプあり（2026年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.7 / p95 281.4 / 449.3 ページ/分 / $0.0479; Surya2 p50 2668.0 / p95 5872.2 / 12.1 ページ/分 / $1.0609。

CORD（インドネシアのレシート）：両エンジンとも崩壊、プロトコルにより隔離

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

フィールドメトリクスでは、SROIEと同じ乖離パターンが圧縮された形で保持されます：正規表現パターンを通じて、docTRはフィールドを一切回復しません（フィールドF1 0.0000 — CSVに記録された文字通りのゼロであり、欠損値ではありません）。これは英語形式のパターンがインドネシア語テキストに何も一致しなかったためです。一方、Surya2の正規化出力は0.2458を抽出します。その後、LLMはペアを0.5500（docTR）および0.5203（Surya2）に再収束させます — 言語ショックはエンジンではなくポストプロセッサーによって吸収されます。CORDは言語ロバストネスの文脈としてここで引用されており、SROIEの数値と単一のリーダーボードに意図的に統合されることはありません。

表：summary_metrics.csv（cer）および field_method_comparison.csv（フィールドF1）、cord_v2 行。これらの数値をいかなるSROIEランキングにも統合しないでください：CORDのCERは、真の言語不一致とグラウンドトゥルースにおける注釈構造の膨張を組み合わせたものです。正規表現パターンは英語形式用に書かれています。docTRの正規表現フィールドF1 0.0000は、CSVに記録された文字通りのゼロであり、欠損値ではありません。

勝敗の分かれ目：結果まとめ表

「どちらが優れているか」はワークロード次第です。この2つのエンジンは評価軸を明確に分けており、その分かれ方が結論です：文字精度は互角、構造化フィールドの利便性はSurya2、コスト・レイテンシ・スループットの全軸でdocTRが優位、そしてLLMポストプロセッサーを使えば最終的なフィールド品質においてエンジンの選択はほぼ無関係になります。

よくある質問

レシートではSurya2はdocTRより正確ですか？

いいえ — 生の文字精度では統計的に同等です: SROIE CER 0.1915（Surya2）対 0.1971（docTR）、その差は0.006ポイント（summary_metrics.csv、cer、sroie_2019行）。違いが出るのは、そのまま使える構造化フィールド出力（regexではSurya2が4.2倍勝ち）と動作環境（レイテンシーでdocTRが24.5倍、コストで22.2倍、スループットで37倍勝ち）です。

docTRは文字精度が最高なのに、なぜregexフィールド抽出が最悪なのですか？

2つの指標は異なる出力を評価しているからです。docTRは元の大文字小文字と区切り文字を保持したクリーンな生の行テキストを返すため、整形済みの値用に書かれた固定regexパターンはほとんど一致しません。そのSROIE regexフィールドF1は0.0766で、基礎となる実行における8エンジン中最低、一方CERは2番目に良い0.1971です（summary_metrics.csv cer、field_method_comparison.csv regex_field_value_f1）。Surya2の小文字化・ラベル構造化された出力は、たまたま0.3183でパターンに一致します。両方をLLMに渡すと、その差は0.003まで縮まります — ボトルネックはOCRではなくregexだったのです。

LLMポストプロセッサーを追加するとdocTRとSurya2は同等になりますか？

ほぼ完全に — docTR 0.6171 対 Surya2 0.6139 SROIEでのLLMフィールドF1（field_method_comparison.csv、llm_field_value_f1、sroie_2019行）。この収束のコストは、文書あたり約2.0〜2.3秒のLLMレイテンシー中央値の追加（llm_median_latency_ms、同行）で、同期のページ単位待機ではなく非同期バッチ処理に適しています。

docTRはSurya2よりどれくらい速くて安いですか？

24.5倍低いp50レイテンシー（108.7ms 対 2,668.0ms）、37倍高いスループット（449.3 対 12.1ページ/分）、そして22.2倍低い1,000ページあたりのコスト（$0.048 対 $1.061）を、同じRTX 4090で$0.76/時間にて実現（summary_metrics.csv、latency_p50_ms / pages_per_minute / cost_per_1000_pages、sroie_2019行）。

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

ベンチマークプロトコルがSROIEランキングから分離している2つの複合的な原因があります：真の言語ミスマッチ（両エンジンのトレーニング焦点外のインドネシア語レシート）と、CORDのグラウンドトゥルーステキスト内のアノテーション構造のインフレーションです。CERは0.9101（docTR）と0.8959（Surya2）に達します（summary_metrics.csv、cer、cord_v2行）。LLMを追加するとフィールドメトリクスはショックの一部を吸収します（0.5500 vs 0.5203）が、CORD行は引用され、いかなる複合ランキングにもプールされません。

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

パイプラインが消費する軸によります。計測コストで大量の生テキストの場合、docTRのエンベロープ（108.7 ms、449.3 pages/min、$0.048/1K pages）が優位です。ポストプロセッサーなしの構造化フィールドの場合、Surya2の標準正規表現F1（0.3183 vs 0.0766）がより良い出発点です。LLMポストプロセッサーによる最終フィールド品質の場合、選択はほとんど重要ではありません（0.6171 vs 0.6139）。これらの結果は2026年8月の1つのGPU層での英語およびインドネシア語レシートに有効です。本番決定はターゲットコーパスで再実行する必要があります（制限事項を参照）。

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

すべての数値はファーストパーティベンチマークの公開CSVの行です — results/summary_metrics.csv（CER/WER、フィールドF1、レイテンシ、コスト、スループット）およびresults/field_method_comparison.csv（正規表現 vs LLMポストプロセッサー、llm_model = deepseek-v4-flash）— はImageToTableai/benchmark-ocrでホストされており、実行ごとに環境フィンガープリント用の1つの編集済みmanifest.jsonがあります。データセット定義は以下に引用されている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/時で計算し、価格は各実行の秘匿化マニフェスト（2026 年 8 月）にタイムスタンプ付きで記録されています。
• エンジン：追加調整なしの標準状態。バージョン固定：docTR v1.0.1（従来型の二段階ニューラル OCR、GPU）と Surya2 (surya-ocr 0.22.1)（ドキュメント解析 VLM、vLLM 配信）。公開リポジトリのモデル表（README.md）および実行マニフェストに基づきます。
• LLM ポストプロセッサー：deepseek-v4-flash を API 経由で温度 0 にて使用し、決定的な出力を実現（field_method_comparison.csv の llm_model 列）。両エンジンのすべての LLM フィールド行に使用された唯一のモデルです。
• コスト基準：ウォールクロック実行時間 × $0.76/時。モデルの初期化を含みます。バッチ処理によりページあたりのコストは低下します。
• フィールド後処理：SROIE の regex フィールド指標は postprocessed_sroie_receipt_regex_*（field_method_comparison.csv の regex_* 列）です。固定パターンセットにより OCR テキスト から抽出されたフィールドです。これらは OCR と下流の抽出を測定するものであり、いずれかのモデルによるネイティブな構造化出力を測定するものではありません。LLM_* 列は OCR テキストと LLM 抽出を測定します。2 つのパイプラインが混在することはありません。

指標の定義

• CER（文字誤り率）: OCRテキストと正解データ間の編集距離（挿入＋削除＋置換）を、正解データの文字数で割った値。低いほど良い。大文字小文字や書式の慣習に敏感で、Surya2の正規化出力（大文字小文字の統一、ラベルと値の結合）に対してはやや厳しめ。
• WER（単語誤り率）: 同じ編集距離計算を単語単位で行ったもの。
• フィールド抽出F1（regex）: 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/時間のレートで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とsurya2の行に由来します。
2. field_method_comparison.csv（GitHub raw）。16行。列はmodel、dataset、llm_model（= deepseek-v4-flash）、regex/LLMフィールド値の精度とF1、文書フィールド完全一致、llm_median_latency_ms、トークン数。 すべてのregex/LLMフィールドF1数値は、ここにあるdoctrとsurya2の行に由来します。
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）。

制限事項

• ドキュメントの範囲 — レシートのみ: SROIE + CORD。ここでは、ドキュメント解析VLMが最大の強みと主張するレイアウト/テーブル/フォーム/長文ドキュメントの処理は測定していません。Surya2の宣伝上の強みは未測定です。このページを使って「docTRがすべてに勝つ」と結論付けないでください。
• サンプルサイズ: 英語361件 + インドネシア語100件のレシート。フィールドF1とCERはコーパスに依存します。数百分の1の差（CERの0.006差やLLM-F1の0.003差を含む）はノイズとして扱い、工学的な真実とは見なさないでください。
• 単一のGPUティアと単一の価格: すべての数値は、$0.76/時間のRTX 4090 1台から得られており、価格は実行マニフェストで2026年8月のタイムスタンプが付いています。他のGPU、マルチGPUサーバー、バッチスケジューリング、または価格変更により、レイテンシ、スループット、コストが変動します。予算を立てる前に、現在のレートでコストを再計算してください。
• 単一のLLMポストプロセッサー: すべてのLLM行は、温度0のdeepseek-v4-flashを使用しています。別のLLMを使用すると、絶対的なフィールドF1が変わります。収束順序は限界的に変動する可能性があります。LLMレイテンシ（中央値約2.0〜2.3秒、field_method_comparison.csvのllm_median_latency_ms）はAPIによるもので、どちらのエンジンのレイテンシにも含まれません。
• 正規表現 (regex) のチューニング: パターンセットはデータセットごとに1回作成されました。フォーマットごとに高度にチューニングされたパターンライブラリは、独自のレイアウトでより高いスコアを獲得できる可能性があります — ただし、LLMが排除するメンテナンスコストがかかります。
• CORD CERはモデル品質の指標ではありません: CORDのグラウンドトゥルースにはアノテーション構造が埋め込まれており、どちらのエンジンも主にインドネシア語でトレーニングされていません。CORD CER（0.90〜0.91）は、言語の不一致とグラウンドトゥルースのインフレーションを反映しています。CORD行は文脈を添えて引用され、SROIEランキングには決して統合されません（プロトコルルール）。
• VLMに対するCERの公平性: CERは正確な文字一致をスコアリングするため、Surya2のケースフォールド・ラベルマージ出力は、誤読ではなく出力規則のためにわずかにペナルティを受けます（CERに関する関連リファレンスを参照）。したがって、CERのタイはSurya2をわずかに過小評価しており、フィールドメトリクスがクロスファミリー比較のより公平な基準です。
• 2つのエンジンのみ: この直接比較は、基盤となる実行の他の6つのエンジン、クラウド/API OCRサービス、ホスト型VLM APIを意図的に除外しています。それらのレイテンシと価格モデルは、ここで測定されたローカルエンジンとは根本的に異なります。
• バージョンの固定: 結果は、docTR v1.0.1とSurya2 0.22.1（2026年8月）に適用されます。どちらかのエンジンの新しいリリースにより、このページのすべての数値が変わる可能性があります。

関連リファレンス: 従来のOCRとドキュメント解析VLMの比較 · 実際のドキュメントで正規表現が破綻するケース · 文字数がフィールド抽出を誤解させる理由 · レシートOCRの精度

関連資料: AI OCRと従来のOCRの精度比較 · 画像データ抽出とOCRエンジンの比較 · AIドキュメント抽出の価格（2026年）