2.2 課題と LLM 活用システムへの移行の詳解

位置づけ

2.1 では、従来型の推薦システムを、コンテンツ理解、ユーザーモデリング、候補検索、ランキング、評価という流れで見てきた。2.2 は、その従来型システムがなぜ限界を持つのか、そしてなぜ LLM を活用した推薦システムが注目されるのかを説明する節である。

重要なのは、LLM が従来の推薦システムを完全に置き換えるという話ではない。実務では、ID ベースの協調フィルタリング、候補検索、ランキングモデル、ビジネスルール、A/B テストは引き続き重要である。LLM は、それらが苦手としてきた意味理解、自然言語理解、コールドスタート、説明生成、非構造化データ活用を補強する技術として考えるのが現実的である。

Hulu のような動画配信サービスで考えると、既に次のような構造化データと行動データがある。

item_information_table: 作品メタデータ
unique_viewed_series: profile_id ごとの 25% 以上視聴シリーズ
genre、sub_genre、casts、film_directors、description、sockets_tag
avg_mood_tag、avg_fingerprint
service_type、publish_start_at、publish_end_at、is_blacklist

従来型の推薦では、これらを特徴量として使い、視聴履歴から「このプロフィールは次に何を見そうか」を予測する。一方、LLM 活用型では、作品説明、タグ、視聴履歴、自然言語クエリ、ユーザーの文脈を、より意味的に扱える。

例えば、従来モデルが「このユーザーは SF ジャンルをよく見る」と捉えるのに対して、LLM 活用型では「このユーザーは、宇宙、時間、父子関係、知的サスペンス、重厚な映像体験を好む可能性がある」といった、より説明的な嗜好表現を作れる。

なぜ従来型推薦だけでは難しくなるのか

従来型推薦、特に協調フィルタリングは非常に強力である。ユーザーとアイテムの相互作用を大量に集めれば、「似たユーザーが見た作品」「この作品を見た人が次に見た作品」を高精度に推定できる。

しかし、現代の推薦システムでは、次のような問題が大きくなる。

ユーザーの嗜好が短時間で変わる
同じユーザーでも文脈によって見たいものが変わる
新作やロングテール作品には十分な視聴履歴がない
作品の意味的な近さが、視聴共起だけでは分からない
自然言語クエリや会話的な要求に対応したい
推薦理由を説明したい
画像、動画、テキスト、行動ログを統合したい
オンライン更新やリアルタイム適応が必要になる

Hulu で考えると、同じプロフィールでも、平日夜には短いバラエティ、週末には長尺映画、家族で見るときはアニメ、ひとりのときは海外ドラマ、というように文脈で嗜好が変わる。unique_viewed_series だけを見ると「このプロフィールはこれらのシリーズを 25% 以上見た」という事実は分かるが、その視聴がどのような気分、目的、状況で起きたのかは分からない。

また、新しく配信開始された作品は視聴履歴が少ない。協調フィルタリングは相互作用がないと強い信号を得にくい。一方、description、sentence、sockets_tag、casts、film_directors、avg_mood_tag、avg_fingerprint は配信直後から使える。LLM は、このようなコンテンツ情報を意味的に解釈し、初期推薦に活かしやすい。

ユーザーレベルの課題

ユーザーレベルの課題とは、ユーザーの嗜好や意図を正しく捉えることの難しさである。

従来型の推薦では、ユーザーは多くの場合、過去の行動ベクトルとして表現される。例えば、プロフィール $u$ の視聴履歴をもとに、ユーザー embedding $\mathbf{u}$ を作る。

\mathbf{u} = \frac{ \sum_{i \in \mathcal{H}_u} \alpha(t_{u,i}) \mathbf{v}_i }{ \sum_{i \in \mathcal{H}_u} \alpha(t_{u,i}) }

ここで $\mathcal{H}_u$ はプロフィール $u$ の視聴履歴、 $\mathbf{v}_i$ は作品 $i$ の embedding、 $\alpha(t_{u,i})$ は最近視聴ほど大きくする重みである。

