PaddleOCR vs EasyOCR レシート比較
精度 vs コスト ベンチマーク (2026)

2つのエンジンは、2世代の深層学習OCRを代表しています。PaddleOCR（PaddlePaddleベース、PP-OCRアーキテクチャ、v3.7.0）は、現代的な2段階パイプラインです。検出段階でテキスト領域を特定し、認識段階で文字起こしを行います。大規模な印刷テキストの高精度処理を目的として設計されています。EasyOCR（PyTorchベース、1.7.2）は、クラシックな単一パスCNN + RNN + CTC認識器です。ResNet特徴抽出器がシーケンスモデルに入力され、Connectionist Temporal Classificationでデコードされます。非常に広範な言語と文字カバレッジ（標準で80以上の言語）と、非常にシンプルなインストールで知られています。文字誤り率（CER）は、挿入、削除、置換を正解文字数で割ったものです。CERが0.204ということは、100文字あたり約20.4文字の誤読を意味します。単語誤り率（WER）は、同じ編集距離のロジックを単語単位で適用したものです。どちらも低いほど良いです。

SROIE（英語レシート）におけるテキスト精度：PaddleOCRの明確な優位性

SROIE 2019テスト分割の361枚の英語レシートにおいて、現代のアーキテクチャが両方のテキスト指標で勝利しています。CERは0.2045対0.2833（相対改善率27.8%）、WERは0.3256対0.6158です。EasyOCRのWERはほぼ2倍です。WERの差はCERの差よりも大きく、EasyOCRがこのコーパスにおいて文字レベルの誤りを単語全体の誤りに増幅させていることを示しています。両エンジンとも、エラーなしで実行されています（CSVのすべてのSROIEおよびCORD行でerror_rate 0.0）。

出典：summary_metrics.csv — cerおよびwer列、sroie_2019行。PaddleOCR cer 0.20449 / wer 0.32563；EasyOCR cer 0.28327 / wer 0.61578。低いほど良い。各エンジン361サンプル；両方error_rate 0.0。

テーブル: summary_metrics.csv — cer / wer / error_rate 列、sroie_2019 行。正確な値: PaddleOCR cer 0.20449 / wer 0.32563; EasyOCR cer 0.28327 / wer 0.61578。CER/WER は低いほど良い。いずれのエンジンもベンチマークの総合精度チャンピオンではなく、その称号は同じ8エンジンの実行（summary_metrics.csv、surya2 および doctr sroie_2019 行）における Surya2（CER 0.1915）と docTR（CER 0.1971）に帰属します。

フィールド抽出: 正規表現によるKIEとLLMによるKIE

テキスト精度はエンジンをランク付けしますが、フィールド抽出はダウンストリームシステムが実際に消費するものです。ベンチマークのSROIEフィールド指標は、各エンジンのOCRテキストに対して2つの後処理を使用して、4つのフラットなレシートフィールド（会社、日付、住所、合計）を対象とします: 固定正規表現パターン（従来のOCR + ルールベースの重要情報抽出アプローチ）と、構造化プロンプトを使用したLLM後処理（temperature 0のdeepseek-v4-flash）です。正規表現では、PaddleOCRは0.3254 フィールドF1でフィールドを抽出し、EasyOCRは0.1477です — 2.2倍の優位性。LLMでは、この差は0.5810対0.3717（1.56倍）で維持されます。

フィールド値F1は、抽出されたフィールド値と正解データの精度と再現率の調和平均です — 1.0はすべてのレシートフィールドが完全に復元されたことを意味し、0は何も復元されなかったことを意味します。SROIE正規表現フィールド列は、ベンチマークのpostprocessed_sroie_receipt_regex_*指標です: 各エンジンのOCRテキストに適用された固定パターン（後処理済み、ネイティブの構造化出力ではありません）。ランク付けの文脈に注意してください: PaddleOCRの0.3254は、8エンジンベンチマークにおける3番目に優れた正規表現フィールド結果（Unlimited-OCR 0.3376およびPaddleOCR-VL 0.3368に次ぐ）であり、4つの純粋に従来のエンジン中最良です。EasyOCRの0.1477は8つ中7位です（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）。「全フィールドが完全一致するドキュメント」は、すべての対象フィールドが完全に一致したドキュメントの割合です。これはフィールドごとの F1 よりもはるかに厳しい基準です。EasyOCR は領収書の 0.28% で4つのフィールドすべてを完全に正しく抽出しています。

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

