ML Boot Camp V、3位の決定履歴

7月中旬に、Mail.RuマシンブートコンテストML Boot Camp Vが終了しました。 古典的な健康診断の結果に従って、心血管疾患の存在を予測する必要がありました。 メトリックは対数損失関数でした。 タスクの詳細な説明はこちらから入手できます 。



私にとって機械学習の知識は、2017年2月のML Boot Camp IIIから始まり、そのようなタスクをどう処理するかについてのある種のアイデアが、今まさに形になり始めています。 第5回コンテストで行われたことの多くは、まず第一に、kaggleに関する記事のコレクション、ディスカッション、およびそこからのコード例を検討した結果です。 以下は、3位を獲得するために何をしなければならなかったかについて、わずかに改訂されたレポートです。

タスクデータ

データセットは、100,000の実際の臨床テストから形成されます。 年齢、身長、体重、性別、上血圧と下血圧、コレステロール、血糖値が与えられます。



さらに、「主観的な」証拠があります-患者が自分自身について報告し、喫煙、アルコール消費、身体活動に関する質問に答えた データのこの部分も主催者によって台無しにされたので、私は彼らに特に希望はありませんでした。



初期データには明らかに非現実的な値が含まれていました。3020年以上で50 cmの成長があり、16020のような圧力と負圧圧力がありました。 これは、分析データを手動で入力する際のエラーによって説明されました。

ツール

タスクは、この場合の標準ライブラリを使用してPythonで解決されました。

• パンダ -表形式データの読み書きと処理（実際にはもっとたくさんありますが、この場合は残りは必要ありませんでした）;
• NumPy-数値の配列に対する操作。
• scikit-learn-基本的なMOアルゴリズム、データ分割、検証など、機械学習用のツールセット。
• XGBoost-勾配ブースティングの最も一般的な実装の1つ。
• LightGBM -XGBoostの代替品。
• TensorFlow + Keras-ニューラルネットワークのトレーニングと使用のためのライブラリとそのラッパー。
• Hyperopt-指定された引数スペースで関数を最適化するためのライブラリ。

CSVとピクルス

長い計算中にデータを保存するために、別々のテーブルよりも複雑な構造を一緒に保存する必要があるまで、最初にcsvを使用しました。 pickleモジュールは非常に優れていることが判明しました。必要なデータはすべて2行のコードで保存または読み取られます。 後で私は圧縮ファイルに保存し始めました：

with gzip.open('../run/local/pred_1.pickle.gz', 'wb') as f: pickle.dump((x, y), f)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リポジトリ

すべての競争コードはgithubにあります。 古いスクリプトはold /のリポジトリに隠されていますが、実際のメリットはなく、作業の結果も検証のために送信されたために残されています。 コードのエラーにより、実行の中間結果は後で使用に適さないことが判明したため、コードのこの部分は最終決定に影響しませんでした。

最初の2週間

最初の2週間でデータをクリーンアップし、過去の競技会の残りのモデルに置き換えましたが、これはあまり成功しませんでした。 新しいサブミットごとに、既存のスクリプトの1つからのコード全体が新しいスクリプトに完全にコピーされ、そこで編集されています。 結果-2週目の終わりには、最後のスクリプトが何をしていたのか、どのスクリプトで実際に使用されていて、どのスクリプトが実行されたのかがわかりませんでした。 コードは扱いにくく、読みづらく、数時間動作し、まったく有用なものを何も保持せずにクラッシュする可能性がありました。

後の2週間

開始から2週間後、古いスクリプトをコピーして少し変更することが非常に困難になったとき、コード全体の完全な変更を開始する必要がありました。 基本クラスとその特定の実装-一般的な部分に分割されました。



新しいコード編成の一般的な考え方は、データ→属性→レベル1モデル→レベル2モデルのパイプラインです。 各ステージは個別のスクリプトファイルを実装し、起動時に必要なすべての計算を実行し、それら、中間結果、およびデータを保存します。 次の各ステージのスクリプトは、前のステージのコードをインポートし、メソッドから処理用のデータを受け取ります。 このすべての背後にある考え方は、最終モデルの1つに対してスクリプトを実行できるようにするために、下位レベルのモデルに対してスクリプトを実行し、必要な属性ジェネレーターを呼び出して、データクリーニングに必要なオプションを起動するということです。 各スクリプトのタスクは、ファイルが存在するかどうか、その結果を保存する場所を確認し、存在しない場合は必要な計算を実行してデータを保存することです。



