レコメンデーションシステム学習サマリー

全体的なアーキテクチャ

• ユーザーの履歴/データ（いいね、読み取り、転送、コメント、お気に入り）がデータベース（オフラインレイヤー）に転送され、その間にKafkaをメッセージ転送として使用できます（kafkaはメッセージキューであり、データを分割できます）。バッチに分割され、MongoDBデータベースに保存されます。もちろん、データ量が少ない場合はKafkaを使用できません）。
• データプラットフォームは、MongoDBからデータを読み取り、データプラットフォームに保存します。データプラットフォームには、コンテンツポートレート、ユーザーポートレート、ユーザー情報、その他のデータも保存されます。現時点では、データプラットフォームには収集可能なすべてのデータがあります。
• これらのデータを今すぐ使用してください。まず、これらのデータをモデルトレーニングに使用し（通常、協調フィルタリング、NMF、FM、YouTuBeのDNNを含む）、モデルファイルモデルファイルを生成する必要があります。モデルファイルの使い方は？これにはオフライン計算が含まれ、オフライン計算ではユーザーのポートレートとユーザー情報も使用されます（たとえば、モデルの複雑さに応じて、協調フィルタリングにはユーザーIDのみが必要ですが、YoutuBeのDNNはすべて使用する必要があります）。
• その後、並べ替えて、並べ替えた結果をredis（高効率）に保存し、ユーザーにプッシュすることができます（より単純で、並べ替えなし）。[これが最も簡単な推奨システムです]

以上就是离线层的操作、オフラインレイヤーは通常、最も単純なレコメンデーションシステムでもあるリコールを実行します
离线层的特点和功能：。1 。リコールコレクションを生成するためのリコールデータとして使用されます。2。リアルタイムである必要はなく、数時間または数日ごとに実行できます。 （データ量は比較的少なく、数時間に1項目、1日に数項目、リアルタイムで呼び出す必要はありません。そうしないと、計算能力が向上し、効果は大きくありません）

コレクションデータフォームを思い出してください：

{
    
    
	{
    
    user_id:"1"}:[{
    
    'a':0.001},{
    
    'b':0.005},{
    
    'c':0.00001}]
}

但是仅使用离线计算会导致模型排序的同质化严重：たとえば、国内ニュースが多い場合、並べ替えの結果はすべて国内ニュースになるか、上位10は国内ニュース、最後の3つは映画、最後の2つはバラエティ番組です。さまざまな種類のニュースはユーザーエクスペリエンスが悪い。したがって、オンラインサービスを追加すると、3種類のニュースが別々にプッシュされます。オンラインサービスステージでは、ユーザーのリアルタイムデータ、ユーザーのポートレート、コンテンツのポートレートなどを統合して、リアルタイムで計算することもできます。、ただし、通常は必要ありません。

ただし、現時点では、リアルタイムのデータユーザーは使用せず、シーケンスレイヤーによって生成されたデータを使用するだけであるため、問題が発生します如果用户的行为或兴趣点突然发生了变化，这样是捕捉不到的。したがって、ユーザーの行動を収集するために、オンラインサービスとオフライン計算の間に近似オンラインレイヤー（GBDT + LRモデルを使用できます）が追加されます。おおよそのオンラインレイヤーは、通常3〜5分以内に計算できます。おおよそのオンラインレイヤーとオフラインまたはオンラインレイヤーの最大の違いは、ユーザーのフィードバックをリアルタイムで収集できることです。

プッシュの内容はどんどん狭くなっています。興味のある人はプッシュされ、興味のない人はプッシュされません。解決策：熱と時間の混合想起に基づいて、ユーザー履歴の一部とコンテンツの類似性の一部を実行します

---

データセンターは、データベース、データファイル、分散ファイルシステムとして理解できます。
おおよそのオンラインレイヤーも並べ替える必要があります。また、コンテンツの特性を取得するには、並べ替えモデルを事前にオフラインでトレーニングする必要があります。
オフラインレイヤーはリコールを行い、おおよそのオンラインレイヤーとオンラインレイヤーは並べ替えを行います。
ビジネスロジックの処理は通常、オンラインサービスで行われます。

---

