Skip to content
Published on

OCR を超えて — OCR-free な文書理解と統合モデル

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに: なぜ OCR を超えようとするのか

レシートの合計を取り出し、契約書の項目を抽出し、チャートを表に変える。こうした文書理解タスクは長く OCR(光学文字認識)を土台にしてきました。しかし OCR は文字を読むところまでしか得意でなく、その文字が何を意味し、どのマスに属するかまでは教えてくれません。

そのため従来の文書処理は複数の段階を鎖のようにつなぎます。文字がどこにあるかを検出し、その文字が何かを認識し、ページのレイアウトを解析し、最後に意味を解釈します。段階が多いほど一箇所の誤差が次の段階へ広がる累積誤差の問題が生じます。

最近はこの鎖を丸ごとモデル 1 つが代替する OCR-free アプローチが台頭しました。画像を入力として受け取り、すぐに欲しい答え(テキスト, キーバリュー, 表)を出すのです。本記事では従来パイプラインの限界、OCR-free なエンドツーエンドモデル、そして検出・認識・パースを 1 つにまとめる統合モデルへの流れを整理します。

OCR と文書理解は違う

まず用語を明確にしましょう。OCR は画像から文字をテキストへ写す作業です。文書理解はそのテキストがどんな構造と意味を持つかを把握する作業です。二つは異なる段階であり、従来システムはこれを分離して処理しました。

OCR:        画像 -> "合計 32,500"  (文字をテキストへ)
文書理解:    "合計 32,500" + 位置/文脈 -> {フィールド: 合計, 値: 32500}  (意味付与)

OCR-free アプローチの核心的な主張は、この二つをわざわざ分離する必要がないということです。一つのモデルが画像を見ながら文字と意味を同時に把握すれば、中間テキストを経て失う情報(位置, フォント, レイアウト文脈)を活かせます。人がレシートを見るとき文字を一つひとつ読んで別に意味を付けないのと似ています。

核心原理: 従来 OCR パイプラインとその限界

従来の文書理解パイプラインは通常次の段階で構成されます。

[文書画像]
   |
   v
[1. テキスト検出] --> 文字/単語領域のボックスを探す
   |
   v
[2. テキスト認識] --> 各ボックス内の文字を文字列へ
   |
   v
[3. レイアウト解析] --> タイトル/本文/表/セル構造を把握
   |
   v
[4. 情報抽出] --> キーバリュー, 表, 意味解釈

各段階は通常別々のモデルであり、別々に学習され別々にチューニングされます。この構造には明確な限界があります。

  • 累積誤差: 段階 1 の検出が文字の一部を見落とすと、段階 2 の認識はいくら良くてもその文字を復元できません。誤差が段階ごとに積み上がります。
  • 段階間の情報断絶: 認識段階は文字の形だけを見て、意味文脈を活用できません。かすれた文字を文脈で補正するのが難しいです。
  • レイアウトの脆弱性: 表の結合セル、複雑なフォーム、手書きが混じる文書でレイアウト解析がよく壊れます。
  • パイプライン維持コスト: 段階ごとにモデルと規則を管理する必要があり運用が複雑です。

これらの限界が OCR-free アプローチの動機になります。段階を減らせば累積誤差が減り、1 つのモデルが文字と意味を一緒に見れば文脈補正が可能になります。

深掘り 1: OCR-free なエンドツーエンド文書理解

Donut 系: OCR なしで画像から直接構造化出力

Donut(Document Understanding Transformer)は OCR 段階を完全になくし、文書画像を入力として受け取りすぐに構造化された出力(例: JSON)を生成するアプローチを提示しました。ビジョンエンコーダが画像を読み、テキストデコーダが欲しい結果を自己回帰的に生成します。

[文書画像]
   |
   v
[ビジョンエンコーダ] --> 画像特徴の系列
   |
   v
[テキストデコーダ] --> 構造化出力 (例: JSON キーバリュー)

この方式の強みは明確です。別途の OCR ボックス検出や認識モデルが不要で、モデルが文字の形と意味を一度に学習します。抽出したい情報の形式で正解を作って学習すれば、モデルがその形式で直接答えを出します。累積誤差が消えパイプラインが単純になります。

