3.5 LLM ベースのデータラベリングと評価の詳解

はじめに: LLM によるラベリングと評価で学ぶこと

この章では、動画推薦で用いるラベルをどのように定義し、LLM をどの段階で使い、どのように評価するかを扱う。推薦モデルの品質は、モデル構造だけで決まらない。何を正例・負例・意味属性として学習させるか、また何をもって推薦結果が良いと判断するかによって、モデルが最適化する対象そのものが変わる。

動画サービスの中心的な信号は、視聴、視聴時間、再視聴などの暗黙的フィードバックである。しかし、行動ログだけでは作品の内容や、ユーザーが選んだ理由を十分に表現できない。そこで LLM は、作品の意味を構造化するラベル、人手レビューを補う評価、コールドスタートを助ける補助特徴として利用できる。本章では、LLM の出力を実行動と混同しないことを前提に、実務で使える境界を整理する。

まず、LLM が補助できる対象と、最終的に実ログ・人手・online 評価で検証すべき対象を区別する。

最初に押さえる要点

LLM を推薦システムへ導入する役割は、オンラインで全作品を推薦することだけではない。作品の意味を補うラベルを作る、曖昧な候補の関連性を評価する、人手レビューを高価値な事例へ集中させる、という用途がある。動画推薦では視聴ログだけから「なぜ見たか」や「内容として何に近いか」を十分に表しにくいため、作品メタデータを読める LLM が補助信号になる。

ただし、LLM のラベルは真実そのものではない。LLM が「この作品はこのプロフィールに関連する」と判定しても、実際に視聴されることや視聴後に満足することは保証しない。LLM は行動ログの代替ではなく、意味情報の補助・人手作業の効率化・診断用評価器として使うべきである。

目的	主な根拠	LLM の役割	最終的な検証
作品理解	あらすじ、ジャンル、人物、映像特徴	タグ・ムード・注意事項の候補生成	人手監査、作品担当者レビュー
将来行動の予測	露出、再生、視聴時間など	コールドスタートの補助特徴・疑似ラベル	時系列評価、A/B テスト
推薦品質の診断	推薦リスト、文脈、作品カード	意図との整合性、重複、多様性の採点	人手との一致、行動指標
学習データ拡張	実ログとカタログ	query、比較ペア、理由の生成	フィルタリング、保留データ評価

Hulu のドメイン資料には、作品メタデータを持つ item_information_table と、シリーズの 25% 以上を視聴したときに記録される unique_viewed_series がある。一方、どの作品をどの位置に露出し、再生しなかったかという impression ログは定義されていない。従って、この資料だけを根拠に未視聴を負例や不満足と断定してはならない。

背景: なぜラベリングと評価が必要なのか

推薦モデルは、ユーザーまたはプロフィール $u$ 、候補作品 $i$ 、時点 $t$ の組に対して、「この場面で作品 $i$ を上位に置く価値」を推定する。そのためには、入力となる特徴量だけでなく、何を正解として学ばせるかというラベルが必要である。

\mathbf{x}_{u,i,t}=\text{profile, item, context, and exposure features}

y_{u,i,t}=\text{the target outcome to be predicted or judged}

例えば、ホーム画面に出す作品を学習するなら、 $\mathbf{x}_{u,i,t}$ にはプロフィールの最近の視聴傾向、候補作品のジャンル・説明文・配信可否、時刻、表示面などが入る。 $y_{u,i,t}$ には「再生されたか」「25% 以上視聴されたか」「人手が内容上関連すると判断したか」など、目的に応じた異なる値が入り得る。

ここで最初の難所がある。動画サービスでは、星評価のような明示的な「好き」「嫌い」が少ない。代わりに残るのは、視聴・未視聴・中断・再視聴のような行動である。行動は非常に価値ある信号だが、好みだけで決まらない。作品が表示されたか、サムネイルが見えたか、家族が同じプロフィールを使ったか、TVOD の料金が障壁だったかも影響する。

このため、推薦におけるラベリングは「人が一つずつ正解を書く作業」だけではない。観測された行動を慎重に学習ラベルへ変換する作業、作品内容を構造化する作業、評価者が判断しやすい基準を作る作業を含む。LLM は、このうち内容理解と言語的な比較を補助できる。

一つのホーム画面を例にする

あるプロフィールが、最近「宇宙を舞台にした SF 映画」と「犯罪サスペンス」を 25% 以上視聴したとする。候補として、思索的 SF 映画 A、同シリーズのシーズン 2、恋愛ドラマ B、SF アニメ C がある。

