文書理解とOCRのいま — 帳票をLLMが読むまで

請求書やスキャンPDFを機械が読むまでを1から。テキスト検出とCTC、誤りの測り方（CER）から、レイアウトを座標ごと埋め込むLayoutLM系、OCRを丸ごと捨てるDonut系、そして画像をそのままLLMに渡す現在までを、表・手書き・幻覚という実務の壁とあわせて解説する。

LayoutLM: Pre-training of Text and Layout for Document Image Understanding

「読む」という仕事は、3つに分かれている

段ボール一箱ぶんの請求書を渡して「金額を集計しておいて」と頼んだとします。頼まれた人がやることは3つです。紙のどこに文字があるかを見つけ、その並びが何という文字列かを言い当て、それが「請求金額」なのか「振込手数料」なのかを判断する。

文書AIでは、この3つに別々の名前が付いています。テキスト検出、文字認識、この2つを合わせて OCR（Optical Character Recognition、光学文字認識）。3つ目が文書理解です。

OCRは1960年代から続く技術で、印刷された文字を読むだけならとうに実用域です。それでも「帳票の入力が自動化できない」という声が消えないのは、詰まる場所がほぼ常に3つ目だからです。文字は読めている。読めた文字が何を指すのかが分からない。

なぜ帳票は、ふつうの文章より難しいのか

小説なら、左上から右下へ順に読めば意味が復元できます。意味のほとんどが語の並び順に入っているからです。

帳票は違います。請求書の右下にある「¥132,000」が合計金額だと分かるのは、それが右下にあるからです。同じ数字が明細行の途中にあれば小計です。帳票では、レイアウトそのものが意味を運んでいる。

だから文字を1本の列に並べ替えた瞬間、意味は壊れます。二段組のPDFからテキストを抜いたら左段と右段が交互に混ざった、という経験は多いはずです。文書理解の難しさは、認識精度よりこの「二次元を一次元に潰す」側にあります。

古典的なOCRは、検出・認識・後処理の3段だった

2010年代までの標準構成は、はっきり3段でした。まずテキスト検出が、文字の並ぶ領域を長方形（バウンディングボックス）で切り出します。対象が「文字行」になっただけの物体検出です。

次に行認識。1行の画像を畳み込みネットで横方向の特徴の列に変え、そこから文字列を出します。困るのは、どのピクセル幅がどの文字にあたるかが事前に分からないことです。

これを解いたのが CTC（Connectionist Temporal Classification）でした。「空白」という記号を導入し、ありうる位置合わせを全部足し合わせてしまう方法です。

$\mathbf{x}$ は行画像の特徴の列、$\mathbf{y}$ は正解の文字列、$T$ は横方向の分割数、$\pi$ は各位置に文字（または空白）を1つずつ割り当てた並べ方、$\mathcal{B}$ は連続する重複を潰して空白を取り除く操作です。式(1)は「$\mathbf{y}$ に潰れる並べ方を全部数え上げ、その確率を合計する」と言っているだけ。

つまり、「この行画像が HELLO と読める確からしさ」を、H が左から何ピクセル目までを占めていたか・L が2コマぶんか3コマぶんか、といったあらゆる引き伸ばし方の可能性をまとめて足した量として定義している、ということです。文字の切れ目を人が教えなくてよくなった、これがCTCの功績でした。

最後に後処理。辞書や正規表現で日付らしさ・金額らしさを当てはめ、O と 0、1 と l の取り違えを直します。

読めたかどうかを、どう測るか

OCRの成績は正解率ではなく編集距離で測ります。出力を正解に一致させるのに、何文字の置換・削除・挿入が要るかを数える方法です。

$S$ は置換した文字数、$D$ は削除、$I$ は挿入、$N$ は正解の文字数。式(2)は「正解1文字あたり何回の直しが必要か」を表し、これを CER（Character Error Rate、文字誤り率）と呼びます。

言い換えれば、出力を正解の姿に直すのに、原稿の何割ぶん打ち直す必要があったかの比率です。CERが0.05なら、正解100文字につき5文字ぶんの手直しが要ったということ。単位を文字ではなく単語にすれば WER（単語誤り率）になります。

ただしCERだけを見ていると足元をすくわれます。値が十分低くても、間違えた1文字が金額の桁なら業務は止まる。現場で要るのは文字の精度ではなくフィールドの精度です。