運用内容（運用の「推奨事項」について知っておくべき2～3の事柄）

「推奨事項」について知っておくべき2、3のこと

編集者注: 運用と推奨は切り離せない関係にあるようです。操作のみで推奨がない場合、操作効果は大幅に低下します。推奨だけがあって運用がなければ、当然推奨は実行できません。したがって、運用の専門家はさまざまな運用スキルを習得する必要があるだけでなく、推奨事項についてもある程度理解している必要があります。この方法でのみ、私たちは共に前進し、理想的な目標を達成することができます。

「シェフ」になりたくない「バイヤー」は「良いオペレーター」ではありません。コンテンツ製品の場合、日常の運用作業、特に「コンテンツ運用」の学生は、推奨アルゴリズムの学生と共同作業を行うことが多いです。

オペレーション学生はレストランのバイヤーのような存在で、食材の仕入れを担当します。一方、レコメンデーション学生はシェフのような存在で、ユーザーが注文したメニュー（好み）を組み合わせ、対応する食材を使用してユーザーが好みそうな料理を作ります。

このチェーンでは、オペレーションの学生が上流にいます。紹介するコンテンツやクリエイターの質が高くなければ、購入する食材が新鮮で質が高くないのと同じように、推薦生がどれだけ頑張っても美味しい料理を作ることは難しいでしょう。

同時に、別の問題もあります。運営学生が最高の食材を仕入れたとしても、推薦学生が調理方法に問題を抱えていた場合、推薦学生は食材を最も合理的な方法で使用できず、食材の価値を最大化できず、資源を無駄にしてしまうことになります。

そのため、運用担当者は、自身の上流作業をしっかり行うだけでなく、推奨される関連作業も知っておく必要があります。こうすれば、料理が美味しくないとき、それが食材の問題なのか調理方法の問題なのかをすぐに知ることができるのではないでしょうか。次の調整をより速く行います。

運用担当者が最初に理解する必要があるのは、コンテンツがどのように推奨されるかということです。私たちが紹介するクリエイターとそのコンテンツは、どのように階層化されたプロセスを経て、推奨されるかどうか、またどの程度のトラフィックが与えられるかが決定されるのでしょうか?

システムに入った後のコンテンツの全体的な処理フローは、製品によって、また自社で処理していないものによっても異なりますが、全体的なロジックは基本的に同じです。大きなモジュールのビジネスロジックは、基本的に下の図のようになります。

上の図に示すように、ユーザーがコンテンツをアップロードすると、そのコンテンツはまずセキュリティ レビュー プロセスを経ます。セキュリティレビューの主な目的は、違法、ポルノ、暴力、流血などのコンテンツを削除することです。審査に合格しなかった動画は基本的に永久にブロックされるか、直接削除されます。

セキュリティ レビューに合格すると、ほとんどのコンテンツ コミュニティでは、繰り返しアップロードまたは移動されたコンテンツを除外するための独自のレビューが行われます。オリジナルレビューのほとんどは機械によって行われ、オリジナルレビューに合格しなかったものは、ユーザー自身の個人ホームページやファンのフォローページなどのプライベートドメインにのみ表示されます。

独創性審査に合格した動画は、最初の品質審査に進みます。品質レビューの主な目的は、意味のない、話題に関係のない、乱雑なコンテンツを除外することです。最初の品質レビューに合格すると、コンテンツは推奨システムによって推奨候補プールに追加され、その後、最も基本的なトラフィック推奨が作品に与えられます。基本的なトラフィック後に生成されるデータを通じて、作業の品質を事前に判断することが目的です。

基本トラフィック後のデータフィードバックが良好であれば、さらにトラフィックの推奨事項が提供されます。より多くのトラフィック推奨事項を取得した後、データのパフォーマンスが良くない場合、推奨事項は停止されます。データのパフォーマンスが良好であれば、2 回目のコンテンツ品質レビューまたはレポートレビューに進みます。

2 回目の品質レビューの主な目的は、前回のレビューでの漏れや、コミュニティ コンテンツのトーンに合わないコンテンツが表示されるのを防ぐことです。レポートレビューとは、コンテンツを消費するユーザーが積極的にクリックしたレポートを指します。報告が多すぎるコンテンツは潜在的なリスクがあるはずなので、再度手動で確認する必要があります。

2 回目の品質レビューまたはレポートレビューに合格すると、作品は引き続き多くのトラフィックを受け取り、推奨サイクルに入り、コンテンツ プラットフォームによる重要な推奨の候補コンテンツになります。

