2.1.1 コンテンツ理解の詳解

位置づけ

推薦システムにおける コンテンツ理解 とは、推薦対象アイテムを機械学習モデルが扱いやすい形に変換する工程である。Hulu のような動画配信サービスで言えば、作品タイトル、ジャンル、サブジャンル、説明文、キャスト、監督、制作国、公開年、配信期間、視聴時間、タグ、AI が推定した mood tag や動画 fingerprint などを使って、各作品が「何であるか」を表現する処理である。

推薦はしばしば「ユーザーが何を好むか」を当てる問題として説明される。しかし、ユーザー理解だけでは不十分である。そもそも推薦候補となる作品をシステムが理解できていなければ、次のような判断ができない。

「インターステラー」と「TENET」は同じ監督の SF 映画として近いのか
「名探偵コナン」の映画版とテレビシリーズのエピソードを同じシリーズ嗜好として扱うべきか
子ども向けプロフィールに対して、暴力性や年齢制限の強い作品を下げるべきか
視聴済み作品と似ているが、同じ作品ばかりにならないように少し違う候補を混ぜるべきか
TVOD 作品を SVOD 作品と同じランキング面に出してよいのか

つまり、コンテンツ理解は「アイテム側の特徴量設計」であると同時に、検索、候補生成、ランキング、フィルタリング、説明、在庫分析、品質管理の基盤である。

Hulu のデータカタログに照らすと、中心になるテーブルは item_information_table である。このテーブルには、series_id、series_title_ja、service_type、genre、sub_genre、sockets_tag、sentence、description、casts、film_directors、countries_of_origin、premiere_year、video_duration、avg_mood_tag、avg_fingerprint などが含まれる。これらはすべてコンテンツ理解の入力または出力になりうる。

一方、unique_viewed_series は、プロフィールごとに 25% 以上視聴したシリーズを保持する暗黙的フィードバックのテーブルである。これは「ユーザーが何を見たか」を表す。コンテンツ理解は、この視聴履歴を「どのような内容の作品を見たか」に変換するためにも使われる。

図 1: コンテンツ理解は作品情報を数値化するだけでなく、候補生成、ランキング、品質制御へ同じ作品理解を供給する中核モジュールである。

なぜ暗黙的フィードバック推薦で重要なのか

Hulu の主なフィードバックはレーティングではなく、視聴の有無である。このとき、unique_viewed_series に記録されるのは「25% 以上視聴した」という事実であり、「どれくらい好きだったか」そのものではない。

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

SF 映画
宇宙を舞台にした作品
クリストファー・ノーラン監督作品

行動ログだけを見ると、単に 3 つの series_id が並んでいるだけである。しかしコンテンツ理解によって、それらの作品から「SF」「宇宙」「知的」「壮大」「サスペンス」「特定監督」「2010 年代の洋画」といった属性を抽出できる。すると、そのプロフィールの嗜好を「作品 ID の集合」ではなく、「作品特徴の分布」として扱える。

これは暗黙的フィードバックで特に重要である。なぜなら、暗黙的フィードバックには次の曖昧さがあるからである。

視聴したからといって、必ず好きだったとは限らない
視聴しなかったからといって、嫌いだったとは限らない
表示されなかった作品は、選ばれる機会すらなかった可能性がある
人気作品は露出が多いため、視聴ログが嗜好以上に露出バイアスを含む
家族共有プロフィールでは、複数人の嗜好が混ざることがある

この曖昧さを補うために、作品の内容を理解した特徴量が必要になる。視聴履歴が少ないユーザーでも、数本の視聴作品からジャンル、雰囲気、出演者、制作国、年代、尺、シリーズ性などを集約すれば、ある程度の嗜好推定が可能になる。

基本構造

コンテンツ理解は、大きく次の 3 段階に分けられる。

アイテム識別
メタデータ抽出
特徴量エンコーディング

それぞれは独立した作業ではなく、下流の推薦モデルで一貫して使えるように接続される。

図 2: コンテンツ理解は「ID を決める」「情報を整える」「モデル用の数値へ変換する」という順に考えると整理しやすい。

1. アイテム識別