ただしトレードオフもあります。明示的な OCR がないため正解形式と十分なデータに大きく依存します。またデコーダが長い出力を生成する場合は速度が問題になりえます。

VLM ベースの文書理解

先の記事で扱ったビジョン言語モデル(VLM)は本質的に OCR-free な文書理解能力を備えます。画像をビジュアルトークンに変え LLM がそれをテキストと一緒に読むため、文書画像を受け取り質問に答えたり表を抽出したりできます。

[文書画像] --> [VLM] --> 「合計はいくら?」のような質問に自然言語で答える
                    --> 表をマークダウン/JSON へ構造化
                    --> 特定フィールドの位置(座標)まで指し示す

VLM の利点は汎用性です。同じモデル 1 つでキャプション, VQA, OCR, grounding をすべて扱い、自然言語の指示で欲しい出力を柔軟に受け取れます。強力な言語能力のおかげで、かすれたり一部隠れた文字も文脈で推論する傾向があります。

深掘り 2: 高解像度, レイアウト, 表, 数式

文書は自然画像と異なります。小さな文字がびっしりで、表や数式といった構造が多いです。これを適切に扱うにはいくつかの仕掛けが必要です。

高解像度処理

文書の小さな文字を読むには十分な解像度が必要です。画像を小さく強制リサイズすると文字がつぶれます。そこで OCR-free モデルは高解像度入力を扱う戦略を使います。

  • タイル/スライシング: 大きなページを複数のタイルに切り、それぞれ処理して統合します。
  • 任意解像度: 先の記事で見た動的解像度のように、元の比率とサイズを保存してディテールを活かします。
高解像度文書の処理戦略
方法 A: タイリング      大きなページ -> 複数タイル -> 個別処理 -> 統合
方法 B: 動的解像度      元の比率を維持 -> サイズに比例するトークン数

解像度を上げるほどディテールは良くなりますがトークン数とコストが増えます。この均衡が文書モデル設計の核心です。

レイアウト, 表, 数式

  • レイアウト: タイトル, 段落, 見出し, 表など領域構造を理解してこそ情報を正しい文脈で抽出できます。OCR-free モデルはこれを別段階の代わりに学習で内在化します。
  • 表: 行と列, 結合セルの構造を保存して読む必要があります。出力をマークダウン表や構造化形式で生成するよう学習します。
  • 数式: 数式は 2 次元構造(分数, 指数, 添字)を持ち一般テキストで表現しにくいです。標準表記へ変換して出力するよう学習するアプローチが一般的です。

こうした構造要素は正解データの形式がそのままモデル出力形式を決めるため、一貫した構造化正解を準備することが重要です。

深掘り 3: 多言語 OCR と統合モデル

多言語 OCR

文書は複数の言語で書かれます。従来 OCR は言語ごとに別の認識モデルや辞書を置くことが多かったですが、OCR-free な VLM は様々な言語の画像テキストデータを一緒に学習し 1 つのモデルで複数言語を扱えます。ラテン文字だけでなく日中韓のような表語文字、右書き文字まで幅広く扱おうとする努力が続いています。ただし学習データが少ない言語や希少フォントでは依然として精度が落ちることがあるため、対象言語分布に合わせたデータ補強が重要です。

統合モデル: 検出・認識・パースを 1 つに

最近の流れは検出, 認識, レイアウト解析, 情報抽出を 1 つのモデルに一元化する統合モデルです。従来パイプラインが段階ごとにモデルを置いていたのを、単一のエンコーダ-デコーダが一度に処理します。

従来パイプライン:  検出モデル -> 認識モデル -> レイアウトモデル -> 抽出モデル
統合モデル:        単一モデル -> (検出 + 認識 + レイアウト + パース) を同時に
  • 利点: 累積誤差の低減, 運用の単純化, 文脈を活用した補正。段階間の情報断絶が消えます。
  • 柔軟性: 同じモデルに異なる指示を与え、全文読み取り, 特定フィールド抽出, 表構造化など多様なタスクを行います。
  • 考慮点: 全過程を学習で内在化するためデータ品質と多様性に大きく依存し、出力の正確性を保証するには検証段階が必要です。

深掘り 3.5: 読み順とレイアウトの難しさ