行動ラベルの問いは、「次の一週間でどの候補を 25% 以上視聴するか」である。
意味ラベルの問いは、「各候補は SF、犯罪、思索的、家族向けなど、どの性質を持つか」である。
評価ラベルの問いは、「ホームのこの枠で A を B より上に置くことは、与えられた文脈に照らして妥当か」である。

同じ作品 A でも、三つの問いの答えは別である。A は内容上非常に関連していても、プロフィールがすでに視聴済みなら表示する価値は低いかもしれない。同シリーズのシーズン 2 は内容が近くても、シーズン 1 未視聴なら推薦すべきでないかもしれない。この区別が、後で扱う LLM ラベルの過信を防ぐ。

このノートを読むための前提

次の用語を区別できれば、このノートは単独で読める。

用語	このノートでの意味	混同しやすい点
アイテム	推薦対象の作品またはシリーズ。ここでは主に `series_id` 単位	1 話や配信バージョンと同一とは限らない
プロフィール	視聴履歴を持つ推薦の主体。 `profile_id` に対応する	契約者個人と必ずしも一対一ではない
候補生成	全カタログから数百～数千件の有望な作品を集める段階	最終順位を決める処理ではない
ランキング	候補を表示順へ並べ替える段階	内容類似度だけで決めるものではない
暗黙的フィードバック	視聴・再生など、行動から得る選好信号	未視聴は明示的な嫌悪を意味しない
ラベル	学習・評価の基準となる値。行動、意味、人手判断、LLM 判断を含む	LLM 出力が唯一の正解ではない
疑似ラベル	LLM や規則で作った、直接観測されていないラベル	実ログと同じ信頼度では扱わない
オフライン評価	過去ログや人手評価セットで行う事前検証	実利用者の因果的な反応は確定しない
オンライン評価	A/B テストなど、実際の露出を変えて測る評価	実験設計と安全なロールアウトが必要である

本ノートは、LLM API の呼び出し方そのものよりも、何をラベルとして定義し、どの段階で LLM を使い、どのように検証するかを扱う。LLM の出力が流暢であることと、推薦システムにとって有用・安全なラベルであることは別の問題だからである。

全体像: LLM は推薦パイプラインのどこに入るか

典型的な動画推薦の流れは次の通りである。

作品カタログ・視聴ログ
        │
        ├─ 作品理解: ジャンル、説明、ムード、人物などを整える
        │              └─ LLM はタグ候補・説明・品質監査を補助できる
        │
        ├─ 候補生成: 全カタログから有望な作品を集める
        │
        ├─ ランキング: 視聴・継続などの行動を予測して並べ替える
        │              └─ LLM ラベルは特徴量や学習データの補助になり得る
        │
        ├─ 再ランキング: 多様性、年齢制約、配信可否、重複を調整する
        │
        └─ 評価: 行動指標、人手評価、LLM judge を別の軸として確認する

本章の LLM は、通常、候補生成やランキングの全リクエストに同期して呼ぶものではない。オフラインで作品ラベルを作る、上位候補を診断する、評価セットを補う、人手レビュー対象を選ぶ、といった使い方が出発点になる。こうすると、コスト・遅延・再現性を管理しながら、LLM が得意な意味理解だけを利用できる。

1. ラベリング対象を分けて考える

1.1 行動ラベル

行動ラベルは、プロフィールが実際に何をしたかを表す。再生開始、視聴秒数、25% 視聴、完走、次話視聴、マイリスト追加、非表示などが該当する。ドメイン資料から明確に作れるのは、評価期間 $T$ における 25% 以上視聴である。

y^{25\%}_{u,i,T}= \begin{cases} 1 & \text{if profile } u \text{ watched series } i \text{ at least 25\% during } T \\ 0 & \text{otherwise} \end{cases}

$y^{25\%}_{u,i,T}=1$ は観測された正例である。しかし $0$ は「嫌いだった」という負例ではない。作品が露出されなかった、棚の下にあり気づかなかった、TVOD の追加課金が必要だった、時間がなかった、といった理由があり得る。これは暗黙的フィードバックで最も重要な注意点である。

1.2 意味ラベル

意味ラベルは「その作品がどのような内容か」を表す。ジャンル、雰囲気、恋愛・暴力表現の強さ、家族視聴への適性、視聴シーン、シリーズへの入りやすさなどが該当する。

