2019 年 XNUMX 月から XNUMX 月にかけて、ソーシャル ネットワーク フィードのランキングを競うコンテストが開催されました。 SNAハッカソン2019で、私たちのチームがXNUMX位になりました。 この記事では、コンテストの組織、私たちが試した方法、ビッグデータをトレーニングするための Catboost 設定について説明します。

SNAハッカソン

この名称でのハッカソンの開催は今回でXNUMX回目となります。 これはそれぞれソーシャルネットワークok.ruによって組織されており、タスクとデータはこのソーシャルネットワークに直接関連しています。
この場合の SNA (ソーシャル ネットワーク分析) は、ソーシャル グラフの分析としてではなく、むしろソーシャル ネットワークの分析として理解される方が正確です。

• 2014 年の課題は、投稿が獲得する「いいね！」の数を予測することでした。
• 2016 年 - VVZ タスク (ご存知かもしれません) は、ソーシャル グラフの分析に近づきました。
• 2019 年には、ユーザーが投稿を「いいね！」する可能性に基づいてユーザーのフィードをランク​​付けします。

2014年のことは言えませんが、2016年、2019年はデータ分析能力に加えて、ビッグデータを扱うスキルも求められていました。 私がこれらのコンテストに惹かれたのは、機械学習とビッグデータ処理の問題の組み合わせだったと思います。これらの分野での経験が勝利に貢献しました。

mlブートキャンプ

2019年、コンテストはプラットフォーム上で開催されました https://mlbootcamp.ru.

コンテストは7月3日にオンラインで始まり、XNUMXつのタスクで構成されました。 誰でもサイトに登録してダウンロードできます ベースライン そして数時間車に荷物を積み込みます。 15 月 15 日のオンライン ステージの終わりに、各障害飛越競技の上位 30 名が、1 月 XNUMX 日から XNUMX 月 XNUMX 日まで開催されるオフライン ステージのために Mail.ru オフィスに招待されました。

タスク

ソース データはユーザー ID (userId) と投稿 ID (objectId) を提供します。 ユーザーに投稿が表示された場合、データには userId、objectId、この投稿に対するユーザーの反応 (フィードバック)、およびさまざまな機能のセットや画像やテキストへのリンクが含まれる行が含まれます。

ユーザーID	オブジェクトID	所有者ID	フィードバック	画像
3555	22	5677	[いいね、クリック]	[ハッシュ1]
12842	55	32144	[嫌い]	[ハッシュ2、ハッシュ3]
13145	35	5677	[クリック、共有]	[ハッシュ2]

テスト データ セットには同様の構造が含まれていますが、フィードバック フィールドがありません。 タスクは、フィードバック フィールドでの「いいね」反応の存在を予測することです。
提出ファイルは次の構造になっています。

ユーザーID	ソートされたリスト[オブジェクトID]
123	78,13,54,22
128	35,61,55
131	35,68,129,11

この指標は、ユーザーの平均 ROC AUC です。

データの詳細な説明については、次のサイトを参照してください。 市議会のウェブサイト。 テストや写真などのデータをダウンロードすることもできます。

オンラインステージ

オンライン段階ではタスクは3つの部分に分かれていました

• 連携体制 — 画像とテキストを除くすべての機能が含まれます。
• Изображения — 画像に関する情報のみが含まれます。
• テキスト — テキストに関する情報のみが含まれます。

オフラインステージ

オフライン段階では、データにはすべての特徴が含まれていましたが、テキストと画像はまばらでした。 データセットには 1,5 倍の行があり、すでに多数の行がありました。

問題解決

私は仕事で履歴書を担当しているため、このコンテストへの取り組みは「画像」タスクから始まりました。 提供されたデータは、userId、objectId、ownerId (投稿が公開されたグループ)、投稿の作成と表示のタイムスタンプ、そしてもちろんこの投稿の画像です。
タイムスタンプに基づいていくつかの特徴を生成した後、次のアイデアは、imagenet で事前トレーニングされたニューロンの最後から XNUMX 番目の層を取得し、これらのエンベディングをブースティングに送信することでした。

