このシリーズでは本番環境でのモデルの監視の必要性について考えていきます。全3回を予定しています。今回はその最初の回です。データの集計処理に不具合が発生してしまい、すべてのユーザーのログイン回数が0となってしまった場合に発生する事象について、ケーススタディとして見ていきます。
今回の要旨
- 機械学習を本番環境で用いる場合、モデルに投入するデータが壊れると結果が壊れる
- 機械学習モデルの精度指標を監視するだけでは不十分なことがある
- データの型だけではなく、欠損を表す値の割合や値の分布の変化についても監視が必要
はじめに
機械学習については取り組みやすくなってきたと思います。実際、深層学習ライブラリの発展やその周辺のエコシステムの発展により、機械学習モデルを動かすこと自体は容易になってきました。さらには各種クラウドサービスプロバイダーからも機械学習のためのサービスが出てきており、環境構築も容易になってきています。
このためか、機械学習の机上実験や PoC を終え、本番環境での利用に取り組むチームも増えてきました。一方、機械学習モデルを本番適用する際の課題について、どのようなものがあるのか広く知られているとは言い難い状況であると考えます。
それぞれの組織で直面する課題はさまざまにあると思います。一方、直面した課題は一般的なのか、どのような課題が他にあるのかについて思い悩むことは少なくないのではないでしょうか。
このため、本ブログでは機械学習を本番環境で用いる際に直面する課題について共有していきたいと思います。
主旨
この記事では本番環境で機械学習システムが壊れてしまう例について、できるだけ具体的なケーススタディを述べます。この記事では数式は出てきませんが、次の前提知識が必要です。
- Web システムについての一般的な知識
- 機械学習に関する基本的な知識
機械学習については、訓練や推論といった概念の理解は前提としますが、アルゴリズムについての詳細な知識は必要ありません。
前提: EC サイトのマーケティングキャンペーン
今回のケーススタディで用いる機械学習タスクの前提条件を述べます。
背景
今回は架空の EC サイトを対象とします。このサイトは立ち上げに成功し、固定客がついています。そこで、マーケティングキャンペーンの効率化について機械学習で取り組むことになりました。私たちはその案件の担当者です。
私達はまず、机上検証を行うことにしました。
机上検証
精度検証の実施時期は、ターゲットを5月頭と決めて推進することになりました。
まずは目的を明確にします。マーケティング担当者と議論し「有望な見込み客を月初に特定してマーケティングキャンペーンを行いたい」ということがわかりました。このため、機械学習を用いて「ユーザーの行動履歴から、商品を購入しそうな顧客のリスト」を作成することにしました。
次に、機械学習モデルが利用するデータの詳細を決めます。分析の結果、ユーザーはおおよそ1ヶ月に1回の間隔で商品を購入していることがわかりました。このため、機械学習のタスクを「前月の行動履歴から翌月の購入回数を予測する」と設定しました。
行動履歴は、ユーザーの行った次の行動の回数を集計したものとしました。
- ログイン
- 販売品の閲覧
- カート追加
- 購入
それぞれの行動の回数は、 Web サイトのボタンを押したときにサーバーに送信されるログからイベント名 (ログインなら user_login という文字列) の数をユーザー ID ごとに集計することで取得します。集計結果は次のようになります。
機械学習モデルは訓練データを用いて、翌月の購入回数と id 列以外のカラム (ログイン、販売品の閲覧、カート追加、購入) の間の関係を覚えます。訓練データには3月の行動履歴と4月の購買回数を用いることにしました。
訓練済みの機械学習モデルは、4月の行動履歴から5月の購入回数の予測値を推論します。推論した翌月の購入回数について降順にソートしたものを見込み客リストとします。
評価では、モデルが推論した5月の購入回数と、実際の購入回数を比較することにしました。精度指標には、R2 score などの典型的な指標を採用しました。
評価結果
精度評価の結果、満足のいく精度が得られたことがわかりました。また、他部署に結果を紹介したところ非常に興味を持たれました。
次のステップは PoC として 6 月頭に見込み客リストに基づくマーケティングキャンペーンを行い、実世界での効果検証を行うことです。
ケーススタディ すべてのユーザーのログイン回数が0
ここから、機械学習モデルが意図しない動作をしてしまった架空の例について、ケーススタディとして述べていきます。
問題発生
7月、マーケティング部署から問い合わせがありました。聞いてみると、6月頭に行った見込み客リストに基づくキャンペーンについて、意図した成果が得られていないとのことでした。
私たちは案件の担当者として、原因をなんとか突き止め、報告しなければいけません。
発生した事象
EC サイト担当のエンジニアの力を借りてデータやログを確認したところ、次の事実がわかりました。
- 6月のモデルの推論結果について、精度を確認してみると異常に悪化していた
- システムログを確認してみたものの、エラーが発生している様子はない
- 6月の月初に収集した5月の行動履歴を見てみると、ほぼ全てのユーザーについてログイン回数が0になっていた
このことから、訓練用データで用いた 3 月の行動履歴と 5 月の行動履歴のデータが著しく異なっており、これまで学習したことのないデータをモデルに入力したため、モデルの精度が著しく低下したことが直接的な原因だと結論づけました。
さらに原因を深堀りするため、EC サイトの開発を行っているエンジニアにヒアリングしたところ、モバイル用とデスクトップ用で別々にログイン回数を集計する変更が5月頭にデプロイされていたことがわかりました。
この際に、サーバーに送信されるイベント名が、モバイル用とデスクトップ用でそれぞれ別の名前 (user_login_from_mobile, user_login_from_pc) に変更されたことも判明しました。ユーザーのログイン回数が0回となってしまっていたのは、6月初の集計処理で元のイベント名 (user_login) を集計したためでした。
原因
今回の事象にはさまざまな原因がありますが、次の4つが原因としてあげられるでしょう。
- 他チームの行った変更に対応できていない
- データの欠損について気がつけていない
- モデルの異常に気がつくのが遅れた
- 適用範囲を急拡大し問題が大きくなった
他チームの行った変更に対応できていない
今回のケースでは EC サイトは別のチームが開発を行っており、機械学習モデルを使うチームとは別のチームでした。このような体制になっていることは珍しくありません。
一般的に、機械学習に必要なデータの集計処理はシステムの幅広い範疇に依存します。また、本番サービスとは独立したサービスになりやすく、本番サービスでの変更に追随できないことも起こりえます。このため、それぞれのシステムの依存関係の管理と、システム変更時の連絡体制の構築が必要になります。
データの欠損について気がつけていない
今回はユーザーの行動履歴を集計して利用していました。この際に、もしログイン回数の 0 の出現割合が 100% に近くなっていることを検知できたら問題は防げたでしょう。
データの型による検証では不十分なこともあります。今回のケースでは、ログからイベント名を検索して件数を取得していたため、欠損は NULL ではなく 0 件として扱われます。データの型として int を用いていた場合、これは妥当な値です。NULL が出現しないかだけではなく、欠損として扱われるデータの件数や割合を監視することも重要です。
今回のケース以外にも、たとえば大規模なマーケティングキャンペーンを行った場合にはデータの分布が変化し、機械学習モデルの品質は劣化します。欠損以外にもデータの統計量や分布を把握し、監視する必要があります。
モデルの異常に気がつくのが遅れた
今回、モデルの推論結果の精度が悪化したことに基づいて異常と判断していました。しかし、精度を測るためには、実際の購入回数を集計するために1ヶ月待たなければいけません。
もし、入力データの監視を行っていればユーザーにキャンペーンを行う前に問題についてわかったはずです。キャンペーンの実行にコストがかかるケースにおいて、キャンペーンの実行前に異常がわかることは非常に大事です。
適用範囲を急拡大し問題が大きくなった
今回発生した問題について、より影響を小さく抑えることはできなかったのでしょうか。
今回のケースでは、見込み客リストについて全ユーザーを対象として作成し、マーケティングキャンペーンを行っていました。しかし、いきなり全ユーザーを対象とするのではなく、A/B テストを行う、カナリアリリースを行うといった方法で、影響範囲を小さくできないか検討すべきです。
まとめ
今回は機械学習モデルに投入されるデータに変更が発生し、機械学習モデルが壊れてしまった例について具体的に見ました。今回のケースに近い状況に、筆者も遭遇したことがあります。従来の監視項目に加えて、データそのものについての監視も必要だということを痛感した事例でした。
また「システム変更時の連絡体制の構築」といった、組織的な側面についても触れました。これは、この分野 MLOps が文化的なものであって特定のツールについてのものではないといわれる理由だと考えます。
次回予告
次回は、データの監視を行っていた際に何らかの異常を検出した際の対応について検討します。
