How to increase user participation

背景

日常生活において、テレビを見るよりもスマートフォンや iPad で遊ぶことを好む子どもが多く見られます。この現象の重要な理由は、テレビを見る場合、子どもは放送される内容を一方的に受け取ることしかできないのに対し（チャンネルを変えることはできても、インタラクティブ性は非常に限られています）、スマートフォンや iPad で遊ぶ場合（たとえば「王者栄耀」などのゲーム）、子どもはデバイスと豊富にインタラクションでき、より強い没入感と面白さを感じられることにあります。同様に、主流のレコメンドシステム（おすすめ商品推測など）は学術環境でも企業レベルのアプリケーションでも良好な成果を上げていますが、レコメンドシステムのインタラクティブ性については十分な検討がなされていませんでした。

直感的には、インタラクティブ性の導入は、一方ではレコメンドシステムに対するユーザーの参加意識を高め、ユーザー体験を向上させ、他方ではレコメンドシステムがユーザーの嗜好をより深く理解し、より良い商品を推奨することでユーザー体験をさらに向上させることができます。インタラクティブレコメンド（以下、インタラクティブレコメンドと呼びます）の在り方を理解するため、我々は大量の学術論文を調査しました。KDD 2018 で発表された「Q&R: A Two-Stage Approach toward Interactive Recommendation」[1] という論文において、実現可能なフレームワークを発見しました。その概略図は以下の通りです。

このフレームワークでは、ユーザーがレコメンドシステムから商品を閲覧する際（おすすめ商品推測など）、システムがユーザーの関連情報を確認するための質問を生成し、ユーザーのフィードバックに基づいてユーザーの直接的な興味を取得し、商品を推奨します。レコメンドシステムのインタラクティブ性は、「質問」と「フィードバック」の全プロセスに体現されています。

次に、フレームワーク内の各モジュールを順に分析します。

質問生成モデル：最初の課題は、どのような形式の質問を生成し、どのように生成するかです。「寒くなってきましたが、マフラーをお探しですか？」のような完全な自然言語で質問を生成できれば理想的です。しかし、自然言語技術は大きな進歩を遂げたとはいえ、現時点ではユーザーの嗜好に合った大量の高品質な質問を生成することは困難です。そのため、図 2 に示すように、我々は「質問生成タスク」を「キーワードレコメンドタスク」に変換しました。具体的には、「マフラー」「ジャケット」「帽子」などのキーワードを生成し、カードに載せてユーザーに提示し、クリックを促します。これらのキーワードに対応する潜在的な質問は「寒いですが、マフラー/ジャケット/帽子をお探しですか？」となります。これにより、質問生成の形式、すなわちキーワードレコメンドを明確にしました。次に、キーワードレコメンドのための十分な大きさの候補セットをどのように取得するかという新たな課題が生じます。以下の理由から、検索ログ内の検索語をキーワードレコメンドの候補セットとして使用することにしました。

検索ログ内の検索語はユーザー自身が入力したものであり、その多くはユーザーのニーズを表現できる有意な言葉です。

検索ログ内の検索語の量は十分に多く、さまざまなニーズをカバーできるため、異なるユーザーに対して、異なる環境（異なるシーズンなど）において、そのユーザーのニーズに合った言葉を見つけて推奨することができます。

ユーザーフィードバック：次にユーザーフィードバックについて説明します。上記の例を挙げると、ユーザーがマフラー/ジャケット/帽子のいずれかのキーワードをクリックした場合、「はい、マフラー/ジャケット/帽子を買いたい」と回答したとみなします。クリックしなかった場合は、購入意思がないことを意味します。もちろん、ユーザーフィードバックにはその他の情報も含めることができます。たとえば、ユーザーが「帽子」をクリックする前に「マフラー/ジャケット」をクリックしたかどうか、クリック後の詳細ページでのスワイプ、追加購入、お気に入り登録などの行動、質問生成からユーザーフィードバックまでの時間間隔などです（時間間隔が長いほど、ユーザーの需要が弱いことを示します）。

