文書解析VLMでCERが誤解を招く理由：定量分析（2026年）

最終確認: 2026-08-18 · 実行ティア: 公式 · 自社ベンチマーク · 8エンジン × 2レシートデータセット

範囲の説明: メカニズムはレシート（SROIE 2019英語、361テストサンプル、CORD v2インドネシア語、100テストサンプル）で自社ベンチマークデータを用いて説明。約76%／約18%／約10%のCER分解はプロトコルノート由来の推定値であり、CSV列ではありません。CORDはSROIEのランキングに統合されません — 言語も正解構造も異なるためです。

文字誤り率（CER）は完全一致の文字照合アルゴリズムであり、品質メーターではありません: 正解と異なる文字ごとに1エラーとして計上します。このベンチマークでは、このスコアリング規則だけで — 実際の誤読の前から — エンジンのランキングが最上位と最下位の間を移動します: Unlimited-OCRは同じ361件のSROIEレシートで最悪のCER（0.6552）と最高の正規表現フィールドF1（0.3376）を記録し、docTRは2番目に良いCER（0.1971）と最悪のフィールドF1（0.0766）を記録しました。

ライターが最も必要とする3つの数値: 約18%はVLMのSROIE CER予算のうち大文字小文字の置換だけで占める割合（プロトコル由来の推定値）— TAN CHAY YEEをtan chay yeeに揃えることは、フィールド値が正しくてもエラーとして計上されます。1.0805はPaddleOCR-VLのCORD CER — 8エンジン中で最悪、CORDの構造を含む正解によるアーティファクトであり、一方でCORDフィールドF1の0.3412はベンチマーク最高です。そして0.6552 / 0.3376のCER最悪／フィールド最高の逆転は、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	正規表現フィールドF1	CER順位	フィールド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最小、フィールドF1最大）。これらはpostprocessed_sroie_receipt_regex_*指標です：各エンジンのOCRテキストに固定パターンを適用したもので、ネイティブな構造化出力ではありません。TesseractはCPUのみで実行（compute_type=cpu）。

2つの反転ペアを明示的に読み取ってください。Unlimited-OCR: 最悪のCER（0.6552）、最高のフィールドF1（0.3376） — 生のOCRメトリクスで最下位にランクされたエンジンが、フィールドレンズでは最上位にランクされます。docTR: 2番目に良いCER（0.1971）、最悪のフィールドF1（0.0766） — テキストは完璧、フィールドは失敗。PaddleOCR-VLもわずかに反転しています（CERランク6、フィールドランク2）。一方、整合した2行（PaddleOCR 3位/3位、Tesseract 5位/5位）はどちらも従来型エンジンであり、その生テキスト出力形式はCERが評価するように設計されたものと正確に一致します。CERだけでエンジンをランク付けすると、本番環境が消費するものによるランク付けとは異なる勝者が得られます — この反転は異常ではなく、デモンストレーションなのです。

フィールドメトリクスは信頼できるクロスファミリーレンズ

各エンジンの生テキストを同じLLMフィールド抽出後処理（deepseek-v4-flash、温度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に集中し、テキスト品質についてほとんど何も語らない、役に立たないほど圧縮された範囲になります。

極端なアーティファクトはPaddleOCR-VLのCORD CER 1.0805で、8エンジン中最も悪い値です。これはテキスト品質の読み取りではなく、構造的インフレーションが、CORDの構造を多用した正解に対して最も大きな相対編集距離を持つ、最もクリーンで短い出力に対して最も強く作用した結果です。フィールドレンズでは、同じエンジンがベンチマークの最高のCORD正規表現フィールドF1（0.3412）を記録しています。CORD CERは構造的に使用不能であり、フィールドメトリクスのみが唯一の公平なCORDレンズです。また、このベンチマークでは、SROIEランキング（異なる言語—インドネシア語—と異なる正解構造）から厳密に分離されています。