結果は驚くべきものではありませんでした。 imagenet ニューロンからの埋め込みは無関係なので、独自のオートエンコーダーを作成する必要があると思いました。

かなり時間がかかりましたが、結果は改善されませんでした。

特徴生成

画像を扱うのは時間がかかるので、もっと単純なことをすることにしました。
すぐにわかるように、データセットにはいくつかのカテゴリ特徴があります。あまり煩わしくないように、catboost だけを使用しました。 このソリューションは素晴らしく、何も設定しなくてもすぐにリーダーボードの最初の行に到達しました。

かなりの量のデータがあり、寄せ木細工の形式でレイアウトされているため、よく考えずに scala を使用して、すべてを Spark で書き始めました。

画像の埋め込みよりも大きな拡張をもたらした最も単純な機能:

• objectId、userId、ownerId がデータ内に出現した回数 (人気度に相関するはずです)。
• userId が ownerId から見た投稿の数 (グループに対するユーザーの関心と相関するはずです);
• ownerId からの投稿を閲覧した一意の userId の数 (グループの視聴者数を反映します)。

タイムスタンプから、ユーザーがフィードを視聴した時刻 (朝/昼/夕方/夜) を取得することができました。 これらのカテゴリを組み合わせることで、引き続きフィーチャを生成できます。

• userId が夕方にログインした回数。
• この投稿が最も頻繁に表示される時間 (objectId) など。

これらすべてにより、指標は徐々に改善されました。 ただし、トレーニング データセットのサイズは約 20 万レコードであるため、機能を追加するとトレーニングの速度が大幅に低下します。

データ活用のアプローチを改めて考えてみました。 データは時間に依存しますが、「将来」における明らかな情報漏洩は見られませんでしたが、念のため次のように分類しました。

私たちに提供されたトレーニングセット (2 月と 2 月の XNUMX 週間) は XNUMX つの部分に分かれていました。
モデルは過去 N 日間のデータに基づいてトレーニングされました。 上記の集計は、テストを含むすべてのデータに基づいて構築されました。 同時に、ターゲット変数のさまざまなエンコーディングを構築できるデータが登場しました。 最も簡単なアプローチは、すでに新しい機能を作成しているコードを再利用し、トレーニングに使用されないターゲット = 1 のデータを単純にフィードすることです。

したがって、同様の機能が得られました。

• userId がグループ ownerId の投稿を見た回数。
• userId がグループ ownerId の投稿を「いいね！」した回数。
• userId が ownerId から「いいね！」した投稿の割合。

つまり、判明したのは、 平均ターゲットエンコーディング カテゴリ特徴のさまざまな組み合わせのデータセットの一部について。 原則として、catboost はターゲット エンコーディングも構築するため、この観点からは利点はありませんが、たとえば、このグループ内の投稿に「いいね！」をしたユニーク ユーザーの数をカウントすることが可能になりました。 同時に、主な目標は達成されました。データセットが数回削減され、フィーチャの生成を継続できるようになりました。

catboost は「いいね！」の反応のみに基づいてエンコーディングを構築できますが、フィードバックには他の反応 (再共有、嫌い、低評価、クリック、無視) があり、これらのエンコーディングは手動で実行できます。 データセットが膨張しないように、あらゆる種類の集計を再計算し、重要度の低い特徴を削除しました。

その時点で私は大差をつけてXNUMX位になっていました。 唯一混乱したのは、画像の埋め込みがほとんど増加を示さなかったことです。 catboost にすべてを捧げようという考えが生まれました。 Kmeans 画像をクラスタリングし、新しいカテゴリ特徴 imageCat を取得します。

KMeans から取得したクラスターを手動でフィルタリングおよびマージした後のいくつかのクラスを次に示します。

imageCat に基づいて次のものを生成します。

• 新しいカテゴリ機能:
  • userId ごとにどの imageCat が最も頻繁に表示されたか。
  • どの imageCat が ownerId を最も頻繁に表示するか。
  • userId ごとにどの imageCat が最も頻繁に「いいね」されましたか。
