従来型OCR vs 文書解析VLM
レシートベンチマーク結果（2026）

文字誤り率（CER）は、個々の文字がどれだけ誤読されるかを測定します — 削除、挿入、置換を正解文字数で割ったものです。これはOCRの古典的な指標であり、英語レシートにおける「VLM優位性」の物語が崩れるポイントです。

SROIE 2019では、最高のテキスト認識器2つはVLMと従来型エンジンで、0.006ポイントの差です：Surya2が0.191、docTRが0.197で、PaddleOCRが第3位（0.204）。残りの3つのVLM — PaddleOCR-VL 0.337、Docling 0.591、Unlimited-OCR 0.655 — はEasyOCR（0.283）やTesseract（0.335）といった従来型エンジンと同等かそれ以下です。

SROIEにおけるモデル別文字精度（英語レシート）

出典：summary_metrics.csv — cer列、sroie_2019行（8行）。Surya2 0.1915、docTR 0.1971、PaddleOCR 0.2045、EasyOCR 0.2833、Tesseract 0.3347、PaddleOCR-VL 0.3370、Docling 0.5909、Unlimited-OCR 0.6552。低いほど良い。TesseractはCPU専用。

表: summary_metrics.csv — cerおよびwer列、sroie_2019行、各361サンプル（8モデルすべてでerror_rate 0.0）。CER = 文字誤り率、WER = 単語誤り率。数値が低いほど良い。正確な値: Surya2 cer 0.19147 / wer 0.27352; docTR cer 0.19707 / wer 0.31990。

単語誤り率（WER）は、異なる粒度で同じ傾向を示します。文字ではなく単語単位の誤りを評価します。Surya2が0.274でWERをリードし、docTRが0.320で続きます。注目すべきは、最下位の外れ値です。Unlimited-OCRはCERが最悪（0.655）ですが、WERは中程度（0.478）です。これは、出力が大文字小文字やフォーマットの正規化が強く行われるためです（手法セクションで議論される出力規約）。単語がほぼそのままでも、文字レベルの編集数が膨らんでしまいます。

Doclingは比較表に登場する前に分類の注釈が必要です。純粋な従来型OCRエンジンでもVLMでもありません。Doclingはパイプラインパーサーです。OCRコアの周囲でレイアウト解析、テーブル検出、読取順序の再構築を段階的に行うツールチェーンです。単純なレシートでは、このパイプラインのオーバーヘッドはほとんど利益をもたらさず、これがSROIEでのCER（0.591）がシングルパスエンジンに劣る理由の一部です。

コストとレイテンシ：従来型エンジンの優位性

文字精度が両者の間に違いを生まないなら、コストとレイテンシがほぼすべてを決定します。同一のテスト分割において、docTRは449ページ/分、108.7 ms p50（1ページあたり）、1,000ページあたり$0.048を維持します。Surya2は12ページ/分、2,668 ms p50、1,000ページあたり$1.061を維持します。つまり、スループットは約37倍、1ページあたりのレイテンシは24.5倍、1,000ページあたりのコストは22倍です。

コストは、壁時計実行時間 × RunPod RTX 4090レート（$0.76/時間、ランマニフェストにタイムスタンプ付きの価格）で計算されます。これは、モデル初期化を含むGPU時間に実際に支払う金額です。Tesseractは特殊なケースです。CPUのみで、GPUコストは全くかかりませんが、SROIEで78.6ページ/分を達成しています。コストセルは設計上CSVで空欄です。無料だからではなく、請求対象のGPU時間を消費しないためです。

出典：summary_metrics.csv — latency_p50_ms列、sroie_2019行。docTR 108.7、PaddleOCR 297.0、EasyOCR 413.6、Tesseract 670.9（CPU）、PaddleOCR-VL 694.3、Docling 732.0、Unlimited-OCR 1600.7、Surya2 2668.0。定常状態レイテンシ、ウォームアップ後にスコアリングする測定モード（モデルロードを除く）。

