レコメンドシステムに入門する

1. はじめに

レコメンドシステムに入門するため、推薦システム実践入門や参考欄に記載の資料を読んでキャッチアップしたときのメモです。

1-1. レコメンドシステムとは

「複数の候補から価値のあるものを選び出し、意思決定を支援する仕組み」です。

レコメンドシステムは、ユーザーに最適な商品やコンテンツを提示することで、意思決定を支援します。具体的には、ユーザーの行動履歴や選好に基づいて、膨大な選択肢の中から価値あるものを抽出し、提示します。これにより、ユーザーは効率よく自分に合った商品やコンテンツに出会うことができ、ビジネス側としては顧客のエンゲージメントや売上を向上させることが可能です。

レコメンドシステムは特にECサイトや動画配信サービス、SNSなどで広く使われています。Netflixでの視聴行動を例に挙げると、視聴の80%は推薦を通じて行われており、ユーザーが自主的にコンテンツを検索するよりも圧倒的に高い割合で推薦が使われています。

1-2. レコメンドシステムの目的

レコメンドシステムは、ユーザーとサービス提供者の双方に利益をもたらします。

ユーザー側の目的としては以下が挙げられます：

• 適合アイテム発見：ユーザーが自分に合った商品やコンテンツを素早く見つけることができる。
• 適合アイテム列挙：候補として関連商品や関連コンテンツがリストアップされ、選択肢を広げる。
• アイテム系列消費：見つけた商品やコンテンツを購入、視聴、利用する。
• サービス内回遊：推薦により、サービス内での他のコンテンツや商品に興味が広がり、滞在時間が増加。

これに対し、サービス提供者側の目的は：

• 新規・低利用頻度ユーザーの定着：パーソナライズされた推奨により、初めての訪問でも価値を見つけやすくし、継続的な利用につなげる。
• サービスへの信頼性向上：推薦がユーザーに価値を提供することで、サービスに対する信頼感を高める。
• 利用頻度向上・離脱ユーザーの復帰：ユーザーの興味に沿った商品やコンテンツを推薦することで、再利用を促す。
• 同時購入：関連する商品の推薦により、ユーザーの購入を促進し、客単価を向上させる。
• 長期的なユーザーのロイヤリティ向上：長期的にユーザーの好みを理解し、より精度の高い推薦を行うことで、ユーザーのロイヤリティを高める。

指標としては、CTR（Click Through Rate）やCVR（Conversion Rate）などが主に用いられますが、多様性も重要です。類似したアイテムばかりを推薦するのではなく、異なる選択肢を提示することで、ユーザーの新たな興味を引き出すことが可能です。

1-3. レコメンドシステムの重要性

情報過多の時代において、ユーザーが自分にとって最も価値のある商品やコンテンツを見つけることはますます困難になっています。この問題を解決するために、レコメンドシステムはますます重要性を増しています。

2. レコメンドシステムの種類

2-1. コンテンツベースフィルタリング (Content-based Filtering)

コンテンツベースフィルタリングは、ユーザーが過去に好んだ商品の属性やコンテンツのメタデータを基に、類似する商品を推薦する手法です。商品の特性（ジャンル、カテゴリ、タグなど）に基づいて、新たにユーザーに合いそうな商品を抽出します。

例えば、過去にアクション映画を視聴したユーザーには、アクションジャンルに属する新しい映画を推薦するような場合です。

この手法は、ユーザーの過去の選好を直接反映するため、ユーザーにとって馴染みのあるコンテンツが推薦されやすくなります。しかし、コールドスタート問題に直面する場合があります。新しいユーザーやコンテンツのデータが不足している場合、最適な推薦が難しくなります。

実装イメージ：

商品の特徴量をベクトル化し、コサイン類似度を使って類似性の高い商品を推薦します。

from sklearn.feature_extraction.text import TfidfVectorizer

# 商品の属性データ
item_features = [
    "action movie with adventure",
    "romantic comedy",
    "science fiction thriller",
    "drama with action elements",
]