これはページの最も特徴的なデータポイントであり、本当に直感に反するものです：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にはすでにその修正された値が含まれています）が、因果関係の主張は行われていません。実用的な含意はマーケティングの外見とは正反対です：このコーパスでは、「十分な」テキストのためにEasyOCRを選択することは、テストされたすべてのエンジンの中で最悪のLLMダウンストリームフィールド回復を予算に計上することを意味します。

出典：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行より。

表：field_method_comparison.csv — llm_field_value_f1、全sroie_2019行；CER列はsummary_metrics.csvのcer、sroie_2019行より。EasyOCRのCER（0.2833）は8エンジン中4位 — 中程度のテキスト精度ですが、LLMによるフィールド復元は最悪（0.3717、Tesseractの0.4389を下回る）。このパラドックスは観察可能で再現可能であることが文書化されていますが、そのメカニズムはこのベンチマークでは特定されていません。

動作エンベロープ：EasyOCR が本物の競争力を持つ領域

精度は唯一の軸ではなく、運用軸において EasyOCR には実測された明確な優位性があります。同じ RTX 4090 で同じ $0.76/hr の条件下で、EasyOCR は SROIE を $0.110 per 1,000 pages で処理するのに対し、PaddleOCR は $0.221（2.0倍の差）です。処理速度は 124.5 pages/min 対 79.7（1.56倍）で、最悪ケースの遅延もタイトに保たれています。p95 は 960.4 ms で、PaddleOCR の初回ページスパイクである 3,331.4 ms と比べ、3.5倍タイトな遅延分布を示します。デプロイもよりシンプルで、広範な言語カバレッジを持つ単一の PyTorch ランタイムで済みます。一方、PaddlePaddle はより重いフレームワークスタックを必要とします。

一見の矛盾に率直な説明が必要です。PaddleOCR は1ページあたりの中央値レイテンシがより低く（p50 297.0 ms 対 EasyOCR の 413.6 ms）、1分あたりのページ数もより低く（79.7 対 124.5）なっています。この2つの数値は異なるクロックを測定しています。レイテンシ p50 は、ウォーム状態（モデルが既にロード済み）での定常状態の1ページあたり推論時間です。一方、1分あたりページ数は、モデルの初期化やバッチ効果を含む実行全体の壁時計スループットです。EasyOCR のより小さく、高速にロードされるランタイムが壁時計の総量レースに勝ち、PaddleOCR の1ページあたり推論はウォーム状態になれば個別にはより高速です。両方の数値は事実であり、異なるものを記述しています。モデルロードのオーバーヘッドが支配的なワークロード（多数の小さなバッチ、頻繁なコールドスタート）では EasyOCR の壁時計上の優位性が現れ、ウォーム状態の長時間実行パイプラインでは PaddleOCR の1ページあたりの優位性が現れます。

コストは壁時計の実行時間 × RunPod RTX 4090 レート（$0.76/hour、価格は実行マニフェストに記録）で計算され、モデルの初期化を含みます。これは実際にGPU時間に支払う金額です。スループットは同じ初期化を含む壁時計の1分あたりページ数です。レイテンシ p50/p95 は、ウォーム状態にしてからスコアリングされた定常状態の1ページあたり推論時間（モデルのロードを除く）です。PaddleOCR の p95 である 3,331 ms は初回ページ/プリフィルのスパイクであり、定常状態の動作ではありません。

出典：summary_metrics.csv — latency_p50_ms / latency_p95_ms カラム、sroie_2019 行。PaddleOCR p50 296.99 / p95 3331.35；EasyOCR p50 413.64 / p95 960.37。定常状態レイテンシ（warm_then_scored 測定モード、モデルのロードを除く）。