この方法は有用である。しかし、ユーザーの意図を 1 本のベクトルに押し込めるため、複雑な嗜好を表現しにくい。

例えば、あるプロフィールが次の作品を見ていたとする。

「インターステラー」
「TENET」
「名探偵コナン」
「世界の果てまでイッテQ」
「アンパンマン」

この履歴から単純に平均 embedding を作ると、SF 映画、アニメ、バラエティ、キッズ作品が混ざった曖昧なベクトルになる。実際には、これは 1 人の嗜好ではなく、家族で同じプロフィールを共有している結果かもしれない。また、平日夜と週末、親と子ども、ひとり視聴と家族視聴で意図が違う可能性がある。

動的な嗜好変化

ユーザーの嗜好は固定ではない。最近見た作品、季節、曜日、時間帯、社会的トレンド、配信開始イベント、キャンペーンによって変化する。

動画配信での例：

年末年始には長尺映画や家族向け作品が見られやすい
新シーズン公開直後は前シーズンの復習視聴が増える
大型スポーツイベント後に関連ドキュメンタリー需要が増える
連休中は一気見されやすいシリーズが伸びる
平日朝は短尺ニュースや子ども向け作品が見られやすい

従来の協調フィルタリングは、過去の相互作用行列をもとに学習するため、このような変化を即座に反映するのが苦手である。もちろん、時間特徴量や最近視聴重みを入れれば改善できる。しかし、外部イベントや自然言語で表現されるトレンドを理解するのは難しい。

LLM は、テキストで与えられる文脈を扱える。例えば「今週から新シーズンが始まった」「夏休み期間」「金曜夜」「家族で見られる作品」といった情報をプロンプトや特徴量に入れ、推薦の意図を調整できる。

自然言語クエリの難しさ

教科書の例にある「アクション満載だが家族向けの、過去 10 年間の映画」は、従来型推薦にとって難しい要求である。

このクエリには複数の条件が含まれている。

アクション要素が強い
家族向けである
過去 10 年間の映画である
おそらく過度に暴力的ではない
ユーザーの現在の視聴意図に合う

構造化メタデータだけで処理するなら、genre、sub_genre、premiere_year、rating_name、kids_mature_flg などを組み合わせる必要がある。しかし、「アクション満載」「家族向け」は必ずしも単一の列で表現されていない。description、sockets_tag、sentence、avg_mood_tag に分散している可能性がある。

LLM は、この自然言語クエリを構造化条件に変換できる。

例えば：

{
  "media_type": "movie",
  "premiere_year_min": 2016,
  "desired_attributes": ["action", "family-friendly"],
  "avoid_attributes": ["extreme violence", "adult-only"],
  "ranking_intent": "family co-viewing"
}

このように自然言語を検索条件やランキング特徴量に変換できれば、従来型の検索・ランキング基盤とも接続しやすい。

LLM によるユーザーモデリング

LLM を使うと、ユーザー履歴を単なる ID 列ではなく、意味的なプロフィールとして表現できる。

例えば、次のような視聴履歴があるとする。

インターステラー
TENET
ダークナイト
メッセージ

従来型では、これを item ID の集合、ジャンル分布、embedding 平均として扱う。LLM 活用では、次のような自然言語プロファイルを生成できる。

このプロフィールは、時間、記憶、宇宙、倫理的選択を扱う重厚な SF やサスペンスを好む傾向がある。派手なアクションだけでなく、複雑な構成や考察性の高い作品に反応しやすい。

このプロファイルは、そのままユーザーに見せる必要はない。ランキング特徴量、候補検索クエリ、推薦理由生成、セグメント分析に使える。

ただし、LLM によるユーザーモデリングには注意点もある。

