mail.ruのmlbootcampをコンテストします。 2位のレシピについて簡単に

こんにちは、読者！ この記事では、MLBootCamp IIIコンテストで2位を獲得する方法を説明します。 知らない人のために、Mail.Ru Groupのこの機械学習とデータ分析の競争は、2月15日から3月15日まで開催されました。



この記事では、ソリューションの構築の歴史、私が何にぶつかったのか、感謝の気持ちを伝えるヒントについて簡単に説明します。



行きましょう。







Loglossがメトリックとして使用されたため、次のことを覚えておく価値がありました。



-多くの分類子は、「箱から出してすぐに」ログ損失を最小限に抑える方法をすでに知っています。

-たとえば0.97や0.03の代わりに1.0または0.0に回答を四捨五入すると、Loglossは「許しません」と誤解します（下の図を参照）。





したがって、予測の結果に手を触れないでください。

問題の解決について

最初の提出は、コンテストの開幕直後に行われました。これは、彼の意見では、トップ10のランダムフォレストです。 その後、約1週間を費やしたステップが実行されましたが、生産的ではありませんでした。2次フィーチャが生成され、交差検証の結果に基づいてフィーチャを選択する最も単純な貪欲なアルゴリズムが起動しました。



アルゴリズムは次のとおりです。フォレストをトレーニングし、そこから機能の重要性を取得し、最初の2つから始めて、現在のセットに1つの機能を追加します。 機能を追加することで結果が改善される場合は、機能をセットに残します。 そうでない場合、私たちはそれを投げ返し、再びそれに戻ることはありません。



この単純なアルゴリズムが完了すると、別のヒューリスティックを使用します。一度に1つの機能をスローし、他のすべての機能に取り組んでいるときに結果を確認します。 結果が改善される場合、それは炉内の特徴を意味します。



フィーチャの検索によりフォレストが生成され、アパートメントがウォームアップされる一方で、次のようにロジスティック回帰をトレーニングし、xgboostで遊んでみたい 以前は使用していません（はい、はい）。



最初に、利用可能なサインに対してロジスティック回帰を試みました（もちろん、それらを正規化することを忘れずに）。次に、すべての機能を次のように変換することにしました。



-パーセンタイルで等しいサイズの1 / NのN間隔でフィーチャのすべての値を打ちます

-機能値をoheとしてエンコードします。 例の特徴値が間隔に該当する場合-1を設定し、そうでない場合は0を1つの値から合計して、長さNのベクトル[0 0 ... 0 1 0 ... 0]を取得します。



アイデアは次のとおりです-プレーヤーの異なるレベル（プレイした日数、星の数など）がターゲット変数に非線形に影響し、この非線形をこの変換された形式の線形モデルに持ち込むことができます（ただし、 、切り捨てられた「グループ」バージョン）。



このような変換では、クロス検証で約0.3836が得られました-ロジスティック回帰では悪くありません（後で判明したため、改善される可能性があります）。



それから彼はxgboostに進み、その時点でのランダムフォレストとほぼ同じ（0.3812前後）のクロス検証に十分なソリューションをすばやく得ました。



その後、クロス検証用の3つの優れた分類器の結果を1つに追加し、3つに分けて送信しました。 ちなみに、この状況は私だけでなく、問題を解決したすべての友人や知人にも見られました。 それは面白い点に来ました-分類器が交差検証でより良く振る舞うほど、それは私を公共のリーダーボードに引きずりました。 この状況は意欲を弱めるものではなかったため、タスクへの関心は約1週間失われました。



<過去1週間>



ある日、リーダーボードを開いて、友達がどのようにテーブルに上がったのかを見て、ある日（または2日）にすでに20才でした。 「うわー」と思って、袖をまくり、再び仕事を始めました。



チャートをよく見ると、オンラインゲームに1日参加した人がいて、100以上のレベルを持ち、多くのボーナスとポイントを持っていることがわかりました。 これは、人々が実際に長時間プレイするという考えにつながりました。2週間のウィンドウで、機能を数え、たった1日でそれらをフックしました。 maxPlayerLevel、totalStarsCount、totalNumOfAttemptsの各機能に基づいて、使用方法について数日間頭を痛めたため、プレーヤーが再生する「予測日数」という1つの新しい機能を作成することにしました。 アイデアは次のとおりです-選択した機能（たとえば、maxPlayerLevel）に従って各日で低い値（4パーセンタイル以下をすべて取得）を取得し、多項式でかなりよく近づくかなり良いグラフを取得します（おそらく4番目の程度ですが、おそらく3番目の十分）。 多項式を作成すると、プレーヤーの機能値の根を見つけて、プレーヤーがプレイした日数の予測にコストをかけることができます。 次のようになります。







x軸は日数を表し、y軸は選択されたフィーチャの値を表します。 壊れた曲線は4パーセンタイル以下の同じ特徴値で、美しい滑らかな曲線は近似多項式のグラフです。





このようにしてさらに3つの属性を取得した後、彼はそれぞれの新しい機能の初期機能（プレーヤーがゲームに費やした日数を除く）を正規化したため、機能の合計数は4倍に増加しました。 たとえば、次のような機能を開発して追加しました。

 ... X['positiviness'] = X.totalStarsCount*X.totalBonusScore*X.usefulBoosters X['winDesire'] = X.attemptsPerDay*X.numberOfBoostersUsed*X.attemptsOnTheHighestLevel X['positivinessPerWinDesire'] = X.positiviness/(X.winDesire+1) ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、記号の数の増加を考慮して、彼は2次記号を生成せず、利用可能なものから最良の特徴を選択し、アンサンブルを訓練し、最終的には120位から上昇して60位になりました。



