この記事では、タオバオのパーソナライズされたレコメンデーション シナリオにおける適応的で教師なしのマルチシナリオ モデリングに関する考えと実践方法を共有します。この研究は CIKM 2022 で発表されました (論文タイトル: マルチシナリオ パーソナライズド レコメンデーションのためのシナリオ適応型および自己教師モデル)。この記事では、マルチシナリオ モデリングがフルドメイン シナリオと単一シナリオの間の移行関係を詳細に記述してドメイン適応を実現する方法と、教師なしデータをマルチシナリオ モデリングに導入する方法を紹介します。推奨とリコールにおけるマルチシナリオモデリングの段階的な実装実践。
まず、マルチシナリオ モデリングのビジネス背景を紹介します。 , 動機と解決策の選択をモデリングします。この記事では、レコメンデーション システムのマルチシナリオ モデリングの問題に焦点を当てます。これは、さまざまなレコメンデーション システムに共通の問題でもあり、早急に解決する必要があります。具体的には5問程度紹介します。
ビジネスの観点とモデルの観点から説明できます。 ビジネスの観点から見ると、「シナリオ」は、単にレコメンデーション プラットフォーム上のさまざまなレコメンデーション ポータルまたはレコメンデーション ホスティング ページとして理解できます。例えば広告分野では、同じ広告を異なるメディア端末に掲載すると同時に、情報フロー広告やオープンスクリーン広告などの異なる配信形態に対応することができます。電子商取引の分野では、タオバオを例に取ると、ホームページ上にあなたのお気に入りの製品を推測する推奨インターフェイス、ショッピングカート内の推奨シナリオ、および関連する推奨事項が表示される、非常に豊富な推奨ページも用意されます。製品詳細ページ。私たちの実際のビジネスであるタオバオでのショッピングなどのコンテンツ レコメンデーションの分野では、レコメンデーション ページには 1 ホップ 2 列の表示シーンと、クリックして入力した後に上下にスライドする没入型の無限のレコメンデーション フローが含まれています。 2番目のホップ。これらの例では、ホストされている各ページをシーンとして使用でき、同じレコメンデーション プラットフォームにも複数のレコメンデーション シーンがあり、複数のシーンの特性が示されます。
モデル モデリングの観点から見ると、マルチシナリオ問題は、同じ特徴空間とラベル空間を共有するが、データ分布が異なる複数のデータ セットとして単純に定義できます。各レコメンデーション シナリオで記録されたデータは、対応するデータ セットを形成できます。各データ セットは異なるソースから取得されていますが、その特徴システムとラベル スペースは一貫しています。最初の目標はパフォーマンスの目標であり、データの疎性の問題の最適化に焦点を当てています。単一の推奨シナリオでは、通常、ユーザー行動データがまばらであるという問題に直面します。この現象は、一部の小規模なシナリオや新しいシナリオで特に顕著です。マルチシナリオ問題の重要な目標の 1 つは、複数のシナリオ間の情報共有を通じて、データの希薄性の問題を軽減し、すべてのシナリオのビジネス指標を改善することです。
2 番目は、イテレーションと運用保守コストの観点からの目標です。従来の最適化手法では、シナリオごとに独立したモデルを保守および最適化するために専任の人員を割り当てます。いくつかの新しいシナリオにアクセスすると、アクセスプロセス全体とモデルトレーニングプロセスを繰り返す必要があります。これは、すべての人員配置、モデル展開作業、およびメンテナンス コストがシナリオの数と正の関係にあり、全体的なメンテナンス コストと反復コストが比較的高くなる可能性があることを意味します。
実際のコストを考慮して、さまざまなシナリオに同時に対応し、新しいシナリオへの迅速なアクセスをサポートできる統一されたアルゴリズム フレームワークを構築したいと考えており、これがマルチシナリオ モデリングを通じて実現したいことです。もう一つの目標。
マルチシナリオの問題は、現在知られているマルチターゲットおよびクロスドメインの問題とは異なることも強調しておく必要があります。マルチシナリオ問題の焦点は、同じ機能システムを共有し、複数の異なるデータ ソースを持ち、同じ目標を持つことです。多目的とは、同じデータ ソースに対して複数の異なる最適化目標があることを意味します。クロスドメインの問題は通常、ソース ドメインとターゲット ドメインに分けられ、ソース ドメインのデータ量と効果が優れていると想定され、ソース ドメインはターゲット ドメインの効果を向上させるために使用されます。 。マルチシナリオの問題では、各シナリオの長所と短所の間に関係はなく、モデリングの目標はすべてのシナリオの効果を向上させることです。
実用化の初期段階では、この種のマルチシナリオの場合、・シナリオ問題のモデリング 業界に存在するソリューションを簡単に分類してみたところ、大きく以下の4種類に分類されます。
最後のカテゴリは、業界で現在主流のマルチシナリオ モデリング手法です。マルチタスク学習アーキテクチャを活用することで、各シナリオのデータをモデル構造で考慮して共同モデリングを実行し、 そしてモデル構造の設計を通じて、シーン間の共通表現と相違点が表現されます。過去 2 年間、業界では多くの試みと実装が行われてきました。たとえば、SAR-Net は MMOE と同様の方法でトレーニングされ、STAR はマトリックス マッピングを通じてこのグローバルに共有されるネットワークと各シナリオに固有のネットワークを構築します。モデル パラメータ間のこのシーンの違いの特徴付けを実現する方法、および動的パラメータ ネットワークを通じてこのシーンの違いを表現するためのその他の作業。
最初の 3 種類の方法の欠点を考慮して、その後の作業は共同訓練に基づいて実行することにしました。
##実際のビジネス実装の過程では、この種の統合モデルによる複数のシナリオの共同モデリングに関して、より具体的ないくつかの課題にも直面しています。これは主に次の側面に反映されています。
課題 1: あらゆるシナリオで情報を最大限に活用することを期待して、ジョイント モデリングを使用します。単一シーン内のデータの疎性の問題を解決するには、他のシーンの有効な情報を指定されたシーンに移行することが本質的ですが、前述したいくつかの方法では、パラメータ行列演算や動的パラメータ ネットワークを使用して、単一シーンの共通点と相違点を特徴付けます。ただし、これらの変換方法は比較的暗黙的なものであり、他のシーンが指定されたシーンに情報を転送したかどうか、およびどの程度の情報が転送されたかを解釈可能な方法で説明することは不可能です。したがって、洗練された効果的なシーン情報の移行をどのように実現するかが、私たちが直面する最初の課題です。簡単に言うと、情報を移行するかどうか、および移行する情報の量をどのようにモデル化するかです。
課題 2: モデルをトレーニングするときは、主に次のようなユーザー インタラクションの動作に基づいて行われます。製品のクリックやビデオ完了などの正のフィードバック信号は、正のサンプルを構築するために使用されます。つまり、ラベル付きサンプル データに対してトレーニングが実行されます。これにより、動作がほとんどない一部のシナリオでは、深刻なデータ スパースの問題が発生します。いくつかの教師なしタスクを使用して、トレーニング データをラベル付きサンプル空間からラベルなしサンプル空間に拡張できれば、データの疎性の問題を軽減するのに役立ちます。
課題 3: レコメンデーション リンク全体が、リコールなどのいくつかの主要な段階に分割されていることは誰もが知っています。そして仕分けです。初期の研究では、マルチシナリオ問題の共同モデリングは主に並べ替え段階に焦点を当てていることがわかりました。これには、基本的に並べ替えモデルである上記のモデルの一部も含まれます。推奨リンク全体の最初の段階として、非常に異なる候補サイズ、取得方法、並べ替えに直面していることを思い出してください。したがって、リコール段階でマルチシナリオ共同モデリングをどのように実装するかも、私たちが直面する課題です。
私たちが行っていることを紹介しましょう。実際のビジネス実装に向けたモデルソリューションであり、このモデルはSASSと呼ばれます。このソリューションは、主に 3 つの中核キーワードに焦点を当てています。1 つ目はシーン適応型転送 (Scenario-Adaptive)、2 つ目は教師なし (Self-Supervised)、3 つ目はリコール タスクの実装探索です。
モデル フレームワーク全体には 2 つのステージが含まれています。1 つは事前トレーニング タスクで、もう 1 つはトレーニング タスクです。もう 1 つは微調整タスクです。最初の段階では、ラベルのないサンプル セットに対して教師なしの事前トレーニング タスクを構築し、対照学習を通じてシーン間の関係をモデル化します。また、リコール段階ではモデル全体を実装するため、ユーザー側とアイテム側を独立してモデル化する必要があるため、ユーザー側とアイテム側で対称的な構造設計となっています。
第 2 段階は微調整タスクであり、第 1 段階で事前トレーニングされた埋め込みおよびネットワーク構造パラメーターの読み込みなど、第 1 段階に基づくモデル構造を再利用します。さらに、第 2 段階では、ラベル付きサンプル空間でリコール タスクをトレーニングし、ユーザー側とアイテム側の表現ベクトルを出力します。次に、これら 2 つの段階について詳しく紹介します。
最初のタスク最初の段階の事前トレーニング タスクでは、シーン間の対照学習の教師なしタスクを構築します。図の右上隅に示すように、対照学習の古典的なトレーニング パラダイムについては誰もがよく知っているはずです。同じオブジェクト x が 2 つの異なるデータ拡張方法を通じて 2 つの異なる特徴セットを取得し、特徴抽出ネットワークとマッピングを使用します。ネットワークは最終的に同じオブジェクトの 2 つの異なるベクトル表現を取得し、学習されたメトリック損失を比較することで 2 つのベクトル間の表現距離を短縮し、教師なしの事前トレーニング タスクを実現できます。
対比学習のアイデアに触発され、マルチシーン モデリングにおけるシーン間の位置合わせ表現を対比学習の事前トレーニング タスクと組み合わせました。前述したように、同じユーザーが複数の異なるシーンにアクセスし、異なるシーンで異なるインタラクティブな動作を行い、シーンに関連する統計情報を残すことがあります。したがって、異なるシナリオにおけるユーザーの行動の違いは、データ強化の自然な方法であると考えることができ、同じユーザーの興味には連続性がありますが、シナリオが異なるとユーザーの表現に一定の違いが生じる可能性があります。次に、これに基づいて対照学習の教師なしタスクを構築します。
図の左側に示すように、具体的なモデルを見ると、さまざまなシナリオに合わせて統合された機能システムを構築しますが、機能の具体的な値はシナリオに対応しています。ユーザーの行動を組み合わせます シーケンスはシーンに分割され、ユーザーはそれぞれのシーンで興味や好みなどの対応する統計的特徴を持ちます。この分割方法により、同一ユーザがシナリオに関連する複数の異なる特徴量セットを有することになる。たとえば、図では、シーン a とシーン b における同じユーザーの特性を取得し、その後、統合表現ネットワーク (この表現ネットワークについては後で紹介します) を通じて、異なるシーンにおける同じユーザーの表現ベクトルを取得できます。 、そして最後に比較を通して損失を知り、二人の距離を縮めます。
今話したのはユーザー側の学習方法ですが、リコールタスクでは通常ユーザー側とアイテム側が独立してモデル化されます。したがって、アイテム側もトレーニングに対称的な構造とタスクを使用し、ユーザー側とアイテム側は同じ埋め込み層を共有します。具体的には、同じアイテムについて、アイテム側の特徴量をシーンに分割し、アイテム側の表現ネットワークを通した後、各シーンのベクトル表現を取得し、同じ対照学習を用います。トレーニングの損失です。
サンプルを構築するとき、ユーザーが 2 つ以上のシーンを訪問する可能性があるため、対照学習のトレーニング タスクを構築するときは、ユーザーが訪問したシーンをペアで組み合わせます。複数のトレーニング サンプルを構築します。アイテム面でも、この2つの組み合わせにより複数のサンプルが構築されています。
特定の対照的な学習タスクに関しては、引き続きトレーニングに InfoNCE の損失形式を使用します。
#シーンのモデリングとシーン間の比較学習タスクを通じて、複数のシーン間のラベルなしデータの事前学習を実現します。モデルフレームワークにおける表現ネットワークの詳細。
2 番目の部分は、各シーンの固有のネットワーク構造です。これは、画像内の各シーンに対応する灰色の部分です。各シーンに対応するサンプルは、対応するネットワークを通じてトレーニングされ、各シーンのネットワーク層パラメーターが分離されているため、このトレーニングと表現により、各シーン間の分布の違いをよく説明できます。さらに、図の左下隅には、補助バイアス ネットワークも導入されています。このバイアス ネットワークの入力には、シーン ID といくつかのシーン固有の特徴、およびいくつかのコンテキスト特徴が含まれます。これにより、共有システムに基づいてシーンのコンテキスト間の差異と偏った情報をさらに特徴付けることができます。 特定のトレーニング プロセスでは、各サンプルが統合された特徴埋め込みレイヤーを通過して結合された後、完全なシーン共有ネットワークに入り、このサンプルは対応するシーンに固有のネットワークは、順伝播および逆伝播ネットワークのトレーニングを実行します。 同時に、ネットワーク構造全体において、フルシーン共有ネットワークの各層の出力はシーン適応型ゲーティング ユニットを通過します。シーン全体の融合情報を統合するには、単一のシーンに移行して、シーン情報の洗練された移行を実現します。詳細については、図のモデルの右上隅の構造を参照してください。マイグレーション構造には、主にアダプティブ ゲートとアップデート ゲートが含まれます。アダプティブ ゲートの出力値は、フル シーン内のどの程度の情報を 1 つのシーンに移行できるかを制御するために使用され、更新ゲートの出力は、フル シーン ネットワークから移行される情報と元の情報を制御するために使用されます。単一シーンの重み付けされたフュージョンの重み値。これら 2 つのゲート ネットワークの入力には、フル シーン ネットワークの情報、単一シーン ネットワークの情報、およびシーン自体のバイアス情報が含まれます。この洗練された適応的な移行構造を通じて、シーンの移行方向と移行情報の量がモデル化され、特徴付けられます。移行構造を複数のレイヤーに積み重ね、最終的に各サンプルは対応するシーンのベクトル表現を取得できます。最後に、各シーンのそれぞれの出力が、対応するシーンのバイアスの出力と融合されて、対応するシーンの最終的なベクトル表現が得られます。 #2. フェーズ 2: タスクの微調整
#第 2 段階は微調整タスクです。モデルを推奨リンクのリコール段階に実装したいため、微調整タスクとリコール タスクの目標は一致しています。サンプルの選択に関しては、ユーザーがクリックしたアイテムをポジティブ サンプルとして使用し、ランダム サンプリングを通じてネガティブ サンプルを構築し、トレーニング用のトリプルを構築してペアワイズ損失を計算します。
さらに、微調整段階では、モデル構造とパラメーターを再利用します。つまり、モデル構造を微調整段階で再利用します。 -チューニング段階と事前トレーニング段階 同じ表現ネットワーク構造が使用され、事前トレーニング段階の埋め込み層とネットワークパラメータがロードされます。これは、最初の段階のシーン間の教師なしトレーニングの情報を保持するのと同等です。
#微調整フェーズのユーザー側とアイテム側のメトリクス マッチング タスクでは、トレーニングに役立つ新しい補助タスクも導入しました。前述したように、各サンプルは、表現ネットワークを通じて特徴付けられた後、2 つのベクトル表現を取得できます。1 つは、各単一シーン ネットワークの一意のベクトル出力です。このベクトルは、対応する各シーンでの独立した表現を示します。もう 1 つは、グローバルに共有されるベクトルです。ユーザー機能またはアイテム機能のグローバル表現を表す出力。したがって、微調整フェーズ全体のトレーニング タスクには 2 つの損失が含まれます。1 つは、単一シーン ネットワークによるユーザーの埋め込み出力とアイテムの埋め込み出力の間で訓練された損失で、もう 1 つは、単一シーン ネットワークの出力に対応するユーザーの埋め込みとアイテムの埋め込みです。このような計算方法を通じて別の損失を取得することもでき、最後の 2 つの損失の加重合計がトレーニングの最終的な損失として使用されます。フルシーンロスという補助タスクの導入は、同一のユーザやアイテムの表現をドメイン全体で記述することと同等であり、各シーンの独立した特徴表現には適していないかもしれないが、トレーニング用のグローバル タスク 最後に、これは全体的な効果の収束に有益であり、その後の実験分析でもこの点を実証できます。
次に、リコールモデルの導入方法を紹介します。モデルのトレーニングが完了したら、微調整段階でモデルをデプロイし、オンラインにします。オンライン推定中に、各シーンの情報がモデル上の対応するシーンのネットワークを介して渡され、そのシーンの表現ベクトルが取得されます。
さらに、補助タスクでは、フル シーン ネットワークの出力はトレーニング フェーズでのみ使用されます。これは、混合サンプルであるため、多少のノイズがある場合でも、予測 When では、各シーンは依然としてそれぞれのシーンによって出力された特徴ベクトルを使用します。再現タスクの場合、アイテム側ですべての候補に対してこのベクトルを生成し、対応するインデックスを構築して、モデル展開によるオンライン推定中にベクトルを生成します。次に、ベクトル検索を通じて topk の結果が取得され、最後に結果がソート段階に返されて、推奨リンク全体に対して後続の操作が実行されます。
# 次に、このモデルを用いた実験解析と実装を紹介します。 . すでに実装されているアプリケーション。
# 私たちは 2 つのオープンソース データ セットと独自の産業データ セットを使用しています。他の方法の効果を比較しました。
比較方法は主に 3 つのカテゴリに分類されます。最初のカテゴリは、リコールに焦点を当てているため、従来の単一シーン モデルです。 task では、YoutubeDNN、MIND、BST、DSSM など、業界で人気のあるいくつかのリコール方法を比較します。これらの単一シーン モデルは、各シーンからの独立したサンプルを使用してトレーニングされます。 2 番目のタイプは、複数のシーンから混合されたサンプルをトレーニングに使用するもので、モデルは依然として業界で一般的に使用されている単一シーン モデルを使用します。 3 番目のカテゴリ は、業界の既存のマルチシナリオ共同モデリング手法と当社が提案する手法の一部です。これらの手法の一部は、ソート段階で使用され、リコール段階での実装に使用されます。より良い比較を行うために、これらの方法をわずかに変更しました。つまり、ランキング モデル ネットワークの最後の層の出力を表現ベクトルとして取り、再現タスクに適応させました。
上の表の最後の 2 つの列は私たちが提案したモデルです。SASS-Base は事前トレーニングを行わないモデル構造ですが、SASS は事前トレーニングを追加します。 .ステージ。私たちが検証した 2 番目のデータセットには欠落している特徴があり、事前トレーニング タスクをサポートできないため、このデータセットに対する SASS-Base と他の手法の効果を比較することに重点を置きました。
#さまざまな種類の方法を比較した結果、いくつかの貴重な結論が得られました。 最初のポイントは、混合サンプルでトレーニングされた単一シーン モデルは、ほとんどの場合、独自の個別のサンプルでトレーニングされた単一シーン モデルよりも効果が低いということです。これは、以前のデモンストレーションと調査の結論と一致しています。つまり、サンプルを混合するこの方法では、より多くのノイズが発生し、各シーンの元のデータ分布が壊れる可能性があります。ただし、データが特にまばらな一部の小さなシーンでは、サンプルを混合した方が良い結果が得られる場合があります。このようなシナリオでは、疎なデータを使用してトレーニングする場合、有効な情報を学習することが困難であるため、この混合サンプル手法を使用すると、データに偏りはあるものの、サンプル サイズの増加によってある程度の利点が得られ、効果が向上します。 2 番目の結論は、マルチシナリオ共同モデリングを通じてトレーニングされたモデルは、一般に最初の 2 種類の単一シナリオ モデリング手法よりも優れているということです。私たちが提案したモデルは、事前トレーニング タスクを追加していません。 SASS - 基本モデルの構造に関しては、基本的に、各シーンで他のマルチシナリオ ジョイント モデリング手法よりも優れているか、同様の結果を達成できます。事前トレーニング タスクを重ね合わせると、全体的な効果がさらに向上しました。
その後、主に次の部分を含む一連のアブレーション実験を実施しました。
最初のものは、グローバル シーンから単一シーンへの情報の転送を記述する適応ゲート構造です。モデルのゲート ネットワークの構造を、(1) 行列乗算マッピングを使用して情報移行を実現する、(2) Simnet に似た 2 つの機能を使用するなど、他の既存のゲート移行方法と比較しました。 MLP を介して融合を実行する; (3) シグモイド ゲートを介して移行される MOE と同様のネットワーク構造。最後に、実際の実験結果から判断すると、私たちの適応手法は良好な結果を達成できます。
2 番目のポイントは、事前トレーニング タスクを追加するかどうかと、さまざまな種類の事前トレーニング タスクが実験結果に与える影響を比較することです。対照的な事前トレーニング方法は、ユーザーの行動シーケンスを通じて次のビデオまたは次のアイテムを予測するトレーニング タスクです。結果を比較した後、事前トレーニング タスクが追加され、シーン間の対照学習を通じてモデルの効果が向上することが証明できます。
3 番目のポイントは、モデル構造設計における補助ネットワークと補助タスクを示すことです。一つは、ファインチューニング段階で世界共通のネットワークを導入し、その出力結果を利用して補助的なファインチューニング学習を行うこと、もう一つは、ネットワーク構造設計においてシーン関連情報を統合することです。各シーンの出力に対するバイアス特徴のアブレーション実験。実験結果は、これら 2 つの構造を追加すると、モデル全体の効果がある程度改善されることも証明しています。
また、表現ネットワークは多層の情報伝達構造であるため、ネットワーク層数を増やすことによるモデルの効果の向上も比較しました。全体的な傾向として、ネットワーク層の数が増加するにつれて、モデル効果が最初に向上し、その後低下することがわかります。その後のネットワーク層数の増加により効果が悪化したのは、ネットワーク層数の増加に伴い全体のパラメータ量が増加し、過学習現象が発生したためではないかと分析しました。さらに、上位レベルの表現を取得した後にこのような大量の情報の移行を実行すると、単一のシーンの表現がフルシーン情報の影響を受けやすくなる可能性があります。したがって、この多層ネットワーク構造の層数を増やすことである程度の効果は向上しますが、必ずしもネットワーク層の数が多ければ多いほど良いというわけではありません。
次の一連の実験では、各シーンが想起時に独自のベクトルを生成するため、想起タスクのさまざまなアイテム側の表現ベクトルを比較しました。一部のマルチシナリオモデリングでは、ユーザー側は異なる表現を持ちますが、アイテム側は詳細に記述されていません。リコールタスクでは、ユーザー側とアイテム側が各シーンに対応しています。各シーンは独自の独立したベクトル表現を持ち、そこで、各シーンに対応するアイテム表現と、シーンに共有される同じアイテム側の埋め込みも比較しました。比較すると、各シーンの独立したベクトル表現がアイテム側でも区別できることが分かる。
最後に、実際のコンテンツ推奨シナリオでこのモデルのオンライン A/B 実験を実施しました。いくつかの実験指標で良好な結果が得られており、特に比較的小規模またはまばらなデータ シナリオでは改善率が高くなります。
現在、私たちが提案したモデル ソリューションは、短いビデオ、画像やテキストの推奨などを含むタオバオのコンテンツ推奨シナリオで推進されており、このモデルはさまざまなシナリオでの主要な想起方法の 1 つとなっています。
最後にまとめてみましょう。全体として、私たちが解決したい問題は、レコメンデーション分野におけるマルチシナリオ モデリングの問題であり、これはレコメンデーション システムの一般的な問題でもあります。この種のマルチシナリオ モデリングにおいて、私たちの主な目標は、統一されたフレームワークを構築することで、さまざまなシナリオ間での情報の利用を最大限に高めることです。この共同モデリング手法により、データの希薄性の問題が解決され、各シナリオのビジネス指標が改善されます。また、同じメソッド アーキテクチャのセットにより、モデルの反復と展開のコストが削減されます。 しかし、実際のビジネス アプリケーションでは、マルチシナリオ モデリングは 3 つの主要な課題に直面しています。 1 つ目は、有効なシーン情報の洗練と移行をどのように達成するか、さらに、マルチシーン モデリングにおけるデータの疎性の問題を解決する方法と、ラベルのないデータを導入する方法、そして 3 つ目のポイントは、マルチシーン モデリングのリコール フェーズです。・シーンジョイントモデリング 着陸を行います。
私たちの実践では、この適応的なシーン情報転送ネットワーク アーキテクチャを設計し、モデル構造の設計、トレーニング方法、展開を含むシーン間の対照学習の教師なしタスクを構築します。課題。最後に、このシーン適応型教師なしモデルは現在すべてのシーンに適切に実装されており、主要なリコール方法として使用されています。
#A1: これはモデル評価の問題であり、各シナリオのモデリング目標に対応させて、シナリオごとの指標の改善を検討する必要があります。想起フェーズのタスクであれば、ヒット率やNDCGなど、対応するシーンごとに想起関連の評価指標を選択することになる。仕分け段階にある場合は、AUC や GAUC などの仕分け関連の指標に主に焦点を当てる必要があります。
#A2: まず第一に、私たちはマルチシーンの問題を全体として解決しているからです。定義が示すように、各シーン間でサンプルはほぼ整列しているため、実際にモデリングするときは、すべての特徴を整列させて平坦化するように努めます。さらに、各シーンに独自の特徴がある場合には、シーン バイアス ネットワークを設計し、完全に連携できない特徴については、この別のネットワーク構造に配置します。
#A3: このコード セットは現在、会社の実際のビジネス シナリオで使用されており、オープン ソースは会社の情報開示コンプライアンス要件に準拠する必要があります。将来的にはコミュニケーションを図り、オープンソースのデモ版を提供する可能性があります。
A4: 現在のモデル自体はリコール段階で実装されているため、モデル全体もそのようなリコール段階で展開されます。もちろん、提供するのは比較です。一般的なスキームは、いくつかの変更を加えて並べ替えモデルとして使用できます。
#A5: ネガティブサンプリングは主に微調整段階で行われます。ユーザーのクリックがポジティブ サンプルとして使用され、各シーンでのアイテムの露出確率に基づいてネガティブ サンプルがランダムにサンプリングされる、リコール タスクでより一般的なネガティブ サンプリング方法を使用します。次に、全体的なトレーニング タスクが各シーンで個別にトレーニングされるため、複数のシーンに分けられます。したがって、ネガティブ サンプルの際、ポジティブ サンプルに対応するネガティブ サンプルもシーンに対応する露光空間でランダムにサンプリングされ、ポジティブ サンプルとネガティブ サンプルのペアが構築されます。
A6: この問題は少し大きな問題です。詳しく説明しましょう。それは、現在のモデルのセットが淘宝網のコンテンツ推奨シナリオに実装されているということです。コンテンツ全体に基づいており、主なキャリアとして、写真、テキスト、ビデオが含まれます。全体的な機能システムは基本的に同じであり、完全に再利用できるため、この作品は完全に適応可能です。そしてもう一つは、実際に次の段階で何をしなければいけないかということで、プロダクトやコンテンツが挙げられるかもしれませんが、それぞれのデータ配信や機能体系が実際には異なっており、これはクロスドメインの問題として理解することができます。 . プロダクト領域とコンテンツ領域の融合です。私たちの次の段階の作業では、このようなクロスドメインのアイデアを複数のシナリオに導入し、一部の行動情報を商品ドメインからコンテンツ ドメインに移行することも望んでいます。 ２点目、目標の統一についてでございますが、目標の統一は達成できております。たとえば、ホームページのクリックに関しては、ユーザーのクリック信号をポジティブサンプルとして使用しますが、この無限の上下の流れでは、実際にはユーザーのクリックはなく、ユーザーのロングプレイ、完了を使用します。正のフィードバックとは、ラベル全体がそのようなバイナリ次元に平坦化されることを意味します。
A7: 一般的に言えば、私たちは今でもこの比較学習の考え方に従っています。実際、重要なポイントは、シーン間で特徴を分割した後、事前トレーニング タスクを構築することです。以前の PPT の説明、または論文の紹介文 (マルチシナリオのパーソナライズされた推奨事項のためのシナリオ適応型および自己教師ありモデル) を参照してください。
A8: 事前トレーニング タスクは、ユーザーが訪問する a と b の 2 つのシナリオなど、ラベルのないスペースで実行されます。属性特性と、各シーンに対応する歴史的に保存されたユーザーの行動シーケンス。これらは、2 つのシーン a と b における同じユーザーの特徴システムを構成します。事前トレーニングのモデリングの目標は、このアクセスされたユーザーをモデル化し、そのような特徴尺度を通じてシーン a とシーン b の間の 2 つの表現ベクトル間の距離を短縮することです。したがって、これは実際には教師なしタスクであり、クリックのないサンプル空間でトレーニングされます。
A9: これは実際には別の問題です。現在、マルチシナリオの問題を解決しています。すべてのシナリオが同じ目標を共有することを願っています。たとえば、クリック ターゲットや私たちが変換した 2 つのカテゴリのターゲットは、実際にユーザーがコンテンツとビデオのどちらに興味があるかを示しています。先ほどのマルチシーン・マルチターゲット手法については、実はマルチシーンとはちょっと違うんですけれども、このマルチシーンモデリングの上に、そういう多目的モデリング手法が構築できるというふうに理解しております。現在、複数のシーンと複数のターゲットを結合して表現するタスクに多くの作業が行われているため、たとえば、現在のアーキテクチャでは、表現ネットワークを通過した後、各サンプルは各シーンに対応する独立したベクトル表現を持つことになります。このベクトル式を入力として使用し、これに基づいてターゲットごとに固有のターゲット関連フィーチャ ネットワークを構築すると、実際にマルチターゲットおよびマルチシーンの共同タスクを実行できます。現在の複数のシナリオのトレーニング方法を基本的なフレームワークとみなして、それに基づいて他の複数の目的のタスクをモデル化することができます。これは理にかなっているような気がします。
A10: この損失は実際には従来の対照学習スキームに似ています。また、InfoNCE 損失、つまりバッチ サイズ n のトレーニング サンプルも選択します。対応するシーン内の同じユーザーまたはアイテムによって生成された 2 つのベクトルを正のサンプルとして扱い、他のサンプルに対応して生成された 2n-2 ベクトルを負のサンプルとして扱い、トレーニング用の損失を構築します。
#A11: 今注目したのはユーザー側なので、アイテム側も実際には同じ構造になっています。アイテム側についても、アイテム自体のグローバル共有ネットワークと、各シーンにおける各アイテムのネットワークパラメータの表現がある。したがって、同じモデル手法により、ユーザー側では完全に対称な構造となります。各アイテムは、このようなグローバルに共有されたパラメーターと各シーンのネットワーク構造を介して移行し、最終的にはシーンに関連する独立した出力を持ちます。
A12: これは良い質問です。現在のモデルは実際にはオフラインでトレーニングされ、毎日更新されます。また、適時性を向上させ、オンライン学習によるストリーミング研修を実施したいと考え、いくつかの代替の試みも行っています。もちろん、現在まだいくつかの問題が発生しており、主にこのようなマルチシナリオ トレーニング方法に反映されています。実際、複数のソースからのデータを同時に導入する必要があります。したがって、この種のストリーミング トレーニングでは、どのようにしてデータを複数のソースに同時にアクセスすることと、安定したトレーニングを確保する方法は実際には比較的大きな課題であるため、現在のモデルはまだオフライン日レベルで更新されています。将来的には、現在のオフライン マルチシナリオ共同トレーニングをベース モデルとして扱い、単一シナリオでのモデル復元を通じてストリーミング データを微調整し、この方法で反復更新を実行するなど、いくつかの試みを行う可能性があります。
#A13: これは実は今紹介されたものです。全体的な核心は、同じユーザーが異なるシナリオで直面するいくつかの機能の表現を分割することです。たとえば、2 つのシナリオ a と b にはいくつかの静的な機能があり、同時に、対応するシナリオに独立したユーザーの行動が残されます。シーケンス、および、カテゴリの好み、アカウントの好み、クリック露出などの統計的特性など、対応するシーンにおけるそのようなユーザーの統計情報。これは、データの特徴構造を異なるシナリオに分割することに相当し、同じユーザーが異なるシナリオで異なる特徴を持つことができます。これが特徴に関する構造であり、先ほど触れたサンプルに関する構造です。ユーザーが複数のシーンを訪問する場合、シーンはペアで結合され、そのようなサンプル ペアが構築されます。次に、アイテム側では、アイテムを複数のシーンに配置できるため、複数のシーン間のペアの組み合わせによってアイテムのサンプルを構築することもできます。
A14: 事前トレーニング フェーズは教師なしタスクです。私たちの焦点は、事前トレーニング タスクを通じてその埋め込みと対応するネットワークの表現を取得することです。パラメーター。したがって、トレーニング前の対照学習を評価する場合、主にトレーニング前の段階で生成されたベクトルの視覚的クラスタリングを通じて効果を分析します。
#A15: これは実際にはシーンの共通点と相違点についての説明です。マルチシナリオ ソリューションの本来の目的は、統一されたシナリオによって強化された後に、モデルを作成し、各シナリオで最適化します。もちろん、実際には、特に後続の反復において、すべてのシナリオで同じモデル アーキテクチャを使用して 100% の成功を達成することは不可能であり、利点の一部は明らかではない可能性があります。したがって、現時点では、実際には、現在のマルチシナリオ アーキテクチャの各シーンの特性に基づいて、上部構造の微調整設計を行う必要があります。つまり、マルチシナリオは、基礎となる埋め込み共有と情報に使用できます。移行部分を行うためのフレームワークです。もちろん、各シナリオには独自のネットワーク特性があり、たとえば、2 番目のホップの一部の強力なトリガー情報には独立した機能構造があり、上位層での適応が必要になります。
A16: 基礎となるエンベディングとグローバルに共有されるネットワークは各シーン間で共有され、各シーンに対応する各ネットワーク パラメーターはそれぞれシーンに固有です。
#A17: 現在、分割データベース構築方法を使用しています。つまり、各シーンに対応する候補が各シーンで独立したインデックスを生成します。
#A18: これに対する標準的な答えはありません。実際のビジネス シナリオに基づいて検討する必要があるかもしれません。
A19: リコールフェーズはマルチチャンネルリコールであるため、ベクトルリコールなど、さまざまなタイプのリコール方法が存在します。運用指標によっては人手によるリコール手法がいくつか用意されているため、現在の推奨段階では実際にはさまざまなリコール手法を融合し、仕分け側で統一スコアリングを行っています。今日私たちが話しているモデルに特有の、焦点は依然としてこのモデルの最適化にあります。
A20: 現在の計画では、モデル トレーニング後の初期化段階でモデル パラメーターを読み込むことです。埋め込みと事前トレーニング後にパラメータを更新する必要があるかどうかについては、事前トレーニングされたモデルをロードした後に修正する実験と、トレーニング中にそのようなモデルのトレーニングに参加し続ける実験の 2 つを行いました。微調整の段階。次に、現在私たちが使用しているのは、微調整フェーズ中に元の事前トレーニングされたモデルのパラメーターを再トレーニングすることです。
A21: シーン間の順序はランダムです。モデルは実際にそのようなグローバル シーンの情報を単一のシーンに移行するため、シーン間のトレーニング順序は実際にはランダムです。
A22: はい、シーンの違いに関しては、シーン内の特性を説明するために、通常、同じユーザーまたは同じアイテムを異なるシーンで異なる特性を持たせて使用します。差異、つまり、データ強化の方法としてシーン間の差異を処理します。シーンだけでなく、シーン上のユーザーやアイテムのいくつかの行動特性の表現も含まれます。
#Q23: オンライン推定では、事前トレーニングされた式を段階的に取得する必要がありますか?そしてリコールをするのか？A23: 事前トレーニングは、最終的なリコール タスクのトレーニングを支援するためのものであるため、見積もりの際には、展開のための第 2 段階の微調整タスクのみを使用します。このようなツインタワー構造モデルは、より古典的な DSSM として理解できます。したがって、最終的には微調整段階のモデル構造を利用してオンライン化し、表現入力を推定する際にユーザー側の式とアイテム側の式を出力します。
A24: この質問を別の言い方にすると、現在使用している 2 段階のアプローチをエンドツーエンドのトレーニングに変換できるかどうかです。トレーニングタスク シーン間の教師なしトレーニングを実行するだけでなく、これに基づいてユーザーとアイテムのリコールの共同トレーニングも実行します。このアプローチは実現可能だと思われますが、これを行わなかった理由は、ラベルのないサンプル データの使用の問題を解決できないためです。つまり、2 段階のタスクで使用されるサンプルは実際には異なり、事前トレーニング段階ではより広範囲のラベルなしデータが使用され、微調整段階ではラベル付きデータが使用されます。共同トレーニングを使用すると、そのようなラベル付きデータに対してのみトレーニングを実行できるため、実際にはサンプル空間が減少することになり、当初の設計意図とは多少異なります。
A25: これは各層で移行を実行します。つまり、多層構造では情報が移行され、単一層構造では情報が移行されます。この構造は次のようになります。積み重ねられた。先ほどの実験結果では、複数の比較を行った結果、レイヤー3を選択すると効果が若干向上することがわかっています。そのため、実際の業務実装においても、このモデルに対応する層数は3層となります。
A26: 事前トレーニングと微調整フェーズのタスクは、日レベルの増分トレーニングであり、微調整フェーズでは、事前トレーニングをインポートします。この 2 つの側面は、インクリメンタル トレーニングが並行して実行され、パラメータが中間でロードされることに相当します。
A27: 私たちの全体的なトレーニング方法は増分トレーニングであるため、時間枠は基本的に一致していると先ほど述べました。
以上がタオバオのパーソナライズされたレコメンデーションでの適応的で教師なしのマルチシナリオ モデルのモデリング実践の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