アイテム識別とは、推薦対象の単位を定義し、それぞれに一意な ID を割り当てる処理である。Hulu では series_id が重要である。例えば、テレビアニメの第 1 話、第 2 話、第 3 話があっても、推薦や視聴履歴の集計では同じシリーズとして扱いたい場合がある。そのため、シリーズ全体を識別する series_id が使われる。

ここで重要なのは、推薦対象の粒度である。

シリーズ単位で推薦するのか
エピソード単位で推薦するのか
シーズン単位で推薦するのか
映画とシリーズを同じ候補集合に入れるのか
SVOD と TVOD を同じ候補集合に入れるのか

粒度を誤ると、推薦品質が大きく落ちる。

例えば、ユーザーが「名探偵コナン」の第 1 話を見た直後に、第 2 話ではなく別の無関係な推理映画を推薦するのがよいとは限らない。連続視聴の文脈では次話推薦が重要である。一方、ホーム画面の「あなたへのおすすめ」では、同じシリーズのエピソードを大量に並べるより、シリーズ代表として 1 つにまとめた方がよいこともある。

つまり、コンテンツ理解の最初の問いは「この作品は何か」だけではない。「推薦システム上、何を 1 アイテムとして扱うべきか」も含まれる。

2. メタデータ抽出

メタデータ抽出とは、作品に付随する情報を構造化する処理である。Hulu の item_information_table には、すでに多くのメタデータが存在する。

代表的なものは次の通りである。

series_title_ja: 作品タイトル
service_type: SVOD または TVOD
contents_provider_name: コンテンツ提供者
publish_start_at, publish_end_at: 配信開始・終了日時
media_type: 映画、シリーズなどの種別
genre, sub_genre: ジャンル、サブジャンル
sockets_tag: 「アメリカ制作」「ハリウッド映画」「壮大な世界観」などのタグ
sentence: キャッチコピーや短い訴求文
description: 作品説明文
producers, film_directors, writers, casts: 制作関係者や出演者
countries_of_origin: 制作国
premiere_year: 公開年
rating_name, kids_mature_flg: レーティングやキッズ関連情報
video_duration: 作品尺
avg_mood_tag: 映像内容から推定された雰囲気スコア
avg_fingerprint: 映像内容から推定された埋め込み
is_blacklist: 推薦対象から除外すべき作品かどうか

この段階でのポイントは、ただ列を読むだけではなく、推薦に使える品質まで整えることである。

例えば、casts が "マシュー･マコノヒー|アン･ハサウェイ|ジェシカ･チャステイン" のような文字列で入っている場合、そのままではモデルが扱いにくい。人物単位に分解し、表記揺れを吸収し、可能なら人物 ID に正規化する必要がある。

また、awards は ||第87回アカデミー賞|視覚効果賞受賞||... のように複雑な区切りを持つ。これも「賞名」「部門」「受賞かノミネートか」に分解できれば、作品の権威性や話題性を表す特徴量になる。

3. 特徴量エンコーディング

特徴量エンコーディングとは、構造化されたメタデータや説明文を、検索や学習に使える数値表現に変換する処理である。

単純な例として、ジャンルを one-hot ベクトルにする方法がある。

\mathbf{x}_{i,\text{genre}} = \begin{bmatrix} 1 & 0 & 0 & 0 \end{bmatrix}

これは作品 $i$ が「洋画」である、というようなカテゴリ情報を表す。しかし、one-hot だけでは「SF」と「ファンタジー」が比較的近い、「恋愛」と「ラブコメ」は近い、といった関係を表しにくい。

そこで、作品全体を dense embedding として表現する。例えば、作品 $i$ のコンテンツ埋め込みを $\mathbf{c}_i \in \mathbb{R}^d$ とする。ユーザー $u$ が視聴した作品集合を $I_u$ とすると、単純なユーザープロファイルは次のように作れる。

\mathbf{p}_u = \frac{1}{|I_u|} \sum_{i \in I_u} \mathbf{c}_i

これは「ユーザーが見た作品の平均的な内容ベクトル」である。さらに、最近見た作品を重くするなら、視聴時刻に応じた重み $w_{u,i}$ を使う。