Sklearnのロジスティック回帰は、vowpal wabbitの確率的実装に置き換えられました（私自身の執筆のPythonラッパーを使用しましたが、それについて）、間隔に機能エンコードを使用するというアイデアを放棄し、クロス検証ログの結果をわずかに改善しました（ここで相互予測の結果を得るための松葉杖もほとんどありませんでした）。 なぜなら vwがすでに関与しているので、なぜそこからパーセプトロンを使用しないのか（--nnフラグ）-したがって、別の分類子がアンサンブルに追加されました。



さて、vwのパーセプトロンが関係していたので、MLPClassifierを使用しないのはなぜですか。



その後、ランダムフォレストに基づく2つの分類器がアンサンブルに追加されました。 それらのうちの1つは、特徴の値（すべての例、1パーセンタイル以下および99目以上が分類子のトレーニングに参加しなかった特徴の値）に従って毎日偏差が除去されたサンプルでトレーニングされました。



合計で、競争の終わりまでに、アンサンブルは7つの分類子で構成されていました。 これすべてのために通常の相互検証スキームを作成し、多くの苦労をしない方法は？ 構築スキームは次のとおりです。

• 各分類子をプロジェクトの個別のフォルダーに配置します。
• 各分類子は、相互検証の代わりに、列車で相互予測を行い、結果を独自のフォルダー内のファイルに追加し、明確な末尾を付けます（これらのファイルの検索を容易にするため）。
• 各フォルダーで、トレイン全体に対して1つの分類子をトレーニングし、テストサンプルに述語を作成します。これは、フォルダー内のファイルに特定の末尾を付けて配置します。
• 分類子フォルダーの上のディレクトリで、一般的なアンサンブルスクリプトを作成します。これは、相互検証のために、必要なすべての分類子フォルダーからすべての相互予測を読み込み、必要なルールに従ってそれらをアンサンブル結果に変換し、必要なメトリック（ログ損失）を計算します。
• アンサンブル検証結果を受け取った後、各フォルダーから予測を読み込み、同じルールに従ってそれらを変換して、テストサンプルのアンサンブル予測を取得します。
• 最後の仕上げを追加します。

最終日

最終日、ソリューションが既に組み立てられて送信されたとき、私の最高の結果は37位で公開され、クロス検証ではログロス0.37906093が得られました。 2位になったことは、Skypeでの友人のメッセージから学んだ。 私はそれが冗談だと​​思ったが、サイトに行くと、それは本当に真実だと確信した。

役に立つヒント

「有用」という言葉は意図的に引用符で囲まれています。 それらのほとんどは、機械学習コンテストでの勝利に関するすべてのストーリーで複数回発見されています。

• 最初は、1日中美しいグラフを描いたり、統計情報を読んだり、その他のトリックを実行したりするべきではありませんが、最初の提出をお勧めします。 これに1〜2時間を費やし、テーブルの場所を気にしないでください。 これにより、最初から怠inessを打ち負かし、タスクを正しく理解したかどうか、提出システムが大会の主催者側で機能するかどうか、回答のあるファイルが正しく形成されているかどうかなどを確認できます。
• 最初の提出後、データ、統計、グラフを見て、タスクの内容を理解してください。 たとえば、この問題では、何らかの理由で、最初にサンプルの例が作成されたすべての人々が最初の日から遊び始め、その後誰かが途中で停止し、慎重な検査の方法を適用した後にのみ、これに気づいたと思いましたそうではありません。
• 可能なすべてのコピーを作成しながら、各変更、各エクスペリエンス、および各アイデアを個別にチェックする必要があります。 可能であれば、もちろんバージョン管理システムを使用する必要がありますが、場合によってはバージョン管理システムなしでも実行できます。 たとえば、ipythonノートブックで作業している場合、次の実験を実行する前にラップトップのコピーを作成します。 ハードディスクのスペースは、希望するソリューションを提供する「正しい」正しいオプションを探すのに費やす神経よりもはるかに安価です。
• 思いついたアイデアを書き留めるボード、ノートブック、またはプログラムを入手してください。 たとえば、私はtrelloを使用しています。そこでは、「新しいアイデア」、「作業中のアイデア」、「壊れたアイデア」の3つのグループのカードがあります。 私は最初のグループに新しいアイデアを書き留め、その後、実験の後、彼女は2番目または3番目に移動します。
• 相互検証し、現在のエクスペリエンスをテストするために予測ファイルを作成することを忘れないでください。 また、良い方法（良いとは言えないにしても）は、トレーニングセットにクロス予測を使用してファイルを書き込むことです。 モデルをアンサンブルに組み合わせると、長所が明らかになります。
  
  
  
  
• 相互検証の結果を信じる

  
  
  

謝辞

Mail.ru、そして素晴らしいコンテストとギフトを提供してくれたIlya Stytsenkoと彼のチームに感謝します。 競争の中で私の友人やライバルに（そしてそれだけでなく）彼らのサポート/話す/相談し、意見を共有する機会に深い感謝を表明します。 あなたの忍耐と忍耐に再び感謝します。