視聴履歴から過剰に推測しすぎる可能性がある
家族共有プロフィールでは人物の嗜好が混ざる
一時的な視聴を長期嗜好と誤解する可能性がある
個人情報やセンシティブ属性を推測すべきではない
生成されたプロファイルが実際の行動に効くとは限らない

したがって、LLM が作ったユーザープロファイルは「仮説」として扱い、オフライン評価と A/B テストで検証する必要がある。

アイテムレベルの課題

アイテムレベルの課題とは、作品同士の関係や作品の意味を正しく捉えることの難しさである。

従来の協調フィルタリングでは、作品同士の近さは共起で決まりやすい。例えば「作品 A を見た人が作品 B もよく見る」なら、A と B は近いと判断される。

これは強力だが、次のような場合に弱い。

新作で視聴履歴が少ない
ロングテール作品で共起が少ない
意味的には近いが視聴者層がまだ重なっていない
ジャンルは違うが同じ気分やテーマで見られる
キャスト、監督、世界観、雰囲気の関連が複雑
動画の内容とメタデータが一致していない

Hulu の item_information_table には、作品理解に使える情報が多い。例えば、「インターステラー」には description、sockets_tag、casts、film_directors、awards、avg_mood_tag、avg_fingerprint がある。

従来の表形式モデルでは、これらを one-hot、頻度、embedding、類似度として使うことはできる。しかし、説明文やタグの奥にある意味、例えば「人類存続」「父と娘」「時間の歪み」「知的で感動的な SF」といった抽象的テーマを十分に捉えるのは難しい。

LLM は、作品テキストから次のような意味表現を抽出できる。

テーマ
感情トーン
視聴シーン
類似作品との違い
適したユーザー意図
注意すべき表現
ファミリー視聴向きか
短時間で気軽に見られるか
考察向きか

ロングテールと意味的橋渡し

ロングテール作品とは、人気作品に比べて視聴回数が少ない作品である。ロングテール作品は、協調フィルタリングでは不利になりやすい。相互作用が少ないため、類似ユーザーや類似作品を見つけにくいからである。

しかし、ロングテール作品の中にも、特定のユーザーには強く刺さる作品がある。問題は、その関係が行動ログだけでは見えにくいことである。

例えば、あるドキュメンタリー作品があるとする。視聴者数は少ないが、内容は「宇宙開発」「科学者の挑戦」「人類の未来」を扱っている。この作品は、SF 映画好き、特に「インターステラー」や「メッセージ」を好むユーザーに合う可能性がある。

協調フィルタリングでは、このドキュメンタリーと SF 映画の共視聴が少なければ、近いとは判断されにくい。一方、LLM は作品説明を読んで、テーマの近さを推定できる。

このような関係を、意味的橋渡しと呼べる。

数式的には、ID ベースの類似度と意味ベースの類似度を組み合わせる設計が考えられる。

\operatorname{score}(u,i) = w_{\text{cf}} s_{\text{cf}}(u,i) + w_{\text{sem}} s_{\text{sem}}(u,i) + w_{\text{pop}} s_{\text{pop}}(i)

ここで $s_{\text{cf}}(u,i)$ は協調フィルタリング由来のスコア、 $s_{\text{sem}}(u,i)$ は LLM embedding やコンテンツ理解由来の意味的スコア、 $s_{\text{pop}}(i)$ は人気度スコアである。

ロングテール作品では $s_{\text{cf}}(u,i)$ が弱くなりやすい。そのため、 $s_{\text{sem}}(u,i)$ が候補検索やランキングで重要になる。

マルチモーダルなアイテム理解

動画推薦では、作品の内容はテキストだけではない。映像、音声、サムネイル、予告編、字幕、説明文、タグ、出演者、監督、視聴ログがすべて作品理解に関係する。

Hulu のデータには、avg_fingerprint と avg_mood_tag がある。これは映像の動画内容そのものから外部 AI が推定した embedding や雰囲気スコアであり、マルチモーダル理解に近い信号である。

例えば、avg_mood_tag に次のような値があるとする。

