LayerX エンジニアブログ

LayerX の エンジニアブログです。

機械学習とビジネスゴールのはざまで

機械学習とビジネスゴールのはざまで

機械学習をプロダクトに取り入れて磨き上げているいるみなさん。機械学習モデルのオフライン評価とビジネス上のKPIとを近づける難しさを感じてませんか?

はじめに

深澤 (@qluto) です。

LayerXという会社で、経理業務をはじめとした業務支援を行うバクラクシリーズの開発に携わっています。私はその中でも、非定型の書類から的確に情報を読み取るAI-OCR機能の開発を担当しています。

私は、機械学習を根幹に据えつつ、ビジネス上や直接的なユーザーの課題解決のために複合的な問題に対処してきたソフトウェアエンジニアです。

今回は、機械学習とビジネスゴールの狭間で生じがちな問題を俯瞰し、バクラクのAI-OCR機能において直面した問題とその解決方法についてご紹介します。

機械学習とビジネスゴールとの間にギャップが生まれてしまうのはどういう時か?

まずは、機械学習とビジネスゴールとの結び付けが難しくなりがちな要因を考えてみましょう。

こういったことを語った書籍や記事には枚挙にいとまがなさそうですが、機械学習システムデザインという本から引用したものを下地にし、自分の経験も踏まえた整理をしてみます。

O'Reilly Japan - 機械学習システムデザイン

この書籍の第1章において、研究分野での機械学習と実現場での機械学習との違いは、

  • 様々な利害関係者の関与
    • 実現場では様々な利害関係者の関与があり、時には相反することもある
  • 計算の優先順位
    • 研究では高速に訓練できることが優先されるが、その一方で、実環境では高速に推論できることが優先される
  • 使用するデータの特性
    • 研究では固定されたデータセットによって性能評価が行われるが、実環境では価値を出し続けるために変化し続けるデータに向き合う必要がある
  • 公正さの課題の重要性
    • 予測精度に関するSoTAはあるが、公正さのSoTAに当たるような決まった指標は確立されてない
  • 説明能力の重要性
    • モデルの出力結果に対する説明能力は、特にビジネスシーンにおいて重要となる

などであると語られています。私たちは事業とは完全独立したような形で研究をしているわけではないのですが、対極的な2者を比較しながら考えを深めていくのは有効なアプローチです。

5つのポイントはそれぞれ語れば長くなりそうなのですが、今回は私が直近取り組んでいたひとつめについてだけ語ろうと思います。

様々な利害関係者の関与

研究やリーダーボードのプロジェクトでは、単独の目標に焦点が当てられます。主にモデル単体の性能がこの目標となるでしょう。 ただ、機械学習の実現場への導入には多くの利害関係者が関与しています。 スコープが異なっていたり、時には要求が相反していたりもします。

  • 機械学習エンジニア
    ユーザーが注文してくれる可能性が高いレストランをレコメンドするモデルが欲しい。そして、より多くのデータがあれば、より複雑なモデルを使えばこれが実現できると信じている
  • 営業チーム
    レストランが高級であるほどサービス料が高額になるので、より高級なレストランをレコメンドするモデルが欲しい
  • プロダクトチーム
    レイテンシーが増大するにつれて、当サービスを介した注文が減少することに気づいたので、お勧めのレストランを100ミリ秒以内で返せるモデルが欲しい
  • 機械学習プラットフォームチーム
    トラフィックの増大に伴い、既存システムのスケーリングの問題のためにこのチームは深夜に何度も叩き起こされることになったので、モデルの更新を後回しにして機械学習プラットフォームの改善を優先したい
  • マネージャー
    利益率を最大化したい。そのためには機械学習チームを手放すこともひとつの選択肢かもしれない

機械学習システムデザインではこのような仮想例が記載されていますが、このような構図は十分身の回りでもあり得るのではないでしょうか。もしかしたら読者の中には、まさにこういったシチュエーションに苛まれたことのあるひともいるかもしれません。

ここには各関係者の思惑がすでに現れていますが、コミュニケーションが不足していればこの状況すら見通せず、届けるべき価値を何ひとつ届けることすらできないかもしれません。

LayerXではチーム間の情報連携は密に行われており、仕組み化も日々進んでいます。全社的にユーザーの業務理解を深く行おうという活動も活発なため、このような課題は現在あまり起きにくい状況だと言えるでしょう。

上記は役割単位で社内の関係者だけを並べ立てた例ですが、多種多様なユーザーの属性やシチュエーションを掛け合わせていくと、より複雑になることが多々あります。

多種多様な社内関係者とユーザーの要求が入り混じることに対応するため、機械学習システムはより複雑なものへと変容していきかねません。複数の機械学習モデルを用意しそれらを組み合わせることになったり、ヒューリスティックなルールを追加することによって特殊だがインパクトの大きい事象に対応することになったり、外部のデータベース・辞書と連携して出力結果を変換したりなど。

複雑化した AI-OCR 機能の内部をどのように改善していくのか?