出典：summary_metrics.csv — cost_per_1000_pages列、sroie_2019行。docTR 0.0479、EasyOCR 0.1098、PaddleOCR-VL 0.2048、PaddleOCR 0.2214、Unlimited-OCR 0.3879、Docling 0.3978、Surya2 1.0609。Tesseract CPUのみ：CSVのセルは空欄（GPUコストなし）。コストにはモデル初期化を含み、純粋な定常状態スループットは含みません。

表: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages、sroie_2019 行。GPU 実行は RTX 4090。Tesseract は CPU のみで実行（コスト列は空欄で、ゼロではない）。スループットはモデル初期化を含む壁時計ベースのページ/分。

テールレイテンシ列は、中央値だけでなく最悪ケースの動作を重視する場合に重要です。PaddleOCR の p95 が 3,331 ms、Docling が 3,240 ms であることは、p50 値から大きく乖離しています — GPU エンジンのテールには、初ページ効果とプリフィルスパイクが支配的です — 一方、docTR の p95 (281 ms) は狭い範囲に留まっています。インタラクティブなワークロード（ユーザーが1ページを待つケース）では、この p95 の差は、0.3 秒の待ち時間と 3 秒以上の待ち時間の違いを意味します。

CORD（インドネシアのレシート）：言語不一致とグランドトゥルースの膨張

CORD v2は、ネストされたフィールド（メニュー、小計、合計）を持つインドネシア語のレシートデータセットです。8つのエンジンのいずれもインドネシア語のレシートで主に訓練されていないため、CORDは言語横断のストレステストとして機能します。その結果、すべてのエンジンのCERは0.90–1.08に崩壊します。これらの数値は、CORDのグランドトゥルーステキストがアノテーション構造を埋め込んでおり、すべてのエンジンの生CERを膨らませているという注意点を考慮して読む必要があります。CORDの結果はSROIEのランキングから厳密に分離され、単一のリーダーボードに統合することはできません。

CORDのCERを1.0に押し上げる力は2つあり、そのうちの1つだけが言語そのものです。まず言語です。英語で訓練されたエンジンはインドネシア語の単語を本当に誤読します。インドネシアの人名、住所、通貨形式（Rp）は、それらの訓練分布の外にあります。次にグランドトゥルースです。CORDの公開されたテキストアノテーションは、純粋な可視テキストではなく、アノテーション構造（座標付きのフィールドラベル）を埋め込んでいるため、生CERは構造的に増強された文字列に対する編集距離を測定します。最もクリーンなVLMの例が最も厳しく罰せられます。CERが1.080のPaddleOCR-VLは、そのメカニズムの極端な産物であり、テキスト品質の読み取りではありません。

したがって、CORDにおける公正なクロスファミリー比較は、CERではなくフィールド指標です（次のセクションを参照）。CER列がまだ有用に示しているのは、言語の不一致が実在し、アーキテクチャ全体で普遍的であること、つまり従来型もVLMもすべてのファミリーが同じ0.90–1.08の帯域にあり、どちらにも構造的な優位性がないということです。

表: summary_metrics.csv — cer 列、cord_v2 行、各100サンプル。これらの数値をSROIEと組み合わせたランキングで比較しないでください: CORD CERは、正解データにおける言語の不一致とアノテーション構造の膨らみを組み合わせたものです（方法論は後述）。CERが1.0を超える（PaddleOCR-VL 1.0805）のは、この膨らんだ正解データによる編集距離アーティファクトです。

フィールドF1：LLM後処理がフィールド精度を収束させる

文字精度はエンジンの順位付けに使われますが、本番環境のユーザーが実際に課金するのはフィールド抽出です。ベンチマークでは、各エンジンのOCRテキストから4つのレシートフィールド（会社名、日付、住所、合計）を2種の後処理で抽出します。1つは固定正規表現パターン（従来型OCR＋ルールベースKIEアプローチ）、もう1つは構造化プロンプトを使用したLLM（deepseek-v4-flash）です。結果、LLMはSROIEにおいてエンジン間の差をほぼ埋め、8エンジン中6つを0.57〜0.62のフィールドF1帯に引き寄せました。一方、正規表現の結果は0.26ポイントの範囲に分散していました。

