nyanp / kaggle-homecredit Goto Github PK

Bureauはノイズが多いので、**値のほうが効くかも？

credit vs applicationなど、テーブルを跨いだ分が余地ありそう

• 過去12ヶ月の支払いした/しないを12bitで表現し、そのままカテゴリ変数化するかtarget encoding

pos/credit/bureauそれぞれで実施できる。また、

• 支払いが遅延したかどうか
• リボ払いで買い物したかどうか
  などのバリエーションが作れる

返済遅延月にクレジットを借りているなど、特にDPDを起こしている月のアクションに注目

同種のローンで他の人より延滞が多い=延滞リスクが高い？

max_bin, num_leaves, colsample

applicationにおけるSK_ID_CURR == 208252 (target==0)と、prevにおけるSK_ID_PREV == 2414778 (3回分の支払記録あり、DPD == 0)が同じローンを指している

organization_typeかoccupation_typeの同一グループ内での相対値。

情報の信頼度に差があるなら、分割したほうが精度が上がるかも

家族の数、居住エリア、家の情報が完全一致する人がいるか？

e.g. Bosch Solution

一番重要そうなPrevious Loanの列をそのままApplicationに加える

外部データは使える。

金額のオーダーが近いもののほうが重要度が高い？

ある日に複数回分のローンをまとめて支払う場合があるが、これがinstallments_payments上の記録だと

• 同日に複数回の支払を記録
• AMT_ANNUITYよりも大きな額の1回の支払として記録

の2通りの記録のされ方がある

TrainとTestでRevlovingの比率が顕著に異なる。

金融情勢によってDPDの意味合いが変わるかも

Number of Credit Linesといった名前で、他のローンコンペで使われる特徴量

新規申し込みするローンが、その人にとって相対的に大きな額かどうか

bureau-balanceを月度の古い順に並べた時の、STATUSの遷移情報を2-gramのcountで表現する。

ローンにもいくつかの種類があり、分割回数や金額が似ているものは似た傾向があるかも。
元の次元が小さいので、prevと組み合わせないと効果が薄いかも

#33 と近いアイデア。以下の2つの行動を区別したい。

• 連続して延滞を続け、ある時点で一気に支払った場合
  • DPDは毎月の支払ごとに1か月分積みあがっていく。
  • →1階微分は30day、2階微分は0day.
• 毎月遅延しながら支払っている場合
  • DPDは累積せず、毎月近い値を中心にばらつく。
  • →1階微分が0

#49 の派生。
同一グループ内での相対ローン額を計算する際、prevを使ってaugmentationする

• Prevのローン情報+Appricationのユーザー情報から、InstallでDPDが起きるかどうかを予測するモデルを作る
• 学習したモデルでApplicationのDPDを予測したものを特徴量に加える

「アクティブなローン」を「最後のMonthly StatusがActiveで、かつ直近12か月に更新があったもの」と定義しているが、これを直近6か月に変えてみる

• 同一ユーザーと思われる申し込みの組がtrain/testに複数観測されるが、いずれもtestの方が100日以上後
• AMT_CREDITとAMT_ANNUITYの比率の分布が、train/test間でズレている
  • 期間の違いによる金利の差を反映している？
• その他、train/testで明確にデータの分布が違う
  • Adversarial ValidationでAUCが0.98くらい出る

どの申し込みも直近8年(2922days)分のデータだけ使われているようなので、train/testで集計期間が変わる訳では無い