EasyOCR vs docTR on Receipts
スピード王者 vs フィールド抽出 (2026)

この2つのエンジンは、2世代のディープラーニングOCRを代表するもので、OCR対VLMの境界線ではどちらも伝統的な側面に位置します。EasyOCR（PyTorchベース、1.7.2）は、古典的なシングルパスのCNN + RNN + CTC認識器です。ResNetの特徴抽出器がシーケンスモデルに供給され、Connectionist Temporal Classificationでデコードされ、アテンションによる改良が加えられています。その設計の中心は、非常に広い言語・スクリプト対応（標準で80以上の言語）と、有名なほどシンプルなインストールです。docTR（v1.0.1）は、現代的な2段階のニューラルパイプラインです。検出段階でテキスト領域を特定し、認識段階でそれらを書き起こします。DETRスタイルのトランスフォーマー検出とトランスフォーマー認識器を中心に構築され、印刷文書の精度を重視して設計されています。文字誤り率（CER）は、挿入・削除・置換を正解文字数で割ったもので、CER 0.197は100文字あたり約19.7文字の誤読を意味します。単語誤り率（WER）は、同じ編集距離のロジックを単語単位で適用します。どちらも低いほど良いです。どちらのエンジンも視覚言語モデル（VLM）ではなく、生のテキストを出力し、構造を理解するわけではありません。

SROIE（英語レシート）でのテキスト精度：docTRの明確な優位性

SROIE 2019テスト分割の361枚の英語レシートでは、現代的なアーキテクチャが両方のテキスト指標で勝利しています。CERは0.1971対0.2833（相対改善30%）、WERは0.3199対0.6158で、EasyOCRのWERはほぼ2倍です。WERの差（48%）はCERの差（30%）よりもはるかに大きく、EasyOCRがこのコーパスで文字レベルの誤りを単語全体の失敗に累積させていることを示しています。両エンジンともエラーなしで実行されています（CSVのすべてのSROIEおよびCORD行でerror_rate 0.0）。どちらのエンジンもベンチマーク全体のCERチャンピオンではありません。その称号はSurya2（0.1915）に属し、docTR自体が2位、EasyOCRは8エンジン中4位です。

出典：summary_metrics.csv — cerおよびwer列、sroie_2019行。docTR cer 0.19707 / wer 0.31990、EasyOCR cer 0.28327 / wer 0.61578。低いほど良い。エンジンあたり361サンプル、両方ともerror_rate 0.0。

表: summary_metrics.csv — cer / wer / error_rate 列、sroie_2019 行。正確な値: docTR cer 0.19707 / wer 0.31990; EasyOCR cer 0.28327 / wer 0.61578。相対差: docTR は CER 30% 低く、WER 48% 低い。CER/WER は低いほど良い。同じ 8 エンジン実行内での CER ランキング文脈: Surya2 0.1915、docTR 0.1971、PaddleOCR 0.2045、EasyOCR 0.2833。

正規表現フィールド逆転: テキスト精度が低いほど、フィールド抽出は高い

両エンジンの生テキストを、SROIE の 4 つのレシートフィールド に対して同じ固定正規表現パターンでベンチマークします — 従来の OCR + ルールベースのキー情報抽出 (KIE) アプローチ — するとランキングが逆転します: EasyOCR は 0.1477 フィールド F1 でフィールドを抽出し、docTR の 0.0766 に対して 1.93× の優位性があり、文字精度が低いエンジンが勝ちます。これはベンチマークで繰り返し見られる「テキスト精度 ≠ フィールド精度」の逆転 — 従来の OCR と文書解析 VLM の間で docTR vs Surya2 に見られるのと同じパターン — が、同じ種類の生の行テキストを出力する 2 つの従来エンジン間でも発生しています。

フィールド値 F1 は、抽出されたフィールド値の適合率と再現率の調和平均で、正解と比較します: 1.0 はすべてのレシートフィールドが完全に復元されたことを意味し、0 は何も復元されなかったことを意味します。この逆転のメカニズムは、認識品質そのものではなく、正規表現パターンセットの特性にあります: パターンはデータセットごとに一度だけ書かれ、RM 12.00 や 14/08/2020 のような整形された値用です。docTR のクリーンだが生の行テキスト — CER では正確だが、元の大文字小文字と区切り文字のノイズを保持 — は固定パターンを打ち負かします; EasyOCR の出力は偶然それらに一致することが多いのです。「正規表現フィールド抽出」列は、ベンチマークの postprocessed_sroie_receipt_regex_* メトリクスです: OCR テキスト + 下流のルールベース抽出を測定し、ネイティブな構造化出力ではありません。フォーマットごとに高度に調整されたパターンライブラリは、どちらのエンジンでも異なるスコアになる可能性があります — パターンセットは固定された測定器であり、調整された本番パーサーではありません。