スケジューラは、時間指定されたタスク
ラベルとポートレート関連を保存するために使用されます

クローラーの基本とスクレイピー

クローラーとは

増分更新
タイミングタスク：Pythonタイマーは常にスレッドを占有し、Linuxサーバー自体にはタイマーがあります

クローラーの原理

Webページのクロール、データの保存、前処理、および関連サービスの提供
Cookie：ログイン情報の保存に使用されます。サーバーではなく、ローカルに保存します。セッションはサーバーに保存されます。

スクレイプフレームワークとは

かすれたプロジェクトを作成する

(recommendation) D:\Code\PycharmProjects\scrapy_project>scrapy startproject sina
(recommendation) D:\Code\PycharmProjects\scrapy_project>cd sina
(recommendation) D:\Code\PycharmProjects\scrapy_project\sina>scrapy genspider sina2 sina.com.cn
Created spider 'sina2' using template 'basic' in module:
  sina.spiders.sina2

BeautifulSoupフレームワーク

実際の戦闘：クローラーを使用してWebサイトのコンテンツをクロールする

Crontab

*	每隔多少分钟
*	小时
*	一个月中的第几天
*	每个月运行一次
*	一周的某一天

原定时任务：
0 1 * * * cd /home/docker-volume/scrapy_project/sina;scrapy crawl sina2 -a page=5 -a flag=1 >> /home/data/sheduler.log

新定时任务（使用shell脚本）/home/data/cron.sh：
#! /bin/sh
export PATH=$PATH:/usr/local/bin

echo$PATH
cd /home/docker-volume/scrapy_project/sina
/usr/local/bin/scrapy crawl sina2 -a page=5 -a flag=1 >> /home/data/sheduler.log 2>&1 &

#/usr/local/bin/scrapy命令的绝对路径应该是必要的

内容画像

プロファイリングシステムの運用プロセス

コンテンツポートレート構築

コンテンツポートレートとは

コンテンツを説明するために使用できる特性のコレクション

• キーワード
• テーマ
• エンティティワード
• 分類
• 映画の長さ
• 記事の著者

内容物熱処理

手動で熱を処理します。だんだんと人がホットスポットに気を配らなくなったら、手動で発熱量を下げてください。

これは一種のルールベースのリコール（熱ベース、時間ベースのリコール）です。従う牛顿冷却定律：周囲の環境よりも高い温度の物体が周囲の媒体に熱を伝達し、徐々に冷却する場合、法則に従います。

コンテンツの人気を更新する方法

システムで推奨される熱：
熱減衰
1、ニュートンの冷却の法則
2、カスタム熱減衰式

• 熱を上げる必要がある場合：
  • 1.ユーザーが記事（いいね、コメント、お気に入り）
    を操作します
    a。ユーザーリクエストがある場合は、データベースを直接操作して人気を変更しますb。ユーザーリクエストがある場合は、MongoDBでいいねの数を記録し、お気に入り、次に合格熱を変更する回数が計算されます
    。熱を更新する方法はいくつかあります
    。a。MongoDBに直接アクセスしてデータを操作します（効率が低く、頻繁なデータ操作には適さず、QPSに影響します）。
    b。kafkaを介したデータの操作（kafkaは中間ですパイプラインを使用してデータを取得し、バッチ処理のために対応するプログラムに転送しますが、MongoDBのデータはリアルタイムで変更できません。これは基本的にリアルタイムです。 （1分、30秒、5分））
    c。最初のデータをredisで操作してから、MongoDBデータベースを定期的に更新します。
  • 2.運転指定（1.発熱量を一時的に最高状態に調整します。2。運転指定プールを設定します）
  • 3.数式の計算

redisがハングした場合の対処方法：1。クラスタリングとシャードストレージを実行します2.ランディングにpikaを使用し
ます指定されたプールを操作することに加えて、2つのプールを追加することもできます：
1。ホットプール（hot_pool）
2。最新のプール（last_pool）
rec_pool = rec_list -rec_list_for_bussiness-hot_pool-last_pool

rec_list = rec_list_for_bussiness [：2] + hot_pool [：3] + last_pool [：2] + Recommendation_system [8]

