2.3 推薦システムにおける LLM パラダイムの詳解

位置づけ

2.3 の主題は、LLM を推薦システムにどう組み込むかである。教科書では、大きく 2 つのパラダイムに分けている。

LLM 強化型推薦システム
LLM を推薦システムとして利用する方式

この 2 つは似ているようで、設計思想が大きく違う。

LLM 強化型推薦システムでは、LLM は既存の推薦パイプラインを補強する部品である。候補検索、ランキング、再ランキング、評価といった従来の構成は残し、LLM は embedding、タグ、要約、意味特徴量、推薦理由、評価補助などを提供する。

一方、LLM を推薦システムとして利用する方式では、LLM 自体が推薦エンジンに近い役割を持つ。ユーザー履歴や自然言語要求をプロンプトとして入力し、LLM が直接「この作品をおすすめする」「この順番で見るとよい」といった出力を生成する。

Hulu のような動画配信サービスでは、基本的には LLM 強化型から始めるのが現実的である。理由は、既に item_information_table、unique_viewed_series、候補検索、ランキング、配信制約、A/B テストといった推薦基盤が存在する前提だからである。LLM をいきなり全推薦エンジンにするより、まず既存パイプラインの弱い部分を補強する方が、コスト、レイテンシ、安全性、評価の面で扱いやすい。

ただし、会話型推薦や高度な自然言語検索では、LLM を推薦システムとして使う価値が大きい。例えば「今日は疲れているので、30 分くらいで軽く笑える作品を探して」「子どもと一緒に見られる、怖すぎない冒険映画が見たい」のような要求は、従来のジャンル検索だけでは扱いにくい。

2 つのパラダイムの違い

2 つの違いを一言で言うと、LLM が「部品」なのか「中心」なのかである。

観点	LLM 強化型推薦システム	LLM を推薦システムとして利用
LLM の役割	特徴量生成、embedding、タグ付け、説明生成、再ランキング補助	ユーザー要求から直接推薦リストや回答を生成
既存推薦基盤	基本的に維持する	一部または全部を LLM 中心に置き換える
主な入力	作品説明、視聴履歴、メタデータ、候補リスト	ユーザー履歴、自然言語要求、制約、会話履歴
主な出力	embedding、特徴量、タグ、スコア補助、説明文	推薦リスト、推薦理由、会話応答、プラン
コスト	比較的抑えやすい	高くなりやすい
レイテンシ	オフライン処理やキャッシュで抑えやすい	オンライン推論が重くなりやすい
評価	既存の NDCG、Recall、A/B テストに乗せやすい	会話品質や回答品質も評価が必要
向いている用途	大規模ホーム推薦、候補検索、ランキング特徴量	対話型推薦、自然言語検索、少数候補の相談

Hulu のホーム画面の「あなたへのおすすめ」を考えるなら、LLM 強化型が向いている。全ユーザーに対して高速に推薦を返す必要があり、配信期間、ブラックリスト、SVOD/TVOD、キッズ適合性などの制約も厳密に守る必要があるからである。

一方、「見たい作品を会話で探す」機能を考えるなら、LLM を推薦システムとして使う方式が向いている。ユーザーの自然言語要求を理解し、追加質問をし、条件を緩めたり絞ったりする対話が必要になるからである。

LLM 強化型推薦システム

LLM 強化型推薦システムでは、LLM は推薦パイプラインの一部として使われる。推薦エンジン全体を LLM に置き換えるのではなく、従来型の候補検索やランキングモデルを強くするために使う。

Hulu の既存データで考えると、LLM 強化型が使える箇所は多い。

description、sentence、sockets_tag から作品の意味 embedding を作る
casts、film_directors、genre、sub_genre を自然文と統合して作品表現を作る
avg_mood_tag や avg_fingerprint とテキスト embedding を組み合わせる
unique_viewed_series からユーザー嗜好プロファイルを作る
候補検索で意味的に近い作品を追加する
ランキング特徴量としてユーザーと作品の意味類似度を使う
推薦理由を生成する
LLM を評価補助者として使い、リストの不自然さを検出する

この方式では、オンラインで毎回 LLM に全候補を渡す必要はない。作品 embedding やタグはオフラインで生成できる。ユーザー embedding も、一定頻度でバッチ更新したり、最近視聴だけを軽量に反映したりできる。

LLM 強化型の基本構成

LLM 強化型の典型的な構成は、次のようになる。