\mathbf{p}_u = \frac{\sum_{i \in I_u} w_{u,i} \mathbf{c}_i}{\sum_{i \in I_u} w_{u,i}}

候補作品 $j$ との近さは、例えば cosine 類似度で計算できる。

\text{sim}(u,j) = \frac{\mathbf{p}_u^{\mathsf{T}} \mathbf{c}_j} {\|\mathbf{p}_u\| \|\mathbf{c}_j\|}

このようにすれば、過去に見た作品と内容的に近い作品を候補として取り出せる。

Hulu の avg_fingerprint は、映像そのものから推定された embedding であるため、この用途に近い。すべての作品に付与されているわけではない点には注意が必要だが、説明文やタグだけでは捉えにくい映像的な雰囲気を補える可能性がある。

図 3: 暗黙的フィードバックでは、視聴した作品 ID をそのまま使うだけでなく、作品ベクトルを集約して「どのような内容を見たか」に変換する。

トピック分類

トピック分類とは、作品をあらかじめ定義された分類体系に割り当てる処理である。教科書では IAB のような汎用的なコンテンツ分類体系が例に出ているが、Hulu では動画配信向けの分類体系が重要である。

例えば、次のような階層を考える。

映画
国内ドラマ
海外ドラマ
アニメ
バラエティ
ドキュメンタリー
キッズ
スポーツ
音楽
ニュース

さらに、映画の下には次のようなサブトピックがある。

SF
アクション
サスペンス
ホラー
恋愛
コメディ
ファミリー
アニメ映画

トピック分類は、検索や推薦で直接使える。例えば「SF をよく見るプロフィール」には SF 作品を多めに出せる。しかし、単に genre と sub_genre を使うだけでは不十分な場合がある。

理由は次の通りである。

ジャンル粒度が粗すぎる
作品が複数ジャンルにまたがる
メタデータの付与基準が時期や提供元によって揺れる
ユーザーの嗜好はジャンル名より細かいことが多い

例えば「SF」が好きなユーザーでも、宇宙冒険 SF、ディストピア SF、タイムリープ SF、怪獣 SF、ロボットアニメでは好みが分かれる。トピック分類は、ジャンルより細かい意味構造を付与することで、この差を扱いやすくする。

LLM を使う場合、作品説明文やタグから次のようなトピックを抽出できる。

宇宙探索
人類存亡
タイムトラベル
家族愛
犯罪捜査
学園生活
医療現場
料理対決

これらをマルチラベル分類として付与すると、推薦モデルは「SF」だけでなく「宇宙探索」「人類存亡」「知的サスペンス」といった細かい嗜好を学習できる。

エンティティ抽出

エンティティ抽出とは、説明文やメタデータから人物、作品名、組織、場所、キャラクター、シリーズ名などを取り出す処理である。

Hulu では、すでに logica_people_ids、logica_cast_ids、logica_producer_ids、logica_film_director_ids などの ID が存在する。これは非常に重要である。文字列としての「クリストファー･ノーラン」と、別表記の「Christopher Nolan」や中黒違いの「クリストファー・ノーラン」を同一人物として扱うには、ID による正規化が必要だからである。

エンティティ抽出が推薦に効く典型例は、人物嗜好である。

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

クリストファー・ノーラン監督作品
アン・ハサウェイ出演作品
ワーナー系の洋画

この場合、単にジャンルを見るだけでは「SF が好き」と解釈されるかもしれない。しかし実際には、監督、俳優、制作スタイルへの嗜好が強い可能性がある。エンティティを抽出しておけば、「このユーザーはノーラン作品をよく見る」「この俳優が出ている作品に反応しやすい」といった特徴を作れる。

エンティティ抽出では曖昧性解消が重要である。教科書の Apple の例と同じで、動画ドメインにも曖昧性がある。

同姓同名の俳優
同じタイトルのリメイク作品
映画版とドラマ版がある作品
日本語表記、英語表記、略称、旧題の混在
シリーズ名とエピソード名の混同

この曖昧性を解消できないと、「見当違いな同名作品」や「別人の出演作」を推薦してしまう。

感情分析と雰囲気理解

