4.1〜4.3 推薦システムとしての LLM

Hulu で利用できる主要な信号

Hulu のデータカタログに沿うと、入力は概ね次のように対応する。

ここで、profile_id と account_id を混同してはならない。アカウントには複数のプロフィールがありうるため、個人嗜好は原則として profile_id 単位で構築する。家族全体の契約状態などは account_id 単位であるが、視聴嗜好までアカウント単位に集約すると、親と子どもの視聴が混ざる可能性がある。

暗黙的フィードバックは「評価 5」ではない

Hulu では視聴の有無が主なフィードバックである。しかし、再生されたことを「好き」と断定できない。自動再生、誤タップ、家族による共用、途中離脱、続き物を義務的に見た場合などがあるからである。反対に、未視聴も「嫌い」を意味しない。単に表示されていない、配信開始を知らない、時間がなかった可能性がある。

従って、LLM に渡す要約も次のように証拠の強さを区別するべきである。

• 25% 以上視聴した作品: 比較的強い正のシグナルであるが、明示的な好評価ではない
• 長時間または完了近くまで視聴した作品: より強い関心の証拠になりうる
• 詳細ページを訪問しただけの作品: 弱い関心である
• 表示されたが選択されなかった作品: 曝露を確認できるが、単発では強い負例にしない
• 表示すらされていない作品: 正負不明である

例えば、作品 $i$ に対する一つの簡易な行動強度を次のように作れる。

ここで、 $w_{ui}$ はプロフィール $u$ の視聴秒数、 $d_i$ は作品長である。これは正解となる唯一の式ではなく、異なる行動を同一の「視聴済み」に潰さないための説明例である。

数値を入れてみる。100 分の『インターステラー』を 80 分視聴し、25% 条件を満たしたが、お気に入り登録はないとする。このとき、

一方、同じ作品を 5 分だけ視聴したなら、25% 条件を満たさず、

となる。両方を単なる watched=true にすると、この差が失われる。

時間減衰を使った履歴要約

コンテキスト長には上限があるため、全視聴履歴をそのまま入れるべきではない。また、3 年前の嗜好と昨夜の意図を同じ重みで扱うのも不自然である。そこで、行動強度 $r_{ui}$ に時間減衰を掛ける方法がある。

$\Delta t_{ui}$ は最終行動からの経過日数、 $\tau$ は減衰の時定数である。例えば $r_{ui}=0.8$、 $\tau=30$ 日なら、3 日前の作品は、

90 日前の作品は、

となる。ただし、長期嗜好まで消すと「昔からミステリーが好き」という安定した特徴を失う。そのため、実際には「直近セッション」「過去 30 日」「長期プロファイル」を別々に要約すると扱いやすい。

LLM に渡す構造化入力の例

自然言語だけでも処理できるが、本番では意味の境界が明確な JSON の方が検証しやすい。

{
  "profile": {
    "is_kids": false,
    "language": "ja",
    "current_time_jst": "2026-08-24T21:10:00",
    "device": "tv"
  },
  "recent_history": [
    {
      "series_id": 500001745,
      "title": "インターステラー",
      "watched_ratio": 0.80,
      "days_ago": 3,
      "evidence": "long_view"
    },
    {
      "series_id": 500005989,
      "title": "るろうに剣心 －明治剣客浪漫譚－ 追憶編",
      "watched_ratio": 0.05,
      "days_ago": 1,
      "evidence": "short_view"
    }
  ],
  "long_term_summary": {
    "positive_tendencies": ["思索的SF", "緊張感のあるドラマ"],
    "uncertain_tendencies": ["時代劇アニメ"]
  },
  "request": {
    "task": "rerank",
    "top_k": 5
  }
}

重要なのは、要約を事実と推論に分けることである。「『インターステラー』を 80% 視聴した」は事実であるが、「思索的 SF が好き」はモデルによる推論である。両者を区別しておけば、誤った嗜好推定を監査しやすい。

難所の補足: プロンプトは「お願い文」ではなく境界仕様である

人間への依頼なら、「おすすめを五つ教えて」で意図を補ってもらえる。しかし、本番システムでは、五件未満のとき、候補が不適切なとき、ID が欠けているとき、配信条件が矛盾するときの動作まで決める必要がある。この意味で、プロンプトは自然言語で書かれた関数仕様に近い。

