docTR vs Surya2: レシートOCR
ヘッド・トゥ・ヘッド・ベンチマーク (2026)
最終レビュー: 2026-08-18 · ランナー階層: 公式 · 初のヘッド・トゥ・ヘッド・ベンチマーク · 2エンジン × 2レシートデータセット
本ページの対象外: レシート以外のあらゆるドキュメントタイプ(テーブル、フォーム、請求書、契約書、長文ドキュメント)。Surya2が宣伝されている強み(レイアウト解析、テーブル認識、長文ドキュメント、任意の言語)はここでは測定しません。クラウド/API OCRサービス、他のオープンソースエンジン(比較対象はこの2つのみ)、ファインチューニング済みモデル、CER/WER以外の全文指標は対象外です。完全な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リポジトリにミラーリングされ、行単位で引用されています。
ベンチマークで最も優れた2つのテキスト認識エンジンは、レシートの文字精度において統計的に拮抗しています — 1つは従来のOCRエンジン、もう1つはドキュメント解析VLMです。SROIE 2019 CER 0.1971 (docTR) 対 0.1915 (Surya2)、0.006ポイント差です。差が出てくるのは、フィールドを抽出させた場合のみです。固定の正規表現パターンを通じて、Surya2の大文字小文字を統一し、ラベル構造化された出力は、docTRのクリーンだが生の行テキストに比べて4.2倍の速度でフィールドを抽出します(フィールド抽出F1:0.3183 対 0.0766)。LLMポストプロセッサーを追加すると、その差はほぼなくなります — フィールド抽出F1はdocTR 0.6171 対 Surya2 0.6139です。この2つのエンジンの本当の、決定的な違いは、運用範囲にあります:docTRが同等のハードウェア上で24.5倍の低レイテンシ、37倍の高スループット、1,000ページあたり22倍のコスト優位性を示しています。
そのトレードオフを1組の数字で表すと:docTRはレシート1ページを108.7 ms(p50)で処理し、1,000ページあたり$0.048のコストがかかります。Surya2は2,668.0 ms(p50)で処理し、1,000ページあたり$1.061のコストがかかります — 同じレシート、同じテスト分割、同じRTX 4090を使用しています。どちらのエンジンも「勝者」ではありません。それぞれ異なる軸で優れており、このページの目的は、同じ制御された実行結果から両方の軸を示すことです。
文字誤り率(CER)は古典的なOCRの評価指標です。挿入、削除、置換を正解文字数で割ったもので、CER が 0.197 ということは、100文字あたり約19.7文字が誤読されたことを意味します。単語誤り率(WER)は、単語粒度で同じ編集距離計算を適用したものです。この次元では、2つのエンジンは拮抗しています。
SROIE 2019 では、docTR と Surya2 がベンチマークで最も強い2つの文字認識エンジンであり、0.006 ポイントの差で隔てられています。これは361サンプルのコーパスではノイズ帯内です。WER も同じ物語を語ります:Surya2 0.2735、docTR 0.3199。英語レシートの文字精度という点では、「VLM は従来の OCR を上回る」という物語はこの比較では成立しません。
文字精度:統計的な拮抗
この拮抗が重要なのは、2つのエンジンがアーキテクチャ的に正反対だからです。docTR は2段階の従来型ニューラルOCRパイプラインで、検出器が単語をローカライズし、認識器がそれらを書き起こし、印刷テキストの元の大文字・小文字とレイアウトを保持します。Surya2 はドキュメントパースィング・ビジョン言語モデル(VLM)で、文書画像全体を読み取り、理解されたテキスト(大文字・小文字統合、ラベル/値ペアの結合、行の再整列など)を出力します。これは下流システムが求めるものに近いですが、正確な文字一致からは遠くなります。CER は正確な文字一致を評価するため、Surya2 に対してはやや保守的です。この非対称性にもかかわらず拮抗が維持されている事実が、この結果を意味あるものにしています。
| 指標(SROIE 2019、n=361) | docTR | Surya2 | 出典 |
|---|---|---|---|
| 文字誤り率(CER) | 0.1971 | 0.1915 | summary_metrics.csv · cer、doctr/sroie_2019 および surya2/sroie_2019 行 |
| 単語誤り率(WER) | 0.3199 | 0.2735 | summary_metrics.csv · wer、同じ行 |
表:summary_metrics.csv — cer および wer 列、sroie_2019 行。正確な値:docTR cer 0.19707 / wer 0.31990;Surya2 cer 0.19147 / wer 0.27352。低いほど良い。両方の実行は error_rate 0.0 で完了しました。
分岐点:標準のフィールド抽出が結果を逆転させる
4つのSROIEレシートフィールド(会社名、日付、住所、合計)において、従来のOCR+ルールベースのキーアクセス情報抽出(KIE)アプローチとして、エンジンの生テキストを同じ固定正規表現パターンでベンチマークすると、ランキングが逆転します。Surya2はフィールドF1で0.3183を達成し、docTRの0.0766を大きく上回り、4.2倍の優位性です。docTRは8エンジンの実行で最高クラスの文字精度を示しながら、正規表現フィールド抽出では最悪の結果となりました。テキスト精度とフィールド精度は切り離されています。
フィールド値F1は、抽出されたフィールド値と正解データの精度と再現率の調和平均です。1.0はすべてのレシートフィールドが完全に復元されたことを、0は何も抽出できなかったことを意味します。この逆転の背景にあるのは、前述の出力形状の違いです。正規表現はRM 12.00や14/08/2020のようなフォーマットされた値用に作成されており、Surya2の正規化されたラベル構造付き出力(大文字小文字統合、キー値マージ)はこれらのパターンに頻繁に一致します。一方、docTRの生行テキストはCERの観点では正確ですが、元の大文字小文字や区切り文字のノイズが残るため、パターンに一致しません。「正規表現フィールド抽出」列はベンチマークのpostprocessed_sroie_receipt_regex_*指標であり、OCRテキスト+下流ルールベース抽出を測定するもので、ネイティブの構造化出力ではありません。
出典: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) | docTR | Surya2 | 出典 |
|---|---|---|---|
| フィールド値F1(正規表現) | 0.0766 | 0.3183 | field_method_comparison.csv · regex_field_value_f1、doctr/sroie_2019およびsurya2/sroie_2019行 |
| フィールド値精度(正規表現) | 0.0623 | 0.2999 | field_method_comparison.csv · regex_field_value_accuracy、同じ行 |
| ドキュメントフィールド完全一致(正規表現) | 0.0000 | 0.0194 | field_method_comparison.csv · regex_document_fields_exact、同じ行 |
テーブル: field_method_comparison.csv — regex列、sroie_2019行。これらはpostprocessed_sroie_receipt_regex_*メトリクスです:各エンジンのOCRテキストに適用された固定パターンによる後処理(ネイティブ抽出ではなく後処理)。docTRのregexフィールドF1は0.0766で、2番目に優れたCERにもかかわらず、8つのエンジンすべての中で最低です。
The LLM Lever: Engine Choice Stops Mattering
両エンジンのOCRテキストをLLMポストプロセッサー(deepseek-v4-flash、temperature 0)に構造化抽出プロンプト付きで入力すると、フィールドの差はほぼ消滅します:docTR 0.6171 対 Surya2 0.6139 フィールドF1 — 従来のエンジンが0.003ポイントのわずかな優位、実質的には引き分けです。決定的なコンポーネントはOCRエンジンではなく、ポストプロセッサーとなります。
これは8エンジン全体のベンチマークで見られるパターンと同じです:LLM後処理は、文字形状の照合ではなく意味(数字、日付、名前)を理解するため、健全なエンジンを収束するフィールドF1帯に引き上げます。docTRのよりクリーンなベーステキストがわずかにリードし、Surya2の正規化された構造はLLMの下でその微小な優位を失います。このレバーには2つのコストがあります:LLM呼び出しはOCR時間に加えて、1文書あたり約2.0–2.3秒の中央値レイテンシーを追加します(docTRのテキストで1,996.3ms、Surya2で2,261.7ms、API発生で種類は同一)、また、エンジンが根本的に読み取れなかったテキストを救うことはできません。
| LLM後処理(SROIE 2019、n=361) | docTR | Surya2 | 出典 |
|---|---|---|---|
| フィールド値F1(LLM) | 0.6171 | 0.6139 | field_method_comparison.csv · llm_field_value_f1、doctr/sroie_2019およびsurya2/sroie_2019行 |
| フィールド値精度(LLM) | 0.6170 | 0.6136 | field_method_comparison.csv · llm_field_value_accuracy、同じ行 |
| 文書フィールド完全一致(LLM) | 0.1496 | 0.1551 | field_method_comparison.csv · llm_document_fields_exact、同じ行 |
| LLMレイテンシー中央値(ms) | 1,996.3 | 2,261.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)。
運用エンベロープ:実際の差が生まれるポイント
文字精度は拮抗し、フィールド精度はLLMの下で収束しますが、バッチパイプラインは数字が終わらなければどちらも気にしません。同じRTX 4090で同じ記録された$0.76/hrの料金で、docTRは449.3 ページ/分を維持し、1ページあたり108.7 ms p50、1,000ページあたり$0.048で動作します。一方、Surya2は12.1 ページ/分を維持し、2,668.0 ms p50、1,000ページあたり$1.061で動作します。これは37倍のスループット差、24.5倍のレイテンシ差、22.2倍のコスト差です。Surya2のペースに合わせて設計されたパイプラインは、docTRのペースに合わせて設計されたものとは、全く異なるアーキテクチャの議論になります。
コストは、壁時計実行時間 × RunPod RTX 4090料金($0.76/hour、ランマニフェストにタイムスタンプ付き)で計算されます。モデルの初期化を含み、実際にGPU時間に対して支払う料金です。スループットは、同じ初期化を含む壁時計のページ/分です。レイテンシ p50/p95は、ウォーム後にスコアリングされた定常状態の1ページあたり推論時間(モデルロードを除く)です。Surya2のテールは比例的に悪く、docTRの281.4 msに対して5,872.2 ms p95です。これは、最初のページでVLMのプリフィル/デコードのスパイクがテールを支配するためです。
出典:summary_metrics.csv — latency_p50_ms列、sroie_2019行。docTR 108.7166、Surya2 2667.9800。定常状態レイテンシ(ウォーム後にスコアリングする測定モード)。
出典:summary_metrics.csv — cost_per_1000_pages列、sroie_2019行。docTR 0.0479、Surya2 1.0609。コスト = 壁時計実行時間 × $0.76/hr(モデル初期化を含む)、ランマニフェストにタイムスタンプ付き(2026年8月)。
| 動作範囲 (SROIE 2019, n=361) | docTR | Surya2 | 出典 |
|---|---|---|---|
| レイテンシ p50 (ms) | 108.7 | 2,668.0 | summary_metrics.csv · latency_p50_ms, doctr/sroie_2019 および surya2/sroie_2019 行 |
| レイテンシ p95 (ms) | 281.4 | 5,872.2 | summary_metrics.csv · latency_p95_ms, 同上行 |
| 1分あたりのページ数 | 449.3 | 12.1 | summary_metrics.csv · pages_per_minute, 同上行 |
| 1,000ページあたりのコスト | $0.048 | $1.061 | 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; コストにはモデル初期化が含まれ、純粋な定常スループットではありません。正確な値: docTR p50 108.7 / p95 281.4 / 449.3 pg/min / $0.0479; Surya2 p50 2668.0 / p95 5872.2 / 12.1 pg/min / $1.0609。
CORD(インドネシアのレシート):両エンジンが崩壊、プロトコルにより隔離
どちらのエンジンもインドネシアのレシートを主に学習していなかったため、CORD v2(100サンプル、ネストされたフィールド menu/sub_total/total)はクロス言語ストレステストとして機能します — そして両者とも崩壊します:CER 0.8959(Surya2)と 0.9101(docTR)。ベンチマークプロトコルに従い、CORDの数値はSROIE比較から隔離されたままです — いかなるランキングにも統合されません — なぜなら、CORDのグランドトゥルーステキストがアノテーション構造を埋め込んでおり、言語の不一致に加えて各エンジンの生CERを膨らませるためです。
フィールド指標においても、SROIEからの逸脱パターンは圧縮された形で維持されます:正規表現パターンを通じてdocTRは1つもフィールドを復元できず(0.0000 field F1 — CSVに記録された文字通りのゼロであり、欠損値ではありません)、英語形式のパターンがインドネシア語テキストに何もマッチしなかったためです。一方、Surya2の正規化された出力は0.2458を獲得します。その後、LLMがペアを再収束させ、0.5500(docTR)と 0.5203(Surya2)にします — 言語ショックはエンジンではなく、ポストプロセッサーによって吸収されます。CORDはここでは言語ロバスト性の文脈として引用されており、SROIEの数値と単一のリーダーボードに意図的にプールされることはありません。
| CORD v2、インドネシアのレシート(n=100) | docTR | Surya2 | 出典 |
|---|---|---|---|
| 文字誤り率(CER) | 0.9101 | 0.8959 | summary_metrics.csv · cer、doctr/cord_v2およびsurya2/cord_v2行 |
| フィールド値 F1(正規表現) | 0.0000 | 0.2458 | field_method_comparison.csv · regex_field_value_f1、同じ行 |
| フィールド値 F1(LLM) | 0.5500 | 0.5203 | field_method_comparison.csv · llm_field_value_f1、同じ行 |
表:summary_metrics.csv(cer)およびfield_method_comparison.csv(field F1)、cord_v2行。これらの数値をいかなるSROIEランキングにも統合しないでください:CORD CERは、グランドトゥルースにおける言語の不一致とアノテーション構造による膨張を組み合わせたものです。正規表現パターンは英語形式用に記述されていました。docTRの正規表現フィールドF1の0.0000は、CSVに記録された文字通りのゼロであり、欠損値ではありません。
優劣は workload に依存:比較グリッド
「優れている」は workload に依存します。この2つのエンジンは軸を明確に分割しており、その分割が発見です:文字精度は互角、構造化フィールドの利便性は Surya2 が有利、コスト・レイテンシ・スループットのすべての軸で docTR が有利、LLM ポストプロセッサーにより最終フィールド品質に対するエンジン選択はほぼ無関係になります。
よくある質問
Surya2はレシートにおいてdocTRよりも正確ですか?
いいえ — 文字の生の精度では統計的に拮抗しています:SROIE CER 0.1915(Surya2)対 0.1971(docTR)、0.006ポイントの差(summary_metrics.csv, cer, sroie_2019行)。異なるのは、箱から出してすぐの構造化フィールド出力(Surya2が正規表現で4.2倍優位)と、運用範囲(docTRがレイテンシで24.5倍、コストで22.2倍、スループットで37倍優位)です。
なぜdocTRは文字精度が最も良いのに、正規表現フィールド抽出は最悪なのでしょうか?
2つの指標が異なる出力を評価しているためです。docTRはクリーンな生の行テキストを返します — 元の大文字小文字と区切り文字を保持 — し、フォーマットされた値用に書かれた固定の正規表現パターンは、それに対してほぼ失敗します:そのSROIE正規表現フィールドF1は0.0766で、基礎となる実行の全8エンジンの中で最低であり、2番目に良いCER(0.1971)に対しています(summary_metrics.csv cer, field_method_comparison.csv regex_field_value_f1)。Surya2の大文字小文字を統一し、ラベル構造化された出力は、0.3183でパターンに一致します。代わりに両方をLLMに渡すと、差は0.003に縮まります — ボトルネックはOCRではなく、正規表現でした。
LLMポストプロセッサーを追加すると、docTRとSurya2は同等になりますか?
ほぼ正確に — docTR 0.6171 対 Surya2 0.6139 SROIEでのLLMフィールドF1(field_method_comparison.csv, llm_field_value_f1, sroie_2019行)。この収束のコストは、文書あたり約2.0〜2.3秒の追加の中央LLMレイテンシ(llm_median_latency_ms, 同じ行)であり、同期的なページごとの待ち時間よりも、非同期バッチ処理に適しています。
docTRはSurya2よりどれだけ高速で安価ですか?
同じRTX 4090で$0.76/hrの条件下で、24.5倍低いp50レイテンシ(108.7 ms 対 2,668.0 ms)、37倍高いスループット(449.3 対 12.1 ページ/分)、および1,000ページあたり22.2倍低いコスト($0.048 対 $1.061)です(summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, sroie_2019行)。
なぜ両エンジンともCORDレシートでこれほど低いスコアを示すのですか?
SROIEランキングから独立したベンチマークプロトコルが分離している2つの複合的な原因があります。言語の不一致(両エンジンの学習対象外であるインドネシア語レシート)と、CORDの正解テキストにおけるアノテーション構造の膨張です。CERはdocTRで0.9101、Surya2で0.8959となります(summary_metrics.csv、cer、cord_v2行)。LLMを追加すると、フィールド指標は衝撃の一部を吸収します(0.5500 vs 0.5203)が、CORD行は引用のみで、いかなる統合ランキングにもプールされません。
レシートパイプラインはdocTRとSurya2、どちらのエンジンを選ぶべきですか?
パイプラインが消費する軸によります。コスト計測付きの大量生テキストには、docTRの性能(108.7 ms、449.3ページ/分、$0.048/1Kページ)が優れています。ポストプロセッサーなしの構造化フィールドには、Surya2の標準正規表現F1(0.3183 vs 0.0766)がより良い出発点です。LLM後処理による最終フィールド品質では、選択の違いはほとんどありません(0.6171 vs 0.6139)。これらの結果は、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:スコアリングパスの前に固定ウォームアップパスを実行し、レイテンシ数値を定常状態にする)で実行された。両実行はエラー率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月)に記録。
- エンジン: ファインチューニングなしの出荷時状態。バージョン固定:docTR v1.0.1(従来型2段階ニューラルOCR、GPU)およびSurya2(surya-ocr 0.22.1)(ドキュメントパースVLM、vLLMで提供)—公開リポジトリのモデル表(README.md)および実行マニフェストに基づく。
- LLMポストプロセッサー: 確定的出力のためtemperature 0でAPI経由のdeepseek-v4-flash(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テキストと正解データ間の編集距離(挿入+削除+置換)を正解文字数で割ったもの。低いほど良い。大文字小文字や表記規則に敏感で、Surya2の正規化出力(大文字小文字統合、ラベル/値の結合)に対してはやや保守的な評価となる。
- 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,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、レイテンシ、コスト、スループットの数値はすべて、このファイルのdocTRおよびSurya2の行に由来する。
- field_method_comparison.csv(GitHub raw)。16行。列名: model, dataset, llm_model(= deepseek-v4-flash)、正規表現/LLMフィールド値精度およびF1、ドキュメントフィールド完全一致、llm_median_latency_ms、トークン数。正規表現/LLMフィールドF1の数値はすべて、このファイルのdocTRおよびSurya2の行に由来する。
- ImageToTableai/benchmark-ocr リポジトリ。結果CSV、編集済みランマニフェスト、固定プロトコル、データセットサンプルリスト(固定テスト分割)を公開しているパブリックリポジトリ。
- results/manifests/(GitHub)。公開された各ラン(16ラン)に対応する編集済みmanifest.json。モデルバージョン、GPU/ドライバー、torch/CUDA/Pythonバージョン、価格タイムスタンプ付きコストメタデータ、アーティファクトハッシュを含む。
- 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。ここでは、ドキュメント解析VLMが最大の利点を主張しているレイアウト/テーブル/数式/長文ドキュメントの処理能力は一切測定されていません。Surya2がマーケティングで強みとしている点は未測定です。このページから「docTRがすべてにおいて優れている」と結論づけないでください。
- サンプルサイズ:英語361件 + インドネシア語100件の領収書。フィールドF1とCERはコーパスに依存します。数百分の一の単桁差(0.006のCER差、0.003のLLM-F1差を含む)はノイズとして扱うべきであり、エンジニアリング上の真実ではありません。
- 単一GPUティアと単一価格:すべての数値は、ランマニフェストで2026年8月のタイムスタンプが付いた、$0.76/hrのRTX 4090 1台から取得しています。他のGPU、マルチGPUサービス、バッチスケジューリング、または価格変動は、レイテンシ、スループット、コストを変動させます。予算策定前に、現在のレートでコストを再算出してください。
- 単一LLMポストプロセッサー:すべてのLLM行は、temperature 0のdeepseek-v4-flashを使用しています。異なるLLMは絶対的なフィールドF1を変動させます。収束順序は、余剰部分で移動する可能性があります。LLMレイテンシ(中央値約2.0〜2.3秒、field_method_comparison.csv llm_median_latency_ms)はAPIによるもので、いずれかのエンジン自体のレイテンシの一部ではありません。
- 正規表現チューニング:パターンセットはデータセットごとに1回作成されました。フォーマットごとに、高度にチューニングされたパターンライブラリは、独自のレイアウトでより高いスコアを出す可能性があります。ただし、LLMが排除するメンテナンスコストが発生します。
- CORD CERはモデルごとの品質指標ではありません:CORDのグランドトゥルースはアノテーション構造を埋め込んでおり、いずれのエンジンもインドネシア語を主に学習していません。CORD CER(0.90〜0.91)は、言語の不一致とグランドトゥルースの膨張を反映しています。CORD行は文脈付きで引用され、SROIEランキングには一切統合されません(プロトコルルール)。
- VLMのCERの公平性:CERは正確な文字一致をスコアリングするため、Surya2の大文字小文字統合、ラベル統合出力は、誤読ではなく出力規約によって軽微なペナルティを受けます。したがって、CERの同率はSurya2をわずかに過小評価しています。フィールド指標の方が、より公平なクロスファミリーの基準です。
- 2つのエンジンのみ:このヘッドトゥヘッド比較は、基礎となるランの他の6つのエンジン、クラウド/API OCRサービス、ホスト型VLM APIを意図的に除外しています。それらのレイテンシと価格モデルは、ここで測定されたローカルエンジンとは根本的に異なります。
- バージョン固定:結果はdocTR v1.0.1およびSurya2 0.22.1(2026年8月)に有効です。いずれかのエンジンの新しいリリースは、このページのすべての数値を変動させる可能性があります。
関連リファレンス: Traditional OCR vs Document Parsing VLMs · Regex vs LLM Field Extraction · Field-Level vs Character-Level Accuracy · Receipt OCR Accuracy
関連読書: AI OCR vs Traditional OCR Accuracy · AI Image Data Extraction vs Traditional OCR · AI Document Extraction Pricing (2026)