{
  "emotional": 0.97,
  "futuristic": 0.46,
  "humanity": 0.69,
  "inspiring": 0.90,
  "intense": 0.90,
  "thought-provoking": 0.97
}

この作品は、単に genre=洋画、sub_genre=SF と見るより、「感情的で、知的で、緊張感があり、人間性を扱う作品」と理解できる。

LLM やマルチモーダルモデルは、このような映像由来特徴とテキスト特徴を統合できる。

例えば、作品 embedding を次のように作る。

\mathbf{v}_i = \operatorname{concat} \left( \mathbf{e}^{\text{text}}_i, \mathbf{e}^{\text{video}}_i, \mathbf{e}^{\text{metadata}}_i \right)

ここで $\mathbf{e}^{\text{text}}_i$ は説明文やタグから作った embedding、 $\mathbf{e}^{\text{video}}_i$ は映像内容から作った embedding、 $\mathbf{e}^{\text{metadata}}_i$ はジャンル、出演者、監督、公開年などから作った embedding である。

この統合表現により、行動ログが少ない作品でも、意味的に近い作品や適したユーザーを探しやすくなる。

モデルレベルの課題

モデルレベルの課題とは、推薦モデルそのものの一般化、更新、拡張、運用に関する難しさである。

教科書では、コールドスタート、データ疎性、スケーラビリティが挙げられている。Hulu の文脈では、これらは非常に現実的な問題である。

コールドスタート

コールドスタートには、新規ユーザーと新規アイテムの 2 種類がある。

新規ユーザーは、視聴履歴が少ないため、嗜好を推定しにくい。unique_viewed_series にほとんど行がないプロフィールでは、協調フィルタリングもユーザー embedding も不安定になる。

新規アイテムは、配信開始直後で視聴履歴が少ないため、どのユーザーに合うか分かりにくい。新作映画、独占配信、期間限定作品、TVOD 作品では特に重要である。

LLM は、新規アイテムのコールドスタートに強い。視聴ログがなくても、description、sockets_tag、casts、film_directors、genre、avg_mood_tag を読んで、作品の意味表現を作れるからである。

例えば、新作の説明文が次のような内容だったとする。

近未来の宇宙開発を舞台に、家族との約束と人類の未来を背負った科学者の葛藤を描く。

LLM は、この作品が「SF」「家族」「人類の未来」「科学者」「感動的」「思索的」といったテーマを持つと推定できる。これにより、「インターステラー」「メッセージ」「オデッセイ」などを見たユーザーに初期推薦しやすくなる。

データ疎性

推薦データは基本的に疎である。ユーザー数と作品数が大きいほど、全ユーザーが全作品を見ることはあり得ない。

ユーザー集合を $\mathcal{U}$ 、アイテム集合を $\mathcal{I}$ 、観測された視聴ペア集合を $\mathcal{O}$ とすると、観測率は次のように表せる。

\rho = \frac{|\mathcal{O}|} {|\mathcal{U}| |\mathcal{I}|}

通常、 $\rho$ は非常に小さい。つまり、ユーザーとアイテムの組み合わせの大半は未観測である。

未観測は「嫌い」を意味しない。単に表示されていない、気づいていない、まだ見る時間がない、TVOD なので後回しにした、などの可能性がある。

LLM は、未観測の空白を意味情報で補える。例えば、視聴履歴が少ないユーザーでも、数件の視聴作品から嗜好を言語的に推定できる。視聴履歴が少ない作品でも、説明文や映像特徴から対象ユーザーを推定できる。

ただし、これは万能ではない。LLM が意味的に合うと判断した作品が、実際に視聴されるとは限らない。価格、配信タイミング、サムネイル、知名度、気分、デバイス、家族状況などが影響する。したがって、LLM の推論は行動ログで補正する必要がある。

スケーラビリティ

LLM を推薦に使うとき、スケーラビリティは大きな問題である。