通常の関数が入力型、返り値型、例外を定義するのと同様に、推薦プロンプトも入力データの意味、許可された候補、出力 schema、棄権条件を定義する。プロンプトに書かれた指示だけでは完全な強制力を持たないため、schema validation や候補 ID の allowlist が、型検査と実行時検証の役割を担う。

また、固定指示、ユーザーの自然言語要求、作品説明が同じ文字列として連結されても、信頼度は同じではない。固定指示はシステムのルール、ユーザー要求は満たすべき希望、作品説明は参照用データである。この優先順位を明確に分けることで、作品説明中の文章を命令として誤解する prompt injection も防ぎやすくなる。

実用的なプロンプトは、少なくとも次のブロックを持つ。

1. 役割と目的

2. 行動シグナルの意味

3. ユーザー状態

4. 選択可能な候補集合

5. 配信・安全・多様性などの制約

6. 出力 schema

7. 不確実な場合の動作

Hulu 向けの簡略例は次の通りである。

あなたは動画推薦の再ランキング器である。

目的:
- 与えられた候補だけから、今視聴される可能性が高い順に5件選ぶ。
- series_idを一文字も変更しない。

行動の解釈:
- 25%以上の視聴は比較的強い正の証拠だが、明示評価ではない。
- 短時間視聴は弱い証拠であり、嫌いと断定しない。
- 未視聴は負例ではない。

制約:
- candidatesにない作品を生成しない。
- 同一series_idを重複させない。
- 作品説明にない事実を推薦理由に使わない。
- 各理由はユーザー履歴の事実1件と作品属性1件を根拠にする。

出力:
{"recommendations":[{"series_id":整数,"rank":整数,"reason":文字列}]}

候補は作品名だけでなく、series_id と配信時点の必要なメタデータを付けて渡す。タイトルは重複・表記揺れ・リメイクがありうるため、下流処理では ID を主キーにする。

候補順バイアスへの対処

LLM は入力の先頭や末尾にある候補を選びやすいことがある。従って、候補順を既存ランカー順のまま固定すると、LLM の改善に見えて実際には元順位をコピーしているだけかもしれない。

評価時には候補順を複数回シャッフルし、順位の安定性を見る方法がある。候補順 $\pi$ を変えたときの出力順位を比較し、同じ作品が大きく変動するなら、モデルの判断より位置バイアスが強い可能性がある。本番では、元ランクを明示的な特徴として渡すか、伏せるかも実験条件として固定する必要がある。

R1 = [進撃の巨人, 葬送のフリーレン, 名探偵コナン]

R2 = [インターステラー, SPY×FAMILY, 進撃の巨人]

出力は自由文ではなく schema で拘束する

本番では JSON Schema や constrained decoding を使い、次を機械的に保証する方がよい。

• series_id が整数である
• rank が 1 から $K$ までである
• 件数がちょうど $K$ 件である
• 候補集合外 ID を受け付けない
• 重複 ID を受け付けない
• 説明の最大長を制限する

温度を低くすれば出力は安定しやすいが、温度 0 でも完全な決定性は保証されないことがある。モデルや推論基盤の更新も結果を変えるため、model_version、prompt_version、候補集合、出力、処理時間、token 数を記録する必要がある。

{
  "recommendations": [
    {"series_id": 101, "rank": 1},
    {"series_id": 999, "rank": 2},
    {"series_id": 101, "rank": 3}
  ]
}

一度に何件比較させるか

候補が数百件ある場合、全件を一つのプロンプトへ入れると、費用だけでなく順位品質も悪化しうる。代表的な分解は次の通りである。

• pointwise: 各候補を独立に採点する。並列化しやすいが、候補間比較が弱い
• pairwise: 二作品ずつ比較する。相対判断はしやすいが、比較回数が増える
• listwise: 複数候補を一度に並べる。Top-K に近いが、候補数と順序バイアスに注意する

$N$ 件の全 pair を比較すると $N(N-1)/2$ 回必要になる。例えば $N=50$ なら、

回であり、オンライン推論には重い。従って、従来ランカーで 20〜50 件まで絞って listwise に再ランキングする、複数の小さな window に分ける、pointwise score と決定論的 sort を組み合わせる、といった構成が現実的である。