その背後には、適切なタスクでデバッグしながら、将来の使用のためにモデルとデータを整理する決定を下す計画がありました。 実際、この決定はコンテストの最も重要な結果でした。このコンテストは、この種の後続のコンテストに参加する際の生活を楽にするために、徐々に小さな図書館に発展しています。

一般計画

最初は2レベルのモデルが計画されていましたが、第1レベルではできるだけ多くの異なるモデルを準備する必要がありました。 これを実現する方法は、可能な限り多くの異なる処理データを準備し、その上で同じモデルをトレーニングすることです。 しかし、データの準備には長い時間がかかります。 データを操作することが成功の鍵ですが（十分な数の有意義な記号を追加することで最も簡単なモデルを使用できます）、必要以上に時間がかかります。 代替手段はブルートフォースソリューションです。つまり、比較的中程度のデータ処理と最大計算時間です。



このアプローチで最も簡単なことは、いくつかの方法でデータを処理し、いくつかの追加機能セットを考え出し、それらの組み合わせを使用することです。 ランダム部分空間法のわずかな変形が判明しますが、完全なものとは異なり、まったくランダムではなく、グループによってすぐに記号が選択されます。 そのため、少数の追加機能を使用して、処理されたデータの数百のオプションを取得できます（実際には、クリーニング方法の数*（2 ^特性グループの数））。 そのようなアプローチは、それぞれがレベル2モデルの品質を向上させるために、特徴の異なるサブセットを使用する単純なモデルにまったく異なるソリューションを提供すると想定されていました。

データ準備

元のデータが汚れていたという事実は、何らかの形で考慮しなければなりませんでした。 主なアプローチは、明らかに不可能な値をすべて破棄するか、何らかの方法で元のデータを復元することです。 そのような歪みの原因はほとんど最後まで不明のままであったため、いくつかの方法でデータを準備し、それらの異なるモデルをトレーニングする必要がありました。



各データ処理オプションは、処理されると、対応する変更を含む完全なデータセットを返すクラスによって実装されます。 この段階でのデータ処理は非常に速く経過するため、中間結果は比較的長いバージョン（2）でのみ保存されました-xgboostを使用した主観的な属性の復元。 残りのデータは要求に応じて生成されました。



処理オプション：

1. テストの主観的な部分の損なわれた値を0.0001に置き換えて、数値形式にするが、無傷のものと区別するための初期データ。
2. 破損した自覚症状は置き換えられました。アルコール消費-0、アクティビティ-1。さらに、残りのデータ列では、喫煙は「回復」しました。
3. 自覚症状が復元されたデータでは、極端な圧力値が消去されます。
4. 復元された自覚症状のあるデータ（2項から）では、圧力、体重、身長の極端な値が消去されました。
5. 精製された圧力のみのデータ（条項3から）では、重量、高さ、圧力がさらにクリーニングされます。
6. 精製された圧力のデータはさらに変換されます-成長、体重、または圧力の個々の信じがたい値はすべてNaNに置き換えられます。

サイン

処理されたデータから追加の特性が生成されました。 それらの意味のあるものはほとんどありませんでした-ボディマスインデックス、性別、体重、古いフォーミュラによる年齢に応じた期待圧力値など かなり簡単な方法で、データを含むさらに多くの列が自動的に取得されました。



追加の属性は、処理されたデータのさまざまなバリアントから生成されましたが、多くの場合同じ方法で生成されました。 特性の一部は値を再計算するのに時間がかかりすぎる可能性があるため、記号の列は別々に保存されました。 スクリプト内の属性の計算は、データクリーニングと同様に実装されました。各スクリプトでは、属性の追加の列を返すメソッドが決定されました。



追加機能のグループ：