• 各種カウンター：
  • userId を参照した一意の imageCat の数。
  • 約 15 の同様の機能と、上記のターゲット エンコーディング。

テキスト

イメージコンテストの結果が自分に合っていたので、テキストに挑戦してみることにしました。 私はこれまでテキストをあまり扱ったことがなく、愚かにも tf-idf と svd で一日を費やしてしまいました。 次に、doc2vec のベースラインを確認しました。これはまさに私が必要なことを実行します。 doc2vec パラメータを少し調整すると、テキストが埋め込まれました。

そして、画像のコードを再利用し、画像の埋め込みをテキストの埋め込みに置き換えました。 結果、テキストコンテストで2位になりました。

連携体制

まだ棒で「つついて」いない競技が XNUMX つ残っており、リーダーボードの AUC から判断すると、この特定の競技の結果がオフライン ステージに最も大きな影響を与えたはずです。
画像自体に基づく特徴を除き、ソース データにあるすべての特徴を取得し、カテゴリ別の特徴を選択し、画像の場合と同じ集計を計算しました。 これをキャットブーストに入れるだけで2位になりました。

Catboost 最適化の最初のステップ

XNUMX位がXNUMX名、XNUMX位がXNUMX名という結果はうれしかったのですが、特別なことをしたわけではないということで、順位を下げることは予想できました。

コンテストの目的はユーザー内の投稿をランク付けすることであり、この間ずっと私は分類の問題、つまり間違った指標を最適化する問題を解決していました。

簡単な例を示します。

ユーザーID	オブジェクトID	予測	グラウンドトゥルース
1	10	0.9	1
1	11	0.8	1
1	12	0.7	1
1	13	0.6	1
1	14	0.5	0
2	15	0.4	0
2	16	0.3	1

ちょっとアレンジしてみましょう

ユーザーID	オブジェクトID	予測	グラウンドトゥルース
1	10	0.9	1
1	11	0.8	1
1	12	0.7	1
1	13	0.6	0
2	16	0.5	1
2	15	0.4	0
1	14	0.3	1

次の結果が得られます。

モデル	AUC	ユーザー1のAUC	ユーザー2のAUC	平均AUC
オプション1	0,8	1,0	0,0	0,5
オプション2	0,7	0,75	1,0	0,875

ご覧のとおり、全体的な AUC 指標の向上は、ユーザー内の平均 AUC 指標の向上を意味するわけではありません。

キャットブースト ランキング指標を最適化する方法を知っている 箱から。 ランキング指標について読んだのですが、 成功事例 catboost を使用し、夜間トレーニングするように YetiRankPairwise を設定する場合。 結果は印象に残るものではありませんでした。 トレーニングが不十分であると判断し、エラー関数を QueryRMSE に変更しました。catboost のドキュメントから判断すると、より速く収束します。 最終的には、分類のトレーニングを行ったときと同じ結果が得られましたが、この XNUMX つのモデルのアンサンブルにより大幅に向上し、XNUMX つのコンテストすべてで XNUMX 位を獲得することができました。

「コラボレーション システム」コンテストのオンライン ステージ終了 5 分前に、セルゲイ シャルノフが私を XNUMX 位に押し上げました。 さらなる道を一緒に歩きました。

オフラインステージの準備

RTX 2080 TI ビデオ カードを使用したオンライン ステージでの勝利は保証されていましたが、主な賞金 300 ルーブルと、おそらく最終 000 位のため、この 2 週間働く必要がありました。

結局のところ、セルゲイもキャットブーストを使用していました。 私たちはアイデアや機能を交換し、次のことを学びました。 アンナ・ベロニカ・ドログシュによるレポート そこには私の疑問の多くに対する答えが含まれており、その時までに私がまだ持っていなかった疑問さえも含まれていました。

レポートを見て、すべてのパラメーターをデフォルト値に戻し、一連の機能を修正した後でのみ、非常に慎重に設定を行う必要があるという考えに至りました。 15 回のトレーニングには約 XNUMX 時間かかりましたが、XNUMX つのモデルはランキングを使用したアンサンブルで得られた速度よりも優れた速度を得ることができました。

特徴生成