# 商品の特徴量をベクトル化
vectorizer = TfidfVectorizer()
item_vectors = vectorizer.fit_transform(item_features)

# 特定の商品の類似商品を計算（例: 0番目の商品）
item_idx = 0
similarity_matrix = cosine_similarity(item_vectors[item_idx], item_vectors)

# 類似度が高い順に商品を推薦
similar_items = np.argsort(similarity_matrix.flatten())[::-1]
print(f"Item {item_idx}に最も類似する商品: {similar_items[1]}")

2-2. 協調フィルタリング (Collaborative Filtering)

協調フィルタリングは、ユーザー同士の行動パターンを分析し、類似した嗜好を持つユーザーの行動を基に、他のユーザーに商品やコンテンツを推薦する手法です。この手法の大きな特徴は、商品のメタデータに依存せず、行動データそのものを利用する点です。

• User-based協調フィルタリング：あるユーザーが他のユーザーと類似した行動をとった場合、その類似ユーザーが好んでいる商品を推薦します。
• Item-based協調フィルタリング：特定の商品を購入したユーザーが他にどんな商品を購入しているかを分析し、それを基に他のユーザーに商品を推薦します。

協調フィルタリングは、過去のユーザー行動に基づいて高精度な推薦を行うことができますが、コールドスタート問題があります。新しいユーザーや商品に対して十分なデータがない場合、推薦が難しくなります。

実装イメージ：

User-based協調フィルタリングは、ユーザー間のコサイン類似度を計算し、最も類似度の高いユーザーの購買履歴を参照して推薦を行います。

from sklearn.metrics.pairwise import cosine_similarity
import numpy as np

# ユーザー×アイテム行列（ユーザーの行動データ）
user_item_matrix = np.array([
    [5, 3, 0, 1],
    [4, 0, 0, 1],
    [1, 1, 0, 5],
    [0, 0, 5, 4],
    [0, 0, 5, 0],
])

# ユーザー間のコサイン類似度を計算
user_similarity = cosine_similarity(user_item_matrix)

# 最も類似したユーザーに基づいて推薦を行う
user_idx = 0  # 推薦を行いたいユーザーのインデックス
similar_users = np.argsort(user_similarity[user_idx])[::-1]  # 類似度が高いユーザー順に並び替え
print(f"User {user_idx}に対して、最も類似したユーザー: {similar_users[1]}")

（補足）Item to ItemとUser to Item 

• Item to Item は主に 協調フィルタリング (Item-based) で使用され、商品詳細ページなどで他の商品との関連を提示するのに適しています。関連商品。カート購入画面、ユーザの購入履歴からi2i、アンケートから購入アイテムのi2i
• User to Item は 協調フィルタリング (User-based) や コンテンツベースフィルタリングで使用され、トップページなどでユーザーごとの嗜好に基づいて推薦するのに向いています。あなたへのおすすめ。メールマガジン、商品属性、検索結果の並び替え、棚の並び替え（あなたへのおすすめ、セール、新着）

3. レコメンドシステム導入フロー

レコメンドシステムを導入する際の具体的なフロー例を記載します。

3-1. 要求・要件整理

まず、ビジネス的な目的とユーザー体験の目標を明確にします。

• ビジネスの目標: レコメンドシステムがもたらす価値を具体的に定義します。売上増加だけでなく、エンゲージメントの向上やユーザーロイヤリティの強化も期待されます。特にECサイトでは、新規顧客の定着や、既存顧客の再訪を促すことが重要です。
  • セレンディピティ、多様性
  • 同じカテゴリが固まらないように。毎回同じレコメンドを出さないように。自明なレコメンドは除きたい。
  • どんな体験を与えたいのか？から逆算する
• システム導入の効果測定: レコメンドシステムの効果を定量的に評価するために、導入前に明確なKPIを設定します。例えば、**CTR（クリック率）やCVR（コンバージョン率）**がよく使われます。これに加えて、ユーザーの多様性をどれだけ確保できたかも指標として重要です。
  • ユーザ体験の向上＋ARPU（平均売り上げ目標）
  • MAU