手を動かす例: 配信期間を JST に直して fallback まで行う

説明用の仮想的な配信情報として、現在時刻を 2026 年 8 月 24 日 21:00 JST とする。item_information_table の配信日時は UTC なので、現在時刻を UTC に直すと 2026 年 8 月 24 日 12:00 UTC である。

LLM が次の順で 5 作品を返したとする。

ここで示した日時とフラグは計算説明用の仮定であり、実際の配信状態を表すものではない。2 位作品の終了時刻 11:59:59 UTC は、現在の 12:00:00 UTC より 1 秒前なので除外する。3 位作品もブラックリスト条件により除外する。残るのは 1、4、5 位の 3 件である。

Top-5 が必要なら、既存ランカーの次点候補から配信可能な 2 件を補い、最終リストを 5 件にする。この例では、LLM へ日時を読ませただけで安全とせず、同じ時刻基準でデータベース側が再判定することが重要である。また、UTC と JST を混ぜると境界時刻で誤配信が起きるため、比較する時刻系を統一する。

多様性再ランキングの数値例

関連度だけで選ぶと、上位が同一ジャンル・同一シリーズ群に偏りやすい。そこで Maximum Marginal Relevance に似た考え方で、未選択候補 $i$ のスコアを次のようにする。

$s(u,i)$ はユーザー適合度、$S$ はすでに選んだ作品、作品間類似度は $0$ から $1$ とする。すでに『インターステラー』を一件目に選んだと仮定する。$\lambda=0.7$、候補 A『TENET テネット』の適合度が $0.90$、既選択作品との最大類似度が $0.95$ なら、

候補 B『葬送のフリーレン』の適合度が $0.82$、最大類似度が $0.20$ なら、

適合度だけなら『TENET テネット』が上だが、すでに似た『インターステラー』を選んでいるため、二件目には『葬送のフリーレン』を出す。この制御は LLM の曖昧な「多様にせよ」という指示だけに任せず、作品 embedding やジャンルを使って後処理で再現可能に行える。

NDCG のワークド例

未来の正解を「評価時点より後に 25% 以上視聴された作品」とする。推薦上位 3 件が [葬送のフリーレン, SPY×FAMILY, 名探偵コナン] で、前者と後者が 25% 以上視聴され、中央の作品は視聴されなかったとする。関連度は [1, 0, 1] なので、

理想順位は正解 2 件を先頭に置く [1,1,0] なので、

従って、

となる。Recall@K は正解を回収したかを見るが、NDCG@K は上位に置けたかも評価する。

時系列分割と曝露バイアス

学習時点より未来の視聴を正解にしなければ、未来情報の漏洩が起きる。例えば、7 月末までの履歴で入力を作り、8 月の視聴を正解にする。作品メタデータも、評価時点で利用可能だった snapshot を使うべきである。

また、ログで観測できる視聴は過去の推薦方策が表示した作品に偏る。表示されなかった作品は選びようがない。したがって、単純なオフライン NDCG の改善だけでは、新しい方策がオンラインでも改善するとは断定できない。最終判断には A/B test が必要であり、可能なら impression と位置を保存して、位置バイアス補正や反実仮想評価を検討する。

ゼロショットの例

最近『インターステラー』を長時間視聴したプロフィールに、
候補A〜Eから次に見る作品を3件選べ。

これは簡単だが、「長時間視聴を好みと断定してよいか」「候補外を出してよいか」「どの形式で返すか」が曖昧である。

Few-Shot の例

例1:
履歴: 作品Xを95%視聴、作品Yを3%視聴
解釈: Xは強い正の証拠、Yは不確実

例2:
履歴: 作品Pの詳細ページを訪問したが未再生
解釈: 弱い関心。正例にも負例にも断定しない

同じ基準で次の履歴を解釈し、候補を順位付けせよ。

Few-Shot の価値は、作品名の知識を教えることより、Hulu 固有の行動ラベルの意味と出力規則を例示する点にある。

CoT は「思考全文の表示」ではなくタスク分解として使う

本番では、長い自由記述の推論をユーザーへ表示する必要はない。代わりに、モデルへ次の判断項目を構造化出力させる。