作品メタデータを収集する
LLM または embedding モデルで作品表現を作る
視聴履歴からユーザー表現を作る
協調フィルタリング候補、人気候補、LLM embedding 候補を統合する
ランキングモデルに LLM 由来特徴量を入れる
再ランキングで多様性、配信制約、ビジネス制約を調整する
必要に応じて推薦理由を生成する
オフライン評価と A/B テストで効果を測る

数式で書くと、最終ランキングスコアは次のように表せる。

S(u,i) = f_\theta \left( x^{\text{cf}}_{u,i}, x^{\text{content}}_{u,i}, x^{\text{llm}}_{u,i}, x^{\text{context}}_{u,i} \right)

ここで $x^{\text{cf}}_{u,i}$ は協調フィルタリング由来特徴量、 $x^{\text{content}}_{u,i}$ は従来のコンテンツ特徴量、 $x^{\text{llm}}_{u,i}$ は LLM 由来特徴量、 $x^{\text{context}}_{u,i}$ は時間帯やデバイスなどの文脈特徴量である。

LLM はスコアを直接決めるのではなく、ランキングモデルに渡す情報を豊かにする。この設計なら、既存のランキングモデルを活かしつつ、意味理解を追加できる。

作品 embedding の生成

LLM 強化型で最も導入しやすいのは、作品 embedding の生成である。

Hulu の item_information_table には、作品を説明する列が多い。

series_title_ja
genre
sub_genre
description
sockets_tag
sentence
casts
film_directors
producers
writers
awards
avg_mood_tag
avg_fingerprint

これらを統合して、作品テキストを作る。

タイトル: インターステラー
ジャンル: 洋画 / SF
監督: クリストファー・ノーラン
出演: マシュー・マコノヒー、アン・ハサウェイ
タグ: 研究者、壮大な世界観、感動的、知的な
説明: 地球の寿命は尽きかけていた...
雰囲気: emotional=0.97, thought-provoking=0.97, intense=0.90

このテキストから embedding $\mathbf{e}_i$ を作る。ユーザー側も、最近視聴した作品を集約して embedding $\mathbf{e}_u$ を作る。候補作品との意味的近さは cosine 類似度で測れる。

\operatorname{sim}_{\text{llm}}(u,i) = \frac{ \mathbf{e}_u^{\mathsf{T}}\mathbf{e}_i }{ \|\mathbf{e}_u\| \|\mathbf{e}_i\| }

この特徴量は、候補検索にもランキングにも使える。

具体例：

プロフィール P001 が「インターステラー」「TENET」「メッセージ」を 25% 以上視聴していたとする。この履歴から作った embedding は、SF、時間、宇宙、知的、重厚、人間ドラマといった方向に寄る可能性がある。候補作品「オッペンハイマー」は宇宙 SF ではないが、ノーラン監督、科学者、重厚なドラマ、倫理的葛藤という意味で近い可能性がある。単純な genre=SF だけでは拾いにくい関係を、LLM embedding が補える。

LLM 由来タグとメタデータ拡張

LLM は、作品説明やタグから追加メタデータを生成できる。これは、ランキング特徴量やフィルタリングに使える。

例えば、作品ごとに次のような属性を付ける。

{
  "themes": ["space exploration", "family bond", "survival"],
  "moods": ["emotional", "thought-provoking", "intense"],
  "watch_contexts": ["weekend movie night", "solo viewing"],
  "pace": "slow-burn",
  "conversation_value": "high",
  "family_friendly": "medium"
}

このような属性は、従来の genre や sub_genre より細かい。例えば「考察したくなる作品」「疲れているときに軽く見られる作品」「家族で安心して見やすい作品」のような推薦軸を作れる。

ただし、LLM 生成タグには品質管理が必要である。LLM が説明文だけから過剰に推測したり、実際の作品内容と合わないタグを付けたりする可能性があるからである。

実務では、次のような対策が必要である。

出力スキーマを固定する
許可するタグ集合を管理する
生成結果をサンプリング監査する
既存の avg_mood_tag や視聴ログと矛盾しないかを見る
キッズ、安全性、レーティングに関わるタグは人手またはルールで検証する

LLM 強化型の利点

LLM 強化型の利点は、既存システムを活かしながら意味理解を追加できることである。

主な利点は次である。

導入範囲を限定しやすい
既存の候補検索、ランキング、評価基盤を再利用できる
オフライン生成やキャッシュでコストを抑えやすい
新作やロングテール作品の初期表現を作りやすい
自然言語説明や意味タグを追加できる
A/B テストで差分評価しやすい

Hulu のような大規模サービスでは、この利点が大きい。ホーム推薦は低レイテンシで安定して動く必要がある。LLM 強化型なら、重い処理はバッチで済ませ、オンラインでは embedding 類似度やランキング特徴量として使える。