出典: field_method_comparison.csv — regex_field_value_f1 / llm_field_value_f1 列、sroie_2019 行。LLM 後処理: deepseek-v4-flash。エンジンあたり 361 サンプル (llm_ok_count)。

表: field_method_comparison.csv — 正規表現列、sroie_2019 行。これらは postprocessed_sroie_receipt_regex_* メトリクスです。各エンジンのOCR テキスト（ネイティブ抽出ではなく後処理済み）に固定パターンを適用したものです。docTR の正規表現フィールド F1 は 0.0766 で、基礎となる実行では8エンジン中2番目に低い値ですが、CER は2番目に良好です。パターンセットはデータセットごとに1回作成されており、docTR のクリーンだが生の行テキストは、これら4つのフィールドでは正規表現に適していません。

LLMレバー：逆転が決定的に覆る

両エンジンのOCRテキストをLLM後処理（deepseek-v4-flash、温度0）に構造化抽出プロンプトで渡すと、フィールド順位は逆転し、ベンチマーク全体で最大の差が生じます：docTR 0.6171 対 EasyOCR 0.3717 のフィールドF1、1.66倍の差です。docTRの結果は8エンジン中で最高のLLMフィールドF1であり、EasyOCRは最低です。正規表現パターンセットがdocTRのクリーンなテキストを不利にした一方で、LLMはそれを評価し、正規表現にたまたま適合しやすかったEasyOCRの中級テキストは、同じプロンプトで劣化します。

これは8エンジンの完全ベンチマーク全体で見られるLLM収束パターンと同じです — LLM後処理は、文字形状のマッチングではなく意味（数値、日付、名前）を理解するため、健全なエンジンを0.57〜0.62のフィールドF1帯域に引き寄せます — EasyOCRは顕著な例外です。このレバーは無料ではありません：LLM呼び出しは、OCR時間に加えてドキュメントあたり約2.0〜2.1秒の中央値レイテンシを追加します（docTRのテキストでは1,996.3ms、EasyOCRでは2,004.5ms、API起因で同種）。また、エンジンが根本的に読み取れなかったテキストを救うことはできません。しかし、このペアリングでは後処理が決定的な要素となります：パイプラインにLLMがあれば、docTRの選択が有利に働きます。

表：field_method_comparison.csv — llm_* 列、sroie_2019 行。LLMモデル：deepseek-v4-flash、温度0（llm_model列）。LLMレイテンシはAPI起因で、エンジンレイテンシ（summary_metrics.csv latency_p50_ms）とは別です。「ドキュメント全フィールド完全一致」とは、すべての対象フィールドが完全に一致したドキュメントの割合であり、フィールドごとのF1よりもはるかに厳しい基準です。EasyOCRはレシートの0.28%で4つのフィールドすべてを完全に一致させます。

EasyOCR LLMのパラドックス：中位のテキスト精度、最下位のダウンストリーム抽出

この直接対決で最も直感に反するデータポイント — PaddleOCR vs EasyOCRで初めて記録され、ここでは別の対戦相手に対して確認されました：EasyOCRのOCRテキストは文字精度で中位（SROIE CER 0.2833、8エンジン中4番目）ですが、そのテキストを他のすべてのエンジンと同じLLM後処理（deepseek-v4-flash、同じプロンプト、同じレシート）に通すと、SROIE LLMフィールドF1は0.3717で、ベンチマーク内の全8エンジン中で最低 — さらにCERが悪い（0.3347）CPUエンジンであるTesseract（0.4389）をも下回ります。変更されたのはOCRテキストのみで、LLM、プロンプト、レシートはすべて同一でした。

