KAKEHASHI Tech Blog

カケハシのEngineer Teamによるブログです。

機械学習エンジニアが「機械学習を使わない」選択をした理由

はじめに

こんにちは。機械学習エンジニアをしている藤本です。

「機械学習を使わないシンプルな方法に置き換えても良さそうだ」

これは、約4年間運用してきたMLモデルのパフォーマンスを初めて可視化した時の率直な感想です。この後、機械学習を使わないモデル(ナイーブモデル)への置き換えを検討することになります。

今回は、「顧客影響が出てからしか検知できない」という後手の対応から脱却し、モニタリング体制を構築するまでの道のりを共有します。技術的負債と向き合い、データに基づいたMLモデル廃止の意思決定に至るまでの経験が参考になればと思います。

チームとシステムが置かれていた状況

MLモデル導入当時の状況と期待

2020年当時、私たちのチームでは新しいプロダクトの開発を進める中で、ある需要予測を行う必要がありました。しかし、実際のデータがないという制約があり、どのようなモデルが適しているかを判断するのが難しい状況でした。そこで現場の薬剤師や店舗スタッフへのヒアリングから需要予測に必要な要素を洗い出すアプローチを取りました。

ヒアリングの結果、以下のような需要の特性が明らかになりました。

  • 週単位、年単位の周期性が存在する
  • エリアごとに需要の一時的な急増・急減が発生する

これらの特性をカバーし、その後の新たに考慮すべき事象にも対応できる柔軟性を持つ方法として、機械学習による需要予測モデルを採用しました。当時は、この予測機能がプロダクトの中核機能を支えるモデルになると考えていました。

その後、プロダクトの改善サイクルの中で、このモデルはサポート的な役割として機能するようになっていき、チームのリソースは顧客価値により直結する機能の改善に集中させていくことになりました。

当時の改善サイクル

当時の改善サイクルは、顧客からの問い合わせをきっかけに改善を行っていました。自分たちもドメインに対する理解が低く、顧客からしたら当たり前の要素をモデルに組み込めていない事が問い合わせとして表面化していたため、改善の優先度も高く、こちらに改善リソースのほとんどを割いていました。

改善効果を把握するためにモデルの精度を測る試みは過去にも何度か行われていましたが、最初はウォッチするものの、数ヶ月後には誰も見なくなるという状況が続いていました。

今振り返ると、最終的に顧客に提供するアウトプットには複数のモデルが絡んでいるため、個々のモデルの精度から顧客への提供価値向上につながるアクションを見出すことができなかったからだと思います。

可視化プロジェクトの始動

転機:別のMLモデルの精度劣化

この状況に転機が訪れたのは、別のMLモデルの件がきっかけでした。リリース当初は良好な精度を保っていたモデルが、運用期間が経つにつれて精度劣化を起こし、それが顧客からの問い合わせという形で初めて顕在化するという問題が起こりました。

この件がきっかけで、各モデルがどのように寄与しているかまで把握できなくても、普段通りの振る舞いを行えているかどうかを知ること自体に価値があると考えるようになりました。

そこで、まずは「プロダクトで利用している各モデルに対して、普段の傾向と異なっているかどうかをモニタリングする」という提案を行いました。

この提案に対して、チームメンバーからは前向きな反応が返ってきました。「完璧な指標はまだわからないが、まずはモデルの振る舞いの変化を捉えることから始めて、徐々に各モデルの寄与度も見えるように改善していけばいいじゃないか」という意見もあり、モニタリング体制を構築する可視化プロジェクトを立ち上げることになりました。

可視化プロジェクトでは、すべてのモデルを対象としたため、今回置き換えたMLモデルもモニタリング対象に含まれました。

モデルの価値を計測するアイデア

これまでの課題分析のノウハウ蓄積があったので評価指標についてはわりとすんなり決まり、モデルの振る舞いの変化を知ることについては目処がつきました。ただ、モデル自体の価値も測りたいという思いもあったので悩んでいたところ、ナイーブモデルと比較するのはどうかというアイデアが出ました。計算コストや運用保守の手間が少なく、説明性も高いナイーブモデルと比較することで、機械学習モデルを利用していることの価値がわかるのではないか?ということでした。このアイデアも採用し、可視化プロジェクトでは

  • モデルが普段通りに振る舞っているかどうか
  • モデルはちゃんと価値を出せているのかどうか

の2点をモニタリングするという運用で始まりました。

可視化で判明した事実

モニタリングを開始するとナイーブモデルと比較して、他のモデルはプロダクト側の方が精度が高いことを示していましたが、今回置き換えたMLモデルのみ、下図赤枠に示す通りナイーブモデルの方が継続的に良い結果を出していることがわかりました。