• その他
  • レコメンド掲載場所：トップページ、詳細ページ、マイページ、メール、etc
  • 表示件数、画像サイズ
  • データの鮮度：データの鮮度も非常に重要です。ユーザーの行動やトレンドが急速に変わる場合、リアルタイムデータを収集して即座にレコメンドに反映させる必要があります。ユーザの回遊率に大きな影響がある場合もあります。一方、過去の購入履歴や定期的なトレンドに基づくデータは、バッチ処理で蓄積され、長期的なパターン分析に活用されます。
  • 特定条件への対応: 新商品や売り切れ商品の扱いについても事前に決定する必要があります。これらの商品は、ユーザーにとって最も価値が高いものをレコメンドするための要素として重要です。

3-2. データの収集と前処理

データ種別

主に以下の2つのタイプのデータを収集します。

#### 1. カタログデータ

• 商品ID、商品名、カテゴリ、価格、販売終了日、説明文、画像URLなど、商品の属性を表すデータ。

#### 2. ユーザーイベントデータ

• 過去の購入履歴、閲覧履歴、評価、クリックデータなど、ユーザーごとの行動ログ。**Google Analytics 4（GA4）やGoogle Tag Manager（GTM）**を活用することで、イベント単位での詳細なデータが取得可能です。
• カラムイメージ
  • ユーザーID
  • イベント名（ページビュー、購入など）
  • イベント発生時刻
  • コンテンツID
  • コンテンツカテゴリ

データクレンジングと前処理

前処理として、不完全なデータや重複データ、異常値を除去したり、データを標準化するなどをします。たとえば、価格情報が欠落している商品や、異常なアクセス数を記録しているログデータなどをフィルタリングします。また、カテゴリや商品属性の正規化も行います。これにより、アルゴリズムが誤解することなく正確な推薦を行えるようにします。

• ex. カタログデータの前処理
  • 商品コードごとにユニークなコードを割り当てる
  • カテゴリーのフィルタリングをする
• ex. ユーザイベントデータの前処理
  • ga4ログとユーザ情報テーブルからユーザのアクティビティログを標準化する
  • 1ヶ月の閲覧ログ、1回以上閲覧があったアイテムに絞る
  • 期間で正規化する
  • →期間ごとのアイテムおよびユーザの閲覧数を計算し、View Targetの正解を設定する

3-3. レコメンドモデルの構築

モデルのIN/OUT

#### 学習のインプットデータ

目的変数としては、例えば「購入の有無（バイナリ変数）」や「ユーザーの評価スコア（連続変数）」を設定します。どのアルゴリズムを使用するかにより、目的変数の種類も異なります。

#### 予測のアウトプット

モデルの予測結果としては、次のような形式が考えられます。

• ランキングリスト: ユーザーに対してトップNのアイテムを推奨。推奨順にアイテムが並べられ、ユーザーが選択可能。
• スコア付き推奨: 各アイテムに対して、予測スコアを提示し、どのアイテムが最も推奨されるかが分かるようにします。

代表的なアルゴリズムと用途

#### 1. コンテンツベースフィルタリング（Content-Based Filtering）

コンテンツベースフィルタリングは、ユーザーが過去に評価したアイテムの属性（特徴）を分析し、類似するアイテムを推奨します。

• TF-IDF（Term Frequency-Inverse Document Frequency）
  • テキストデータの頻度をもとに、商品の特徴を抽出し類似アイテムを推奨。
  • 例: 過去に見た映画のジャンルやキーワードに基づいて新しい映画を推奨。
  • 適用例: 商品説明やレビューに基づいた商品推薦。
  • 課題: アイテムのコンテンツが充実していないと精度が低下。
• Word2Vec / Doc2Vec
  • 商品のテキストをベクトル化し、ユーザーが好むアイテムと似た特徴を持つアイテムを推薦します。
  • 例: ある本のレビューから、関連する本を推薦。
  • 適用例: 本や映画などテキストが充実したアイテム群において有効。