商品レコメンドモデル：最後は商品レコメンドです。ユーザーがキーワードをクリックすると、ユーザーの意図が明確であることを意味し、そのキーワードを直接入力として検索アルゴリズムを呼び出し、商品リストを取得します。ご覧の通り、我々の処理では最後の 2 ステップは古典的な検索タスクであり、その概略図は以下の通りです。

これは本質的に「先にレコメンドし、それから検索する」というプロセスです。「レコメンド」はキーワードレコメンドに対応し、「検索」はユーザーがクリックしたキーワードに基づく検索結果の取得に対応します。検索タスクはユーザーの意図が明確なため、レコメンドタスクよりも多くの取引を生み出せること、そしてレコメンドタスクはユーザーがキーワードを入力する必要がないため、検索タスクよりもインタラクションコストが低いことはよく知られています。我々の処理では、ユーザーがキーワードを入力する必要がなく、かつユーザーの意図を明確にしてそれに合致する商品を返すことができます。まさに検索とレコメンドの良いところ取りと言えます。

最後の 2 ステップを古典的な検索タスクに変換したため、既存の検索アルゴリズムを直接呼び出すことができます（インタラクティブレコメンド向けの微調整のみ）。したがって、最初のステップである「キーワードレコメンド」が我々の最適化の焦点となります。

注意点として、キーワードレコメンドは質問を生成する一手段に過ぎません。動画、ガイド、単一商品も質問生成の素材として使用できます。それに対応して、ユーザーフィードバックや商品レコメンドの形式も多様です。フィードバックは、スワイプ画面、いいね、コメント、攻略ページでの滞在時間などが含まれます。商品レコメンドも、動画、ガイド、または単一商品に基づく商品ソートに置き換わります。

プロダクトの形

キーワードレコメンドアルゴリズムの説明に入る前に、まずプロダクトの形式を紹介します（説明の便宜上、プロダクトを「Wind Vane」と名付けました）。これにより、直感的な理解が得られます。Wind Vane のプロダクトコンセプトは以下の通りです。

(1) インタラクティブであること。

(2) ニーズにフォーカスし、説明可能で、強い体験感があること。

(3) シーン感覚があること。

このコンセプトに基づき、プロダクトのゲームプレイを以下のように設計しました。図 4 に示すように、ユーザーはまずタオバオのホーム画面の「おすすめ」ページで商品をクリックし（第 1 画像に対応）、商品詳細ページに入った後（第 2 画像に対応）、スワイプ、追加購入、お気に入り登録などの操作を行います。ユーザーが「おすすめ」ページに戻ると、アルゴリズムが Wind Vane を表示するかどうかを判定し、シーンに基づいた Wind Vane のコピー（第 3 画像の「南宝はこう着こなす」など）と、そのシーンに出現するキーワードを生成します（第 3 画像に対応）。ユーザーがキーワードをクリックすると、第 2 ホップの検索結果ページに遷移します（第 4 画像に対応）。

構成

全体の技術フレームワークを図 5 に示します。まず、検索ログ、商品情報、ナレッジグラフデータに基づいて基礎データテーブルが生成されます。次に、キーワードの候補抽出とソートのプロセスを経ます。ソート時には、ユーザーの過去の嗜好だけでなく、詳細ページのユーザー情報（端末インテリジェンス）も考慮し、表示コントロールモジュールを通じてソート結果を調整します。ユーザーがキーワードをクリックすると検索プロセスがトリガーされます。最後に、ログは検索ログに書き戻されます。点線は、今後さらなる最適化が必要なモジュールを示しています。以下、候補抽出、ソート、表示コントロール、端末インテリジェンスの 4 つのコアモジュールを説明します。

候補抽出

候補抽出の全プロセスは、metaPath モデル [2] を用いて統一的に説明できます。具体的には、図 6 に示すように、ユーザー、商品、キーワード、シナリオ、カテゴリはすべてヘテロジニアスネットワーク内のヘテロジニアスノードとみなすことができ、異なる候補抽出戦略が異なる metaPath に沿ってユーザーに適切なクエリを見つけるために使用されます。各 metaPath はそれぞれのタイプとスコアに対応します。目的は、ヘテロジニアスネットワーク上の metaPath に基づいて、ユーザーとキーワードの間に関連性があるかどうか、およびその関連性の強さを評価し、最も強い関連性を持つキーワードをユーザーに推奨することです。以下、異なる候補抽出戦略を順に紹介します。