1. 最も単純な意味のある兆候は、 BMI 、脈圧、タイプの圧力の平均値です $$ $ inline $ \ frac {ap \ _hi + x * ap \ _lo} {x + 1} $ inline $ xの異なる値に対して。 年齢/体重ごとに圧力を計算するための近似式も取得され、各患者について予想される圧力が計算されます（形式の式 $$ $ inline $ ap \ _X = a + b * age + c * weight $ inline $ ） 生の値に基づいて計算されます。
   
   
   
   
2. 請求項1と同じですが、さらに、利用可能な圧力に基づいて、患者の体重を回復する試みが行われました。 この方法で予測された各記号について、「実際の」値との差が追加されます。 生の値に基づいて計算されます。
3. 文字で区切られた生データ列のテキスト表現-最初は左側に配置され、次に右側に配置されます。 シンボルは、数値（ ord（） ）に置き換えられます。 行が短すぎてすべての列に十分ではない場合、-1が設定されました。
   
   
   
   
4. 請求項3と同じですが、結果の列はバイナリエンコード（ワンホットエンコード）です。
   
   
   
   
5. パラグラフ4のデータはPCAを通過しましたが、 メルセデスの kaggleでの最近の競争の重い遺産です。
   
   
   
   
6. 年齢を除くすべての生のソース列について、ターゲット列の平均値が計算されます。 これを行うには、最初に圧力、身長、体重の値を10で割り、丸めて、それらからカテゴリ属性を取得します。 次に、データを10分割し、それぞれについて9分割し、各カテゴリについてターゲット列の加重平均値（病気、病気ではない）を計算しました。 平均値を計算するものが何もない場合、私は単純にグローバル平均値を記録しました。
   
   
   
   
7. 請求項6と同じですが、平均は請求項2の特性についても計算されました。
   
   
   
   
8. パラグラフ7と同じですが、オプションNo. 5に従ってクリーニングされたものが初期データとして使用されました。
   
   
   
   
9. パラグラフ7と同じですが、オプションNo. 3に従ってクリーニングされたものが初期データとして使用されました。
   
   
   
   
10. 生データはk-means法によってクラスター化され、クラスターの数は任意に選択されます（2、5、10、15、25）。これらの各ケースのクラスター番号はバイナリエンコードされます。
    
    
    
    
11. パラグラフ10と同じですが、使用されたデータはオプション3に従ってクリアされました。

モデル

モデルは非常に長い時間（数十時間）動作し、エラーが発生したり、意図的に中断したりする可能性があるため、最終結果だけでなく中間データも保存する必要があります。 このため、各モデルにはベース名が与えられます。 さらに、モデルの名前とデータに割り当てられた名前から、このデータがあるファイルの名前が取得されます。 すべての保存と読み込みは、モデルの基本的な方法で行われます。これにより、中間データが均一に保存されます。 将来の計画-ファイルではなく、データベースにデータを保存します。 使用される実装の欠点は、モデルをコピーするときに名前を更新することを忘れて、元のモデルとそのコピーのデータの未定義状態を取得できることです。



モデルが計算結果を保存している場合、残っているのはそれらを読み取って呼び出し元に返すことだけです。 中間結果のみがある場合は、それらを再読み取りする必要もありません。 これにより、特に数時間のコンピューティングに関しては、多くの時間を節約できます。



モデルによって保存されるデータの主な分離は、このデータの寿命です。 このような各データグループには、保存用の独自のベースパスがあります。 合計で3つのグループがあります。

1. 次回の起動時に使用されない一時的なもの、たとえば、個々のフォールドに対するニューラルネットワークの最適な重み。
2. これらのモデルは、次の起動時に必要になります-他のほとんどすべて。
3. 追加機能など、いくつかのモデルに役立つグローバルに役立つデータ。

すべてのモデルのインターフェースは共通であり、通常のスクリプトとして個別に実行できるだけでなく、Pythonモジュールとしてロードすることもできます。 一部のモデルが他のモデルの結果を必要とする場合、それらをロードして実行します。 その結果、レベル2の各モデルの説明は、結果を組み合わせる必要があるモデルの名前のリストと、貪欲なアルゴリズムで記号を選択する必要性の記号に縮小されました。



モデルの中にはニューラルネットワークに基づいたものがあり、出力では非常に自信のある0または1または極値に非常に近い値を与えることができました。 エラーが発生した場合、そのような自信は対数損失により非常に細かく罰金が科せられるため、保存時にすべてのモデルの値が切り捨てられ、少なくとも1e-5が0または1のままになりました。 最も簡単な方法は、np.clip（z、1e-5、1-1e-5）を追加して、それを忘れることです。 その結果、すべてのモデルのデータはカットされましたが、それらのほとんどはすでに約0.1〜0.93の範囲の結果をもたらしました。

ハイパーオプト

モデルのパラメーターを調整するには、hyperopt （ 詳細 ）を使用する必要がありました。 結果は改善されましたが、長い間、特に遅いモデルでは、試行回数を約20に設定しました。また、終了の2日前に、 記事に記載されているハイパーオプトブートストラップが見つかりました-デフォルトでは、最初の20回のモデル起動はランダムパラメーターで実行され、 ソースで確認できます。 モデルのいくつかを早急に詳しく説明する必要がありました。

レベル1モデル

