バクラク事業におけるAI-OCR機能のアーキテクチャ

アーキテクチャ選択の背景や意図

バクラク事業では、日々の経理担当者の業務や現場の稟議や経費精算作業において、圧倒的に使いやすくワクワクするような体験作りを目指しています。バクラクでは法人の支出に関わる作業をサポートするサービス群を提供しており、請求書受取・請求書発行・稟議経費精算・法人カード・電子帳簿保存法対応ストレージサービスなどがあります。
その中で、AI-OCR機能という機械学習を活用した機能が、バクラクの提供する全てのサービスで利用されています。今回はそのアーキテクチャを紹介したいと思います。

AI-OCR API

AI-OCR機能はバクラクの各サービスから独立して存在します。AI-OCR APIは各サービスからのファイルに関する情報を含むリクエストを受けると、5秒以内にそのサービスで利用する項目（例：取引先名・書類日付・支払金額・支払期日・振込先口座など）を読み取りその結果を各サービスにレスポンスとして返します。
AI-OCRの内部の処理は大きく前処理・推論・後処理から構成され、それぞれのタスクはAI-OCR WorkerとSQSで非同期処理することで突発的にリクエストが増えてもスケールしやすくしています。
書類データを扱う処理は内部データが欠損していることもしばしばあり、予期せぬ挙動が発生しうるため、ファイルを開くような処理はAPIやworkerで処理せず、Lambda関数に逃して処理することでpanicやメモリ領域を大量に使う処理が発生してしまっても他のリクエストには影響しないようにしています。

機械学習パイプライン

機械学習モデルはVertex AI Pipelinesを用いた実験パイプラインで作成されています。Vertex AI Pipelinesを選んだ背景としては、メンバーの知見があったからという理由もありますが、フルマネージドでサーバーレスに動作するためインフラを持たなくていい、というのが今のフェーズのチーム規模の要件に合致していると感じたためです。また、OSSであるKubeflow Pipelinesを用いて実装できるため、汎用性が高いと感じました。
学習に使用するデータは、各プロダクトの書類データやアノテーション結果などをBigQueryにインポートしており、BigQuery内で機械学習モデルに入力するための前処理などが完結するように工夫しています。
プロダクトの本番環境はAWS上で構築されているため、APIはSageMaker Endpointのカスタムコンテナで提供しています。少し工夫している点として、前処理・後処理などのCPUで動作する部分とGPUで推論する部分を分けているところがあります。このようにすることで、CPU、GPUのどちらかがボトルネックになった際に、それぞれの要件に合わせてスケールアウトさせることを可能にしています。また、GPU推論にはTriton Inference Serverを用いており、TensorRTのモデルをデプロイすることで低レイテンシを実現しています。

現在の課題と今後の改善予定

AI-OCR API

AI-OCRのAPIは非同期処理によって大量のリクエストにも対応できるようにしていますが、実はAPIは一定時間ポーリングしたのち、処理が終わらない場合はそれ以降は処理がまだ途中であってもタイムアウトとしてクライアントにリクエストを返すような同期的な挙動をしています。したがって、非同期処理の良さをうまく使いきれないのが現状です。
今後は同期処理すべきものと非同期処理すべきものを見極めた上で処理の方法を変え、それぞれの恩恵を十分に受けられるようなアーキテクチャを目指したいと思っています。たとえばリアルタイム性を求められないが数万件のリクエストを捌きたいというニーズと、数十枚を即時でデータ化して欲しいというニーズがある場合、同じAPIで処理するのではなく、同期と非同期APIをそれぞれ用意してあげると効率よく処理できるのではないかと考えています。

機械学習パイプライン

まず、実験パイプラインの話だと実験の高速化が課題になっています。一定VertexAI Pipelinesでキャッシュ機能などを自作し効率化は図っていますが、事業の成長に伴って扱えるデータも指数関数的に増加しており、単純に全てのデータを用いてしまうと非効率な学習・評価になってしまいます。まず、データに立ち返ってどういう問題を解くべきか、どういう評価をするべきか、をしっかり考えた上で、事業成長に対してスケールできるような実験パイプラインの構築を行っていく予定です。
また、コンパウンドプロダクトならではの悩みかもしれないですが、プロダクトが増えていくことによって、AI-OCR APIが呼び出される箇所が多くなり、プロダクトに対して必要な読み取り項目も増えてきています。今後、増加する項目に応じて複数のモデルを運用していく可能性もあり、どこまでの処理を共通化するか、どのように運用するか、などを考慮したML基盤を構築する必要性が出てくると思っています。まずは、モノレポ的な開発体制を取っていくことでそのような課題を解決していこうと考えています。

◆執筆：
北岡知晃　バクラク事業部 機械学習グループ ソフトウェアエンジニア　@tapioca_pudd
島越直人　バクラク事業部 機械学習グループ テックリード　@nt_4o54