7.1レコメンデーションシステムの基本モデル

推奨システムは教師あり学習です
- 教師あり学習のサブ学習と予測
学習システムは所定のトレーニングサンプルを使用します
- モデルはトレーニング後に取得され、モデルは予測システムの予測に使用されます。
予測システムは、モデルによる所定のテストサンプルの予測を提供します

ここに画像の説明を挿入

レコメンデーションシステムの目的
- 予測システムの結果がテストサンプルの実際の結果に近づくように、学習システムを通じてモデルを効果的にトレーニングします
予測されたコンテンツ、
- 情報、曲、またはビデオが好き
- 特定の商品を購入する確率
推奨システムの最適化、
- パス（モデル、アルゴリズム、データ、機能）、
- 予測結果の精度を向上させる、
- ユーザーにおすすめのアイテムは、ユーザーの本当の好みに近い

学習システムで処理されるユーザーデータの量が増え、データの次元が増え、使用される推奨モデルもより複雑になります。
コラボレーションモデル、コンテンツモデル、ナレッジモデル
コラボレーションモデルでは、主に友達の好みに基づいて自分が好きなものを推測します。
コンテンツモデルはアイテム自体に基づいており、ユーザーはAが好きで、Bも好きだと予測します。
知識モデルは、ユーザーの限られた条件に基づいており、ユーザーのニーズに応じて推奨されます

推奨されるシステムアーキテクチャ設計は、教師あり学習の基本モデルに基づいており、ビジネスのニーズに応じてカスタマイズされます。ビジネスニーズに合ったレコメンデーションシステムを磨く。
学習システムでは、データを報告し、整理し、機能を構造化する必要があります。
データを保存および処理するためのプラットフォームが必要です。
データの量とデータの種類によっては、学習システムをカスタマイズする必要がある場合があります。
予測システムでは、予測リクエストを処理し、ビジネスコール用のAPIとしてパッケージ化する必要があります。
同時に、オンラインサービスの信頼性とスケーラビリティも確保する必要があります。

次に、最初に一般的に使用されるレコメンデーションシステムのアーキテクチャを紹介します。
- 次に、これらのアーキテクチャの理解に基づいて、各モジュールのいくつかの一般的なコンポーネントを紹介し、
- 最後に、推奨システムのいくつかの一般的な問題を紹介します。

7.2レコメンデーションシステムの共通アーキテクチャ

このセクションで紹介するいくつかのレコメンデーションシステムアーキテクチャは相互に独立していないため、実際のレコメンデーションシステムはこれらのアーキテクチャの1つ以上を使用する場合があります。
実際には、この記事で紹介するアーキテクチャーを設計の出発点として使用できます。独自のビジネス特性に合わせて、より独立した思考を独自のビジネス特性と組み合わせて、独自のビジネスに適したシステムを設計する必要があります。

ユーザーの行動速度に応じたオフライントレーニングとオンライントレーニングに基づく推奨システム。
従来の機械学習とディープラーニングを使用した推奨システム
ビジネスの重要性のために、コンテンツ指向の推奨システムという別のカテゴリーが導入されています。
各セクションの最後に、実際のシステム設計で発生する問題を紹介します。
- 設計参照用。

7.2.1オフライントレーニングに基づくレコメンデーションシステムのアーキテクチャ設計

「オフライン」
一定期間（1週間または数週間）の履歴データを使用してトレーニングします。
- モデルの反復のサイクルが長い（時間単位）
フィッティングは、ユーザーの中長期的な関心事です。
モバイルアプリケーション市場、音楽推薦
「オンライン」トレーニングは、インクリメンタルなリアルタイムトレーニングを指します。
- モデルは、各トレーニングサンプルにすばやく応答する必要があります。
- ユーザーは現在食べ物のビデオを見ていて、長い間滞在しています。
- 次に、次のビデオ推奨システムは、短期的な関心を検出した後、より類似したビデオを推奨します
- トレーニングデータの更新頻度は秒単位です。
- 情報、ショッピング、短いビデオの推奨

オフライントレーニングに基づく推奨システム：ロジスティック回帰、勾配リフティング決定木
- 因数分解機

ここに画像の説明を挿入

データレポートとオフライントレーニング：学習システム
リアルタイム計算とA / Bテスト：予測システム
オンラインストレージモジュールもあります。
- リアルタイム計算モジュールが呼び出すためにモデルとモデルに必要な特性情報を保存します
図のモジュールは、トレーニングと予測のために2つのデータストリームを形成します。
- トレーニングデータストリームはビジネスデータを収集し、最後にモデルを生成してオンラインストレージモジュールに格納します。
- 予測されたデータストリームは、ビジネス予測要求を受け入れ、ABテストモジュールを介してリアルタイム計算モジュールにアクセスし、予測結果を取得します。
トレーニングデータストリームは大量のトレーニングデータを処理する必要があり、更新サイクルは時間単位で長くなります。
- したがって、対応するアーキテクチャはオフライントレーニングベースのアーキテクチャと呼ばれます
予測されたデータストリームはインターネットでのビジネスに使用され、遅延は数十ミリ秒以内です。
- これにより、トレーニングと予測のための2つのデータストリーム上の各モジュールに異なるアーキテクチャ要件が作成されます。

