レシートにおけるTesseractとPaddleOCRの比較
レガシーCPU vs モダンGPU (2026)

2つのエンジンとは何か：35年のOCR vs CNN 2段階パイプライン

このページ全体の物語は、アーキテクチャのギャップにある。TesseractはクラシックなオープンソースOCRエンジンで、1980年代にHPで開発され、2005年にGoogleがオープンソース化したため、約35年の歴史を持つ。そのパイプラインは従来のコンピュータビジョン：適応的二値化、ページセグメンテーション、連結成分解析、文字認識（バージョン4以降はLSTMベース）で、このベンチマークではCPUのみで実行され、GPUコストは発生しない（CSVではcompute_type = cpu）。PaddleOCRは、PaddlePaddleエコシステム出身のモダンな深層学習エンジン：PP-OCRファミリーの2段階パイプラインで、テキスト領域を特定する検出段階（DBNetスタイル）と、それを文字起こしする認識段階で構成され、GPU上で実行される。一方のエンジンは学習したパターンに対して文字の形を照合することで読み、もう一方はテキストの場所と内容を学習することで読む。このベンチマークでは、同じレシート、同じプロトコル、同じマシンで両者を検証した。

なぜこの仕組みが重要か：Tesseractのアプローチは実行コストが低く、GPUを必要としないが、その文字モデルは数十年にわたるクラシック認識の結晶であり、テキスト品質に硬い天井として表れる。PaddleOCRのアプローチはGPU時間を要するが、はるかにクリーンなテキストを読み取る。このベンチマークの目的は、1回の制御された実行からそのトレードオフの両面に数値をつけることであり、驚くべきは運用コスト面のトレードオフがいかに狭かったかである。

文字精度：モダンアーキテクチャが全テキスト指標で勝利

SROIE 2019では、テキスト精度のギャップは大きく一方的：CER 0.2045（PaddleOCR）対 0.3347（Tesseract）で、39%の相対的改善；WER 0.3256 対 0.5591で、42%の相対的ギャップ。TesseractのCER 0.3347は、基礎となる実行の8エンジン中5位で、中位であり最下位ではないが、その上のエンジンは1つを除きすべて深層学習エンジンであり、Tesseractと深層学習層（最高：Surya2 0.1915、docTR 0.1971）のギャップは、それらのエンジンとPaddleOCR（0.2045、3位）のギャップよりも大きい。

文字誤り率（CER）はクラシックなOCRの尺度で、挿入、削除、置換を正解文字数で割ったもので、CER 0.335は約100文字あたり33.5文字の誤読を意味する。単語誤り率（WER）は単語粒度で同じ編集距離計算を適用する。どちらも低いほど良い。WERギャップ（42%）がCERギャップ（39%）よりも広いことは、Tesseractの文字の誤りがこのコーパスでは単語全体の失敗に複合していることを意味し、これはクラシックエンジンの失敗モードであり、下流のフィールド抽出器が直接引き継ぐものである。

出典：summary_metrics.csv — cerおよびwer列、sroie_2019行。PaddleOCR cer 0.20449 / wer 0.32563；Tesseract cer 0.33468 / wer 0.55915。低いほど良い。エンジンあたり361サンプル；両方のerror_rate 0.0。

表: summary_metrics.csv — cer / wer / error_rate 列、sroie_2019 行。正確な値: Tesseract cer 0.33468 / wer 0.55915; PaddleOCR cer 0.20449 / wer 0.32563。CER/WER は低いほど良い。同じCSVによるランキング情報: 全8エンジンのSROIE CERは、surya2 0.1915、doctr 0.1971、PaddleOCR 0.2045、easyocr 0.2833、Tesseract 0.3347 (5位)、paddleocr_vl 0.3370、docling 0.5909、unlimited_ocr 0.6552。ここで扱う両エンジンはベンチマークの精度王者ではなく、docTRとSurya2がCERの上位2位を占めている。

フィールド抽出：本番環境の判断を分けるギャップ

