ロボットにユーモアのセンスを教えた方法

IT界には、機械学習（ML）が青年期のセックスのような冗談があります。誰もがそれについて話し、誰もがそれをするふりをしますが、実際、成功する人はほとんどいません。FunCorpは、MLを製品の主要なメカニズムに導入し、主要なメトリックの根本的な（ほぼ40％！）改善を達成することに成功しました。面白い？猫へようこそ。

少し背景

FunCorpブログを不定期に読んでいる人のために、私たちの最も成功した製品は、ミーム愛好家のためのソーシャルネットワークの要素を備えたiFunnyUGCアプリケーションであることを思い出させてください。ユーザー（これは米国の若い世代の4人に1人の代表者です）は、アプリケーションで直接新しい写真やビデオをアップロードまたは作成します。スマートアルゴリズムは、それらの最良のものを選択し（または、「機能」という言葉から「機能」と言います）、それぞれを形成します。視聴者の99％が対話する、別のフィード内の30〜60コンテンツユニットの7日目の問題。その結果、アプリケーションに入ると、各ユーザーにはトップミーム、ビデオ、面白い写真が表示されます。頻繁にアクセスすると、フィードがすばやくスクロールし、ユーザーは数時間で次の問題を待ちます。ただし、アクセス頻度が低いと、注目のコンテンツが蓄積され、フィードは数日で1000アイテムに増える可能性があります。



したがって、タスクが発生しました。フィードの開始時に、各ユーザーに最も関連性の高いコンテンツを表示し、個人的に興味のあるミームをグループ化することです。



iFunnyの存在から9年以上の間、このタスクにはいくつかのアプローチがありました。

最初に、笑顔の数（「いいね」の類似物）でフィードを並べ替える明白な方法を試しました-笑顔率。時系列で並べ替えるよりはましでしたが、同時に「病院の平均気温」の影響もありました。誰もが好むユーモアはほとんどなく、今日人気のあるトピックに興味がない（そして率直に言って迷惑な）人は常にいるでしょう。 ..。しかし、あなたはまた、あなたの好きな漫画からのすべての新しい面白いジョークを見たいです。



次の実験では、アニメ、スポーツ、猫と犬のミームなど、個々のマイクロコミュニティの関心を考慮に入れようとしました。これを行うために、彼らはいくつかのテーマ別の特集フィードを形成し始め、写真で認識されるタグとテキストを使用して、ユーザーが興味のあるトピックを選択できるようにしました。何かが改善されましたが、ソーシャルネットワークの効果は失われました。ユーザーエンゲージメントに大きな役割を果たした注目コンテンツへのコメントが少なくなっています。さらに、セグメント化されたフィードに向かう途中で、非常に人気のある多くのミームを失いました。彼らは「FavoriteCartoon」を見ましたが、「TheLastAvengers」についてのジョークは見ませんでした。



私たちはすでに機械学習アルゴリズムを製品に実装し始めているので、それは私たち自身のミートアップで発表しました、彼らはこの技術を使用して別のアプローチを作りたかった。



コラボレーティブフィルタリングの原理に基づいたレコメンデーションシステムの構築を試みることが決定されました。この原則は、アプリケーションにユーザーに関するデータがほとんどない場合に適しています。登録時に年齢や性別を示すものはほとんどなく、IPアドレスによってのみ地理的な場所を推測できます（ただし、iFunnyユーザーの大多数が居住者であることが占い師なしで知られています）米国）、および電話モデルによる-収入レベル。これに関しては、一般的に、すべてです。コラボレーティブフィルタリングは次のように機能します。ユーザーのコンテンツの肯定的な評価の履歴が取得され、同様の評価を持つ他のユーザーが検出され、同じユーザーがすでに気に入っているもの（同様の評価）が推奨されます。

タスクの特徴

ミームはかなり具体的なコンテンツです。まず、急速に変化する傾向に非常に敏感です。1週間前にトップに立ち、視聴者の80％を笑顔にしたコンテンツとフォームは、今日、その二次的な性質と無関係性でイライラを引き起こす可能性があります。



第二に、ミームの意味の非常に非線形で状況に応じた解釈。ニュースセレクションでは、特定のユーザーがかなり一貫して使用している有名な名前やトピックを見つけることができます。映画のセレクションでは、キャスト、ジャンルなどに追いつくことができます。はい、あなたは個人的なミームの選択でこれらすべてに追いつくことができます。しかし、セマンティックコンテンツにまったく適合しない画像や語彙を使用する、ユーモアの真の傑作を見逃すことは、なんと残念なことでしょう。





最後に、非常に大量の動的に生成されたコンテンツ。 iFunnyでは、ユーザーは毎日何万もの投稿を作成しています。このすべてのコンテンツは、できるだけ早く「レーキ」する必要があります。パーソナライズされた推奨システムの場合は、「ダイヤモンド」を見つけるだけでなく、社会のさまざまな代表者によるコンテンツの評価を予測できるようにする必要があります。