ビジネスデータを設定してトレーニングサンプルを作成する
サブコレクション、検証、クリーニング、変換
ビジネスからデータを収集する必要があります。
ビジネス主導、アイテム、ユーザー、シーンのいくつかの側面から収集
- コアデータサンプルは品質を保証する必要があります。
- すべてを定量化し、細かいほど良い
報告されたデータの正確性を検証して、論理エラー、データの不整合、データの欠落を報告しない
データの信頼性を確保するために、ダーティデータをクリーンアップする必要があります。
- 一般的なデータクリーニング：null値チェック、異常値、異常タイプ、データ重複排除
データ変換、収集したデータをトレーニングに必要なサンプル形式に変換、
- オフラインストレージモジュールに保存します。
予測結果が正確かどうかにかかわらず、データの品質は非常に重要です。
- モデルの強度に応じて、より重要なのはトレーニングデータの質と量です。

ここに画像の説明を挿入

オフライントレーニングオフライントレーニングモジュールは、ラインストレージとオフライン計算を分離します
オフラインストレージには、分散ファイルシステムまたはストレージプラットフォームが必要です
オフライン計算の一般的な操作：サンプルサンプリング、特徴エンジニアリング、モデルトレーニング、類似度計算

サンプルサンプリングは、サンプルを合理的に設計し、モデルトレーニングに高品質の入力を提供することで、より理想的なモデルをトレーニングします。
ポジティブサンプルとネガティブサンプルを合理的に定義します。実際には、しばしばポジティブサンプルとネガティブサンプルの不均衡が発生します。
- 罰の重みや組み合わせなどで解決します。
- ビジネスの理解と組み合わせて、ポジティブサンプルとネガティブサンプルを合理的に設計します。
サンプルを設計するときは、ユーザーサンプルの数のバランスを確保するようにしてください。
悪意のあるブラシトラフィックとロボットユーザーの場合、サンプルの重複排除により、ユーザーのサンプル数のバランスが確保されます。
サンプルの多様性を十分に考慮してください。現在の推奨アルゴリズムに依存しないユーザーサンプルを収集して、サンプルのソースを充実させます。

特徴エンジニアリングは、ドメイン関連の知識を使用して元のデータから可能な限り多くの情報を取得し、特徴はモデルのトレーニング効果を改善するために使用されます。
特徴選択では、評価関数、停止基準、および検証プロセスのステップを通じて、特徴セットから最も統計的に有意な特徴サブセットのセットを選択します。
特徴抽出では、コンポーネント分析、判別分析、その他の方法を使用して、元の特徴を変換および結合し、ビジネスまたは統計的有意性を持つ新しいコア特徴を構築します。
3番目に、特徴の組み合わせは、マルチモーダル埋め込みと他の方法を組み合わせて、ユーザー、アイテム、および背景からの特徴ベクトルを組み合わせて、補足情報を実現します。

最初の2つのステップの後、モデルトレーニングは、与えられたデータセットを使用して、トレーニングを通じてモデルを取得します。トレーニングは、入力変数と出力変数間のマッピングを記述するために使用されます。
実際には、大規模なトレーニングセットを処理する必要性を考慮して、一般に、トレーニング用に分散できる線形時間アルゴリズムが選択されます。

ここに画像の説明を挿入

図7.1と図7.2の推奨システムで言及されているモジュールに加えて、オンラインストレージモジュールもあります。
オンラインサービスには、待ち時間に関する厳しい要件があります。
ユーザーがアプリを開き、迅速に応答することを望んでいる
これには、推奨システムがユーザー要求を処理し、数十ミリ秒以内に推奨結果を返すことが必要です。
オンラインサービスの場合、専用のオンラインストレージモジュールが必要です。
- オンラインのモデルと機能データを保存する
オンラインストレージモジュールにはローカルメモリまたは分散メモリが必要です
オープンソースソフトウェアに基づいてオンラインストレージを可能な限り高速にするために、いくつかのカスタマイズ、キャッシュ戦略、増分戦略、遅延有効期限戦略、SSDを作成することもできます

ここに画像の説明を挿入