テキスト精度がエンジンをランク付けするが、ダウンストリームシステムが実際に利用するのはフィールド抽出である。ベンチマークのSROIEフィールド指標は、各エンジンのOCRテキストに対して2種の後処理を用いて、4つのレシートフィールド（会社名、日付、住所、合計）を対象とする：固定正規表現パターン（従来のOCR＋ルールベースの重要情報抽出アプローチ）と、構造化プロンプトを使用したLLM後処理（deepseek-v4-flash、温度0）。正規表現では、PaddleOCRが0.3254 フィールドF1でフィールドを抽出し、Tesseractは0.2335 — 1.39倍の優位性。LLMでは、ギャップは0.5810対0.4389（1.32倍）と続く。LLMの利点は両エンジンに及ぶが、Tesseractのより弱い基盤からスタートしている。本番パイプラインを決定する上限の議論は、次のセクションにある。

フィールド値F1は、抽出されたフィールド値と正解の精度と再現率の調和平均です — 1.0はすべてのレシートフィールドが完全に復元されたことを意味し、0は何も復元されないことを意味します。SROIE正規表現フィールド列は、ベンチマークのpostprocessed_sroie_receipt_regex_*指標です：各エンジンのOCRテキストに適用された固定パターン — ポスト処理済みであり、ネイティブの構造化出力ではありません。ランキングの文脈：PaddleOCRの正規表現F1 0.3254は、8エンジンベンチマークにおける4つの純粋に従来型エンジンの中で最高です（Unlimited-OCR 0.3376とPaddleOCR-VL 0.3368に次ぐ）；Tesseractの0.2335は全体で4番目の正規表現結果です（summary_metrics.csv、field_f1_regex、sroie_2019行）— このクラシックエンジンは、クリーンな英語テキストでは中程度のフィールド抽出性能を発揮しますが、まさにそこから競争力を失います。

出典：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およびllm列、sroie_2019行。regex列はpostprocessed_sroie_receipt_regex_*メトリクス：各エンジンのOCRテキストに適用された固定パターン。LLMポストプロセッサ：temperature 0のdeepseek-v4-flash（llm_model列）。LLMレイテンシはAPIによるもので、エンジンレイテンシとは別です（summary_metrics.csv latency_p50_ms）。“Docs with all fields exact”は、すべての対象フィールドが完全に一致したドキュメントの割合です — フィールドごとのF1よりもはるかに厳しい基準です。ランキングの文脈（llm_field_value_f1、sroie_2019の全行）：PaddleOCR 0.5810は8中5位；Tesseract 0.4389は7位で、EasyOCRの0.3717にのみ先行しています。

驚き：ウォールクロックにおけるCPUスループットの同等性

このページの見出しに値する発見は、誰のサードパーティ比較にも記録されていないものです：同じレシートにおいて、CPUのみのクラシックエンジンは、ウォールクロックの1分あたりページ数でモダンなGPUエンジンに匹敵します — 78.6（Tesseract）対79.7（PaddleOCR）、約1.4%の差で、統計的に同等です。クラシックエンジンは「大量で遅い」わけではありません：1ページあたりは遅いですが安定しており、このコーパスでは、基礎となるランの7つのGPUエンジンのうち4つを上回っています（docling 56.7、paddleocr_vl 68.2、unlimited_ocr 34.4、surya2 12.1ページ/分）。

