kaggle本第3章
第３章 特徴量の作成
3.1 本章の構成
3.2 モデルと特徴量
3.3 欠損値の扱い
NN使うときの欠損値取り扱いが大変だと感じます、普段みなさんどうしてますか？wakame.icon
データ見て中央値にするか、平均値にするか、最頻値・・・って感じwakame.icon
0埋め、最頻値・平均などが多いですかね。面倒ですよねcurrypurin.icon
基本レコードは消さないで対応するのが基本になってるのかな?
3.4 数値変数の変換
その他の非線形変換(P.130)
四捨五入・切り上げ・切り捨てを行う
価格設定を200円ではなく、198円にするとお得に見える
端数部分を特徴として使う
Column データ全体の数値を利用して変換を行うときに、学習データのみを使うか、テストデータも使うか
お仕事では当然テストデータと訓練データを合わせて変換するなんて芸当は不可能、Kaggleというコンペの仕組み上できるからやるwakame.icon
LBProvingも似たような話でできてしまうからやる、こういうのはルールなりシステムで縛らない限り参加者はやると思う
以前の輪読の時に出てきた、このWebページの次の文言どういう意味でしたっけcurrypurin.icon 僕の理解ですが、例えば標準化を行う場合、CrossValidation前に標準化を実施するのではなく、CrossValidationの中でtrainの平均・標準偏差を計算し、その値を用いてvalidの値も標準化を実施すべき、という考え方だと思います。kaggle-jaの回答の方も同様の意見に見えます。testに対しては、train全体の平均・標準偏差を利用するのかなと思います。sinchir0.icon 高際の言っているのは、実務の話なんですかね？
3.5 カテゴリ変数の変換
3.5.5 target encoding (P.142 - P.150)
target encodingのリーク対策の一個として、smoothingも有名かなと思うので関連サイト貼っておきます。 この式はni の数が十分に大きければ第一項の影響が大きくなり普通のTargetEncodingと同じような値を示す。一方で niの数が小さいと第二項の影響が大きくなりデータセット全体の目的変数が1の割合に近づく。
niはデータ数ですね。niが大きい時は普通のtagtet encoding 小さい時はデータ全体の目的変数の確率に近くよう補正をかけるイメージですねsinchir0.icon
target encoding する際の fold の切り方を毎回迷います。(二段階 CV する必要があると思うのですが特に二段目の方) nyk510
target_encodingするならcategory_encordersというライブラリが便利という話wakame.icon
smoothing effect to balance categorical average vs prior. Higher value means stronger regularization. The value must be strictly bigger than 0.
smoothingも対応してます
3.6 日付・時刻を表す変数の変換
3.6.2 日付・時刻を表す変数の変換による特徴量(P.156 - 159)
休日かどうかの休日フラグは大抵効くので毎回作ってる、jpholidaysは2019年->2020年への変則的な休日変更にも対応してくれているwakame.icon
Signateの公園コンペでは効きましたwakame.icon
各国の休日はpandasに確かあったはず
from pandas.tseries.holiday import USFederalHolidayCalendar
3.7 変数の組み合わせ
featuretoolsで組み合わえ特徴量作れたのをこちらの記事を読んで初めて知ったwakame.icon
merge, groupbyを使わなくてよくなるのでコードは綺麗になると思ってます
3.8 他のテーブルの結合
この例カテゴリ変数をone-hotencodingしてるから時間かかってるのかも
なんでgbdtなのにone-hotencodingしてるのかは不明
追記 KaggleDaysTokyoにて
非常に面白いと思ったのが, label encoding と one-hot encoding の比較です. Kaggleではlabel encodingの方が良く使われる傾向にあるのですが, 実験上ではone-hot encodingの方がパフォーマンスが全体的に良いことが確認されました. 特にlabel encodingだとハイカーディナリティなカテゴリ変数に対してoverfitしやすく, one-hot encodingはlabel encodingよりは多少overfitが軽減されています (恐らく今回の実験用データセットがシンプルだから).
3.9 集約して統計量をとる
3.9.2 時間的な統計量をとる (P.168)
Kaggleの「Facebook Recruiting IV：Human or Robat?」は、オークションサイトの入札が人間とボットのどちらによるものかを判別するタスクでした。ボットはたくさん入札し、また速く入札するという知見から、入札回数の平均と入札間の間隔の中央値を特徴量とする方法がとられていました注17。
注17のkaggle blogのリンクが消失していたので当時のディスカッションのリンクを下に貼ったwakame.icon
入札回数の平均と入札間の間隔の中央値を特徴量にした、Bidding action over timeの項のグラフがわかりやすい。Botと人間の入札間隔はBotのほうが早いことがわかる。
検索したら出てきた日本人参加者の方の解法
3.9.5 ユーザ側でなく、アイテム側に注目する(P.169)
特別な商品に注目する(P.170)wakame.icon
ユーザの行動や属性のポイントとなるような商品があれば、そこに注目するのも良いでしょう。 Kaggleの「Instacart Market Basket Analysis」の2位のソリューションでは、オーガニック、グルテンフリー、アジアのアイテムに注目していました。
user_id毎に集計してカウントしている
3.10 時系列データの扱い
3.11 次元削減・教師なし学習による特徴量
3.11.5 どういう状況のとき「t-SNE,UMAPを試してみよう！」と考えるのかを知りたい(p.193)sinchir0.icon
Kaggleの例だとt-SNEで可視化すると、testにしかないクラスタがあることがわかり、train/testの分布が異なるのではという気づきが得られるという例がありましたwakame.icon
Porto Seguro’s Safe Driver Predictionコンペ
また公開カーネルでは訓練データの次元削減(PCA/t-SNE)後の可視化で正例と負例のクラスタがほぼ重なるため、予測が難しいのではwakame.icon
3.12 その他のテクニック
3.12.2 レコード間の関係性に注目する
「グラフ理論を用いた特徴量」はどういう問題設定だと有効なパターンが多いのか。A=B.B=CならばA=Cが成り立つ状況？(p.200)sinchir0.icon
分子コンペではGBDTよりGCNのほうが良いパフォーマンスが出たっぽい？wakame.icon
原子と結合からなるグラフと見なせる分子データを扱うにあたりGraph Convolutional Networks（GCN）が活用された。
3.12.7 トピックモデルの応用によるカテゴリ変数の変換(p.204)
最近だとKaggle Days TokyoにてML_Bearさんが本特徴量を作っていました。sinchir0.icon
3.12.9 decision tree feature transformation(p.205)
決定木が目的変数を参照した特徴量を付与するため、leakを引き起こしやすい気がするけれどどうなんでしょう？sinchir0.icon
気になりますね。クラスタリング程度の意味しかないのでleakするのか、それともするのか。今ならLightGBMで作って、XGBoostに入れるとかですかね。初めて聞いた手法でしたcurrypurin.icon
3.13 分析コンペにおける特徴量の作成の例
3.13.5 分析コンペにおけるその他のテクニックの例
カーブフィッテイングとの差分を予測する(p.214)
Ridge回帰でのトレンド推定(p.215)