ただし、継続的な推奨プロセス全体を通じて、リスクがないことを確認するためにプラットフォーム全体で最も人気のある動画をレビューするハイプロファイルレビューなどのより詳細なレビュープロセスがいくつか行われます。同時に、ユーザーからの報告は継続的に確認され、潜在的な違法行為をタイムリーに検出します。

継続的な推奨プロセス中に、コンテンツのデータ フィードバックが減少すると、推奨は徐々に低下し、最終的に停止します。

上記のすべてのプロセスにおいて、推奨が停止された作品は、偶発的なトリガーやその他のリコールにより、後続のプロセスで再アクティブ化され、推奨のためにより多くのトラフィックが与えられます。よくある例としては、お祭りがあるときに、過去のお祭りに関連したコンテンツが思い出されて、再度おすすめされる、といったことが挙げられます。

上記の推奨プロセスを理解すると、運用スタッフは全体的なコンテンツ フローを明確に理解し、それを独自の製品やビジネス ロジックと組み合わせて全体的なプロセスを改良できるようになります。こうすることで、問題が発生した場合に、コンテンツが現在どの段階にあるかをタイムリーに把握できるようになります。

上記の推奨プロセスは、コンテンツフローのロジックを明確にするのに役立ちますが、上図のトラフィック推奨モジュールがどのように推奨を行うかはわかりません。この問題を理解するには、まず推奨システム全体を理解する必要があります。

推奨システムを簡単に分解すると、主にデータ、アルゴリズム、アーキテクチャの 3 つの側面で構成されていることがわかります。

1. データは主に、ユーザーやコンテンツの特徴情報、コンテンツに対するユーザーの行動フィードバックデータなど、推奨に必要な情報を提供します。
2. アルゴリズムは主に戦略とロジックを提供します。膨大な量のデータがある場合、手動の戦略を分析して介入することは困難です。したがって、情報ロジックを自動的に処理して推奨コンテンツを返すには、一連のアルゴリズムが必要です。
3. アーキテクチャは主にデータとアルゴリズムを運ぶプラットフォームであり、上流と下流のデータとロジックを接続して、システムが安定してリアルタイムかつ自動的に実行できるようにします。

一般的な推奨システムを以下の図に示します。

上記の推奨アーキテクチャでは、データ ストレージ モジュールは主に、コンテンツ インデックス (コンテンツを見つけやすくするための、コンテンツに対応する論理識別子)、ユーザー機能 (ユーザーのポートレート情報、興味のあるポイントなど)、およびユーザー ログ (クリック、いいね、共有、コメントなど、クライアント側でユーザーがコンテンツに対して生成した一部の動作を含む) を保存する役割を担います。

推奨アルゴリズム部分では、コンテンツインデックスを通じてコン​​テンツが呼び出されます。呼び出される候補コンテンツは通常、数が多く、その後、フィルタリングのレイヤーを通過して、推奨に適さないコンテンツや、他の操作やレビュー ロジックに干渉するコンテンツが除外されます。結果として得られた推奨候補プールはソートされます。

選別は通常、粗選別と細選別の 2 つのステップに分けられます。ソート方法は、ユーザー特性とユーザー行動ログを使用して、ユーザーが絞り込む可能性が最も高い順序にコンテンツを並べます。このようにして、最終的にソートされたコンテンツがクライアントにプッシュされ、クライアントの実際の表示シナリオに従って表示されます。

コンテンツが表示された後、ユーザーの行動がログを通じて再報告され、その後、ログの計算、ユーザーポートレートの更新、CTRなどの推奨指標の更新がリアルタイムで実行されます。リアルタイム計算が完了すると、最終保存用のデータストレージに更新されます。

このようにして、その後の推奨事項のために取得されるデータはすべて最新のものになります。

上記の推奨システム構造図により、推奨の上流と下流の動作原理を理解し、推奨システムのコンポーネントを知ることができます。これらのコンポーネントのうち、日常業務と最も関係する部分は推奨アルゴリズムです。推奨アルゴリズムの 2 つの主要なステップは、リコールとソートです。

これを理解すれば、基本的に推奨アルゴリズムの原理を理解でき、推奨の問題に遭遇したときに、問題がどこにあるのかがわかるようになります。

まずは「リコール」について見てみましょう。リコールとは何ですか?

リコールとは、レコメンデーション システムが特定の戦略を通じてコン​​テンツ プール全体から一部を選択することを意味します。一般的に、推奨システムがリコールする方法には、一般的な人気リコール、協調フィルタリング リコール、興味タグ リコールなど、さまざまなものがあります。

シングルリコールには独自の利点がありますが、同時に欠点も明らかです。したがって、より完全かつ包括的な想起を実現するために、次の図に示すように、「多方向想起」が通常採用されます。