各モデルの入力データの選択は、レベル1モデルの一般的なコードに分類されます。ソースデータと0個以上の属性グループをクリーニングするためのオプションは常に1つです。 共通のデータセットへのデータと機能のコレクションは、モデルに共通のコードで実装されます。 これにより、個々のモデルのコードが削減され、特定の初期データと追加機能が指定されました。



最適化のための共通コードを作成するのに十分な時間がなかったため、個々のベースレベル1モデルは依然として互いに強くコピーします。 合計で、2種類が判明しました。

• ニューラルネットワーク（keras）
• 木（XGBoost、LightGBM、rf、et）

ニューラルネットワークに基づいて使用されるモデルの主な違いは、ハイパーパラメーターの適合がないことです。 他のモデルでは、hyperoptが使用されました。

ニューラルネットワーク

私はニューラルネットワークのパラメーターを真剣に選択しなかったため、結果はブースティングの結果よりも悪かった。 チャットの後の方で、 64-64のような漏れやすいreluアクティベーションと、 各層 に 1〜5個のニューロンのドロップアウトがあり、比較的適切な結果が得られたネットワークデバイスについて言及しました。



私は自宅でニューラルネットワークをほぼ次の形式で使用しました。

• 入り口;
• 数百のニューロン（通常256）。
• ある種の非線形性、ドロップアウト（それがあった場所-パラメータが多すぎてネットワークが再トレーニングしていると考えたため、0.7のオーダーの値を取りました）; トレーニング中にモデルがnan-sに分岐した場合-バッチ正規化を追加-詳細はこちらまたはこちら 。
• 100個または2個のニューロン（64-128）;
• 非線形性;
• 1ダースまたは2ニューロン（16）;
• 非線形性;
• 古典的なシグモイド出力を備えた1つの出力ニューロン。

同様のデバイスは、以前の競合からほとんど変更されずに移行しました。 それとは別に、ニューラルネットワークはあまりうまく表示されませんでしたが、レベル2モデルの計算にその結果を使用するために残されました。



内側の層のアクティベーション関数の選択は非常に簡単です-利用可能なセットから、すべてのシグモイドバリアントを除外しました（0に近い値境界付近の勾配のため）、「クリーン」ReLU（トレーニングから出力0で出力を開始したニューロンのため）抜けて）残りのものから何かを取りました。 最初は、 Parametric Reluでしたが、 Scaled Exponential Linear Unitsを取り始めた最新モデルではそうでした。 このような置換との大きな違いに気付くことはできませんでした。



他のモデルと同様に、ニューラルネットワークのデータは、sklearnのKFoldを使用してフォールドで戦った。 各パーティションのトレーニングでは、モデルを再構築せずにネットワーク層の重みを再初期化する方法を遅すぎたため、モデルを新たに構築する必要がありました。



検証用に割り当てられたデータの一部の予測の品質が向上するまで、ネットワークをトレーニングしました。 同時に、検証の結果が改善されるたびに、ネットワークの重みが節約されました。 これを行うには、標準のコールバックとkerasを使用して、検証の最良の結果でネットワークの状態を保存し、トレーニングサンプルの特定のパスで検証結果が改善しなかった場合はトレーニングを早期終了し、結果が複数のパスで改善しなかった場合は学習率を下げます。



ネットワークトレーニングが停止（ローカルミニマム）になり、データによると数回のパスで結果が改善されない場合、学習率は低下し、これが役に立たない場合は、トレーニングを数回移動すると停止しました。 トレーニング後、トレーニング期間全体のネットワークウェイトの最適な状態がロードされました。



同時に、複数のネットワークをトレーニングするときに同じコールバックインスタンスのセットを数回使用しようとすると、十分に遅れて問題に気付きました。 この場合、新しいネットワークのトレーニングの開始時のコールバックの状態は、最初のネットワークに自動的にリセットされません。 その結果、各新しいネットワークの学習率はますます低下し、同じコールバックが使用されたすべてのネットワークで以前に得られたすべてよりも良くない場合、最良の結果は保存されませんでした。

ツリーベースのモデル

ランダムフォレストと余分なツリーのバギングに基づいた「ウッディ」モデルの2つのバリアントと、XGBoostとLightGBMの2つの勾配ブースト実装を使用しました。 ランダムフォレストの両方のバリアントは、交差検証とパブリックの両方でパフォーマンスが低いため、多くのコンピューター時間を費やさなければならず、モデルの結果を組み合わせるときに役立つことが期待されたため、単に残りました。 LightGBMとXGBoostのパフォーマンスは大幅に向上し、第1レベルの予測のほとんどはそれらから受信されました。



