CC-OCRが9つの主要AIモデルを7,058の実際の文書でテスト、大半が基礎的な課題で不合格に

最先端のビジョン・ランゲージモデルに、蛍光灯の下でわずかに斜めから撮影されたタイ料理のメニュー写真を送り、料理名と価格を抽出させると、驚くべき数のモデルが自信満々に開始した後に、つまずいてしまいます。ここでいう「つまずく」とは「誤答」を意味するのではなく、スキップするレコードのように出力が切断されるまで、同じ3語を延々と繰り返す状態を指します。

これは、2024年12月にアリババのQwenグループと华南理工大学のチームが共同で発表したベンチマーク「CC-OCR」に隠れた知見の一つです。この論文では、GPT-4oやGeminiを含む9つの主要な大規模マルチモーダルモデルを、4つのカテゴリに分類された7,058枚の実写かつ注釈付き画像を用いてテキスト読解タスクで評価しました。その目玉となる結果は、画像の「読み取り」能力を広く備えているとみなされているモデルにも、単純な精度スコアでは決して表面化しない、特定かつ予測可能な失敗モードが存在することです。AIを活用したドキュメント処理を構築している場合、リーダーボードの順位よりも、この区別の方がはるかに重要です。

CORDデータセットからの実際のレシート — CC-OCRがモデルをテストするために使用する、斜めから撮影された実世界のドキュメントの一例。出典: CORD (Park et al., NAVER CLOVA, 2019), ライセンス: CC BY 4.0.

OCRベンチマークが通常見落としていること

光学文字認識（OCR）とは、画像から読み取り可能なテキストを抽出する技術ですが、かつてはスキャンされたページ上の印刷された英語テキストを読み取る、あるいはナンバープレートを読み取るなど、特定の狭いタスクに特化したモデルを実行することを意味していました。大規模マルチモーダルモデル（LMM）はこの枠組みを変えました。これらのモデルは、写真の説明やチャートに関する質問への回答など、同じモデルファミリーによって行われるタスクを実行でき、インターネット、PDF、スクリーンショットから収集された膨大な画像とテキストのペアで訓練されているため、画像に埋め込まれたテキストも読み取ることができます。

問題は、「テキストを読み取る」というタスクが、クリーンなスキャンページから離れると、多くの異なる、より難しいサブスキルを内包していることです。実際のドキュメントには、奇妙な角度で配置されたテキストがあります。意味が単語だけでなくグリッド構造にある表が含まれています。単一の行内で複数の言語が混在しています。手書きであったり、水損傷があったり、誰かのスマートフォンで奇妙な角度から撮影されていたりします。

CC-OCR以前の既存の大多数のOCRベンチマークは、この問題の狭いスライスのみをテストしていました。一部のベンチマークはシーンテキスト（道路標識、店舗の看板など）にのみ焦点を当てていました。他のベンチマークはドキュメント解析（PDFを構造化されたMarkdownまたはHTMLに変換すること）にのみ焦点を当てていました。英語と中国語以外の複数の言語をテストするベンチマークはほとんどありませんでした。また、「モデルが画像の正しい領域を見つけるか」（グラウンディング）と「モデルが正確なテキストを生成するか」を別々の測定可能な要素として組み合わせるベンチマークはほとんどありませんでした。このギャップを埋めることをCC-OCRは目指しており、これがモデルを自分で訓練しない人々でも論文を読む価値がある理由です。ドキュメントをOCRパイプラインに信頼して任せる前に、実際に何をチェックすべきかを教えてくれます。

CC-OCRの構築方法：1つのスコアではなく4つのトラック

CC-OCRは評価を4つのトラックに分割し、それぞれが異なる実世界のシナリオを対象としています。

マルチシーンテキストリーディング。 これは古典的な「野生のテキスト（text in the wild）」です。道路標識、製品パッケージ、スクリーンショット、レシートなどが対象となります。課題はテキストを孤立して読むことではなく、小さかったり、傾いていたり、複雑な背景に埋もれているテキストをまず見つけ出し、その後で正確に読み取ることです。

多言語テキストリーディング。 このベンチマークは、OCR研究で支配的な英語/中国語のペアを超えた言語範囲をカバーしており、英語の標識をうまく読むモデルが、例えば日本語の縦書きやアラビア語の右から左への表記も処理できるかをテストします。