u2i2q：核心的なアイデアは、検索結果ページにおける検索クエリと商品の関連性（q2i）に基づいて、商品とクエリの関連性（i2q）を逆方向に取得し、ユーザーがクリックした商品とクエリの関連性を構築することです。その原理は、検索ログにおいて、クエリと商品が同時に出現する頻度が高いほど、その関連性が強いというものです。metaPath モデルでは、この戦略はユーザー→商品→クエリの metaPath に沿ってクエリを見つけることを意味します。

u2i2scene2q：図 7 に示すように、この候補抽出は 2 つのプロセスに分かれます。i2scene（左）は商品をクリックすると対応するシーンが有効化されることを意味し、scene2q（右）はシーンが対応するキーワードを生成することを意味します。

u2i2c2q：主なアイデアは、ナレッジグラフを導入し、カテゴリ情報を使用してクエリの候補抽出効果を高めることです。

現時点では、候補抽出モードはキーワードのみで比較的単一ですが、今後は動画やガイドなどの他のモードのエンティティも導入される予定です。また、詳細ページの行動データやナレッジグラフを活用して候補抽出効果を高める余地も大きく残されています。

ソート

ソートは、精密ソートとリランキングの 2 つのプロセスに分かれます。精密ソートには 2 つのバージョンがあります。

バージョン 1：xftrl

ftrl の理論研究は 10 年以上の歴史がありますが、Google が KDD 2013 で発表した論文 [3] がこの理論モデルを完全にエンジニアリングし、ftrl に基づく多くの企業レベルのオンライン学習モデルを生み出しました。xftrl は xps プラットフォームが ftrl に基づいて開発した専用モデルで、タオバオの数百億のスパース特徴量を処理できます。オフライン実験では、最初の 4 日間のデータをトレーニングに使用し、翌日のデータをテストに使用した結果、xftrl はテストセットで 0.67 の AUC を達成しました。

バージョン 2：Attention_GRU

(1) 動機

xftrl（ftrl）は非常に効果的で、成熟した技術実装を備えています。しかし、xftrl（ftrl）には以下の欠点があります。

多くの研究で、ユーザーの長期・短期的な興味と行動の系列 [4,5] を考慮することがレコメンド効果の向上に役立つことが証明されていますが、xftrl（ftrl）は特徴量エンジニアリングを通じてこれらの系列情報のごく一部しか取り込むことができません。

xftrl（ftrl）は本質的に線形モデルであり、特徴量の交互作用は特徴量エンジニアリングで交互式特徴量を追加することによってのみ実現できます。これはアルゴリズムエンジニアのビジネスに対する理解と経験に大きく依存します。一般的に、アルゴリズムエンジニアは特徴量エンジニアリングにおいて 2 次の交互作用特徴量のみを考慮するため、高次の特徴量間の交互作用関係を捉えることができません。全体として、特徴量エンジニアリングで特徴量の交互作用を捉えることは、無効な交互式特徴量の追加や重要な交互式特徴量の欠落を招きやすいと言えます。

この課題に対し、我々はカスタマイズした Attention_GRU モデルを使用してキーワードレコメンド効果を向上させることを提案しました。Attention_GRU は系列データ（過去の行動系列を含む）をうまくモデル化できることが証明されています。また、Attention_GRU は本質的にニューラルネットワークモデルであり、特徴量間の交互作用（高次）関係をニューラルネットワークの非線形活性化関数によって捉えることができます。もちろん、確信度の高い交互式特徴量をニューラルネットワークに入力し、その部分の特徴量の交互作用を明示的にモデル化することもできます。カスタマイズした Attention_GRU モデルは、主に IJCAI 2017 と IJCAI 2018 で発表した 2 本の論文 [4,5] に基づいています。

(2) モデルフレームワーク