item_information_table には genre 、 sub_genre 、 sockets_tag 、 sentence 、 description 、キャスト・監督、 avg_mood_tag 、 avg_fingerprint がある。LLM はこれらを統合して欠損タグの候補や統一的な説明を作れる。ただし、LLM 出力を公式事実として上書きしてはいけない。例えば「緊張感のある思索的 SF」は補助的な意味ラベルであり、「プロフィールが今夜その作品を見る」は行動予測である。両者は別物である。

1.3 評価ラベル

評価ラベルは、推薦結果が目的に対してどれほど良いかを表す。「この候補は最近の嗜好と内容上合うか」「10 件のリストに同一シリーズが多すぎないか」「キッズプロフィールに不適切な作品が混ざらないか」といった判定である。

LLM-as-a-Judge はこの評価ラベルを作る用途である。これは意味的な補助評価軸であり、実視聴を測る指標の置き換えではない。採点基準、提示情報、モデル版、候補の順序によって結果が変わり得るため、人手との一致を継続的に測る必要がある。

2. 図 3.4 を動画推薦へ読み替える

図 3.4: LLM による関連性判定のポイントワイズ、ペアワイズ、リストワイズ方式。

提示された図は、検索の query と document の関連性を LLM が判定する三方式を示す。動画推薦では、query をプロフィール文脈 $q_u$ 、document を候補作品のカード $d_i$ と置き換える。

q_u=\text{recent viewing, explicit intent, surface, and constraints}

d_i=\text{title, synopsis, metadata, availability, and safety attributes of item } i

作品カードには、 series_title_ja 、 media_type 、 genre 、 sub_genre 、 description 、 sockets_tag 、出演者、監督、 premiere_year 、 service_type 、配信可否など、推測で補わなくてよい事実を構造化して渡す。 is_blacklist=true 、配信期間外、年齢制限違反の候補は、LLM に採点させる前に除外するべきである。

プロフィール文脈も履歴を無加工で全件投入しない。評価時点以前の unique_viewed_series だけを使い、最近性と多様性を保って要約する。

プロフィール文脈
- 最近 30 日: SF 映画を 3 本、犯罪サスペンスを 2 本、いずれも 25% 以上視聴
- 長期傾向: 映画を主に視聴。海外ドラマは少ない
- 現在の意図: 明示されていない
- 表示面: ホームの「あなたへのおすすめ」
- 制約: 視聴可能、未視聴、年齢制限を満たす作品のみ

この形なら、プロフィール ID、正確な視聴日時、個人情報を LLM に渡さずに必要な判断根拠を与えられる。

2.1 ポイントワイズ: 一件ずつ絶対評価する

ポイントワイズでは、一つの文脈 $q_u$ と一つの作品カード $d_i$ を見て、関連度を判定する。図の上段左にある Relevance Generation がこれに当たる。

g_{u,i}=J_{\mathrm{LLM}}(q_u,d_i)

出力を Yes / No だけにすると粗すぎる。動画推薦なら次の 4 段階が実用的である。

関連度 $g_{u,i}$	定義	例
3	最近の意図・視聴傾向に強く整合し、阻害要因がない	最近の思索的 SF 視聴に近い新着 SF 映画
2	整合するが、確信を下げる要因がある	同ジャンルだがシリーズ途中からの作品
1	弱い関連性だけがある	人気だが履歴との接点が少ない作品
0	関連しない、または制約違反	利用不可、年齢制限違反の作品

ポイントワイズは作品メタデータの品質監査、候補の粗いフィルタ、疑似ラベル生成に使いやすい。各候補を独立に並列処理できるからである。一方、LLM の絶対スコアはプロンプト間で校正されているとは限らない。また、候補数に比例してコストが増えるため、全カタログのオンラインランキングへ直接使う設計は現実的でないことが多い。

図の下段左にある Query Generation は、作品カードから「この作品を探す人が持ちそうな意図」を作る処理である。

\tilde q\sim P_{\mathrm{LLM}}(q\mid d_i)

例えば、作品説明から「宇宙を舞台に、人類の存続を描く緊張感のある SF 映画」という意図を作り、 $(\tilde q,d_i)$ を検索器の正例にできる。ただし、これは実ユーザーが入力した query ではない。実検索ログがあるなら必ず混ぜ、生成データには出所フラグと低めのサンプル重みを付けるべきである。

