AI2.0時代において、OCRモデルの研究は終焉を迎えたのか？（OCR：画像内のテキストを編集・検索可能なテキストに変換する技術）

Vary の作者らは、OCR-2.0 に向けた最初の汎用エンドツーエンド モデルである GOT をオープンソース化しました。

実験結果は人々に証明します:いいえ~いいえ~いいえ~

GOT モデルのパフォーマンスはどの程度ですか?

さっそく、レンダリングをご紹介します。

△最もよく使われるPDF画像からMarkdownへの変換機能

△ 2列テキスト認識機能

△ 自然な風景ときめ細かいOCR機能

△ ダイナミック解像度OCR機能

△ 複数ページのOCR機能

△ より多くの記号に対応するOCR機能

研究チームは、GOT モデルのパフォーマンスは良好であったものの、言語サポートの増加、形状の複雑化、チャート上の OCR パフォーマンスなど、いくつかの制限もあったと述べています。

OCR-2.0 の研究はまだ先のことであり、GOT にもかなりの改善の余地がある (プロジェクトはデータとコンピューティング リソースの点で非常に限られている) とのことです。

GOTとOCR-2.0の可能性を深く理解しているため、GOTをオープンソース化することで、より多くの人々がVQAを捨て、強力な認識に戻ることを願っています。純粋なOCRは非難されやすいと誰もが言いますが、それはOCRが十分に機能していないことを示しているだけではないでしょうか？

GOT: OCR-2.0に向けて

一般的な OCR モデルは汎用的である必要があり、これは入力と出力の両方が汎用的であるという事実に反映されています。

GOT の一般的な機能は次のとおりです。入力に関しては、モデルはシーンテキスト OCR、ドキュメント OCR、きめ細かい OCR、より一般的な OCR などのタスクをサポートします。

△ユニバーサルOCRモデルは「ユニバーサル」である必要があります。

出力に関しては、このモデルはプレーンテキスト出力と、Markdown などの読みやすく編集可能なフォーマットされたテキスト出力の両方をサポートしています。

モデルの構造とトレーニング方法では、ビジョン エンコーダー、入力埋め込み層、デコーダーで構成されるパイプラインが採用されています。

エンコーダ本体は、ローカル アテンションを備えた VIDDet アーキテクチャを採用しており、高解像度で CLIP ソリューションのグローバル アテンションが過度にアクティブ化されることを防ぎ、メモリ オーバーフローを回避します。

エンコーダの最後の2層は、Varyデュアル畳み込み設計を採用しています。エンコーダ全体では、1024×1024×3の画像を256×1024の画像トークンに圧縮します。これは、A4用紙サイズの高密度OCRに十分なサイズです。

△ GOT構造とトレーニングフローチャート

研究チームは、段階的に固定するLLMを使用せずに、学習プロセス全体を3段階に分割しました。画像とテキストのアライメント段階がなかったため、画像トークンのテキスト圧縮率が低下しました。

トレーニングの 3 つのフェーズは次のとおりです。

フェーズ1 ：効率的な事前学習済みエンコーダ。GOTの学習プロセス全体を通して、A100レベルのカードは使用されません。リソースを節約するため、このフェーズでは小型のOPT-125Mをデコーダーとして使用し、エンコーダーに最適化指示を与え、大量のデータを迅速に入力できるようにします。

フェーズ2 ：エンコーダーとデコーダーの共同トレーニング。このフェーズでは、前フェーズで事前トレーニング済みのエンコーダーとQwenチームによって事前トレーニングされたQwen0.5Bを使用して、GOTの基本構造が完成します。

研究チームはデコーダーのサイズをわずかに大きくしました。この段階では大量のOCR-2.0の知識を入力する必要があり、多くのデータ（化学式のOCRなど）は実際にはある程度妥当なものだったためです。しかし、彼らはあえてデコーダーのサイズを小さくしようとはしませんでした。

