過去のコンペをただ語る

Transcript

1. Kaggle Tokyo Meetup #2 過去のコンペをただ語る @threecourse

2. プロフィール • 生命保険会社のアクチュアリー • 機械学習仕事で使わない勢 • kaggleガチ勢に復帰しようと思ったが... • 好きなライブラリ：hyperopt

3. kaggleへの取り組み • やっぱりやるからにはいい順位を目指さないとつまらない • ゆるふわにやるのは難しいので、出るコンペ数を制限する方が良さそう • コンペ中は英語のドキュメントを読んだり、ちょっと難しい数式を勉強する 気になる • コンペ中は明らかに仕事への集中力が落ちている

   • 数値系のコンペは、stacking祭りになって辟易する面もあった。 – 数値系であってもちょっと違うコンペがあるので、コンペによっては楽 しめるかもしれない • kaggleよりやるべきことがあるのなら、そちらをやるべきなのかもしれない。 でもあんまり見つからない（募集中） • Dark SoulsとかPlanet Coasterとか囲碁とか将棋ウォーズとかやったけど、 kaggleがやっぱり一番生きている実感がある • コーディング技術や機械学習の技術で正面から戦っても勝てない気がす るので、軸をずらしたアプローチを心がけたい

4. kagglerのジレンマ • コンペ中は発表資料を作っている余裕がない • コンペでないといろいろ調べる気力がない • ただ過去のコンペを語るだけで発表になるので、meetup #3 の機会などには、お忙しい方はこんな感じで発表頂ければ •

   発表枠をちゃんと取ると、meetupは年１回くらいかな？ • もう少し緩く集まる機会があると良いかなとは思う

5. kaggle環境 PyCharm • spyderとは何だったのか • コード補完が効く、変数名変えられる、使ってない変数は薄くしてくれる、 エディタ内terminalもある • 上のフォルダのscriptを呼び出すためのフォルダ構成を悩んでいたが、 pycharmにルートフォルダを設定、呼び出すときはsys.path.appendでルー

   ト追加で良さそう • さすがにvim覚えるのはつらい 作業管理 • Git + Bitbucket • Slackで一人でつぶやく • もう少し構造的にまとめたいものはEvernote

6. kaggle環境 リソース • 本格的にやるなら、計算を終わるのを待ってる時間が勿体ないので、 AWSのスポットインスタンス借りる流れを作った方が良さそう • スポットインスタンス発注する -> rsyncでコード送る ->

   S3でデータ取得 -> ランの実行 -> 結果をS3に保存 -> 終わったらシャットダウン • GPUは自前で買った方が安いはず（たぶん）

7. Walmart Recruiting II: Sales in Stormy Weather 2015/4/1 – 2015

   /5/25, 1st / 485 データ・概要 • お店、商品ごとの販売量が与えられる。 • テスト期間の大雨の日の販売量が欠けているので、それを予測する • 天候データが与えられているがどうも壊れている様子で、それをどう使っても精度 は出なかった。 アプローチ・思い出 • 初参加（その前にtitanicやpoker rule inductionとかは少しやった） • linuxもこのとき覚えた – なんとsourceコマンドでスクリプト叩いてる... • matplotlibでひたすらPDFを作った – jupyter notebookがあまり好きになれないので、pdfをせっせと作ることが多い • pandasの使い方覚えるの大変だった – indexの使い方、概念に慣れる必要がある – np.arrayを入れるか、seriesを入れるかで結果が変わることがある – 時々numpyに戻って処理することも必要だったり

8. Walmart Recruiting II: Sales in Stormy Weather アプローチ・思い出（cont.) • 単純にお店、商品ごとに販売量の平均を取るだけでそこそこ行く。

   • Rのppr関数でベースラインのフィッティングをさせ、ベースラインとの誤差を vowpal wabbitの線形回帰で埋めに行った • 終盤、係数を見ていたらBlack Friday近辺とクリスマスが大きいことに気づき、モ デルに反映 • 終了の数日前、フィットが見た目に怪しいところをエクセルで手修正してしまった • ルールをよく見るとhand labelling禁止と書いてあったことに気づき、慌てて adminに取り消してもらった • (参考) https://www.kaggle.com/c/walmart-recruiting-sales-in-stormy- weather/forums/t/14452/first-place-entry • Recruitingコンペで、当時はbeat the benchmarkが無かった (public sharingも禁 止） • 何も考えず分類器にかけていた人も多かったみたいなので、意外にみんなデー タとかタスクとか見てないんじゃないかと思った。 • 優勝したけど、まわりにkaggleを知ってる人がほとんどいなかった • twitterでつぶやいてみたら、誰かが捕捉してくれて、今に至る

