|
H. K. 日本アイ・ビー・エム株式会社 テクノロジー事業本部 データ・AI・オートメーション事業部 Data And AI第一テクニカル・セールス |
Data And AIテクニカル・セールスとして、SPSS® ModelerやCollaboration And Deployment Services、Watson® Studioを用いた機械学習の業務活用を支援。 |
機械学習モデル運用のコンセプトであるMLOpsには、通常のアプリケーション運用との大きな違いとして、モデルが劣化しうるという特徴があります[1]。例えば、元々25歳以上の反応がよかったキャンペーンが、時間の経過とともに25歳未満の反応がよくなっていた場合、元々作成したモデルの性能は劣化します。
こういう時にMLOps製品を導入すれば、自動でモデルが更新されて自動運用できると思われることも多いのですが、これは完全な幻想です。
実は、モデル自体によって学習データが影響を受けてしまうという根本的な問題があることが見過ごされていることが多く、モデルによって影響をうけたデータで自動再学習を行うと極端に性能の悪いモデルが運用されかねないのです。
本稿では、まずMLOpsの全体像を再確認した上で、MLOpsをつかった、失敗しない実践的な運用について考えていきます。
第1章 MLOpsとは
MLOpsとは機械学習(Machine Learning)モデルを開発、業務適用、運用していく一連の流れを統合的に考えるコンセプトです。
このMLOpsを実現するためのソフトウェアは、様々なプログラム部品やモデルを管理する①プログラム管理レポジトリと、その部品を組み合わせた②パイプラインの機能を持っています。
図1.MLOPSを実現するソフトウェアの構成
パイプラインにはモデル作成や、業務適用をするスコアリングのほかにも、モデルの劣化を検知するモニタリングやモデルを再作成するモデルリフレッシュという運用フェーズで使うパイプラインもあります。
第2章 モデルのモニタリングやリフレッシュのために必要なフィードバック・データ
モニタリングやモデルリフレッシュのためにはフィードバック・データが必要です。フィードバック・データとは運用開始後の結果データです。説明変数と反応結果としての目的変数の組合せになります。年齢や性別という説明変数からキャンペーン反応を予測するモデルを作る場合以下のようなデータになります。
図2. フィードバック・データ例
そしてこのフィードバック・データをつかって、モニタリング・パイプラインで予測した結果と実際の結果を比較します。以下の例だとキャンペーン反応(実測)と$R-キャンペーン反応(予測)が一致していれば予測は当たったことになりますし、異なっていれば外れたことになります。
図3. 予実比較の評価例
このようにモデルの予実比較をして性能が下がっていないかを検知するのがモニタリングです。元々25歳以上の人の反応がよかったキャンペーンが、時間の経過とともに25歳未満の人の反応がよくなっていたというようなことがあれば、25歳以上の人の反応がよいことを予測していたモデルの性能劣化が検知できます。
モデルリフレッシュ・パイプラインはこのフィードバック・データを使って、モデルを再作成するパイプラインです。最新のフィードバック・データをつかうことで、先の例のような25歳未満の人の反応が良くなっているデータが増えていたなら、25歳未満の人の反応がよいという予測モデルができることになります。
このようにモデルのモニタリングやリフレッシュという運用フェーズではフィードバック・データが重要な役割を果たします。
第3章 MLOps実装上の注意
MLOpsのソフトウェアを導入して、フィードバック・データさえ用意すれば、自動的に新しいモデルを作り直して、最新の精度の高いモデルで自動運用をできるという期待を持ってしまいがちですが、そう簡単にはいきません。この章では特にフィードバック・データの観点からMLOpsの実装上の注意について考えていきます。
3-1 モデルの影響を受けていないフィードバック・データの重要性
フィードバック・データは、原則としてはモデルの影響をうけていないデータであるべきです。モデルの影響を受けていないデータのことをコントロール・グループ(統制群)と呼びます。モデルの影響をうけたデータでは、その影響を受けた範囲での評価は可能ですが、モデルが切り捨ててしまった範囲の評価ができなくなります。モデルによってフィードバック・データが影響をうけてしまうのです。
例えば、女性で25歳以上がキャンペーンに反応しやすいので、女性で25歳未満の人にはキャンペーンを打たなかったとすると、その施策を実施した後のフィードバック・データには「女性で25歳未満」の情報がまったく含まれません。このデータでモデルをモニタリングして、評価しても「女性で25歳未満」の反応率が高くなっていても気づけません。
図4. モデルの影響を受けたフィードバック・データによる評価例
さらに、モデルの影響をうけたフィードバック・データをつかってモデルを再作成すると、もっと致命的な問題も起こりえます。
たとえば女性用化粧品のキャンペーンをするモデルを想定します。初期モデルの結果から「男性」にはほとんど売れていなかったのでキャンペーンをうたなかったとすると、その施策を実施した後のフィードバック・データには「男性」の情報がまったく含まれません。このフィードバック・データで新モデルを作り直すと「性別」は購入に影響をあたえないファクターとしてモデルが作り直されてしまいます。つまり次のモデルでは「男性」がキャンペーン対象になります。さらにこのモデルが運用されると、次回のフィードバック・データには男性には売れなかったというデータが含まれますので。次回の新モデルは「男性」にはキャンペーンを打たないモデルが出来上がります。男性に送るモデルと送らないモデルがシーソーのように繰り返し作られることになります。
図5. モデルの影響を受けたフィードバック・データによるモデル再作成例
こういう問題はキャンペーンのようなデータ傾向が頻繁に変わる業務だけではなく、比較的データ傾向の安定した設備の故障予測などでも起こりえます。例えば温度が100度以上だと壊れる確率が高いというモデルができて運用され、結果として100度以上での運用が発生しないために、100度以上での故障が発生していないフィードバック・データができれば、次には100度以上での故障を予測しないモデルができてしまい、100度以上での故障が発生するようになります。
これを避けるためには、モデル影響を受けていないコントロール・グループが必要になります。キャンペーンの話なら、モデルの予測結果とは関係なく、無作為に数パーセントのデータにはキャンペーンを発送していれば25歳未満の反応データが収集できます。このモデルの影響を受けていない結果をフィードバック・データとしてモニタリングやモデルのリフレッシュにつかうのが望ましいということになります。
図6:モデルの影響を受けたフィードバック・データとコントロール・グループとして用意したフィードバック・データの違い
コントロール・グループを確保するために、実業務にメリットのないデータを含めて広範囲に取得するということは、予測を無視して、みすみすコストを増やしてしまったり、販売機会を逸してしまったりすることも意味します。しかし、これは正しく評価を行い、継続的にモデルの品質を保つために必要なコストであると基本的には考えるべきです。
しかしながら、めったに発生しないことを予測する場合(めったに発生しないコンバージョンや故障などの予測)には、評価に十分な分量のコントロール・グループを集めることが困難な場合があります。また、キャンペーンでコストが増えるだけなら許容できるかもしれませんが、詐欺の検知や、高価な装置故障予測、人命にかかわる予測などだとコントロール・グループを用意することは非常に困難になります。例えば、無作為に選んだ装置では、故障が予測される条件でも高額な装置を稼働させてコントロール・グループをつくるということです。こういう予測を無視することはコストが大きすぎます。
このようにコントロール・グループを用意することが困難な場合は、モデルからわかったルールを一部固定化して永続的なビジネスルールとしてしまうという対応方法が考えられます。化粧品キャンペーンの例でいえば、あらかじめ女性のみに限定するということが考えられます。設備の故障予測であれば、温度が100度以上のリスクが非常に高いことがわかっていれば、100度以上では常に異常のアラートをあげるようにするということです。
なお、フィードバック・データがモデルの影響を受けないようなモデルの場合は、基本的にはこれらの懸念はありません。例えば需要予測モデルは、予測結果によって需要自体を変えることがないので、特にコントロール・グループについて考える必要はありません(というよりも、そもそもコントロール・グループを作ることができません)。ただし、需要予測の結果に合わせて供給を調整した結果として、欠品が発生した場合にはフィードバック・データは影響を受けてしまい、本当の需要(潜在的需要)は分からなくなります。こういうデータをどう扱うかは業務担当者と考える必要があります。
3-2. フィードバック・データ自体が外れ値の場合の対応
また、コントロール・グループがあっても毎回それをつかってモデルを再作成してよいとは言えないこともあります。それは外れ値の発生をとらえきれないことがあるからです。
たとえば特価販売、増税減税、大規模広告、災害、異常気象、オリンピックなどの一時的なイベントなどがあるとその期間のデータを基にしたモデルは、そのイベントに引きずられたモデルになります。そしてそのモデルでイベント終了後の予測をするとあたりの悪いモデルになってしまう可能性があります。
設備の故障予測などでも、一時的にサプライヤーや原材料が変わっていることがあると稼働特性が変わっていることもあり得ます。
逆に永続的な革新的な変化が起こっていることもあり得ます。各種規制やその緩和や自動運転などのイノベーション、競合の出現などです。こういう場合は古いモデルや古いデータはむしろ切り捨てたほうがよいこともあります。
このような外れ値や革新的変化は学習データやフィードバック・データに表現されていないことが多くあります。手元にあるデータが予測対象の事象を十分に説明できていない可能性があるということはいつも念頭に置いておくべきです。
第4章 まとめ
機械学習モデルやAIは自動で判断をして、自動的に再学習して賢くなっていくことが期待されますが、それはあくまでも機械学習モデルやAIに与えた学習データやフィードバック・データに依存しています。フィードバック・データに含まれていない情報や例外的状況で含まれてしまった情報がありうることを意識したうえで、それぞれの業務特性、データ特性にあわせた実践的なモデルの運用を行うことが重要になります。
[参考文書]
[1] なぜMLOpsが必要なのか https://community.ibm.com/community/user/japan/blogs/provision-ibm1/2021/08/17/vol97-0014-ai
*ProVISION 記事一覧はこちらから
IBM、IBMロゴ、SPSS®、Watson® Studio は、米国やその他の国におけるInternational Business Machines Corporationの商標または登録商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストについては、ibm.com/trademarkをご覧ください。
#AI
#ProVISION
#Highlights
#Highlights-home
#ProVision
#ProVision-AI