EasyOCR vs docTR on 領収書
速度チャンピオン vs フィールド抽出 (2026)
最終レビュー: 2026-08-18 · ランナー層: 公式 · 初の自社ヘッド・トゥ・ヘッドベンチマーク · 2エンジン × 2領収書データセット
このページの対象外: 領収書以外のあらゆるドキュメントタイプ――テーブル、フォーム、請求書、契約書、長文ドキュメントは対象外です。クラウド/API OCRサービス、ファインチューニングされたエンジン、およびベンチマークの他の6つのエンジン(Tesseract、PaddleOCR、Docling、Surya2、Unlimited-OCR、PaddleOCR-VL)は、ランキングコンテキストとして引用される場合を除き対象外です。完全な8エンジンまとめは従来OCR vs ドキュメントパーシングVLMに掲載されています。
範囲声明:このページのすべての数値は領収書のみに適用されます――SROIE 2019英語領収書とCORD v2インドネシア語領収書。ハードウェア層1つ(RTX 4090、$0.76/hr、価格は2026年8月時点)、LLM後処理プロセッサ1つ(deepseek-v4-flash、temperature 0)、固定モデルバージョン(EasyOCR 1.7.2、docTR v1.0.1)。これらの結果を他のドキュメントタイプ、GPU、またはLLMに外挿しないでください――ベンチマークは領収書OCRと領収書フィールド抽出のみを測定します。すべての数値はベンチマークのresults/summary_metrics.csvおよびresults/field_method_comparison.csvから取得しており、公開GitHubリポジトリにミラーリングされ、行単位で引用されています。
クリーンな英語レシートでは、モダンアーキテクチャがテキスト品質で圧勝します:docTRのSROIE CER 0.1971 対 EasyOCRの 0.2833(30%低い)、WER 0.3199 対 0.6158(48%低い)。しかし、両エンジンのテキストを同じ固定正規表現パターンに通すと、順位は逆転します:EasyOCRはフィールド抽出率が 1.93倍 高い(フィールドF1 0.1477 対 0.0766)――これはベンチマークにおける「テキスト精度 ≠ フィールド精度」の逆転現象で、今度は2つの従来型エンジンの間で発生しています。LLMポストプロセッサを追加すると、逆転は再び決定的に覆ります:docTR 0.6171(8エンジン中最高)対 EasyOCR 0.3717(8エンジン中最低)――1.66倍の差であり、ベンチマークで最大級のLLMフィールドF1差の一つです。動作範囲はdocTRが完全に支配します:3.8倍 高速なp50(108.7対413.6 ms)、3.6倍 高いスループット(449.3対124.5ページ/分)、2.3倍 安い(1,000ページあたり $0.048 対 $0.110)――両軸でベンチマーク最速かつ最安のエンジンです。
そのトレードオフを一対の数字で表すと:docTRはレシート1ページを 108.7 ms のp50で読み取り、1,000ページあたり $0.048 で、LLMポストプロセッサを通じてフィールドを 0.6171 F1 で抽出します。一方、EasyOCRは 413.6 ms のp50で読み取り、1,000ページあたり $0.110 で、LLM下流のフィールドF1は 0.3717 にまで崩壊します――テストした8エンジン中最低です。同じレシート、同じテスト分割、同じRTX 4090。どちらのエンジンも「勝者」とは言えません。EasyOCRは正規表現フィールド抽出の優位性と導入しやすさを維持し、docTRはここで測定されたすべての精度、速度、コスト軸で勝利します。
2つのエンジンは、深層学習OCRの2世代を代表し、どちらもOCR対VLMの区分における従来型に分類されます。EasyOCR(PyTorchベース、1.7.2)は、古典的な単一パスCNN + RNN + CTC認識器です。ResNet特徴抽出器がシーケンスモデルに入力され、接続主義時系列分類でデコードされ、アテンションベースのリファインメントが施されます。その設計中心は、非常に広範な言語と文字カバレッジ(標準で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。
| 指標(SROIE 2019、n=361) | docTR | EasyOCR | 出典 |
|---|---|---|---|
| 文字誤り率(CER) | 0.1971 | 0.2833 | summary_metrics.csv · cer、doctr/sroie_2019およびeasyocr/sroie_2019行 |
| 単語誤り率(WER) | 0.3199 | 0.6158 | summary_metrics.csv · wer、同じ行 |
| エラー率(失敗ページ) | 0.0 | 0.0 | summary_metrics.csv · error_rate、同じ行 |
テーブル: 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。
正規表現フィールドの反転: テキストは劣るが、フィールドの回復性は高い
4 つの SROIE レシートフィールド(会社名、日付、住所、合計)に対して、2 つのエンジンの生テキストを同じ固定正規表現パターンでベンチマークします — これは従来の OCR + ルールベースの重要情報抽出 (KIE) アプローチです — するとランキングが反転します: EasyOCR は 0.1477 フィールド F1 でフィールドを抽出し、docTR は 0.0766 です。これは文字精度が低いエンジンにとって 1.93× の優位性です。これはベンチマークで繰り返し見られる「テキスト精度 ≠ フィールド精度」の反転です — docTR vs Surya2 で従来の OCR とドキュメントパース VLM の間に見られたのと同じパターン — 今度は同じ種類の生行テキストを出力する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)。
| 正規表現後処理(SROIE 2019、n=361) | docTR | EasyOCR | 出典 |
|---|---|---|---|
| フィールド値 F1(正規表現) | 0.0766 | 0.1477 | field_method_comparison.csv · regex_field_value_f1、doctr/sroie_2019 および easyocr/sroie_2019 行 |
| フィールド値精度(正規表現) | 0.0623 | 0.1267 | field_method_comparison.csv · regex_field_value_accuracy、同じ行 |
| ドキュメントフィールド完全一致(正規表現) | 0.0000 | 0.0000 | field_method_comparison.csv · regex_document_fields_exact、同じ行 |
表:field_method_comparison.csv — 正規表現列、sroie_2019 行。これらは postprocessed_sroie_receipt_regex_* 指標です。各エンジンの OCR テキスト(後処理済み、ネイティブ抽出ではなく)に固定パターンを適用したものです。docTR の正規表現フィールド F1 は 0.0766 で、基礎となる実行における全 8 エンジン中 2 番目に低い値ですが、CER は 2 番目に優れています — パターンセットはデータセットごとに一度だけ作成され、docTR のクリーンだが生の行テキストは、この 4 つのフィールドでは正規表現に適していません。
LLMのレバー:決定的な逆転
両エンジンのOCRテキストを、構造化された抽出プロンプト付きのLLMポストプロセッサ(temperature 0のdeepseek-v4-flash)に渡すと、フィールドランキングは再び逆転します。これはベンチマーク内の全ペアリングの中で最大の差です: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時間に加えて、1文書あたり約2.0〜2.1秒の中央値レイテンシを追加します(docTRのテキストで1,996.3 ms、EasyOCRで2,004.5 ms、APIによるもので種類は同一)。また、エンジンが根本的に読み取れなかったテキストを救うものではありません。しかし、このペアリングにおいて、ポストプロセッサは決定的なコンポーネントとなります。パイプラインにLLMが含まれることで、docTRの選択は複利効果を生みます。
| LLMポスト処理(SROIE 2019、n=361) | docTR | EasyOCR | 出典 |
|---|---|---|---|
| フィールド値F1(LLM) | 0.6171 | 0.3717 | field_method_comparison.csv · llm_field_value_f1、doctr/sroie_2019およびeasyocr/sroie_2019行 |
| フィールド値精度(LLM) | 0.6170 | 0.3712 | field_method_comparison.csv · llm_field_value_accuracy、同じ行 |
| 文書フィールド完全一致(LLM) | 0.1496 | 0.0028 | field_method_comparison.csv · llm_document_fields_exact、同じ行 |
| LLMポスト処理レイテンシ中央値(ms) | 1,996.3 | 2,004.5 | field_method_comparison.csv · llm_median_latency_ms、同じ行 |
表:field_method_comparison.csv — llm_*列、sroie_2019行。LLMモデル:temperature 0のdeepseek-v4-flash(llm_model列)。LLMレイテンシはAPIによるもので、エンジンレイテンシとは別です(summary_metrics.csv latency_p50_ms)。「文書フィールド完全一致」は、すべての対象フィールドが完全に一致した文書の割合です。これはフィールドごとのF1よりもはるかに厳しい基準です。EasyOCRは領収書の0.28%で4つのフィールドすべてを完全に正しく取得しています。
EasyOCR LLMパラドックス:中程度のテキスト精度、最悪のダウンストリーム抽出
このヘッド・トゥ・ヘッド比較で最も直感に反するデータポイント――PaddleOCR vs EasyOCRで初めて記録され、ここでも異なる対戦相手 against で確認されたもの:EasyOCRのOCRテキストは文字精度では中程度(SROIE CER 0.2833、8エンジン中4位)――しかし、そのテキストを他の全エンジンと同じLLMポストプロセッサー(deepseek-v4-flash、同じプロンプト、同じレシート)に渡すと、SROIE LLMフィールドF1は0.3717と、ベンチマーク内の全8エンジンで最低――CERがより悪い(0.3347)CPUエンジンのTesseract(
出典:field_method_comparison.csv ― llm_field_value_f1、全8 sroie_2019行、各361サンプル(llm_ok_count)。LLMポストプロセッサーは全エンジン同一:temperature 0のdeepseek-v4-flash。CERコンテキストはsummary_metrics.csv、cer列、sroie_2019行より。
| 全8エンジン、SROIE 2019(各n=361) | SROIE CER | SROIE LLM フィールド F1 | 出典 |
|---|---|---|---|
| docTR v1.0.1 | 0.1971 | 0.6171 | field_method_comparison.csv · doctr/sroie_2019 行、llm_field_value_f1(cer: summary_metrics.csv) |
| surya2 | 0.1915 | 0.6139 | field_method_comparison.csv · surya2/sroie_2019 行、llm_field_value_f1(cer: summary_metrics.csv) |
| unlimited_ocr | 0.6552 | 0.6054 | field_method_comparison.csv · unlimited_ocr/sroie_2019 行、llm_field_value_f1(cer: summary_metrics.csv) |
| paddleocr_vl_vllm | 0.3370 | 0.5921 | field_method_comparison.csv · paddleocr_vl_vllm/sroie_2019 行、llm_field_value_f1(cer: summary_metrics.csv) |
| paddleocr | 0.2045 | 0.5810 | field_method_comparison.csv · paddleocr/sroie_2019 行、llm_field_value_f1(cer: summary_metrics.csv) |
| docling | 0.5909 | 0.5685 | field_method_comparison.csv · docling/sroie_2019 行、llm_field_value_f1(cer: summary_metrics.csv) |
| tesseract (CPU) | 0.3347 | 0.4389 | field_method_comparison.csv · tesseract/sroie_2019 行、llm_field_value_f1(cer: summary_metrics.csv) |
| EasyOCR 1.7.2 | 0.2833 | 0.3717 | field_method_comparison.csv · easyocr/sroie_2019 行、llm_field_value_f1(cer: summary_metrics.csv) |
表: 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/hr レートにおいて、docTR は 449.3 ページ/分、1ページあたり 108.7 ms p50、1,000ページあたり $0.048 を維持します。一方、EasyOCR は 124.5 ページ/分、413.6 ms p50、1,000ページあたり $0.110 を維持します。これは、docTR に有利な 3.8倍 のレイテンシ差、3.6倍 のスループット差、2.3倍 のコスト差を意味します。全8エンジンの実行を通じて、docTR の 108.7 ms p50、449.3 ページ/分、$0.048 のコストは、測定されたすべてのエンジンの中で最高の数値です。docTR はベンチマークで最も高速かつ最も安価なエンジンです。
コストは、壁時計実行時間 × RunPod RTX 4090 レート($0.76/hour、価格はランマニフェストにタイムスタンプ付き)で計算され、モデル初期化を含みます。これは、GPU時間に対して実際に支払う金額です。スループットは、同じ初期化を含む壁時計ページ/分です。レイテンシ p50/p95 は、ウォームアップ後にスコアリングされた定常状態の1ページあたり推論時間(モデルロードを除く)です。EasyOCR のテールは比例して悪く、docTR の 281.4 ms に対して 960.4 ms の p95 で、3.4倍の差があります。EasyOCR は、測定された他のほとんどのエンジンよりも依然として本質的に安価です(その $0.110 は、docTR に次ぐベンチマークで2番目に低い1,000ページあたりの数値です)。つまり、高価でも遅くも中程度のコストと中程度の速度です。
出典: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/hr(モデル初期化を含む)、価格はランマニフェストにタイムスタンプ付き(2026年8月)。docTR の $0.048 は、ベンチマーク内のすべてのエンジンで最も低い1,000ページあたりのコストです。EasyOCR の $0.110 は2番目に低いです(summary_metrics.csv、cost_per_1000_pages、すべての sroie_2019 行)。
| 動作範囲(SROIE 2019、n=361) | docTR | EasyOCR | 出典 |
|---|---|---|---|
| レイテンシ p50(ms) | 108.7 | 413.6 | summary_metrics.csv · latency_p50_ms、doctr/sroie_2019 および easyocr/sroie_2019 行 |
| レイテンシ p95(ms) | 281.4 | 960.4 | summary_metrics.csv · latency_p95_ms、同じ行 |
| 1分あたりのページ数(実時間) | 449.3 | 124.5 | summary_metrics.csv · pages_per_minute、同じ行 |
| 1,000ページあたりのコスト | $0.048 | $0.110 | summary_metrics.csv · cost_per_1000_pages、同じ行 |
表: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レイテンシ、最高のpg/min、最低コストを保持しています(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は1つもフィールドを取得できませんでした(0.0000 field F1 — CSVでは文字通りゼロであり、欠損値ではありません)。なぜなら、英語形式のパターンはインドネシア語テキストの何もマッチしなかったのに対し、EasyOCRは0.0067を取得しました。docTRのコスト優位性もCORDでは縮小し、逆転します($0.094 vs EasyOCRの$0.086 / 1,000ページあたり) — しかし、実行時間スループットの優位性は500.4 vs 211.8 ページ/分(2.4倍)に拡大します。CORDは言語ロバスト性の文脈で引用されており、SROIEの数値と単一のリーダーボードに意図的に統合されることはありません。
| CORD v2、インドネシアのレシート(n=100) | docTR | EasyOCR | 出典 |
|---|---|---|---|
| 文字誤り率(CER) | 0.9101 | 0.9185 | summary_metrics.csv · cer、doctr/cord_v2およびeasyocr/cord_v2行 |
| フィールド値 F1(正規表現) | 0.0000 | 0.0067 | field_method_comparison.csv · regex_field_value_f1、同じ行 |
| フィールド値 F1(LLM) | 0.5500 | 0.3378 | field_method_comparison.csv · llm_field_value_f1、同じ行 |
| ページ/分(実行時間) | 500.4 | 211.8 | summary_metrics.csv · pages_per_minute、同じ行 |
| コスト / 1,000ページあたり | $0.094 | $0.086 | summary_metrics.csv · cost_per_1000_pages、同じ行 |
表: summary_metrics.csv および field_method_comparison.csv、cord_v2 行。CORD の数値を SROIE のランキングに統合しないでください: CORD の CER は、正解データにおける言語の不一致とアノテーション構造の膨張を組み合わせたものです。正規表現パターンは英語のフォーマット用に作成されたため、両エンジンで正規表現のフィールド値 F1 は約 0–1% にまで低下します。docTR の 0.0000 は CSV に記録された文字通りのゼロであり、欠損値ではありません。LLM のフィールド値 F1 の差 (0.5500 vs 0.3378) は、言語を超えて SROIE のパターンを拡張しています。コスト順序は逆転します (EasyOCR $0.086 vs docTR $0.094) が、スループットの差は拡大します (2.4×)。
Who Wins When: The Recap Grid
“Better” はワークロードに依存し、このヘッド・トゥ・ヘッドは軸を明確に分割します: 生テキスト精度、LLM ダウンストリーム フィールド、速度、スループット、コストはすべて docTR に有利です。固定正規表現によるフィールド抽出とデプロイの観点は EasyOCR に有利です — ただし、EasyOCR の LLM ダウンストリーム結果は、最大のリスクであり、販売ポイントではありません。
よくある質問
docTRはレシートにおいてEasyOCRよりも正確ですか?
はい、このベンチマークのすべての生テキストおよびフィールド抽出精度軸において優れています。 SROIE 2019では:CER 0.1971対0.2833(30%低く)、WER 0.3199対0.6158(48%低く)、LLM後処理フィールドF1 0.6171対0.3717(1.66倍、8中1位対8中8位)— ただし、正規表現フィールドF1ではEasyOCRが0.1477対0.0766で勝っています(summary_metrics.csvおよびfield_method_comparison.csv、sroie_2019行)。どちらのエンジンもベンチマーク全体のCERチャンピオンではなく — Surya2(0.1915)がdocTRをわずかに上回り、その称号を保持しています。
なぜ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よりどれだけ高速で安価ですか?
同じRTX 4090($0.76/hr)で、3.8倍低いp50レイテンシ(108.7 vs 413.6 ms)、3.4倍低いp95レイテンシ(281.4 vs 960.4 ms)、3.6倍高いスループット(449.3 vs 124.5 pages/min)、1,000ページあたり2.3倍低いコスト($0.048 vs $0.110)を達成しています(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はdocTRで0.9101、EasyOCRで0.9185に達しています(summary_metrics.csv、cer、cord_v2行)。両者を分かつのは、LLMによる後処理の回復力です。docTRのフィールド値F1は0.5500、EasyOCRは0.3378です。文字レベルで両方の認識器が失敗した場合でも、SROIEでのパターンは継続し、さらに広がります。
レシート処理パイプラインはEasyOCRとdocTRのどちらを選ぶべきですか?
計測可能なコストで大量の抽出フィールドを得ることを目的とするパイプラインでは、docTRがこのコーパスで優位です。より優れた生テキスト(CERが30%低い)、全エンジン中最良のLLM後処理フィールド(0.6171 vs 0.3717)、そして2.3倍のコスト優位性、3.6倍のスループット、3.8倍のレイテンシ性能を同時に達成しています(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件の英語レシート、フラットフィールド会社/日付/住所/合計)および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/hrで計算され、価格は各実行の編集済みマニフェストにタイムスタンプ付き(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後処理:API経由のdeepseek-v4-flash、決定論的出力のためにtemperature 0(field_method_comparison.csvのllm_model列)。両エンジンのすべてのLLMフィールド行に使用された単一モデルです。
- コスト基準:壁時計実行時間 × $0.76/hr、モデル初期化を含む — バッチ処理により1ページあたりのコストが下がります。
- フィールド後処理: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の場合、フィールド値は1つも抽出されなかったことを意味する。
- フィールド値 F1(LLM): LLMポストプロセッサーの出力(OCRテキスト → deepseek-v4-flash → フィールド)に対する同じ指標。列名: llm_field_value_f1。2つのパイプラインは異なり、混合されることはない。
- ドキュメントフィールド完全一致: すべての対象フィールドが完全に一致したドキュメントの割合 — フィールドごとのF1よりもはるかに厳しい基準。
- レイテンシ p50/p95 & ページ/分: 安定状態の1ページあたり推論時間(ウォームアップ後にスコアリング、モデルロードを除く)と、モデル初期化を含む実時間スループット。測定対象となるクロックが異なる。
- 1,000ページあたりコスト: 記録された$0.76/hrのレートで、モデル初期化を含む1,000ページの請求GPU時間。
出典一覧
- 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行に由来する。
- field_method_comparison.csv(GitHub raw)。16行。列名: model, dataset, llm_model(= deepseek-v4-flash)、正規表現/LLMフィールド値精度およびF1、ドキュメントフィールド完全一致、llm_median_latency_ms、トークン数。すべての正規表現/LLMフィールドF1の数値は、このファイルのeasyocrおよびdoctr行(およびパラドクステーブルのsroie_2019の8行すべて)に由来する。
- ImageToTableai/benchmark-ocr リポジトリ。結果CSV、編集済みランマニフェスト、固定されたプロトコル、および再現用のデータセットサンプルリスト(固定テスト分割)を公開しているリポジトリ。
- results/manifests/(GitHub)。公開された各ラン(16ラン)に対し、モデルバージョン、GPU/ドライバー、torch/CUDA/Pythonバージョン、価格タイムスタンプ付きコストメタデータ、アーティファクトハッシュを含む編集済みmanifest.jsonが1つずつ。
- Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019)。SROIE 2019データセットの定義、タスク構造、ライセンス(CC-BY-4.0)。
- 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ティアと単一価格: すべての数値は、$0.76/hrのRTX 4090 1台から得られたもので、価格のタイムスタンプはランマニフェストの2026年8月時点です。他の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)を最も悪くすることが文書化されています — これは、出力テキストのレイアウト規則という仮説の下で観察され、再現可能な結果であり、因果メカニズムは明示的に分離されていません。ライブラリの証明された特性としてではなく、計画に利用する測定結果として扱ってください。
- 正規表現チューニング: パターンセットはデータセットごとに1回作成されました。フォーマットごとに、高度にチューニングされたパターンライブラリは、独自のレイアウトでより高いスコアを出す可能性があります — ただし、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 レシートベンチマーク · 従来のOCR vs ドキュメントパースVLM · 正規表現 vs LLMフィールド抽出 · フィールドレベル vs 文字レベルの精度 · 1,000ページあたりのOCRコスト
関連する読み物: AI OCR vs 従来のOCRの精度 · AI画像データ抽出 vs 従来のOCR · AI文書抽出の料金(2026年)