コンテンツプロファイリングの基本的な技術的ポイント

1. キーワード抽出：アイテムのポートレートのラベルの最も基本的なソースであり、TF-IDF、TextRankなどの他のテキスト分析のデータベースも提供します。
2. エンティティ認識：人、場所、場所、作品、映画、テレビドラマ、歴史的イベント、ホットイベントなど、CRFモデルと組み合わせた最長の辞書ベースの方法;アナログ単語セグメンテーションと品詞タグ付け、エンティティ認識はよく分割された各単語の認識にこれは、定義された名前付きエンティティクラスコレクションの1つです。
3. コンテンツ分類：分類システムに従ってテキストを分類し、分類を使用して粗粒度の構造化情報を表現します。SVM、FastText。
4. テキストのクラスタリング：誰も分類システムを開発していないという前提の下で、監督なしでテキストを複数のクラスターに分割することも非常に一般的です。ラベルとして見ないでください。クラスター番号は、ユーザーのポートレートの一般的なコンポーネントでもあります。 ;
5. トピックモデル：多数の既存のテキストからトピックベクトルを学習し、各トピックの新しいテキストの確率分布を予測することも非常に実用的です。実際、これも一種のクラスタリングのアイデアです。トピックベクトルはラベルフォームだけでなく、ユーザーポートレートの一般的な構成;記事のトピックを提供するLDAトピックモデル。
6. 単語の埋め込み：単語の埋め込み、単語からテキストまで、この埋め込み表現を学ぶことができます。埋め込まれた表現は、文字通りの意味の下で意味情報を掘り起こし、限られた次元でそれを表現することです。密な単語ベクトルを取得します。

コンテンツポートレート詳細構造

キーワード抽出：TF-IDF

単語の頻度、単語の停止、逆文書の頻度

期間頻度（期間頻度、TF）：

$${TF}_{m、0}=\frac{COUNT（\omega ）}{|D_1|}$$
つまり、用語
$$単語の頻度（TF）=\frac{1語でのテキストの章では、現在の倍の数}{温家宝章における用語の合計数}$$

言葉を止めに行く：

「的」、「はい」、「
在」など。一般的なセグメンテーションはjieba関数（jiebaセグメンテーションライブラリ）を使用し、通常、検索エンジン、および完全なセグメンテーションモードの3つのモードがあります。検索エンジンと完全なセグメンテーションの間にほとんど違いはありません。

逆ドキュメント頻度（逆ドキュメント頻度、IDF）：

一部の単語はこの記事のキーワードですが、他の記事でも頻繁に使用される単語であるため、記事全体の特徴を表すものではありません。
このとき、キーワードであり、記事の特徴を表すことができる単語を見つける必要があります。（1つの記事の単語の重要性を考慮
）単語wに現れるドキュメントの総数nとドキュメントの数の比率の対数docs（w、D）は次のように表すことができ
$${IDF}_{ああ}={log}_2（（\frac{n個}{docs（\omega 、D）}）$$
文字通りの式は次のとおりです。
$$逆テキストファイルの頻度率（IDF。）=log（（\frac{言語材料ライブラリのテキストファイルの合計の数}{パケット含む言葉のテキストファイルの数+1を}）$$
つまり、単語がより一般的である場合、その逆文書の頻度は小さくなります（つまり、重要度が低くなります）。つまり、逆文書の頻度が高いほど、キーワードが他の単語に表示される可能性が低くなります。ドキュメント、つまりこの記事のキーワード。

次に、ドキュメントのTF-IDF値就与一个词在文档中出现的次数成正比，与改词在其他文档中出现的次数成反比：
$$TF-IDF=単語の頻度（TF）\ast 逆テキストファイルの頻度率（IDF。）$$
因此，TF-IDF算法即对关键词的TF-IDF值降序排序，最后取前N个关键词作为最终的结果。

TextRank

ビルドプロセス

TF-IDFを使用して、Mysqlのニュースデータからキーワードを抽出し、それらの特性をMongodbに保存してから、mongodbのコンテンツをRedisに転送し、コールドスタートの時間で並べ替えます。

シンプルなエンジニアリング

フラスコを使用する