9. Coupon Purchase Prediction 2015/7/16 – 2015/9/30, 3rd/1076 データ・概要 • ユーザーの属性、購入履歴、閲覧履歴、クーポンの属性が与えられる

   • 各ユーザーがテスト期間のクーポンのどれを購入したかを予測する • 評価指標はMAP@10 アプローチ・思い出 • ユーザーがあるクーポンを購入した、購入しないを正例、負例とした。 – ユーザー×クーポンで一千万行以上になるので、サンプリングして数百万行 のデータとして扱った。 – 64GBのAWSインスタンスを借りていた – 学生の参加を意識していたようですが、リソース的にはなかなかつらいデー タセット – ニューラルネットなどで動的に正例・負例を生成すれば、省メモリでも行け たっぽい • かなり終盤までロジスティック回帰で進めた（それしか使えなかった）。終盤に xgboostを覚えて、混ぜて提出。

10. Coupon Purchase Prediction アプローチ・思い出(cont.) • beat the benchmarkはcosine distanceを使ったもので、わりとナンセンスだった •

    ビジネスがどういったものかの知識があるのが大きい – 同じ種類のクーポンの再発行があることに気づいた – 同じカテゴリ、同じような属性でも、クーポンによって全然内容・人気が違う – 「宅配」は全国どこからでも買えるが、「グルメ」は近場にしか行けない • 「ギフト」というカテゴリがあって、過去の実績からは一定の購入が想定されるの に、LBでは購入されていないようなので、外れ値として落とさざるを得ない – その発想を拡張して、「宅配」「その他」といったカテゴリを落としに行った – 「その他」はともかく、「宅配」を入れると線形回帰ではつらかった • 最後のひと押しになったのは、カテゴリをさらに価格帯で細分化 – 「グルメ」でも、1000円と3000円と10000円では意味合いが違う • （参考) https://github.com/threecourse/kaggle-coupon-purchase-prediction

11. Walmart Trip Type 2015/10/26 – 2015/12/27, 38th / 1047 データ・概要

    • あるカスタマーのある日の購買データ（Tripという）が与えられる • これを37種類の"TripType"に分類する • 購買データは曜日、購入量、アイテムのカテゴリの大分類、小分類、UPC番号 （バーコード番号のようなもの） アプローチ・思い出 • kaggleの流れを整理しようと思った（モデル作成、パラメータ調整、クロスバリデー ションなど） – モデルはモデルの種類・パラメータ・特徴量の組で表せるとか – CVのindexや作成したfeatureをどう保存するかとか • 購買データの基本的な情報を抽出（長さ、平均数量、返品の数など） • 大分類、小分類を含むか否かを特徴量にする • モデルはまずはxgboost – xgboostって大量のfeatureでもいけるんだ…

12. Walmart Trip Type アプローチ・思い出(cont.) • CrowdFlowerのSolutionを参考にいろいろ試したが、良い特徴量は作れなかった • neural netで上手くモデリングできるかが大きかった様子 –

    hyperoptでぶん回した結果、adadeltaの結構極端なパラメータにするとxgbに は敵わないがそこそこのスコアが出た。 – xgbとstackingすると思いのほか上がった – ちゃんとfeature selectionしていなかったのが良くなかった – single modelのベストがnnだった模様。多クラス分類ではnnが強力ということ なのでしょう • UPC番号がどうdecodeできるのか悩んでいたが、チェックディジットを取っただけ だった – 単純に上５桁をとる、などで多少効いたかもしれない

13. Prudential Life Insurance Assessment 2015/10/26 – 2015/12/27, 30th/2619 データ・概要 •

    保険申込者のレコードに対応する反応変数を推定する。反応変数は1-8 • ほとんどの項目名は匿名化されている。（Product_Info, Insured_Infoなど大まかな くくりはわかる） • 評価指標はquadratic weighted kappa • train/testの分け方はかなり均質