文書を理解するときよく見落とされる難しさが読み順です。人は多段組みの新聞を見ると左の段を上から下へ読み、その次に右の段へ移ることを自然に分かります。しかしモデルにとってこれは自明ではありません。

多段レイアウトの例
  +------------------+------------------+
  | 段1 最初の段落    | 段2 最初の段落    |
  | 段1 二番目の段落  | 段2 二番目の段落  |
  +------------------+------------------+

  正しい読み順: 段1 全体 -> 段2 全体
  誤った順序:   行単位で左右交互に読む (意味が壊れる)

従来パイプラインはレイアウト解析段階でこの順序を明示的に計算しました。OCR-free モデルはこれを学習で身につける必要があるため、様々なレイアウトのデータで十分に学習されないと読み順が乱れることがあります。表, 脚注, サイドバー, キャプションが混じると難易度がさらに上がります。

この問題は出力形式の設計で一部緩和されます。たとえば領域別に構造化して出力するよう学習すると、モデルが領域境界を意識して順序をよりよく取ります。核心はモデルが読み順を一貫して出すか検証データで確認することです。

深掘り 3.6: 表を構造化する具体的な方法

表は文書理解で最も難しい要素の一つです。行と列の関係, 結合セル, ヘッダ階層をすべて保存する必要があるためです。OCR-free モデルは表をどんな形式で出力するよう学習するのでしょうか。

表出力形式の選択肢
  マークダウン表    簡単, 単純な表に適する, 結合セル表現に限界
  HTML 表          結合セル(rowspan/colspan)を表現可能, 冗長
  構造化 JSON      セル別の座標/内容を明示, パースが容易, 最も柔軟

各形式にはトレードオフがあります。マークダウンは人が読みやすいですが複雑な結合セルを表現しにくいです。HTML 表は結合を表現できますが出力が長くなります。構造化 JSON は最も柔軟ですが正解データをその形式で一貫して準備する必要があります。

核心はタスクに合った形式を選び、正解データをその形式で統一することです。モデルは正解形式を模倣するため、表出力形式がばらつくとモデルも一貫しない表を出します。また表精度を評価するときは単純な文字列一致ではなく、セル単位・構造単位で比較してこそ実際の品質を捉えられます。

深掘り 4: ベンチマークと評価方法

OCR-free モデルをどう評価するのでしょうか。タスクごとに測定指標が異なります。

  • テキスト認識精度: 認識された文字列と正解の一致度。編集距離ベースの指標が一般的です。
  • キーバリュー抽出精度: レシート・フォームでフィールド単位で当てたか。フィールド別の精度と再現率を見ます。
  • 表構造精度: セル単位の一致だけでなく行・列・結合構造まで正しいか評価します。
  • 文書 VQA 精度: 文書に対する質問の答えが正しいか。正解との意味的一致を見ます。
評価観点のまとめ
  何を読んだか      テキスト認識精度 (編集距離)
  何を抽出したか    キーバリュー精度/再現率
  構造を保存したか  表セル/構造の一致度
  意味を理解したか  文書 VQA 精度

重要な点は単一スコアがモデルの全能力を代表しないことです。あるモデルは一般テキストはよく読みますが表構造で弱く、あるモデルは英語は強いですが多言語で落ちます。だから自分の実際の文書分布に合わせた自前の評価セットを構築することが何より安全です。公開ベンチマークスコアは出発点にすぎず、実際の運用データのノイズと多様性をそのまま反映しません。

深掘り 5: 推論パイプラインの設計

OCR-free モデルを実際のサービスに載せるときの推論パイプラインは単にモデル呼び出し一つで終わりません。前処理, モデル推論, 後処理・検証の三段階で見るのがよいです。

[原本文書]
   |
   v
[前処理]   解像度正規化, 回転補正, ノイズ除去
   |
   v
[モデル推論]  OCR-free モデル -> 構造化出力を生成
   |
   v
[後処理]   形式検証(JSON スキーマ), 信頼度判定, フォールバック
   |
   v
[結果]    検証通過 -> 自動処理 / 失敗 -> 人のレビュー

