Download to read offline
Uploaded by西岡 賢一郎
学習時に使ってはいないデータの混入「リーケージを避ける」
データマイニングや機械学習をやるときによく問題となる「リーケージ」を防ぐ方法について論じた論文「Leakage in Data Mining: Formulation, Detecting, and Avoidance」(Kaufman, Shachar, et al., ACM Transactions on Knowledge Discovery from Data (TKDD) 6.4 (2012): 1-21.)を解説します。 主な内容は以下のとおりです。 ・過去に起きたリーケージの事例の紹介 ・リーケージを防ぐための2つの考え方 ・リーケージの発見 ・リーケージの修正
![[DL輪読会]NVAE: A Deep Hierarchical Variational Autoencoder](https://cdn.slidesharecdn.com/ss_thumbnails/nvaeadeephierarchicalvariationalautoencoder-201113004930-thumbnail.jpg?width=640&height=640&fit=bounds)
![SSII2022 [TS1] Transformerの最前線〜 畳込みニューラルネットワークの先へ 〜](https://cdn.slidesharecdn.com/ss_thumbnails/ts120220608ssiitransformerr2-220607054025-3adacf07-thumbnail.jpg?width=640&height=640&fit=bounds)
![SSII2022 [SS2] 少ないデータやラベルを効率的に活用する機械学習技術 〜 足りない情報をどのように補うか？〜](https://cdn.slidesharecdn.com/ss_thumbnails/ss2ssii2022-220607054716-2760bd30-thumbnail.jpg?width=640&height=640&fit=bounds)
![SSII2022 [OS3-02] Federated Learningの基礎と応用](https://cdn.slidesharecdn.com/ss_thumbnails/ssii2022-os3-02-220607020834-2b5f93ff-thumbnail.jpg?width=640&height=640&fit=bounds)
![[DL輪読会]Grokking: Generalization Beyond Overfitting on Small Algorithmic Datasets](https://cdn.slidesharecdn.com/ss_thumbnails/20220325okimura-220405024717-thumbnail.jpg?width=640&height=640&fit=bounds)
![[DL輪読会]ICLR2020の分布外検知速報](https://cdn.slidesharecdn.com/ss_thumbnails/iclr2020ood-190927011524-thumbnail.jpg?width=640&height=640&fit=bounds)
学習時に使ってはいないデータの混入「リーケージを避ける」
- 1.
- 2. 今回紹介する内容 ● Leakage inData Mining: Formulation, Detecting, and Avoidance ○ 著者: Shachar Kaufman, Saharon Rosset, Claudia Perlich, Ori Stitelman ○ 投稿: Knowledge Discovery and Data Mining (KDD), 2011. ○ 引用: 196件 (2021/05/04 地点) ● 論文の内容 ○ データマイニングにおいて起こしやすい誤ちのうちの1つに"リーケージ"というものが ある ○ リーケージ: 本来得られるはずのないデータをモデルの学習時に使用してしまうこと。 データがもれるということでリークするともいう。 ■ 学習時には精度が高く出るが、本番環境では精度が落ちる ○ これは現実世界、機械学習コンペの両方で起きている ○ 深く議論されてこなかったリーケージの定式化を試み、未然に防ぐ、検出する方法を 紹介
- 3. 機械学習コンペティションにおけるリーケージの事例１ KDD cup 2007 1998~2005年のNetflixの映画評価履歴データを用いた2つのタスク 1.2006年の映画に対して各ユーザーが評価をするかどうかを予測 2. 2006年の各映画に集まるレビューの数を予測 ● 2つのタスクにおいて与えられたデータ内の映画は異なっている ● タスク2の優勝者はタスク1のテストデータ(2006年にどの映画にレビューし たか)を使用してモデルを作成していた
- 4. 機械学習コンペティションにおけるリーケージの事例２ KDD cup 2008 胸部X線データから乳がんを検出するタスク ●通常は無視するであろう患者IDが予測に寄与した ● おそらく患者IDが検査機関や機器に関連して付与されており、目的変数 となる乳がんである確率と相関を持ってしまっていた
- 5. INFORMS Data MiningChallenge 2008 患者の診療履歴を用いた肺炎の診断 ● 配布したデータにおいて、目的変数といくつかの特徴量として埋め込まれてしま った ● 主催者側はこのような特徴をいくつか除外して再配布したが、その欠損部分が推 測可能になっておりリーケージは防げなかった 機械学習コンペティションにおけるリーケージの事例３
- 6. 機械学習コンペティションにおけるリーケージの事例４ INFORMS Data MiningChallenge 2010 株価変動予測モデルの開発(増減の予測: 2値分類) ● 銘柄を非公開にしたり、テストデータに予測可能な変数を入れないなど、過去の コンペで起こったリーケージの事例に当てはまらない最低限の対策は行っていた ● yahooやgoogleの株価情報データを元に銘柄をある程度特定できてしまった ● 結果として約30チームがAUC 0.9以上を達成してしまう
- 7. 機械学習コンペティションにおけるリーケージの事例５ IJCNN 2011 SocialNetwork Challenge ソーシャルネットワーク上の繋がりを予測 ● 匿名化された約700万のエッジを持つグラフ構造から、ネットワークをよく表現 する残りの9000のエッジを特定する ● 細かく調べることでデータ元がFlickrであることを特定でき、6割以上のエッジを 予測することができた ● 主催者の意図ではない
- 8.
- 9. リーケージが発生する状況: 特徴量へリーク ● 特徴量にリークするのを防ぐ ○特徴選択、生成されたxは次を満たさなければならない ■ 全てのxはyよりも前に観測可能 ○ つまり、有効な特徴(legit{y}) は次の集合の部分集合である ■ これをno-time-machine requirement (タイムマシンいらずの要求) と呼ぶ → 目的変数よりも先に観測できる特徴を使う
- 10. リーケージが発生する状況: 特徴量へリーク ● 特徴量にリークするのを防ぐ ○このルールを守れば先程の機械学習コンペでのリーク事例の大半は未然に防ぐことができる ■ 例) KDD cup 2008 → 患者の状態の観測後にその情報を含む特徴(患者ID)が決まっていた ○ ではKDD cup 2007の例はどうか？ ■ モデル学習させた特徴は全て目的変数よりも前に観測可能であった ■ もう一つ対策が必要 → トレーニングデータ内のリーケージ
- 11. リーケージが発生する状況: トレーニングデータ内のリーケージ ● トレーニングデータ内のリーケージ ○このような条件も満たす必要があった ■ 学習に用いる特徴X は目的変数y よりも前に観測される ■ 学習させる目的変数はテストデータの目的変数よりも前に観測される ■ 目的変数も含めて学習に使ったデータはモデルに組み込まれた一つの特徴という考える
- 12. リーケージが発生する状況: トレーニングデータ内のリーケージ ● トレーニングデータ内のリーケージ ○KDD cup 2007 における失敗事例はなぜ起きたか？ ○ タスク1: ユーザーがどの映画にレビューしたか ○ タスク2: 各映画が何件のレビューを獲得したか ○ この二つが独立なものになっていなかった ■ テストデータはどちらのタスクも2006年のものである ■ タスク1で与えられたテストデータから、2006年の映画に関してのトレンドを 学習できてしまっていた → 同年度における「ユーザーのレビュー履歴」と「各映画のレビュー獲得数」が 依存している → 潜在的に存在する依存関係を把握することは難しい
- 13. リークを避ける２つの方法のまとめ ● リークを避けるためには、「目的変数より前に観測された説明変 数を使う」ことと「テストの目的変数より前に観測された学習用 の目的変数を使う」の2つを使えばよい ● 具体的にはどのようにすればよいか ○データ収集時に”タグ”をつける ○ タグを用いて学習、評価データを正しく分ける ● 例) no-time-machine の場合 ○ 正当性を判断するタグ → タイムスタンプ
- 14. リーケージを検出するには？ ● どのように収集されたかわからないデータはどう対処すべきか ○ タグがついていないため、正しいデータの分割もできない ○→ 探索的データ解析 (EDA (Exploratory data analysis)) ● 探索的データ解析 ○ データの視覚化、パターンの発見、相関関係の確認、など ○ 何か驚くような発見があればリークを疑う (例) KDD cup 2008 乳がんの検出タスクにおいて、患者IDが目的変数と高い相関 を持っていた ○ 驚くべき発見の全てがリークというわけではない
- 15. リーケージの修正 リーケージを検出した後にやるべきこと (3つのシナリオが考えられる) 1. タグが付与されている元データにアクセスし、leakage-freeなデータを再構 成する 2. 元データが利用できない場合、データ収集の方法を見直して leakage-free な データが使えるようになるまでプロジェクトを延期する 3. リーケージを起こしていないデータのみでモデルを作成
- 16. まとめ ● データマイニングにおけるリークは現実世界、機械学習コンペの両方 で起きており、適切に除去していく必要がある ● リーケージの発生は学習データとテストデータ、またその目的変数間 の時系列を意識していないことが主な原因となっている ●データを収集する側は”タグ”で正当性を確保、データを扱う側はタグ を元に正しいモデリング(データの分割や特徴選択)をすることが重要 である
- 17. チャンネル紹介 ● チャンネル名: 【経営xデータサイエンスx開発】西岡賢一郎のチャンネル ● URL: https://www.youtube.com/channel/UCpiskjqLv1AJg64jFCQIyBg ● チャンネルの内容 ○ 経営・データサイエンス・開発に関する情報を発信しています。 ○ 例: アジャイル開発、データパイプライン構築、AIで使われるアルゴリズム4種類など ● noteでも情報発信しています → https://note.com/kenichiro
Editor's Notes
- #2 今回は学習時に使ってはいけないデータの混入というテーマでリーケージについてお話しようと思います。 現実的には利用できないデータをいわばカンニングのような形で学習時に使用することで、非現実的な性能を実現してしまうリーケージは、データ扱う世界における大きな問題の一つです。 この動画では、リーケージの事例とリーケージを防ぐための方法を論じた論文を紹介します。 リーケージに関しての理解を深めるのに役立つと思うので、ぜひ最後まで見ていってください。 このチャンネルでは、機械学習などデータサイエンスの話をはじめとして、データサイエンスを実務に活かすための開発や経営の話をしていきます。 興味ある人はぜひチャンネル登録をお願いします。
- #3 今回は、Leakage in data miningという論文で2011年に投稿された論文を紹介します。 この論文は、データマイニングで起こしやすい過ちの一つであるリーケージにフォーカスしています。 リーケージとは、本来得られるはずの無いデータを、機械学習のモデルを作成するときなどに使用してしまうことを言います。 リークするなどと言ったりもしますね。 学習時に精度が非常に高く出るが、実運用となる本番では精度が落ちるということが起きている時、リーケージを疑ってもいいかもしれません。 リーケージは現実世と機械学習のコンペなどいろいろなところで起きています。 この論文では、あまり深く議論されていなかったリーケージを定式化し、未然に防ぎ検出する法を紹介しています。 それでは、解説していきます。
- #4 まず最初に機械学習コンペティションでおきたリーケージの事例を5つ紹介します。 1つめは2007年のKDD Cupで起きたものです。 このコンペティションでは、Netflixの映画評価履歴データを使って2つの予測のタスクが出されていました。 1つ目が各ユーザが映画に対して評価をするかどうかを予測するタスクで、もう一つが集まるレビューの数を予測したタスクでした。 2つのタスク別々として与えられ含まれる映画は異なっていたのですが、優勝者は1つめのタスクのテストデータを利用してモデルを作成していたということです。 テストデータは予測対象となる年のデータとなるので、本来であれば学習に含めることのできないものとなります。
- #5 2つめのリーケージの事例は、2008年のKDD Cupのものです。 この年は、胸部X線データから乳がんを検出するタスクを出されていました。 このタスクでは、患者IDがデータに付与されており、患者IDと乳がんとなる確率が相関を持っていました。 本来は乳がんと患者IDは相関を持つはずのないものなのですが、患者IDが検査機関や機器に関連して付与されていたことにより相関を持ってしまったということです。 これもまた、本来乳がんを検出するタスクとしては知るべきではない情報が含まれている事例となります。
- #6 3つめは、2008年INFORMSデータマイニングチャレンジ出だされた診療履歴を用いた肺炎診断のタスクです。 こちらは目的変数が特徴量として特徴量として埋め込まれてしまっていました。 主催者側はこれらの特徴を取り除いたりしたのですが、欠損となった値が推定可能になっており、リーケージは防げなかったということです。
- #7 4つ目の事例は2010年のInformsデータマイニングチャレンジで出された株価変動予測モデルのタスクでした。 この問題では、銘柄を非公開にしたり、テストデータに予測可能な変数を入れないなどリーケージの対策を行っていたのですが、他のサイトの株価情報をもとに銘柄をある程度特定できてしまい、多くのチームが非現実的な高精度な予測を達成してしまいました。 いくら隠蔽しても、元データを推測されてしまっては予測問題として成り立たないですね。
- #8 最後に紹介するのは2011年のIJCNNソーシャルネットワークチャレンジです。 巨大なグラフ構造からソーシャルネットワーク上のつながりを予測するタスクだったのでした。 しかし、元データがFlickrであることが特定され、6割以上のエッジを予測されてしまうという自体になりました。 こちらもまた、グラフ構造から予測してもらいたかったものだったため、主催者が意図していたものとは違う予測モデルが出てきたということです。 このように、有名なコンペティションであってもリーケージを防ぎきれず、意味のない予測モデルが優勝してしまうということが多く発生しています。 コンペティションなど、リーケージに特に気をつけてデータを準備しているタスクでも、このような自体になってしまっていることを考えると、実世界においてリーケージを防ぐことがいかに難しいことがわかると思います。
- #9 この論文では、リーケージを避けるためにまずはリーケージを発生させないようなデータセットの定式化を行っています。 細かい部分は長くなってしまうので、この動画ではざっとだけ紹介します。 リーケージを発生させないようにするには、とにかく時系列を意識することが大事とこの論文では主張されています。 つまり、時間軸でみたときに特定時点で手に入るデータかどうかを気にするということです。 この論文では、リーケージが発生する状況を「特徴量へリークする場合」と「トレーニングデータ内のリーケージ」の2つに分けて説明しています。
- #10 まず1つめの特徴量にリークする場合ですが、これを防ぐためには特徴量を目的変数よりさきに観測できるもののみ利用することで防ぐことができます。 この論文の著者はこのことをタイムマシンいらずの要求と呼んでいるようです。
- #11 目的変数より前に観測された説明変数のみを有効な説明変数にことは、2008年のKDD Cupにおけるリーケージではどうなるかというと、 リーケージとなった患者IDは目的変数より後に確定するものなので、説明変数として取り除くことができるというわけです。 このように目的変数の観測より前に観測できる説明変数にすることで、大抵のリーケージの発生は防ぐことができるのですが、実は例外もあります。 2007年のKDD CupはNetflixのデータを用いたもので、全ての特徴量は目的変数よりも前に観測可能になっていました。 つまり、トレーニングデータ内にまだリーケージが発生しているということです。 そのため、このリーケージの発生を防ぐために、もう一つ別の条件を付け加える必要が出てくるというわけですね。
- #12 トレーニングデータ内のリーケージを防ぐためのもう一つの方法は、学習用の目的変数をテスト用の目的変数より前に観測できるものに限定するというものです。 単純に、学習モデルとつくる時点では、テスト用の目的変数がわかっていないと仮定するというだけですね。 つまり、目的変数も含めて、学習に使ったデータはモデルに組み込まれた1つの特徴として考えるということです。 現実世界では当たり前なのですが、実際実験するときはテストデータも過去のデータを利用したりするので、抜け落ちがちなものです。
- #13 2007年のKDD Cupでは、2つのタスクが独立なものになっていなかったことが問題でした。 つまり、ユーザーのレビュー履歴と映画のレビュー獲得数が依存していたということですね。 そして、タスク1のテストデータをタスク2の学習で使うことで、高い精度の学習モデルを作ることができていたというわけです。 なので、さきほどの、学習データの目的変数をテスト用の目的変数より前に観測できるものに限定することで、この問題は回避できます。 潜在的に存在する依存関係を把握することは難しいので、時間情報を用いて適切にデータを絞ることが重要になってくるということです。
- #14 まとめるとリークを避ける2つの方法として、目的変数より前に観測された説明変数を使うこととテストの目的変数より前に観測された学習用の目的変数を使うことを紹介しました。 具体的なやり方としては、データの収集時にタグをつける方法が提案されています。 タグを用いることで学習と評価のデータを正しく分けることができるというわけです。 時系列情報を使い場合は、このタグをタイムスタンプにすればよいということですね。 ただ、このようなデータ収集のやり方は理想ではありますが、実際の現場ではどのように収集されたのかわからないデータを扱わないといけないことも多いと思います。
- #15 どのように収集されたデータを扱う時、正しいデータの分割ということは実質不可能です。 ここで出てくるのが、探索的データ解析です。 与えられたデータがリーケージを含んでいるのではないかを、きちんとデータ自身の傾向を見ることで調査してみようということです。 探索的データ解析では、可視化やパターンの抽出や相関の調査などをやっていきます。 そこで、意図しない驚くべき発見などがあればリークを疑ってみましょう。 2008年のKDD Cupにおける乳がんと患者IDの相関などはまさにその一例と言えると思います。 ただし、驚くべき発見は全てリークというわけではなく、もちろん文字通り驚くべき発見ができるということもあります。 そういう意味でも探索的データ解析の重要性は高いと言えます。
- #16 もし、リーケージが発見されてしまった場合は、次の3つの方法でリーケージの解消をしていきます。 1つめが元データを利用してリーケージフリーなデータを作り直すこと。 こちらに関しては、元データにタグが付いていることと、そもそも元データにアクセスできることの両方の条件が必要となります。 リーケージを修正する2つめの方法では、リーケージフリーなデータが使えるようになるまでプロジェクトを延期します。 リーケージが発生している時点で機械学習を適切にできないので、適切な学習ができるデータが集まるまでプロジェクトを延期してしまうということです。 リーケージを修正する最後の方法では、リーケージを起こしていないデータのみでモデルを構築します。 使える変数を減らしていく決断をするということですね。 実際の現場でリーケージを発見してしまった場合、これらの方法を参考にしてみてください。 現実的には3つめのリーケージを起こしていないデータのみでモデルを作成することが一番簡単です。 ここまでリーケージを防ぐ方法とリーケージの発見する方法そしてリーケージを修正する方法を紹介しました。 リーケージの一番の問題としては、なかなか気づきにくい点だと思います。 想定していたよりも高性能のモデルができたときは、その性能に喜ぶのではなく、まずはリーケージを疑ってみると良いと思います。
- #17 最後にまとめをします。 データマイニングにおけるリークは現実世界や機械学習コンペなど色んな場所で起きており、非現実的な結果をもたらしています。 そのため、リーケージが疑われる場合は、適切に除去していく必要があります。 リーケージの発生は学習データやテストデータ、また目的変数間の時系列情報を意識していないことが原因となっていることが多いです。 データを収集するときは、タグで正当性を確保できるようにし、タグをもとに正しいモデリングをすることが重要となってきます。
- #18 最後にチャンネルの紹介をさせてください。 このチャンネルでは、経営やデータサイエンスや開発の話をしていきます。 聞きたい話のリクエストも募集中です。 もし、この動画が役に立ったら高評価とチャンネル登録をお願いいたします。