LLM 強化型の課題

一方で、LLM 強化型にも課題がある。

目的関数とのズレ

LLM embedding が意味的に近い作品を見つけても、それが視聴されるとは限らない。意味的関連性と行動確率は違う。

例えば、「インターステラー」と科学ドキュメンタリーはテーマ的には近いかもしれない。しかし、ユーザーが映画を見たい気分なら、ドキュメンタリーは視聴されない可能性がある。

したがって、LLM 由来特徴量は、CTR、25% 以上視聴率、NDCG@K、総視聴時間などの実指標で検証する必要がある。

更新とキャッシュ

作品 embedding は比較的安定しているが、ユーザー embedding は変化する。最近視聴をどれだけ早く反映するかが問題になる。

例えば、ユーザーが昨日から韓国ドラマを見始めたのに、ユーザー embedding が 1 週間前の SF 映画嗜好のままだと、推薦が遅れる。逆に、1 回だけ見た作品に強く引っ張られすぎると、長期嗜好を壊す。

長期嗜好と短期意図を分ける設計が必要である。

\mathbf{e}_u = \lambda \mathbf{e}^{\text{long}}_u + (1-\lambda) \mathbf{e}^{\text{short}}_u

ここで $\mathbf{e}^{\text{long}}_u$ は長期履歴、 $\mathbf{e}^{\text{short}}_u$ は最近履歴から作った embedding である。

ストレージと検索基盤

作品数が多い場合、embedding を保存し、近傍検索する基盤が必要になる。ベクトルの次元数、更新頻度、ANN インデックス、フィルタ条件、配信制約を考慮する必要がある。

Hulu では、検索時に次の制約を必ず考える必要がある。

publish_start_at を過ぎている
publish_end_at を過ぎていない
is_blacklist=false
キッズやレーティング制約に合う
SVOD/TVOD の表示方針に合う

embedding 検索で近い作品が見つかっても、表示可能でなければ推薦できない。

LLM を推薦システムとして利用する方式

次に、LLM を推薦システムそのものとして使う方式を考える。この方式では、LLM にユーザー情報や要求を入力し、LLM が直接推薦を生成する。

例えば、次のようなプロンプトを入力する。

ユーザーの最近の視聴履歴:
- インターステラー
- TENET
- ダークナイト

ユーザーの要求:
今日は疲れているので、重すぎないが知的に楽しめる映画を見たい。

候補作品:
1. オッペンハイマー
2. メッセージ
3. 世界の果てまでイッテQ
4. 名探偵コナン 劇場版
5. 韓国恋愛ドラマ A

このユーザーに合う順に並べ、理由も短く説明せよ。

LLM は、履歴、要求、候補作品の意味を総合して、ランキングと理由を出せる。これは、従来のスコアリングモデルより柔軟である。

ただし、この方式を大規模なホーム推薦全体に使うのは難しい。理由は、コスト、レイテンシ、再現性、制約遵守、評価の難しさがあるからである。

LLM Recommender が向いている場面

LLM を推薦システムとして使う方式は、特に対話型、少数候補、高文脈の場面に向いている。

例えば：

会話型作品探索
自然言語検索
旅行プランや献立のような複合的推薦
ギフト選びのような相談型推薦
ユーザーが条件を何度も変更する推薦
少数候補の比較説明
「なぜこれがおすすめか」を重視する体験

Hulu であれば、次のような機能が考えられる。

ユーザー: 子どもと一緒に見られる映画を探して。怖すぎないものがいい。
システム: 年齢層は小学生くらいですか、それとも未就学児向けですか。
ユーザー: 小学生くらい。
システム: では、家族向けで冒険要素があり、怖さが強すぎない作品を中心に探す。

このようなやり取りでは、LLM の自然言語理解と対話能力が大きな価値を持つ。

LLM Recommender の基本構成

LLM を推薦システムとして使う場合でも、LLM だけで完結させるべきではない。実務では、候補取得や制約処理は外部システムに任せ、LLM は意図理解、候補比較、説明に使うのが安全である。

構成例：

ユーザーの自然言語要求を受け取る
LLM が要求を構造化する
検索システムが条件に合う候補を取得する
配信期間、ブラックリスト、キッズ制約、SVOD/TVOD 制約を適用する
通常のランキングモデルで候補を絞る
LLM が上位候補を再ランキングし、理由を生成する
ユーザーの追加要求に応じて再検索または再ランキングする