ドキュメントパーシング。 これはAIパイプラインにおいてますます中心的な役割を果たしている「PDFから構造化テキストへの変換」タスクです。スキャンされたドキュメントを取得し、テーブル、見出し、読み取り順序を保持したMarkdown、HTML、またはその他の構造化形式に変換します。単なる平坦なテキストダンプではありません。

キー情報抽出。 請求書やフォームなどのドキュメントから、総額、日付、ベンダー名などの特定のフィールドを抽出します。 indiscriminately（区別なく）すべてを文字起こしするのではなく、これがビジネスがOCRから実際に求めているもの、すなわち「ページ全体を読んでほしい」のではなく「請求書番号を教えてほしい」というニーズに最も直接的に対応するタスクです。

これらの4つのトラック全体で、ベンチマークには39のサブセットが含まれています。注目すべき設計上の選択として、7,058枚の画像のうち41%が実際のアプリケーションからのものであり、この論文で初めて公開されたものであり、古い学術データセットからの再パッケージ化ではありません。これは重要です。なぜなら、古いベンチマークは暗記されやすい傾向があるからです。訓練中にデータセットの画像を見たモデルは、そのデータセット上で人工的に強力なパフォーマンスを示すことになります。新鮮な実世界の画像は、テストを不正に操作しにくくし、本番システムが実際に遭遇する状況により近づけます。

評価では、ほとんどのOCRスコアリングが混同している2つの要素を分離しています。1つはモデルが画像内の正しい位置を見つけるかどうか（グラウンディング、通常は予測されたバウンディングボックスが真のバウンディングボックスとどれだけ重なるかでスコアリングされます）、もう1つは抽出されたテキストが正確かどうかです。モデルはテキストを完璧に読み取っても、そのテキストの来源となる位置を指し示せない場合、評価が下がることになります。これは一般的で示唆的な失敗モードです。

レシートや回転した看板が最先端モデルを崩壊させる理由

本論文では、プロプライエタリモデル（GPT-4oやGeminiファミリー）とオープンソースモデルの両方を含む9つの主要なLMM（マルチモーダル大規模言語モデル）をテストし、その結果は3つの繰り返される弱点に明確に分類されました。

テキストグラウンディングは、生データの読み取り精度が示唆するよりも劣っている。 モデルは看板のテキストを正しく文字起こしできても、そのテキストが画像のどこに位置するかを正確に囲むボックスを描けない場合があります。これは些細な技術的なギャップのように聞こえますが、「モデルが請求書の合計額を読み取った」ことと、「モデルがダウンストリームシステムに請求書の合計額の正確な位置を伝え、強調表示や赤外、テンプレートとの照合を可能にする」こととの違いです。文字起こし以上の処理を行うパイプラインにとって、このギャップは全てを左右するものです。

多方向のテキストは一貫した盲点である。 回転した、垂直な、あるいはそれ以外で水平ではないテキストは、標準的な左から右への水平テキストを問題なく処理するモデルさえも混乱させます。これは、スキャンされた文書を取り扱ったことがある誰もがすでに知っていることと一致します。現実世界のスキャンは決して完璧に整列していないのです。角度をつけて撮影されたレシート、上下逆さまにスキャンされたフォーム、縦書きの日本語看板などは、本番環境でのエッジケースではなく、火曜日の日常です。

反復によるハルシネーションが最も珍しい発見である。 より困難な、あるいは視覚的に複雑な画像では、一部のモデルがループに陥り、一貫した限定された出力を生み出す代わりに、単語、フレーズ、または行を繰り返し続けてしまいます。これはモデルが間違った答えを出すケースではなく、完全に劣化出力パターンに陥っている状態です。これは言語生成全般で既知の失敗モードです（モデルは次に何が来るべきか不確実な場合、反復ループに陥ることがあります）。しかし、OCRタスクにおいて、ページに実際に書かれていることで「正しい」出力が厳密に制約されると期待される場所でこれが現れることは、有用な警告です。信頼度ベースのフィルタリングではこれを必ずしも検出できません。なぜなら、モデルは素朴なダウンストリームチェックが気づくような形で不確実性を表現していないからです。単に確信を持って自分自身を繰り返しているだけです。

9つのモデルのいずれも、4つのトラックすべてで優位に立っていません。英語のシーンテキストでは強力なモデルが、多言語文書では平凡な性能を示すこともあります。文書をクリーンなMarkdownに解析できるモデルが、同じソース画像でのキー情報抽出で苦戦することもあります。これが実用的な見出しです。「最高のOCRモデル」というのは、単一の転移可能なタイトルではありません。それは、あなたの文書が実際にどのような見た目をしているかに大きく依存します。