フィールド値F1は、抽出されたフィールド値の精度と再現率の調和平均で、正解データと照合してスコアリングされます。1.0は全フィールド値が完全に抽出されたことを、0は何も取得できなかったことを意味します。正規表現列はデータセットごとに1組の固定パターンを使用し、LLM列は決定論的な出力のためにtemperature 0のdeepseek-v4-flashを使用します（比較CSVのllm_model列）。2つの指標は異なるパイプラインを測定し、混合されることはありません。

出典：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_field_value_f1 / llm_field_value_f1、sroie_2019 行。LLM = deepseek-v4-flash 後処理。docTR regex 0.0766 → LLM 0.6171 (8.1× 向上); 6つの主要エンジンは 0.5685–0.6171 の範囲に分布。

この表には2つの直感に反する結果があります。まず、docTRはSROIEで最も低いregexフィールドF1 (0.077) と最も高いLLMフィールドF1 (0.617) を持っています — regexがフィールドの7.7%しか抽出できなかったクリーンなOCRテキストが、LLMでは61.7%を達成しました。ボトルネックはOCRではなく後処理でした。次に、0.57–0.62のバンドから外れる2つのエンジンは、まさにOCR品質が低下している2つです: EasyOCR (0.372、SROIE CER 0.283) とTesseract — そのCORDの結果 は、LLMが根本的に読めないテキストからフィールドを抽出できないことを示しています (CORD CER 0.9523)。あらゆる後処理の上限は、その下にあるOCRの品質です。

CORDでは、LLMも言語ショックの一部を吸収しています。健全なエンジン（PaddleOCR 0.553、docTR 0.550、PaddleOCR-VL 0.520、Surya2 0.520）において、regexがほぼゼロに崩壊する（docTR 0.0、EasyOCR 0.7%）のに対し、LLMのフィールドF1は0.47–0.55を維持しています。これは、パターンが英語フォーマット用に書かれており、「さらに一つの言語」のペナルティはルールによってほぼ完全に負担され、LLMによって負担されないためです（field_method_comparison.csv、llm_field_value_f1 / regex_field_value_f1、cord_v2行）。

CERが文書解析VLMを過小評価する理由

CERはVLMの出力と正解を文字単位で比較し、認識誤りではない2つの正当な動作、大文字小文字の統一とラベル/値の結合に対してVLMにペナルティを与えます。SROIEのベンチマークにおけるCER分解は、VLMのCERの約18%を大文字フォーマットの違い（例：TAN CHAY YEE → tan chay yee）に、約10%を行の結合または区切り行の削除に帰属させています。実際にはフィールド値自体（会社名、合計、日付）は正しく、（ベンチマークのプロトコルノートに記録されたCER分解分析、SROIE実行）。

この設計上の緊張は現実的かつ構造的なものです。従来型OCRエンジンは大文字小文字を保持した生のテキストを出力するため、CERスコアリングに最適化されています。文書解析VLMは「理解された」テキスト（大文字小文字の正規化、ラベル/値ペアの結合、行の再配置）を出力し、これはダウンストリームシステムが求めるものに近いですが、正確な文字一致からは遠くなります。これが、ページの見出しが類似出力間の公平な比較にのみCERを使用し、公平なクロスファミリー比較がフィールド指標に存在する理由であり、（アノテーション構造の膨張をさらに負う）CORD CERが独自のセクションに隔離されている理由です。より広いポイント：ファミリー間のCER差は自動的に精度差を意味しません。ファミリーをまたいでモデルを比較する人は、あるファミリーが「よりよく読む」と結論付ける前に、CERが何を測定しているかを確認すべきです。

選択方法：ワークロードに合った軸は何か