モデルは 4 つの特徴量、すなわちユーザー側の非リアルタイム特徴量、ユーザー側のリアルタイム特徴量、クエリ側の特徴量、その他の特徴量に分かれます。4 部分の特徴量を取得した後、結合して 3 層のニューラルネットワークに入力し、ニューラルネットワークの出力とラベルに基づいて損失を計算します。

(3) Attention_GRU

このうち、Attend と Generate は関数です。各要素が j 番目の入力に対するアテンション重みを表すベクトルです。glimpse として知られます。Recurrency は循環活性化関数を表します。Attention_GRU では、循環活性化関数は GRU です。

我々の GRU の実装では、上記の式の x は図 8 の i に対応します。

Attention_GRU で一連の実験を行いました。最初の実験では、クエリ側のカテゴリ特徴量のみを使用しました（クエリ ID はスパースすぎるため、より粒度の細かいカテゴリを使用しました）。レコメンドの AUC は 0.5685 で、0.5 を上回り、キーワード自体の（カテゴリの）人気がキーワードレコメンドに有用であることを示しました。ユーザーの過去の行動系列における商品カテゴリの特徴量を追加した後（商品 ID ではなく商品カテゴリを使用する理由は上記と同じ）、AUC は 0.6037 に向上し、過去の商品（カテゴリ）と系列情報が有用であることを示しました。さらに、商品タイトルとキーワードのテキスト特徴量を追加したところ、AUC は 0.6203 に上昇し、テキスト情報の使用がキーワードレコメンド効果をさらに高められることを示しました。最後に、図 8 のすべての特徴量を追加した結果、AUC は 0.6830 に達し、ベンチマーク手法の xftrl を上回りました。表 1 が我々の実験結果です。

表 1 xftrl、Attention_GRU、および改良型 Attention_GRU のオフライン実験効果。

(4) Attention_GRU の改良

キーワードレコメンド効果をさらに高めるため、Attention_GRU のアテンションメカニズムにいくつかの独創的な改良を加えました。主な動機は以下の通りです。

ユーザーの過去の行動が発生してから時間が経つほど、キーワードレコメンドへの影響は小さくなり、対応するアテンション重みも小さくなります。すなわち、アテンション重みの時間減衰です。

異なる行動タイプはキーワードレコメンドへの影響が異なります。たとえば、購入行動はクリック行動よりも強い影響を持ち、対応するアテンション重みも異なります。すなわち、アテンション重みへの行動タイプの介入です。

ここで、d × d の次元の行列です。時間間隔は過去の行動の発生とキーワードレコメンドの間の時間差を表し、Time_decay は単調減少関数です。表 1 に示すように、Attention_GRU の改良後、AUC は 0.6999 に達しました。さらに、ODPS データを tfrecord フォーマットに変換してモデルの入力とした結果、トレーニング速度が 40% 高速化されました。

(5) いくつかの考察

xftrl には Attention_GRU にない特徴量が含まれており、Attention_GRU がモデル化する長期・短期の系列と重要性は xftrl では効果的にモデル化されていないため、両モデルは補完的です。今後、両モデルを組み合わせて効果をさらに高めることができます。

精密ソートプロセスにはまだ多くの改善余地があります。たとえば、キーワード、動画、ガイドなどのマルチモーダルエンティティをどのようにソートするか、詳細ページでのユーザー行動などのリアルタイム特徴量はキーワードレコメンドに非常に重要ですが、どのようにこれらの特徴量をより良くモデル化するか、ナレッジグラフデータを効果的に活用してモデル効果をさらに高める方法などです。

リランキングプロセスは比較的単純で、主にランキング効果を確保した上で、より多様なキーワードを生成することを目的としています。

表示コントロール

表示コントロールは 2 つの部分に分かれます。(1) 位置、タイミング、意図などのコントロール。(2) シーン化と業界介入です。

位置、タイミング、意図などのコントロール：位置とタイミングのコントロールは、主に一部の悪いケースの出現を防ぐためのものです。意図コントロールは、モデルを使用してユーザーの意図を識別し、Wind Vane を表示するかどうかを決定することを意味します。

