レシートのフィールド抽出におけるRegex vs LLM
第一者ベンチマーク結果（2026年）

SROIE Results: English Receipts (361 Samples)

英語レシートでは、8つのエンジンすべてにおいてLLMが正規表現を上回ります。最小の向上は1.76倍（PaddleOCR-VL 0.337 → 0.592）、最大は8.1倍です。また、LLMはモデル間の差をほぼなくします。7つの非Tesseractエンジンのうち6つが0.05ポイントの範囲内（0.569–0.617）に収まるのに対し、正規表現の結果は0.26ポイント（0.077–0.338）に分散していました。

SROIE（Scanned Receipt OCR and Information Extraction, ICDAR 2019）は、標準的な英語レシートベンチマークです。4つの対象フィールド（会社名、日付、住所、合計）を持つ361件のテストレシートから構成されています（Huang et al., 2019）。各エンジンはまず共有のRTX 4090環境でOCRテキストを生成し、そのテキストは2つの並列後処理器に供給されました。1つは固定の正規表現パターンセット（従来のOCR + ルールベースKIEアプローチ）、もう1つは構造化抽出プロンプトを使用したLLM deepseek-v4-flashです。両者は同じ正解フィールドに対してスコアリングされました。チャートは、エンジンごとの正規表現フィールドF1（青）とLLMフィールドF1（緑）を示しています。

Source: field_method_comparison.csv — rows for dataset=sroie_2019, columns regex_field_value_f1 / llm_field_value_f1 (stored as 0–1 decimals, shown as %). LLM postprocessor: deepseek-v4-flash (llm_model column). 361 samples per engine (llm_ok_count).

Source: field_method_comparison.csv — sroie_2019 rows: regex_field_value_f1 / llm_field_value_f1 / regex_field_value_accuracy / llm_field_value_accuracy (0–1 decimals shown as %). docTR F1 0.0766 → 0.6171; Surya2 0.3183 → 0.6139; PaddleOCR 0.3254 → 0.5810.

CORD結果：インドネシアのレシート（100サンプル、ストレステスト）

CORDは差を広げます。LLMが向上するからではなく、正規表現が崩壊するからです。8つのエンジンのうち6つが正規表現フィールドF1を10.8%以下に留め、2つ（docTR 0.0%、EasyOCR 0.7%）はほぼ回収できません。LLMはTesseract以外のすべてのエンジンを33.8%以上に引き上げ、手書きパターンが通用しない言語やレイアウトにおいても抽出が汎用的であることを証明しています。

CORD v2はネストされたフィールド（menu、sub_total、total）を持つインドネシア語のレシートデータセットです（Park et al., 2019）。8つのエンジンのいずれもインドネシア語レシートで主にトレーニングされていないため、クロス言語ストレステストとして実施しました。この表を読む際に2つの注意点があります。まず、CORDの正解テキストにはアノテーション構造やVLM出力の正規化の違いが含まれ、すべてのエンジンの生CERを体系的に水増しします。したがって、以下のフィールド指標が、CERではなく、公正なモデル間比較です。次に、正規表現パターンはフラットな英語SROIEスキーマ用に書かれていました。CORDのネストされたスキーマとインドネシア語のフォーマット（Rp通貨、日付規則）はこれらを打ち破ります。これはまさに発見です：特定の市場に合わせたルールは通用しません。

出典：field_method_comparison.csv — データセット=cord_v2の行、列regex_field_value_f1 / llm_field_value_f1（0–1の小数を%で表示）。各エンジン100サンプル（llm_ok_count）。

出典：field_method_comparison.csv — cord_v2行（正規表現/LLM フィールド値F1および精度、0–1の小数を%で表示）。PaddleOCR LLM F1 0.0154 → 0.5527；docTR 0.0 → 0.5500；tesseract 0.0752 → 0.1627。

LLMがギャップを埋める理由と、その限界

