SNA Hackathon 2019ファイナルは4月1日に終了し、その参加者は、最新の機械学習技術、コンピュータービジョン、テスト処理、および推奨システムを使用してソーシャルネットワークフィードのソートに参加しました。 ハードなオンライン選択と160ギガバイトのデータに対する2日間のハードワークは無駄ではありませんでした:)。 参加者が成功するために何が助けになったか、その他の興味深い観察について話します。

データとタスクについて

競争は、 OKソーシャルネットワークのユーザーのフィードを準備するメカニズムからのデータを提示しました。

• コンテンツ表示ログは、ユーザー、コンテンツ、作成者、およびその他のプロパティを説明する多数の記号とともにユーザーフィードに記録されます。
• 表示されたコンテンツに関連するテキスト。
• コンテンツで使用される画像の本体。

データの合計量は160ギガバイトを超えますが、そのうち3つ以上がログ用、3つ以上がテキスト用、残りが写真用です。 大量のデータは参加者を驚かせませんでした： ML Bootcampの統計によると、ほぼ200人がコンテストに参加し、3,000を超える提出物を送信しました。 たぶん、彼らは700,000ルーブルと3枚のGTX 2080 Tiグラフィックスカードの賞金プールに動機付けられました。

コンテストの参加者は、テープの並べ替えの問題を解決する必要がありました。個々のユーザーごとに、「クラス！」マークを取得したオブジェクトがリストの先頭に近づくように表示オブジェクトを並べ替えます。

ROC-AUCが品質評価指標として使用されました。 同時に、メトリックはすべてのデータ全体としてではなく、ユーザーごとに個別に考慮されてから平均化されました。 この計算オプションは、多くのクラスに属するユーザーを区別することを学習したアルゴリズムが利点を享受しないという点で注目に値します。 一方、標準のPythonパッケージにはそのようなオプションはありません。これにより、以下で説明するいくつかの興味深い点が明らかになりました。

技術について

従来、SNA Hackathonはアルゴリズムであるだけでなく、テクノロジーでもあります。出荷されるデータの量は160ギガバイトを超えており、参加者は興味深い技術的なタスクに直面しています。

寄木細工vs. Csv

学術研究およびKaggleでの主要なデータ形式はCSVであり、その他のプレーンテキスト形式です。 ただし、業界の状況は多少異なります。「バイナリ」ストレージ形式を使用すると、はるかにコンパクトで処理速度が向上します。

特に、 Apache Sparkに基づいて構築されたエコシステムでは、 Apache Parquetが最も人気があります。これは、多くの重要な運用機能をサポートするデータを格納する列形式です。

• 進化をサポートする明示的に指定された回路。
• ディスクから必要な列のみを読み取ります。
• 読み取り時のインデックスとフィルターの基本的なサポート。
• 文字列圧縮。

しかし、明らかな利点にもかかわらず、Apache Parquet形式での競争のためのデータの提出は、一部の参加者からの厳しい批判に会いました。 保守主義と何か新しいものの開発に時間を費やすことを望まないことに加えて、いくつかの本当に不快な瞬間がありました。

第一に、PythonのParquetを操作するための主要ツールであるApache Arrowライブラリーでの形式のサポートは、完璧とはほど遠いです。 データを準備するとき、すべての構造フィールドをフラットに拡張する必要がありましたが、それでもテキストを読むとき、多くの参加者がバグに遭遇し、その時点で現在のバージョン0.12ではなく、古いバージョンのライブラリ0.11.1をインストールすることを強制されました。 第二に、単純なコンソールユーティリティ（cat、lessなど）を使用してParquetファイルを表示しません。 ただし、 parquet-toolsパッケージを使用すると、この欠点を比較的簡単に補うことができます。

それでも、最初にすべてのデータをCSVに変換してから使い慣れた環境で作業しようとした人は、最終的にこの考えを放棄しました。結局、Parquetはかなり速く動作します。

ブースティングとGPU

「狭いサークルで広く知られている」サンクトペテルブルクで開催されたSmartData会議で、Alexey NatekinはCPU / GPUでの作業中にいくつかの一般的なブースティングツールのパフォーマンスを比較しました 。 しかし、それでも、この結論は、主に国内のCatBoostツールの開発者による活発な論争につながりました。