シーン化と業界介入：ソートで生成されたキーワードはニーズのフォーカスに優れていますが、シーン感覚と発散性が不足しています。そのため、モデルを使用して 4 つのキーワードの生成をより合理的にし、対応するシーンのコピーを生成します（たとえば、図 4 の「南宝はこう着こなす」）。さらに、ダブル 11 やブラックフライデーでは業界介入も導入しました。一方では、業界知識を導入して Wind Vane の効果を高め、他方では、一部の業界指標を補完して有利な効果を達成することができます。

端末インテリジェンス

ユーザーは商品詳細ページで、追加購入、お気に入り登録、滞在時間など、多くの行動情報を持っています。これらの情報は、ユーザーの直接的な興味を捉えるために非常に重要です。端末インテリジェンス情報をモデルに導入した後、キーワードレコメンド効果は大幅に向上しました。

もちろん、このモジュールにも多くの改善余地があります。

端末インテリジェンス情報は多数あり、スワイプ経路、商品識別の閲覧、購入者コメントの閲覧なども含まれますが、まだモデルに組み込まれておらず、より有用なシグナルの導入がレコメンド効果の向上につながります。

詳細ページでのユーザー行動も一つの系列であり、Attention_GRU モデルを使用して詳細ページの行動系列をモデル化することで、レコメンド効果をさらに高められます。

候補抽出、精密ソート、リランキング、表示コントロールのプロセスは現在すべてサーバー側で処理されていますが、実際には各端末が独自のモデルを保持できるため、上記のプロセスを端末側に移行してリアルタイムのモデル更新を実現できます。サーバー側のフレームワークでは 1 つのモデルがすべてのユーザーにサービスを提供しますが、端末インテリジェンスのフレームワークでは、各ユーザーが独自のパーソナライズされたモデルを持つことになります。

ダブル 11

Wind Vane はダブル 11 で非常に優れた成果を上げ、すべてのビジネス指標が期待を上回りました。ユーザーの収束ニーズと発見ニーズに対応して、ダブル 11 の異なる時間帯に異なるコントロール戦略を採用しました。前半はユーザーの購買意欲が明確で、収束型クエリのプッシュに注力し、低迷期は発見ニーズが強いため、主にシナリオベースのクエリをプッシュし、夜間はもう一波の購買ニーズを取り込み、収束型クエリの数を増やしました。

まとめと展望

インタラクティブレコメンドは有望な方向性です。ホーム画面の「おすすめ」において、我々は Wind Vane というインタラクティブレコメンドの革新的な試みを行いました。全員の努力により、Wind Vane は 2018 年のダブル 11 で一定の成果を上げました。

しかし、まだ多くの改善余地があります。

現在使用している詳細ページデータは、追加購入、お気に入り登録、滞在時間など、まだ限定的です。今後は、詳細ページでどのボタンがクリックされたか、どのセクションが閲覧されたか、スワイプの経路と速度など、詳細ページのより多くのデータを取得し、これらの詳細ページデータをより良くモデル化するためにモデルをさらに最適化します。

シナリオベースのクエリの候補抽出ロジックはまだ比較的単純です。今後は、ナレッジグラフ情報を導入して、シーンベースのクエリの候補抽出とソート効果を高めます。

特徴量システムと目的関数の改善が必要です。現在の特徴量システムは主にユーザー側の特徴量とクエリ側の特徴量を含んでいますが、トリガーアイテムの情報を十分に活用していません。また、現在の目的関数は主に第 1 ホップのクリック率を考慮していますが、第 2 ホップの PV と取引量の方が明らかに重要であるため、第 2 ホップの指標を目的関数にどのように組み込むかも最適化のポイントです。

現在、第 2 ホップのページは検索を呼び出すインターフェースです。しかし、検索インターフェースは主に第 2 ホップの結果ページのキーワードとの関連性とユーザーのパーソナライゼーションを考慮しており、第 1 ホップのトリガーアイテムを考慮していません。そのため、2 ホップアルゴリズムの改善または新しい 2 ホップアルゴリズムの再設計も最適化すべきポイントです。