出典：summary_metrics.csv — cost_per_1000_pages カラム、sroie_2019 行。PaddleOCR 0.2214、EasyOCR 0.1098。コスト = 壁時計の実行時間 × $0.76/hr（モデル初期化を含む）、価格は実行マニフェストに記録（2026年8月）。いずれのエンジンもベンチマークで最も安いわけではありません — docTR が $0.048 per 1,000 pages（summary_metrics.csv、doctr/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 価格はマニフェストに記録）；コストにはモデル初期化が含まれます。正確な値：PaddleOCR p50 296.99 / p95 3331.35 / 79.71 pg/min / $0.2214；EasyOCR p50 413.64 / p95 960.37 / 124.53 pg/min / $0.1098。p50とpages/minの逆転については、上記の文章で説明しています：定常状態のページあたり推論（PaddleOCRが優位）と、初期化やバッチ効果を含む実時間スループット（EasyOCRが優位）の違いです。

CORD（インドネシアのレシート）：両エンジンとも崩壊するが、PaddleOCRのLLMフィールド回復は生き残る

どちらのエンジンもインドネシアのレシートを主に学習していなかったため、CORD v2（100サンプル、ネストされたフィールド menu/sub_total/total）は言語横断ストレステストとして機能し、生のCER（文字誤り率）では両エンジンとも崩壊する：0.9083（PaddleOCR）と0.9185（EasyOCR）。これは言語不一致による同水準の結果であり、両エンジンとも実質的にテキストを読むことができない。ベンチマークプロトコルに従い、CORDの数値はSROIEとの比較から隔離され、ランキングには統合されない。CORDの正解テキストにはアノテーション構造が埋め込まれており、言語不一致に加えて全エンジンの生のCERを膨らませるためだ。

フィールド指標は、ほぼ同一のCERとは異なる物語を語る。LLMポストプロセッサーを通じて、PaddleOCRのフィールドF1はCORDで0.5527を維持し、EasyOCRの0.3378を上回る。これはSROIEのパターンの延長であり、文字認識レベルで両エンジンが失敗しても、PaddleOCRのLLM下流回復は言語ショックに耐え、EasyOCRのそれは耐えない。EasyOCRのCORD LLMフィールドF1は8エンジン中2番目に低く（Tesseractの0.1627のみ上回る。summary_metrics.csv/field_method_comparison.csv cord_v2行）、再びCERが悪いエンジンに遅れを取るという逆説が両データセットで継続する。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 は、正解データにおける言語の不一致とアノテーション構造の膨張を組み合わせたものです。正規表現パターンは英語のフォーマット用に作成されたため、両エンジンで正規表現の field F1 は約 0–2% にまで低下します。PaddleOCR の CORD における LLM field F1 は 0.5527 で、SROIE での優位性 (0.5810 vs 0.3717) を繰り返しています — その LLM ダウンストリームの回復力は、EasyOCR が耐えられない言語ショックにも耐えています。

Who Wins When: The Recap Grid

“Better” はワークロードに依存し、このヘッド・トゥ・ヘッド比較は軸を明確に分割しています: 英語のレシートにおけるすべての精度軸は PaddleOCR を支持し、コスト、壁時計スループット、テールレイテンシ、およびデプロイの容易さは EasyOCR を支持し、生のテキスト精度のチャンピオンはどちらでもありません (Surya2/docTR) — EasyOCR の LLM ダウンストリームの結果は、その最大の注意点であり、販売ポイントではありません。

よくある質問

レシートの精度はPaddleOCRの方がEasyOCRより高いですか？

はい、このベンチマークで測定されたすべての精度軸で優れています。 SROIE 2019では：CER 0.2045 対 0.2833（27.8%の相対的改善）、WER 0.3256 対 0.6158、正規表現フィールドF1 0.3254 対 0.1477（2.2倍）、LLM後処理フィールドF1 0.5810 対 0.3717（summary_metrics.csvおよびfield_method_comparison.csvのsroie_2019行）。どちらのエンジンもベンチマーク全体のテキスト精度王者ではありません。Surya2（CER 0.1915）とdocTR（0.1971）がその座にあります。

EasyOCRの方がPaddleOCRより安価ですか？

はい、英語レシートでは1,000ページあたり約2倍安価です：SROIE 2019では$0.110対$0.221、CORDでは$0.086対$0.342と差が広がります。これは同じRTX 4090（$0.76/hr）で、コストにモデル初期化を含めた場合です（summary_metrics.csvのcost_per_1000_pages、sroie_2019およびcord_v2行）。ベンチマーク全体で最も安価なエンジンは、1,000ページあたり$0.048のdocTRです。