Collaborative Systems コンテストでは、多数の機能がモデルにとって重要であると評価されます。 例えば、 Auditweights_spark_svd - 最も重要な兆候ですが、それが何を意味するかについての情報はありません。 重要な特徴に基づいてさまざまな集計を行う価値があると考えました。 たとえば、ユーザー別、グループ別、オブジェクト別の平均 Auditweights_spark_svd です。 トレーニングが実行されず、ターゲット = 1、つまり平均値のデータを使用して同じことを計算できます。 Auditweights_spark_svd ユーザーごとに、彼が気に入ったオブジェクトごとに。 その他の重要な兆候 Auditweights_spark_svd、いくつかありました。 その一部を次に示します。

• 監査重みCtr性別
• 監査重みCtrHigh
• userOwnerCounterCreateLikes

たとえば、平均 監査重みCtr性別 userIdによると、平均値と同様に重要な特徴であることが判明しました userOwnerCounterCreateLikes ユーザー ID + 所有者 ID によって。 これで、フィールドの意味を理解する必要があるとすでに考えているはずです。

また、重要な機能としては、 監査重みのいいね数 и 監査重みショー数。 それぞれを分割すると、さらに重要な特徴が得られました。

データ漏洩

競技モデリングと製品モデリングはまったく異なるタスクです。 データを準備するときに、すべての詳細を考慮して、テストのターゲット変数に関する重要な情報を伝えないことは非常に困難です。 運用ソリューションを作成している場合は、モデルのトレーニング時にデータ漏洩を回避するように努めます。 しかし、競争に勝ちたいのであれば、データ漏洩が最良の機能です。

データを調べてみると、objectId 値によると次のことがわかります。 監査重みのいいね数 и 監査重みショー数 これは、これらの特徴の最大値の比率が、表示時の比率よりも変換後の比率をよりよく反映することを意味します。

私たちが発見した最初の漏れは、 AuditweightsLikesCountMax/auditweightsShowsCountMax.
しかし、データをより詳しく見てみるとどうなるでしょうか? ショーの日付で並べ替えて、次の結果を取得しましょう。

オブジェクトID	ユーザーID	監査重みショー数	監査重みのいいね数	ターゲット（好き）
1	1	12	3	おそらくそうではありません
1	2	15	3	多分はい
1	3	16	4

最初にそのような例を見つけたときは驚きましたが、私の予測が当たらなかったことが判明しました。 しかし、オブジェクト内のこれらの特性の最大値が増加したという事実を考慮して、私たちは怠惰ではなく、次のことを見つけることにしました。 監査重み表示数次 и 監査重みいいね数次へ、つまり次の瞬間の値です。 機能を追加することで
(auditweightsShowsCountNext-auditweightsShowsCount)/(auditweightsLikesCount-auditweightsLikesCountNext) 私たちはすぐに鋭いジャンプをしました。
同様のリークは、次の値を見つけることで使用できます。 userOwnerCounterCreateLikes userId+ownerId 内、たとえば 監査重みCtr性別 objectId+userGender 内。 私たちは漏洩のある同様のフィールドを 6 つ発見し、そこから可能な限り多くの情報を抽出しました。

その時点までに、私たちはコラボレーション機能から可能な限り多くの情報を絞り出しましたが、画像とテキストのコンテストには戻りませんでした。 画像やテキストに直接基づいた機能は、関連するコンテストでどれくらいの利益をもたらすのでしょうか?

画像とテキストのコンテストではリークはありませんでしたが、その時までにデフォルトの catboost パラメータを戻し、コードをクリーンアップし、いくつかの機能を追加していました。 合計は次のとおりです。

ソリューション	すぐ
画像付きの最大値	0.6411
最大画像なし	0.6297
XNUMX位の結果	0.6295

ソリューション	すぐ
テキスト付きの最大値	0.666
テキストなしの最大値	0.660
XNUMX位の結果	0.656

ソリューション	すぐ
共同作業で最大限の効果を発揮	0.745
XNUMX位の結果	0.723

テキストや画像から多くを引き出せる可能性は低いことが明らかになり、最も興味深いアイデアをいくつか試した後、それらを使用するのをやめました。