2.2 ペアワイズ: 二作品を比較する

ペアワイズでは、同一の文脈 $q_u$ に対して候補 $i$ と $j$ のどちらがより関連するかを問う。図の下段右に対応する。

z_{u,i,j}= \begin{cases} 1 & \text{if } i\succ j \\ 0 & \text{if } j\succ i \end{cases}

$i\succ j$ は「文脈 $q_u$ では、 $i$ を $j$ より上に置くべき」を意味する。例えば、最近 SF 映画を複数視聴したプロフィールに、新着の思索的 SF と人気の恋愛ドラマを比較させる。LLM が前者を選び、最近性・ジャンル・あらすじのどれを根拠にしたかを返せば、ペアワイズ学習信号または上位候補の再順位付けに使える。

注意点は次の通りである。

候補の提示順が結果に影響し得る。 $(i,j)$ と $(j,i)$ の両順で採点するか、順序をランダム化する。
$n$ 候補の総当たり比較には $n(n-1)/2$ 回が必要である。上位 $K$ 件だけに限定する、トーナメント方式にするなどの制約が必要である。
A / B だけを強制すると、同程度や両方不適切という情報が失われる。 Tie と Neither を許し、後段での扱いを決めるべきである。

2.3 リストワイズ: リスト全体を判定する

リストワイズでは、候補集合 $D=\{d_1,\ldots,d_n\}$ を一度に渡し、順位または段階評価を返させる。図の上段右に対応する。

\pi_u=J_{\mathrm{LLM}}(q_u,D)

利点は、候補間の重複とリスト全体の多様性を見られることである。「同じシリーズの劇場版が上位 5 件を占める」「SF だけでなく履歴上の犯罪サスペンスも一件入れる」といった判断は、ポイントワイズでは捉えにくい。

一方、候補数が大きいほど入力長、コスト、順位バイアスが増える。先頭の候補や説明が長い候補が有利になり得る。実務では既存ランカーの上位 $K$ 件に対象を絞り、入力順を複数回シャッフルし、JSON 形式で完全な順列を返させる方法が妥当である。候補が多い場合は小さな窓で順位付けし、窓をずらして結果を集約する windowed listwise reranking を使えるが、窓の切り方も評価対象として固定・検証する必要がある。

3. LLM judge を評価器にする手順

3.1 判定仕様を先に固定する

「関連性がありますか」だけでは、一貫した採点はできない。評価対象の表示面、基準時点、文脈、利用可能性、評価基準を明記する。

項目	仕様例
対象	プロフィール $u$ に対する未視聴シリーズ $i$
基準時点	ある時点の情報だけを使用
文脈	基準時点より前の 90 日の 25% 以上視聴履歴を要約
関連性	現在の視聴傾向と内容面で整合し、ホームに提示する合理性があること
除外	利用不可、ブラックリスト、年齢・プロフィール制約違反
非判断事項	将来の視聴を断定しない。入力にない作品事実を推測しない
出力	0–3 の関連度、根拠、確信度、判定不能フラグ

この仕様がなければ、ある事例ではジャンル近接、別の事例では人気度を根拠に高得点を付ける、といったぶれが生じる。人間アノテータ用と同じ粒度のルーブリックが必要である。

3.2 構造化出力と再現性を確保する

自然言語の説明だけを返させず、機械検証できる schema を用いる。

役割: 動画推薦の評価者。
目的: プロフィール文脈に対する候補シリーズの内容上の関連度を判定する。
規則: 入力にない事実を推測しない。将来の視聴を断定しない。
出力 JSON:
{
  "relevance_grade": 0 | 1 | 2 | 3,
  "evidence": ["入力中に明示された根拠"],
  "uncertainty": "low" | "medium" | "high",
  "abstain": true | false
}

evidence を入力 field に明示された根拠に限定すると、架空の作品情報を持ち込んだ判定を検出しやすい。構文、値の範囲、候補 ID の一致は呼び出し直後に検証する。モデル名・版、prompt、schema、temperature、最大出力 token、日時を保存しない評価は再現できない。温度は原則として低く固定する。

3.3 人手ラベルで校正する

LLM の自己申告した確信度を品質保証に使ってはいけない。まず人手ラベル付き評価セットを作る。簡単な事例だけではなく、次のような失敗しやすい層を意図的に含める。

