雑記

f:id:cookie-box:20180513082851p:plain:w60

機械学習で Leakage ってよく聞きますけど、結局 Leakage の語義というか具体的に言い切ると何なのかよくわからないんですよね。漏れてはいけない情報が漏れていること、のようではあるんですが、何が漏れてはいけないんでしょう? 我々は総力を挙げてテストデータの正答を予測するモデルの構築に取り組まなければならないのではないんでしょうか?

f:id:cookie-box:20180513082908p:plain:w60

ここ https://www.kaggle.com/docs/competitions に What is Leakage? とあるから読んでみたらどうかな。「予期せぬ混入した情報」であって以下のようなタイプがあるって書かれているね。

  • テストデータに対する正答が漏れてしまっている。
  • テストデータであるはずのデータが訓練データに混ざってしまっている。
    • 上の2つは言うまでもないね。自分でデータ分析をするときはバグでこれらの漏洩をしないように注意だね。コンペティションではじゅうぶん気を付けられていると思うけど、回答者が調べれば正答が突き止めることができてしまうような出題はできないね。
  • モデルが利用できないはずの未来の情報が混ざってしまっている。
    • 以下のブログで紹介されている、「売上を予測するコンペティションで、店舗の住所を特定して(予測時点では知りえないはずの)未来の天候情報を紐づける」というのがこれだよね(もっともこれはデータに混ざっていたわけじゃなくて、第三者データから持ち込んだわけだけど)。
      https://adtech.cyberagent.io/techblog/archives/259
  • 意図的に加えたノイズや匿名化が除去されてしまう。
    • これはよくわからないけど、研究の目的上とか実用上の制約で匿名化データを使用しなければならないときに、個人名をどこかから探してきてくっつけたら駄目みたいな話だね。モデルが自分の力でノイズを除去したり個人の性質を同定したりするならよさそうな気はするけどね。
  • 何らかの事情で利用禁止することにしたために除去した情報が残ってしまっている。
  • モデルが運用上入手できない情報が利用されてしまう。
    • これらは「未来の情報」「個人情報」以外で目的上「この情報からの学習は意図しないという情報」って感じがするね。コンペティションの出題者も、意図しない情報がどこかから発掘されないように出題しないといけないから大変だよね。
  • データがもつ情報が利用目的から外れて歪められてしまう。
    • これは以下の記事で挙げられている例のことだと思うんだよね。テニスのルールは詳しくないんだけど、両選手のミスショットの回数とかから勝敗を予測するのが学習の意図なんだけど、プレイヤー1の名前とプレイヤー2の名前を説明変数に入れてしまうともうモデルはこの対戦カードの対戦結果はこれって覚えちゃうよね。でもそんなことをモデルにしてほしかったわけじゃない。
      https://tjo.hatenablog.com/entry/2016/01/27/235620
  • これらの情報が第三者データから持ち込まれてしまう。
だからやっぱり Leakage は「漏れてはいけない情報が漏れた下で予測が実行されること」で、というからには漏れてはいけないものとは何か定められていないといけないけど、その典型例は「テストデータの正答」「モデルを利用する場面ではまだ入手できない未来の情報」「その他のモデルが知り得ない情報」「その他、学術的な目的などでこの情報からは学んでほしくないという情報」とかみたいだね。でも何か予測を実施するときの制約というのはケースバイケースだから、具体的に統一的にこれが漏れていてはならないとは言いづらいんじゃないかな。

f:id:cookie-box:20180513082851p:plain:w60

なるほど。その未来の情報という例で思ったんですが、こういうのはどうです? 未来の天候情報そのものを参照するとズルなので、未来の天候情報を予測するモデルを謎の目的関数で学習して、そのモデルの予測を利用して未来の売上を予測するというのは。

f:id:cookie-box:20180513082908p:plain:w60

いや私運営じゃないから知らないんだけど…確かにモデルがあからさまにデータを内蔵していなくて自分で天候を予測しているなら問題は少なそうだけど、それで達成できるような精度は直接未来の売上を予測しても達成できるんじゃないの…? もちろんモデルによるけど…。だいたい中間目標を置くのは多くの場面で得策じゃないよね。天候情報の予測がよほど楽勝だったら別だけど、じゃあやっぱり大してプラスにならないんじゃないの。

f:id:cookie-box:20180513082851p:plain:w60

ぐぬぬ…。

f:id:cookie-box:20180513082908p:plain:w60

上の Kaggle のページの続きに Leakage の具体例があるね。

  • 各患者が前立腺ガンかどうかを予測するためのデータに「前立腺の手術を受けたか」という変数を含めてしまった。

f:id:cookie-box:20180513082851p:plain:w60

ちょっとうっかりしすぎじゃないですかね。因果関係ってご存知ですかって感じなんですけど。

f:id:cookie-box:20180513082908p:plain:w60

いやでも、こんなことも実務で起こらないとはいえないから気を付けないとねってことなんじゃないかな。これは極端な例で、実際の Leakage はもっとわかりづらいって書いてあるよ。あと続く例は、実際に初期の Kaggle のコンペティションで、ソーシャルネットワークの「つながり」の予測問題があったみたいなんだけど、サンプルスクリプトのミスで、ある条件を満たすユーザどうしは無条件で「つながっている」というラベルがついてしまっていたみたいで、これを突いたチームが2位になったみたいだね。さらに1位のチームは、スクレイピングによってデータの匿名性を剥がしちゃったみたいだけど。

f:id:cookie-box:20180513082851p:plain:w60

…それって出題ミスですよね。2位のチームは、出題者の意図とは違うモデルを構築してしまったとはいえ、データのパターンを見出したのだから Leakage ですらないような。1位のチームは…大会のレギュレーションによるでしょうね。…最後の Leakage in Competitions というパラグラフにはなんて書いてあるんです?

f:id:cookie-box:20180513082908p:plain:w60

コンペティションにも Leakage がない保証があるようになんてできない。以下のような対処はできるけどいつもできるわけじゃないって書いてあるね。

つづかない