このシリーズでは本番環境でのモデルの監視の必要性について考えていきます。全 3 回のうち、今回は 2 回目の記事です。
背景
この記事は前回の続きとなっています。まだ前回の記事をご覧になっていない方はそちらからご覧ください。
機械学習を実用化するにあたり、データ自体の監視を行わない場合に陥ってしまう事象について私達は理解を深めました。そこで、私達はデータの監視について検討することにしました。
まとめ
- 1件の推論用データから検出できる異常には、単一の特徴量から検出できるものと複数の特徴量を総合的に検出するべきものがある
- 単一の特徴量から検出できる異常には素早く対応すべきものが含まれるため、開発者と機械学習チームの共同が必要
- 複数の特徴量から検出できる異常はすぐには原因がわからないものが含まれるため、システムのエラーとは分けて扱うことが必要
登場人物
データの監視を行うに当たり、今回は次の3つのチームの動き方について考えていきます。
- 機械学習チーム: マーケティングチームに見込み客リストを社内に提供することが主なミッション
- 開発チーム: EC サイトの開発が主なミッション
- 運用チーム: インフラ管理や監視が主なミッション
機械学習チームはマーケティングチームに見込み客リストを社内に提供することが現在の主なミッションです。運営している EC サイトで収集したデータから機械学習を用いて見込み客リストを作成します。
開発チームは EC サイトの開発が主なミッションです。マーケティング部門の要望を聞いて新たなマーケティング施策をサイト上に実装したり、他のシステムとの連携を実装したりします。
運用チームはインフラやその上で動くアプリケーションの管理や監視が主なミッションです。開発チームの作成した EC サイトは運用チームの提供するインフラの上で動いています。
前提
今回の記事では機械学習の一般的なコンポーネントについては解説しません。コンポーネントの詳細については、たとえば MLOps: Continuous delivery and automation pipelines in machine learning をごらんください。
今回の記事では次の前提をおいています。
- EC サイトではすでに開発チームと運用チームによる監視が行われ、異常発生時にはアラート対応が行われている
- 機械学習システムは EC サイトとは独立に動いており、機械学習システムが落ちても EC サイトや基幹システムには影響しない
- EC サイトから収集したデータを機械学習システムでは用いているため、EC サイトに不具合が発生すると機械学習システムの動作に影響する
これらの前提の上で、データの監視について検討していきましょう。
記事の構成
以降の記事では、次のような構成を取ります。
- それぞれのケースに該当する異常なデータの具体例
- 検出方法: データの異常を検出するための手法や観点
- 想定される原因: そのような事象を発生させうる原因の例
- 想定される対処方法: 想定される原因への対処方法の例
- 注意点: 異常への対応を行うにあたっての注意点
また、データの異常への対応として、アラート対応のようなワークフローを想定して記述しています。具体的には、事象を検出し、どの異常に該当するのか判定して、原因の切り分けを行い、対処を検討し実行するといったワークフローです。
検討するケース
このシリーズではは4つのケースについて、データの監視を検討します。
最初の2つのケースは1件の推論用データのみから検出できるものです。ここでは次の2つを考えます。
- 単一の特徴量のみで検出可能なケース
- 複数の特徴量の組み合わせで検出可能なケース
単一の特徴量のみで異常を検出するケースは比較的単純ですが、より即応性が求められる場合があります。
一方、複数の特徴量の組み合わせで異常を検出するケースではその後の対応で複雑な判断を求められる場合があり、解決に時間がかかることもあります。このため、この2つを分けて考えます。
次の2つのケースは1件の推論用データだけではなく、データセット全体を見て検出するものです。
- 推論用データセットのみで検出可能なケース
- 推論用データセットと学習用データセットを用いて検出可能なケース
ここでは学習用データセットの有無でケースを分けて考えています。これらのケースについては次回の記事で触れていきます。
1. 単一の特徴量
単一の特徴量のみで異常を検出できるケースには次のものが挙げられます。
- 欠損すべきでない値が欠損する
- 正の値のみが入力されるべき箇所に負の値が入力される
- 異常に大きな値が入力される
- 今までになかった文字列が入力される
たとえば、ユーザーの情報において、EC サイトへの登録日からの経過日数に -1 が入力されていたり以上に大きい値 (100年など) が入っている場合が該当します。
検出方法
このケースでは、モデルに入力するデータのスキーマを定義し、スキーマに違反するデータがないか監視すると良いでしょう。スキーマには典型的に次の情報を含めます。
- 値の型 (int, float, string, etc.)
- 欠損の有無
- 値域
値域については次のものが挙げられます。
- 数値型であれば最大値、最小値
- カテゴリカルな値であれば、許容可能な値の一覧やパターン (例: “YYYY-MM-DD”)
スキーマに違反するデータが検知された場合、アラートをあげて対応することになるでしょう。
想定される原因
このような事象について、典型的には次のような原因が考えられます。
- ユーザーの誤入力
- EC サイトのアイテムに新しいカテゴリを追加
- システムのデプロイ時に混入したバグ
想定される対処方法
それぞれの対処方法について考えてみましょう。
ユーザーの誤入力については、ユーザーの入力値に対するバリデーションの実装が考えられます。多くの Web 入力フォームで行っていることが対処方法として有用でしょう。
EC サイトのアイテムに新しいカテゴリが追加されるのは通常のことですが、新しいカテゴリが追加された場合に機械学習の予測性能が下がることもよくある事象です。このような場合には学習データとテストデータを作成し直し、モデルを再度訓練してデプロイするといったことが必要でしょう。
システムのデプロイ時には入念な準備が前もって行われますが、誤った設定やバグがデプロイされてしまうことはどうしても起こりえます。このような場合には、影響範囲や緊急性、重要度について素早く判断し、対応する必要があります。多くの場合、デプロイ前の状態への切り戻しや、暫定対応としての修正を hotfix としてデプロイすることが必要になります。
関係者
ユーザーの誤入力を防止するバリデーションルールの追加については、開発チームが主に対応することとなるでしょう。対応の際にはデータのバリデーションは UI だけではなくバックエンドでも必要になる点には注意しましょう。また、入力値のバリデーションを行うルールの作成には、機械学習チームが支援できるでしょう。
新しいカテゴリの追加への対応に必要な学習データの作り直し、再学習については、機械学習チームが主に対応することとなるでしょう。
システムのデプロイ時に混入したバグへの対応のためには、開発チームと運用チームが連携して対応する必要があるでしょう。
注意事項
このケースでは異なるチームが異なる緊急度で対応している点に注意が必要です。
今回の場合、機械学習モデルは EC サイトとは独立して動いており、機械学習チームの行う対応はそこまで緊急度は高くありません。一方、バグ対応は緊急対応をすばやく要求される場合が含まれます。これは大きなストレスにさらされる過酷な業務です。
これらの2つの対応は性質が違うため、単一のワークフローで対応するのは望ましくありません。機械学習システムから切り戻しや hotfix といった暫定対応のためのワークフローにアラートをあげるべきか、業務要件から慎重に判断すべきでしょう。
今回のケースにおいて、 EC サイトで用いている RDBMS への入力値に異常が認められた場合と、機械学習システムの ETL 処理において異常が認められた場合には対応すべき速度が異なります。この2つの事象を切り分けられるようにログに情報を含め、アラートを適切なチームに伝達できるよう考慮が必要です。
またアラートには原因となった事象ができるだけわかるような情報を含めることも必要でしょう。
2. 複数の特徴量の組み合わせ
次に、複数の特徴量の組み合わせで発生するケースを考えます。
これはそれぞれの特徴量はスキーマにしたがっているものの、それぞれの組み合わせを考えると異常なデータが入力された場合が該当します。
たとえば、ユーザーの属性情報として 170 cm 60 kg で 8 歳という情報が与えられた場合、個々の属性情報は正常な値ですが全体としては不自然です。今回はこのような特徴量を組み合わせてわかる異常について検討します。
外れ値は複数の特徴量の組み合わせで発生するケースのひとつです。外れ値の監視はモデルの振る舞いを担保する上でも重要です。
外れ値は発生することが稀なため、学習データに極めて稀にしか含まれていないか、あるいはまったく含まれていないこともあるでしょう。このため、モデルが外れ値をうまく学習できていない可能性があり、考慮が必要になります。
検出方法
このような特徴量を組み合わせて異常を検出することは、単一の特徴量での検出と比較して難しくなります。
真っ先に思いつくのが人手による全件目視ですが、できるだけ避けるべきでしょう。機械学習で用いるデータでは特徴量の数が数百に渡ることもあり、人の手には負えません。できるだけ自動的な検出が望ましいです。
検出には次のような方法が考えられるでしょう。
- ルールベースでの検出
- 異常検知などのアルゴリズムによる検出
ルールベースでの検出では、論理的にありえない値の組み合わせを事前に検討し、検出します。事前にデータについて十分知識を得ておくことが必要です。
異常検知などのアルゴリズムによる検出では、意図した異常が意図通りに得られているか事前の検証が必要でしょう。
また、どうしても偽陽性が避けられないため、1件だけで判断するのではなく、異常なデータが何件かまとまって発生したことを検知するのが望ましいでしょう。
想定される原因
原因を想定することも単一の特徴量で発生する場合に比べて困難です。次のような事象は原因として考えられるでしょう。
- ユーザーの誤入力
- 何らかのまれな事象の発生 (あるいは、学習データの不足)
- システムのデプロイ時に混入したバグ
これ以外に想定できるものがないか、業務知識を用いて事前に洗い出すとよいでしょう。
対処方法
対処方法もケースバイケースでさまざまなものがありえます。製造業が物品を抜き出して検査するように、異常な組み合わせが検知された場合にはユーザーの入力について追加の確認を行うことも考えられます。
まず、ルールベースで検出した場合は、事前の検討結果が活用できるでしょう。検出する内容によってはその後の対応について、自動化の余地が見つかるかもしれません。
このような検討は機械学習モデルの出力を即時でビジネス判断に利用する場合に特に有用でしょう。
一方、異常検知などのアルゴリズムで検出した異常については人手での原因分析とその後の対応が必要になるでしょう。
今回のように、緊急度の高くない月次処理を対象とした機械学習モデルの場合は、異常として検出したデータについて、ドメイン知識を元に改めて人手で判断することが考えられます。機械学習の判断根拠を SHAP などの手法を用いて可視化し、モデルの判断根拠と推論結果が妥当かどうか判断することもできるでしょう。
注意点
異常検知などのアルゴリズムにより検出した異常への対応について、どのチームがアラートを受け取るか事前の検討が大切です。
多くのケースにおいて適切なのは機械学習チームとなるでしょう。一方、機械学習に長けた人材であってもアラート対応について長けているとは限りません。対応フローの事前の検討や、異常発生時の対応のトレーニングを提供すべきでしょう。
また、異常検知などのアルゴリズムにより検出した異常への対応について、開発チームと運用チームによるアラート対応フローに含めることはおすすめできません。異常検知などのアルゴリズムにより異常を検出した場合の対応は、システムにエラーが発生した場合の対応とは異なります。
アルゴリズムにより検知した異常を、システムのエラーと同等に扱ってアラートを挙げてしまうと、現場に即座に対応するように過度のプレッシャーを与えてしまいます。これが続くと、現場ではアラートを無視するような設定が投入されてしまい、異常検知のアルゴリズムを組み込んでも機能しなくなってしまいます。
このようなことを防ぐために、異常検知などのアルゴリズムを用いる際には、検知した異常が正しい人に正しく届くように使うことが大切です。
そのためにも、アラートに次に何をすべきか判断できるだけの情報を含められないか、あるいは別のワークフローで対処できないかといった事項について、業務要件に照らし合わせた検討が必要です。
次回
最終回となる次回では、推論用のデータセット全体を見る必要があるケースについて検討します。