つまり、LLM Recommender と言っても、現実にはハイブリッドである。LLM が勝手に存在しない作品を作ったり、配信されていない作品を推薦したりしないように、候補集合はシステム側で制御する必要がある。

プロンプト設計の重要性

LLM を推薦システムとして使う場合、プロンプト設計が非常に重要になる。プロンプトが曖昧だと、LLM はもっともらしいが制約を守らない推薦を出す可能性がある。

悪いプロンプトの例：

このユーザーにおすすめの映画を教えて。

これでは、配信中かどうか、年齢制約、TVOD/SVOD、候補集合、理由の根拠が不明である。

より実務的なプロンプトでは、次の情報を明示する。

利用可能な候補作品だけから選ぶ
配信期間外やブラックリスト作品は含めない
ユーザー履歴
ユーザーの現在要求
出力形式
推薦理由に使ってよい根拠
不確実な場合は断定しない

例：

あなたは動画配信サービスの推薦補助である。
以下の候補作品だけから、ユーザー要求に合う順に最大 5 件を選ぶ。
候補にない作品を追加してはいけない。
推薦理由は、与えられたメタデータと視聴履歴に基づくものだけにする。

ユーザー要求:
週末に家族で見られる、怖すぎない冒険映画が見たい。

視聴履歴:
- 名探偵コナン
- SPY x FAMILY
- ハリー・ポッター

候補作品:
...

出力:
JSON で [{"series_id": ..., "reason": ...}] の形式にする。

このように、LLM の自由度を必要な範囲に制限することが重要である。

LLM Recommender の課題

LLM を推薦エンジンとして使う場合の課題は大きい。

計算コストとレイテンシ

ホーム推薦では、ユーザーが画面を開いた瞬間に推薦を返す必要がある。LLM に長い履歴や候補リストを渡して推論すると、レイテンシが大きくなる。

特に候補作品が数百件から数千件ある場合、すべてをプロンプトに入れることはできない。コンテキスト長にも制限があり、コストも高い。

そのため、LLM Recommender では、候補数を事前に絞る必要がある。

|\mathcal{I}| \rightarrow |\mathcal{C}_u| \rightarrow |\mathcal{L}_u|

ここで $\mathcal{I}$ は全作品集合、 $\mathcal{C}_u$ は候補検索後の集合、 $\mathcal{L}_u$ は LLM に渡す少数候補集合である。通常、 $|\mathcal{L}_u|$ は数十件程度に抑える必要がある。

制約遵守

LLM は、候補にない作品や配信されていない作品を推薦してしまう可能性がある。これは動画配信では致命的である。

Hulu では少なくとも次の制約を守る必要がある。

publish_start_at と publish_end_at の範囲内である
is_blacklist=false である
レーティングやキッズ制約に合う
地域や権利制約に合う
SVOD/TVOD の表示方針に合う

したがって、LLM には自由に作品名を生成させるのではなく、システムが渡した候補集合から選ばせるべきである。

再現性と評価

LLM の出力は、温度、プロンプト、モデルバージョン、候補順序に影響される。推薦システムでは、同じ入力に対して安定した出力が欲しい場面が多い。

また、従来の NDCG@K や Recall@K だけでは、会話型推薦の品質を十分に評価できない。

LLM Recommender では、次の評価も必要になる。

ユーザー要求を正しく理解したか
追加質問が適切か
候補にない作品を出していないか
推薦理由が事実に基づいているか
会話が短く目的達成できたか
ユーザーが最終的に視聴したか

どちらを選ぶべきか

選択基準は、プロダクトの目的、既存基盤、レイテンシ要件、コスト、評価可能性で決まる。

Hulu の代表的なユースケースで考える。

ユースケース	推奨パラダイム	理由
ホーム画面の大量推薦	LLM 強化型	低レイテンシ、大規模配信、既存ランキング活用が重要
新作やロングテールの候補補強	LLM 強化型	作品説明や mood から意味表現を作れる
ランキング特徴量追加	LLM 強化型	既存モデルに意味類似度を追加できる
推薦理由表示	LLM 強化型	根拠付き生成なら導入しやすい
自然言語検索	LLM Recommender 寄り	ユーザー意図の解釈が重要
会話型作品相談	LLM Recommender	対話と条件変更が中心
少数候補の比較	LLM Recommender	候補間の意味的な違いを説明しやすい

一般的には、最初に LLM 強化型を導入し、効果と運用知見を得たうえで、会話型推薦や自然言語検索に LLM Recommender を広げるのがよい。

Hulu での実践的なアーキテクチャ

