How to Win a Data Science Competition Week2-02

Posted on 2019/10/04 in 機械学習 , Updated on: 2019/10/05

coursera の How to Win a Data Science Competition: Learn from Top Kagglers の Week 2 のまとめ2。

Dataset clearning and other things to check

  • Dataset cleaning
    • 同じ値しか入っていない特徴量はないか
    • 複製された特徴量はないか
  • Other things to check
    • 複製された行はないか。あれば理由を考えよう
    • dataset はシャッフルされていないか

  • train と test 両方ですべて同じ値を持つ特徴量
    • サンプリング手順が原因か
    • こういう特徴量はメモリの無駄なので削除
  • train 内ですべて同じ値を持つ特徴量
    • 同様にメモリの無駄なので削除してOK
  • 全く同じ特徴量が複数ある
    • 一つ残して他は消す
  • カテゴリ変数でラベルだけ異なる場合
    • ラベルを数値に変換して同じ特徴量を探す
    • この際、ラベルのエンコードを正しく行うことが重要
    • 特徴量の上から順番にエンコードしていく必要がある

データフレームの重複行および列の削除

code function
df.nunique(axis=0)==1 値がすべて同じカラムをTrueで返す
df.nunique(axis=1)==1 値がすべて同じインデックスをTrueで返す
df.T.drop_duplicates() 各インデックスの値が同じカラムを削除
df.T.drop_duplicates() 各インデックスの値が同じカラムを削除
df.factorize() カテゴリ変数のラベルを上から順番に数値にエンコード

Validation and overfitting

  • Private データ採点後のランキングのシェイクダウンの原因
    1. Validationのスコアを検討せずに、Publichリーダーボードが高くなる予測を提出した
    2. Publich/Private データに一貫性がない(どちらかのデータ数が少なすぎるなど)
  • 正しい Validation は大事
  • コンペは、通常ラベル付きデータとラベル無しデータの2つのチャンクが与えられる
  • ラベル付きデータで学習して、ラベル無しデータのラベルを予測する
  • その前に、ラベル付きデータを分割して、モデルの性能を評価するのが Validation

  • Validation はモデルの質を評価する助けになる

  • Validation はまだ見ぬデータでいい結果を残すモデルを選択する助けになる
  • Underfittingは、学習データを十分学習できてない
  • Overfittinghは、学習データを学習しすぎ
    • データ内のノイズを学習してしまっていたり
    • テストデータに一般化できないパターンを学習してしまっていたり

Validation strategies

  • 最もよく使われる分け方
    • Row Number
    • Time
    • Id
  • 特徴量生成のロジックは、データスプリット方法に依存する
  • コンペの train/test の分割と同じように Validation を設定する

  • 使われる分割手法
    • Hold Out
      • データ数が比較的多いときに有用
    • KFold
      • くり返し Hold out
      • 最終的にすべてのデータを検証に用いることができる。
      • データ数少ないときに有用
    • LeaveOneOut
      • データからサンプル1つを抜いたものを検証として他すべてを使ってトレーニングする
      • 非常に計算コスト高い
      • データ数少ないときに有用
  • 検証セット作成時に、ランダムにサンプリングするとターゲット値に偏り出てうまくいかないときある
    • Stratify (層化) サンプリング使おう。

Data spliting

  • 検証データを作成するときは、train データと test データの分割を模倣するように分割する - 時系列データで、train の後に test が連続しているとき 
    => 検証データとして train データの末尾から連続したサンプルを使う
  • 行ごとにランダムに分割してもOKなのは、これは行が互いに独立しているときに成り立つ。層じゃないとオーバーフィットする
  • 検証スコアとリーダーボードスコアが一致しないのは、検証データ作成が悪いかも
  • KFold の分割数は通常 5程度でOK
  • 5分割して検証を5回行い、test データへの予測も 5回実施し平均化する。より安定したモデルのパフォーマンス
  • 信頼できる検証データを作ってからが、コンペのスタート

Problems occuring

  • 検証データとトレイニングデータの関係 = テストデータとトレイニングデータの関係なるのが理想
  • そうなれば、検証データでのスコアアップ手法がテストデータにも直接効くことが予想できる
  • ただテストデータと同じような検証データを作成するのは難しい
  • 前処理やモデルチューニングの前に、検証データがうまくいってるか確認するためにまず佐文っとしてみる
  • 検証スコアの平均と標準偏差を計算してリーダーボードスコアをだいたい予想する
  • コンペでは、トレインデータとテストデータが意図的に異なっている場合がある
    • トレインデータは男性、テストデータには女性のデータしかない等
      • こういった場合は、平均値が異なるだけで分布は同じではないか?など推察してみる
      • リーダーボードプルービング
  • 中には、トレインデータが男:女が9:1、テストデータが1:9のような分布の異なる場合もある
    • 検証データとトレインデータもテストデータと同じように1:9になるように作る

Basic data leaks

  • コンペデータにたまにあるリークについて
  • 非現実的に良い予測結果を出せるデータ内の予想外情報
  • 一度データリークが見つかると、それまでの予測を大幅に上回るスコアが出てしまうことも
  • コンペの目的が高い点数を取ることなので皆これを利用する
  • 現実世界の問題解決には全く使えない

  • 具体的な事例
    • 未来の株価データを使って過去の事象を予測できてしまう
    • 画像分類コンペにおいて、メタデータが利用されてしまう
      • 犬を撮影してから猫を撮影 => 撮影時刻データから完全に分類できてしまう
      • 犬と猫それぞれ特定のカメラで撮影 => カメラの情報から完全に分類できてしまう
    • ハッシュ化されたIDを解読すると何らかの情報が得られてしまう

Leaderboard probing and examples of rare data leaks

  • データリークの見つけ方
  • リーダーボードの公開情報から何らかの特定情報をみつける
  • 小さな行のセットをいくつか変更してサブミットしてスコアの変動から予測する