これはレイテンシの数字と矛盾するように見えますし、脚注ではなく、誠実な説明が求められます。レイテンシp50は、定常状態の1ページあたり推論であり、ウォームアップ後にスコアリングされ、モデルのロードは除外されています — PaddleOCRの297.0 msは、Tesseractの670.9 msより確かに高速です。1分あたりページ数は、ラン全体のウォールクロックスループットであり、モデルの初期化やバッチ効果を含みます。CSVのスループットを1ページあたりのウォールクロック時間に変換します（60秒 ÷ pages_per_minute）：PaddleOCRは1ページあたり約753 msのウォールクロックに対し、p50は297 ms — 約456 msが初期化/プリフィルおよびバッチオーバーヘッドです。Tesseractは1ページあたり約763 msのウォールクロックに対し、p50は671 ms — 約92 msがオーバーヘッドです。Tesseractの軽量化されたCPUランタイムは高速に起動し、安定してストリーミングします。PaddleOCRのGPUパイプラインは、実行ごとにより重いロード/プリフィルコストを支払い、この361ページのコーパスでは、その高速な定常状態をほぼ相殺しています。長時間稼働するウォームパイプラインでは、PaddleOCRの1ページあたりの優位性が見られます。コールドスタート、小さなバッチ、頻繁な再初期化が支配的なパイプラインでは、クラシック側のエンジンが同等かそれ以上に見えます。

p95のテールは、1つの数字で同じ物語を語ります：Tesseractのp95は1,507.0 msで、PaddleOCRの3,331.4 msより2.2倍狭いです。GPUエンジンの最初のページ/プリフィルスパイク — そのウォールクロックの1ページあたり時間を膨らませる同じロードパス — が最悪ケースのテールを支配しており、CPUエンジンにはそのようなスパイクがありません。テールレイテンシに敏感な、または容量を計画するワークロードには、クラシックエンジンの方が予測可能です。

出典: summary_metrics.csv — pages_per_minute カラム、sroie_2019 行。Tesseract 78.63285、PaddleOCR 79.71298。モデル初期化を含む壁時計ベースのページ/分；ページごとの定常状態のレイテンシは latency_p50_ms カラム（下記チャート参照）。整合性: 60 ÷ 78.63285 = 763 ms/ページ vs 60 ÷ 79.71298 = 753 ms/ページ 壁時計ベース。

出典: summary_metrics.csv — latency_p50_ms / latency_p95_ms カラム、sroie_2019 行。Tesseract p50 670.87 / p95 1506.99；PaddleOCR p50 296.99 / p95 3331.35。定常状態レイテンシ（ウォームアップ後にスコアリングする測定モード、モデルロードを除く）。p50 とページ/分の緊張関係は上記の文章で整合性が取られています：異なるクロックであり、どちらも現実的です。

テーブル: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute、sroie_2019 行。正確な値: Tesseract p50 670.87 / p95 1506.99 / 78.63 pg/min；PaddleOCR p50 296.99 / p95 3331.35 / 79.71 pg/min。レイテンシはページごとの定常状態（ウォームアップ後にスコアリング、モデルロードを除く）；ページ/分は初期化とバッチ効果を含む壁時計ベース — 均衡と p95 の反転は測定モデルとアーキテクチャの事実であり、矛盾ではありません。

コストの物語：レガシーエンジンが完全に勝つ場面

コストは、Tesseractの年齢が有利となる唯一の軸であり、それは構造的なものです。TesseractはCPU専用であるため、CSVのコストセルは設計上空欄です（GPU課金を計測する必要がない）。一方、PaddleOCRは、記録された$0.76/hrで同じRTX 4090上で1,000ページあたり$0.2214を課金します。スループットが同等のワークロード（上記の同等性）では、GPU課金を嫌うインフラストラクチャにおけるクラシックエンジンの運用コストは実質的に低くなります。これは、「アップグレードする価値があるか」という判断の価格基準です。

コストは、壁時計実行時間 × RunPod RTX 4090レート（$0.76/hour、ランマニフェストにタイムスタンプ付き価格）で計算され、モデル初期化を含みます。空のTesseractセルはゼロではなく、エンジンがGPUに触れたことがないための欠損値です。ベンチマークでは、数値を仮定する代わりに空欄として記録されます（プロトコルルール：空セルはnot_applicableであり、決して0ではありません）。2つのコンテキスト数値がこれを裏付けています。PaddleOCRの$0.2214は、7つのGPUエンジンの中では中位です（docTRがベンチマークで最も安いGPU行を1,000ページあたり$0.048で保持）。また、CORDでは、PaddleOCRのコストは141.0ページ/分で1,000ページあたり$0.3419に上昇します。