観察されたパターン、メカニズムは未検証。 もっともらしい仮説 — そしてそれ以上のものではありませんが — は出力形式の慣習に関するものです：EasyOCRがテキスト行をレイアウト、結合、または分離する方法が、生の文字精度とは無関係な理由で下流のLLMフィールド抽出を低下させるようです。ベンチマークはこのメカニズムを特定しておらず、結果は再現可能で安定しているものとしてここに記録されています（EasyOCRのSROIE行は2026-08-17のtorch 2.8再実行で再検証され、r1/r2/r3はバイト単位で同一；公開済みCSVにはすでに修正済みの値が含まれています）が、因果関係の主張は行われていません。docTRのよりクリーンなベーステキスト + LLMは、EasyOCRが逃す同じ帯域の最上位に位置します。

出典： field_method_comparison.csv — llm_field_value_f1、全8つのsroie_2019行、各361サンプル（llm_ok_count）。LLM後処理は全エンジンで同一：deepseek-v4-flash、温度0。CERコンテキストはsummary_metrics.csvのcer列、sroie_2019行から。

表: field_method_comparison.csv — llm_field_value_f1、全sroie_2019行。CER列はsummary_metrics.csvのcer、sroie_2019行から。docTRの0.6171はベンチマークで最高のLLMフィールドF1です。EasyOCRのCER（0.2833）は8エンジン中4位 — 中位のテキスト精度でありながら、LLM下流のフィールド復元率は最悪（0.3717、Tesseractの0.4389を下回る）。このパラドックスは観測・再現可能な事象として記録されていますが、そのメカニズムは本ベンチマークでは特定されていません。

動作環境: docTR はベンチマークの速度とコストの両方でチャンピオン

精度はどのエンジンが最もよく読むかを決定し、動作環境はどれが最初に終了するかを決定します。同じRTX 4090、同じ記録された$0.76/時間のレートで、docTRは449.3ページ/分、108.7 ms p50（1ページあたり）、$0.048/1,000ページを維持します。EasyOCRは124.5ページ/分、413.6 ms p50、$0.110/1,000ページで、3.8倍のレイテンシー差、3.6倍のスループット差、2.3倍のコスト差があり、すべてdocTRに有利です。8エンジン全体の実行を通じて、docTRの108.7 ms p50、449.3ページ/分、$0.048のコストは、測定されたどのエンジンよりも優れており、docTRはベンチマークで最速かつ最も安価なエンジンです。

コストは、ウォールクロック実行時間×RunPod RTX 4090レート（$0.76/時間、実行マニフェストにタイムスタンプ付きの価格）として計算され、モデルの初期化を含みます。これは、GPU時間に対して実際に支払う価格です。スループットは、同じ初期化を含むウォールクロックの1分あたりのページ数です。レイテンシーp50/p95は、ウォームアップ後にスコアリングされた定常状態の1ページあたりの推論時間です（モデルの読み込みは除く）。EasyOCRのテールは比例的に悪く、960.4 ms p95（docTRの281.4 msに対して）で、3.4倍の差があります。EasyOCRは、測定された他のほとんどのエンジンよりも依然として本当に安価です（その$0.110は、ベンチマークで2番目に低い1,000ページあたりの数値で、docTRに次ぐものです）。つまり、中程度のコストと中程度の速度であり、高価でも遅くもありません。

出典: summary_metrics.csv — latency_p50_ms / latency_p95_ms列、sroie_2019行。docTR p50 108.72 / p95 281.38; EasyOCR p50 413.64 / p95 960.37。定常状態のレイテンシー（warm_then_scored測定モード、モデルの読み込みは除く）。

出典: summary_metrics.csv — cost_per_1000_pages列、sroie_2019行。docTR 0.0479、EasyOCR 0.1098。コスト = ウォールクロック実行時間×$0.76/時間（モデル初期化を含む）、実行マニフェストにタイムスタンプ付きの価格（2026年8月）。docTRの$0.048はベンチマークで最も低い1,000ページあたりのコストであり、EasyOCRの$0.110は2番目に低い値です（summary_metrics.csv、cost_per_1000_pages、すべてのsroie_2019行）。

表: 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; EasyOCR p50 413.64 / p95 960.37 / 124.53 pg/min / $0.1098。ベンチマーク全体での最良値: docTR は全8エンジン中、最低の p50 レイテンシ、最高のページ/分、最低コストを記録（summary_metrics.csv、sroie_2019 行）。

CORD（インドネシアのレシート）：両エンジンともテキストで崩壊、LLMの差は拡大

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