パラメーターを適合させた後、乱数ジェネレーターのいくつかの（通常は3つの）初期状態について、各「木質」モデルを計算しました。 そのような結果はすべて、レベル2モデルで使用するために個別に保存されました。 レベル1モデルの予測は、RNGの最後に使用された状態の結果から取得されました。



LightGBMとXGBoostは、指定された反復回数の検証で学習の質が改善されない場合、学習を停止する機能を提供します。 このため、10,000件の手順を学習し、検証結果が改善しなくなった時点で停止することができました。 その結果、そのようなモデルのパラメーターを選択するときに、ツリーの数を選択する必要はありませんでした。 ランダムフォレストやsklearnからの余分なツリーのような可能性はありません。そのため、ツリー数の選択をhyperoptにシフトする必要がありました。 検証自体の品質をチェックするたびに、それらを1つのステップでトレーニングすることはできましたが、怠lazがそれを防ぎました。

種が少ない

個々のモデルの作業の結果は、乱数ジェネレーターの状態に大きく依存します。 この依存関係を取り除くために、レベル1のトレーニングモデルでは、いくつかのSIDを使用した学習結果が計算されました。 さらに、各シードについて、結果は個別に保存されました。 同時に、コンテスト終了後、最後のシードの結果が別のレベル1モデルによって保存された結果として使用されることが判明しました。 残りの結果は引き続き保存され、レベル2モデルで使用されました。

レベル2モデル

レベル1の各モデルが1〜4回の予測を行ったという事実により、レベル2では、データには最大190列が含まれていました。 最初のデータと兆候はそこに到達しませんでした-すでに予測された確率のみ。 レベル2モデルのそれぞれは、レベル1モデルのサブセットを組み合わせました（一部は初期レベル2モデルの結果を使用しました）。



レベル2のすべてのモデルはほぼ同じ方法で配置されます-モデルのモジュール名でロードし、それらの作業の結果を取得し、ロードから使用する列のオプション選択と、予測を結合するための回帰パラメーターのフィッティング。



うまくいかなかったのは、別のレベルを追加し、すべてのレベル2モデルの予測を結合しようとしたことです。そのような公共の組合の結果は非常に悪かったので、私は二度目の試みをすることすら考えていませんでした。



組み合わせで最良の結果が得られる予測の一部を選択する際に、「貪欲な」アルゴリズムが使用されました-使用可能なものから最良の列の1つが選択され、その後、サイクルで残りの列が以前に選択された列に1つずつ追加されました検証のレベル2モデルの結果が改善されるまで、列の追加が続けられました。さらに、時間を節約するために、選択のモデルとしてBayesianRidgeが使用されました。その結果は、パラメータが適切に調整されたRidgeに次ぐものでした。この選択の結果、通常約20列のデータが残りました。



最終的な計算では、選択は最初に利用可能なすべてのリグレッサーのハイパーオプトを介して実行されましたが、sklearnのBayesianRidgeとRidgeのみが多少適切に表示されていたため、最終的にコードは縮退し、BayesianRidgeモデルを組み合わせてリッジパラメーターをフィッティングすることでこの結果を改善しようとしました。

検証

最初は10倍で検証されています。同時に、一部のモデルは0.534-0.535でcvを示し始め、0.543-0.544またはそれよりも悪い結果を公表しました。コンテストの終わりに向かって、検証中と公開中に結果を近づけるために、分割を30倍に増やしました。数30の選択は、プロセッサの能力に基づいています-1つのモデルの計算に10時間未満しか必要としない最大値を選択しました。



この場合、すべて同じように、一部のモデルは0.535〜0.536のレベルで検証されました。これは、一般の0.543程度の結果を背景に、検証スキームの妥当性について疑問を呈しました。競技終了の約3日前に、トレーニングデータから0.7と0.3の30のランダムパーティションを30分割に追加する必要がありました。正確に30を選択するのは、cv-プロセッサの能力と同じ理由です。すべてのパーティションはrandom_stateによってコミットされました。その後、検証の最良の結果は約0.537でした。



これも望ましいものとはほど遠いものでしたが、最後のモデルがカウントされるまで待つのに十分な数日しか残っていなかったので、そこで止めなければなりませんでした。その結果、私は2件の提出を選択しました。結果は、公開で0.543、検証で0.538を上回りました。後に判明したように、このような12の提出物のうち、7が3位になり、見逃すものは何もありませんでした。