レシートにおけるTesseract vs PaddleOCR
レガシーCPU vs 最新GPU（2026年）

2つのエンジンの違い：35年のOCR vs CNN2段階パイプライン

このページの全体的なストーリーはアーキテクチャの差です。Tesseractは、1980年代にHPで開発され、2005年にGoogleがオープンソース化した古典的なオープンソースOCRエンジンであり、約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（3位）、easyocr 0.2833、Tesseract 0.3347（5位）、paddleocr_vl 0.3370、docling 0.5909、unlimited_ocr 0.6552 です。ここで取り上げたエンジンはいずれもベンチマークの精度チャンピオンではありません — docTR と Surya2 が CER の上位2位を占めています。

フィールド抽出：本番導入の判断を左右する差

テキスト精度はエンジンの評価に役立ちますが、下流システムが実際に利用するのはフィールド抽出です。このベンチマークの SROIE フィールド指標は、4つの平文レシートフィールド（会社名、日付、住所、合計）を対象とし、各エンジンの OCR テキストに対して2種類の後処理を適用しています：固定の正規表現パターン（従来の 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）。

Table: field_method_comparison.csv — regex と llm 列、sroie_2019 行。regex 列は postprocessed_sroie_receipt_regex_* メトリクスです。各エンジンのOCRテキストに適用される固定パターンです。LLM後処理: deepseek-v4-flash、温度0（llm_model列）。LLMレイテンシはAPI経由で発生し、エンジンのレイテンシとは別です（summary_metrics.csv latency_p50_ms）。「全フィールド完全一致の文書」とは、すべての対象フィールドが完全に一致した文書の割合であり、フィールドごとのF1よりもはるかに厳しい基準です。ランキングの文脈（llm_field_value_f1、全sroie_2019行）: PaddleOCR 0.5810は8件中5位、Tesseract 0.4389は7位で、EasyOCRの0.3717より上位です。

驚きの発見: ウォールクロックでのCPUスループット同等性

このページで最も注目すべき発見は、他社の第三者比較では誰も文書化していない点です。同じレシートにおいて、CPUのみのクラシックエンジンが、最新のGPUエンジンとウォールクロックの1分あたりページ数で同等であることです — 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 — 1ページあたり約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/ページ、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。定常状態レイテンシ（warm_then_scored測定モード、モデル読み込みを除く）。p50とページ/分の乖離は上記の本文で整合しています: 異なる時計、どちらも実測値です。

表: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute、sroie_2019行。正確な値: Tesseract p50 670.87 / p95 1506.99 / 78.63ページ/分; PaddleOCR p50 296.99 / p95 3331.35 / 79.71ページ/分。レイテンシはページあたりの定常状態（ウォーム後スコアリング、モデル読み込みを除く）; ページ/分は初期化とバッチ効果を含むウォールクロック — 同等性とp95の逆転は、測定モデルとアーキテクチャの事実であり、矛盾ではありません。

コストの実態：レガシーエンジンが圧倒的に勝つ領域

コストは、Tesseractの古さが利点となる唯一の軸であり、それは構造的なものです：TesseractはCPU専用のため、CSVのコスト欄は設計上空白です — GPU課金の計測対象がありません — 一方、PaddleOCRは同じRTX 4090で記録上の$0.76/時間のレートで1,000ページあたり$0.2214を請求します。スループット連動型のワークロード（上記の同等条件）では、GPU課金に慎重なインフラにおけるクラシックエンジンの運用コストは実質的に低くなります — 「アップグレードする価値があるか」という判断の価格基準となります。

コストは、ウォールクロック実行時間 × RunPod RTX 4090レート（$0.76/時間、実行マニフェストに価格のタイムスタンプあり）で計算され、モデル初期化を含みます。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/時間（モデル初期化を含む）、価格は実行マニフェストにタイムスタンプ付きで記録（2026年8月）。ベンチマークで最安のGPUエンジン：docTR、1,000ページあたり$0.048（doctr/sroie_2019行）。

表：summary_metrics.csv — cost_per_1000_pages / compute_type列、sroie_2019行。Tesseractのコスト欄は、エンジンがCPU専用のため空白です（空欄であり、0.0000ではありません）；PaddleOCRのGPUコストには記録上の$0.76/時間でのモデル初期化が含まれます。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）読み取れないほどであり、いかなる後処理（regexまたはLLM）でもフィールドを復元できません。LLMレバーは役立ちます（TesseractのSROIE F1はregexの0.2335からLLMの0.4389に上昇）が、より弱い基盤から始まり、エンジンが読まなかったテキストを作り出すことはできません。CORDは言語堅牢性の文脈としてここで引用されており、SROIEの数値と単一のリーダーボードに統合されることは意図的にありません。

表: summary_metrics.csv（cer / cost_per_1000_pages / pages_per_minute）および field_method_comparison.csv（フィールド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ではありません。

誰が勝つか：総括グリッド

「より良い」はワークロード次第であり、この直接対決は軸を異常なほど明確に分けています：すべての精度軸でPaddleOCRが優位、コスト・CPUのシンプルさ・タイトなp95テールではTesseractが優位、ウォールクロックのスループットは統計的に引き分け、ページあたりのレイテンシではPaddleOCRが優位、そして生のCERチャンピオンシップはどちらにも属しません（docTR/Surya2）。

よくある質問

領収書の認識精度は、TesseractよりPaddleOCRの方が高いですか？

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

CPUのみで動作するTesseractが、なぜPaddleOCRと1分あたりの処理ページ数で並ぶのですか？