協調システムでさらに機能を生成しても増加は見られず、ランキングを開始しました。 オンライン段階では、分類とランキングのアンサンブルによってわずかな増加が見られましたが、これは分類のトレーニングが不十分だったためであることが判明しました。 YetiRanlPairwise を含むどの誤差関数も LogLoss の結果に近い結果を生成しませんでした (0,745 対 0,725)。 QueryCrossEntropy にはまだ希望がありましたが、起動できませんでした。

オフラインステージ

オフライン段階では、データ構造は同じままですが、若干の変更がありました。

• 識別子の userId、objectId、ownerId は再ランダム化されました。
• いくつかの標識は削除され、いくつかは名前が変更されました。
• データは約 1,5 倍に増加しました。

列挙した困難に加えて、大きなプラスが 2080 つありました。それは、チームに RTX XNUMXTI を搭載した大規模なサーバーが割り当てられたことです。 長い間htopを楽しんでいます。

アイデアはただ 1 つ、すでに存在するものを単純に再現するというものでした。 サーバー上で環境をセットアップするのに数時間を費やした後、結果が再現可能であることを徐々に検証し始めました。 私たちが直面している主な問題は、データ量の増加です。 負荷を少し軽減し、catboost パラメータ ctr_complexity=0,733 を設定することにしました。 これにより速度は少し低下しますが、モデルは動作し始め、結果は良好で、2 でした。 Sergey は、私とは異なり、データを 64 つの部分に分割せず、すべてのデータをトレーニングしました。これにより、オンライン段階では最高の結果が得られましたが、オフライン段階では多くの困難がありました。 私たちが生成したすべての機能を catboost に押し込もうとした場合、オンライン段階では何​​も機能しません。 Sergey は、float32 型を floatXNUMX に変換するなど、型の最適化を行いました。 この記事では、 pandas のメモリ最適化に関する情報を見つけることができます。 その結果、セルゲイはすべてのデータを使用して CPU でトレーニングし、約 0,735 を獲得しました。

これらの結果は勝つのに十分でしたが、私たちは本当の速さを隠しており、他のチームが同じことをしていないことを確信できませんでした。

最後まで戦い抜く

キャットブーストのチューニング

私たちのソリューションは完全に再現され、テキスト データと画像の機能が追加されたので、残ったのは catboost パラメーターを調整するだけでした。 Sergey は少数の反復を使用して CPU でトレーニングし、私は ctr_complexity=1 の CPU でトレーニングしました。 残り XNUMX 日だったので、反復を追加するか ctr_complexity を増やすだけで、朝までにさらに速い速度が得られ、一日中歩くことができます。

オフライン段階では、サイト上で最適なソリューションを選択しないだけで、速度が非常に簡単に隠蔽されてしまう可能性があります。 私たちは、応募締め切り前の最後の数分間にリーダーボードに劇的な変化が起きると予想し、中止しないことにしました。

アンナのビデオから、モデルの品質を向上させるには、次のパラメーターを選択するのが最善であることがわかりました。

• Learning_rate — デフォルト値はデータセットのサイズに基づいて計算されます。 learning_rate を増やすには、反復回数を増やす必要があります。
• l2_leaf_reg — 正則化係数、デフォルト値は 3、できれば 2 ～ 30 から選択します。値を減らすと、オーバーフィットが増加します。
• 袋詰め_温度 — サンプル内のオブジェクトの重みにランダム化を追加します。 デフォルト値は 1 で、重みは指数分布から抽出されます。 値を減らすと、オーバーフィットが増加します。
• ランダム強度 — 特定の反復での分割の選択に影響します。 random_strength が高くなるほど、重要度の低い分割が選択される可能性が高くなります。 その後の反復ごとに、ランダム性が減少します。 値を減らすと、オーバーフィットが増加します。