出典：summary_metrics.csv — cost_per_1000_pages列、sroie_2019行。PaddleOCR 0.2214。Tesseractの値は空欄です（CSVのセルが空）：CPU専用の計算タイプ、GPU課金なし — プロットでは省略として扱われ、ゼロではありません。コスト = 壁時計実行時間 × $0.76/hr（モデル初期化を含む）、ランマニフェストにタイムスタンプ付き価格（2026年8月）。ベンチマークで最も安いGPUエンジン：docTR 1,000ページあたり$0.048（doctr/sroie_2019行）。

表：summary_metrics.csv — cost_per_1000_pages / compute_type列、sroie_2019行。Tesseractのコストセルは空欄です（空、0.0000ではない）。エンジンがCPU専用のためです。PaddleOCRのGPUコストには、記録された$0.76/hrでのモデル初期化が含まれます。CORDでは、PaddleOCRのコストは141.0ページ/分で1,000ページあたり$0.3419です（paddleocr/cord_v2行）。

CORD（インドネシア領収書）：両エンジンとも崩壊し、ベンチマーク最大のフィールドギャップが出現

いずれのエンジンもインドネシア領収書を主に学習していなかったため、CORD v2（100サンプル、ネストフィールド menu/sub_total/total）は言語横断ストレステストとして機能し、生のCER（文字誤り率）では両エンジンとも崩壊します：0.9083（PaddleOCR）と0.9523（Tesseract）、これは言語不一致による結果です。ベンチマークプロトコルに従い、CORDの数値はSROIE比較から隔離され、いかなるランキングにも統合されません。その理由は、CORDの正解テキストにアノテーション構造が埋め込まれており、言語不一致に加えて全エンジンの生CERを過大に評価してしまうためです。

両エンジンの差が最も顕著なのはLLMフィールド抽出であり、これは本ページの最も強力な単一データポイントです。LLM後処理により、PaddleOCRのCORDフィールドF1スコアは0.5527を維持し、CORDにおける全8エンジン中最高を記録します。一方、Tesseractは0.1627に崩壊し、ベンチマーク全体で全8エンジン中最低となります。この0.39ポイントの差は、実行された全LLMフィールド比較において、兄弟行間で最も大きなギャップです。これは上限論の具体例です：TesseractのCORDテキストは読み取れないほど劣化しており（CER 0.9523）、いかなる後処理（正規表現でもLLMでも）もフィールドを復元できません。LLM活用は効果があります（TesseractのSROIE F1は正規表現の0.2335からLLMで0.4389に向上します）が、出発点が弱く、エンジンが読み取らなかったテキストを生成することはできません。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は、正解データにおける言語の不一致とアノテーション構造の膨張を組み合わせたものであり、正規表現パターンは英語形式用に作成されています（両エンジンの正規表現F1は約1〜8%に低下）。ランキングコンテキスト（llm_field_value_f1、全cord_v2行）：PaddleOCR 0.5527は8つ中最良；Tesseract 0.1627は8つ中最悪――ベンチマーク内で最も広い兄弟行間の差。Tesseractのコストセルは空です（CPUのみ）、決して0ではありません。

Who Wins When: サマリーグリッド

“Better”はワークロードに依存し、このヘッド・トゥ・ヘッドは軸を通常とは異なる明確さで分割します: すべての精度軸はPaddleOCRを支持し、コスト、CPUのシンプルさ、および厳密なp95の裾はTesseractを支持し、壁時計スループットは統計的な拮抗であり、ページあたりのレイテンシはPaddleOCRを支持し、生のCERチャンピオンはどちらでもありません（docTR/Surya2）。

よくある質問

PaddleOCRはレシートにおいてTesseractよりも正確ですか？

はい — このベンチマークで測定されたすべての精度軸において。 SROIE 2019では：CER 0.2045 対 0.3347（相対改善率39%）、WER 0.3256 対 0.5591（42%）、正規表現フィールドF1 0.3254 対 0.2335（1.39倍）、LLM後処理フィールドF1 0.5810 対 0.4389（1.32倍）（summary_metrics.csvおよびfield_method_comparison.csv、sroie_2019行）。いずれのエンジンもベンチマークの総合テキストチャンピオンではありません — Surya2（CER 0.1915）とdocTR（0.1971）がその座を保持しています。