教科書では、感情分析はレビューやコメントからポジティブ、ネガティブな感情を抽出するものとして説明されている。Hulu の推薦では、レビューだけでなく、作品の雰囲気理解としても考えるとよい。

データカタログには avg_mood_tag がある。例えば、ある作品に次のようなスコアが付いている。

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

これは、作品を「ジャンル」ではなく「視聴体験の質感」で表す特徴である。

同じ SF でも、雰囲気は大きく違う。

明るく爽快な SF
暗く重い SF
家族愛が中心の SF
難解で思索的な SF
アクション中心の SF
ホラー寄りの SF

ユーザーの満足度はジャンルだけでは決まらない。夜にリラックスしたいユーザーには、重く難解な作品より軽い作品が合うかもしれない。週末にじっくり映画を見るユーザーには、長尺で思索的な作品が合うかもしれない。

したがって、感情分析や雰囲気理解は、次のような用途で役立つ。

ムードベース推薦
「泣ける」「スカッとする」「考えさせられる」などの棚生成
同ジャンル内の細かい並べ替え
視聴時間帯や曜日に応じたランキング調整
キッズやファミリー向けの安全性制御

重要フレーズ抽出

重要フレーズ抽出とは、説明文やタグから作品を特徴づける短い語句を取り出す処理である。

例えば description に次のような内容があるとする。

「地球の寿命は尽きかけていた。居住可能な新たな惑星を探すという人類の限界を超えたミッションに選ばれたのは、まだ幼い子供を持つ元エンジニアの男。」

ここからは、次のような重要フレーズを抽出できる。

地球の寿命
居住可能な惑星
人類存続
宇宙ミッション
元エンジニア
親子関係

これらは検索にも推薦にも効く。例えば、ユーザーが「宇宙」「親子」「感動」系の作品をよく見ているなら、単に SF であること以上に、「宇宙ミッション」と「親子関係」を持つ作品を高く評価できる。

重要フレーズは、特にロングテール作品で重要である。人気作品は視聴ログが大量にあるため協調フィルタリングで学習しやすい。一方、視聴ログが少ない作品は、内容情報がなければ推薦されにくい。説明文やタグから重要フレーズを抽出しておけば、まだ視聴ログが少ない作品でも、似た内容を好むユーザーに届けやすくなる。

コンテンツ品質評価

コンテンツ品質評価とは、推薦対象として作品やメタデータが適切かを評価する処理である。動画配信では、作品そのものの品質だけでなく、メタデータ品質、配信可否、安全性、ユーザー期待との整合性も含まれる。

Hulu のデータでは、次のような列が品質制御に関係しうる。

publish_start_at, publish_end_at: 配信期間内か
is_coming_soon: 近日公開か
is_live: ライブ作品か
rating_name: 年齢レーティング
kids_mature_flg: キッズ向け制御
is_blacklist: ブラックリスト対象か
service_type: SVOD か TVOD か
description: 説明文の有無や品質
avg_fingerprint: 埋め込みの有無
avg_mood_tag: mood tag の有無

推薦では、関連性が高いだけでは不十分である。例えば、配信終了済みの作品、ブラックリスト作品、キッズプロフィールに不適切な作品、SVOD ユーザーに突然 TVOD 課金作品ばかり出すような推薦は、モデルスコアが高くても望ましくない。

そのため、ランキング前後にビジネスルールや品質フィルタを入れる必要がある。

典型的には次のような制約が入る。

配信期間内の作品だけを候補にする
is_blacklist = true の作品を除外する
キッズプロフィールでは年齢不適合の作品を除外または降格する
TVOD 作品は明示的な枠や文脈がある場合に限定する
同一シリーズや同一ジャンルの出しすぎを抑える
視聴済み作品を再推薦しない、または継続視聴枠に分離する

このような制約は、単なる後処理ではなく、コンテンツ理解の一部である。なぜなら、作品が「推薦可能な状態か」を理解する必要があるからである。

古典的なテキスト表現

教科書では、BoW と TF-IDF が従来手法として紹介されている。

BoW は、文書を単語の出現回数ベクトルとして表す。例えば、作品説明文から語彙を作り、各作品を次のようなベクトルで表す。