どちらが高速ですか：PaddleOCRかEasyOCRか？

どちらのクロックを指すかによります。PaddleOCRは定常状態の中央値レイテンシが低い（297.0対413.6 ms p50）ですが、EasyOCRは壁時計スループットが高い（124.5対79.7ページ/分）です。これは、壁時計ページ/分にモデル初期化とバッチ効果が含まれ、EasyOCRの軽量ランタイムがより速く起動するためです（summary_metrics.csvのlatency_p50_ms / pages_per_minute、sroie_2019行）。長時間稼働するウォームパイプラインでは、PaddleOCRがページあたり高速です。多数の小さな、または頻繁なコールドバッチでは、EasyOCRが壁時計レースに勝ちます。

なぜ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行）。

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

SROIEランキングからプロトコルが分離している2つの複合的な原因があります：言語の不一致（インドネシアのレシートが両エンジンの学習対象外であること）と、CORDの正解テキストにおけるアノテーション構造の膨張です。CERはPaddleOCRで0.9083、EasyOCRで0.9185となります（summary_metrics.csv, cer, cord_v2行）。両者の違いを決定づけているのは、LLMによる後処理の回復力です。PaddleOCRは0.5527、EasyOCRは0.3378のフィールドF1スコアを示し、文字レベルで両方の認識器が失敗した場合でも、SROIEのパターンが維持されます。

レシート処理パイプラインにはPaddleOCRとEasyOCR、どちらのエンジンを選ぶべきですか？

パイプラインが会社名、日付、合計などのフィールド（抽出された値）を扱う場合、レシートではPaddleOCRが明確なデフォルトです：正規表現でフィールドF1が2.2倍、LLMで1.56倍高く、CORDの言語ショックに耐えるLLM後処理の回復力を備えています（field_method_comparison.csv）。安価な大量処理、厳格なワーストケース性能、軽量なスタック、または導入時の広範な言語カバレッジが必要な場合は、EasyOCRが運用面で本物の競争力を持っています（コスト2倍安、実行時間スループット1.56倍、p95が3.5倍厳格、80以上の言語）— ただし、採用前にその弱いLLM後処理を考慮に入れてください。これらの結果は、2026年8月に1つのGPUティアで英語およびインドネシア語のレシートに対して得られたものです。本番環境での判断の前に、対象コーパスで再実行してください（制約事項を参照）。

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

すべての数値は、自社ベンチマークの公開CSVの1行です — 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：スコアリングパスの前に固定ウォームアップパスを行い、レイテンシ数値を定常状態にします）で実行されました。両方の実行で、両データセットのエラー率は0.0でした（summary_metrics.csvのerror_rateカラム）。 underlying runには合計8つのエンジンが含まれていますが、このページでは2つのエンジンのみを比較し、他のエンジンはランキングの文脈として引用されています。8エンジンの完全な結果は、Traditional OCR vs Document Parsing VLMsで別途公開されています。

実行環境

• ハードウェア：両エンジンは同じNVIDIA RTX 4090（24 GB）で実行。GPUコストはRunPodのオンデマンドレート$0.76/hrで計算。価格は各実行のマニフェスト（2026年8月）に記録。
• エンジン：出荷時設定のまま、ファインチューニングなし。バージョン固定：PaddleOCR 3.7.0（最新の2段階深層学習OCR — PP-OCR検出+認識、GPU）とEasyOCR 1.7.2（クラシックなResNet+CRNN with CTCデコーディング、GPU）— 公開リポジトリのモデル表（README.md）および実行マニフェストに基づく。EasyOCRのSROIE行は、2026-08-17のtorch 2.8での再実行で再検証済み（繰り返し実行r1/r2/r3はバイト同一）；公開CSVにはその修正済み値が含まれています。
• LLM後処理：API経由のdeepseek-v4-flash（温度0で決定論的出力のため）。field_method_comparison.csvのllm_modelカラムに記録。両エンジンのすべてのLLMフィールド行に使用された単一モデル。
• コスト基準：壁時計実行時間 × $0.76/hr（モデル初期化を含む）— バッチ処理により1ページあたりのコストが低減。
• フィールド後処理：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時間。