各段階の役割は明確です。

  • 前処理: スキャン文書は傾いたり影が差すことが多いです。回転補正と正規化でモデルが見やすい入力を作ります。
  • モデル推論: タスクに合った指示(全文読み, フィールド抽出, 表構造化)でモデルを呼び出します。
  • 後処理: 出力が期待したスキーマに従うか検証し、数値・日付のようなフィールドは形式規則でもう一度確認します。信頼度が低ければ人のレビューへ回します。

この構造で核心はモデルを信頼の終点ではなくパイプラインの一段階として見ることです。モデルが誤りうるという前提の上で検証とフォールバックを設計してこそ実際の業務で安定して動作します。

深掘り 6: 手書き, 低画質, 回転といった難問

実際の文書はきれいな印刷物だけではありません。難しい入力でどんな問題が起きるか整理します。

  • 手書き: 筆跡が人ごとに異なり認識が難しいです。手書きデータで補強するか、信頼度の低いフィールドを人のレビューへ回すのが現実的です。
  • 低画質・圧縮ノイズ: かすれや圧縮アーティファクトが激しいと小さな文字が崩れます。可能なら原本の高画質を確保し、前処理でノイズを減らします。
  • 回転・傾き: スキャン角度がずれると認識が落ちます。回転補正の前処理が役立ちます。
  • 混合レイアウト: 多段組み, サイドバー, 脚注が混じる複雑なページは読み順が紛らわしいです。モデルが読み順を一貫して出すよう学習・検証することが重要です。

これらの難問はモデル単独で完璧に解くのは難しいです。入力品質を引き上げる前処理と、不確実な出力をふるい落とす後処理が一緒に進んでこそ実務で耐えうる精度になります。

比較テーブル: 従来 OCR vs OCR-free

項目従来 OCR パイプラインOCR-free / 統合モデル
構造検出-認識-レイアウト-抽出の多段階単一モデルのエンドツーエンド
累積誤差段階ごとに積み上がる大きく低減
文脈補正困難(認識は形だけ)可能(言語能力を活用)
表/数式別途の規則/モデルが必要学習で構造化出力
多言語言語別モデル/辞書の傾向1 モデルで多言語
運用の複雑さ高い(複数モデル管理)低い(単一モデル)
データ依存段階別の中間ラベル最終正解形式に依存
出力正確性の保証段階別検証が容易検証段階の追加を推奨

深掘り 9.5: プロンプト設計で出力を扱う

VLM ベースの OCR-free モデルは同じ画像でもプロンプト(指示)によって異なる出力を出します。これは強力な柔軟性であると同時に変動性の原因です。

同じレシート, 異なる指示
  "このレシートを読んで"            -> 自由な自然言語の要約
  "合計だけ数値で答えて"            -> 32500
  "項目を JSON 配列で抽出して"       -> 構造化されたリスト
  "店名, 日付, 合計をキーバリューで"  -> 明確なフィールドマッピング

実務で安定した結果を得るにはプロンプトを具体的かつ一貫して設計することが重要です。

  • 出力形式の明示: 望む形式(JSON スキーマ, フィールド一覧)を指示に明確に書きます。
  • 例の提供: 期待する出力の例を一つ二つ見せると形式遵守が良くなります。
  • 不確実性の処理指示: 値が見つからなければ推測せず空の値を出すよう明示しハルシネーションを減らします。
  • 一貫性の固定: 同じタスクには同じプロンプトを使い出力変動を減らします。

プロンプトはモデルを再学習せずに出力を調整する最も安いつまみです。しかしプロンプトだけで解決しない正確性の問題は結局データとファインチューニング, 後処理で扱う必要があります。プロンプトは出発点であり万能の解法ではありません。

実務適用: レシート, フォーム, 文書

OCR-free アプローチを実際の業務に適用する際の考慮点をタスク別に整理します。

  • レシート/インボイス: 店名, 日付, 項目, 合計のようなキーバリューを抽出します。出力を固定の JSON スキーマで定義すると後処理が楽になります。金額のような数値は形式誤りが致命的なため検証ロジックを置いてください。
  • フォーム/申請書: チェックボックス, 署名, 手書きが混じります。手書き認識は依然として難しいため、信頼度の低いフィールドは人の確認段階へ送るヒューマンインザループ設計が安全です。
  • 表が多い文書: 財務諸表, 仕様表などは表構造の保存が核心です。結合セルとヘッダを正確に捉えるか検証データで点検してください。
  • 多様な様式: 同じ種類でも業者ごとに様式が異なります。OCR-free モデルは様式変形に比較的強いですが、ドメインデータでファインチューニングすると精度が大きく上がります。