数字に見られる3つのパターンが、表面下で何が起きているかを説明します。それぞれ、正確なCSVセルを示した検証可能な主張です。

(a) LLMは0.26ポイントのモデル間ギャップを0.05ポイントの帯域に縮める

正規表現では、選択するエンジンが極めて重要でした：SROIEのフィールドF1は0.077（docTR）から0.338（Unlimited-OCR）まで0.26ポイントの広がりがありました。LLMでは、7つの非Tesseractエンジンのうち6つが0.569（Docling）から0.617（docTR）の間に収まり、0.05ポイントの帯域となりました（field_method_comparison.csv、sroie_2019行、regex_field_value_f1対llm_field_value_f1）。上流のOCRは読み取れるテキストを生成するだけでよく、LLMはそれをほぼエンジン非依存の品質でフィールド抽出します。この帯域から外れる2つのエンジンがあります：EasyOCRの0.372（英語レシートでの最低のLLM F1）とTesseractの0.439です。CORDでは、Tesseractが明らかに遅れを取っています — その0.163はテーブル全体で最悪のLLM結果です。

(b) Tesseractの限界はOCRによって決まる

「ゴミを入れればゴミが出る」はLLM後処理にも当てはまります。Tesseractのインドネシア語レシートにおける生のOCRテキストの文字誤り率は0.9523です（summary_metrics.csv、tesseract/cord_v2、cer） — 100文字中約95文字が誤りや順序違いです。したがって、CORDでのLLMフィールドF1は0.1627となります（field_method_comparison.csv、tesseract/cord_v2、llm_field_value_f1）：LLMは読めないテキストから会社名や合計を抽出できません。あらゆる後処理の限界は、その下にあるOCRの基本品質によって決まります — これはいかなるプロンプトエンジニアリングも解消できない制約です。

(c) docTRが最も恩恵を受ける：正規表現のフロアからLLMのトップへ

docTRの事例は、問題がOCRではなく後処理にあったことを最も明確に示しています。SROIEでの正規表現フィールドF1は、8つのエンジンすべてで最低の0.0766でした — そのクリーンで正確なテキスト（SROIE CER 0.1971、ベンチマークで最高、summary_metrics.csvのdoctr/sroie_2019行）は、桁区切り付きの合計や複数行の住所に対する正規表現パターンに単にマッチしなかったのです。LLMでは同じテキストがベンチマーク最高のSROIE結果である0.6171を生み出します — 8.1倍の向上であり、テーブル全体で最大です（field_method_comparison.csv、doctr/sroie_2019、regex_field_value_f1 0.0766 → llm_field_value_f1 0.6171）。CORDでも効果は繰り返されます：正規表現では0.0、LLMでは0.5500です。

Regexで十分な場合とLLMを使うべき場合

正直なトレードオフは「Regexが壊れている」ではなく「レシートが多様な場合にRegexは脆い」ということです。Regexによる後処理は決定論的で、無料で、即座に完了します。一方、LLMによる後処理はトークンを消費し、1.8〜2.4秒の中央値（ドキュメントあたり）を追加します（field_method_comparison.csv、全16行のllm_median_latency_ms）。その見返りに、LLMはSROIEで1.76〜8.1倍多くのフィールドを回復しました。また、Regexがほとんどのエンジンでほぼゼロに崩壊したCORDでは、LLMはルールベースの抽出では到達できなかったフィールドの33.8〜55.3%を回復しました。

Regexで十分な場合：ドキュメントが少数の安定したレイアウトから来て、必要なフィールドがほぼ一定の形式で出現する場合（固定の請求書番号パターン、単一の日付規則、1つの通貨など）には、Regexが適切なツールです。コストがかからず、マイクロ秒で実行でき、失敗も予測可能です。ベンチマークの下限ケースがこれを示しています。レシートに整合したRegexを持つエンジンでも、SROIEでフィールドF1スコア0.34に達しました（Unlimited-OCR 0.3376、PaddleOCR-VL 0.3368）。

