メモ:Using AntiPatterns to avoid MLOps Mistakes

論文
https://arxiv.org/pdf/2107.00079.pdf

概要

金融分野でのMLOpsアンチパターンをまとめた論文。
技術的な課題もあればMLの結果を使っている周辺のコンテキストが十分な知識を有していなかったことが原因となっている。
これらの状況を議論するに当たり共通のボキャブラリーを提供することで、ステークホルダー間の素早いコミュニケーション並びにより素早く問題を解決する。

ここでは9つのアンチパターンについて取り上げる。
f:id:A_Koide0519:20210810224536p:plain

アンチパターン

Data Leakage AntiPattern

データリークはモデルが本来持っていない、あるいはモデル生成時には利用できないデータを利用してしまうこと。
モデル作成時にモデルを過大評価してしまう可能性があり、そのまま本番提供すると想定よりも性能が全然出ないということが起こりする。
システムやデータの複雑さが時間的な依存を隠してしまいがち。

ユーザーの行動履歴をembeddingしたものを使ったりするとこういう問題が発生しそうな感じがする。

Peek-a-Boo AntiPattern

データが実際に取得できるまでタイムラグが有る場合がある。
例えば、月の労働時間は当該月が終わって次の月にならないとわからない情報。
モデラーがこのデータの日付と実際にデータを受け取れる日付の違いを理解しないと想定しないデータをモデルに含めてしまうかも。

Temporal Leakage AntiPattern

レーニングとテストのデータセット分割の際に、サンプリングの方法を誤ってしまうとリークが発生する。
特に予測問題では、連続性があるデータの分割の仕方を誤るとリークが起こってしまう可能性がある。

Oversampling Leakage AntiPattern.

不均衡データにおいてOverSamplingはよく用いられる手法だが、TrainとTestの前にOverSamplingを実施してしまうとリークが発生する可能性がある。銀行の解約予測を事例にリークが起きていることを説明する。
f:id:A_Koide0519:20210812195057p:plain

この図を見ると(a)の方のOverSamplingしたあとにデータを分割した方は楽観的な性能を示しているが、これはOversamplingのタイミングがTestデータを作る前に行われたことが原因であると考えられる。

Metrics-from-Beyond AntiPattern

データの前処理の段階でTrainデータとTestデータを合わせて正規化などをしてしまうことにより、Testデータの統計的な性質がリークしてしまう可能性がある。

‘Act Now, Reflect Never’ AntiPattern

一度モデルが本番にDeployされると、予測はフィルタリング、更新、反映、定期的な調査も行われないまま現状維持で利用されることがある。
こういったことがコンセプトドリフト、誤った予測結果の提供、敵対的攻撃を引き起こしてしまう。
※コンセプトドリフト:入力データと予測結果の関係が変化した状態. 古いデータに基づいて構築されたモデルが新しいデータと矛盾した状態.
デプロイしたモデルに対してのモニタリングやデバックの仕組みを用意する必要がある。

Tuning-under-the-Carpet AntiPattern

ハイパーパラメータはモデルのパフォーマンスにおいて重要な役割を果たす。実際の例として退会予測のタスクにおいてXGBのハイパラチューニングをした結果としない結果を示す。
f:id:A_Koide0519:20210813165259p:plain
F1スコアが3.5%程度改善していることからも、チューニングは重要であることがわかる。
ハイパーパラメータの最適化に関わる学習パイプラインの部分は、再現性があり容易に適応できるように、明示的かつ丹念に文書化することが必要。

‘PEST’ AntiPattern

新しいML分野の研究が提案される時、主要なコントリビューションは下記に寄って示される。
i)これまで検証されていなかった理論的提案
ii)新しい理論的な提案と経験的な検証の組み合わせ
iii)既存の学習パイプラインを効果的に補強し、パフォーマンスを向上される
経験的検証を行うには、提案手法を過去のアプローチと比較して公正に評価し経験的な性能を評価する必要がある。しかし新たに提案されたML手法の経験的な検証が不十分であったり、欠陥があったり、あるいは期待外れであったりすることはよくある。
こういったケースでは、報告された経験的な利益は経験的優位性の認識 (PEST) antipatternが発生しているということになる。
対策として、まずはシンプルなモデルでBaselineを作ってそこからより高度なモデルの調査をしていく、あるいはSQuADのようなベンチマークのデータセットに対してモデルを検証するパイプラインを構築するといったことが挙げられる。

個人的にこの話で思い出すのはRecSys2019のBestPaperだった下記の論文。
https://arxiv.org/pdf/1907.06902.pdf

Bad Credit Assignment AntiPattern

モデルが改善したときに、MLパイプライン全体のどこに性能向上の要因があったのか特定できない問題が頻繁に起きる。
研究領域においては改善は新しいアーキテクチャによるものであると言われることが多いが、実際には巧妙な問題設定、データの前処理、ハイパラチューニング、既存ロジックを新しいタスクに適用したといったことで性能向上することがほとんど。
こういったことを防ぐために、ablation studyによって新しい学習モデルのどの部分に優位性があったのかを経験的な評価の中に含める必要がある。

Grade-your-own-Exam AntiPattern

ここの章はあまりよくわからなかったが...

モデリング潜在的な威力を探るために好奇心に駆られた反復作業から始まる。このタイミングでは3rd-partyからのレビューなどは必要ないが、この状況が長く続くと検証を行わず、検証されていない結果を他の方法と比較することができない。
これを避けるために、テストと評価のデータは独立してサンプリングされるべきで、堅牢なパフォーマンス分析のためには、モデル開発が完了するまで隠しておき、最終的な評価にのみ使用する必要がある。
実際には、サイエンティストが最終的なテストセットを入手し、このテストセットに対してテストを繰り返すことで、テストセットでのパフォーマンスを向上させるようにモデルを修正してしまう。
これは暗幕的なデータのリークに繋がり、パフォーマンス評価での過学習が選択バイアスにつながる。
これはHARKing「Hypothesizing After Results are Known」(結果が判明したあとに仮説を作る)と呼ばれている。

Set & Forget AntiPattern

モデルのトレーニングと推論にはSet and Forgetの考えが適用されることが主流となっている。しかし、モデルが予測するターゲットの統計的な特徴が時間とともに変化することが頻繁に発生する(concept drift)。
concept driftの対策方法については下記のサイトに良くまとまっていたので勉強になった。
recruit.gmo.jp

モデルをdailyなどで定期的にTrainingしている場合にはForgettingをしている状態と言って問題ないのだろうか。

‘Communicate with Ambivalence’ AntiPattern

モデル自身の不確実性に関する情報についてほとんど注意が払われていない状態。
校正されていないモデルを本番に投入すると、何かあったときに補償や改善のためのパイプラインを導入することが難しくなるので、Brier Score(またはそれに準ずるもの)で注意深くキャリブレーションされているモデルを投入する必要がある。

rindalog.blogspot.com

‘Data Crisis as a Service’ AntiPattern

データの抽出手順を記録せずに手動で抽出したデータを使ってモデルを開発すると、後々モデルを検証したり展開する際にデータの準備に非常に時間がかかる。
センシティブなデータなどで外部のデータ提供者がサニタイズしたりするとこういったことが起こりやすい。
対応として以下のようなものがあげられる。
・専門的なデータエンジニアリングプラクティスの用意
・パイプライン上移動するデータの追跡
・仲介業者を含むすべてのデータプロダクトの系統の追跡