全ユーザー、全候補作品に対して、毎回 LLM にプロンプトを投げてランキングするのは現実的ではない。レイテンシ、コスト、安定性、再現性の問題がある。

例えば、1 リクエストで候補 1000 件を LLM に渡して並べ替えるとする。ユーザー数が多いサービスでは、コストも遅延も大きくなりすぎる。

したがって、LLM 活用は次のように分解して設計するのが現実的である。

オフラインで作品 embedding を作る
オフラインで作品タグや説明要約を作る
オフラインでユーザーセグメントや嗜好プロファイルを作る
リアルタイムでは embedding 検索や軽量ランキングに使う
LLM 直接推論は少数候補の再ランキングや説明生成に限定する
高価な LLM 出力はキャッシュする

つまり、LLM をオンラインランキングの全件処理に使うのではなく、特徴量生成、候補生成補助、意味理解、説明生成に使う方がスケールしやすい。

LLM 活用型推薦の代表的なパターン

LLM を推薦に使う方法はいくつかある。実務では、以下のパターンを組み合わせることが多い。

パターン 1: LLM embedding を使う

最も導入しやすいのは、テキストやプロフィールから embedding を作り、候補検索やランキング特徴量として使う方法である。

作品 embedding:

series_title_ja、genre、sub_genre、description、sockets_tag、casts、film_directors、sentence を結合し、作品テキストを作る。

ユーザー embedding:

最近視聴した作品の説明文やタグを集約し、プロフィールの嗜好テキストを作る。

類似度は cosine 類似度で計算できる。

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

この方法の利点は、既存の ANN 検索やランキングモデルに組み込みやすいことである。欠点は、embedding がなぜ近いのかを細かく制御しにくいこと、最新のユーザー文脈を反映するには更新が必要なことである。

パターン 2: LLM でメタデータを拡張する

LLM を使って、作品に追加タグや説明属性を付ける方法である。

例えば、description と sockets_tag から次のような属性を生成する。

テーマ
視聴気分
対象年齢感
家族視聴向き
考察向き
軽く見られるか
感情トーン
暴力性や怖さの注意
類似作品クラスタ

例：

{
  "themes": ["space exploration", "family bond", "survival"],
  "mood": ["emotional", "thought-provoking", "intense"],
  "watch_context": ["weekend movie night", "solo viewing"],
  "not_suitable_for": ["light background viewing"]
}

このような属性は、ランキング特徴量やフィルタリング、推薦理由生成に使える。

Hulu の avg_mood_tag は既に雰囲気スコアを持っているため、LLM 生成タグと組み合わせると、メタデータの厚みを増やせる。

パターン 3: LLM で自然言語クエリを構造化する

検索や会話型推薦では、ユーザーが自然言語で要求を出す。

例えば：

週末に家族で見られる、怖すぎない冒険映画を探して

LLM はこれを次のような構造化条件に変換できる。

{
  "watch_context": "family weekend",
  "desired_genres": ["adventure", "family"],
  "avoid": ["horror", "extreme violence"],
  "duration_preference": "movie",
  "safety_level": "family-friendly"
}

この出力を使って、従来の検索基盤、候補検索、ランキングモデルを動かす。重要なのは、LLM が最終推薦をすべて決めるのではなく、ユーザー意図を既存システムが扱いやすい形に変換する点である。

パターン 4: LLM で少数候補を再ランキングする

候補検索と通常ランキングで上位 20 件程度まで絞った後、LLM にリスト全体を見せて再ランキングする方法である。

これは、全候補に LLM を使うより現実的である。

LLM reranker では、次のような観点を考慮できる。

ユーザーの現在の自然言語意図
視聴履歴との意味的なつながり
リスト内の重複
多様性
家族視聴やキッズ安全性
推薦理由の自然さ

ただし、オンラインで毎回 LLM reranking を行うとコストとレイテンシが大きい。高価な処理なので、会話型推薦、検索結果ページ、重要な棚など、使いどころを限定するのが現実的である。