• その他の自然言語処理
  • トピックモデリングや単語の埋め込みを用いて、商品のテーマやカテゴリを学習し、ユーザーに最適な商品を推薦します。
  • 例: 商品の説明文を分析し、自動的にタグを付け、そのタグを基にアイテムを推薦。
  • 適用例: 商品の説明が膨大で、分類やタグ付けが必要な場合。

#### 2. 協調フィルタリング（Collaborative Filtering）

協調フィルタリングは、ユーザーやアイテムの相関に基づき、類似する傾向を持つユーザーやアイテムから推奨を行う手法です。ユーザーベースとアイテムベースに大別されます。

• ユーザーベース協調フィルタリング
  • ユーザー同士の行動や評価を比較し、似た行動を取る他のユーザーが評価したアイテムを推奨します。
  • 例: 似た映画を好む他のユーザーが見ている映画を推奨。
  • 適用例: 同じ趣味を持つユーザーに対して商品やコンテンツを推奨するシナリオ。
  • 課題: コールドスタート問題（新規ユーザーの推薦が難しい）。
• アイテムベース協調フィルタリング
  • アイテム同士の類似性に基づき、ユーザーが以前に見たアイテムに似たものを推薦します。
  • 例: 過去に視聴した映画に類似する映画を推奨。
  • 適用例: 商品やコンテンツが多い場合、過去のアイテムとの関連性を基に推薦。
  • 課題: 人気アイテムに偏る可能性。
• 行列分解（Matrix Factorization）
  • 協調フィルタリングのモデルベース型。ユーザーとアイテムの潜在因子を学習し、スパースデータ（欠損の多いデータ）に強い。特に大量データで有効です。
  • 例: Netflixの映画レコメンドシステムでのSVD（特異値分解）。
  • 適用例: 大規模データで高次元な特徴を学習する場合。

#### 3. その他のアプローチ

これらのアルゴリズムは、協調フィルタリングやコンテンツベースフィルタリングとは異なる手法を用い、特定のビジネスロジックや複合的なアプローチに基づいています。

• ルールベースの推薦（Rule-Based Recommendation）
  • 事前に設定されたビジネスルールや統計情報に基づきアイテムを推薦します。たとえば、過去1ヶ月の売上数や特定のイベント時に推奨アイテムを変更するなど、明確な条件に基づいて推薦します。
  • 例: 毎月のトップセラー商品を推薦。
  • 適用例: 新規アイテムや期間限定キャンペーンなど、特定の条件でアイテムを推薦したい場合。
  • ルールベースも適切に使いこなす。人気な質問は表示するとか。コールドスタート問題やサービス理解に有効な場合もある。
• アソシエーションルール（Association Rule）
  • 同時購入パターンに基づき、関連するアイテムを推薦。例えば、「おむつとビール」といった同時に購入されるアイテムのパターンを発見し、その関係性を基にアイテムを推薦します。
  • 例: 本商品を購入したユーザーが他に買った商品を推薦。
  • 適用例: ECサイトでのバンドル販売や関連商品の推薦。
• 回帰モデル
  • レコメンドを回帰問題として扱い、ユーザーごとのアイテム評価スコアや購入確率を予測します。例えば、価格やユーザー属性をもとに、次に購入される可能性の高いアイテムを予測します。
  • 例: 商品の評価スコアや購入確率を予測し、トップの商品を推薦。
  • 適用例: 定量的なスコアをもとに、アイテムをランキングする場合。
• ディープラーニングを活用したモデル
  • 自動エンコーダー（Autoencoders）やリカレントニューラルネットワーク（RNN）など、深層学習を用いた手法。ユーザーやアイテムの高度な特徴抽出や時間依存性を考慮した予測が可能です。
  • 例: ユーザーの過去の行動履歴を時系列データとして扱い、将来の購入を予測。
  • 適用例: 大規模なデータセットや高度なパターン認識が必要なシステム。

その他