LLMを使うべき場合：フォーマットのばらつきが生じた場合（複数の通貨、地域別の日付形式、複数行の住所、多様なスタイルのベンダー名、または第二言語など）には、LLMを使います。これらはすべてパターンを崩しますが、LLMは1つのプロンプトでそれらすべてを吸収します。ベンチマークのCORD結果は、「もう1つの言語」がルールベースのパイプラインにどれほどのコストをもたらすかを定量的に示しています。RegexのフィールドF1は、英語のSROIEでの0.08〜0.34から、インドネシア語のCORDでの0.00〜0.34に低下しましたが、LLMは0.16〜0.55を維持しました。これは、Regexアプロー�プが100%のペナルティを支払い、LLMは部分的にしか支払わなかったものです。ほとんどの本番フローに適したアーキテクチャはハイブリッドです。可変フィールドにはLLM抽出を、厳格な期待フォーマットを持つフィールドにはRegexまたはルールベースの検証を使い、ドキュメントあたり1.8〜2.4秒のLLMコストは、同期的なユーザー待ちではなく、非同期バッチ処理で償却します。

よくある質問

LLMによるフィールド抽出は正規表現による抽出よりも正確ですか？

はい、このベンチマークでは、すべての行において、LLM後処理（deepseek-v4-flash）は、2つのデータセット（field_method_comparison.csv、全16行）のすべての8つのOCRエンジンにおいて、正規表現後処理を上回りました。SROIE英語レシートでは、LLMフィールドF1は0.37–0.62で、正規表現の0.08–0.34を上回りました。CORDインドネシア語レシートでは、0.16–0.55対0.00–0.34でした。

LLM後処理でレシートフィールドを最もよく抽出するOCRモデルはどれですか？

SROIEではdocTRで、フィールドF1は0.6171です。ただし、LLMが関与すると、エンジン間の差はほぼなくなります。7つの非Tesseractエンジンのうち6つが、0.569から0.617の間に収まります（field_method_comparison.csv、sroie_2019行、llm_field_value_f1）。CORDでは、PaddleOCRが0.5527でリードし、docTRが0.5500でそれに次ぎます。

なぜTesseractはLLMを使っても遅れを取るのですか？

そのOCRテキストが劣化しすぎており、どの後処理でもフィールドを復元できないためです。インドネシア語レシートでは、文字誤り率が0.9523（summary_metrics.csv、tesseract/cord_v2）で、LLMフィールドF1が0.1627に制限されます。これはベンチマークにおける最悪のLLM結果です（field_method_comparison.csv、tesseract/cord_v2、llm_field_value_f1）。

LLMは正規表現に比べてフィールド抽出をどれだけ改善しますか？

英語レシートではエンジンによって1.76×から8.1×の改善が見られます。最大の改善はdocTRで、フィールドF1が0.077から0.617に向上しました（field_method_comparison.csv sroie_2019行）。インドネシア語レシートでは改善はさらに大きく、PaddleOCRで36×、docTRでは正規表現がほぼ何も復元できなかったため（0.0から0.55）、事実上無限大です。

LLMの後処理はすべてのフィールドを正しく抽出できますか？

いいえ — そして、読者はそう期待すべきではありません。ベンチマークで最高のLLMフィールドF1は0.617（docTR、SROIE）で、約38%のフィールドがまだ見逃されているか間違っていたことを意味し、最高の文書全体の完全一致率は15.5%（Surya2、SROIE、llm_document_fields_exact）です — つまり、最大でも約6文書に1つだけが4つのフィールドすべてを完全に正しく抽出していました。LLM抽出は正規表現よりも大幅な改善ですが、万能薬ではありません。本番環境では、フィールドレベルの信頼度スコアリングと人間のレビューが依然として必要です。

LLMの後処理はどれほど遅く、高コストですか？