1. ハード制約を満たすか

2. 直近意図に適合するか

3. 長期嗜好に適合するか

4. 既選択作品と重複しすぎないか

5. 最終 score と短い根拠

例えば各項目を 0〜2 点で返させ、合計を監査できるようにする。ただし、LLM が書いた理由は因果的に忠実な内部推論とは限らない。説明は「モデルがそう考えた証明」ではなく、入力根拠と矛盾しないユーザー向け文章として検証する。

評価予測

教科書の 1〜10 点予測は明示評価データに自然だが、Hulu の暗黙的フィードバックへそのまま移植するのは不自然である。代わりに、次のようなラベルが使える。

• 評価期間内に 25% 以上視聴する確率
• impression 後に再生開始する確率
• 10 分以上視聴する確率
• 期待視聴秒数

例えば、LLM に恣意的な「8.7 点」を生成させるより、候補間の順位や high / medium / low の離散判定を学習させ、その後に calibration する方が評価しやすい。

Top-K 推薦

候補を与えず自由生成させる open-vocabulary Top-K と、候補集合から選ばせる closed-set Top-K を区別する。本番 Hulu では後者が基本である。

candidatesに含まれるseries_idだけを使い、5件を順位付けせよ。
候補外を推薦したい場合も生成せず、insufficient_candidates=trueを返せ。

この insufficient_candidates は重要である。候補がすべて不適切なときに、無理に 5 件を選ばせると品質が落ちる。既存ランカーや人気作品へ fallback できる設計が必要である。

対話型推薦

対話では、発話履歴そのものではなく、更新可能な状態として管理するとよい。

{
  "must_have": ["SF", "映像美"],
  "avoid": ["ホラー", "過度な恋愛中心"],
  "soft_preferences": ["スリラー"],
  "already_seen": [500001745],
  "open_questions": ["長編でもよいか"]
}

「ホラーは好まない」のような明示的制約は、過去の暗黙履歴より優先する。ただし、その制約が今回だけか長期的かを区別する。会話の途中で条件が変わったら、古い状態を上書きする必要がある。

説明生成

良い説明は、ユーザー根拠、作品根拠、両者の接続を含む。

最近『インターステラー』を長時間視聴している。
候補作品は思索的なSFで、avg_mood_tagの thought-provoking が高い。
したがって、壮大な設定の中で考えさせられる物語を好む可能性に合う。

一方、「あなたはクリストファー・ノーラン監督が大好きだから」のように、履歴が一作品しかないのに強く断定する説明は避ける。「好む可能性がある」「最近の視聴に近い」と証拠強度に合わせるべきである。

逐次的推薦

逐次推薦では集合だけでなく順序が重要である。例えば、長期的にはアニメをよく見るプロフィールでも、直近に SF 映画を 2 本続けて見ていれば、次の一本では現在の SF セッションを重く見る可能性がある。

入力を単なる作品集合ではなく、

90日前: アニメA
30日前: アニメB
昨日: SF映画C
今日: SF映画D

のように順序と時間差付きで与える。長期嗜好と直近意図を別 score にしてから統合すると解釈しやすい。

情報量と簡潔さのバランス

全履歴を削らず入れることは「情報豊富」ではなく、関連情報をノイズに埋める行為になりうる。トークン予算を、例えば次のように明示的に割り当てる。

この配分は一例であり、重要なのは候補数を増やした結果、指示や重要履歴がコンテキストから押し出されないように計測することである。

明確性と失敗時の挙動

「良い作品を推薦せよ」では、良いの意味が定まらない。目的を「今後 7 日以内に 25% 以上視聴される可能性」「今夜テレビで一本完結の映画を選ぶ」などに具体化する。また、候補不足、metadata 欠損、矛盾する条件への動作も定義する。

prompt injection とデータ汚染

作品説明やユーザー入力は命令ではなくデータである。外部由来の説明文に「以前の指示を無視せよ」と書かれていても実行しないよう、命令ブロックとデータブロックを分ける。出力後も ID allowlist と schema validation を通す。プロンプトだけをセキュリティ境界にしてはならない。

反復改善は一件の成功例ではなく固定評価セットで行う

