Surya2 vs Unlimited-OCR vs PaddleOCR-VL:
レシートVLMベンチマーク(2026)
最終レビュー: 2026-08-18 · 実行階層: 公式 · 初出3社VLMベンチマーク · 3エンジン × 2レシートデータセット
本ページの対象外: レシート以外の文書タイプ — テーブル、フォーム、請求書、契約書、長文ドキュメントは対象外です。3つのエンジンが宣伝する強み(レイアウト解析、テーブル認識、数式解析、およびUnlimited-OCRの40ページ以上のドキュメントの単一パス解析)はここでは測定されていません。クラウド/API OCRサービス、基盤実行の他の5エンジン、ファインチューニングされたモデルは対象外です。完全な8エンジン総合比較は従来OCR vs 文書解析VLMに掲載されています。
本ページのすべての数値の対象範囲: レシート(SROIE 2019英語、CORD v2インドネシア語)、1つのGPU階層(RTX 4090、$0.76/hr)、2026年8月のモデルバージョン。 請求書、テーブル、複雑なレイアウトにこれらの結果を外挿しないでください — ベンチマークはレシートOCRとレシートフィールド抽出のみを測定しています。すべての数値はベンチマークのresults/summary_metrics.csvおよびresults/field_method_comparison.csvから引用されており、公開GitHubリポジトリにミラーリングされ、行単位で引用されています。
3つの文書解析VLMが同じ361枚の英語レシートを読み取り、文字誤り率(CER)が3.4倍にわたる結果に — SROIE 2019のCERは0.1915(Surya2)対0.6552(Unlimited-OCR)、PaddleOCR-VLはその中間の0.3370。この差は主に出力規則の違いであり、読取能力の違いではない:VLMは大文字小文字を統合し、ラベルと値の行を結合し、テキストを再配置するが、CERはこれらの正規化をすべて誤りとしてカウントする(ベンチマーク自体の分解によると、SROIEのCER予算の約5分の1は大文字小文字の置換に起因する)。3つのエンジンを、その出力が実際に構築された指標 — フィールド抽出 — に当てはめると、差は縮まる:箱出しの正規表現フィールドF1は3機種で0.3183〜0.3376、LLMポストプロセッサがテキストを処理すると0.5921〜0.6139に収束する。3者が本質的に異なるのは、インドネシアのレシート(PaddleOCR-VLのCORD正規表現フィールドF1は0.3412で、ベンチマーク内の全8エンジン中最高)と、運用範囲(同一ハードウェアで3.8倍のレイテンシと5.2倍のコスト差)においてである。
そのトレードオフを一対の数字で示す:PaddleOCR-VLは1枚のレシートページを694.3 ms(p50)で読み取り、1,000ページあたり$0.205;Surya2は2,668.0 ms(p50)で読み取り、1,000ページあたり$1.061 — 同じレシート、同じテスト分割、同じRTX 4090。3機種の中で最も安価で最も遅いのは同じマシンであり、レシートにおいて文字レベルの「品質」リーダーは実行コストが最も高い。3機種のいずれもすべての場面で「勝つ」ことはない;このページの目的は、ベンチマークの各軸がどのようにフィールドを分けるかを示すことである。
3つのエンジンはすべて文書解析型視覚言語モデル(VLM)です。これは、従来のOCRエンジン(Tesseract、PaddleOCR、EasyOCR、docTR――基礎となる実行の他のエンジン)が返す、大文字小文字を維持した生の文字列ではなく、文書画像全体を読み込み、理解したテキスト――大文字小文字を統合し、ラベル/値ペアを1行にまとめ、読み取り順序に従って行を再配置した――を出力するニューラルモデルです。この出力規約が、フィールド抽出の数値を最初から強くし、生の文字誤り率の数値を誤解を招きやすくしているのです。次のセクションで示します。VLMファミリー内でも、3つのモデルはサイズと学習目標が大きく異なります。Surya2は6億5000万パラメータのテキスト中心モデルで、クリーンなフルページ転写(90以上の言語)に調整されています。PaddleOCR-VLは0.9Bのコンパクトな汎用モデルで、言語、テーブル、数式の幅広い対応を目的として構築されています。Unlimited-OCRは長文書とバッチ解析に特化しており(40ページ以上の文書を1回で読み取ることが、そのマーケティング上の核です)。以下のCER数値すべてに適用される重要な注意点があります。文字誤り率(CER)は、正解文字に対して挿入、削除、置換をカウントするため、VLMが学習して行う正規化を正確に罰します。フィールドレベルのF1値の方が、VLM間の公平な比較基準であり、このページの柱です。
なぜVLMにCERを使ってはいけないか:3.4倍の差は出力規約によるもので、読解能力ではない
生のCER列だけを見ると、Unlimited-OCRは失敗したモデルのように見え(SROIEで0.6552)、Surya2は世界クラスのように見えます(0.1915。従来のdocTRの0.1971と並び、8エンジン実行での最良の生CER)。どちらの解釈も出力スタイルの産物です。CERが0.6552とスコアされた同じUnlimited-OCRのテキストは、0.4779の単語誤り率(WER)を獲得します――大文字小文字の統合が単語を壊さずに文字を置き換えるため、単語は生き残り、文字が損なって見えるのです。PaddleOCR-VLの数値はこのパターンを逆転させています。CORDでのCER 1.0805は全8エンジンで最悪ですが、CORDフィールドF1値の0.3412は全8エンジンで最良です――ベンチマーク自体のCSVがCERランキングに矛盾しています。
この仕組みには2つの層があります。層1――正規化税:文書解析型VLMは「理解した」テキストを出力します――TAN CHAY YEEはtan chay yeeになり、INVOICE NO : PEGIVはラベルと値を1行にまとめます。CERは完全一致マッチングであるため、フィールド値が正しくても、統合された大文字小文字やまとめられた行はすべて誤りとしてスコア付けされます。ベンチマークの公開されたSROIE予測に対する誤り分解分析によると、生CER予算の約5分の1が大文字小文字の置換に、約10分の1が行の統合/削除に起因しています。3つのエンジンは異なる率でこの税を支払っています――Unlimited-OCRの重い統合はCERをWER far beyondに膨らませ、PaddleOCR-VLの行/ラベル統合はWER(0.6462)を自らのCER(0.3370)以上に押し上げています。層2――CORDにおける正解構造の膨張:CORDの正解テキストはアノテーション構造(メニュー項目、座標、フィールドラベル)を埋め込んでいるため、CERは各エンジンで、真の言語不一致に加えて系統的に膨張します――全エンジンCORD CERクラスターの0.90~1.08(従来のTesseract 0.9523、docTR 0.9101、およびすべてのVLMを含む)は、この膨張がコーパス全体にわたるものであり、モデル固有のものではないことを確認しています。
| 指標(SROIE 2019、n=361) | Surya2 | Unlimited-OCR | PaddleOCR-VL | 出典 |
|---|---|---|---|---|
| 文字誤り率(CER) | 0.1915 | 0.6552 | 0.3370 | summary_metrics.csv · cer, surya2/unlimited_ocr/paddleocr_vl_vllm sroie_2019 rows |
| 単語誤り率(WER) | 0.2735 | 0.4779 | 0.6462 | summary_metrics.csv · wer, same rows |
表: summary_metrics.csv — cerおよびwer列、sroie_2019行。正確な値: Surya2 cer 0.19147 / wer 0.27352; Unlimited-OCR cer 0.65524 / wer 0.47788; PaddleOCR-VL cer 0.33696 / wer 0.64623。低いほど良い。3つの実行すべてがerror_rate 0.0で完了。VLMをCERでランク付けしないこと: Unlimited-OCRのCER/WER乖離(0.6552 vs 0.4779)やPaddleOCR-VLのCORD CER-vs-field-F1反転(後述)は、このベンチマークのプロトコルがVLM行に対して指摘する種類の出力規約アーティファクトです。
レイヤー1と2の結果として、このページの残りのすべてのセクションでは、3つのVLMをフィールド抽出F1値(構造化出力が直接供給する指標)と運用エンベロープ**(レイテンシ、スループット、コスト)で比較し、CERは注意書きとともに引用します。これは文書解析VLM行に対するベンチマークのプロトコルルールであり、正しい視点です。レシートパイプラインが消費するのはフィールド(会社名、日付、住所、合計)であり、文字列ではありません。
箱から出してすぐのフィールド抽出:構造化出力はVLMファミリーの特徴
各エンジンの生テキストを、SROIEレシートの4つのフィールド(会社名、日付、住所、合計)に対して同じ固定正規表現パターンで処理します。これは従来のOCR+ルールベースのキーワード情報抽出(KIE)アプローチです。3つのVLMは0.02ポイント以内に収まります。Unlimited-OCR 0.3376、PaddleOCR-VL 0.3368、Surya2 0.3183です。3つすべてが8エンジンのランクで上位4位に入り、2つは最高の従来型エンジン(PaddleOCRの0.3254)を上回り、残り1つは0.007ポイント差で及ばないだけです。彼らの「理解されたテキスト」は、LLMポストプロセッサがなくてもフィールドコンシューマに届きます。これは、生文字OCRエンジンにはないファミリーの特徴です。
フィールド値F1は、抽出されたフィールド値の正解に対する精度と再現率の調和平均です。1.0はすべてのレシートフィールドが完全に復元されたことを意味し、0は何も復元されなかったことを意味します。VLMファミリーの優位性の背景にあるメカニズムは、上記で説明した出力形式です。CERを膨らませる同じ大文字小文字変換、ラベル構造化テキストが、抽出パターンと一致するのです。「正規表現フィールド抽出」列は、ベンチマークのpostprocessed_sroie_receipt_regex_*メトリクスです。これらはOCRテキスト+下流のルールベース抽出を測定し、ネイティブの構造化出力ではありません。同じパターンセットがすべてのエンジンに適用されました。対照として、従来型エンジンの正規表現フィールドF1は、0.0766(docTR)、0.1477(EasyOCR)、0.2237(Docling)、0.2335(Tesseract)です。7つの非VLMエンジンのうち6つが、トリオの最低値を下回っています。
出典: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)。
| 正規表現後処理(SROIE 2019、n=361) | Surya2 | Unlimited-OCR | PaddleOCR-VL | 出典 |
|---|---|---|---|---|
| フィールド値 F1(正規表現) | 0.3183 | 0.3376 | 0.3368 | field_method_comparison.csv · regex_field_value_f1、surya2/unlimited_ocr/paddleocr_vl_vllm sroie_2019 行 |
| フィールド値精度(正規表現) | 0.2999 | 0.3089 | 0.3102 | field_method_comparison.csv · regex_field_value_accuracy、同一行 |
| ドキュメントフィールド完全一致(正規表現) | 0.0194 | 0.0028 | 0.0028 | field_method_comparison.csv · regex_document_fields_exact、同一行 |
表:field_method_comparison.csv — 正規表現列、sroie_2019 行。これらはpostprocessed_sroie_receipt_regex_*メトリクスです。各エンジンのOCRテキストに固定パターンを適用したものです(後処理であり、ネイティブ抽出ではありません)。Surya2の0.3183は3エンジン中最も低いですが、8エンジン中4位を維持し、最良の従来型エンジン(PaddleOCR 0.3254、summary_metrics.csv field_f1_regex、paddleocr/sroie_2019行)から0.007下回る水準です。
LLMの活用:3つのエンジンの収束
3つのエンジンのOCRテキストをすべて、構造化された抽出プロンプト付きのLLMポストプロセッサ(deepseek-v4-flash、temperature 0)に渡すと、開箱時のバンドはほぼ拮抗する範囲に収束します:Surya2 0.6139、Unlimited-OCR 0.6054、PaddleOCR-VL 0.5921 — 0.022ポイントの差で、正常なエンジンのベンチマーク収束バンド(0.57〜0.62)の中に完全に収まります。決定的なコンポーネントはVLMではなく、ポストプロセッサとなります。
これは、8エンジン全体の実行が示すのと同じ収束パターンです。LLMは文字形状の照合ではなくセマンティクス(数字、日付、名前)を理解するため、テキストが十分に読み取れる限り、上流テキスト品質の大部分の差異を吸収します。3つのVLMすべてが条件を満たし、バンド内に収まります。この活用にはコストが伴います:LLM呼び出しは、OCR時間に加えて、1文書あたり約1.9〜2.3秒の中央値レイテンシを追加します(PaddleOCR-VLのテキストで1,946.7 ms、Unlimited-OCRで1,982.0 ms、Surya2で2,261.7 ms — APIによるもので、種類は同一です)。これは、同期的なページごとの待ち時間よりも非同期バッチ処理を有利にします。文書レベルの完全一致率 — 4つのフィールドがすべて一致したレシートの割合 — は3つすべてで低く(0.1219〜0.1551)、フィールドごとのF1値が実上有意義な数値であることを示しています。
| LLMポストプロセッサ(SROIE 2019、n=361) | Surya2 | Unlimited-OCR | PaddleOCR-VL | 出典 |
|---|---|---|---|---|
| フィールド値F1(LLM) | 0.6139 | 0.6054 | 0.5921 | field_method_comparison.csv · llm_field_value_f1、surya2/unlimited_ocr/paddleocr_vl_vllm sroie_2019行 |
| フィールド値精度(LLM) | 0.6136 | 0.6046 | 0.5852 | field_method_comparison.csv · llm_field_value_accuracy、同じ行 |
| 文書フィールド完全一致(LLM) | 0.1551 | 0.1302 | 0.1219 | field_method_comparison.csv · llm_document_fields_exact、同じ行 |
| LLMレイテンシ中央値(ms) | 2,261.7 | 1,982.0 | 1,946.7 | field_method_comparison.csv · llm_median_latency_ms、同じ行 |
表:field_method_comparison.csv — llm_*列、sroie_2019行。LLMモデル:deepseek-v4-flash、temperature 0(llm_model列)。LLMレイテンシはAPIによるもので、エンジンレイテンシとは別です(summary_metrics.csv latency_p50_ms)。
CORD(インドネシアのレシート):汎用コンパクトモデルの勝利
CORD v2(100枚のインドネシアのレシート、ネストされたフィールド menu/sub_total/total)は、ベンチマークにおける言語横断のストレステストであり、3つのVLM(視覚言語モデル)が本質的に差をつける場所です。同じ英語形式の正規表現パターンを通じて、PaddleOCR-VLはインドネシアのレシートフィールドを0.3412のフィールドF1値で抽出します。これはベンチマーク全体で8エンジン中最高のスコアであり、Surya2は0.2458、Unlimited-OCRは0.1079にとどまります。汎用コンパクトモデルの学習の幅広さが、テキスト中心および長文書モデルが劣勢になる場所を正確に示しています。
すべてのCORDの文字誤り率(CER)値は、ベンチマーク・プロトコルにより隔離され、SROIEランキングには一切統合されません。CORDの正解データはアノテーション構造を埋め込んでいるため(言語の不一致に加え、すべてのエンジンの生CERを膨らませています。全エンジンのCORD CERクラスターは0.90〜1.08)、正規表現パターンは英語形式用に書かれたものです。以下のCORD比較は、フィールド指標のみです。LLMポストプロセッサーの下では、SROIEと同様に言語ショックは吸収されます。3モデルは0.4678〜0.5203のフィールドF1値に再収束します(Surya2 0.5203、PaddleOCR-VL 0.5198、Unlimited-OCR 0.4678)。言語横断の重労働を行うのはポストプロセッサーであり、エンジンではありません。
出典:summary_metrics.csv — field_f1_regex列、cord_v2行(0〜1の小数を%で表示)。PaddleOCR-VL 0.3412は、ファイルの全16行におけるfield_f1_regexの最大値です。CORD正規表現で次点はSurya2 0.2458です。
| CORD v2、インドネシアのレシート(n=100) | Surya2 | Unlimited-OCR | PaddleOCR-VL | 出典 |
|---|---|---|---|---|
| フィールド値F1(正規表現) | 0.2458 | 0.1079 | 0.3412 | summary_metrics.csv ・ field_f1_regex、surya2/unlimited_ocr/paddleocr_vl_vllm cord_v2行 |
| フィールド値F1(LLM) | 0.5203 | 0.4678 | 0.5198 | field_method_comparison.csv ・ llm_field_value_f1、同じ行 |
| 文字誤り率(CER)— 隔離済み | 0.8959 | 0.9224 | 1.0805 | summary_metrics.csv ・ cer、同じ行 |
テーブル: summary_metrics.csv (field_f1_regex / cer) および field_method_comparison.csv (llm_field_value_f1)、cord_v2 行。CORD の数値を SROIE のランキングに混ぜてはいけません: CORD の CER は、正解データにおける言語の不一致とアノテーション構造による膨張を組み合わせたものです(全エンジンが 0.90–1.08 に集束 — 従来の Tesseract 0.9523、docTR 0.9101 を含む)。PaddleOCR-VL の CER が 8 つのエンジンの中で最も高い 1.0805 なのは、そのクリアで正規化された出力が、構造を多く含む CORD の正解データから最も遠いためです — 一方で、その regex フィールド F1 はベンチマーク全体で最高です。
運用エンベロープ: 3.8倍のレイテンシ、5.2倍のコスト
フィールド精度は収束するが、運用コストは収束しない。同じ RTX 4090 で同じ $0.76/hr のレートで、PaddleOCR-VL は 68.2 ページ/分、694.3 ms p50(1ページあたり)、1,000ページあたり $0.205 を維持する。Unlimited-OCR はエンベロープの中央に位置し、34.4 ページ/分、1,600.7 ms p50、1,000ページあたり $0.388。Surya2 は価格とレイテンシの外れ値で、12.1 ページ/分、2,668.0 ms p50、1,000ページあたり $1.061。最も高速な VLM は、同一ハードウェア上で最も低速なものより 3.8倍 高速で 5.2倍 安い。
コストは、壁時計実行時間 × RunPod RTX 4090 レート($0.76/hour、ランマニフェストにタイムスタンプ付き)で計算され、モデル初期化を含む — つまり、GPU時間に対して実際に支払う金額。スループットは、同じ初期化を含む壁時計ページ/分。レイテンシ p50/p95 は、ウォーム後にスコアリングされた定常状態の1ページあたり推論時間(モデルロードを除く)。Surya2 のテールは比例的に悪く — PaddleOCR-VL の 1,154.3 ms に対して 5,872.2 ms p95 — なぜなら、最初のページでは VLM のプリフィル/デコードスパイクがテールを支配するから。2つの数値は互いに比較するのではなく、一緒に読むべきもの:PaddleOCR-VL は最低の p50 を持つが、CORD 上では壁時計スループットで Unlimited-OCR に負ける(73.99 vs 67.13 ページ/分) — 壁時計数値はモデル初期化を含み、Unlimited-OCR の vLLM バッチ処理が十分に効率的であるため、ここで順序が逆転する。
出典: summary_metrics.csv — latency_p50_ms 列、sroie_2019 行。Surya2 2667.9800、Unlimited-OCR 1600.7459、PaddleOCR-VL 694.2519。定常状態レイテンシ(ウォーム後にスコアリングする測定モード)。
出典: summary_metrics.csv — cost_per_1000_pages カラム、sroie_2019 行。Surya2 1.0609、Unlimited-OCR 0.3879、PaddleOCR-VL 0.2048。コスト = 実行時間 × $0.76/hr(モデル初期化を含む)、価格はランマニフェストに記録(2026年8月)。
| 動作範囲(SROIE 2019、n=361) | Surya2 | Unlimited-OCR | PaddleOCR-VL | 出典 |
|---|---|---|---|---|
| レイテンシ p50(ms) | 2,668.0 | 1,600.7 | 694.3 | summary_metrics.csv · latency_p50_ms、surya2/unlimited_ocr/paddleocr_vl_vllm sroie_2019 行 |
| レイテンシ p95(ms) | 5,872.2 | 2,521.9 | 1,154.3 | summary_metrics.csv · latency_p95_ms、同じ行 |
| 1分あたりのページ数 | 12.1 | 34.4 | 68.2 | summary_metrics.csv · pages_per_minute、同じ行 |
| 1,000ページあたりのコスト | $1.061 | $0.388 | $0.205 | 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 行。3エンジンすべてGPU(RTX 4090、$0.76/hr、価格はマニフェストに記録);コストにはモデル初期化を含み、純粋な定常スループットではない。正確な値: Surya2 p50 2668.0 / p95 5872.2 / 12.1 pg/min / $1.0609;Unlimited-OCR p50 1600.7 / p95 2521.9 / 34.4 pg/min / $0.3879;PaddleOCR-VL p50 694.3 / p95 1154.3 / 68.2 pg/min / $0.2048。
最適な選択は?:比較グリッド
「より優れている」は作業量に依存し、これら3つのVLMの間では軸が明確に分かれています。フィールド精度は収束し(正規表現とLLM)、生の文字テキストはSurya2が有利、多言語フィールドはPaddleOCR-VLが有利、コスト・レイテンシ・スループットのすべての軸ではPaddleOCR-VLが有利で、Unlimited-OCRがその中間に位置します。正直な結論は、レシートにおいて、パイプラインに何らかの後処理器がある場合、VLMの選択はほとんど重要ではないということです。そして、後処理器がない場合、通常重要となる軸では、安価な汎用コンパクトモデルが高価な専門モデルを上回ります。
よくある質問
レシートの文書解析VLMで最も精度が高いのはどれですか?
フィールド抽出において、英語レシートでは3社がほぼ互角です:Surya2、Unlimited-OCR、PaddleOCR-VLの3者で、SROIE正規表現フィールドF1は0.3183〜0.3376、LLMフィールドF1は0.5921〜0.6139です(field_method_comparison.csv、sroie_2019行)。インドネシア語レシートでは答えが変わります:PaddleOCR-VLのCORD正規表現フィールドF1は0.3412で、ベンチマーク内の全8エンジン中最も優れています(summary_metrics.csv、field_f1_regex、cord_v2行)。生のCER(文字誤り率)でVLMをランク付けすべきではありません。大文字小文字の統合や行の結合など、出力規約の違いを誤りとしてカウントしてしまうためです(上記「なぜCERを使わないのか」のセクションを参照)。
なぜUnlimited-OCRはCERが最悪なのに、SROIEの正規表現フィールドF1が最良なのですか?
2つの指標が異なる出力を評価しているためです。Unlimited-OCRの強い大文字小文字統合は、文字レベルの誤りを膨らませます。CERが0.6552であるのに対しWERが0.4779であることがその証拠です。一方で、同じ正規化されたテキストが、他のどのエンジンよりも固定抽出パターンにうまくマッチしています。SROIE正規表現フィールドF1は0.3376で、8エンジンの実行結果の中でトップです(summary_metrics.csv cer / wer、field_method_comparison.csv regex_field_value_f1、sroie_2019行)。
なぜPaddleOCR-VLのCORD CERはベンチマーク内で最悪なのに、CORDフィールドF1は最良なのですか?
CORDの正解データがアノテーション構造を埋め込んでいるのに対し、PaddleOCR-VLの出力が最もクリーンで正規化されているためです。構造を含むテキストから最も遠いため、編集距離が最大(CER 1.0805)になります。同じ出力スタイルが抽出パターンにうまくフィットします。CORD正規表現フィールドF1は0.3412で、全8エンジン中最も優れています(summary_metrics.csv、cer / field_f1_regex、cord_v2行)。この逆転現象は、CORD CERがモデルごとの品質指標ではないことをベンチマーク自体が示しています。
PaddleOCR-VLはSurya2よりどれだけ高速で安価ですか?
同じRTX 4090($0.76/hr)で、3.8倍低いp50レイテンシ(694.3 ms vs 2,668.0 ms)、5.6倍高いスループット(68.2 vs 12.1 pages/min)、1,000ページあたり5.2倍低いコスト($0.205 vs $1.061)を実現しています(summary_metrics.csv、latency_p50_ms / pages_per_minute / cost_per_1000_pages、sroie_2019行)。
LLMポストプロセッサを追加すると、3つのVLMは同等になりますか?
ほぼ同等です — SROIEでのLLMフィールドF1値が0.5921から0.6139に、ベンチマークの0.57〜0.62の収束帯内で0.022ポイントの差に収まります(field_method_comparison.csv、llm_field_value_f1、sroie_2019行)。この収束のコストは、文書あたり約1.9〜2.3秒の追加中央LLMレイテンシです(llm_median_latency_ms、同じ行)。これは非同期バッチ処理に有利です。
レシートパイプラインは3つのVLMのうちどれを選ぶべきですか?
パイプラインが重視する軸によります。ポストプロセッサなしのネイティブ多言語フィールドでは、PaddleOCR-VLのCORD正規表現F1値(0.3412)が測定された唯一の有用なレベルです。最も安価で高速なVLMサービングでは、再びPaddleOCR-VL(694.3 ms、$0.205/1Kページ)です。コストとレイテンシが制約とならないクリーンな生の英語テキストでは、Surya2のCER(0.1915)が最も優れています。中程度のボリュームでのバランスの取れたポイントでは、Unlimited-OCR(1,600.7 ms、$0.388/1Kページ、最高の出荷時SROIEフィールドF1値)です。パイプラインにLLMポストプロセッサがある場合、レシートでは選択はあまり重要ではありません — 3つすべてが収束帯に収まります。これらの結果は、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論文から来ています。
方法論と出典
プロトコル
このページは、独立した再現可能なベンチマーク実行(公式ティア)の3方向スライスを報告しています — 第三者の主張の調査でも、ベンダー比較ページでもありません。固定テスト分割のみを使用:SROIE 2019テスト(361件の英語レシート、フラットフィールド:会社名/日付/住所/合計)およびCORD v2テスト(100件のインドネシア語レシート、ネストされたフィールド:メニュー/小計/合計)。訓練分割は評価されていません。3つのすべてのエンジンは、同じ画像、同じ正解データ、同じ測定プロトコル(warm_then_scored:スコアリングパスの前に固定ウォームアップパスがあり、レイテンシ数値は定常状態)を使用しました。3つのすべての実行は、error_rate 0.0(summary_metrics.csvのerror_rate列)で完了しました。基礎となる実行には合計8つのエンジンが含まれていますが、このページでは名前付きの3つのVLMのみを比較し、完全な8エンジンの結果はTraditional OCR vs Document Parsing VLMsで別途公開されています。
ランタイム環境
- ハードウェア:3つのすべてのエンジンは、同じNVIDIA RTX 4090(24 GB)で実行されました。GPUコストは、RunPodのオンデマンドレートである$0.76/hrで計算され、価格は各実行の編集済みマニフェストにタイムスタンプ付き(2026年8月)。
- エンジン:出荷時設定、ファインチューニングなし。バージョン固定:Surya2(surya-ocr 0.22.1)およびPaddleOCR-VL 1.6、両方vLLMで提供。Unlimited-OCRはvLLMで提供されるが、公開固定バージョンなし(制限事項を参照)—公開リポジトリのモデルテーブル(README.md)および実行マニフェストに基づく。
- LLM後処理:deepseek-v4-flashをAPI経由でtemperature 0で使用し、決定論的な出力を実現(field_method_comparison.csvのllm_model列)。3つのすべてのエンジンのすべてのLLMフィールド行に使用された単一モデル。
- コスト基準:壁時計実行時間 × $0.76/hr、モデル初期化を含む — バッチ処理により1ページあたりのコストが低下。
- フィールド後処理:SROIE正規表現フィールドメトリクスは
postprocessed_sroie_receipt_regex_*(field_method_comparison.csvのregex_*列)— 固定パターンセットによってOCRテキストから抽出されたフィールド。これらはOCR + 下流抽出を測定し、任意のモデルによるネイティブ構造化出力を測定するものではありません。LLM_*列はOCRテキスト + LLM抽出を測定します。2つのパイプラインが混ざることはありません。
指標の定義
- CER(文字誤り率): OCRテキストと正解データ間の編集距離(挿入+削除+置換)を正解文字数で割ったもの。低いほど良い。ドキュメント解析VLMには不利: フィールド値が正しくても、大文字小文字の統合、ラベル/値の結合、行の並べ替えを誤りとして評価する。このページでは注意点とともに掲載。
- WER(単語誤り率): 単語粒度での同じ編集距離計算。CERとWERが大きく乖離する場合(Unlimited-OCR: 0.6552 vs 0.4779)、その差は誤読ではなく出力正規化による影響を示す。
- フィールド値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、レイテンシ、コスト、スループットの数値は、このファイルのsurya2、unlimited_ocr、paddleocr_vl_vllm行に由来します。
- 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 フィールドF1値は、このファイルの3つのエンジン名の行に由来します。
- 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)。
制限事項
- CERがVLMに対して不公平なのは、このページがフィールド指標に基づいている理由です: ドキュメント解析VLMは大文字小文字を統合し、ラベル/値の行を結合し、テキストを再配置するため、生のCERスコアは出力規約を誤りとしてカウントします。Unlimited-OCRのCER(0.6552)とWER(0.4779)の乖離や、PaddleOCR-VLのCORD反転(最悪CER 1.0805、最高フィールドF1 0.3412)は、いずれもその代償によるものです。CERに基づいてVLMをランク付けする比較(このページを含む)は、読解能力ではなく出力スタイルの指標として扱うべきです。
- ドキュメント範囲 — レシートのみ: SROIE + CORD。ここでは、ドキュメント解析VLMが最大の利点を主張するレイアウト/テーブル/数式/長文ドキュメントの処理能力は測定されていません。3つのエンジンすべてのマーケティング上の強み(Unlimited-OCRの40ページ超シングルパス解析を含む)は未測定です。このページから「VLM Xがすべてで勝利する」と結論付けないでください。
- サンプルサイズ: 英語361件 + インドネシア語100件のレシート。フィールドF1とCERはコーパスに依存します。数百分の一の単桁差(0.022ポイントのLLM-F1差を含む)はノイズとして扱い、エンジニアリング上の真実と見なすべきではありません。
- 単一GPUティアと単一価格: すべての数値は、$0.76/hrのRTX 4090 1台から得られたもので、価格のタイムスタンプはラン�マニフェストによると2026年8月です。他のGPU、マルチGPUサービス、バッチスケジューリング、または価格変動は、レイテンシ、スループット、コストを変動させます。予算策定前に、現在のレートでコストを再算出してください。
- 単一LLMポストプロセッサー: すべてのLLM行は、temperature 0のdeepseek-v4-flashを使用しています。異なるLLMは絶対的なフィールドF1を変化させ、収束順序は余剰部分で移動する可能性があります。LLMレイテンシ(中央値約1.9〜2.3秒、field_method_comparison.csv llm_median_latency_ms)はAPIによるもので、エンジン自体のレイテンシには含まれません。
- CORD隔離: CORDの正解データはアノテーション構造を埋め込み、正規表現パターンは英語形式用に作成されています。CORD CER(すべてのエンジンで0.90〜1.08)は、言語不一致と正解データの膨張を反映しており、モデルごとの品質を反映していません。CORD行は文脈付きで引用され、SROIEランキングには一切統合されません(プロトコルルール)。
- バージョン固定: 結果はSurya2 0.22.1、PaddleOCR-VL 1.6、Unlimited-OCR vLLMサービス版(2026年8月)に有効です。Unlimited-OCRはベンチマーク公開モデル表に公開的に固定されたバージョン番号がないため、行を正確なリリースに追跡できません。いずれかのエンジンの新しいリリースは、このページのすべての数値を変動させる可能性があります。
- 正規表現チューニング: パターンセットはデータセットごとに1回作成されました。フォーマットごとに高度にチューニングされたパターンライブラリは、独自のレイアウトでより高いスコアを出す可能性がありますが、LLMが排除するメンテナンスコストが発生します。
関連リファレンス: docTR vs Surya2 レシートベンチマーク · 従来のOCR vs ドキュメント解析VLM · 正規表現 vs LLMフィールド抽出 · フィールドレベル vs 文字レベルの精度 · レシートOCR精度
関連記事: AI OCR vs 従来のOCRの精度 · AI画像データ抽出 vs 従来のOCR · AI文書抽出の料金(2026年)