他のパラメータは最終結果に与える影響がはるかに小さいため、それらを選択しようとしませんでした。 ctr_complexity=1 を使用した GPU データセットでのトレーニングの 20 回の反復には 30 分かかり、縮小されたデータセットで選択されたパラメーターは完全なデータセットの最適なパラメーターとはわずかに異なりました。 最終的に、データの 10% に対して約 10 回の反復を実行し、その後、すべてのデータに対してさらに約 XNUMX 回の反復を実行しました。 次のようなことがわかりました。

• Learning_rate デフォルトから 40% 増加しました。
• l2_leaf_reg そのままにしておきました。
• 袋詰め_温度 и ランダム強度 0,8まで減りました。

モデルはデフォルトのパラメーターで十分にトレーニングされていないと結論付けることができます。

リーダーボードの結果を見て非常に驚きました。

モデル	モデル1	モデル2	モデル3	アンサンブル
チューニングなし	0.7403	0.7404	0.7404	0.7407
チューニングあり	0.7406	0.7405	0.7406	0.7408

私は、モデルを迅速に適用する必要がない場合は、パラメーターの選択を、最適化されていないパラメーターを使用する複数のモデルのアンサンブルに置き換える方が良いと自分自身で結論付けました。

Sergey は、GPU で実行できるようにデータセットのサイズを最適化していました。 最も簡単なオプションはデータの一部を切り取ることですが、これはいくつかの方法で実行できます。

• データセットがメモリに収まり始めるまで、最も古いデータを徐々に削除します (XNUMX 月初旬)。
• 最も重要度の低い機能を削除します。
• エントリが XNUMX つだけある userId を削除します。
• テスト内の userId のみを残します。

そして最終的には、すべてのオプションからアンサンブルを作成します。

最後のアンサンブル

最終日の夕方までに、0,742 をもたらすモデルのアンサンブルをレイアウトしました。 一晩、ctr_complexity=2 でモデルを起動したところ、30 分の代わりに 5 時間トレーニングされました。 午前4時にのみカウントされ、最後のアンサンブルを行い、公開リーダーボードで0,7433を獲得しました。

問題を解決するためのアプローチが異なるため、予測には強い相関関係はなく、アンサンブルが大幅に増加しました。 適切なアンサンブルを取得するには、生のモデル予測を使用して、predict(prediction_type='RawFormulaVal') を使用し、scale_pos_weight=neg_count/pos_count を設定することをお勧めします。

ウェブサイトで見ることができます プライベートリーダーボードの最終結果.

その他の解決策

多くのチームはレコメンダー システム アルゴリズムの規範に従いました。 この分野の専門家ではない私はそれらを評価することはできませんが、興味深い解決策が 2 つあったことを覚えています。

• ニコライ・アノヒンの解決策。 Mail.ru の従業員であるニコライさんは賞品に応募しなかったので、彼の目標は最大速度を達成することではなく、簡単に拡張可能なソリューションを取得することでした。
• 審査員賞受賞チームの決定 この記事はフェイスブックから、手動作業なしで非常に優れた画像クラスタリングが可能になりました。

まとめ

私の記憶に一番残っていること：

• データにカテゴリ特徴があり、ターゲット エンコードを正しく行う方法を知っている場合は、catboost を試してみる方が良いでしょう。
• コンテストに参加している場合は、learning_rate と iterations 以外のパラメーターの選択に時間を無駄にすべきではありません。 より迅速な解決策は、複数のモデルのアンサンブルを作成することです。
• ブースティングは GPU で学習できます。 Catboost は GPU 上で非常に高速に学習できますが、大量のメモリを消費します。
• アイデアの開発およびテスト中は、小さい rsm~=0.2 (CPU のみ) および ctr_complexity=1 を設定することをお勧めします。
• 他のチームとは異なり、私たちのモデルのアンサンブルは大幅な向上をもたらしました。 私たちはアイデアを交換し、異なる言語で書いただけです。 データの分割には異なるアプローチがあり、それぞれに独自のバグがあったと思います。
• ランキングの最適化のパフォーマンスが分類の最適化よりも悪かった理由は明らかではありません。
• 私はテキストを扱う経験を積み、レコメンダー システムがどのように作られるかについて理解しました。

感動、知識、そして賞品を与えてくださった主催者に感謝します。

出所： habr.com