ワークロードなしに「より良い」は意味をなしません。ベンチマークの正直な結論は、2つのエンジンファミリーが異なる軸で勝ち、レシートは特に従来型エンジンが勝つ軸と、後処理が—エンジンファミリーではなく—フィールド品質を決定する軸を測定しているということです。

選択ガイダンスは引用されたCSV行から直接導き出されたものであり、データに基づく読者支援であり、ベンダーの推奨ではありません。正確な結果はハードウェア、ドキュメントの構成、モデルバージョンによって異なります。

よくある質問

文書解析VLMは、レシートにおいて従来型OCRよりも正確ですか？

文字精度の点では否です。最高のVLMと最高の従来型エンジンは、SROIE 2019において統計的に拮抗しています（Surya2 CER 0.191 対 docTR 0.197、summary_metrics.csv sroie_2019行）。PaddleOCR（0.204）が3位です。フィールド抽出が目的の場合、VLMの有無にかかわらず、LLM後処理が決定的な要因となります（0.57〜0.62の収束帯、field_method_comparison.csv）。

文書解析VLMよりも従来型OCRが適しているのはどのような場合ですか？

大量処理、コスト従量制、またはインタラクティブなレイテンシが求められる場合です。SROIEにおいて、docTRは1,000ページあたり$0.048のコストで108.7 ms（p50）のレイテンシを実現し、449ページ/分を処理しました。Surya2は1,000ページあたり$1.061のコストで2,668 ms（p50）のレイテンシを実現し、12ページ/分を処理しました（summary_metrics.csv、doctrおよびsurya2のsroie_2019行）。ページごとのインタラクティブな待ち時間としては、0.1秒対2.7秒の違いです。

なぜ文書解析VLMは、安価なOCRよりもCERが高くなることがありますか？

CERは正確な文字一致を評価するためです。VLMは、誤読ではなく出力規約である大文字小文字の統合やラベル/値の結合に対してペナルティを受けます。ベンチマークのCER分解によると、SROIEにおけるVLMのCERの約18%は大文字小文字の形式差、約10%は行結合/区切り文字の欠落に起因し、フィールド値自体はしばしば正確です（方法論を参照）。CORDのCERは、正解データ内のアノテーション構造によってさらに膨らむため、このページではCORDのCERをランキングから除外し、ファミリー間比較にフィールド指標を使用しています。

RTX 4090でレシートOCRの1ページあたりのコストはいくらですか？

RTX 4090（$0.76/hr）で、1,000ページあたり$0.048（docTR）から$1.061（Surya2）の範囲です（価格は2026年8月のランマニフェスト（summary_metrics.csvのcost_per_1000_pages、sroie_2019行）に記録）。TesseractはCPU専用でGPU時間を消費しません。コストにはモデルの初期化が含まれるため、バッチサイズが大きくなると1ページあたりのコストは下がります。

なぜすべてのモデルがCORDレシートでCER 0.90以上をスコアするのですか？

2つの複合的な原因があります：言語の不一致（インドネシア語のレシートがすべてのエンジンの学習対象外であること）と、CORDの正解テキスト内のアノテーション構造によるスコアの膨張です。いずれのファミリーもこれを逃れられず、全8モデルが0.90〜1.08の範囲に収まります（summary_metrics.csvのcer、cord_v2行）。CORDは言語/レイアウトの堅牢性をテストするためのセットであり、SROIEのランキングとは別に管理されています。

LLMが悪いOCR出力を修正してくれるのですか？

ベーステキストの品質までしか改善できません。SROIEでは、LLMがエンジンに関係なく6つのエンジンを0.57〜0.62のフィールドF1の範囲に引き上げましたが（field_method_comparison.csv）、TesseractのCORDケースは限界を示しています：CER 0.9523で、LLMによるフィールドF1は0.163です。LLMは読めないテキストからフィールドを抽出することはできません。

レシートOCRで最も高速なのはどれですか？

このベンチマークではdocTRです：SROIE 2019で1ページあたり108.7 ms（p50）、449ページ/分です（summary_metrics.csvのdoctr/sroie_2019: latency_p50_ms, pages_per_minute）。最も遅かったSurya2は、p50で24.5倍遅く（2,668 ms）、スループットで37倍遅く（12ページ/分）でした。

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

