こちらの記事は カケハシ Advent Calendar 2024 の11日目の記事になります。
こんにちは。Musubi AI在庫管理の開発を担当している機械学習エンジニアの木村です。
この記事では今年に実施した予測アルゴリズムの改善の取り組みの中で重要だったと思うポイントについて紹介したいと思います。 技術的な話は割愛して取り組みそのものに焦点を当てて書いていきます。
背景
AI在庫管理では日々数百万件にのぼる薬の需要予測を行っています。また薬を処方する病院、薬局、患者さん、薬の種類の違いなどによって来局の間隔や処方量のパターンもさまざまで、すべての予測で理想的な結果を出すことはとても難しいです。とはいえ、たった1件の予測のミスでも、薬局を訪れた患者さんが薬を受け取れず困ってしまう可能性があるため、予測のミスを防ぐことは重要な課題です。
少しでも予測精度を上げるため、私たちのチームでは顧客からのアルゴリズム関連の問い合わせや改善要望を集計・分析し、継続的な改善を行っています。 AI在庫管理はリリースから3年ほどが経ち、リリース当初と比べると予測精度が向上しましたが、その一方でシステムが複雑化してきており、また品質に対する要件のレベルも厳しくなってきていることから、問題発生時の原因調査やアルゴリズムの改善の難易度は上がってきていると感じます。
このような状況の中でチームメンバーと協力しながらアルゴリズムの改善に取り組みを進めております。
予測アルゴリズム改善の取り組みで重要だったポイント
次のような流れでアルゴリズム改善に取り組みました。
- 顧客要望に応えるための取り組み
- 顧客要望から重要度の高い課題抽出を行い、原因調査を行います。
- 厳しい品質要件を満たすための取り組み
- 改善案の試作と評価を繰り返します。品質要件を満たすものが完成した段階で、リリースを行います。
一連の取り組みを振り返り、私が特に重要だと感じたポイントを、反省点も含めてまとめたいと思います。
顧客要望に応えるための取り組み
顧客要望の分類、決定
顧客から寄せられるアルゴリズムに関する問い合わせについて、日頃から各案件に課題ごとにタグを付けて分類してきましたが、予測アルゴリズムの複雑さに対し分類基準が明確でなかったため、異なる課題が混在したり一部の案件を見逃してしまっているケースがありました。 そのため今回は過去の問い合わせを含めて再度分類を実施しました。
課題を精査してみないと分類基準自体を決めづらかったり、課題が複合的で分類が難しい場合もありますが、できるだけ早い段階で分類基準を明確にしておくことで手戻りを減らして効率的に調査できると思いました。また、客観的かつ定量的な基準があれば、別の担当者が対応する場合でも一貫した結果を得られると思います。
顧客問い合わせ案件のうち重要度の高い課題として、複数の疾患を抱える患者さんの来局予測が出せなくなるケースがあるという課題を抽出しました。
本質的な原因調査
来局予測を出すかどうかを決めるために二階層の機械学習モデルを導入しており、第一階層で処方データのクラスタリングを行い、第二階層でクラスタリング結果に基づき予測を出すかどうかを決める判別モデルを使っています。
当初の調査では、この判別モデルの出力結果のみを見ており、根本原因を特定しないまま判別モデルの改善に取り掛かってしまいました。その結果、目先で見ていた数値はわずかに改善したものの、精度が悪化するケースも見られ、効果的な改善策にはなりませんでした。時間をかけてしまったものの、このアプローチでは本質的な課題解決には至らないと判断し、対応を一旦保留することになりました。
その後、クラスタごとにデータを精査し、本質的な原因は判別モデルではなく、前段のクラスタリングの精度にあることが判明しました。 振り返ってみると、階層別に各モデルの精度指標をしっかりと定義して、モニタリングを実施していれば早い段階で本質的な原因に辿り着けていたと思います。
最終的には根本原因を特定し、クラスタリングの精度を向上させたことで、判別モデルの精度改善だけでなく、他の予測アルゴリズムの精度も向上しました。このクラスタリング結果は他のロジックでも広く利用しており、全体的な精度の向上が実現できました。 問題の本質を見極めることの重要性を改めて認識しました。
厳しい品質要件を満たすための取り組み
検証環境での再現
予測アルゴリズムの試作と評価をするために本番環境の挙動を検証環境で再現しました。 AI在庫の本番環境はAWSですが分析環境はDatabricksを使っているのでコード等を必要に応じて編集しつつ移植をしました。 SQLの書き方はAWS AthenaとDatabricksとで少し異なる部分があり下記を参考にして編集しました。
また、まとめて保存されている過去のデータから本番環境の日ごとのバッチ処理を再現するための検討も行いました。 過去の本番環境のデータを全て保持しているわけではないので、結果を完全に再現することはできないのですが、検証環境で良い結果を得られれば本番環境でも良い結果になることが保証できるくらいの再現はできるようになり、安心感を持ってアルゴリズム変更に取り組むことができました。
厳格なリリース判定基準
アルゴリズムの評価の際にそれを改善した場合に問い合わせのあった案件のみでなく顧客全体にどの程度のインパクトが期待できるかを評価・可視化しました。 また、新しいアルゴリズム導入時にデグレが発生しないように、特に以下の3点に注意しました。
- 精度：変更内容が多岐に影響するので影響範囲をあらかじめ調べた上で精度面で評価すべき項目をリストアップしました。今回の改善目的であった来局予測が出せなくなる課題に関する指標は改善すること、その他の精度指標については悪化しないことを判定基準としました。
- 処理時間：コストの観点でアルゴリズムの処理時間を現状と同程度かそれ以下に抑えることも判定基準としました。PythonのcProfileで処理時間のボトルネックを調べながらアルゴリズム変更を実施していきました。また前処理する対象のデータを必要最小限に抑える工夫を行いました。処理時間を短時間化する際にはコードが複雑になり過ぎないような注意も必要でした。
- 顧客への悪影響：アルゴリズム変更による顧客への悪影響が生じないことも判定基準としました。顧客影響をチーム内で繰り返し議論し、詳しく調査しました。顧客の発注数量や在庫数量に直接影響を与えない変更であっても、画面表示に違和感が生じないかなど、細部にわたって検討を行いました。
カナリアリリースの活用
この記事の執筆時点では、まだリリースは完了していませんが、現在その準備を進めています。意図せぬ挙動が発生した際に影響を最小限に抑えるため、リリース対象を限定するカナリアリリースを計画しています。カナリアリリースの対象となる薬局については、今回のアルゴリズム変更による影響が小さい薬局を抽出し、プロダクトマネージャーと合意の上で決定しています。
カナリアリリース当日は、複数のエンジニアが薬局の営業開始前に予測結果を確認する予定です。問題が発生した場合にはリバートをした上で予測を再作成できる時間を確保しています。
全薬局へのリリースは、カナリアリリースの結果を十分に検証した後に行う計画です。手順が多くなるのは避けられませんが、薬局への影響を最小限に抑えるために必要なプロセスです。安全なリリースを目指して慎重に取り組んでいます。
おわりに
この記事では、AI在庫のアルゴリズム改善をする上で私が取り組んだ中で重要だと思った内容をご紹介しました。振り返ってみると反省点も多く手探りな部分も多いのですが、全体的な精度向上につながる改善策を見つけることができました。AI在庫の予測アルゴリズム自体が複雑化してきて改善の難易度は増してきましたが、今後も顧客の信頼に応えるためにシステムの安定性を担保しつつ予測精度の向上を目指していきたいと思います。読んでいただきありがとうございました。