共通して、モデル出力をそのまま信頼するより形式検証, 信頼度しきい値, 人のレビューといった安全装置を一緒に置くことが実務で重要です。モデルが断定的に誤った値を出しうるため、重要なフィールドほど検証を強化すべきです。

深掘り 7: OCR-free と従来 OCR のハイブリッド

OCR-free が万能ではないため、実務では従来 OCR と OCR-free を混ぜて使うハイブリッド設計がよく登場します。各方式の強みを活かすのです。

ハイブリッド設計(例)
  1. 従来 OCR でテキストと位置を素早く抽出
   |
   v
  2. OCR-free/VLM がそのテキストと画像を一緒に見て意味を解釈
   |
   v
  3. 二つの経路の結果を相互検証して信頼度を算定
  • OCR 結果をヒントとして注入: 従来 OCR が抽出したテキストを VLM の入力に一緒に入れ、モデルが文字をより良く読むのを助けます。
  • 相互検証: 二つの経路が同じ値を出せば信頼度が高く、異なれば人のレビューへ回します。正確性が重要な金融・法律文書で有用です。
  • 速度と正確性の折衷: 速い OCR で一次処理し、難しいケースだけ重い VLM へ送ればコストと正確性の均衡を取れます。

ハイブリッドの教訓は明確です。新技術が旧技術を完全に置き換えるより、二つを組み合わせて弱点を補うほうが実務でより堅牢なことが多いのです。

深掘り 8: 構造化出力を安定して受け取る

OCR-free モデルに構造化出力(JSON, 表)を受け取るとき、モデルが常に完璧な形式を出すわけではありません。安定したパースのための仕掛けが必要です。

構造化出力の安定化フロー
  [モデル出力文字列]
   |
   v
  [形式パース試行]  JSON パースなど
   |
   +-- 成功 --> [スキーマ検証]  フィールド存在/型の確認
   |               |
   |               +-- 通過 --> 結果を採用
   |               +-- 失敗 --> フォールバック/再試行
   |
   +-- 失敗 --> [復旧試行]  部分抽出または再生成
  • スキーマの固定: 期待するフィールドと型をあらかじめ定義し、出力がそれに合うか検証します。
  • 再試行戦略: 形式が壊れたら別のプロンプトや設定でもう一度試します。
  • 部分受容: 一部のフィールドだけ信頼できるなら、そのフィールドだけ採用し残りは人へ回します。

こうした後処理の仕掛けがあってこそモデル出力を実際のシステムへ安全に接続できます。モデルが時々形式を外すのは正常だという前提で設計すべきです。

深掘り 9: コストと遅延の観点

OCR-free モデル、特に VLM ベースは従来 OCR より重いです。コストと遅延を管理する観点が必要です。

コスト/遅延の比較(直観)
  従来 OCR        軽い, 速い, 安い
  小型 OCR-free   中間
  大型 VLM        重い, 遅い, 高い, 代わりに柔軟/正確
  • 段階的ルーティング: 易しい文書は軽い経路へ、難しい文書だけ重い VLM へ送り平均コストを下げます。
  • 解像度調整: 小さな文字がなければ解像度を下げてトークンとコストを減らします。
  • バッチ処理: 大量文書はリアルタイムでなくバッチで処理して処理量を引き上げます。
  • キャッシュ: 同じ様式の文書が繰り返されるならプロンプトや中間結果をキャッシュして再利用します。

正確性だけを追うとコストが手に負えなくなり、コストだけを追うと品質が落ちます。タスクの正確性要求と予算の間で均衡を取ることが実務設計の核心です。

深掘り 12: 多言語文書の追加の挑戦

多言語文書は単に複数の言語を認識する以上の挑戦を抱えています。

  • 混合言語: 一つの文書に複数言語が混じる場合(例: 英語本文 + 現地語注釈)がよくあります。モデルが言語境界をうまく扱う必要があります。
  • 文字の方向: 右書き文字や縦書きが混じると読み順がさらに複雑になります。
  • 数値/日付形式: 地域ごとに日付・通貨表記が異なるため抽出後の正規化が必要です。
  • フォントの多様性: 言語ごとにフォント変形が大きく、学習データが少ない言語は精度が落ちます。