Hulu の文脈では、次のようなハイブリッド構成が現実的である。

オフラインで item_information_table から作品テキストを作る
LLM または embedding モデルで作品 embedding と追加タグを生成する
unique_viewed_series から長期嗜好と短期嗜好を作る
協調フィルタリング、人気、新作、LLM embedding 検索で候補を集める
配信期間、ブラックリスト、キッズ制約を適用する
ランキングモデルで視聴確率や視聴時間を予測する
LLM 由来特徴量をランキングに入れる
ホーム推薦では低レイテンシな再ランキングを使う
会話型検索では LLM が自然言語要求を構造化し、少数候補を説明付きで提示する
オフライン評価と A/B テストで効果を検証する

この設計では、ホーム推薦と会話型推薦で LLM の役割を変えている。

ホーム推薦では、LLM は主にオフライン特徴量生成と候補補強に使う。会話型推薦では、LLM はユーザーとの対話、意図理解、説明生成に使う。

オフライン処理とオンライン処理の分離

LLM 活用で重要なのは、オフライン処理とオンライン処理を分けることである。

オフラインでできること：

作品 embedding 生成
作品タグ生成
作品説明の正規化
類似作品クラスタ作成
ロングテール作品の意味分類
推薦理由の候補テンプレート生成

オンラインで行うこと：

ユーザーの現在文脈を反映
候補検索
ランキング
配信制約チェック
少数候補の LLM reranking
会話応答

重い LLM 処理をすべてオンラインに置くと、コストとレイテンシが大きくなる。作品情報のようにあまり変わらないものはオフラインで処理し、ユーザーの今の要求だけオンラインで扱うのがよい。

評価方法の違い

LLM 強化型と LLM Recommender では、評価方法も少し違う。

LLM 強化型では、既存の推薦指標に乗せやすい。

Recall@K
NDCG@K
MAP@K
Coverage
Diversity
25% 以上視聴率
総視聴時間
A/B テストでのリテンション

一方、LLM Recommender では、会話品質や制約遵守も評価する必要がある。

要求理解の正確さ
候補外作品を出さない率
配信不可作品を出さない率
推薦理由の事実性
追加質問の適切さ
会話ターン数
ユーザーの最終視聴率
ユーザー満足度

例えば、会話型推薦で「怖すぎない家族向け映画」を要求された場合、単に視聴されたかだけでなく、本当に怖すぎない作品を出したか、キッズ制約を守ったか、理由が正しいかを見る必要がある。

よくある設計ミス

LLM に全候補を丸投げする

全作品や大量候補を LLM に渡してランキングさせる設計は、コストとレイテンシが大きくなりやすい。候補検索と軽量ランキングで絞ってから、必要な場合だけ LLM を使うべきである。

候補集合を制約しない

LLM に自由に作品名を生成させると、配信されていない作品や存在しない作品を出す可能性がある。Hulu では、必ず表示可能な series_id の候補集合から選ばせる必要がある。

LLM embedding をそのまま正解だと思う

意味的に近いことと、実際に視聴されることは違う。LLM embedding は有用な特徴量だが、行動ログとランキングモデルで補正する必要がある。

評価指標を従来のままにする

会話型推薦では、NDCG だけでは不十分である。要求理解、制約遵守、理由の正確さ、会話ターン数なども見る必要がある。

まとめ

推薦システムにおける LLM 活用には、大きく 2 つのパラダイムがある。LLM 強化型推薦システムは、既存の候補検索やランキングを維持しつつ、LLM を特徴量生成、embedding、タグ付け、説明生成、再ランキング補助に使う方式である。大規模なホーム推薦や既存基盤を持つサービスでは、この方式が現実的である。

LLM を推薦システムとして利用する方式は、LLM がユーザーの自然言語要求や会話履歴を直接解釈し、推薦リストや説明を生成する方式である。対話型推薦、自然言語検索、少数候補の比較には向いているが、コスト、レイテンシ、制約遵守、評価の難しさがある。

Hulu のような動画配信サービスでは、まず LLM 強化型として、item_information_table の作品情報や unique_viewed_series の視聴履歴を意味的に活用するのがよい。具体的には、作品 embedding、LLM 由来タグ、ユーザー嗜好プロファイル、意味類似度特徴量を既存の候補検索とランキングに追加する。

そのうえで、自然言語検索や会話型作品相談のような領域では、LLM Recommender を限定的に導入するのがよい。全推薦を LLM に置き換えるのではなく、既存の推薦基盤と LLM の得意領域を分担させることが、実務上の最も堅実な設計である。