文書解析VLMにおいてCERが誤解を招く理由
第一者ベンチマークデータ(2026年)で定量化
最終レビュー: 2026-08-18 · 実行階層: 公式 · 第一者ベンチマーク · 8エンジン × 2レシートデータセット
本ページの対象外: 文字レベルとフィールドレベルの精度の定義上の違いは、関連するフィールドレベル vs 文字レベルの精度の定義ページに記載されています。本ページはその差を定量化するデータ層です。請求書、フォーム、長文書は測定されていません。レシートのみ(SROIE 2019英語、CORD v2インドネシア語)、1つのGPU階層(RTX 4090)、2026年8月のモデルバージョンです。
範囲の声明: 機構はレシート(SROIE 2019英語、テストサンプル361件;CORD v2インドネシア語、テストサンプル100件)を用いた第一者ベンチマークデータで示されています。約76%/18%/10%のCER分解はプロトコルノート由来の推定値であり、CSV列ではありません。CORDはSROIEランキングに統合されることはありません。異なる言語、異なる正解構造のためです。
文字誤り率(CER)は完全文字一致アルゴリズムであり、品質計測器ではありません。正解と異なる文字ごとに1つの誤りを課します。このベンチマークでは、このスコアリング規則 alone — 本物の誤読の前に — エンジンをランキングの上位と下位の間で移動させます。Unlimited-OCRは同じ361件のSROIEレシートで最悪のCER(0.6552)と最良の正規表現フィールドF1(0.3376)を記録し、docTRは2番目に良いCER(0.1971)と最悪のフィールドF1(0.0766)を記録します。
記述者が最もよく必要とする3つの数値:VLMのSROIE CER予算の約18%が大文字小文字の置換のみ(プロトコル由来の推定値)です。TAN CHAY YEEをtan chay yeeに統一することは、フィールド値が正しいにもかかわらず誤りとしてスコアリングされます。1.0805はPaddleOCR-VLのCORD CERで、8エンジンすべての中で最悪です。これはCORDの構造に富んだ正解の産物ですが、そのCORDフィールドF1は0.3412でベンチマーク全体で最良です。そして、CER単独でランキングすると誤った勝者を選ぶことになる0.6552 / 0.3376のCER最悪/フィールド最良の逆転です。
CERは完全一致スコアリングアルゴリズムであり、品質計測器ではない
CERは、認識されたテキストと正解テキスト間のレーベンシュタイン編集距離です。つまり、一方を他方に変換するために必要な最小限の文字挿入・削除・置換の回数を、正解の長さで割ったものです(正式な定義はOCR-D評価仕様で公開されています)。CERは差異を数えるものであり、誤読と正当な再フォーマットを区別することはできません。エンジンの出力規約が正解と異なる場合(大文字小文字、区切り文字、行の順序など)、CERは誤読ではない行為に対してエラーとして課金します。
従来のOCRエンジン(Tesseract、PaddleOCR、EasyOCR、docTR)は、元の大文字小文字と行レイアウトを保持した生の文字列を出力するため、その出力規約は正解に近く、CERは本質的な読み取り誤差に近いものを測定します。文書解析VLM(Surya2、Unlimited-OCR、PaddleOCR-VL)は、理解されたテキストを出力します。これらは大文字小文字の統一(TAN CHAY YEEがtan chay yeeになる)、ラベル/値の結合(INVOICE NO\n: PEGIVがInvoice No : PEGIVになる)、行の再配置などを行います。これはスキャナではなく、リーダーの出力規約です。統合された大文字小文字や結合された行のすべてが編集距離のペナルティとなり、たとえ基礎となるフィールド値が正しくても課されます。
ベンチマークのプロトコル分析によると、公開されたSROIE予測におけるVLMの生のCER予算は、おおよそ~76%が正解と同一の文字、~18%が大文字小文字の置換、~10%が行結合/区切り文字の欠落に分解され、実際のフィールド値(会社名、合計、日付、住所)は正しいままです。この分解は、ベンチマークの分析ノートに基づくプロトコル推定であり、CSV列ではありません。この内訳は方向性を示すものであり、正確な数値ではありません。重要なのはその方向性です。大文字小文字の統一だけで、クリーンな英語レシートにおけるVLMの「悪い」CERの大部分を説明できます。
2つのCSV行が、分解なしにメカニズムを明らかにします。Unlimited-OCRはSROIEでCER 0.6552だがWER 0.4779とスコアリングします。文字列は乱雑に見えますが、単語は生き残ります。大文字小文字の統一が単語を壊さずに文字を置換するためです(summary_metrics.csv、cer / wer、unlimited_ocr/sroie_2019行)。そして、正規化が最も少ないVLMであるSurya2は、CER 0.1915とスコアリングします。これは8エンジン全体の実行における最良の生CERであり、強力な従来型エンジンと区別がつきません(summary_metrics.csv、cer、surya2/sroie_2019行)。CER列が主に測定しているのは、VLMの読み取り能力ではなく、VLMの出力規約です。
逆転が証明するもの:CERとフィールドF1の不一致
ベンチマークのCERランキングとフィールド抽出ランキングは、実質的に一致しません。8つのエンジンをSROIE CERで順位付けすると、勝者はSurya2(0.1915)です。一方、正規表現フィールドF1(本番パイプラインが消費する指標に近いもの)で順位付けすると、勝者はUnlimited-OCR(0.3376)であり、CERでは最下位のエンジンです。この2つの列のうち、1つはダウンストリームシステムが実際に消費するものを測定していません。
フィールドF1は、抽出されたフィールド値(SROIEの会社名、日付、住所、合計)における適合率と再現率の調和平均です。フィールドは二値単位であり、一致するか、失敗するかのいずれかです。正規表現列はすべてのエンジンのテキストに同じ固定パターンセットを適用するため、唯一の変数はエンジンの出力です。以下の表は、361件のレシートにおいて、各エンジンのCERと正規表現フィールドF1を、両指標での順位とともに示しています。
出典:summary_metrics.csv — cerおよびfield_f1_regex列、sroie_2019行(各エンジン361サンプル、8エンジンすべてでerror_rate 0.0)。この2つの系列は、大きさとして互いに比較可能ではありません(単位が異なるため)が、順位が一致しない点が重要です。
| モデル | 種類 | CER | WER | Regex field F1 | CER順位 | Field-F1順位 | 出典 |
|---|---|---|---|---|---|---|---|
| Surya2 | ドキュメント解析VLM | 0.1915 | 0.2735 | 0.3183 | 1 | 4 | summary_metrics.csv · surya2/sroie_2019行 |
| docTR | 従来型OCR (GPU) | 0.1971 | 0.3199 | 0.0766 | 2 | 8 | summary_metrics.csv · doctr/sroie_2019行 |
| PaddleOCR | 従来型OCR (GPU) | 0.2045 | 0.3256 | 0.3254 | 3 | 3 | summary_metrics.csv · paddleocr/sroie_2019行 |
| EasyOCR | 従来型OCR (GPU) | 0.2833 | 0.6158 | 0.1477 | 4 | 7 | summary_metrics.csv · easyocr/sroie_2019行 |
| Tesseract | 従来型OCR (CPU) | 0.3347 | 0.5591 | 0.2335 | 5 | 5 | summary_metrics.csv · tesseract/sroie_2019行 |
| PaddleOCR-VL | ドキュメント解析VLM | 0.3370 | 0.6462 | 0.3368 | 6 | 2 | summary_metrics.csv · paddleocr_vl_vllm/sroie_2019行 |
| Docling | パイプラインパーサー | 0.5909 | 0.7596 | 0.2237 | 7 | 6 | summary_metrics.csv · docling/sroie_2019行 |
| Unlimited-OCR | ドキュメント解析VLM | 0.6552 | 0.4779 | 0.3376 | 8 | 1 | summary_metrics.csv · unlimited_ocr/sroie_2019行 |
表: summary_metrics.csv — cer / wer / field_f1_regex列、sroie_2019行。順位はこの表の8行内で算出(1 = その指標で最良:CERが最も低く、field F1が最も高い)。これらはpostprocessed_sroie_receipt_regex_*指標です:各エンジンのOCRテキストに適用された固定パターンであり、ネイティブの構造化出力ではありません。TesseractはCPUのみで実行(compute_type=cpu)。
2つの反転ペアを明確に読み取れます。Unlimited-OCR:最悪のCER(0.6552)、最高のフィールドF1(0.3376) ― 生のOCR指標で最下位にランク付けされたエンジンが、フィールド lens では1位になります。docTR:2番目に良いCER(0.1971)、最悪のフィールドF1(0.0766) ― テキストは完璧ですが、フィールド抽出は失敗します。PaddleOCR-VLも境界で反転しています(CERランク6位、フィールドランク2位)。一方、2つの一致する行(PaddleOCR 3位/3位、Tesseract 5位/5位)はどちらも従来型エンジンで、その生テキスト出力の規則はCERがスコアリングするように設計されたものと正確に一致しています。CERのみでエンジンをランク付けすると、本番環境が消費するものでランク付けした場合とは異なる勝者が得られます。この反転は異常ではなく、実証です。
フィールド指標は信頼性の高いクロスファミリー lens です
各エンジンの生テキストを同じLLMフィールド抽出後処理(deepseek-v4-flash、temperature 0)に通すと、利用可能なOCRテキストを持つ6つのエンジンは0.57〜0.62のフィールドF1に収束します ― CERランク付けで巨大に見えるVLM対従来型のファミリー境界(0.19から0.66)はほぼ消滅します。2つのエンジンがこのバンドを下回ります:EasyOCRの0.3717とTesseractの0.4389です。フィールド指標は、実際に重要なこと ― 下流のフィールド回復 ― に基づいてエンジンを区別し、ファミリー境界を越えて一貫して行います。
これは上記のCERテーブルと同じエンジンセットで、フィールド次元のみで再スコアリングされたものです。Unlimited-OCRとdocTRの間のCER反転はなくなります。なぜなら、フィールド値の回復こそがパイプラインが消費するものだからです。そのメカニズムは、後処理がCERが罰していた出力規則の違いを吸収することです。それは、大文字小文字を統一し、ラベル/値を結合したテキストを読み取り、値を抽出します。ここで使用されているLLMフィールドF1は、ベンチマークのメソッド比較におけるllm_field_value_f1列で、各行にLLMモデルが記録されています。
| モデル | タイプ | CER(コンテキスト) | LLM フィールドF1 | 収束帯内(0.57–0.62) | 出典 |
|---|---|---|---|---|---|
| docTR | 従来型OCR(GPU) | 0.1971 | 0.6171 | はい — 最高値 | field_method_comparison.csv · llm_field_value_f1、doctr/sroie_2019行 |
| Surya2 | 文書解析VLM | 0.1915 | 0.6139 | はい | field_method_comparison.csv · llm_field_value_f1、surya2/sroie_2019行 |
| Unlimited-OCR | 文書解析VLM | 0.6552 | 0.6054 | はい | field_method_comparison.csv · llm_field_value_f1、unlimited_ocr/sroie_2019行 |
| PaddleOCR-VL | 文書解析VLM | 0.3370 | 0.5921 | はい | field_method_comparison.csv · llm_field_value_f1、paddleocr_vl_vllm/sroie_2019行 |
| PaddleOCR | 従来型OCR(GPU) | 0.2045 | 0.5810 | はい | field_method_comparison.csv · llm_field_value_f1、paddleocr/sroie_2019行 |
| Docling | パイプラインパーサー | 0.5909 | 0.5685 | はい — 帯端 | field_method_comparison.csv · llm_field_value_f1、docling/sroie_2019行 |
| Tesseract | 従来型OCR(CPU) | 0.3347 | 0.4389 | いいえ — 未達 | field_method_comparison.csv · llm_field_value_f1、tesseract/sroie_2019行 |
| EasyOCR | 従来型OCR(GPU) | 0.2833 | 0.3717 | いいえ — 未達 | field_method_comparison.csv · llm_field_value_f1、easyocr/sroie_2019行 |
表:field_method_comparison.csv — llm_field_value_f1列、sroie_2019行、llm_model=deepseek-v4-flash。CER列は相互参照用にsummary_metrics.csvから再掲しています。「収束帯」とは、利用可能なテキストを持つ6つのエンジンで観測された0.5685–0.6171の範囲を指し、帯外の2行はエンジンの分類ではなく、観測結果として記載しています。
CORDは第二のインフレーション層を追加:正解の構造
CORDが公開している正解テキスト(gt_text)には、純粋な表示テキストではなく、アノテーション構造(フィールドラベル、メニュー項目、座標)が埋め込まれています。CERはその構造的に拡張された文字列に対して編集距離を計算するため、すべてのエンジンのCORD CERは、読み取り誤差が検討される前に体系的に膨らんでいます。その結果:8つのすべてのエンジンがCORD CER 0.90〜1.08の範囲に集約され、テキスト品質についてほとんど何も語らない、無意味に圧縮された範囲となっています。
極端な例は、8つのエンジン中最悪のPaddleOCR-VLのCORD CER 1.0805です。これはテキスト品質の読み取りではなく、最もクリーンで短い出力に対して構造的インフレーションが最も強く作用した結果であり、CORDの構造を含む正解に対する相対的な編集距離が最大になるためです。フィールドの観点から見ると、同じエンジンがベンチマークで最高のCORD正規表現フィールドF1(0.3412)を記録しています。CORD CERは構造的に使用不可能です。フィールド指標のみがCORDの公平な観点であり、このベンチマークではSROIEのランキングとは厳密に分離されています(異なる言語――インドネシア語――と異なる正解構造のため)。
出典:summary_metrics.csv — cerおよびfield_f1_regex列、cord_v2行(エンジンあたり100サンプル)。CORD CERはエンジンファミリー間、さらにはエンジン間でも比較できません。正解がアノテーション構造を埋め込んでいるため、CERは表示テキストではなく、構造的に拡張された文字列との距離を測定します。
| モデル | タイプ | CORD CER | Regex field F1 | 出典 |
|---|---|---|---|---|
| PaddleOCR-VL | ドキュメント解析 VLM | 1.0805 | 0.3412 | summary_metrics.csv · paddleocr_vl_vllm/cord_v2 行 |
| Surya2 | ドキュメント解析 VLM | 0.8959 | 0.2458 | summary_metrics.csv · surya2/cord_v2 行 |
| Unlimited-OCR | ドキュメント解析 VLM | 0.9224 | 0.1079 | summary_metrics.csv · unlimited_ocr/cord_v2 行 |
| Tesseract | 従来型 OCR (CPU) | 0.9523 | 0.0752 | summary_metrics.csv · tesseract/cord_v2 行 |
| Docling | パイプラインパーサー | 0.9219 | 0.0612 | summary_metrics.csv · docling/cord_v2 行 |
| PaddleOCR | 従来型 OCR (GPU) | 0.9083 | 0.0154 | summary_metrics.csv · paddleocr/cord_v2 行 |
| EasyOCR | 従来型 OCR (GPU) | 0.9185 | 0.0067 | summary_metrics.csv · easyocr/cord_v2 行 |
| docTR | 従来型 OCR (GPU) | 0.9101 | 0.0000 | summary_metrics.csv · doctr/cord_v2 行 |
表: summary_metrics.csv — cer / field_f1_regex 列、cord_v2 行。CORD は SROIE ランキングには統合されません(プロトコルルール):正解の構造がすべてのエンジンの CER を膨らませ、正規表現パターンは英語フォーマット用に作成されています。フィールド指標のみが CORD を公平に評価する手段です。フィールド F1 でソートしており、CER ではありません — 重要なのは、CER 列にはソート情報がないということです。
フィールド lens は CORD テーブルを完全にひっくり返します。 ベンチマークで最も悪い CORD CER を持つエンジン(PaddleOCR-VL、1.0805)が、最高の CORD field F1(0.3412)を持ちます。docTR の CORD field F1 は文字通り0.0000 — 何も抽出できていません — 一方、その CORD CER(0.9101)は中程度の値で、何の情報も伝えません。CORD において、フィールド数値なしで CER を公開することは、単に情報不足であるだけでなく、エンジンを誤った順序にランク付けしてしまうのです。
CERが適切な指標となるケース
CERは依然として、正確な文字再現という実際のものを測定しており、下流の消費者がフィールドではなくテキストそのものを必要とする場合には適切な指標です。このページの結論は「CERはVLMスタイルの出力のクロスファミリー比較において誤解を招く」というものであり、「CERは常に間違っている」というものではありません。
- 生のOCRファミリー内では、CERはその価値を保ちます。 従来のエンジンは大文字小文字やレイアウトを保持した生のテキストを出力するため、CERは真の読み取り品質を測定します。このベンチマークにおける従来エンジンのCER列(SROIEで0.1971〜0.3347)は、フィールド性能をVLMよりもはるかに正確に追跡しています(正規表現フィールドF1との順位相関:PaddleOCRとTesseractは3位/3位、5位/5位で完全に一致)。
- テキストそのもののユースケース。 完全一致を求める下流の消費者(リテラルな文字列を見つける必要がある全文検索、ドキュメントの文字を再現する監査証跡、または必須の文字列に対する合格/不合格チェック)は、フィールドではなく文字を消費します。これらに対しては、正確な文字再現(CER)が忠実な指標であり、フィールドF1は適切な視点ではありません。
- 公開時の経験則。 CERの数値を公開する際は、エンジンの出力規則(大文字小文字を統一するか?ラベルを結合するか?行を再順序するか?)と正解の構築方法(純粋な可視テキストか、CORDの
gt_textのようにアノテーションで補強されたものか)の両方を記述してください。いずれかが不明な場合、その数値はエンジンやデータセット間で移植可能ではありません。 - このベンチマークからの境界ルール。 CERは生のOCRファミリー内では公平ですが、従来OCR/ドキュメントパースVLMの境界を越えると不公平になります。フィールドレベルのF1(正規表現またはLLMによる後処理)は両方の境界を越えて公平です。同じファミリー内の生テキスト品質にはCERを、クロスファミリー比較にはフィールドF1を使用してください。そして、VLMの行については常に分解の注意点を報告してください。
よくある質問
OCRエンジンとVLMを比較する際に、CERが誤解を招くのはなぜですか?
CERは正確な文字の編集距離スコアであるため、ドキュメント解析VLMは意図的に文字を正確に再現しません。大文字小文字を統一し、ラベル/値の行を結合し、テキストを再配置します。これらの正規化は、フィールド値が正しい場合でもすべて誤りとしてカウントされます。このベンチマークでは、Unlimited-OCRはSROIE CERが最悪(0.6552)ですが、同じ361件のレシートで正規表現フィールドF1は最高(0.3376)です(summary_metrics.csv、cer / field_f1_regex、unlimited_ocr/sroie_2019行)。CERランキングとフィールドランキングでは、異なるエンジンが1位になります。
CERはOCRの指標としてまだ有用ですか?
はい、生のOCRエンジンの範囲内、およびテキストをそのまま使用する場合に限っては有用です。従来のエンジン(Tesseract、PaddleOCR、EasyOCR、docTR)はCERが公平に測定できる生の文字列を出力します。このベンチマークでは、それらのSROIE CERは0.1971〜0.3347の範囲で、フィールド性能と連動します(PaddleOCR 3位/3位、Tesseract 5位/5位、CERおよびフィールドF1)。CERは、エンジンが出力を正規化する場合(VLMスタイル)や、正解が表示テキストではなく構造を埋め込む場合(CORD)には適した指標ではありません。
なぜVLM OCRモデルの文字誤り率は高いのですか?
主に読み取り能力ではなく、出力規則の違いによるものです。ベンチマークのプロトコル分析によると、VLMのSROIE CERの約18%は大文字小文字の統一、約10%は行結合/区切り文字の削除に起因します(ベンチマークの分析ノートに基づく推定であり、CSV列ではありません)。一方、フィールド値自体は正しいです。Unlimited-OCRのCER 0.6552対WER 0.4779は、文字が統一され、単語は残るという特徴を示しています(summary_metrics.csv、cer / wer、unlimited_ocr/sroie_2019行)。
OCRエンジンやドキュメント解析VLMを比較する最適な指標は何ですか?
フィールドF1です。生OCRパイプラインでは正規表現で後処理し、いずれのファミリーでもLLMで後処理します。SROIEでは、LLMフィールドF1はファミリーに関係なく8つのエンジンを0.57〜0.62に収束させます(field_method_comparison.csv、llm_field_value_f1、sroie_2019行)。また、正規表現フィールドF1はCORDテーブルを合理的にランク付けできる唯一の指標であり、PaddleOCR-VLの0.3412がベンチマーク最高値です(summary_metrics.csv、field_f1_regex、cord_v2行)。数値と併せて、使用した後処理と出力規則を必ず明記してください。
なぜPaddleOCR-VLのCORDにおけるCERは非常に高いのに、フィールドF1は最高値なのでしょうか?
CORDの正解データは、純粋な可視テキストではなく、アノテーション構造(フィールドラベル、座標、メニュー項目)を含んでいるためです。PaddleOCR-VLの出力は最もクリーンで、最も短く、最も正規化されているため、その構造的に拡張された文字列との編集距離が最大になります(CER 1.0805、8エンジン中最悪)。フィールド指標で見ると、同じテキストがインドネシアのレシートフィールドを0.3412のフィールドF1で抽出し、ベンチマーク最高値を達成しています(summary_metrics.csv、cer / field_f1_regex、paddleocr_vl_vllm/cord_v2行)。CORDのCERは、どのエンジンでも構造的に利用できません。フィールド指標のみが、CORDを公平に比較できる唯一の方法です。
大文字小文字の統一とは何か、なぜCERを膨らませるのですか?
大文字小文字の統一とは、すべてのテキストを単一のケースに正規化することです。例えば、TAN CHAY YEEはtan chay yeeになります。CERは文字を正確に比較するため、正解データの大文字に対して、統一された文字はすべて置換としてカウントされます。値は同一でもです。このベンチマークのプロトコル分析によると、大文字小文字の置換はVLMのSROIE CER予算の約18%を占めます(プロトコル由来の推定値)。そのため、VLMがレシートを完璧に読み取っても、失敗したモデルのように見えるCER値が報告されることがあります。
OCRエンジンの比較は、文字誤り率(CER)とフィールドF1のどちらで行うべきですか?
従来のOCRエンジンとVLMエンジンの両方に関わる比較では、フィールドF1で行うべきです。なぜなら、パイプラインが処理するのは文字列ではなくフィールドであり、CERは正規化されたVLM出力や構造が補強された正解に対して系統的に過大評価されるためです。CERは、生のOCRエンジン同士の比較や、下流の消費者が原文テキスト(検索、監査、完全一致)を必要とする場合にのみ使用してください。このベンチマークでは、2つの指標は大きく異なります。CERではdocTRが2位、Unlimited-OCRが8位ですが、正規表現によるフィールドF1ではdocTRが8位、Unlimited-OCRが1位です(summary_metrics.csv、sroie_2019の行)。
これらのCERとフィールドF1の数値はどこから来たものですか?
すべての表の数値は、一次ベンチマークの公開されたresults/summary_metrics.csvまたはresults/field_method_comparison.csvの1行であり、ImageToTableai/benchmark-ocrで公開されています。各実行には、モデルバージョンと環境フィンガープリントを記録した、1つの編集済みmanifest.jsonが添付されています。約76%/18%/10%のCER分解は、ベンチマークの分析ノートから導出されたプロトコルベースの推定値であり、明確にCSVの列ではありません。データセットの定義は、以下に引用されているSROIEおよびCORDの論文から来ています。
方法論と出典
プロトコル
このページは、独立した再現可能なベンチマーク実行(公式ティア)の指標公平性の次元を報告しており、第三者の主張の調査ではありません。固定されたテスト分割のみを使用しています:SROIE 2019テスト(361件の英語レシート、フラットフィールド会社/日付/住所/合計、CC-BY-4.0)とCORD v2テスト(100件のインドネシア語レシート、ネストされたフィールドメニュー/小計/合計、CC-BY-4.0)。訓練分割は評価されていません。8つのエンジンが、フリーズされたプロトコルreports/receipt_v1_official_protocol.md(ウォームアップ後にスコアリング、公式ティアのみ)の下で、ファインチューニングなしでそのまま実行されました。すべての16回のスコアリング実行が、error_rate 0.0(summary_metrics.csvのerror_rate列)で完了しました。データは2026年8月に収集されました。
ランタイム環境
- ハードウェア: すべてのGPU実行は単一のNVIDIA RTX 4090(24 GB)で行われます。TesseractはCPUのみ(compute_type=cpu)で実行され、すべてのテーブルにそのように記載されています。
- エンジンとバージョン(実行マニフェストに基づく): Tesseract 5.3.4、PaddleOCR 3.7.0、EasyOCR 1.7.2、docTR v1.0.1、Docling 2.119.0、Surya2 0.22.1、Unlimited-OCR vLLM-served、PaddleOCR-VL 1.6。
- フィールド後処理: 正規表現フィールドF1 = 各エンジンのOCRテキストに適用された固定
sroie_receipt_regex/cord_receipt_regexパターン(後処理済み、ネイティブ抽出ではない);LLMフィールドF1 = 同じテキストを読み取るdeepseek-v4-flash(temperature 0)(field_method_comparison.csvのllm_model列)。
指標の定義
- 文字誤り率(CER): 認識テキストと正解テキスト間のレーベンシュタイン編集距離 — 最小の挿入/削除/置換回数を正解の長さで割ったもの(OCR-D評価仕様)。低いほど良い。正確な文字の再現のみを測定します。
- 単語誤り率(WER): 単語粒度での同じ編集距離ロジック — 単語は1回の大文字小文字の置換で生存するため、CER/WERの乖離は、単語を壊さずに文字を変更する正規化を明らかにします。
- フィールド値F1: 抽出されたフィールド値に対する精度と再現率の調和平均;フィールドは正解と完全に一致した場合のみマッチします。正規表現とLLMの列は、同じOCRテキストに対する2つの後処理であり、混合されることはありません。
- 出力規則: エンジンがテキストをどのようにフォーマットするか(大文字小文字、区切り文字、行の順序)。従来のエンジンはこれを保持しますが、文書解析VLMはこれを正規化します — このページが測定する軸です。
- 正解の構造: 参照テキストが純粋な可視テキスト(SROIE)か、アノテーション構造で補強されたもの(CORD
gt_text)か。後者はすべてのエンジンのCERを膨らませます。
出典一覧
- summary_metrics.csv (GitHub raw)。16行 = 8エンジン × 2レシートデータセット。列にはcer、wer、field_f1_regex、field_acc_regex、compute_type、error_rateが含まれます。このページのすべてのCER/WERおよび正規表現フィールドF1の数値は、ここにある行に遡及し、ファイル/モデル/データセット/指標レベルで引用されています。
- field_method_comparison.csv (GitHub raw)。正規表現 vs LLMフィールド抽出の並列比較(llm_field_value_f1、llm_model=deepseek-v4-flash)。LLMフィールドF1テーブルの出典です。
- ImageToTableai/benchmark-ocr リポジトリ。結果CSV、編集済み実行マニフェスト、固定化されたプロトコル(
reports/receipt_v1_official_protocol.md)、および再現用の固定サンプルリストを公開しているリポジトリです。 - results/manifests/ (GitHub)。公開された実行ごとに1つの編集済みmanifest.jsonがあり、モデルバージョン、環境フィンガープリント、アーティファクトハッシュが記録されています。
- receipt_v1_official_protocol.md。固定化された実行契約:固定テスト分割、公式ティア、ウォームアップ後のスコアリング測定、CORD-vs-SROIE分離ルール。このページで引用されているプロトコルレベルのルールの出典です。
- ベンチマークプロトコル分析メモ(社内実行ドキュメント、WRITING_BRIEF §8.2/§8.3)。VLM正規化メカニズム(大文字小文字の統一、ラベル/値の結合、行の再順序付け)、CORD正解構造メカニズム、およびSROIE CER分解(約76%同一 / 約18%大文字小文字 / 約10%行結合)。ここでは明示的に「プロトコル由来の推定値 — CSV列ではない」というラベル付きで引用されています。この内訳は方向性を示すものであり、正確な数値ではありません。
- OCR-D Project — Quality Assurance Specification。形式的なCER定義(挿入 + 削除 + 置換)/ 総文字数およびWERの類似指標。形式的な定義の基盤です。
- 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データセット定義、ネストされたフィールドスキーマ、ライセンス(CC-BY-4.0)。
制限事項
- 分解数値はプロトコル由来の推定値であり、測定値ではありません:SROIE CERの約76%/約18%/約10%という分解は、ベンチマークのプロトコル分析ノート(WRITING_BRIEF §8.2)から得られたものであり、CSVカラムから得られたものではありません。方向性(正規化がVLM CERの主因であり、誤読ではない)は堅牢ですが、正確なパーセンテージは方向性の推定値として扱い、ポイント測定値としては扱わないでください。
- レシートのみ:SROIE(英語)およびCORD(インドネシア語)のレシートです。請求書、フォーム、テーブル、または長文ドキュメントでの動作は未測定です。メカニズムは汎化可能ですが、数値は汎化できません。
- 単一のLLM後処理:すべてのLLMフィールドF1数値は、温度0のdeepseek-v4-flashを使用しています。異なるLLMは絶対F1値、場合によっては収束帯を変化させます。収束帯内のクロスファミリー順序が安定したシグナルです。
- CERは逐語テキストのケースでも有効:結論はVLMスタイル出力のクロスファミリー比較に限定されています。生OCRの同ファミリー比較と正確な文字を必要とするダウンストリームコンシューマー(検索、監査)にとって、CERは依然として正当な指標です。このページは、それらのコンテキストにおけるCERへの反論ではありません。
- CORDはSROIEランキングに統合されていません:異なる言語、異なる正解構造です。CORDはベンチマークプロトコルに従い、フィールド指標のみで比較されます。
- バージョンとハードウェアの固定:数値は上記に記載された2026年8月のモデルバージョンと1つのGPUティア(RTX 4090)に有効です。新しいリリースはCERとフィールドF1を変化させます。一桁パーセントの差はノイズとして扱うべきです。
- サンプルサイズ:361 + 100サンプル。ブートストラップ信頼区間はベンチマークの評価出力で報告されていますが、このページでは行ごとに再現されていません。
関連リファレンス: フィールドレベル vs 文字レベルの精度(定義) · 従来のOCR vs ドキュメントパースVLM · 正規表現 vs LLMフィールド抽出 · レシートにおけるPaddleOCR vs EasyOCR · Surya2 vs Unlimited-OCR vs PaddleOCR-VL · OCRレイテンシーベンチマーク · 1,000ページあたりのOCRコスト