バクラクの AI-OCR 機能に対し、この問題を解きほぐすために行ったことについて紹介をします。

これまでの状況の解説

バクラクの AI-OCR 機能は次のスライドのようにタスクが分割されています。

現状システムとしてはシンプルですが、請求書の読み取りというタスクに多層的な複雑さが含まれています。これを機械学習モデルに解かせたいというモチベーションがあり鋭意努力中です。続く投稿でこのことについて案内できればと思います。

この多段階構成を一つひとつ分解して評価可能な状態になっていれば話は簡単なのですが、現実的にはそれが難しいのが現在の状況です。

去年機械学習モデルを作成した際には、下記スライドにあるようにデータセットを整備しており、請求書の値の読み取りというタスクをユーザーが最終的に採用した値で評価することを主軸として改善を積み重ねてきました。

機械学習モデルと追加のルールベースロジックを分けて評価できるように整えている部分もちゃんとあり、どこで何が起きているかを把握できていないわけではありませんでした。しかし、ロジックが徐々に増えて複雑になってきています。このロジックには私たちが直接関与するものもあれば、ユーザーの要求に合わせて値を変更可能にするプロダクト上の設定も含まれています。

特に後者はオフライン評価の環境では取り扱うのが難しく、オフライン評価とオンライン評価の乖離が大きな懸念となってきました。

課題解決のために行ったこと

私が入社間もなかったこともあり、AI-OCR 機能とそれを取り巻く周辺仕様についての棚卸しを行いました。全てを詳細に述べると長くなるので簡単な紹介にとどめますが、現在は下記のようなロジックが代表的なものとして採用されています。

  • 社内のマスターデータによって影響を与えるもの
    • 一般公開されている日本会社名辞書による取引先名の補完・修正
  • ユーザー自ら運用に即した値になるよう影響を与えられるようにするもの
    • ユーザーによって独自で設定された取引先マスタによる取引先名の補完・修正
    • 業務ルールに合わせた支払期日の修正(毎月の特定日に支払期日を一律で揃えたいなど)
  • 機械学習モデルをアシストするヒューリスティックなルールセット
    • 正規表現によるカバレッジ重視の抽出ロジック

これらは機械学習モデルの出力結果がユーザーに届くまでの過程で適用されるものです。

当然、全体の性能改善を図るために取り入れられているものですが、毎日 AI-OCR の結果をモニタリングする中まだまだ不十分な部分もあるのでは……?という事例がちらほらと目につくようになってきた状況でもありました。

社内のマスターデータは古びて漏れが生じているケースが見つかったり、ユーザーに設定していただければ大きく改善されそうな変更パターンが見つかったりなど。これらを目視でちらほらと見つけてはいたのですが、どれほどのネガティブインパクトが生じているかを定量的に評価することが急務でした。

複雑なものへの対処は大変なことですが、単純に要素が多くて理解が難しいのと、要素同士が密な相互関係を持っていて難しくなっているかによって対処法も変わります。今回棚卸しした一つひとつのものは基本的に周辺のものと独立していて、要素が多いという性質が悩みの大部分です。ならば一つひとつを追いかけられるようにすればいいだけのこと。

まず、それぞれのロジックがどのような影響を与えているのかが記録しきれていない部分に対してログを取るようにしました。後から大規模データ分析が簡単に行えるようデータ基盤(LayerX の場合は BigQuery 上に展開)への連携が効率よくされるような設計も大事でした。

次に、日々行なっている性能モニタリング方法を更新しました。これまで行なってきたモニタリングがどういうものだったのかは下記の記事に詳しいです。

tech.layerx.co.jp

良いモニタリングはただただ起きていることを理解するだけではなく、すぐに実行可能な改善策を導き出すことができるものです。

今回の更新にあたっては、懸念となり得る要因を一つひとつ剥がし落としながら、真因に効率よく迫れるようにするため、モニタリングを行う際のトラブルシューティング思考プロセスをフローチャートとして描き、それに合わせたダッシュボードを整備しました。

結び

ソフトウェアエンジニアリングの範疇ではコードとテストを管理することが要所ですが、機械学習システムにおいてはデータを管理することが加わってきます。直接的に操作を加えることのできない生きたデータとなってくると管理が難しいものですが、異常を検知することができれば少なくとも先手を打つことができるのではないかと思います。

今回は取り上げなかったのですが、データシフト・データドリフトへの対処や機械学習モデルの説明能力に関してもまだまだ課題があります。

入社して3ヶ月。7月からは AI-OCR のモデリングを主軸としたチームのリーダーを務めさせていただくことになりました。LLM をも駆使しながら AI-OCR の性能をより高めていき、バクラクな体験を届けたいと思っています。

AI-OCRに関連する技術は日々進歩を続ける中、その技術でお客様の体験をバクラクにするための仲間がまだまだ必要で、一緒に働いてくれる仲間を大募集しております!

少しでも興味を持ってくださった方!ご応募をお待ちしております!

jobs.layerx.co.jp

私とカジュアルに話す機会も歓迎しております! jobs.layerx.co.jp