パターン 5: LLM で推薦理由を生成する

LLM は、推薦理由の生成に向いている。

例えば、次のような理由を生成できる。

「インターステラー」や「TENET」のような、時間と人間ドラマを扱う重厚な作品を視聴しているため、この作品も合う可能性がある。

推薦理由は、ユーザーの納得感を高める可能性がある。ただし、理由が不正確だと信頼を損なう。

例えば、実際にはキャストが共通していないのに「同じ俳優が出演」と書いてはいけない。LLM はもっともらしいが誤った説明を生成する可能性があるため、推薦理由は構造化データに基づいて生成するべきである。

安全な設計としては、LLM に自由生成させるのではなく、使ってよい根拠を渡す。

{
  "allowed_evidence": [
    "同じ監督",
    "SF ジャンル",
    "thought-provoking mood が高い",
    "過去に類似作品を視聴"
  ]
}

このように制約をかけることで、説明の正確性を上げられる。

LLM 活用と従来型推薦のハイブリッド構成

実務で有力なのは、従来型推薦と LLM を組み合わせるハイブリッド構成である。

Hulu の推薦パイプラインに当てはめると、次のようになる。

item_information_table から公開中で推薦可能な作品を抽出する
作品説明、タグ、キャスト、監督、mood、fingerprint から意味表現を作る
unique_viewed_series からプロフィールの視聴履歴を作る
視聴履歴から協調フィルタリング系のユーザー表現を作る
視聴履歴から LLM ベースの嗜好プロファイルや embedding を作る
協調フィルタリング候補、意味検索候補、人気候補、新作候補を統合する
ランキングモデルで視聴確率や視聴時間を予測する
LLM 由来特徴量をランキング特徴量として使う
必要に応じて少数候補を LLM で再ランキングする
推薦理由を生成する
A/B テストとモニタリングで効果を検証する

この構成では、LLM は複数箇所で使える。

工程	LLM の使い方
コンテンツ理解	説明文、タグ、映像由来情報から意味属性を抽出
ユーザーモデリング	視聴履歴から嗜好プロファイルを生成
候補検索	embedding 検索やクエリ拡張に使う
ランキング	LLM embedding、意味類似度、生成タグを特徴量にする
再ランキング	少数候補を文脈に合わせて並べ替える
説明	推薦理由を自然言語で生成
評価	リスト品質や説明文品質を補助評価

重要なのは、LLM の出力をそのまま信用しすぎないことである。LLM は意味理解に強いが、Hulu の実ユーザーが実際に視聴するかは別問題である。最終的には行動ログと A/B テストで評価する必要がある。

LLM 移行で増える新しい課題

LLM を使えば従来の課題がすべて解決するわけではない。むしろ、新しい課題も増える。

レイテンシとコスト

LLM 推論は、通常の embedding 類似度計算や GBDT ランキングより高コストである。オンラインで頻繁に呼ぶと、ページ表示速度やインフラコストに影響する。

対策としては、次がある。

オフライン生成を基本にする
embedding やタグをキャッシュする
LLM reranking は候補数を絞ってから行う
小さいモデルと大きいモデルを使い分ける
バッチ処理を使う
頻繁に変わらない作品情報は再生成しない

ハルシネーション

LLM は存在しない情報をもっともらしく生成することがある。推薦理由で特に危険である。

例えば、作品 A と作品 B に共通キャストがいないのに「同じ俳優が出演」と説明してしまうと、ユーザーの信頼を損なう。

対策としては、次がある。

生成に使ってよい根拠を構造化して渡す
item_information_table の事実に基づかない説明を禁止する
キャスト、監督、公開年などは生成ではなく参照で埋める
LLM 出力を検証するルールを入れる
推薦理由をテンプレート化する

評価の難しさ

LLM が作った embedding、タグ、プロファイル、説明文が本当に推薦改善に効いているかを測る必要がある。