過去2年間で、GPUの開発とアルゴリズムの適応の進歩は止まらず、SNA HackathonファイナルはCatBoost + GPUペアの勝利と考えることができます-すべての勝者はそれを使用し、主に単位時間あたりにより多くの木を育てる能力のためにメトリックを引き出しました。

平均ターゲットエンコーディングの統合された実装は、CatBoostに基づくソリューションの高い結果にも貢献しましたが、ツリーの数と深さはより大幅に増加しました。

他のブースティングツールも同様の方向に進んでおり、GPUサポートを追加および改善しています。 だから、もっと木を育てましょう！

スパークvs. Pyspark

Apache Sparkツールは、一部はPython APIのおかげで、産業データサイエンスの強力なリーダーです。 ただし、Pythonを使用すると、異なるランタイムとインタープリターを統合するためのオーバーヘッドが追加されます。

ユーザーは、このアクションまたはそのアクションがもたらす追加コストの量を認識していれば、それ自体は問題になりません。 しかし、参加者がApache Sparkを使用しなかったという事実にもかかわらず、非常に多くの人が問題の大きさを認識していないことが判明しました。 Scalaはハッカソンチャットに定期的に登場し、対応する解析済みの投稿が表示されました 。

要するに、Scala / Java経由でSparkを使用する場合と比較して、Python経由でSparkを使用する場合の速度低下は、次のレベルに分類できます。

• Spark SQL APIのみがユーザー定義関数（UDF）なしで使用されます-この場合、クエリ実行計画全体がJVMのフレームワーク内で計算されるため、実質的にオーバーヘッドはありません。
• UDFは、C ++コードでパッケージを呼び出すことなくPythonで使用されます。この場合、UDFが計算される段階のパフォーマンスは7〜10倍低下します。
• UDFはPythonでC ++パッケージ（numpy、sklearnなど）にアクセスして使用されます。この場合、パフォーマンスは10〜50倍低下します。

一部には、 PyPy （PythonのJIT）とベクトル化されたUDFを使用することでマイナスの影響を補うことができますが、これらの場合でもパフォーマンスの違いは複数あり、実装と展開の複雑さには追加の「ボーナス」が伴います。

アルゴリズムについて

しかし、データサイエンスハッカソンで最も興味深いのは、もちろんテクノロジーではなく、ファッショナブルで実績のある新しいアルゴリズムです。 CatBoostは今年SNA Hackathonを支配しましたが、いくつかの代替アプローチがありました。 それらについてお話します:)。

微分可能なグラフ

予選の結果に基づく決定の最初の出版物の 1つは、木ではなく微分可能なグラフ（人工ニューラルネットワークとも呼ばれます）専用でした。 著者はOKの従業員であるため、賞品を追いかける余裕はありませんが、堅実な数学的基盤に基づいて有望なソリューションを構築することを楽しんでいます。

提案されたソリューションの主なアイデアは、利用可能な機能を入力データのさまざまな側面を考慮した予測に変換する単一の計算可能な微分可能グラフを構築することでした。

• オブジェクトとユーザーの結合を使用すると、古典的な共同推奨の要素を追加できます。
• MLPを介したスカラー埋め込みから集約への移行により、任意の特性を追加できます。
• query-key-valueの注意により、モデルは最近の履歴を見ている以前は不慣れなユーザーの動作にも動的に適応することができました。

このモデルは、テキストコンテンツを推奨する問題を解決するオンライン選択に非常に優れていることが判明したため、複数のチームが決勝で一度にプレイしようとしましたが、成功しませんでした。 これは、これには時間と経験が必要であるという事実と、ファイナルの属性の数がはるかに多く、ツリーに基づくメソッドがそれらのために大きな利点を受け取ったという事実が原因でした。

共同支配的

もちろん、コンテストを開催するとき、ログにかなり強いシグナルがあることがわかりました。そこに収集された兆候は、フィードのランキングに関するOKで行われた作業の大部分を反映しているためです。 それにもかかわらず、最後まで、参加者が「3番目の兆候」に対処することに成功することを望んでいました-コンテンツ（テキストと写真）から属性を抽出するためのモデルの開発に巨大な人的資源と機械的資源が投資した状況は、すでに比べて非常に控えめな品質の向上をもたらします準備された、主に協力的な特性。