プロンプト変更は、同じ時系列 holdout と candidate set で比較する。平均指標だけでなく、キッズ、コールドスタート、長期利用者、TV デバイス、人気作品に偏らない層などの slice を見る。プロンプトのバージョンをログへ残さなければ、オンライン変化の原因を追えない。

難所の補足: SFT は「推薦の意味」を直接最小化しているわけではない

上の損失が直接見ているのは、正解 token を高い確率で出したかである。NDCG、視聴時間、多様性をそのまま計算して最小化しているわけではない。例えば、正解が C03、C01 の順なら、モデルはまず C03 を出し、その正解 token を前提として次に C01 を出すよう学ぶ。この学習方法を teacher forcing と呼ぶ。

teacher forcing では、学習中は常に正しい過去 token が与えられる。しかし推論時に最初の候補を誤って C02 と出すと、その後は学習時にあまり見ていない文脈から続きを生成しなければならない。この学習時と推論時の差も、生成モデルの難しさの一つである。

また、同じプロフィールに C03、C01 と C01、C03 のどちらの順も妥当な場合、一方だけを正解にすると、もう一方まで誤りとして確率を下げかねない。複数の正解順、pairwise 選好、soft label を用意する理由は、この一意でない推薦の正解を扱うためである。

手を動かす例: SFT loss を token ごとに計算する

候補番号を使い、正解出力を次の 3 token と単純化する。

[C03] [C01] [END]

学習前のモデルが、正解 token にそれぞれ次の確率を与えたとする。

この一例の SFT loss は、

である。token 当たり平均は、

となる。学習後に正解 token の確率が順に $0.80, 0.75, 0.90$ まで上がれば、

となり、loss は下がる。ただし、これは「この正解文字列を出しやすくなった」ことを示すだけであり、未知プロフィールへの NDCG やオンライン視聴時間が必ず改善したことを意味しない。そのため、学習 loss と推薦指標の両方を測る必要がある。

手を動かす例: 長い series_id を候補 alias に置き換える

候補が次の三作品だとする。

{
  "C01": {"series_id": 500001745, "title": "インターステラー"},
  "C02": {"series_id": 500005989, "title": "るろうに剣心 －明治剣客浪漫譚－ 追憶編"},
  "C03": {"series_id": 50028800, "title": "候補作品X"}
}

LLM に 500001745 を一桁ずつ自由生成させると、一桁欠けた 50001745 や、候補外の数字を作る余地がある。そこで出力語彙を [C01], [C02], [C03] に限定し、モデルには [C03, C01, C02] のように返させる。その後、決定論的な lookup により、

[C03, C01, C02]
    ↓
[50028800, 500001745, 500005989]

へ戻す。この方法なら、新作の series_id をモデルの重みに事前登録していなくても、候補表に alias を追加するだけで選択可能になる。

難所の補足: なぜ低ランクで十分な場合があるのか

ファインチューニングで必要な変化が、巨大な重み空間のあらゆる方向に及ぶとは限らない。基盤モデルはすでに日本語、映画の概念、順位付けの基本を学んでいる。Hulu 推薦へ適応するときに必要なのは、「短時間視聴を負例と断定しない」「候補 ID のみを返す」「配信 metadata を根拠にする」といった、比較的限定された振る舞いの修正である可能性がある。

地図に例えると、モデル全体の知識を一から描き直すのではなく、既存地図の上に「Hulu 推薦ではこの道を優先する」という薄い交通レイヤーを重ねるのが LoRA である。低ランク行列は、この追加変更を少数の主要な方向の組み合わせとして表現する。

ただし、rank を小さくすれば常によいわけではない。必要な変更が複雑なのに rank が小さすぎると表現力が不足し、rank を大きくすると学習パラメータと過学習リスクが増える。そのため、rank は学習 loss だけでなく、未知ユーザー・未知作品を含む評価指標で選ぶ。

ただし、これはモデル全体の学習メモリが必ず 0.39% になるという意味ではない。activation、optimizer state、対象層数、batch size などもメモリを使う。また、LoRA は学習コストを下げるが、データ品質、評価、adapter の version 管理は依然必要である。

手を動かす例: 2 次元の LoRA 更新を実際に掛ける