出典一覧

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、レイテンシ、コスト、スループットの数値は、このファイルのpaddleocrおよびeasyocrの行に遡及する。
2. field_method_comparison.csv（GitHub raw）。16行。列名: model, dataset, llm_model（= deepseek-v4-flash）、正規表現/LLMフィールド値の精度およびF1、ドキュメントフィールド完全一致、llm_median_latency_ms、トークン数。すべての正規表現/LLMフィールドF1の数値は、このファイルのpaddleocrおよびeasyocrの行（およびパラドクステーブルのsroie_2019の8行すべて）に遡及する。
3. ImageToTableai/benchmark-ocr リポジトリ。結果CSV、編集済みランマニフェスト、固定プロトコル、データセットサンプルリスト（固定テスト分割）を公開しているパブリックリポジトリ。
4. results/manifests/（GitHub）。公開された各ラン（16ラン）に対応する編集済み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。ここではPaddleOCRのPP-Structureによるレイアウト/テーブル/ドキュメント機能、EasyOCRの80以上の言語によるレシート以外のテキスト対応、または他のドキュメントタイプの性能は測定していません。このページからいずれかのエンジンが「すべてにおいて優れている」と結論づけないでください。
• サンプルサイズ： 英語361件 + インドネシア語100件のレシート。フィールドF1とCERはコーパスに依存します。数百分の一の単桁の差はノイズとして扱うべきであり、エンジニアリング上の真実とは見なすべきではありません（ただし、ここで記録された差（CER 27.8%、正規表現F1 2.2倍）はその範囲を遥かに超えています）。
• 単一GPUティアと単一価格： すべての数値は、$0.76/hrのRTX 4090 1台から得られたもので、価格のタイムスタンプはラン�マニフェストによると2026年8月です。他のGPU、マルチGPUサービス、バッチスケジューリング、または価格変動は、レイテンシ、スループット、コストに影響を与えます。予算策定前に、現在のレートでコストを再算出してください。
• 単一LLMポストプロセッサー： すべてのLLM行は、temperature 0のdeepseek-v4-flashを使用しています。異なるLLMは絶対的なフィールドF1を変える可能性があります。EasyOCRパラドックスの大きさはLLMによって変動する可能性がありますが、観察されたパターンはこの単一のポストプロセッサーにおいて両データセットで維持されました。LLMレイテンシ（SROIEで中央値約1,817～2,005 ms、field_method_comparison.csv llm_median_latency_ms）はAPIによるもので、いずれかのエンジン自体のレイテンシの一部ではありません。
• EasyOCRパラドックスのメカニズムは未検証： ベンチマークでは、EasyOCRの中程度のCERテキストが最悪のLLMダウンストリームフィールド回復率（SROIE 0.3717 / CORD 0.3378）を生むことが文書化されています。これは、出力テキストレイアウト規則の仮説の下で観察され、再現可能な結果であり、因果メカニズムは明確に分離されていません。ライブラリの証明された特性としてではなく、計画に利用する測定結果として扱ってください。
• 正規表現チューニング： パターンセットはデータセットごとに1回作成されました。フォーマットごとに、高度にチューニングされたパターンライブラリは、独自のレイアウトでより高いスコアを出す可能性があります。それは、LLMが排除するメンテナンスコストを伴います。
• CORD CERはモデルごとの品質指標ではありません： CORDのグランドトゥルースはアノテーション構造を埋め込んでおり、いずれのエンジンもインドネシア語を主に学習していません。CORD CER（約0.91）は、言語の不一致とグランドトゥルースの膨張を反映しています。CORDの行は文脈付きで引用され、SROIEのランキングには一切統合されません（プロトコルルール）。
• バージョン固定： 結果はPaddleOCR 3.7.0およびEasyOCR 1.7.2（2026年8月）に有効です。いずれかのエンジンの新しいリリースは、このページのすべての数値を変える可能性があります。

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

関連読書： AI OCR vs 従来のOCR精度 · AI画像データ抽出 vs 従来のOCR · AIドキュメント抽出の価格（2026年）