OCR構築において重要である理由

OCRエンジンを選択するか、あるいはそれに依存する製品を構築している場合、この論文の3つの要点が評価方法を変えるはずです。

まず、ベンダーのデモ例ではなく、実際のドキュメントでテストを行うことです。CC-OCRの貢献の一つは、狭い範囲のベンチマークに対する批判でもあります。クリーンで水平、英語のみというシーンテキストで高得点を出したモデルが、実際の顧客から届いた回転した多言語の表が多い請求書をどのように処理するかについて、ほとんど何も教えてくれません。レシート、外国語のドキュメント、手書きのフォームを扱う製品の場合は、それらに対して具体的にベンチマークを取ることが重要です。なぜなら、一般的なリーダーボードの順位はそれを予測できないからです。

第二に、「テキストを読み取れたか」と「テキストの位置を特定できるか」を区別してください。抽出されたフィールドをハイライトしたり、ドキュメントから構造化データを構築したり、何らかの人間によるレビューワークフローを行うユースケースの場合、グラウンディング精度は「あると良い」ものではなく、コア機能です。そして、CC-OCRが示しているように、モデルが生のテキスト精度に比べて最も弱い次元がまさにここにあります。

第三に、本番環境では誤った答えだけでなく、反復ループに注意してください。あり得ないが誤った合計を幻覚するモデルは、既知で管理可能なリスクです。低信頼度の抽出物をフラグ付けし、レビューステップを追加することができます。一方、トークン制限に達するまでフレーズを繰り返して止まらなくなるモデルは、全く異なる失敗モードです。これは、単一のドキュメントでAPI予算を静かに消費し、明らかに壊れた出力を生成しますが、自動化されたパイプラインでそれを特別にチェックしていないと見逃しやすいものです。後処理ステップに長さや反復チェックを組み込むことは過剰ではなく、文書化された失敗モードに対する直接的な対応です。

これはまた、単一のモデルにすべてを賭けるのではなく、同じドキュメントに対して複数のエンジンをテストする実用的な議論でもあります。CC-OCRでテストされたモデルのどれが、マルチシーンリーディング、多言語リーディング、ドキュメント解析、キー情報抽出の4つのトラックすべてで優位に立ったわけではありません。したがって、本番システムにとって最も安全な賭けは、エンジンの選択をドキュメントタイプ依存のものとして扱い、一度きりの決定ではなく、特定の入力でプライマリエンジンの特定の弱点が現れたときにフォールバックパスを持つことです。

日本語の読者にとって、この論文が英語のみを対象としており、縦書きのテキストを無視していることは、漢字と縦書きレイアウトがカバーされていないことを意味します。これは、日本語のOCR/VLMモデルにとって最も難しいケースの一つです。

本論文で解決されていない問題

CC-OCRは2024年末時点での9つのモデルのスナップショットであり、この分野は急速に進化しています。その後、新しいマルチモーダルモデルがリリースされており、本論文で浮き彫りにされたグラウンディングや反復の問題を特に解決しているものもあるかもしれません。また、このベンチマークは反復によるハルシネーション（幻覚）がなぜ発生するのかという原因に深く掘り下げておらず、パターンを記録しているだけで解決策を提供していません。その結果、実務者は文書化された解決策に頼るのではなく、独自の検出と緩和ロジックを構築する必要があります。

さらに覚えておくべきことは、いかに包括的であってもベンチマークはあくまで7,058枚という固定された画像セットであるということです。実際のドキュメントは、固定されたテストセットでは完全に捉えきれない形で常に驚きをもたらします。例えば、新しい請求書のテンプレート、誰も想定していなかった言語の組み合わせ、あるいは特定の顧客のハードウェアに固有のスキャナアーティファクトなどです。CC-OCRは、現在のモデルがどこで苦戦しやすいのかを示す、真に有用な地図です。しかし、それは製品リリース前に自社のドキュメントでテストを行うことを代替するものではありません。

これがまさに本論文全体の核心です。汎用的な「モデルが画像を読める」という機能と、信頼性の高い本番環境向けOCRは関連していますが、明確に異なるものです。そして、その間のギャップは、単に回すだけで調整できる一つのダイヤルではなく、向き、グラウンディング、制御不能な反復といった、特定のテスト可能な形で現れます。