例えば、LLM 生成タグが増えると、オフライン NDCG は上がるかもしれない。しかし、オンラインでは視聴率が変わらない可能性もある。また、説明文が自然でも、ユーザーがそれを見ているとは限らない。

評価では、次のように分ける必要がある。

意味品質: タグや説明が正しいか
モデル品質: NDCG@K や Recall@K が上がるか
体験品質: ユーザーが推薦を理解しやすいか
ビジネス品質: 視聴、継続、収益に効くか
安全性: 不適切な生成や誤説明がないか

プライバシーと安全性

ユーザー履歴から自然言語プロファイルを作ると、過剰な推測が発生する可能性がある。

例えば、「このユーザーは深夜に特定ジャンルをよく見るため、心理状態はこうである」といった推測は避けるべきである。推薦に必要な範囲を超えて、センシティブな属性や状態を推測してはいけない。

安全な方針としては、次がある。

視聴嗜好に限定したプロファイルにする
センシティブ属性を推測しない
家族共有プロフィールで個人を断定しない
ユーザーに見せる説明では過度に内面を推測しない
ログと生成物の保存期間や利用目的を明確にする

Hulu での具体的な移行ステップ

LLM 活用へ移行するとき、いきなり本番ランキングを LLM に置き換えるのはリスクが高い。段階的に導入するのがよい。

ステップ 1: 作品メタデータ拡張

最初に取り組みやすいのは、作品メタデータの拡張である。

item_information_table の次の列を使う。

series_title_ja
genre
sub_genre
sockets_tag
sentence
description
casts
film_directors
awards
avg_mood_tag
avg_fingerprint

LLM で、作品ごとにテーマ、気分、視聴文脈、注意要素、類似作品説明を生成する。これはオンライン推論ではなく、オフラインバッチでよい。

ステップ 2: 意味 embedding 候補検索

次に、作品テキスト embedding を作り、ユーザー履歴 embedding と近い作品を候補に出す。

既存の候補検索に、次の検索経路を追加するイメージである。

協調フィルタリング候補
人気候補
新作候補
LLM embedding 類似候補
mood 類似候補

この段階では、LLM 候補だけに頼らず、候補検索の recall を上げるための追加チャネルとして使うのがよい。

ステップ 3: ランキング特徴量として利用

候補検索で集めた作品に対して、LLM 由来特徴量をランキングに入れる。

例えば：

ユーザー嗜好プロファイル embedding と作品 embedding の類似度
最近視聴作品と候補作品の意味類似度最大値
作品の LLM 生成テーマ
作品の watch context タグ
mood と LLM タグの一致
自然言語クエリと作品の一致度

この段階では、ランキングモデルは従来の GBDT や DNN のままでよい。LLM は特徴量を供給する役割である。

ステップ 4: 説明生成

推薦理由を生成する。ただし、最初は自由生成ではなく、根拠付きテンプレートに近い形がよい。

例えば：

「{過去視聴作品}」と同じく、{theme} や {mood} を持つ作品であるためおすすめである。

ここで {theme} や {mood} は、LLM が生成した属性ではなく、検証済みの属性または構造化データから選ぶ。

ステップ 5: 会話型推薦や高度な再ランキング

最後に、自然言語クエリや会話型推薦に広げる。

例えば：

今日は疲れているので、軽く笑える 30 分くらいの作品が見たい

このような要求は、従来型のジャンル検索だけでは扱いにくい。LLM が意図を解釈し、作品候補を条件に合わせて絞り、ランキングすることで価値が出る。

ただし、会話型推薦は UI、ログ設計、評価指標も変わる。通常のホーム推薦とは別のプロダクトとして評価する必要がある。

表 2.1 の読み替え

教科書の表 2.1 を Hulu 文脈で読み替えると、次のようになる。