フィールド指標はSROIEのパターンが拡大・増幅されていることを示しています。LLM後処理を通じて、docTRのフィールドF1はCORDで0.5500を維持し、EasyOCRの0.3378に対して1.63倍の差があります。これはSROIEの1.66倍と同じ順序であり、両方のテキスト認識エンジンが文字レベルで失敗している場合でも同様です。正規表現パターンを通じて、docTRはフィールドを一切回復できません（0.0000フィールドF1 — CSV内の文字通りのゼロであり、欠損値ではありません）。英語形式のパターンがインドネシア語テキストに何も一致しなかったためです。一方、EasyOCRは0.0067を取得します。docTRのコスト優位性もCORDでは縮小・逆転します（$0.094 vs EasyOCRの$0.086、1,000ページあたり）— しかし、そのウォールクロックスループットの優位性は500.4 vs 211.8ページ/分（2.4倍）に拡大します。CORDは言語堅牢性の文脈のためにここで引用されており、SROIEの数値と単一のリーダーボードに意図的に統合されることはありません。

表: summary_metrics.csv（cer / pages_per_minute / cost_per_1000_pages）および field_method_comparison.csv（フィールドF1）、cord_v2 行。SROIE のランキングに CORD の数値を混ぜないでください：CORD の CER は、言語の不一致とアノテーション構造のインフレーションが組み合わさったものです。正規表現パターンは英語形式用に書かれているため、両エンジンで正規表現フィールドの F1 が約 0〜1% に落ち込みます。docTR の 0.0000 は CSV に記録された文字通りのゼロであり、欠損値ではありません。LLM フィールド F1 の差（0.5500 対 0.3378）は SROIE のパターンを言語横断的に拡張しており、コスト順は逆転し（EasyOCR $0.086 対 docTR $0.094）、スループットの差は広がります（2.4倍）。

どちらが勝つか：まとめ表

「優れている」はワークロード次第であり、この直接比較は軸を明確に分けています：生テキスト精度、LLM ダウンストリームフィールド、速度、スループット、コストはすべて docTR に軍配が上がります。固定正規表現によるフィールド抽出とデプロイのしやすさは EasyOCR に軍配が上がります。ただし、EasyOCR の LLM ダウンストリーム結果は最大のリスクであり、売りポイントではないことに注意が必要です。

よくある質問

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

はい、このベンチマークのすべての生テキストおよびフィールド抽出精度の指標において。SROIE 2019では：CER 0.1971 vs 0.2833（30%低い）、WER 0.3199 vs 0.6158（48%低い）、LLM後処理フィールドF1 0.6171 vs 0.3717（1.66倍、8エンジン中最高 vs 最低）— ただし正規表現フィールドF1ではEasyOCRが0.1477 vs 0.0766で勝っています（summary_metrics.csvおよびfield_method_comparison.csvのsroie_2019行）。どちらのエンジンもベンチマーク全体のCERチャンピオンではありません— Surya2（0.1915）がわずかな差でそのタイトルを保持しています。

なぜdocTRはテキスト精度が高いのに、EasyOCRよりも正規表現フィールド抽出が悪いのですか？

2つの指標が固定された測定手段に対して異なる出力を評価するためです。docTRはクリーンな生の行テキストを返します— CERでは正確ですが、元の大文字小文字と区切り文字を保持します— そして、データセットごとにフォーマット済み値用に一度書かれた固定正規表現パターンは、それに対してほとんど失敗します：SROIE正規表現フィールドF1 0.0766（field_method_comparison.csv、regex_field_value_f1、doctr/sroie_2019行）。EasyOCRの出力は0.1477でパターンに一致します。両方をLLMに渡すと、ギャップは逆転してdocTRが1.66倍有利になります— ボトルネックはOCRではなく正規表現パターンセットでした。

EasyOCRは文字精度がそこそこなのに、なぜLLMフィールド抽出が最悪なのですか？

これはベンチマークで文書化されたパラドックスであり、現在証明されたメカニズムはありません。 EasyOCRのSROIE CER（0.2833）は8エンジン中4位ですが、LLM後処理フィールドF1（0.3717）は最下位です— より悪いCERを持つTesseract（0.4389）よりも下です。主要な仮説は、EasyOCRがテキスト行をレイアウトまたは結合する方法における出力形式の慣習が、下流のLLM抽出を劣化させるというものです。これは観察され再現可能なパターンとしてラベル付けされており、メカニズムは未検証です（field_method_comparison.csv、llm_field_value_f1、sroie_2019行）。同じパラドックスがPaddleOCR vs EasyOCRの別の対戦相手に対しても文書化されています。

