本記事は Sansan Advent Calendar 2023 第9日目の記事です。
はじめに
こんにちは、研究開発部の内田です。
みなさん師走はどうお過ごしでしょうか。 私は先日Jリーグを見に行きまして、その試合で見事、東京ヴェルディが昇格を決めました。 16年ぶりにJ1復帰ということで、その間の苦しんでいた時期を思い返すと、未だにじーんと来るものがあります。 来年からは次のフェーズへと歩を進め、より強いクラブへと進化していって欲しいものです。
閑話休題、私は普段 NineOCR 開発チームのリーダーを務めております。 ここ1年の取り組みを振り返ると、こちらもフェーズの変わり目の年だったと感じます。 本エントリでは、 NineOCR としてここ1年取り組んでいきたいこと、今後取り組んでいくことをまとめたいと思います。
NineOCR とは
NineOCR は、弊社が独自に開発している名刺に特化した光学文字認識 (Optical Character Recognition; OCR) エンジンです。 2018年頃の取り組み開始以降、E-mail版・氏名版を経て、2022年にデータ化範囲を名刺記載の全項目に拡大し、現在 Sansan・Eight の名刺データ化に広く活用されています。
NineOCR は、主に文字列検出器・文字認識器・後処理器の3モジュールで構成されており、これらを WebAPI 上で直列に実行することで名刺 OCR 機能を提供しています。
汎用的なOCRと大きく異なる点としては、文字列検出時点で各文字列に属性情報を付与していることが挙げられます。検出位置や認識結果文字列からは判定できない視覚的な情報を属性の推定に反映できる他、後処理を簡素化する効果があります。 また、文字認識器も検出単位に合わせて柔軟に認識できるよう設計しています。
概して、データ化での利用を念頭においてカスタマイズできることが強みと言えます。
過去1年間の取り組み
MLOps
前述の全項目版の展開を境に、名刺 OCR として1発ドカンと成果を狙うフェーズから、継続的に価値を提供し続けるフェーズへと移行したと考えています。 継続的に価値を提供し続けるには、生産性や運用といった部分にも目を向ける必要が出てくるため、 MLOps 推進に舵を切りました。 以下では、NineOCR における MLOps の事例をいくつか紹介します。
Feature Store
NineOCR の文字列検出器・文字認識器には深層学習ベースのモデルを採用しています。 モデル構築には、質の高い学習データが大量に必要となります。 弊社はデータ化を1つの生業としており、人のチェックにより質も保証されているため、かなり恵まれていると言えます。 実際、データ化フローの中間結果を直接ないし間接的に利用し、プロダクト展開可能なモデルを構築することができました。 しかしながら、継続的にモデルを改善していくには、次のような課題もありました。
- 文字列検出器
- 学習データを生成していたフローが自動化に伴い廃止され、新規データ流入がない。
- 文字認識器
- 学習データ作成に NineOCR の推論値が必要となるため、データ作成に多大な時間を要する。
- データガバナンスの観点から、手元で長期間保持することは避けたい。
これらを解決するため、最新データを学習可能な形に変換して蓄積しておく基盤である Feature Store を構築しました*1。 Feature Store の構築および改善はアーキテクトチームと連携して進めており、システム構成等の詳細は R&D エンジニアの八藤丸さんの記事が詳しいのでご覧ください。
Feature Store の導入によって、性能面で次のような成果を上げることができました。
- 文字列検出器
- 学習データの追加が可能となり、最新データで追加学習してモデルを更新。
- 文字認識器
- 特定の文字を含むケースや苦手ケースを検索可能となり、それらをサンプリング・アノテーションしてモデルを更新。
また、それ以外のサブモジュールの更新においても、起案から1-2週間程度でリリースできるようになってきており、生産性が大きく向上しているのを実感しています。
SageMaker Training
Feature Store の取り組みからも分かるように、現在の NineOCR 改善の取り組みは Data-centric なアプローチと言えます。 このアプローチでは、必然的にデータに向き合う時間が長くなり、開発マシンの GPU を持て余すことが多いです。 他方、データを整えていざ実験する際には、もっと並列数を稼ぎたくなるジレンマがあります。
このジレンマを解消するため、学習ジョブの実行環境として SageMaker Training を利用することに決めました。 これにより、手元の GPU 枚数を削りながら、学習時はスペックの高いマシンで並列にジョブを回せる環境を整えることができました。 詳細は、研究員の石井さんが解説記事を出しているのでご覧ください。
カナリアリリース
継続的に価値を「提供」しなければならないフェーズであるため、モデルをデリバリーする際の運用についても試行錯誤しています。
NineOCR は、主に名刺データ化システムである GEES から利用されています。 ありがたいことに、以前 GEES では NineOCR のリリース前に性能検証をかなり厚く行っていました。 しかし、この方式では検証にかかる工数が嵩んでしまったり、タスク優先度の関係で性能検証が後回しになってしまう等、運用上の課題が生じていました。
解決策として、 NineOCR と GEES の協議の上、カナリアリリースを導入しました。 カナリアリリースとは、リリースターゲットを本番の一部に適用してみて、問題ないことを確認したのち全展開 or 取り下げを判断するリリース手法です。 カナリアリリース導入により、実際の KPI による検証が可能になり、リリースのフットワークが大分軽くなりました。
ただ、カナリアリリースによるデグレリスクを許容してもらっていたり、まだまだ少なくない工数を割いてもらっている状況であるため、運用改善としては道半ばです。 今後もサイクルを回す中で、少ない工数で正しい判断を下せるよう工夫していきたいところです*2。
論文投稿
弊社は例年 MIRU (Meeting on Image Recognition and Understanding; 画像の認識・理解シンポジウム) にスポンサーとして参加しています。 昨年までは企業ブースの出展のみに留まっておりましたが、今年は念願の論文発表を行いました。 うち1件は文字認識に関するテーマであり、NineOCR 開発チームにインターンとして来ていただいていた竹長さんとの共同研究でした。 発表内容を含む参加レポートについては、研究員の本田さんがまとめていますのでご覧ください。
社内での利用促進
最後は NineOCR チームに閉じない話になりますが、昨年の全項目版の展開後も、社内のあらゆるところで NineOCR 活用は進んでいます。 その中で最も大きかったのが、 Eight における事例です。
実は今年 Eight データ化フローの完全自動化 を実施しており、現在 NineOCR の結果をルール・辞書ベースで補正するだけでデータ化が完結しています。 データ化コストに対する効果もさることながら、社員総出で名刺をデータ化していた創業当初を考えると、非常に大きなインパクトのある出来事でした。 性能要件を引き下げず完全自動化する判断を下せたのは、NineOCR・GEES・Eight に関わるメンバーの努力あってこそです。 この場を借りて全員にお礼を申し上げたいと思います。
今後の取り組み
更なる性能向上
先に述べた Eight の完全自動化は NineOCR チームにとって悲願でしたが、名刺データ化の本丸はやはり Sansan です。 Sansan のデータ化は Eight に比べて性能的なハードルが一段高く、完全自動化を達成するには、エラー分析やデータ収集を地道に積み上げていく他ありません。 そのためには、 MLOps 推進を通して改善サイクルを高速化し、より本質的な部分の検討に時間を割きながら、エンジンをブラッシュアップしていきたいと考えています。
他ドメインへの展開
今まで NineOCR は、名刺に特化した OCR エンジンとして大きな成果を上げてきました。 裏を返せば、NineOCR の技術を名刺以外のドメインへ適用できていないとも言えます。 これはタイミングに左右される部分であるため、一概に悪いとは言えないのですが、 OCR に関わっている一研究員としては、少し勿体無いように感じています。 今後は請求書や契約書のデータ化を担っているチームと連携しながら、適用可能な部分を探っていければと考えています。
抜本的なモデル変更
弊社の研究開発部は、プロダクト・ビジネスへの貢献を第一に、分析やモデリングを通して価値を提供していくのが基本的なスタンスです。 一方で、研究員という職業柄、最先端の技術を用いて成果を出していきたいと思う気持ちも当然あります。
NineOCR は、最先端の技術を適用する余地が比較的大きいプロジェクトでもあるため、抜本的なモデル変更を含む挑戦的なテーマに取り組んでいきます。 以下では、現段階で動き始めているテーマについて紹介します。
End-to-end OCR
冒頭で述べたように、現在稼働している NineOCR は、個別に学習した文字列検出器と文字認識器を直列に実行しています。 両者は互いに情報をシェアしていないため、時として人間が認識するよりストイックな問題設定になってしまうことがあります。 例えば、「メールアドレスが掠れていても氏名や会社名の情報を使えば読むことができるが、単体では判読不能」というケースはその典型です。
上記の問題は、文字列検出と文字認識を同時に行う End-to-end OCR モデル*3があれば、ある程度解決できそうに思えます。 また、近年は Transformer 系のモデルの台頭もあり、非常にシンプルに End-to-end OCR モデルを実装できるようになってきており、API のメンテナンス性向上にも寄与するかもしれません。
現在、Feature Store を活用して NineOCR の End-to-end OCR 化の検証を進めている最中です。 上手く進めば「いつの間にか NineOCR の中身が End-to-end OCR になっていた!!!」なんてこともあるかもしれないですね。
Vision and Language モデル
2023年は空前の生成 AI ブームの年でした。 GPT-4 がリリースされた際の「自社のエンジンが代替されてしまうのではないか?」という危機感は割と現実的なものでした。 幸い NineOCR は性能・コスト面で立場を脅かされることはなかったですが、マルチモーダルな生成 AI の台頭は今後も無視することはできません*4。
現在、 NineOCR チームとして Vision and Language モデルの検討を進めており、 手始めとして OCR を Visual Question Answering の枠組みで解き、 NineOCR と比較する実験を行なっています。 すぐすぐ NineOCR をアウトパフォームできるとは考えませんが、 NineOCR を基準に得手不得手を知っておくことは、モデルの可能性を推し量る上で重要と考えています。
現段階では何かに特化するより、モデルの汎用性を活かして価値を生み出すアプローチをとりたいと考えており、目下活用先の探索中です。 近いうちに良い報告ができるよう、検証を深めていければと思います。
まとめ
最後までお付き合いいただきありがとうございました。 だいぶ散逸的になってしまいましたが、まとめると「 NineOCR を今後も伸ばし、広げ、変えていく」ということに尽きます。 そんな NineOCR を一緒に作りたいという方がいらっしゃれば、各種窓口よりお話を聞きにきていただけると幸いです。