新着・ログ不足の作品
同一シリーズのシーズンや劇場版
タイトルやジャンルは似るが雰囲気が異なる作品
キッズ、ライブ、TVOD、配信終了間近などの制約を持つ作品
長期嗜好と最近嗜好が衝突するプロフィール

人間同士にも不一致があるため、単一アノテータの答えを絶対正解とみなさない。複数人でラベル付けし、不一致を調停または分布として保存する。LLM と人間の比較には、正解率だけでなく、順序尺度に対応する重み付き Cohen のカッパやペアワイズ一致率を使う。全体平均だけでなく、失敗しやすい層ごとに分析することが重要である。

3.4 行動指標と別に報告する

将来行動を予測するランカーは、時間で分けたホールドアウトで評価する。基準時点 $t_0$ より前の履歴だけで候補と特徴を作り、その後の評価期間で 25% 以上視聴されたシリーズを正例とする。

\operatorname{Recall@K}=\frac{1}{|\mathcal{U}|}\sum_{u\in\mathcal{U}}\frac{|R_u@K\cap\mathcal{Y}_u|}{|\mathcal{Y}_u|}

LLM judge の段階関連度 $g_{u,i}$ で測る NDCG は、意味上の順位品質を補助的に測る。

\operatorname{DCG@K}=\sum_{r=1}^{K}\frac{2^{g_{u,\pi(r)}}-1}{\log_2(r+1)}

\operatorname{NDCG@K}=\frac{\operatorname{DCG@K}}{\operatorname{IDCG@K}}

この値は「LLM が定義した意味上の関連性」であり、実視聴 NDCG とは別に報告する。人間・LLM が内容上は適合と判定しても、認知度、サムネイル、時間帯、課金条件などで再生されない場合があるためである。露出ログを利用できるなら、表示位置・表示面・露出時刻を含め、位置バイアスを扱う評価へ進むべきである。

4. 生成型ラベリングと生成後フィルタリング

LLM が生成できるのは、関連度だけではない。作品説明からの検索 query、補助タグ、視聴シーン、作品ペアの類似理由、プロフィールと作品の比較ラベル、説明文の候補を作れる。

生成物 $\tilde D$ は実データ $D_{\mathrm{real}}$ と区別し、同じ重みで学習へ混ぜない。

\mathcal{L}=\sum_{x\in D_{\mathrm{real}}}\ell(x)+\lambda_{\mathrm{syn}}\sum_{\tilde{x}\in\tilde D}w(\tilde{x})\ell(\tilde{x})

$\lambda_{\mathrm{syn}}$ は合成データ全体の影響、 $w(\tilde{x})$ は個々の生成物の品質重みである。実ログより生成物を信頼できるという前提は置かない。LLM が作った query とラベルだけで検索器を学習すると、実ユーザーの query でなく「LLM らしい query」にだけ強くなる危険がある。

生成後フィルタリングは少なくとも次の順序で行う。

JSON schema、 series_id 、許可ラベル、文字数を検証する。
生成されたジャンル、人物、配信形態が item_information_table の事実と矛盾しないかを確認する。
同じ作品から生成された重複・近重複を除く。
別 prompt・別モデル・ルールで、具体性、事実性、意図の明確さを採点する。
高影響・低信頼度・ランダム標本を人手監査する。
実データだけの保留セットで、下流モデルの改善を測る。

同じモデル・同じ prompt に生成と検査を任せると、同じ偏りを見逃しやすい。ルール、人手、異なる判定器、実ログを組み合わせるべきである。

5. 人間支援型 LLM ラベリング

LLM は大量の初期ラベルを作れるが、年齢適合性、センシティブな表現、作品の事実性、ブランドポリシーの判断を完全自動化すべきではない。人手は LLM 出力の最終採点者であるだけでなく、ラベル体系、例外規則、失敗パターンを定義する役割を持つ。

全件の人手確認は高コストであり、全自動採用は高リスクである。従って、不確実性・影響度・ポリシーリスクが高い事例を優先してレビューへ送る。

\operatorname{review}(x)=\mathbb{1}[a\,\operatorname{uncertainty}(x)+b\,\operatorname{impact}(x)+c\,\operatorname{policy\_risk}(x)>\tau]

不確実性は LLM の自己申告だけから作らない。複数 prompt の一致度、候補順を変えたときの安定性、複数実行の分散、入力欠損、ルール違反を組み合わせる。影響度はホーム上位枠への露出規模、新着大型作品、キッズ面などで定義できる。