なぜTesseractはCPUのみであるにもかかわらず、1分あたりのページ数でPaddleOCRと同等の性能を発揮するのですか？

なぜなら、1分あたりのページ数は壁時計スループットであり、1ページあたりの推論速度ではないからです。 PaddleOCRの定常状態p50（297.0 ms）はTesseract（670.9 ms）より確かに2.3倍速いですが、壁時計スループットにはモデルの初期化とバッチ効果が含まれます：79.7ページ/分のPaddleOCRは、297 msのp50に対して壁時計で約753 ms/ページを費やし、一方、Tesseractの軽量化されたCPUランタイムは、671 msのp50に対して約763 ms/ページを費やしています — GPUエンジンは実行ごとにより重いロード/プリフィルコストを支払うため、この361ページのコーパスでは速度優位性がほぼ相殺されています（summary_metrics.csv、pages_per_minute / latency_p50_ms、sroie_2019行）。

なぜTesseractのp95レイテンシはPaddleOCRよりも狭いのですか？

GPUエンジンの初ページ/プリフィルスパイクが最悪ケースのテールを支配しているためです：PaddleOCR p95 3,331.4 ms 対 Tesseract p95 1,507.0 ms、p50の順序が2.2倍反転しています（summary_metrics.csv、latency_p95_ms、sroie_2019行）。TesseractのCPUパイプラインにはロードスパイクがなく、安定してストリーミングします。PaddleOCRの高速な定常状態は、実行ごとにより重い初期化パスを伴います。2つのクロックは異なるものを測定しており、どちらも現実です。

TesseractはPaddleOCRより安いですか？

GPU課金では、はい — TesseractにはGPUコストがありません：CPU専用であるため、コストセルは設計上空欄（決して0にはならない）ですが、PaddleOCRはSROIEで1,000ページあたり$0.2214、CORDで$0.3419と課金されます。同じRTX 4090（$0.76/hr）で、モデル初期化コストを含む比較です（summary_metrics.csv, cost_per_1000_pages, sroie_2019およびcord_v2行）。ベンチマーク全体で最も安いGPUエンジンは、1,000ページあたり$0.048のdocTRです。

なぜTesseractのCORD LLMフィールドF1がベンチマーク全体で最悪なのでしょうか？

LLM後処理では、OCRエンジンが読み取らなかったテキストを回復できないためです。 TesseractのCORD CERは0.9523 — インドネシアのレシートでは事実上読めない状態 — であり、LLMフィールドF1は0.1627にまで低下し、8つのエンジン中最悪です。一方、PaddleOCRは0.5527を維持し、8つ中最良です（field_method_comparison.csv, llm_field_value_f1, cord_v2行）。クリーンな英語テキスト（SROIE）では、同じ手法でTesseractも0.4389に改善しますが、上限は基本テキストの品質によって決まります。

なぜ両方のエンジンがCORDレシートでそれほど悪いスコアを出すのですか？

SROIEランキングから独立して評価される2つの複合的な原因があります：言語の不一致（インドネシアのレシートが両エンジンの訓練対象外であること）と、CORDの正解テキストにおけるアノテーション構造の膨張です。CERは0.9083（PaddleOCR）と0.9523（Tesseract）に達します（summary_metrics.csv, cer, cord_v2行）。両者を分かつのは、LLMによる後続の回復力です：PaddleOCR 0.5527対Tesseract 0.1627のフィールドF1 — ベンチマークで最も大きな差です。CORD行は文脈付きで引用され、統合ランキングには含まれません。

レシートパイプラインはTesseractとPaddleOCR、どちらのエンジンを選ぶべきか？