これらの機能は、機械学習モデルの開発にとってどのような意味がありますか？まず、モデルは常に最新のデータでトレーニングする必要があります。推薦システムの開発に没頭し始めたばかりの時点では、私たちが何十分について話しているのか、それとも数時間について話しているのかはまだ完全には明らかではありません。しかし、どちらもモデルの継続的な再トレーニングの必要性、またはさらに良いことを意味します-データの継続的なストリームでのオンライントレーニング。これらはすべて、適切なモデルアーキテクチャを見つけ、そのハイパーパラメータを選択するという観点からは最も簡単なタスクではありません。これにより、数週間以内にメトリックが確実に低下し始めないことが保証されます。



別の難しさは、私たちが採用したa / bテストプロトコルに従う必要があることです。最初にユーザーの一部をチェックし、結果をコントロールグループと比較せずに、何も実装することはありません。



長い計算の結果、次の特性を持つMVPを開始することが決定されました。ユーザーとコンテンツのやり取りに関する情報のみを使用し、大量のメモリを備えたサーバー上でモデルをリアルタイムでトレーニングします。これにより、ユーザーのテストグループのやり取りの履歴全体をかなり長期間保存できます。新規性の効果を維持し、リリース中にアプリケーションに大量にアクセスするユーザーからの最新データを使用する時間を確保するために、トレーニング時間を15〜20分に制限することにしました。

モデル

最初に、ALS（交互の最小二乗）またはSGD（確率的勾配降下）でのマトリックス分解とトレーニングを使用して、最も古典的な協調フィルタリングをねじり始めました。しかし、彼らはすぐに理解しました。最も単純なニューラルネットワークからすぐに始めてみませんか？単純な単層メッシュを使用します。このメッシュでは、線形埋め込みレイヤーが1つだけで、ハイパーパラメーターを選択する数週間に埋もれないように、非表示レイヤーが折り返されることはありません。 MVPを少し超えていますか？多分。しかし、優れたGPUを備えたハードウェアがある場合、そのようなメッシュをトレーニングすることは、より古典的なアーキテクチャよりも難しいことはほとんどありません（それをフォークする必要がありました）。



当初、イベントの開発には2つのオプションしかないことは明らかでした。開発によって製品の指標に大きな結果がもたらされるか、ユーザーとコンテンツのパラメーターをさらに掘り下げるか、新しいコンテンツと新しいユーザーに関する追加のトレーニングを行うか、ディープニューラルネットワークを掘り下げるか、パーソナライズされたコンテンツのランク付けでは得られないかのいずれかです。目に見える増加と「ショップ」をカバーすることができます。最初のオプションが発生した場合は、上記のすべてを最初の埋め込みレイヤーにねじ込む必要があります。Neural FactorizationMachine



を選択することにしました。その動作の原理は次のとおりです。各ユーザーと各コンテンツは、同じ固定長のベクトルによってエンコードされます。埋め込みは、ユーザーとコンテンツの間の一連の既知の相互作用についてトレーニングされます。



トレーニングセットには、コンテンツを表示しているユーザーのすべての事実が含まれています。笑顔に加えて、「共有」または「保存」ボタンをクリックし、コメントを書くことで、コンテンツに関する肯定的なフィードバックとしてカウントすることが決定されました。存在する場合、インタラクションは1でマークされます。表示した後、ユーザーが肯定的なフィードバックを残さなかった場合、インタラクションは0（ゼロ）でマークされます。したがって、明示的な評価尺度がない場合でも、明示的なモデル（ユーザーからの明示的な評価を持つモデル）が使用され、肯定的なアクションのみが考慮される暗黙的なモデルは使用されません。



暗黙的なモデルも試しましたが、すぐには機能しなかったため、明示的なモデルに焦点を合わせました。おそらく、暗黙的なモデルの場合、単純なバイナリクロスエントロピーよりもトリッキーなランキング損失関数を使用する必要があります。



Neural MatrixFactorizationと標準のNeuralCollaborative Filteringの違いは、ユーザーとコンテンツの埋め込みベクトルを単純に接続する通常の完全に接続されたレイヤーではなく、いわゆるBi-InteractionPoolingレイヤーが存在することです。 Bi-Interactionレイヤーは、埋め込みベクトルのセット（iFunnyにはユーザーとコンテンツの2つのベクトルのみ）を要素ごとに乗算することにより、1つのベクトルに変換します。



Bi-Interactionの上に追加の隠れ層がない場合、これらのベクトルのドット積を取得し、ユーザーバイアスとコンテンツバイアスを追加して、それをシグモイドでラップします。これは、このコンテンツを表示した後のユーザーからの肯定的なフィードバックの可能性の見積もりです。特定のデバイスでデモンストレーションする前に、利用可能なコンテンツをランク付けするのは、この評価によるものです。



したがって、トレーニングのタスクは、正の相互作用があるユーザーとコンテンツの埋め込みが互いに近くにあり（最大のドット積を持つ）、負の相互作用があるユーザーとコンテンツの埋め込みが互いに遠くにあることを確認することです。 （最小ドット製品）。



このトレーニングの結果、同じことを笑顔にするユーザーの埋め込みは、互いに近くなります。そして、これは他の多くのタスクで使用できるユーザーの便利な数学的記述です。しかし、それは別の話です。