能動学習では次のループを回す。

現行の LLM または分類器で未ラベルプールを採点する。
不確実性、代表性、影響度、ポリシーリスクで人手レビュー候補を選ぶ。
複数のアノテータがガイドラインに沿って判定し、不一致を保存する。
合意ラベルを追加し、モデル、prompt、規則を更新する。
固定テストセットと将来時点の行動データで再評価する。

候補を不確実な事例だけに絞ると、人気作品や特定ジャンルへ偏る。ジャンル、年代、配信形態、作品規模、プロフィール傾向で層化したランダム監査も必要である。

6. Hulu 向けの最小実験

最初から LLM に全ランキングを任せるのでなく、限定された検証可能な用途から始めるべきである。

実験 A: 新着作品の意味ラベル補完

目的は、 item_information_table の既存メタデータを補完し、コールドスタートの特徴を増やすことである。

既存の genre と重複しないラベル体系を固定する。例はトーン、視聴シーン、物語構造である。
人手が正解ラベルを作った層化標本を用意する。
LLM にタイトル、説明、ジャンル、人物、タグを渡し、schema 制約付きで事前ラベルを出させる。
人手との一致、欠損、事実誤認、ジャンル別の失敗を測る。
合格したラベルだけを embedding またはランキング特徴に加える。
新着作品に限定した候補検索 Recall と、後日の 25% 視聴率をベースラインと比較する。

LLM ラベル自体が高精度でも、既存の avg_fingerprint や sockets_tag と完全に重複していれば、下流推薦への追加価値は小さい。ラベル精度と下流効果を分けて測る必要がある。

実験 B: ランカー上位候補の LLM judge 評価

目的は、既存ランカー上位の意味的な失敗を見つけることである。オンライン順位を LLM に直接任せる実験ではない。

基準時点までの unique_viewed_series からプロフィール文脈を作る。
現行ランカーと比較ランカーの上位 10 件を集める。
利用不可、既視聴、ブラックリストなどを事前に除く。
順番をシャッフルしたリストワイズ prompt と、必要に応じたペアワイズ比較で、関連度・重複・多様性を判定する。
一部を人手評価し、LLM judge の順位・理由・不確実性を校正する。
将来期間の 25% 視聴 Recall@K、行動 NDCG@K、意味的 NDCG@K を併記する。

両方の NDCG が改善するなら有望である。意味的 NDCG だけが改善するなら、内容整合性は上がったが行動へ結び付いていない可能性がある。行動指標だけが改善するなら、LLM のルーブリックが実際の視聴動機を捉えていない可能性がある。

7. よくある失敗

失敗	問題	回避策
未視聴を一律負例にする	未露出・見落とし・利用不可を嫌悪と混同する	impression を用いる。ない場合は未観測として扱う
LLM 関連度を視聴確率と解釈する	内容上の適合と行動は異なる	LLM 指標と時系列行動指標を分けて報告する
未来情報を要約に入れる	オフライン評価のリークになる	基準時点を固定し、履歴とカタログを time travel 可能にする
全カタログを LLM 採点する	コスト・遅延・再現性の問題が大きい	上位候補、オフライン評価、ラベル生成に限定する
二択比較を強制する	同程度・両方不適切を失う	`Tie` と `Neither` を許す
生成物を無検査で教師にする	幻覚・反復・偏りを増幅する	schema、事実照合、重複除去、人手監査を通す
LLM の理由を事実とみなす	入力にない根拠を作り得る	根拠を入力 field に紐付けさせる

まとめ

図 3.4 のポイントワイズ、ペアワイズ、リストワイズは、LLM に関連性を問う粒度の違いである。動画推薦では query をプロフィール文脈、document を作品カードと読み替える。

ポイントワイズは、作品単位の意味ラベルや粗い候補評価に適する。ただし独立に出した絶対スコアの比較には限界がある。
ペアワイズは、二候補の相対比較とペアワイズ学習信号に適する。ただし順序バイアス、比較回数、同点の扱いを設計する必要がある。
リストワイズは、順位だけでなく重複・多様性を含むリスト品質の評価に適する。ただし候補数、入力順、コストの制約が大きい。

Hulu では、まず item_information_table の意味ラベル補完と、 unique_viewed_series の時系列行動評価を分離して扱うべきである。その上で、人手校正済みの LLM judge を補助評価器として加え、採用判断は行動ログとオンライン実験で行うのが堅実である。