さらに、このMLモデルは以下の問題も抱えていました

  • 予測機能においてAWSコストの約20%を占めていた(薬局×医薬品単位で膨大な数のモデルを学習・推論するため)
  • 導入拡大に伴うスケーラビリティの問題が顕在化していた

これらの事実から、MLモデルを必要としないナイーブモデルへの置き換えを本格的に検討するようになりました。

改善に向けた取り組み

置き換えに向けた影響範囲の調査

モデル置き換えにあたっては、このモデルを利用するサポート機能への影響に加えて、このモデルの予測結果を他のプロダクトが使っていたので、他プロダクトへの影響も調査する必要がありました。

ナイーブモデルの改良

調査の結果、インフルエンザ治療薬など、季節性やトレンドの影響を受けやすい医薬品で、ナイーブモデルの弱点が明らかになりました。

この課題に対し、データサイエンティストのメンバーから「直近4週間のトレンドの利用」の提案がありました。検証の結果、トレンドも考慮したナイーブモデルは先述の弱点を克服し、冒頭の定量評価においてもMLモデルと同等以上の性能を示したため、トレンドを考慮したナイーブモデルを採用することにしました。

意思決定と改善の実施

収集したデータとこれまでの分析結果を基に、意思決定のための資料をPdMに提示しました。データに基づいた明確な根拠があったため、組織として納得感のある決断ができました。

意思決定後は、エンジニア、データサイエンティスト、Bizチームなど様々なメンバーが協力して実行に移りました。特に印象的だったのは、「MLモデルからの脱却」という技術的には後退とも取れる変更に対して、「現状の強みはここだから、アピールポイントを変えよう」といったような形でBizチームが前向きに資料更新の議論を重ねてくれたことです。

モニタリング体制の運用

改善実施後も、構築したモニタリング体制は継続的に運用されています。隔週で各モデルの精度を計算して更新するようになっているのでそのタイミングでエンジニア・データサイエンティストが集まり、各指標の推移を確認しています。

この会議では「この指標はこういう面で課題があるのでこう改善したらどうか」といった指標自体の見直しや、「ここの指標の変化はGWの影響を受けていそう」といった外部要因の気付きも共有されています。

このような継続的なモニタリングにより、モデルの性能維持だけでなく、新たな改善機会の発見やナレッジ共有につながっており、プロダクトの品質向上に貢献し続けています。

この活動を通じて得られた学び

1. MLモデル導入における仮説検証の重要性

今回の活動を通じて、MLモデルの導入では、特にデータが限られた状況からスタートする場合、初期仮説の検証と継続的なモニタリングが不可欠であることを痛感しました。

「ヒアリングから実際起きている現象をMLモデルで再現できる」という仮説によるアプローチは当時を振り返ると仕方無いとは思いますが、その仮説を継続的に検証する仕組みが無かった事で改善の必要性に気づく時期がかなり遅れてしまいました。

2. モニタリングがもたらす組織的価値

モデル精度のモニタリングやその体制の構築は、実際的な価値だけでなく、様々な組織的な価値もあると感じています。

まず実際的な価値として、個々のモデルをナイーブなモデルとそれぞれ比較し、価値を発揮しているかどうかを評価するアプローチでMLモデルの問題に気づくことができました。今回のMLモデルの置き換えは、先述のコストやスケーラビリティの問題により優先度が上がったと言う側面がありますが、改善のテーブルに乗せることができたのは可視化プロジェクトのおかげでした。

また、モニタリングを通してデータの変化に伴うモデルの振る舞いの変化(例:GWやお盆)を知ることでドメインへの理解も深まっています。参加メンバがドメインや各モデルに対する理解を深めることができるという良いナレッジ共有の場にもなっています。

さらに、モニタリングのプロセスや体制が確立されたことで、運用改善や指標見直しの議論が継続的に生まれるようになり、以前のような形骸化を防ぐことができています。

3. シンプルなアプローチから始める重要性

今回、MLモデルの置き換えはナイーブモデルへの置き換えから検討を始めて、その後の影響調査で分かった弱点を工夫して解消した形になります。

課題を解決するため、最もシンプルな方法だとどうなるかという検証は、最適解を選ぶためのヒントになるという事も今回の活動を通して得た学びでした。

終わりに

機械学習エンジニアとして、高度な技術を追求することも大切ですが、ビジネス価値を最大化する最適解を見つけることこそが、真の技術者の責務だと感じています。

今回のモニタリングの組織化により、意思決定プロセスを改善し、より健全な技術選定ができるようになりました。データによる可視化を組織として取り組む重要性を、改めて実感しました。

カケハシで一緒に働きませんか?

そんなカケハシでは一緒に働く仲間を募集しています。少しでも興味のある方はぜひご連絡ください!