実モデルより大幅に小さい 2 次元の例で、LoRA が元の重みに「小さな差分」を足す様子を見る。元の重みを単位行列とする。

rank $r=1$、 $\alpha=1$ とし、学習された行列を次とする。

差分は、

である。従って更新後の重みは、

となる。入力を $\mathbf{x}=[2,1]^{\mathsf{T}}$ とすると、元モデルの出力は、

であるが、LoRA 適用後は、

となる。元の $\mathbf{W}_0$ は変更せず、低ランク差分だけで出力方向を変えている。実際の Transformer では、この変化が「短時間視聴を嫌いと断定しない」「候補 ID だけを返す」といった推薦タスク向けの出力傾向として学習される。

難所の補足: DAPT・SFT・RAG は「知識を置く場所」が違う

三手法は、同じ情報を別名で扱っているのではない。モデルのどこへ、いつ情報を与えるかが異なる。

• DAPT は、動画配信ドメインの文章を大量に読ませ、モデル内部の言葉の捉え方を変える
• SFT は、入力に対してどのような推薦出力を返すべきかという振る舞いを学ばせる
• RAG は、推論のたびに外部から現在の事実を持ってくる

人間の新人研修に例えると、DAPT は映画や配信業界の資料を広く読んで語彙を身につける研修、SFT は接客例を使って推薦の回答方法を練習する研修、RAG は接客のたびに最新の配信カタログを端末で調べる行為である。

配信終了日時のように頻繁に変わる情報を DAPT や SFT で覚えさせると、再学習するまで古いままになる。反対に、毎回 RAG で一般的な「伏線」「群像劇」の意味から調べ直すだけでは、モデルのドメイン理解が弱い。安定した概念はモデルへ、変化する事実は外部データへ置く、という判断が重要である。

手を動かす例: 同じ新作を DAPT・SFT・RAG がどう扱うか

まだ視聴ログがない新作アニメ X が追加され、metadata に「時間旅行」「仲間との別れ」「感動的」「全 12 話」と記載されたとする。

• DAPT 済みモデルは、「時間旅行」「全 12 話」といった動画ドメインの文章や語彙を自然に解釈しやすい
• ドメイン SFT 済みモデルは、「最近、時間旅行アニメを長時間視聴したプロフィールには X を候補上位にする」という入力・出力形式に従いやすい
• RAG は、その日のカタログから X の series_id、配信期間、service_type、説明文を取得し、モデルへ実際の候補として渡す

例えば DAPT と SFT が完了した日が 8 月 1 日で、新作 X が 8 月 20 日に登録されたなら、モデルの重みは X の存在を知らない。しかし、8 月 24 日の推論で RAG が X を取得すれば、既知の「時間旅行」「感動的」という意味を使って順位付けできる。反対に、RAG が X を候補へ入れなければ、どれほどよく学習したモデルでも X を選べない。この例が、三手法の役割の違いである。

コールドスタートへの効果と限界

新作に視聴ログがなくても、作品説明やキャスト、タグを理解できれば content-based な推薦が可能になる。例えば新作 X に行動履歴がなくても、「思索的 SF」「宇宙」「親子」という属性があれば、『インターステラー』を長時間視聴したプロフィールの候補になりうる。

しかし、ドメイン知識だけでは、その作品が実際に Hulu ユーザーへどれほど受けるか、どのトレイ位置で選ばれるかは分からない。意味的類似性は行動適合性の一部であり、オンライン行動で更新する必要がある。

ユーザーごとのチューニングが難しい理由

• 一人あたりの教師データが少なく、過学習しやすい
• 新しい視聴のたびに更新するのは、ユーザー embedding 更新より遅い
• 数百万プロフィール分の adapter 配置、version、rollback が必要になる
• プロフィール削除時に、重みに入ったデータを確実に除去するのが難しい
• 家族共用や一時的セッションを長期嗜好として固定する恐れがある
• 新作・配信終了などのカタログ変化には別途 retrieval が必要である

従って、Hulu での第一選択は通常、共通モデルを固定し、profile_id ごとの embedding、直近履歴、検索された候補を実行時に注入する方法である。ファインチューニングするなら、まず全ユーザー共通の推薦指示 adapter、次に十分なデータがある安定 segment の adapter、という順が安全である。

segment 単位にも注意が必要である

