OCRをGPUなしで動かすために、モデルを2つに分けた

GPUを使わずCPUだけで動く、多言語対応のOCRを作りました。1つの大きなモデルではなく、用途の違う2つに分けています。

前提(CPUだけで動かす理由)

このOCRは、製品ラベルを撮影した画像から、シリアル番号や型番などの識別情報を読み取るために作りました。最初に決めていた条件は、GPUを使わないことです。GPUのインスタンスは、使っても使わなくても時間単位で費用がかかります。読み取りの量がそれほど多くない用途では、この費用が見合わないと判断しました。

CPUだけで動かすと決めると、選べるモデルの範囲がかなり狭くなります。精度だけでなく、モデルの大きさそのものを基準に選ぶ必要が出てきます。

2つに分けた設計

多言語に対応させたいとき、1つの巨大なモデルにすべての言語を詰め込むやり方もあります。今回は、そうしませんでした。

既定のエンジンには、中国語・英語・日本語・ラテン文字をまとめて1つの132MBのモデル(検出用59MB、認識用73MB)でカバーできるものを採用しています。多くの案件は、これだけで足ります。

一方で、ベトナム語には別の問題がありました。既定のエンジンにベトナム語の文章を読ませると、声調記号がきれいに脱落してしまいます。単に精度が落ちるのではなく、記号そのものが消えてしまう状態です。この問題は、パラメータの調整では直りませんでした。

そこで、ベトナム語の声調記号だけを担当する、もう1つのエンジンを別に用意しました。こちらは約623MBあり、既定のエンジンの5倍近い大きさです。すべての案件でこの重いエンジンを常時動かすのではなく、ベトナム語が必要なときだけ切り替えて有効にする作りにしています。

分けて分かったこと

2つに分けてよかったと感じているのは、ベトナム語が要らない案件のお客様に、余計な容量と処理時間を負担させずに済むことです。実測では、英語と日本語は完全一致で信頼度0.997と0.999、ベトナム語専用エンジンも0.913まで到達しています。1つのモデルに無理にまとめていたら、どこかの言語で精度を妥協することになっていたと思います。

識別番号を抜き出す部分は、モデルではなくルールで作りました。正規表現でラベルの形式に合わせ、近くにある数値と結びつけ、シリアル番号らしいものはチェックサムで確認する、という組み合わせです。結果がおかしいときに、どのルールで拾ったかをすぐ追えるようにしたかったためです。テストは、単体42件、実際のモデルを使った結合12件の、合わせて54件を用意しています。

まだできないこと

正直に書いておきます。ベトナム語エンジンは、印刷された文字を撮影した画像では検証できていますが、実際にスマートフォンで撮ったような写真ではまだ検証していません。既定で無効にしているのは、この理由からです。

表や複数列のフォームのように、構造そのものを読み取る用途にも対応していません。もっと大きなモデル構成で対応できることは調べていますが、今の132MBという軽さとは引き換えになるため、必要になった案件が出てから考える方針にしています。認証やアクセス制限もまだ入っておらず、今は社内や開発環境での利用を前提にした段階です。

要件がまとまっていなくても構いません。状況を聞かせてください。出品サービスのページからご連絡いただけます。