イントロダクション
このタスクは、実際には OCR の「前段」にあたる処理です。
近年は汎用 OCR モデルがかなり成熟しており、前処理なしでも、制約の少ない環境で文字を見つけて認識結果を返せるようになってきました。
ただし、それにはそれなりのコストがかかります。
ここで言う「コスト」は、いくつかの観点から考えられます。
推論コスト
実際の現場では、OCR 領域の中でも文書認識の比重はかなり大きいです。というのも、私たちの生活は文書と切り離せないからです。
しかも、こうした場面では、自分から積極的にスキャンしたいというより、必要に迫られて提示することの方が多いはずです。
- 銀行口座を開くときは本人確認書類が必要ではないか？
- 海外に行くときはパスポートが必要ではないか？
- ビザ申請では証明書類が必要ではないか？
- 保険加入では契約書の確認が必要ではないか？
需要が大きいからといって、必ずしも儲かる市場とは限りません。この分野には競合も多く、安価で実用的な製品がすでにたくさんあります。
つまり、汎用 OCR モデル（多くの場合は LLM）でこの問題をそのまま処理すると、推論コストだけで赤字になりかねません。
しかも、かなり派手に赤字になります。
ここでは、予算をまったく気にしなくていい人たちはいったん除外しています。
文字は通常かなり密集している
文書中の文字はたいてい高密度です。情報を取りこぼしたくなければ、高解像度でスキャンする必要があります。
例えば、一般的な物体検出では を使うことが多いですが、文書位置合わせの場面では、、、あるいはそれ以上まで上げることも珍しくありません。
もしモデルの役割を分割せず、高解像度のまま LLM に全部やらせると、推論コストはもちろん、計算資源の負担も非常に大きくなります。学習用 GPU の価格を見れば、その重さはよく分かります。LLM は本当に高価です。
中国語は文字種が非常に多い
中国語は簡体字と繁体字を含めると文字種が非常に多く、ラテン文字圏の文字分類と比べて桁違いです。
モデルは複雑な背景から文字を見つけ、そのうえでごく小さな文字領域から判別に必要な特徴を抽出しなければなりません。そのため、必要なパラメータ数も計算量も大きくなります。
私たちはもちろん、エンドツーエンドですべてを解決したくなります。理想を言えば、何も分けずにひとつのモデルですべて片づけたい。
そうした方向のモデルはすでに存在しますし、今後さらに増えていくでしょう。
ただ、現時点では推論コストが高く、収益性も低いため、現場目線ではかなり厳しい選択です。
機能分割
そこで必要になるのが、もっと現実的で経済的な方法です。その文脈で、モデル機能の分割は自然な選択になります。
これが、このプロジェクトの目的です。
- 雑然とした環境の中から、必要な文書領域を正確に見つけて平坦化し、その後の文字認識や各種処理につなげること。
文書位置合わせのあとに文字検出があり、そのあとに文字認識があり、最後に意味理解があります。
工程は少し増えますが、コストと効果のバランスを考えると、かなり現実的な構成です。
モデルの機能
このモデルは、画像内の文書を検出し、四隅の角点を正確に求め、文書を平坦化して後続の文字認識やその他の処理に使えるようにするためのものです。
ここでは 2 種類のモデルを提供しています。「ヒートマップモデル」と「点回帰モデル」で、それぞれ特徴と向いている場面が異なります。詳細は後続の章で説明します。
技術面では、学習には PyTorch を採用し、推論時には ONNX に変換して各種プラットフォームへ展開できるようにしています。また、推論には ONNXRuntime を利用し、CPU と GPU の両方で効率よく動作するようにしています。
性能面では、モバイル端末上でもおよそ 10〜20 FPS 程度の推論速度を実現しており、多くの実用シーンに対応できます。
深層学習の文脈以外で「Localization」と言うと、一般には文書や製品の多言語化を意味します。
しかしここでは、画像中の文書位置を特定し、平坦化する処理を指しています。
平坦化：三次元空間で歪んだ文書を、透視変換などで二次元平面へ写し取り、見やすい平面画像にすること。
定義
この分野の一般的な定義に従い、文書の 4 点は次の順序で扱います。
- 始点は左上
- 終点は左下
すなわち、順序は 左上 → 右上 → 右下 → 左下 です。
可視化では各座標点に異なる色を使っていますが、その色は文書の向きを意味するものではありません。
つまり、文字がどの向きに回転していても、モデルは常に左上を始点、左下を終点として定義します。
遊び場
このモデルは Web ページ上でも試せます。遊び場はこちらです。
利用中にバグを見つけた場合は、悪用を避けるためにも公開せず、まずは私たちに私的に知らせてください。できるだけ早く対応します。
最後に
最初は、Zero-shot で動作し、しかもモバイル端末上で快適に使えるモデルを目指していました。つまり、世界中のさまざまな文書にそのまま一般化でき、追加アノテーションや微調整なしで使えるものです。
しかし実際には、モデル規模の制約が大きく、その目標は思っていたより遠いものでした。
モデルを大きくすれば当初の目的から離れますし、大きくしないなら構造を工夫する必要があり、その結果として汎化性能に影響が出ることもあります。
結局、数か月試行錯誤した末に、Zero-shot 性を一部あきらめてでも、まず精度を優先する判断を取りました。
このテーマに興味があるなら、ぜひ自分でも試してみてください。フィードバックをもらえると嬉しいです。
意見や提案も歓迎します。ぜひ交流しましょう。