• ＞距離学習や近似近傍探索といった最新のテクニックを使ったうえで、各サービスに応じて購入済みの商品スコアを下げる、同じシリーズを出しすぎないといったヒューリスティックなロジック
• ＞ほかの出版社の同ジャンル作品や異なるジャンルだけど興味関心の高そうな作品など多様な興味を反映したアルゴリズムを作成
• データの偏り。ネガティブサンプリングとして負例の教師データを別途集めるなど
• LLMを活用
  • 情報抽出・構造化としてのLLM活用
  • Embedding取得としてのLLM活用
  • RAGによるレコメンド
  • おすすめアイテムの推論としてのLLM活用
    • [ユーザーの過去の行動履歴: トイ・ストーリー, マトリックス, ……] [候補アイテム候補群: スターウォーズ, スパイダーマン, ……] 私の行動履歴に基づいて、次に見たいと思う可能性が高い順にこれらのアイテムをランク付けしてください。
    • レコメンド対象のアイテムに対する質問と当該のアイテムが選択された確率をLLMにわたす。生成された質問とペルソナの説明をLLMに渡し、その関連性を1~10で評価してもらう。

####（補足）多段階推薦（Two-Stage Recommendation）

多段階推薦は、まず大規模な候補アイテムから少数のアイテムを絞り込み、その後、リランキングやスコアリングを行う手法です。

1. candidate generation
   • すべてのアイテムからユーザーに適した候補を数百件程度選び出します。主に協調フィルタリングやアソシエーションルールを使って広範囲に候補を絞り込みます。
   • ex. 協調フィルタリングによる候補生成
     • ga4ログとマスタデータを取得する
       • 日付が有効なものを取得する
     • ユーザごとに、過去1ヶ月の間に閲覧した商品のログのペアを生成する
     • アイテムごとの共起頻度をまとめて計算し、ランキングを作成する
       • 不足しているカテゴリはランキング上位のアイテムを補完する
     • →結果、アウトプットとしては【ユーザごとの、推薦アイテムと共起頻度とカテゴリ分類】
2. ranking
   • 推奨リストの最終的な並び順をユーザーの最新の行動データや多様性を考慮して調整します。
   • 例: 特定の商品が売れすぎないように、人気度に応じた平等なリスト作成。

代表的な評価指標

• RMSE: 連続評価を扱う場合に有効。予測スコアと実際の評価値の誤差を測定。
• nDCG: 推奨リストのランキング精度を評価する指標。正解のアイテムが上位にいるほどスコアが高くなります。
• MAP: 推奨リストにおけるアイテムの正解率を評価。平均精度を測定。
• Precision@k、Recall@k: 上位k個のアイテムの正解率や再現率を測定。

3-4. レコメンドシステムの構築

レコメンドシステムを構築する際、システムアーキテクチャやデータフローの設計が非常に重要です。システムは、リアルタイム推薦やバッチ推薦といった異なる要件に応じて設計され、これらのシステムは特定のビジネスニーズやユーザーフローに合わせて最適化されます。ここでは、具体的なシステム構成例や推薦手法について詳しく解説します。

アーキテクチャ例

• Commune

  • Cloud Scheduler+Cloud FunctionでVertex AI Pipelineを起動してFirestoreにレコメンド結果を格納。それをCloud Run上で動くFastAPIから取得する
    

• Commune

  • Recommendation DBにない場合は、Queuing Serviceにキューが入って、ML-API-Handler for near real-time がDBからデータを取ってInference Serverに投げる
    

• コネヒト

  • 事前にStep Functionsから起動してDynamoDBに格納。APIは直近興味を持ったアイテムIDのリストをもらってDynamoDBをつつく。
    

• DeNA

  • ユーザの行動はPub/Subにリアルタイム連携、DataflowでBigTableに格納
    

レコメンドの提供方法

• DMMのあちこちをパーソナライズする推薦システムから引用
  

バッチ推薦の例：ニュース記事のプッシュ推薦

バッチ推薦は、定期的にデータを更新し、一定のタイミングでユーザーに対して推薦を行う手法です。ここでは、ニュース記事のプッシュ通知を例にとって解説します。