\mathbf{x}_i = \begin{bmatrix} \text{count}(\text{宇宙}) & \text{count}(\text{恋愛}) & \text{count}(\text{刑事}) & \text{count}(\text{家族}) \end{bmatrix}

BoW の利点は単純で解釈しやすいことである。一方、語順や文脈は失われる。

例えば、次の 2 文は BoW では似た表現になりやすい。

「家族を守るために戦う」
「家族を失った男が復讐する」

どちらも「家族」「戦う」といった語が出るが、視聴体験はかなり違う。

TF-IDF は、単語の出現頻度を文書全体での珍しさによって補正する手法である。作品 $i$ における語 $t$ の TF-IDF は概念的に次のように書ける。

\text{tfidf}(t,i) = \text{tf}(t,i) \cdot \log \frac{N}{\text{df}(t)}

ここで、 $N$ は全作品数、 $\text{df}(t)$ は語 $t$ を含む作品数である。多くの作品に出てくる一般語は重みが下がり、特定作品群にだけ出る語は重みが上がる。

動画推薦では、TF-IDF は今でも使い道がある。

説明文ベースの類似作品検索
重要語句抽出のベースライン
LLM や embedding の品質確認
タグ候補の生成
コールドスタート作品の初期特徴量

ただし、TF-IDF だけでは意味的な近さを扱いにくい。「宇宙」と「惑星探索」、「刑事」と「捜査官」、「恋愛」と「ラブストーリー」が近いことを自然には学習しない。

単語埋め込み

Word2Vec や GloVe は、単語を dense vector として表す手法である。BoW や TF-IDF と違い、意味的に近い単語が近いベクトルになることを期待する。

例えば、理想的には次のような近さが表現される。

「宇宙」と「惑星」
「刑事」と「捜査」
「恋愛」と「ラブストーリー」
「アニメ」と「声優」

ただし、単語埋め込みだけでは作品全体の意味を表すには工夫が必要である。説明文に含まれる単語ベクトルを平均するだけでは、作品のストーリー、雰囲気、対象年齢、ジャンル横断的な特徴を十分に表現できないことが多い。

そのため、現在は文埋め込み、マルチモーダル埋め込み、LLM を使った構造化抽出がよく使われる。

LLM ベースのコンテンツ理解

教科書の重要な主張は、従来はタスクごとに別々のモデルが必要だったが、LLM によって多くのコンテンツ理解タスクを統一的に扱えるようになった、という点である。

従来は、次のように別々の仕組みを作ることが多かった。

トピック分類には Naive Bayes や SVM
重要語句抽出には TF-IDF や TextRank
感情分析には専用の分類器
品質判定にはルールベースや別の分類モデル
エンティティ抽出には固有表現抽出モデル

LLM を使うと、同じ入力から複数の構造化情報をまとめて抽出できる。

図 4: LLM は自由文を推薦用の構造化特徴に変換できるが、固定スキーマ、許可ラベル、ID 照合を入れて出力を制御する必要がある。

例えば、作品説明文、タグ、キャスト、監督、ジャンルを入力し、次の JSON を生成させる。

{
  "topics": ["宇宙探索", "人類存亡", "親子関係"],
  "moods": ["思索的", "感動的", "緊張感がある"],
  "target_audience": ["SF映画好き", "重厚な洋画好き"],
  "safety_notes": ["キッズ向けではない可能性"],
  "key_phrases": ["居住可能な惑星", "人類の限界を超えたミッション"],
  "entity_candidates": {
    "directors": ["クリストファー・ノーラン"],
    "casts": ["マシュー・マコノヒー", "アン・ハサウェイ"]
  }
}

このような出力は、推薦の特徴量として使えるだけでなく、推薦理由にも使える。

例えば、ホーム画面で次のような説明を付けられる。

「壮大な宇宙 SF が好きなあなたへ」
「ノーラン監督作品を見た人におすすめ」
「考えさせられるヒューマンドラマ」

ただし、LLM 出力をそのまま信用するのは危険である。推薦システムに組み込むには、次のような対策が必要である。

出力スキーマを固定する
許可された分類ラベルから選ばせる
人物名や作品名は ID マスタと照合する
hallucination を検出する
高価な LLM 推論はオフラインでバッチ化する
重要な安全性判定はルールや監査済みモデルと併用する
モデル変更時に特徴量分布が急変しないか監視する