出典：summary_metrics.csv — cer列とfield_f1_regex列、cord_v2行（エンジンあたり100サンプル）。CORD CERはファミリー間やエンジン間でも比較できません。正解に注釈構造が埋め込まれているため、CERは表示テキストではなく構造的に拡張された文字列までの距離を測定するからです。

モデル	タイプ	CORD CER	正規表現フィールド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を公平に見る手段です。CERではなくフィールドF1でソートされています — 重要なのは、CER列にはソートの意味がないということです。

フィールドの視点でCORDの表は完全に逆転します。ベンチマークで最悪のCORD CER（PaddleOCR-VL、1.0805）を持つエンジンが、最高のCORDフィールドF1（0.3412）を記録しています。docTRのCORDフィールド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は同じ361枚のレシートで最悪のSROIE CER（0.6552）を記録しながら、最良の正規表現フィールドF1（0.3376）を達成しています（summary_metrics.csv、cer / field_f1_regex、unlimited_ocr/sroie_2019行）。CERランキングとフィールドランキングでは異なる勝者が選ばれます。

CERは依然として有用なOCR指標なのでしょうか？

はい。生のOCRファミリー内および逐語テキストを消費するユーザーにとっては有用です。従来のエンジン（Tesseract、PaddleOCR、EasyOCR、docTR）は、CERが公平に測定できる生の文字ストリームを出力します。このベンチマークでは、それらのSROIE CERは0.1971〜0.3347の範囲で、フィールドパフォーマンスと連動しています（PaddleOCRはCERとフィールドF1で3位/3位、Tesseractは5位/5位）。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はファミリーに関係なく6つのエンジンを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行）。数値とともに、後処理と出力規約を常に明記してください。

CORDでPaddleOCR-VLの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を使用してください。パイプラインが消費するのは文字ストリームではなくフィールドであり、正規化されたVLM出力と構造が拡張された正解ではCERが系統的に過大評価されるためです。CERは、生のOCRファミリー内、または下流の消費者が逐語的なテキスト（検索、監査、完全一致）を必要とする場合にのみ使用してください。このベンチマークでは、2つの指標は大きく異なります。CERではdocTRが2位、Unlimited-OCRが8位ですが、正規表現フィールドF1ではdocTRが8位、Unlimited-OCRが1位です（summary_metrics.csv、sroie_2019行）。

これらのCERとフィールドF1の数値はどこから来ていますか？

すべての表の数値は、ImageToTableai/benchmark-ocrで公開されているファーストパーティベンチマークの公開済みresults/summary_metrics.csvまたはresults/field_method_comparison.csvの行であり、実行ごとにモデルバージョンと環境フィンガープリントを記録した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経由で提供）、PaddleOCR-VL 1.6。
フィールド後処理: 正規表現フィールドF1 = 各エンジンのOCRテキストに適用される固定のsroie_receipt_regex/cord_receipt_regexパターン（ネイティブ抽出ではなく後処理）。LLMフィールドF1 = 同じテキストを読み取るdeepseek-v4-flash（温度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)。正規表現と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)。公開された各実行につき、モデルバージョン、環境フィンガープリント、アーティファクトハッシュを含む編集済みmanifest.jsonが1つ。
receipt_v1_official_protocol.md。凍結された実行契約：固定テスト分割、公式ティア、ウォームアップ後のスコアリング計測、CORDとSROIEの分離ルール。このページで引用されているプロトコルレベルのルールのソース。
ベンチマークプロトコル分析ノート（内部実行ドキュメント、WRITING_BRIEF §8.2/§8.3）。 VLM正規化メカニズム（大文字小文字の統一、ラベル/値の結合、行の並べ替え）、CORD正解構造メカニズム、およびSROIE CER分解（約76%同一 / 約18%大文字小文字 / 約10%行結合）。ここでは「プロトコル由来の推定値 — CSV列ではない」という明示的なラベルを付けて引用されています。分割は方向性を示すものであり、正確なものではありません。
OCR-Dプロジェクト — 品質保証仕様。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サンプル。ブートストラップ信頼区間はベンチマークの評価出力で報告されていますが、このページでは行ごとに再現されていません。