パイプラインがフィールド（会社名、日付、合計などの抽出値）を扱う場合、レシートではPaddleOCRが明確なデフォルトです。正規表現でフィールドF1が1.39倍、LLMで1.32倍向上し、CORD言語ショックに耐えるLLMダウンストリーム回復力があります（field_method_comparison.csv）。クリーンな英語ドキュメントの大量生テキスト処理、GPUコストゼロ、CPUオンリーインフラ、または尾部レイテンシの予測可能性が必要な場合は、Tesseractが依然として正当な選択肢です。実行時間スループットは拮抗（79.7 vs 78.6ページ/分）、p95は2.2倍 Tighter、GPU課金もありません。ただし、中位のテキストベース（CER 0.3347、8つ中5位）を想定し、すべてのダウンストリームフィールドパイプラインの上限となります。これらの結果は、2026年8月に1つのGPUティアで英語およびインドネシア語のレシートに対して得られたものです。本番環境での判断前に、対象コーパスで再実行してください（制限事項を参照）。

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

すべての数値は、自社ベンチマーク公開CSVの行です。results/summary_metrics.csv（CER/WER、正規表現フィールドF1、レイテンシ、コスト、スループット。tesseract行はcompute_type=cpuでコストセルは空）と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：スコアリングパスの前に固定ウォームアップパスがあり、レイテンシ値は定常状態）で実行されました。両方の実行で、両データセットのエラー率は0.0でした（summary_metrics.csvのerror_rate列）。CPU/GPUの非対称性はこの比較に固有のものです：Tesseractは設計上、GPUアクセラレーターエンジンに対してCPU（compute_type=cpu）で実行されました。GPU時間が課金されなかったためコストセルは空で、レイテンシ/スループットは同じマシンで同じプロトコルで測定されました。基礎となる実行には合計8つのエンジンが含まれていますが、このページでは名前付きの2つのエンジンのみを比較し、他のエンジンはランキングコンテキストとして引用されています。完全な8エンジンの結果は、Traditional OCR vs Document Parsing VLMsで別途公開されています。

ランタイム環境

• ハードウェア：両エンジンは、NVIDIA RTX 4090（24 GB）を搭載した同じマシンで実行されました。GPUコストは、RunPodのオンデマンドレート$0.76/hrで計算され、価格は各実行のマニフェスト（2026年8月）に記録されています。TesseractはCPUで実行され、GPUコストは発生しません。コストセルは設計上空です。
• エンジン：デフォルト設定、ファインチューニングなし。バージョン固定：Tesseract 5.3.4（クラシックオープンソースOCRエンジン — LSTMベースの認識を用いた従来のCVパイプライン、CPU専用、システムpython3ランナー、GPU環境なし）およびPaddleOCR 3.7.0（最新の2段階深層学習OCR — PP-OCR検出＋認識、GPU）— 公開リポジトリのモデル表（README.md）および実行マニフェストに基づきます。
• LLM後処理：API経由のdeepseek-v4-flash（温度0で決定論的出力のため）。field_method_comparison.csvのllm_model列に記載。両エンジンのすべてのLLMフィールド行で使用された単一モデルです。
• コスト基準：壁時計実行時間 × $0.76/hr（モデル初期化を含む）。バッチ処理により1ページあたりのコストが低減。Tesseract（CPU専用）には適用されません。
• フィールド後処理：SROIE正規表現フィールド指標はpostprocessed_sroie_receipt_regex_*（field_method_comparison.csvのregex_*列）です。固定パターンセットでOCRテキストから抽出されたフィールドです。これらはOCR＋下流抽出を測定し、いずれかのモデルによるネイティブ構造化出力を測定するものではありません。LLM_*列はOCRテキスト＋LLM抽出を測定します。2つのパイプラインが混ざることはありません。

指標の定義

• 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ページあたり推論時間（ウォームアップ後のスコアリング、モデルロードを除く）およびモデル初期化を含む壁時計スループット。異なるクロックを測定しています。このページのp50とページ/分の一致は測定モデル上の事実であり、エラーではなく、スループット均等セクションで調整されます。
• 1,000ページあたりのコスト：記録された$0.76/hrのレートで1,000ページに対する請求済みGPU時間（モデル初期化を含む）。Tesseractのセルは空です（CPU専用）— 空のセルはnot_applicableであり、0ではありません。