上図に示すように、ユーザーのパーソナライズされた要素があるかどうかに基づいてリコールを分類すると、2 つのカテゴリに分けられます。1 つは、人気のあるコンテンツや過去のクリックスルー率が高いコンテンツのリコールなど、パーソナライズされた要素のないリコールです。もう 1 つは、ユーザーの興味タグの想起や協調フィルタリングの想起など、パーソナライズされた要素を含む想起です。

一般的なリコール戦略は次のとおりです。

1. 人気リコール：サイト全体、各種コンテンツ指標に基づいて算出された総合スコアの現在のランキング、このランキングから最初のk1コンテンツをリコールします。
2. 興味タグ: ユーザーの好みに基づいた興味タグを指します。たとえば、ユーザーがスポーツでバスケットボールを見るのが好きな場合、バスケットボールのタグから k2 コンテンツが呼び出されます。
3. ユーザーベースの協調フィルタリング: ユーザー間の興味の類似性を計算することを指します。たとえば、ユーザー A が {a、b、c} を気に入っており、ユーザー B が {a、b、d} を気に入っている場合、2 人のユーザーのお気に入りセットの共通部分を和集合で割ると、2 人の興味の類似度が求められ、{a、b}/{a、b、c、d} = 0.5 になります。このようにして、推奨ユーザーと最も類似した興味を持つユーザーを見つけて、ユーザー A に d を推奨するなど、他の現在のユーザーが見ていないコンテンツを推奨することができます。類似ユーザー間の異なるコンテンツのリストに従って、上位 k3 のコンテンツを呼び出すことができます。
4. コンテンツベースの協調フィルタリング: ユーザーベースの協調フィルタリングと同様に、ここでは異なるコンテンツ間の類似性を計算します。計算方法はたくさんあります。簡単な方法は、2 つのコンテンツを「いいね！」したユーザーの数の重複を直接計算することです。このようにして、現在のコンテンツに類似したコンテンツのシーケンスを取得し、類似度で並べ替えて、推奨のために上位の K4 を呼び出すことができます。
5. ソーシャル関係に基づくリコール: 一般的に、ソーシャル メディアの関係を通じて、ユーザーの友人が好きなコンテンツがユーザーに推奨されます。たとえば、友人が好きな WeChat ビデオ アカウントのコンテンツ推奨などです。
6. 文脈情報の想起: 午後のある時間的文脈と場所に基づいて情報を想起することを指します。最も典型的な例は、祭りの期間中に休日関連のコンテンツを思い出すことです。もう 1 つの例は、地理的な位置に基づいて近くのコンテンツを思い出すことです。

リコール後のソートは、一般的に大まかなソートと細かいソートの 2 つの段階に分けられます。

1. 大まかなソートには通常、大量の想起されたコンテンツの単純な融合ソートが含まれます。たとえば、上位 k 個のそれぞれから複数のリコール ソースが選択され、大量のリコールされたコンテンツが制御可能なレベル (通常は数千のレベル) に切り捨てられます。そうしないと、細かい選別の段階に非常に時間がかかります。
2. 精密ソートでは、一般的にソートにモデルを使用し、ソート後に呼び出されるコンテンツは数百に達します。

細かいランキングを実行する方法はたくさんあります。最も基本的なものは、戦略ルールソート（指定された重みとルールで各リコールをソートする）です。その後、LR（線形回帰）、LR+GBDT（線形回帰+ツリーモデル）、FM（因子分解モデル）、DNN（ディープラーニングモデル）など、さまざまなモデルに基づいてソートが行われます。

さまざまなモデルのランキングはかなり複雑で、その多くは解釈できません。ここでは詳細には触れませんので、興味のある読者は自分で検索してください。

上記の推薦ロジックを理解すれば、運営側の学生は推薦した学生と基本的にスムーズにコミュニケーションをとることができます。同時に、推奨システムに潜在する問題点を迅速に発見し、自身の運用経験に基づいて推奨リコール、ユーザーポートレート、コンテンツ機能などについて独自の意見を述べることもできます。

この記事を書く過程で、私はいくつかの本や記事も参考にしましたが、皆さんにもお勧めします。

参考文献:

南村小富、WeChat パブリックアカウント: 誰もがプロダクトマネージャーであるコラムニスト、南村小富。 Kuaishou のシニア プロダクト マネージャー。以前は Alibaba と YY で勤務し、インターネット プロダクトの設計と運用で 7 年の経験があります。

この記事はもともと「Everyone is a Product Manager」に掲載されました。無断転載禁止

タイトル画像はUnsplashより、CC0契約に基づき提供