このベンチマークでは、LLM呼び出しにより文書あたり1.8–2.4秒の中央値レイテンシが追加されました（field_method_comparison.csv、llm_median_latency_ms、全16行）。また、16グループの完全な実行では約133万プロンプト + 28万完了トークンが消費されました（llm_prompt_tokens / llm_completion_tokensの合計）。これはリアルタイムのフィールド抽出レイテンシではなく、非同期バッチ処理に適しており、インタラクティブな検索には適していません。

LLMの後処理は英語以外のレシートで機能しますか？

正規表現よりも優れていますが、上限は低くなります。インドネシアのCORDレシートでは、LLMはフィールドF1を0.16–0.55に保ち、正規表現は0.00–0.34に崩壊しました（field_method_comparison.csv、cord_v2行） — しかし、最高のCORD結果（0.5527）は最高の英語結果（0.6171）にまだ及んでいません。これは、より困難な文字体系と劣化したOCRベースの両方を反映しています。英語レシート用に作成されたルールは基本的に機能しなくなりましたが、LLMは代わりに緩やかに劣化しました。

方法論と出典

プロトコル

このページでは、ImageToTable.aiのオープンソースOCRベンチマークにおけるフィールド抽出の比較を報告しています。これは、第三者の主張の調査ではなく、独立した再現可能な実験ラン（公式ティア）です。各（モデル × データセット）ペアのパイプラインは以下の通りです：OCRエンジンがレシート画像からテキストを生成し、そのテキストを2回抽出します。1回は固定の正規表現パターンセットで、もう1回はLLMポストプロセッサーで行い、両方の出力が同じ正解フィールドに対してスコアリングされます。LLMポストプロセッサーはdeepseek-v4-flash（比較CSVのllm_modelカラム）で、決定論的な出力のためにtemperature 0で実行されます。361件のSROIEと100件のCORDサンプルはすべて正常に完了しました（llm_ok_count = 361 / 100）。

ランタイム環境

• ハードウェア：すべてのGPU実行はNVIDIA RTX 4090（24 GB）で行いました。PyTorchベースのエンジン（docTR、EasyOCR、Docling）はPyTorch 2.8.0+cu128（CUDA 12.8）で実行；TesseractはCPUのみで実行（GPUコストなし）；vLLMで提供されるエンジン（Surya2、Unlimited-OCR、PaddleOCR-VL）はvLLMポッドで実行しました。ドライバーおよびPythonのバージョンは実行ごとに若干異なり、削除済みのランマニフェストに正確に記録されています（以下のアーティファクトアクセスを参照）。
• LLMポストプロセッサー：API経由のdeepseek-v4-flash、temperature 0。
• 測定モード：warm_then_scored — スコアリングパスの前に固定のウォームアップパスが行われるため、レイテンシー数値は定常状態です。
• データセット：SROIE 2019 テスト — 361件の英語レシート、フラットフィールド（会社、日付、住所、合計）、CC-BY-4.0；CORD v2 テスト — 100件のインドネシア語レシート、ネストされたフィールド（メニュー、小計、合計）、CC-BY-4.0。
• サンプル数：SROIE 361 / CORD 100、すべて固定のテスト分割から（トレーニングデータの漏洩なし）。

両方のポストプロセッサーが消費した上流OCRテキストは、これらのエンジンバージョンからのものです：

完全なランごとの再現性フィンガープリントは、パブリックリポジトリのベンチマークの削除済みランマニフェスト（results/manifests/）にあります（公開ランごとに1つのmanifest.json、合計16件）。各マニフェストには、ランID、モデル＋バージョン、ランナースクリプトハッシュ（SHA-256）、GPUモデル/ドライバー/VRAM、torch/CUDA/torchvision/torchaudioバージョン、Pythonバージョン、pip-freezeハッシュ、コストメタデータ（GPU $/時間と価格タイムスタンプ）、測定モード、およびアーティファクトハッシュ（サンプルリスト、予測、指標、パフォーマンス）が開示されています。