すべての数値は、一次ベンチマークの公開CSVの行から来ています：results/summary_metrics.csv（8モデル×2データセット：CER/WER、フィールドF1、レイテンシ、コスト、スループット）とresults/field_method_comparison.csv（正規表現 vs LLM後処理）。これらはImageToTableai/benchmark-ocrでホストされており、各ランの環境フィンガープリント用に1つの編集済みmanifest.jsonが含まれています。データセットの定義は、以下に引用されているSROIE 2019およびCORDの論文から来ています。

手法と情報源

プロトコル

本ページでは、独立した再現可能なベンチマーク実行（公式ティア）による文書解析比較を報告しています。これは第三者の主張の調査ではありません。固定されたテスト分割のみを使用しています：SROIE 2019テスト（361件の英語レシート、会社名/日付/住所/合計のフラットフィールド）とCORD v2テスト（100件のインドネシア語レシート、メニュー/小計/合計のネストされたフィールド）。訓練分割は評価対象外です。すべての（モデル×データセット）ペアは、同じ画像、同じ正解データ、同じ測定プロトコル（warm_then_scored：スコアリングパスの前に固定ウォームアップパスが実行され、レイテンシが定常状態になる）を使用しています。すべての16回の実行がエラー率0.0（summary_metrics.csvのerror_rate列）で完了しました。

実行環境

• ハードウェア：すべてのGPU実行はNVIDIA RTX 4090（24 GB）で実行。GPUコストはRunPodのオンデマンドレート$0.76/hrで計算。価格のタイムスタンプは各実行のマニフェスト（2026年8月）に記録。TesseractはCPUのみで実行し、GPUコストなし（CSVのコストセルは空）。
• エンジン：すべてのモデルはデフォルト設定で実行。ファインチューニングなし。バージョンは実行マニフェストに準拠。
• LLM後処理：API経由のdeepseek-v4-flash（temperature 0で決定論的出力）。field_method_comparison.csvのllm_model列に記録。すべてのLLMフィールド行に単一モデルとして使用。
• コスト基準：壁時計実行時間×$0.76/hr（モデル初期化を含む）。バッチ処理によりページ単位コストが低減。
• フィールド後処理：SROIEフィールド指標はpostprocessed_sroie_receipt_regex_*/LLMバリアント。つまり、固定regexセットまたはLLMによってOCRテキストから抽出されたフィールド。モデルのネイティブ構造化出力ではなく、OCR＋下流抽出を測定。

バージョンはベンチマークのモデルテーブル（README.md）および実行ごとのマニフェスト（results/manifests/、公開された実行ごとに1つ、計16件）に記録されたもの。各マニフェストには、実行ID、モデルバージョン、ランナースクリプトハッシュ、GPU/ドライバー、torch/CUDA/Pythonバージョン、pip-freezeハッシュ、価格タイムスタンプを含むコストメタデータ、再現性のためのアーティファクトハッシュが記録されています。

指標の定義

• CER（文字誤り率）: OCRテキストと正解データ間の編集距離（挿入＋削除＋置換）を正解文字数で割ったもの。低いほど良い。大文字小文字や表記規則に敏感。
• WER（単語誤り率）: 単語粒度での同じ編集距離計算。
• フィールド値F1（regex）: OCRテキストに固定の正規表現パターンを適用して抽出したフィールド値に対する、適合率/再現率の調和平均（従来型OCR＋ルールベースKIEパイプライン）。列名: regex_field_value_f1。
• フィールド値F1（LLM）: LLM後処理の出力（OCRテキスト → deepseek-v4-flash → フィールド）に対する同じ指標。列名: llm_field_value_f1。 2つのパイプラインは異なり、混合されることはありません。
• レイテンシ p50/p95 ＆ ページ/分: 安定状態の1ページあたり推論時間（ウォーム後にスコアリング、モデルロードを除く）と、モデル初期化を含む実時間スループット。
• 1,000ページあたりコスト: 記録された$0.76/hrのレートで1,000ページを処理した場合の請求GPU時間。CPUのみのTesseractは空欄。