docTRはEasyOCRよりどのくらい速く、安いのでしょうか？

3.8倍低いp50レイテンシ（108.7ms対413.6ms）、3.4倍低いp95（281.4ms対960.4ms）、3.6倍高いスループット（449.3対124.5ページ/分）、そして2.3倍低い1,000ページあたりのコスト（$0.048対$0.110）を、同じRTX 4090、$0.76/時間で実現しています（summary_metrics.csv、latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages、sroie_2019行）。docTRは、このベンチマークにおいて、3つの指標すべてで最速かつ最安のエンジンです。EasyOCRは中程度のコスト（2番目に安い）で、中程度の速度（2番目に速いスループット）です。

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

ベンチマークプロトコルがSROIEランキングから分離している2つの複合的な原因があります：真の言語ミスマッチ（両エンジンのトレーニング焦点の外にあるインドネシアのレシート）と、CORDのグラウンドトゥルーステキスト内のアノテーション構造のインフレーションです — CERは0.9101（docTR）と0.9185（EasyOCR）に達します（summary_metrics.csv、cer、cord_v2行）。それでも両者を分けるのはLLMダウンストリームの回復力です：docTR 0.5500 対 EasyOCR 0.3378 のフィールド値F1 — SROIEのパターンは、両方の認識エンジンが文字レベルで失敗しても、持続し、さらに拡大します。

レシートパイプラインはどちらのエンジンを選ぶべきでしょうか、EasyOCRかdocTRか？

計測されたコストで大量の抽出フィールドを目標とするパイプラインにとって、docTRはこのコーパスで優位です：より良い生テキスト（CERが30%低い）、あらゆるエンジンの中で最高のLLMダウンストリームフィールド（0.6171対0.3717）、そして2.3倍のコスト優位性、3.6倍のスループット、3.8倍のレイテンシ — 4つの軸すべてを同時に達成しています（summary_metrics.csv / field_method_comparison.csv、sroie_2019行）。EasyOCRは、クリーンなドキュメントに対する安価で、インストールが簡単で、多言語対応の一括OCRがタスクであり、正規表現抽出や適度な量の生テキストで、LLMダウンストリームのフィールド品質がそれほど重要でない場合には、依然として正当な選択肢です — ただし、コミットする前に、測定された弱いLLMダウンストリームの予算を立ててください。これらの結果は、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 でホストされており、各実行には環境フィンガープリント用の編集済み manifest.json が1件付属しています。データセットの定義は、下記のSROIE 2019およびCORDの論文に基づいています。

方法論と情報源

プロトコル