フェーズ 3 : エンコーダーをロックし、デコーダーを強化して、座標または色によってガイドされるきめ細かい OCR (読み取りペンで使用可能)、動的解像度 OCR テクノロジ (超高解像度画像で使用可能)、および複数ページ OCR テクノロジのサポートなど、より多くの OCR アプリケーション シナリオに適応します。

この機能は主に、後続のフォロワーがArxivデータでより適切にトレーニングできるようにすることを目的としています。私たちのアイデアは、.texファイルのページ切れを気にすることなく、複数ページのPDFで直接トレーニングすることです。

研究チームは、GOT モデル設計全体の中で最も困難な側面であるデータ エンジニアリングに直面し、さまざまな種類のデータを構築するために、LaTeX、Matpix-markdown-it、Matplotlib、Tikz、Verovio、Pyecharts など、多数のデータ レンダリング ツールを学習しました。

△ GOTで使用されるデータレンダリングツール

OCR の研究はまだ始まったばかりです。

大規模モデルが全面投入される時代に、なぜ OCR の研究を続けるのでしょうか?

研究チームには独自の理由がありました。

OCRは常に実用化に最も近い研究分野の1つであり、AI-1.0時代の技術的な集大成です。

LLM（LVLM）を中心とするAI-2.0時代では、OCRはマルチモーダルな大規模モデルの基本機能となり、様々なモデルが本格的に導入されつつあります。

マルチモーダル大規模モデルは、汎用モデルとして、OCR モデルに比べてある種の次元削減の利点を常に持っているように見えます。

では、純粋なOCRの研究は本当に終わったのでしょうか？もちろん終わりません！まだ始まったばかりかもしれません。

まず、AI-1.0 OCR システムと LVLM OCR の欠点を確認しましょう。

まず、AI-1.0パイプライン型OCRシステムがあります。このシステムの欠点は明らかです。各モジュールが比較的独立しているため、最適化が局所的になり、メンテナンスコストが高くなります。

最も重要なのは、それが普遍的ではないことです。異なる OCR タスクには異なるモデルへのルーティングが必要となり、不便です。

純粋なOCRタスクにおける大規模マルチモーダルモデルの欠点は何でしょうか？私たちは、主に2つの問題があると考えています。

1. 推論を行うと、必然的に画像トークンの数が過剰になり、純粋な OCR タスクのボトルネックが発生します。

推論（VQAのような）機能はLLM（デコーダー）によって実現されます。より優れたVQA機能（少なくともデータ収集の観点）を得るには、LLMを最大限に活用する必要があります。したがって、画像トークンはテキストトークンに可能な限り類似している必要があります（少なくとも高次元では、LLMがより快適に機能するように）。

100個のテキストトークンでLLM語彙に何文字をエンコードできるか想像してみてください。また、PDFの1ページのテキストにはいくつのトークンが必要でしょうか？VQAを維持すると、OCRタスク、特に高密度OCRタスクでは、かなり見苦しいモデルになることは容易に想像できます。

例えば、PDF画像1枚がA4用紙1枚分しかない場合があります。多くのLVLMでは、数千の画像トークンを抽出するために、画像のスライスとOCR処理が必要です。各画像をスライスする必要がある場合、複数のPDFページから合成画像を作成するにはどうすればよいでしょうか？

OCR モデルにこれほど多くのトークンを用意する必要はないと考えています。

2. 非常に明白な点の 1 つは、モデルが大きすぎるため、反復が困難になっていることです。

新しい言語のサポートなど、新しいOCR機能を導入するには、SFTでモデルをトレーニングするだけでは不十分です。事前トレーニングまたは事後トレーニングでビジョンエンコーダーを有効にする必要があり、これは非常に多くのリソースを消費します。

これは OCR のニーズには無駄が多すぎます。

小さなモデルでこれほど多くの OCR タスクを同時に実行できるのかと疑問に思う人もいるかもしれません。

私たちの答えは「はい」です。そして、さらに良くなる可能性も秘めています。