候補生成での使い方

推薦システムは通常、全作品を直接ランキングしない。まず候補生成で数百万件または数十万件の作品から数百件程度に絞り、その後ランキングする。

コンテンツ理解は候補生成で強い効果を持つ。

代表例は、コンテンツ類似候補である。ユーザーが見た作品の embedding と近い作品を ANN 検索で取得する。

\text{candidates}(u) = \text{TopK}_{j \in \mathcal{I}} \ \text{sim}(\mathbf{p}_u, \mathbf{c}_j)

ここで $\mathcal{I}$ は推薦可能な作品集合である。

この方法は、次の場面で特に有効である。

視聴履歴が少ない新規ユーザー
視聴ログが少ない新作やロングテール作品
協調フィルタリングで拾いにくいニッチ嗜好
説明文やタグが豊富な作品
mood や映像 fingerprint が有効な作品

ただし、コンテンツ類似だけに頼ると、似た作品ばかりになる。これを content bubble と呼んでもよい。ユーザーが SF を 1 本見たら SF ばかり出る、アニメを見たらアニメばかり出る、といった状態である。

そのため、実運用では複数の候補生成器を混ぜる。

コンテンツ類似候補
協調フィルタリング候補
人気作品候補
新着作品候補
継続視聴候補
トレンド候補
編集部キュレーション候補
TVOD 促進候補

コンテンツ理解は、このうち複数の候補生成器で使われる。

図 5: 全作品を一度にランキングするのではなく、候補生成で大きく絞り、ランキングと品質制御で表示枠に載せる作品を決める。

Hulu のデータで考える具体例

item_information_table の例では、「インターステラー」に次のような情報がある。

genre: 洋画
sub_genre: SF
contents_provider_name: Warner Bros.
countries_of_origin: US
premiere_year: 2014
film_directors: クリストファー・ノーラン
casts: マシュー・マコノヒー、アン・ハサウェイ、ジェシカ・チャステインなど
sockets_tag: アメリカ制作、ハリウッド映画、研究者、壮大な世界観、超大作、感動的、知的な
description: 地球の寿命、人類存続、宇宙ミッション、親子関係などを含む
avg_mood_tag: emotional、inspiring、intense、melancholic、thought-provoking などが高い
avg_fingerprint: 映像内容に基づく embedding

この作品から作れるコンテンツ特徴は多い。

ジャンル特徴: 洋画、SF
人物特徴: ノーラン、マコノヒー、ハサウェイ
地域特徴: US
年代特徴: 2010 年代
雰囲気特徴: 感動的、知的、思索的、緊張感
物語特徴: 宇宙探索、人類存続、親子関係
ビジネス特徴: SVOD/TVOD、配信期間、提供元
品質制御特徴: ブラックリスト、年齢制限、キッズ適合性

これを視聴履歴と結び付けると、次のような推論ができる。

同じ監督の作品を推薦する
宇宙 SF を推薦する
感動的で思索的な洋画を推薦する
長尺映画をよく見るユーザーに優先する
短時間視聴が多いユーザーには映画ではなく関連する短尺コンテンツを優先する
キッズプロフィールでは年齢制限や雰囲気を考慮して抑制する

このように、コンテンツ理解は単なる「タグ付け」ではなく、推薦ロジック全体に効くアイテム表現の設計である。

協調フィルタリングとの関係

古典的な協調フィルタリングは、ユーザーとアイテムの相互作用行列を使う。暗黙的フィードバックでは、例えば視聴があれば $r_{u,i} = 1$ 、観測されていなければ $r_{u,i} = 0$ と置くことがある。

ただし、未観測の $0$ は「嫌い」ではない。単に見ていないだけである。そのため、暗黙的フィードバックでは信頼度を別に置くことが多い。

例えば、観測値 $p_{u,i}$ と信頼度 $c_{u,i}$ を次のように定義する。

p_{u,i} = \begin{cases} 1 & \text{if user } u \text{ watched item } i \\ 0 & \text{otherwise} \end{cases}

c_{u,i} = 1 + \alpha r_{u,i}