1. モデリング
   • モデルはユーザーの過去の閲覧履歴や記事の特徴量を学習し、ユーザーがどの記事を開封するかを予測します。モデルの学習は一日に一度などの周期で行われます。
   • 例: ニューラルネットワークやロジスティック回帰を用いたCTR（クリック率）予測モデル。
2. 候補記事の選択
   • 過去のデータを用いて、ニュース記事のクリック率が高い順に上位K件の候補記事を選びます。
   • 例: 30分ごとにユーザーに最適化された候補記事を選出。
3. スコアリング
   • 学習済みモデル(1)にユーザーの特徴量と記事の特徴量を入力し、各ユーザーに対して各候補記事のスコアを計算してデータベースに保存します。
   • 例: ユーザーがどの記事をクリックする可能性が高いかをスコアリングし、その結果に基づいて推奨します。
4. プッシュ送信
   • ユーザーの指定した時間に、データベースから各ユーザーに対して最適な候補記事をプッシュ通知します。

リアルタイム推薦の例

リアルタイム推薦は、ユーザーの行動に即座に反応して新たなデータを取り込み、即時に最適な推薦を行う手法です。

• ユーザー特徴量の更新
  • ユーザーが記事をクリックしたタイミングで、その行動データをもとにユーザーの特徴量をリアルタイムで更新します。ユーザーの過去のクリックデータや現在のクリックした記事の特徴量を使って新しい特徴を生成し、モデルに反映させます。
  • 例: 新たにクリックした記事が「スポーツ」カテゴリであれば、ユーザーの興味の重心が「スポーツ」にシフトすることを示す特徴量の更新。

その他の考慮点

• 障害が発生した場合：リアルタイムシステムがダウンした際、ルールベースのシステムでバックアップすることも考慮すべきです。たとえば、最新の売れ筋商品やランキング上位の商品を推薦する。
• 売れ筋でない商品のレコメンド：人気商品の推薦に偏らないように、少数のマイナー商品もリストに含め、多様な商品を提案することがユーザー体験の向上につながります。
• 人気度ごとの平等な推薦：特定の人気商品だけでなく、人気度に応じてアイテムの推薦リストを平等に作成することで、アイテム間のバランスを取ります。
• データのバージョン管理。当時の状態を一度復元する必要があることがある

3-5. 評価と改善

レコメンドシステムを実際に運用する際には、継続的な評価と改善が不可欠です。

オフライン評価

オフライン評価では、シミュレーションや過去のデータを用いて、モデルの性能を事前に評価します。
＞「人間が提案した求人と同じような求人を提案できたか？」という観点で、「人間の提案を超えるようなレベルのものかどうか」はオフラインテストでは確認できませんが、最低限の品質を担保することはできます。

• シミュレーション
  • 過去のデータに対してモデルを適用し、推薦結果の精度を評価します。具体的には、ユーザーが以前にクリックしたアイテムや購入したアイテムを正しく予測できるかをテストします。
  • 評価指標: Precision@k、Recall@k、NDCGなどが使用されます。
  • ex. ランダムに100人を選ぶ→開発中のモデルと、人気ランキング（直近1ヶ月）とをnDCGやMAPで評価する。評価期間は3日間で、推薦したアイテムを閲覧したかどうかで評価する。
  • その他ポイント
    • 評価するべきことを正しく評価できるメトリクスになっているか？よく使われるキーワードとあまり使われないキーワードを同じ重みで評価するのは適切か？
    • オフラインメトリクスとオンラインメトリクスの相関。Booking.comの事例など

オンライン評価

オンライン評価では、実際のユーザーに対して推薦を行い、その結果をリアルタイムで計測します。