多言語処理の段階
  認識        様々な文字体系をテキストへ
   |
   v
  構造理解    言語に関係なくレイアウト/表を把握
   |
   v
  正規化      地域別の数値/日付/通貨形式を統一

核心は認識精度だけでなく認識後の正規化まで考慮してこそ実務で使える結果になることです。対象言語と地域を明確にし、その分布に合わせたデータと後処理規則を準備することが多言語文書処理の出発点です。

落とし穴と限界

  • ハルシネーション: モデルが文書にない値をもっともらしく生成しえます。特にかすれたり空のフィールドで危険です。根拠のない出力を除外する検証が必要です。
  • 希少フォント/言語: 学習データが少ないフォント, 言語, ドメインで精度が落ちます。対象分布に合わせたデータ補強が重要です。
  • 高解像度コスト: 小さな文字を読もうと解像度を上げるとトークンとコストが急増します。必要な分だけ上げる均衡が必要です。
  • 出力形式の逸脱: 構造化出力でスキーマを外れた結果が出ることがあります。パース段階で形式検証とフォールバックを準備してください。
  • ベンチマークと実際の差: ベンチマークスコアが高くても実際の業務文書の多様性とノイズでは異なる挙動になりえます。自前のデータで評価するのが安全です。

深掘り 10: ドメイン別適用時の考慮事項

OCR-free モデルを特定の産業に適用するとき、ドメインごとに異なる制約と要求があります。

  • 金融: 数値の正確性が絶対的です。一桁の誤りが大きな問題につながるため、相互検証と人のレビューを強く置きます。規制遵守のための監査証跡も必要です。
  • 医療: 処方箋・検査票の用語が専門的で、誤りのコストが大きいです。ドメインデータのファインチューニングと保守的な信頼度しきい値が重要です。
  • 法律: 長い文書, 複雑なレイアウト, 精密な引用が核心です。読み順と構造の保存が特に難しいです。
  • 物流/製造: 送り状・ラベル・バーコードが混じり、様式が業者ごとに異なります。様式変形に強いモデルと後処理規則が有用です。
ドメイン別の優先順位
  金融     正確性 > 速度, 強い検証
  医療     正確性 > コスト, ドメインファインチューニング
  法律     構造/順序の保存, 長文書処理
  物流     様式の多様性対応, 処理量

共通の教訓はドメインの誤りコストに比例して検証強度を調整することです。誤りが致命的なドメインほどモデル出力をそのまま信頼せず安全装置を厚く積むべきです。

深掘り 11: これからの方向

文書理解モデルは急速に発展しています。いくつかの流れを挙げます。

  • より長い文書: 複数ページを一度に扱う能力が重要になっています。ページ間の文脈を維持することが課題です。
  • 効率化: トークンプルーニング, 適応的解像度などで高解像度処理コストを下げる研究が活発です。
  • エージェント結合: 文書を読みその結果で後続行動(検索, 計算, API 呼び出し)を行うエージェントと結合する流れがあります。
  • 検証の内在化: モデルが自身の出力信頼度を一緒に出し、不確実な部分を自ら示す方向が研究されています。

これらの方向はすべて一つを目指します。人の介入を減らしつつ正確性を維持することです。ただし現状では完全自動化より、モデルと検証・人のレビューを結合した設計が実務で最も堅牢です。

おわりに

文書 AI は文字を読む段階の鎖から、画像を受け取り意味を直接出す単一モデルへ重心を移してきました。OCR-free アプローチは累積誤差を減らし、言語能力で文脈を補正し、検出・認識・パースを 1 つに統合して運用を単純化します。

もちろん万能ではありません。ハルシネーション, 希少ドメイン, 高解像度コストといった限界が残り、出力の正確性を保証するには検証装置が必要です。それでも 1 つのモデルが文字と意味を一緒に見るという方向性は文書理解の強力な流れであり、VLM の発展とともにその適用範囲は広がり続けています。核心はツールの強みと限界の両方を理解し、タスクの正確性要求に合わせて適切な安全装置とともに使うことです。

参考資料

Discuss on Twitter • View on GitHub