1分あたりの処理ページ数は実測スループットであり、1ページあたりの推論速度ではないからです。 PaddleOCRの定常状態のp50（297.0 ms）はTesseract（670.9 ms）より確かに2.3倍高速ですが、実測スループットにはモデルの初期化とバッチ効果が含まれます：79.7ページ/分でPaddleOCRは1ページあたり約753 msの実測時間に対しp50は297 ms、一方TesseractのCPUランタイムは1ページあたり約763 msに対しp50は671 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専用のため、CSV内のコスト欄は設計上空白です（0ではありません）。一方、PaddleOCRは同じRTX 4090（$0.76/時間、モデル初期化コスト込み）で、SROIEでは1,000ページあたり$0.2214、CORDでは$0.3419が請求されます（summary_metrics.csv、cost_per_1000_pages、sroie_2019およびcord_v2行）。ベンチマーク全体で最も安いGPUエンジンはdocTRで、1,000ページあたり$0.048です。

なぜ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下流での回復力です：フィールドF1はPaddleOCR 0.5527 対 Tesseract 0.1627 — ベンチマーク内で最も広い兄弟行間ギャップです。CORD行は枠組みを付けて引用され、いかなる統合ランキングにもプールされることはありません。

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

パイプラインがフィールド（会社名、日付、合計金額などの抽出値）を利用する場合、レシートではPaddleOCRが明確なデフォルトです。正規表現ではフィールドF1が1.39倍、LLMでは1.32倍となり、CORDの言語ショックにも耐えるLLMダウンストリームの回復力があります（field_method_comparison.csv）。GPUコストゼロ、CPUのみのインフラ、またはテールレイテンシーの予測可能性を備えた、クリーンな英語ドキュメントでの大量の生テキストが必要な場合は、Tesseractも依然として有力な選択肢です。スループットは同等（79.7対78.6ページ/分）、p95は2.2倍タイト、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（正規表現と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列）。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後処理: deepseek-v4-flashをAPI経由で温度0に設定し、決定的な出力を実現（field_method_comparison.csvのllm_model列）。両エンジンのすべてのLLMフィールド行に使用された唯一のモデルです。
• コスト基準: ウォールクロック実行時間 × $0.76/hr、モデル初期化を含む — バッチ処理によりページあたりのコストが低下。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はフィールド値が一切回収されなかったことを意味します。
• フィールド値F1（LLM）: LLM後処理の出力に対する同じメトリクス（OCRテキスト → deepseek-v4-flash → フィールド）。列: llm_field_value_f1。 2つのパイプラインは異なり、決して混在しません。
• 文書フィールド完全一致: すべての対象フィールドが完全に一致した文書の割合 — フィールドごとのF1よりもはるかに厳しい基準です。
• レイテンシp50/p95 & ページ/分: 定常状態のページあたり推論時間（ウォームアップ後にスコアリング、モデル読み込みを除外）と、モデル初期化を含むウォールクロックスループット。 これらは異なる時計を測定しています。 このページの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フィールド値の精度とF1、document-fields-exact、llm_median_latency_ms、トークン数。すべてのregex/LLMフィールドF1数値は、ここのtesseract行とpaddleocr行（およびランキング文脈における全8つのsroie_2019 / cord_v2行）に由来します。
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）。

制限事項

• CPU/GPUの非対称性は本質的なものであり、欠陥ではありません： TesseractはCPU上で動作し、GPUアクセラレーションを利用するエンジンと比較されました。そのコストセルは設計上空白です（GPU請求なし、0ではありません）。レイテンシとスループットは、同じマシン、同じプロトコルで測定されたCPU数値であり、異なるマシンクラスでは動作範囲が変わる可能性があります。コスト比較は「GPU請求あり vs なし」として捉え、ハードウェアに依存しない真実として扱わないでください。
• ドキュメント範囲 — レシートのみ： SROIE + CORD。ここでは、複雑なレイアウト、表、手書き、長文ドキュメント（従来のエンジンがさらに劣化することが知られているドキュメントタイプ）におけるTesseractの動作や、PaddleOCRのPP-Structureレイアウト/テーブル機能は測定されていません。このページを使用して、どちらかのエンジンが「すべてに勝つ」と結論付けないでください。
• サンプルサイズ： 英語361件 + インドネシア語100件のレシート。フィールドF1とCERはコーパスに依存します。数百分の1の一桁台の差はノイズとして扱うべきであり、工学的な真実ではありません — ただし、ここで記録された差（CER 39%、正規表現F1の1.39倍、CORD LLM-F1の0.39ポイント差）はその範囲をはるかに超えています。
• 単一のGPUティアと単一の価格： すべてのGPU数値は、1台のRTX 4090、$0.76/時間、価格は2026年8月の実行マニフェストにタイムスタンプされたものです。他のGPU、マルチGPUサービス、バッチスケジューリング、または価格変更により、レイテンシ、スループット、コストが変動します — 予算を立てる前に現在のレートでコストを再計算してください。
• 単一のLLM後処理： すべてのLLM行は、温度0のdeepseek-v4-flashを使用しています。異なるLLMは絶対的なフィールドF1を変えます。SROIEの1.32倍とCORDの0.39ポイントの差は、わずかに変動する可能性があります。LLMレイテンシ（SROIEで中央値約1,817–1,837ミリ秒、field_method_comparison.csv llm_median_latency_ms）はAPIによるものであり、どちらのエンジン自体のレイテンシには含まれません。
• 正規表現のチューニング： パターンセットはデータセットごとに一度だけ作成されました。フォーマットごとに高度にチューニングされたパターンライブラリは、独自のレイアウトでより高いスコアを獲得できる可能性があります — ただし、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とVLMの8エンジン比較 · フィールドに対する固定ルールと言語モデル · 正しい文字数でもフィールドが間違っている可能性がある理由

関連記事： AIと従来のOCRの精度の差 · 画像においてAI抽出がOCRに勝る理由 · AI文書抽出の価格（2026年）