• A/Bテスト
  • 推薦システムの異なるバージョンを比較する最も一般的な方法です。たとえば、AIベースの推薦とルールベースの推薦を比較し、どちらが高いCTRやCVRを達成できるかを検証します。
  • 評価指標: CTR（Click Through Rate）、CVR（Conversion Rate）、STEDI（Satisfaction Through Empirical Data Insights）など。
  • 具体例: 推薦タイプ（ルールベースかAIか）、ユーザ数、推薦数、インプレッション数、推奨記事閲覧数などを記録し、結果を分析。そのために、推論結果にどのモデル・バージョンで推論したかを格納しておく。
• インタービーリング
  • 推薦結果を混ぜて表示し、どちらがユーザーにより好まれるかを測定します。少ないユーザで評価が可能ですが、実装コストはやや高いです。

ユーザースタディ

ユーザーの意見を直接収集し、システムの改善に役立てます。

• インタビュー
  • ユーザーに直接インタビューを行い、推奨結果の品質や満足度をヒアリングします。評価の目的ごとに適切なサンプリング手法を採用する必要があります。層下抽出法など。
• アンケート
  • ユーザー中心の評価フレームワークResQueなどを使用し、アンケート調査で定量的なフィードバックを得ます。

改善

評価結果を基に、コールドスタート問題やバイアスを軽減し、システム全体のパフォーマ

ンスを向上させます。

• コールドスタート問題
  • 新規ユーザーや新規アイテムに対しては、事前の情報がないため、初期設定時に「好きな商品を選ぶ」などのアンケートを活用して対応します。
  • モデルベースの協調フィルタリング
• バイアスの除去：
  • セレクションバイアス：特定のアイテムに偏った推薦を防ぐため、ランダム要素を導入する。
  • 表示バイアス：ユーザーが上位に表示された商品を選びやすい問題に対処するため、リランキングの際に位置を調整する。
• リランキングとフィルタリング
  • 推奨結果のリランキングや特定の条件に基づくフィルタリングで、より多様な推薦を提供します。

（補足）レコメンドと検索

• 検索にはクエリがある、レコメンドはクエリがない
• 検索＝マッチング＋ランキング
• マッチング
  • 全文検索（文字列検索など）、セマンティック検索（意味や文脈を考慮したアプローチ）
• ランキング
  • ランキングをレコメンドでパーソナライズすることがある

参考

• kaggle masterが語るDMMレコメンドチームの魅力
  • DMM
  • レコメンド精度改善のポイント
• DMMのあちこちをパーソナライズする推薦システム
  • DMM
  • レコメンドの種類と役割
• atmaCup#15と実世界のレコメンドの比較(の一例)
  • DMM
  • コンペと実務の違い、業務ならではの最適化指標
• 事業会社でレコメンドエンジンを作る際のいくつかの壁
  • Leverages
  • 実務上での具体的な改善取り組み
• 生成AI時代のレコメンド
  • レコメンドにおける大規模言語モデルの活用
• 「生成AI時代に必要な検索とレコメンドをざっくり抑える」というタイトルでDevelopersIO 2024に登壇しました
  • 検索とレコメンドの概要。生成AIならではの話は特にない。
• レコメンドアルゴリズム入門：基礎から応用まで実装に必要な知識を解説
  • レコメンドアルゴリズムを解説。詳しめ
• ウォンテッドリーにおける推薦システムのオフライン評価の仕組み
  • ウォンテッドリー
  • オフライン評価のポイント
• LLMで学習不要のレコメンドエンジンを実現
  • ナレッジセンス
  • LLMを使用したレコメンドエンジン作成のフレームワーク
• コミュニティプラットフォームのバッチレコメンドを支える機械学習基盤
  • Commune
  • バッチレコメンドを支える機械学習基盤
• ニアリアルタイムで投稿レコメンドをユーザーに届ける
  • Commune
  • Message Queuing Service (MQS) を利用した非同期処理による方法
• コミュニティサービスに「あなたへ」フィードを リリースするまでの試行錯誤
  • コネヒト
  • レコメンドPJを推進するために取り組んだこと
• モバオクでのリアルタイムレコメンドシステムの紹介
  • DeNA モバオク
  • リアルタイムレコメンドシステムのアーキテクチャ