ここで $r_{u,i}$ は視聴回数や視聴時間などの強さ、 $\alpha$ は信頼度の増幅係数である。

協調フィルタリングは「同じ作品を見たユーザーは似ている」という情報を使う。一方、コンテンツ理解は「作品そのものが似ている」という情報を使う。両者は競合ではなく補完関係にある。

協調フィルタリングが得意なことは次である。

大量ログから予想外の関連を学習する
タグや説明文に表れない嗜好を拾う
実際のユーザー行動に基づくため強い

コンテンツ理解が得意なことは次である。

新作やロングテール作品でも特徴を作れる
推薦理由を説明しやすい
安全性やビジネス制約を入れやすい
類似性の意味を制御しやすい
ユーザー履歴が少ない場合でも使える

実務では、協調フィルタリング、コンテンツ特徴、行動特徴、文脈特徴を混ぜるのが自然である。

実務上の注意点

コンテンツ理解を推薦に使うときは、特徴量を作るだけでなく、運用上の問題を考える必要がある。

第 1 に、メタデータ欠損がある。avg_mood_tag や avg_fingerprint はすべての作品に付与されているわけではない。欠損をそのまま 0 と扱うと、「雰囲気が弱い作品」と「データがない作品」を混同する。欠損フラグを別特徴として持つべきである。

第 2 に、鮮度がある。publish_start_at、publish_end_at、is_coming_soon は時間で意味が変わる。昨日まで推薦できた作品が今日配信終了している可能性がある。候補生成やランキングの前に、推薦可能集合を日次またはリアルタイムで更新する必要がある。

第 3 に、表記揺れがある。人物名、作品名、タグ、制作国、提供元などは、文字列のまま使うと同一概念が分裂する。ID 正規化、辞書、エンティティリンクが重要である。

第 4 に、推薦の多様性がある。コンテンツ類似を強くしすぎると、似た作品ばかりになる。ランキング後にジャンル、シリーズ、出演者、mood の偏りを調整する必要がある。

第 5 に、説明可能性と正確性がある。LLM が生成した推薦理由が事実と違うと、ユーザー体験を損なう。推薦理由に使う情報は、作品メタデータや検証済み抽出結果に限定するのがよい。

第 6 に、評価指標がある。コンテンツ理解の改善は、単に分類精度だけで評価しても不十分である。最終的には推薦指標に効くかを見る必要がある。

例えば、次のような指標で評価する。

オフラインの Recall@K、NDCG@K、MAP@K
視聴開始率
25% 以上視聴率
完了率
継続視聴率
長期リテンション
多様性、カバレッジ、ロングテール露出
キッズ安全性やブラックリスト違反率

コンテンツ理解の品質が上がっても、ホーム画面のクリック率だけを最適化すると、短期的に強い人気作品へ偏る可能性がある。Hulu のようなサービスでは、ユーザー満足、継続利用、作品発見、多様性、配信権利、ビジネス制約を同時に考える必要がある。

まとめ

2.1.1 の「コンテンツ理解」は、推薦対象アイテムを意味のある機械表現に変換する工程である。Hulu の動画推薦では、item_information_table に含まれるジャンル、タグ、説明文、人物、制作国、公開年、配信期間、mood tag、fingerprint などを使って、作品を多面的に表現する。

暗黙的フィードバック推薦では、視聴ログだけでは「なぜ見たのか」「何を好んだのか」が曖昧である。コンテンツ理解によって、視聴履歴を「SF を見た」「ノーラン作品を見た」「感動的で思索的な作品を見た」「長尺の洋画を見た」といった解釈可能な嗜好に変換できる。

最終的に、コンテンツ理解は次の役割を持つ。

作品の意味的な特徴を抽出する
新作やロングテール作品のコールドスタートを緩和する
候補生成で類似作品を高速に検索する
ランキングでユーザー嗜好との一致度を特徴量化する
推薦理由を作る
キッズ、安全性、配信期間、ブラックリストなどの制約を扱う
コンテンツ需給やカタログの偏りを分析する

したがって、コンテンツ理解は推薦システムの前処理ではなく、推薦品質と運用品質を支える中核モジュールである。