この問題を知って、最初に予選ラウンドでタスクを3つのトラックに分割し、最終的にのみ結合データセットを形成しましたが、ハッカソン形式で固定メトリックを使用して、コンテンツモデルの開発に投資したチームは、共同で開発しているチームと比較して意図的に負けた状況に陥りました一部。

ju審員賞は、この不正を補うのに役立ちました...

ディープクラスター

これは、FacebookからDeep Clusterアルゴリズムを再現およびテストする作業に対してほぼ満場一致で授与されました。 クラスターと画像の埋め込みを構築するための初期のマークアップを必要としないシンプルな方法は、アイデアの新規性と有望な結果を魅了しました。

この方法の本質は非常に簡単です。

1. 意味のあるニューラルネットワークで画像の埋め込みベクトルを計算します。
2. 結果の空間でベクトルをk-meansでクラスター化します。
3. 画像のクラスターを予測するためのニューラルネットワーク分類器をトレーニングします。
4. 収束するまで（800 GPUがある場合）、または十分な時間があるまで、手順2〜3を繰り返します。

最小限の労力で、OK画像の高品質なクラスタリング、適切な埋め込み、3桁目のメトリック増加を達成することができました。

未来を見る

どのデータでも、予測を改善するための「抜け穴」を見つけることができます。 それ自体はそれほど悪くはありません。抜け穴が発見され、長い間、履歴データの検証結果とA / Bテストの間に不可解な矛盾の形でしか現れない場合、それははるかに悪いです。

この種の最も一般的な抜け穴の1つは、将来の情報の使用です。 このような情報は多くの場合非常に強力な信号であり、機械学習アルゴリズムが有効になっている場合、自信を持って使用し始めます。 製品のモデルを作成するとき、将来からの情報漏洩を避けるためにあらゆる方法で努力していますが、ハッカソンでは、参加者が使用したメトリックを上げる良い機会です。

最も明らかな抜け穴は、これらのフィールドにnumLikesとnumDislikesが存在し、ショーの時点でオブジェクトに反応カウンターがあったことです。 同じオブジェクトに関連する時間的に最も近い2つのイベントを比較することで、最初のイベントに対するオブジェクトの反応を高精度で判断できました。 データには同様のカウンターがいくつかあり、それらを使用すると顕著な利点が得られました。 当然、実際の使用では、そのような情報は利用できません。

人生では、同様の問題に気付かずにつまずく可能性があり、通常は否定的な結果をもたらします。 たとえば、マークの数に関する統計をカウントする「クラス！」 すべてのデータに応じて、オブジェクトを個別の属性として取得します。 または、参加チームの1つで行ったように、カテゴリ属性としてオブジェクト識別子をモデルに追加します。 トレーニングセットでは、このような機能を備えたモデルはうまく機能しますが、テストセットに一般化することはできません。

結論の代わりに

参加者の決定に関するデータやプレゼンテーションを含むすべてのコンテスト資料は、 Mail.ru Cloudで入手できます。 データは、リンクの可用性を除いて、制限なしに研究プロジェクトで使用できます。 ストーリーについては、最終チームのメトリックを含む最終テーブルをここに残しましょう。

1. Scalaのしゃがみ、Python-0.7422の非表示、ソリューションの解析はここから入手でき、コードはこことここにあります 。
2. マジックシティ-0.7256
3. ケフィア-0.7226
4. チーム6-0.7205
5. ボートの3-0.7188
6. ホール＃14-0.7167および審査員賞
7. BezSNA-0.7147
8. ポンガ-0.7117
9. チーム5-0.7112

SNA Hackathon 2019は、シリーズの以前のイベントと同様、あらゆる意味で成功しました。 さまざまな分野のクールな専門家を1つの屋根の下に集め、実り多い時間を過ごすことができました。参加者自身と組織を助けてくれたすべての人に感謝します。

何かもっと良くできたでしょうか？ もちろんそうです！ 開催された各コンペティションは、新しい経験で私たちを豊かにします。次の準備をするときに考慮し、そこで止まるつもりはありません。 SNAハッカソンでお会いしましょう！