リアルタイム推奨モジュールは、ビジネスからの新しいリクエストを予測します
APPを開き、APPがバックグラウンドでサーバーにリクエストを送信します。
- リクエストを受け取った後、サーバーは、アプリケーション市場におけるユーザーの以前の履歴に基づいてその好みを推測します
- 次に、推奨アプリケーションリストをモバイルAPPに返し、それをAPPインターフェイスでユーザーに提示します。
リアルタイム計算モジュールには、次の計算が必要です。
- （1）ユーザーの特性を取得し、システムはリクエスト内のユーザーIDに従ってオンラインストレージモジュールからユーザーのポートレートと履歴の動作を読み取り、ユーザーのモデル特性を構築します。
- （2）推奨モデルを呼び出し、ユーザーモデルを組み合わせて推奨システムのアルゴリズムモデルを呼び出し、特定のAPP候補プール内のアイテムに対するユーザーの優先確率を取得します。
- （3）結果をソートし、候補プールのスコアリング結果をソートして、結果リストをモバイルAPPに返します。
リアルタイム計算モジュールは、オンラインストレージモジュールから大量のデータを読み取る必要があります。
- 短時間で多数のモデルのスコアリングを完了する
- モジュールには高いパフォーマンス要件があります。
このモジュールは、コンピューティングタスクを完了するための分散コンピューティングフレームワークです。

ビジネスアイテムのリストが大きすぎます。
- 複雑なモデルを使用して各項目をスコアリングするリアルタイム計算、
- 時間がかかりすぎる
推奨リストの生成をリコールとソートに分割
リコール：多数の候補（数百万）から候補セット（数百）を選択します
ランキングでは、ランキングモデルを使用して、リコールによって取得された比較的小さな候補セットにスコアを付けます
おすすめリストを並べ替えた後、
- 多様性と運用上の考慮事項については、
- また、3番目のステップ再配置フィルタリングを追加します。これは、詳細なソート後に推奨リストを処理するために使用されます
再配置フィルタリングは、ユーザーにいくつかの探索的コンテンツを提供し、
- ユーザーがプラットフォームで見るコンテンツが均質すぎるのを避け、下品な違法行為を排除する
アーキテクチャを図7.6に示します。

ここに画像の説明を挿入

ここに

7.3推奨システムの共通コンポーネント

7.3.1データレポートの共通コンポーネント

Apache Kafkaオープンソースストリーム処理プラットフォーム
リアルタイムデータソース用の高スループットで低レイテンシの処理フレームワーク。
論理的には、マルチプロデューサーキューとマルチコンシューマーキューの分散実装です。
メッセージはトピックごとに管理され、トピックには複数のプロデューサーとコンシューマーを含めることができます
プロデューサーはメッセージを生成してトピックにプッシュし、トピックをサブスクライブするコンシューマーはトピックからメッセージをプルします

ここに画像の説明を挿入

7.3.2共通コンポーネントのオフラインストレージ

HDFS（Hadoop分散ファイルシステム）は、広く使用されている分散ファイルシステムです。
低コスト、高信頼性、高スループット。
そのフォールトトレランスメカニズムにより、HDFSは安価なハードウェアに基づいて分散ファイルシステムを構築でき、コンポーネントに障害が発生した場合でも信頼できるストレージを提供できます。

HiveはHadoopをベースにしたデータウェアハウスで、より完全なSQL関数を備えています。
- 基になるストレージとしてHDFSを使用する
SQLに慣れているユーザーは、複雑なプログラミングなしでデータを操作できるので便利です。
データスケールは数百PBに達し、構造化データのストレージをサポートします。

7.3.3オフラインコンピューティングの共通コンポーネント

Apache Sparkは、インメモリデータ処理に基づく高性能分散コンピューティングフレームワークです。
シンプルで柔軟な強力なAPIにより、ユーザーは複雑なデータ分析のための効率的なプログラムを開発できます。
SparkはHadoopと同様のMapreduceコンピューティングモデルを提供しますが、Hadoopとは異なり、メモリベースの中間データ構造を使用するため、複数の反復を必要とするワークロードのサポートが向上します。

テンソルフロー
データフローグラフの数値計算のためのオープンソースソフトウェアフレームワーク。
研究者がさまざまなアプリケーションを開発するための強力で多様なAPI。

分散テンソルフローはパラメーターサーバーのサポートを提供します。
他のパラメータサーバーとは異なります
- Tensorflowのパラメータサーバーは、パラメータを暗黙的に更新します
- プログラマーはこれらのパラメーターを手動でプッシュおよびプルする必要はありません。
tensorflowに基づくパラメーターサーバーの開発を容易にする
分散テンソルフロープログラムを作成する主なタスクは、
- パラメータをさまざまなパラメータサーバーに合理的に分散する方法になります。
- クラスター構成インターフェース、指定されたデバイスインターフェース、同期モードインターフェースを介してパラメーターを構成します。