課題カテゴリ	Hulu での具体例	従来手法の弱点	LLM 活用の方向性
ユーザーレベル	同一プロフィール内で家族の嗜好が混ざる、曜日や気分で見たいものが変わる	過去視聴 ID の平均では意図を分解しにくい	視聴履歴を意味的プロファイル化し、文脈や自然言語意図を反映する
アイテムレベル	新作、ロングテール、ジャンル横断のテーマ類似作品	共視聴が少ない作品の関係を捉えにくい	説明文、タグ、mood、映像 embedding から意味的関係を作る
モデルレベル	新規プロフィール、新規配信作品、疎な視聴ログ	相互作用がないと推定しにくい	ゼロショットな作品理解、LLM embedding、合成特徴量で補う
その他	推薦理由が説明できない、複雑な検索要求に弱い	ID ベースのスコアは理由を持たない	根拠付き説明生成、自然言語クエリ解析、会話型推薦

この表で重要なのは、LLM の役割が「スコアを魔法のように当てること」ではない点である。LLM は、従来システムが扱いにくかった非構造化情報や自然言語意図を、推薦パイプラインで使える形に変換する役割を担う。

よくある誤解

LLM があれば協調フィルタリングは不要になる

これは誤解である。協調フィルタリングは、実ユーザーの行動パターンを直接反映できる。LLM が作品説明を読んで「合いそう」と判断しても、実際に Hulu ユーザーが見るかは別問題である。

実務では、協調フィルタリングと LLM は補完関係にある。行動ログが豊富な人気作品では協調フィルタリングが強く、新作やロングテールでは LLM の意味理解が効きやすい。

LLM にランキングを全部任せればよい

これも危険である。LLM はコスト、レイテンシ、再現性、ハルシネーション、評価の難しさを持つ。特に大規模サービスで全リクエストを LLM ランキングにするのは重い。

現実的には、LLM は候補生成、特徴量生成、少数候補の再ランキング、説明生成に使い、最終的な大規模ランキングは軽量モデルや既存基盤と組み合わせる。

LLM の説明は常に正しい

LLM は自然な説明を作るのが得意だが、事実性は保証されない。推薦理由は、構造化データや実際の特徴量に基づいて制約する必要がある。

意味的に近い作品は必ず視聴される

意味的類似性と行動確率は違う。作品がテーマ的に近くても、知名度、サムネイル、配信タイミング、視聴時間、価格、気分によって視聴されないことがある。LLM 由来の意味特徴は、行動ログに基づくランキングで補正する必要がある。

まとめ

2.2 の主旨は、従来型推薦が弱い領域を整理し、それが LLM 活用型推薦への移行を促している、ということである。

ユーザーレベルでは、嗜好の動的変化、文脈依存、自然言語意図、家族共有プロフィールのような複雑性が課題になる。LLM は視聴履歴や文脈を意味的に解釈し、ユーザープロファイルやクエリ理解を補強できる。

アイテムレベルでは、新作、ロングテール、ジャンル横断の意味的関連性が課題になる。LLM は description、sockets_tag、sentence、casts、film_directors、avg_mood_tag、avg_fingerprint などを統合し、作品のテーマや雰囲気を捉えやすくする。

モデルレベルでは、コールドスタート、データ疎性、スケーラビリティが課題になる。LLM はゼロショットな作品理解や embedding 生成により、相互作用が少ない領域を補える。ただし、オンライン推論コストが高いため、オフライン特徴量生成や少数候補の再ランキングとして使うのが現実的である。

Hulu の推薦で実践するなら、まず LLM を作品メタデータ拡張、意味 embedding 候補検索、ランキング特徴量、推薦理由生成に使うのがよい。いきなりランキング全体を LLM に置き換えるのではなく、既存の協調フィルタリング、候補検索、ランキング、評価基盤と組み合わせるべきである。

LLM 活用への移行は、従来手法の否定ではない。行動ログに基づく強い推薦基盤の上に、言語理解、意味理解、説明可能性、コールドスタート対応を追加する進化である。