指標の定義

• フィールド値F1（正規表現アプローチ）：正規表現による後処理を用いた抽出フィールド値の精度と再現率の調和平均 — 従来のOCR + ルールベースKIEアプローチ。列名：regex_field_value_f1。
• フィールド値F1（LLMアプローチ）：LLMポストプロセッサーの出力に対して計算された同じ指標 — OCR + LLM後処理アプローチ。列名：llm_field_value_f1。この2つのアプローチは異なるパイプラインであり、混合されることはありません。
• フィールド値精度：抽出されたフィールド値のうち、正解データと完全に一致する割合（regex_field_value_accuracy / llm_field_value_accuracy）。
• ドキュメントフィールド完全一致：すべての対象フィールドが完全に一致したドキュメントの割合（regex_document_fields_exact / llm_document_fields_exact）。
• CER/WER（コンテキストのみ）：生のOCRテキストの文字/単語誤り率。このページではTesseractのLLM上限を説明するためにのみ使用。

成果物へのアクセス

1. field_method_comparison.csv（GitHub raw）。16行 = 8モデル × 2データセット；列：model, dataset, llm_model（= deepseek-v4-flash）, regex/llm field F1 + accuracy, document-fields-exact, llm_median_latency_ms, llm_prompt_tokens, llm_completion_tokens。このページのすべてのフィールドF1および精度の数値は、このファイルの行に追溯できます。
2. summary_metrics.csv（GitHub raw）。モデル × データセットごとのCER/WER。Tesseract上限の説明（tesseract/cord_v2 cer 0.9523）およびdocTRのSROIE CER 0.1971に使用。
3. ImageToTableai/benchmark-ocr リポジトリ。結果CSV、実行マニフェスト、再現用データセットサンプルリストを公開しているリポジトリ。
4. results/manifests/（GitHub）。公開された各実行（16実行）に対し、上記の実行環境フィンガープリントと成果物ハッシュを記載した、修正済みmanifest.json。
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019)。SROIEデータセットの定義とライセンス。
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2019)。CORD v2データセットの定義とライセンス。

制限事項

• 文書の範囲: レシートのみ（SROIE + CORD）。発見事項は、さらなるテストなしに請求書、フォーム、または長文書には一般化されません。
• サンプルサイズ: 英語361件 + インドネシア語100件のレシート。フィールドF1はコーパス構成に敏感です。数百分の一の単一点差はノイズとして扱ってください。
• 単一LLMモデル: すべてのLLM行はdeepseek-v4-flashを使用しています。異なるLLM（サイズ、プロンプティング、またはベンダー）では異なる絶対数値が得られます。正規表現対LLMの順序は、余裕のある範囲で変動する可能性があります。
• CORDの正解データに関する注意: CORD gt_textにはアノテーション構造とVLM正規化の違いが含まれるため、CORD上の生のCERはすべてのエンジンで系統的に過大評価されています（例：PaddleOCR-VLのCER 1.08はアーティファクトであり、テキスト品質の実際の読み取りではありません）。フィールドメトリクスが公正な比較です。CERはここではTesseractの説明にのみ使用されています。
• レイテンシはリアルタイムの抽出レイテンシではありません: llm_median_latency_ms（1.8–2.4秒）は、OCRテキストからLLMフィールド抽出呼び出し全体をカバーし、フィールドごとのルックアップではなく、OCR時間自体も含まれません。
• 正規表現のチューニング: 正規表現パターンは、データセットごとに一度だけ記述された固定セットです（SROIE-flatスキーマ）。ベンダーごとに高度にチューニングされた正規表現ライブラリは、独自のフォーマットでより高いスコアを出す可能性がありますが、LLMが排除するメンテナンス負担を伴います。

関連リファレンス: フィールドレベル vs 文字レベルの精度 · レシートOCR精度 · 文書タイプ別のOCR精度

関連読書: OCR精度の主張を読み解く方法