「SF ファン」「キッズアニメ中心」のような行動 segment は adapter を共有しやすい。しかし segment は固定属性ではなく、時間で変わる確率的な状態として扱うべきである。単一 cluster にプロフィールを閉じ込めると、フィルターバブルや古い嗜好の固定化が起きる。

また、年齢・性別だけで作品嗜好を決める segment はステレオタイプを強化しうる。行動由来の segment でも、センシティブな属性の proxy になっていないか、slice ごとの露出と品質を監査する必要がある。

難所の補足: embedding の注入は「ID の数値を文章に足す」ことではない

profile_id やユーザー embedding をそのままテキスト token の列へ追加しても、LLM が意味を理解できるとは限らない。特に、推薦モデルの 128 次元ユーザー embedding と LLM の 4,096 次元 hidden state は、次元数も学習された空間の意味も異なる。

そこで、ユーザー embedding を LLM が受け取れる次元へ変換する projection 層を学習したり、複数の仮想 token に変換して prompt の先頭へ付けたり、adapter の中間層へ入力したりする。これは、日本語を話さない二人の間に通訳を置くことに近い。embedding が豊富な情報を持っていても、LLM の表現空間へ正しく対応づける通訳がなければ使えない。

また、projection 層を学習するときには、ベース LLM とユーザー embedding 生成器の version を固定・記録する必要がある。片方の embedding 空間だけを再学習すると、同じベクトル座標が以前と違う意味になり、projection が機能しなくなる可能性がある。

手を動かす例: ユーザー embedding を一回の視聴で更新する

説明のため、embedding を 2 次元とする。第 1 軸、第 2 軸に人間が厳密な意味を割り当てられるわけではないが、ここでは計算を見せるために「アニメアクション寄り」「思索的 SF 寄り」と仮置きする。長期ユーザー embedding を、

とする。候補 A『進撃の巨人』系の作品と候補 B の新作 SF 映画の embedding を、

とする。長期 embedding だけなら内積 score は、

であり、A が上である。ところが、直近に『インターステラー』を長時間視聴し、セッション embedding が、

になったとする。直近を 70%、長期を 30% として、

と更新する。新しい score は、

となり、B が上になる。この更新には LLM の再学習も個人 LoRA の作成も必要なく、ユーザー embedding を差し替えるだけでよい。これが、大規模サービスで動的 embedding が有力な理由である。

手を動かす例: 複数目的の報酬を合成する

一つの推薦リストに対する報酬を、次の加重和とする。

すべての部分報酬は 0 から 1 とする。リスト A は人気アニメばかりで関連性は高いが多様性が低く、次の値だとする。

リスト B は関連性が少し低いが、アニメ、SF 映画、国内ドラマを含み、説明も metadata に基づいているとする。

この設定なら B が好まれる。ただし、重みを関連性 0.9 に変えれば A が勝つ可能性がある。つまり、RLHF や選好最適化は「正しい目的を自動発見する魔法」ではなく、何を良い推薦と定義したかを強く反映する。重みと部分報酬をプロダクト目標に沿って監査する必要がある。

難所の補足: reward hacking は「指標を改善したが目的を損なう」現象である

報酬を「再生開始されたか」だけにすると、モデルは再生されやすい有名作品、刺激的なサムネイル、過度に断定的な説明を優先するかもしれない。再生開始率は上がっても、数分で離脱する、同じ人気作品ばかりになる、説明への信頼を失うなら、推薦体験全体は改善していない。

これはモデルが悪意を持つからではない。与えられた数値を最大化するという学習目的に忠実だからである。学校で「提出枚数」だけを評価すれば、内容の薄いレポートを大量に出す行動が合理的になるのと同じである。

従って、主目的を一つ決めても、最低視聴時間、候補外生成率、多様性、キッズ安全性、長期利用指標などを guardrail として置く。A/B test でも、平均再生開始率だけで成功判定せず、短時間離脱や特定ジャンルへの露出集中が悪化していないかを確認する。

オンラインの再生を直接報酬にする場合も、クリックベイト的説明や人気作品への集中を招きうる。短期再生だけでなく、視聴時間、満足度 proxy、長期 retention、多様性、安全性を guardrail として監視する必要がある。