背景
この記事は前回の続きとなっています。データの監視の必要性については第1回を、前提となる基礎知識や登場人物については第2回を参照ください。
前回の記事では、推論用データの 1 件のみから検出可能な事象とその対応について見てきました。今回の記事ではデータセット全体を見て検出可能な事象とその対応について検討します。
まとめ
- 推論用データセットの監視には統計量 (平均値、中央値、パーセンタイル値) や欠損を表す値の割合が用いられる
- 訓練用データセットと推論用データセットとの距離を計算することで、データセットの変化を検出できる
- 運用に組み込む際にはチームや目的に応じて採用する手法を選定することが必要
データセット全体を見て検出可能な事象
機械学習においてデータセットは推論用のデータセットと学習用のデータセットに分類できます。この記事では本番環境での事象について取り扱うため、学習用のデータセットだけから判定できる事象以外の 2 つについて見ていきます。
- 推論用データセットのみで検出可能なケース
- 推論用データセットと学習用データセットを用いて検出可能なケース
まずは推論用のデータセットだけから検出可能な事象について検討します。その後、推論用と学習用の両方のデータセットを用いて検出可能な事象について検討します。
今回は正解ラベルを用いたモデルの性能監視については深く立ち入りません。正解ラベルを用いた性能監視は重要ですが、手に入るまでには時間がかかるケースがあります。
たとえば、次のようなケースでは正解ラベルが手に入るまでには時間がかかります。
- 結果を得るまでに時間がかかるケース ( 例: 金融機関で与信のために機械学習でスコア付)
- 正解ラベルの付与には人手で作業が必要なケース (例: 手書き文字認識を行うケース)
- ユーザーの入力のクレンジングに時間がかかるケース (例: チャットボット)
このようなケースでは精度指標を得るまでに数週間から数ヶ月かかることがあります。その間に入力データの監視を行わない場合に生じうる事象について、第1回でケーススタディとして見てきました。
そのため、ここでは正解ラベル以外のデータを用いた監視について検討します。
推論用データセットのみから検出
推論用データセットのみから異常を検出できるケースには次のものが挙げられます。
- 特定の値の割合が異常に大きくなる
- 特徴量の値の分布が急激に変化する
たとえば、ユーザーの情報において、EC サイトの特定のページの閲覧回数が 0 になっているユーザーが急激に増加したり、登録日からの経過日数が数日のみのユーザーが急激に増加する場合が該当します。
検出方法
このケースではモデルへの入力を適当な単位で分割したデータを作成し、特徴量の統計量を追跡することでデータの変化の傾向を確認すると良いでしょう。
たとえば、モデルの入力を日毎に分割したデータを作成し、それぞれの日毎に統計量を計算することが考えられます。統計量は次のものが考えられます。
- 平均値
- 中央値
- パーセンタイル値
また、欠損として扱われる値 (NULL, 0, 空白文字列など) があれば、その出現割合の監視も検討すると良いでしょう。
想定される原因
典型的に考えられる原因には次のものが挙げられます。
- システムのデプロイ時に混入したバグ
- 特徴量を生成するデータパイプラインの不備
- ビジネス的な環境の変化
特徴量を生成するデータパイプラインの不備では、欠損を表す値の割合が増えることが典型的です。
たとえば、システムのデプロイに起因する仕様変更が発生し、特定のカラムの更新がなされなくなった場合に、データパイプラインの実装が追随できていないとこのような事態が発生するでしょう。
また、それ以外にもビジネス的な環境の変化でこのような事象が発生することもあります。たとえば、大規模なマーケティングキャンペーンを行った結果、EC サイトに新規ユーザーが大量に流入した場合、登録日からの経過日数が小さなユーザーが急激に増加します。
新規ユーザーについては利用できる情報が少ないために、機械学習モデルの予測精度が低いことがあります。このような場合、全体として機械学習モデルの性能が低下することがあります。
想定される対処方法
対処方法には次のものが考えられます。
- デプロイの切り戻し (可能ならば)
- データパイプラインの更新
- 再学習して精度確認、問題なければデプロイ
データパイプラインの維持には想定外の労力がかかることがあります。今回のケースではデータパイプラインの入力源である EC サイトは開発チームが担当しており、データパイプラインの出力を利用する機械学習チームとは異なります。
このようにデータを利用する場合、複数の役割の異なるチームが連携する必要がある点には注意が必要です。
また、マーケティングキャンペーンが行われた場合のようにデータの傾向が変化した場合には、モデルの再学習と精度確認、再デプロイが必要になります。モデルのデプロイを行うための一連のタスクが属人化してしまうのを避けるため、自動化を検討すると良いでしょう。
再学習の判断のためには訓練用データセットとの比較が必要になります。これについては後ほど詳しく見ていきます。
注意点
データパイプラインの異常に対応するためには異なるチームが共同して動くことになります。このため、事前の運用体制の構築が必要です。
この際に、それぞれのチームは専門分野も価値観も異なるチームであることに注意しましょう。
まず、専門分野について考えます。開発チームは Web サービスの作成が得意ですが、機械学習チームは一般的に得意ではありません。
このような専門分野の差違を乗り越えチーム間の交流を行うためには、DevOps の取り組みが有効です。機械学習チームが運用業務を行ってみる、開発チームと機械学習タスクをペアプロしてみる、などの取り組みが有効でしょう。
次に、価値観についてですが、今回のケースでは開発チームの提供する EC サイトはエンドユーザーに価値を提供し、機械学習チームの提供する機械学習モデルはマーケティングチームに価値を提供します。
このようなケースではそれぞれのチームでの優先順位の付け方が異なるため、チーム間での調整も必要になります。このようなマネジメントの側面も必要になることは覚えておくと良いでしょう。
推論用と学習用のデータセットで検出
最後に、推論用と学習用の両方のデータセットを用いて検出するケースについて見ていきましょう。
これは先程述べたように、モデルの学習から時間がたっているために、実際の本番環境のデータの分布が学習時と大きく変わっているケースです。
機械学習モデルは学習用データと似たデータに対してはうまく働くことを期待できますが、学習用データとかけ離れたデータについてはうまく働くとは限りません。
このため、推論用に入力されたデータを収集し、学習用のデータセットと比較することが必要になります。
検出方法
推論用と学習用のデータセットを比較するために、さまざまな指標が利用できます。代表的な指標は次の 2 つのどちらかに属します。
- 分布の間の距離を測定する指標: KL ダイバージェンスなど
- 検定に用いられる指標: 各種の統計量や p 値など
より詳細なリストをこの記事の末尾に記します。このような指標を計算し、閾値を設定して監視することになるでしょう。また、ヒストグラムといったグラフを用いて可視化も検討すると良いでしょう。
考えられる原因
データの分布自体はさまざまな原因で変わります。今回の EC サイトの場合、典型的には次のようなものが考えられるでしょう。
- 大規模なマーケティングキャンペーンを行った結果、新規ユーザーが大量に流入しユーザーの分布が変わった
- サービスの成長に伴いユーザーの分布が変わった
これ以外にもさまざまな現実の事象が関係します。現実の変化がどのようにサービスに影響するのか、日頃から検討が必要となるでしょう。
対処方法
データの分布の変化を検知した場合、次のような対応が必要になるでしょう。
- 推論結果を目視確認し、ドメイン知識で判断
- 学習データ、テストデータの再作成と再学習
- モデルや前処理の見直し
まずはモデルにとって未知のデータについての振る舞いを確認するため、推論結果の確認が必要でしょう。この際、機械学習で取り組むような複雑な問題に対して自動的な判断は困難です。
このため、未知のデータの振る舞いの妥当性については目視で確認し、業務領域の専門家がドメイン知識で判断する必要があるでしょう。
また、新たなデータで学習することは対応の一つとして考えられるでしょう。このようなデータの変化は領域によっては頻繁に発生します。そのようなケースでは再学習のための一連のタスクを自動化しておく必要があります。
再学習しても所望の精度が得られないケースでは、機械学習モデルで用いているアルゴリズムや特徴量の見直しが必要になります。現状用いているモデルをベースラインとし、実験的な取り組みから始めることになるでしょう。
注意点
注意点として、このようなデータの分布の変化について、運用チームの行っているアラート対応フローへと安易に含めることはおすすめできません。対応のためにはデータサイエンスや機械学習に関するスキルが必要になるため、最低でも機械学習チームにスムーズに連絡がなされるようになっていると良いでしょう。
さいごに
今回のシリーズでは典型的なケースを用いて、運用体制の構築時に検討すべき事項について述べました。
実際に運用体制を検討する際には、自分たちのシステムに合わせた対応方法の検討が必要です。対応が必要な事象を洗い出し、その事象の発生を検知する方法とその際の対応方法を洗い出していくと良いでしょう。
一方、他組織で用いられている指標や手法をそっくり真似ることはおすすめできません。データの監視についてはさまざまな組織がさまざまな手法で取組を発表しています。それらを収集して検討をはじめると、対応が必要ない事項や対応不能な事項についても検討が必要になってしまいます。
データの監視は標準的な手法が提唱されていない分野です。自分たちの組織に合わせて、最小限対応すべき事項について洗い出すところから始めると良いでしょう。
今回のシリーズで述べた課題に対しては、データバリデーションと呼ばれる技術が用いられます。データバリデーションはデータベースや Web の入力フォームなどで古くからある取り組みですが、機械学習分野に適用されたのはここ数年です。さまざまな実装があるので各組織にあったものを試してみると良いでしょう。
また、データの監視について、今回述べていないことがまだまだあります。たとえば、次のような事項については今回触れられていません。
- ラベルデータの監視: モデルへの入力データだけを考えたものの、ラベルデータについての監視の検討も必要
- モデルの推論結果の監視
- バイアスの監視: ユーザー群全体に対する監視だけを考えたものの、実運用時には特定のユーザー群についてのモデルの振る舞いも監視する必要がある
これらについては別の記事で触れていこうと思います。
付録. データの比較に用いられる指標
推論用と学習用のデータセットを比較するためには次のような指標が利用できます。
分布間の距離を計測する方法
2つのデータセットを確率分布と捉えて、分布間の距離 (偽距離) を測定する際に用いる指標です。次のようなものがあります。
ほかにも Wikipedia にはさまざまな距離が列挙されています。利用する目的やチームに合わせて理解しやすく、運用を考えやすいものを選択すると良いでしょう。
分布間の距離を計測する方法
2つのデータセットが異なる分布に従っていないか、仮説検定の手法で確かめることもできます。その際には特徴量の型によって異なる検定を導入する必要があります。次のものは統計量としてよく知られたものです。
- KS(コルモゴロフ–スミルノフ)検定統計量 (数値)
- カイ二乗統計量 (カテゴリカル値)
ほかにも複雑なデータに対してはカーネルを導入し MMD (maximum mean discrepancy) を適用することもできるでしょう。MMD の詳細な解説はここでは避けますが、わかりやすい記事があるので参考になさってください。