出典一覧

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、レイテンシ、コスト、スループットの数値はすべて、この行に追溯できます。
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の数値はすべて、この行に追溯できます。
3. ImageToTableai/benchmark-ocr リポジトリ。結果CSV、編集済みランマニフェスト、固定されたプロトコル、および再現用のデータセットサンプルリスト（固定テスト分割）を公開しているリポジトリ。
4. results/manifests/（GitHub）。公開された各ラン（16ラン）に対し、環境フィンガープリント、モデルバージョン、コストメタデータ、アーティファクトハッシュを含む編集済みmanifest.json。
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が最大の利点を主張する文書タイプは、ここでは未測定です。このページから「従来型OCRはどこでも優れている」と結論づけないでください。
• サンプルサイズ: 英語361件 + インドネシア語100件のレシート。フィールドF1とCERはコーパスに依存します。数百分の一の単桁の差はノイズとして扱い、エンジニアリング上の真実とみなすべきではありません。
• 単一GPU階層: すべてのGPU数値は、1時間$0.76のRTX 4090 1台から取得したものです。他のGPU、マルチGPUサーバリング、またはバッチスケジューリングでは、レイテンシ、スループット、コストが変動します。
• CPU/GPUの非対称性: Tesseract（CPU）はGPUアクセラレータエンジンと比較されています。そのレイテンシ/時間はCPUハードウェアを反映し、コスト優位性はGPU課金ゼロを反映しています。これは関連するすべての表に記載されていますが、この非対称性は比較に内在しています。
• LLM後処理は単一モデル: すべてのLLMフィールド行はdeepseek-v4-flashを使用しています。異なるLLMでは絶対F1が異なり、収束順序は端数で変動する可能性があります。LLMレイテンシ（中央値約1.8〜2.4秒、field_method_comparison.csv llm_median_latency_ms）はAPIによるもので、OCRエンジン自体のレイテンシの一部ではありません。
• コストのタイムスタンプ: $0.76/時のGPU価格は、2026年8月のランマニフェストで記録されました。GPUスポット/オンデマンド価格は変動します。予算策定前に、現在のレートでコストを再計算してください。
• CORD CERは品質の指標ではありません: CORDの正解データはアノテーション構造を埋め込んでおり、エンジンはインドネシア語でトレーニングされていません。CORD CER（全8モデルで0.90〜1.08）は、言語の不一致と正解データの膨張を反映しており、モデルごとの読取品質を反映していません。CORD行は意図的にSROIEランキングには統合されていません。
• 正規表現のチューニング: 正規表現パターンセットはデータセットごとに1回作成されました。ベンダーごとに高度にチューニングされたパターンライブラリは、独自のフォーマットでより高いスコアを出す可能性がありますが、LLMが排除するメンテナンスコストが発生します。
• クラウド/APIモデルなし: AWS Textract、Google Document AI、Azure AI Document Intelligence、およびホスト型VLM API（クラウドOCRサービスなど）は含まれていません。それらのレイテンシと価格モデルは、ここで測定されたローカルエンジンとは根本的に異なります。
• バージョン固定: 結果は、上記の2026年8月のモデルバージョンに有効です。任意のエンジンの新しいリリースでは結果が変動する可能性があり、大きなp95スパイクを持つ2つの測定（PaddleOCR、Docling）のp50レイテンシは、このランのバッチパターン下でのプリフィル/初ページ効果を反映しています。

関連リファレンス: 正規表現 vs LLM フィールド抽出 · フィールドレベル vs 文字レベルの精度 · レシートOCRの精度 · 文書タイプ別のOCR精度

関連読書: AI OCR vs 従来型OCRの精度 · AI画像データ抽出 vs 従来型OCR · AI文書抽出の価格（2026年）