そのため、ユーザーはフィードを入力してコンテンツの視聴を開始します。あなたが見るたびに、笑顔、共有など。クライアントは統計を分析ストレージに送信します（興味がある場合は、RedshiftからClickhouseへの移行の記事で以前に説明しました）。途中で、関心のあるイベントを選択してMLサーバーに送信し、そこでメモリに保存します。



15分ごとに、モデルがサーバー上で再トレーニングされ、その後、新しいユーザー統計が推奨事項で考慮されます。



クライアントはフィードの次のページを要求します。これは標準的な方法で作成されますが、コンテンツリストがMLサービスに送信される途中で、この特定のユーザーのトレーニング済みモデルによって指定された重みに従って並べ替えられます。







その結果、ユーザーは最初に、モデルによれば、自分よりも好ましい写真やビデオを目にします。

内部サービスアーキテクチャ

このサービスはHTTP経由で機能します。Flaskは、Gunicornと組み合わせてHTTPサーバーとして使用されます。add_eventとget_ratesの2つのリクエストを処理します。



add_eventリクエストは、ユーザーとコンテンツ間の新しいインタラクションを追加します。これは内部キューに追加され、別のプロセスで処理されます（最大1600 rps）。



get_ratesリクエストは、モデルに従ってuser_idおよびcontent_idリストの重みを計算します（ピーク時の約100 rps）。



主な内部プロセスはディスパッチャです。これはasyncioで記述され、基本的なロジックを実装します。

1. add_eventリクエストのキューを処理し、それらを巨大なハッシュマップ（1週間に2億イベント）に保存します。
2. 円でモデルを再計算します。
3. ハッシュマップから1週間より古いイベントを削除しながら、30分ごとに新しいイベントをディスクに保存します。

トレーニングされたモデルは共有メモリに配置され、そこからHTTPワーカーによって読み取られます。

結果

チャートはそれ自体を物語っています。スミリーの相対数が25％増加し、ビューの深さが40％近く増加したのは、A / Bテスト50/50の終了時に新しいアルゴリズムをオーディエンス全体に展開した結果です。つまり、基本値と比較して実際に増加しています。ほぼ2倍の大きさでした。 iFunnyは広告から収益を上げているため、深さの増加はそれに比例した収益の増加を意味し、2020年の危機的な月を非常に落ち着いて乗り切ることができました。スミリーの数が増えると、忠誠心が高まります。つまり、将来的にアプリケーションを放棄する可能性が低くなります。忠実なユーザーは、アプリケーションの他のセクションに移動し、コメントを残し、互いに通信し始めます。そして最も重要なことは、推奨の品質を向上させるための信頼できる基盤を作成しただけではありません。また、アプリケーションの長年にわたって蓄積した膨大な量の匿名の行動データに基づいて、新しい機能を作成するための基礎を築きました。

結論

ML Content Rateサービスは、多数のマイナーな改善と改善の結果です。

まず、未登録のユーザーもトレーニングで考慮されました。彼らは先験的にエモティコンを残すことができなかったので、最初はそれらについての質問がありました-コンテンツを見た後に最も頻繁なフィードバック。しかし、これらの恐れが無駄であり、非常に大きな成長点を閉じたことがすぐに明らかになりました。多くの実験は、トレーニングサンプルの構成を使用して行われます。つまり、オーディエンスの大部分をサンプルに配置するか、考慮されるインタラクションの時間間隔を拡張します。これらの実験の過程で、データの量が製品メトリックに重要な役割を果たすだけでなく、モデルを更新する時間も重要であることが判明しました。多くの場合、ランキングの品質の向上は、モデルを再計算するために10〜20分余分に溺れ、イノベーションを放棄する必要がありました。



多くの、たとえわずかな改善でも、結果が得られました。それらは、学習の質を改善するか、学習プロセスを加速するか、メモリを節約しました。たとえば、相互作用がメモリに収まらないという事実に問題がありました-それらは最適化されなければなりませんでした。さらに、コードが変更され、再計算のためのより多くの相互作用など、コードに突き刺すことが可能になりました。また、サービスの安定性も向上しました。



現在、既知のユーザーパラメータとコンテンツパラメータを効果的に使用して、インクリメンタルで迅速な再トレーニングモデルを作成する作業が進行中であり、将来の改善のための新しい仮説が浮上しています。



このサービスをどのように開発したか、および他にどのような改善を実装したかについて知りたい場合は、コメントに書き込んでください。しばらくすると、2番目の部分を書く準備が整います。

著者について

残念ながら、Habrは記事の複数の著者を示すことを許可していません。記事は私のアカウントから公開されましたが、そのほとんどはFunCorpMLサービスの主任開発者であるGrishaKuzovnikov（PhoenixMSTU）、およびアナリストとデータサイエンティスト-DimaZemtsov。あなたの扱いにくい使用人は、主に十代のセックスジョーク、紹介と結果のセクション、および編集作業を担当しています。そしてもちろん、これらすべての成果は、バックエンド開発チーム、QA、アナリスト、およびこれらすべてを発明し、A / B実験の実施と調整に数か月を費やした製品チームの助けがなければ、実現できなかったでしょう。