14. Prudential Life Insurance Assessment アプローチ・思い出 • 匿名特徴量は嫌い… • 特徴量はいくら作っても精度には寄与しなかった •

    アメリカの保険査定の資料とか調べたのですが… • kappaのためにクラス区切りのoptimizeをしないと勝負にならない。 – 基本的には反応変数を数値としてregressionをした後、optimizeしてクラス区 切りを求める。 • １位の人によると、２つのモデルのCVが同等のスコアだとして、それを70/30に分 けると、publicで良いモデルはprivateで悪くなるので、敢えてpublicLBのやや悪い モデルを選んだとのこと – https://www.kaggle.com/c/prudential-life-insurance- assessment/forums/t/19010/1st-place-solution • xgb, ert, linear, svmでregressionやclassificationを組み合わせて３層Stackingとし た。多少効果はあったっぽい。 • いっぱいモデルをつくるとパラメータ調整する気力がないので、hyperoptに頼った。 • （参考)http://threeprogramming.lolipop.jp/blog/?p=999

15. State Farm Distracted Driver Detection 2016/4/5 – 2016/8/1, 55th/1440 データ・概要

    • ドライバー画像を safe driving, texting, talking to passengerといった９種類のクラ スに分ける – safe driving, hair and makeup, talking to passengerあたりの分類がつらい • 画像は動画からの切り出し。また、train/testがドライバーで分かれている – このため、ドライバーで分けずに単純にCVをやると、とんでもなく良いスコア が出てしまう。 – ドライバーによる難易度の差が大きいので、あまりCVスコアとLBスコアの関 連がなかったように思う – 学習目的としてはCVが信用できるコンペの方が良いと思う

16. State Farm Distracted Driver Detection アプローチ・思い出 • komakiさんから誘いがあり、チームを組んだ • slackで議論、bitbucketでお互いのソースを見れるようにしておく、基本的に各自

    で進める • jiao dongに翻弄（？）された序盤 – かなり良いスコアのbtbがforumに投げ込まれた – https://www.kaggle.com/c/state-farm-distracted-driver- detection/forums/t/20747/simple-lb-0-23800-solution-keras-vgg-16- pretrained – VGGモデルでただfine-tuningするだけ(pretrained model恐るべし） – ドライバーごとのCVになっていないのでCVスコアが意味をなさなかったり、 使ってないコード消してなかったり、なんとも信用度が低かった – ラン時間も結構かかるので試しにくかった（63時間といっている。TITANXだと 1日程度だったような） – 教訓：人のことは信じましょう

17. State Farm Distracted Driver Detection アプローチ・思い出(cont.) • 自分のアプローチは単にパラメータ変えて投げただけとなってしまった • 関節やケータイの位置にラベリングし、クジラコンのようにadditional

    targetとして 使おうとしたが、精度は上がらなかった – regressionだとlossの定義が面倒な部分があるので、8*8でclassifitionとした – ちゃんと関節の位置も予測できているのは興味深かった（ちゃんと予測でき ているドライバーであれば） • semi-supervised, puesdo labellingといった単語にはたどり着いた – 問題の性質を考えると、semi-supervisedはたぶん正しい方針の一つ – 動画が基になっていることを利用することは頭の片隅にあったが… – talking to passengerが分けづらいのは、talking to passangerと指示されてい る時間に必ずしも横を向いているとは限らないためと考えれば、前後の情報 を使うことにもっと力を注ぐべきだったか • GANでドライバー画像を生成したりもした • 自分の結果が出なかったので、だんだん辛くなってきた。いろいろあって残り１か 月くらいでリタイア

18. Two Sigma Financial Modeling Challenge 2016/12/2 - 2017/3/1 データ・概要 （private

    sharingにならない程度に） • 時系列データを元に株価（？）のリターン（？）を予測する • とてもノイズが大きい • 初めて開催される、コードを提出するコンペ – 提出用のコードでは、将来の特徴量は使えないので、コードを変えなきゃい けない – 提出用のコードとモデリング用のコードを２重管理するのが手間 – 時間制限がタイトだったり、デバッグしようにも提出用のコードのエラーを最 低限しか出してくれないので、つらい • 結構やったのですが、たぶん撤退