ソースリスト

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、レイテンシ、コスト、スループットの数値は、このファイルのtesseractおよびpaddleocr行に由来します（tesseract: compute_type=cpu、コストセルは空）。
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 field-F1数値は、このファイルのtesseractおよびpaddleocr行（およびランキングコンテキストのすべての8つのsroie_2019 / cord_v2行）に由来します。
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）。

制限事項

• CPU/GPUの非対称性は欠陥ではなく、本質的なものです： TesseractはGPUアクセラレーションエンジンに対してCPUで実行されました。コストセルは設計上空欄です（GPU課金なし、決して0ではありません）。レイテンシ/スループットは、同じマシンで同じプロトコルで測定されたCPUの数値です。異なるマシンクラスでは動作範囲が変わる可能性があります。コスト比較は「GPU課金 vs なし」として扱い、ハードウェア非依存の真実として扱わないでください。
• ドキュメント範囲 — レシートのみ： SROIE + CORD。ここでは、Tesseractの複雑なレイアウト、テーブル、手書き、または長文ドキュメント（古典エンジンがさらに劣化することが知られているドキュメントタイプ）での動作や、PaddleOCRのPP-Structureレイアウト/テーブル機能は測定されていません。このページを使用して、いずれかのエンジンが「すべてにおいて優れている」と結論付けないでください。
• サンプルサイズ： 英語361件 + インドネシア語100件のレシート。フィールドF1とCERはコーパスに依存します。数百分の一の単桁の差はノイズとして扱うべきであり、エンジニアリングの真実として扱うべきではありません。ただし、ここに記録されている差（39% CER、1.39× regex F1、0.39ポイントのCORD LLM-F1スプレッド）はその範囲をはるかに超えています。
• 単一のGPUティアと単一の価格： すべてのGPUの数値は、ラン�マニフェストで2026年8月のタイムスタンプが付いた$0.76/hrのRTX 4090 1台から得られたものです。他のGPU、マルチGPUサービス、バッチスケジューリング、または価格変動は、レイテンシ、スループット、コストを変動させます。予算策定前に、現在のレートでコストを再計算してください。
• 単一のLLMポストプロセッサー： すべてのLLM行は、temperature 0のdeepseek-v4-flashを使用しています。異なるLLMは絶対的なフィールドF1を変動させます。1.32×のSROIEと0.39ポイントのCORDの差は、マージンで動く可能性があります。LLMレイテンシ（SROIEで中央値約1,817–1,837 ms、field_method_comparison.csv llm_median_latency_ms）はAPIによるもので、いずれかのエンジン自体のレイテンシの一部ではありません。
• 正規表現チューニング： パターンセットはデータセットごとに1回作成されました。フォーマットごとに、高度にチューニングされたパターンライブラリは、独自のレイアウトでより高いスコアを出す可能性があります。それはLLMが排除するメンテナンスコストを伴います。
• CORD CERはモデルごとの品質読み取りではありません： CORDのグランドトゥルースはアノテーション構造を埋め込んでおり、いずれのエンジンもインドネシア語を主に学習していません。CORD CER（0.91–0.95）は、言語の不一致 + グランドトゥルースの膨張を反映しています。CORDの行はフレーミング付きで引用され、SROIEのランキングには一切マージされません（プロトコルルール）。
• バージョン固定： 結果はTesseract 5.3.4およびPaddleOCR 3.7.0（2026年8月）に有効です。いずれかのエンジンの新しいリリースは、このページのすべての数値を変動させる可能性があります。特にTesseractの結果は5.3.4を反映しており、2026-08-14の繰り返し実行で再検証されています。

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

関連記事： AI OCR vs 従来のOCRの精度 · AI画像データ抽出 vs 従来のOCR · AI文書抽出の料金（2026年）