このページは、独立した再現可能なベンチマーク実行（公式ティア）の一対一の比較スライスを報告しています — 第三者による主張の調査でも、ベンダー比較ページでもありません。固定テスト分割のみを使用：SROIE 2019テスト（英語レシート361件、フラットフィールド company/date/address/total）およびCORD v2テスト（インドネシア語レシート100件、ネストフィールド menu/sub_total/total）；トレーニング分割は評価していません。両エンジンは同じ画像、同じグラウンドトゥルース、同じ測定プロトコル（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月）にタイムスタンプされています。
• エンジン： 標準設定で、ファインチューニングなし。バージョン固定：EasyOCR 1.7.2（従来型 CNN + RNN + CTC 認識器、ResNet特徴抽出器、GPU）および docTR v1.0.1（最新の2段階ニューラルOCR — DETRスタイルトランスフォーマー検出＋認識、GPU）— 公開リポジトリのモデルテーブル（README.md）と実行マニフェストに基づきます。EasyOCRのSROIE行は、2026-08-17のtorch 2.8再実行（繰り返し実行 r1/r2/r3 はバイト単位で同一）で再検証されました；公開CSVには修正後の値が含まれています。
• LLM後処理： 決定的出力のため温度0でAPI経由の deepseek-v4-flash（field_method_comparison.csv の llm_model 列）；両エンジンのすべてのLLMフィールド行で使用された唯一のモデルです。
• コスト基準： ウォールクロック実行時間 × $0.76/時間、モデル初期化を含む — バッチ処理によりページあたりのコストが下がります。
• フィールド後処理： SROIE正規表現フィールドメトリクスは postprocessed_sroie_receipt_regex_*（field_method_comparison.csv の regex_* 列）— データセットごとに1回記述された固定パターンセットによって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 & ページ/分: 定常状態の1ページあたりの推論時間（ウォームアップ後に計測、モデル読み込みは除外）と、モデル初期化を含む実時間スループット。これらは異なる時計で測定されます。
• 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、レイテンシ、コスト、スループット数値は、ここにあるeasyocrとdoctrの行に由来します。
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数値は、ここにあるeasyocrとdoctrの行（およびパラドックステーブルの8つのsroie_2019行すべて）に由来します。
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 です。ここでは、EasyOCR の80以上の言語対応がレシート以外のテキストでどのように機能するか、docTR がテーブル・フォーム・長文ドキュメントでどのように動作するか、その他のドキュメントタイプについては一切測定していません。このページをもとに、どちらかのエンジンが「すべてにおいて優れている」と結論付けないでください。
• サンプルサイズ: 英語361枚 + インドネシア語100枚のレシートです。フィールド F1 と CER はコーパスに依存します。数百分の一の一桁台の差はノイズとして扱い、工学的な真実とは見なさないでください。ただし、ここで記録された差（CER 30%、WER 48%、LLM F1 1.66倍）はその範囲をはるかに超えています。
• 単一の GPU ティアと単一の価格: すべての数値は、実行マニフェストに記録された2026年8月時点の価格である $0.76/hr の1台の RTX 4090 に基づいています。他の GPU、マルチGPUサーバー、バッチスケジューリング、または価格変更により、レイテンシ、スループット、コストは変動します。予算を立てる前に、現在のレートでコストを再計算してください。
• 単一の LLM 後処理: すべての LLM 行は temperature 0 の deepseek-v4-flash を使用しています。別の LLM を使用すると、絶対的なフィールド F1 が変わります。EasyOCR のパラドックスの大きさは LLM によって変動する可能性がありますが、観測されたパターンは、この単一の後処理装置で両方のデータセットにわたって一貫していました。LLM のレイテンシ（SROIE で中央値約2.0〜2.1秒、field_method_comparison.csv の llm_median_latency_ms）は API によるものであり、どちらのエンジン自体のレイテンシには含まれません。
• EasyOCR パラドックスのメカニズムは未検証: このベンチマークは、EasyOCR の中間ティアの CER テキストが LLM ダウンストリームのフィールド復元率で最悪の結果（SROIE 0.3717 / CORD 0.3378）を生むことを記録しています。これは、出力テキストのレイアウト規則という仮説の下での観測可能で再現可能な結果であり、因果メカニズムは明示的に特定されていません。これは、ライブラリの証明された特性としてではなく、計画を立てるための測定結果として扱ってください。
• 正規表現チューニング: パターンセットはデータセットごとに一度だけ作成されました。フォーマットごとに高度にチューニングされたパターンライブラリは、自身のレイアウトでより高いスコアを獲得できる可能性がありますが、それは LLM が排除するメンテナンスコストがかかります。docTR の正規表現フィールドの不利（0.0766 vs 0.1477）は、この固定された測定器の特性であり、チューニングされたパーサーが復元できるという主張ではありません。
• CORD CER はモデル品質の指標ではありません: CORD の正解データには注釈構造が埋め込まれており、どちらのエンジンも主にインドネシア語でトレーニングされたわけではありません。CORD CER（約0.91）は、言語の不一致と正解データの水増しを反映しています。CORD の行は文脈を明記して引用され、SROIE のランキングには決して統合されません（プロトコル規則）。
• 2つのエンジンのみ: この直接比較では、基礎となる実行の他の6つのエンジン、クラウド/API OCR サービス、ホスト型 VLM API を意图的に除外しています。それらのレイテンシと価格モデルは、ここで測定されたローカルエンジンとは根本的に異なります。
• バージョン固定: 結果は EasyOCR 1.7.2 と docTR v1.0.1（2026年8月）に基づいています。どちらかのエンジンの新しいリリースにより、このページのすべての数値が変わる可能性があります。

関連リファレンス: PaddleOCR vs EasyOCR レシートベンチマーク · docTR vs Surya2 レシートベンチマーク · Traditional OCR vs Document Parsing VLMs · パターンマッチング vs モデルベースのフィールド抽出 · 文字単位ではなくフィールド単位で精度を測定する · 1,000ページあたりのOCRコスト

関連記事： AI OCRの精度が従来のOCRと異なる理由 · 画像においてAI抽出がOCRを上回る理由 · AIドキュメント抽出の価格（2026年）