電子書籍レコメンドにおける Reranking モデル (2nd-stage) の導入事例

サムネイル

はじめに
背景
提案手法
効果検証
- オフライン評価
- A/B テスト
  - 表示位置別 CVR 分析
補足: i2i レコメンドへの適用
おわりに
脚注

はじめに

こんにちは、データ活用推進部レコメンドチームの寺井です。普段は DMM グループの各種サービスで、レコメンドシステムの開発・改善を担当しています。

本記事では、電子書籍サービスのレコメンドシステムに、Reranking モデル (2nd-stage) を導入した取り組みについて紹介します。具体的には、u2i と i2i の2つのレコメンドに適用し、A/B テストで効果を検証しました。

この記事を通じて、2-stage レコメンドシステムにおける実践的な知見と、大規模な推論処理を効率化するための工夫をお伝えできればと思います。

背景

従来の電子書籍サービスのレコメンドシステムでは、u2i・i2i のいずれも Two-Tower モデルをベースにレコメンドを生成していました。u2i ではユーザとアイテムの Embedding 類似度、i2i ではアイテム間の Embedding 類似度をスコアとして使用し、スコアの高い順にアイテムを表示していました。

このアプローチでは、Embedding の類似度スコアのみで表示順序が決まるため、購買確率やクリック確率といったビジネス KPI に直接最適化されていないという課題がありました。例えば、Embedding 空間上で類似していても、ユーザの購買行動に結びつきにくいアイテムが上位に表示されるケースもありました。

提案手法

既存の Two-Tower モデルを用いた候補生成の後に、Reranking モデルを追加する 2-stage レコメンドシステム¹を採用しました。

2-stage レコメンドシステムでは、全アイテムから候補を絞り込む 1st-stage と、絞り込んだ候補の表示順序を最適化する 2nd-stage に分けて処理を行います。

1st-stage: 候補生成
- Two-Tower モデルなどの軽量かつ高速なロジックを用いて、ユーザが興味を持ちそうな候補アイテムを広く収集します。この段階では、全アイテムの中から関連度が高そうなものを数百〜数千件程度まで絞り込むことを重視します。
2nd-stage: Reranking
- 1st-stage で絞り込んだ候補アイテムに対して、多様な特徴量を用いて購買確率を予測し、スコアの高い順に並べ替えます。この段階では、候補集合の中でどのアイテムを上位に表示するかを最適化します。

2つの stage に分けている理由としては、ユーザに対して全アイテムをスコアリングするのは計算コストが高すぎるためです。まずは高速な候補生成で対象を絞り込み、その後に Reranking モデルで精緻に並べ替えることで、計算量を抑えつつランキング最適化を実現しています。

以降、u2i を題材に、候補生成、特徴量設計、Reranking モデル、推論処理の高速化について順に説明していきます。

1. 候補生成

u2i では、候補の多様性を確保するために4つの経路からアイテムを収集しています。

Two-Tower u2i: ユーザ Embedding とアイテム Embedding の内積に基づく候補
i2i ロジック: ユーザの行動履歴に基づく類似アイテムの候補
人気ロジック①: 人気傾向に基づく候補
人気ロジック②: 別軸の人気傾向に基づく候補

購入済みアイテムを除外したうえで、1ユーザあたり100〜600件の候補を生成します。

各候補経路を追加するごとに Recall・HitRate が改善することをオフライン評価で確認し、4経路すべてを採用しました。

2. 特徴量設計

100以上の特徴量を以下のように設計しました。

カテゴリ	例
ユーザ静的特徴量	ユーザ Embedding
ユーザ動的特徴量	期間別の行動傾向、価格帯の嗜好、新作嗜好度、モメンタムやトレンド
アイテム静的特徴量	アイテム Embedding, テキスト Embedding、ジャンル、出版社、掲載誌、価格、鮮度
アイテム動的特徴量	期間別の行動傾向、モメンタムやトレンド
ユーザ×アイテム特徴量	ユーザとアイテムの cos 類似度、価格帯の一致度、新作嗜好との整合性

Feature Importance を見ると、ユーザ×アイテム特徴量が上位に現れる中で、「掲載誌」や「出版社」といったアイテム静的特徴量が上位に現れていた点が特徴的でした。電子書籍では特定の掲載誌や出版社を追いかけるユーザが多いため、これらの特徴量が購買予測に有効に寄与していると考えられます。

3. Reranking モデル

LightGBM を用いて、ユーザごとに生成された候補アイテム群の順位を最適化するランキング学習 (Learning to Rank) ² を行います。

各ユーザを1つの query とみなし、そのユーザに提示された候補アイテムの中で、実際に購入につながりやすい作品ほど上位に来るように学習させています。

これにより、各アイテムを独立にスコアリングするだけでなく、同一ユーザに対して提示される候補群の相対的な並び順まで含めて最適化できます。

4. 推論処理の高速化

u2i における Reranking モデルの推論では、対象ユーザ×候補アイテム分の特徴量生成やスコアリングが必要になってきます。数億レコード規模のデータを扱うことになるため、処理を高速化する必要がありました。

4-a. 分散ワーカーによるスケールアウト

4つの Vertex AI CustomJob をワーカーとして並列起動し、各ワーカーがモジュロ演算で割り当てられたシャードを処理する構成を採用しました。

シャード分割

推論対象のユーザを farm_fingerprint のモジュロ演算で32シャードに分割し、BigQuery テーブルも shard_ix でパーティション化しています。4ワーカーと32シャードの対応は以下の通りです。

num_shards = 32, num_workers = 4
- Worker 0: shard [0, 4, 8, 12, 16, 20, 24, 28]
- Worker 1: shard [1, 5, 9, 13, 17, 21, 25, 29]
- Worker 2: shard [2, 6, 10, 14, 18, 22, 26, 30]
- Worker 3: shard [3, 7, 11, 15, 19, 23, 27, 31]

I/O の最小化

各ワーカーは担当シャードに含まれるユーザ ID・アイテム ID のみを INNER JOIN で取得します。必要なデータだけを読み込むことで、I/O コストを大幅に削減しています。

-- シャードに出現するユーザ ID のみを取得
WITH ids AS (
  SELECT DISTINCT user_id
  FROM test_dataset
  WHERE shard_ix = @target_shard
)
SELECT u.*
FROM user_embedding AS u
INNER JOIN ids ON ids.user_id = u.user_id

結果の書き出しと集約

各ワーカーは独立したテーブル（predictions__w000_of_004 など）に結果を書き出し、全ワーカーの完了後に UNION ALL で結合します。ワーカー間に依存関係がないため、1ワーカーで障害が発生しても他への影響はありません。

ワーカー内の並列化

さらなる高速化を目指して ThreadPoolExecutor（スレッド並列）や ProcessPoolExecutor（プロセス並列）も試行しました。しかし、BigQuery Storage API の認証・クォータ制約やピークメモリの増加が大きく、効果は限定的でした。そのため、ワーカー内はシャードを単一プロセスで逐次処理する構成にしています。

4-b. 計算経路の見直し

当初は Python 側で行っていた推論結果を用いた sort 処理や TopK 抽出を、BigQuery による後処理に移譲しました。

-- BigQuery側でランキングとTopK抽出を実行
WITH ranked AS (
  SELECT
    ROW_NUMBER() OVER (
      PARTITION BY user_id
      ORDER BY rerank_score DESC
    ) AS rank,
    user_id, item_id, rerank_score
  FROM predictions
)
SELECT * FROM ranked
WHERE rank <= @max_response

数百万行のソートを Python の pandas などで行うよりも、BigQuery の window 関数に任せた方が効率的です。また、特徴量生成もすべて BigQuery 上で行っており、Python 側は LightGBM の推論のみに集中させています。

効果検証

オフライン評価

本番導入前に、過去の購買ログを用いて u2i レコメンドのオフライン評価を実施しました。

既存の Two-Tower モデル（Control）と Reranking モデル導入後（Test）を比較しています。

nDCG・HitRate

	nDCG@5	nDCG@10	nDCG@40	HitRate@5	HitRate@10	HitRate@40
比率（Test / Control）	+48.1%	+36.6%	+19.1%	+66.7%	+75.0%	+50.0%

nDCG・HitRate ともに大幅な改善が見られました。特に nDCG@5 は +48.1% と、上位表示の品質向上が顕著でした。Reranking によって購入につながりやすいアイテムを上位に配置できていることが確認できます。

DR 推定量による Off-Policy Evaluation

購買行動への寄与をより直接的に評価するために、Doubly Robust（DR）推定量³による Off-Policy Evaluation（OPE）も実施しました。

DR 推定量は、報酬予測モデルによる Direct Method と傾向スコアによる Inverse Propensity Scoring を組み合わせた手法です。報酬モデルまたは傾向スコアモデルのいずれか一方が正しく指定されていれば一致性を持つという二重頑健性を備えます。

今回は GBR と MLP の2種類の報酬予測モデルを学習し、ブートストラップ法で 95% 信頼区間を算出して統計的有意性を検定しました。

DR 推定量のブートストラップ分布

DR 推定量においても有意な改善が確認されたため、A/B テストへの進行を決定しました。

A/B テスト

14日間の A/B テストを実施しました。評価に用いた指標は以下の通りです。

ARPU：ユーザあたりの平均売上
商品詳細 PV：商品詳細ページの閲覧数
u2i 経由の商品詳細 PV：u2i 棚を経由した商品詳細ページの閲覧数

結果は以下の通りです。

	ARPU	商品詳細 PV	u2i 経由の商品詳細 PV
結果	向上	向上	向上
統計的有意差（p < 0.05）	あり	あり	あり

すべての指標で統計的に有意な改善が確認されました。特に u2i 経由の商品詳細 PV は大幅に向上しています。

表示位置別 CVR 分析

Reranking が効いているかを確認するために、u2i 棚内の表示位置ごとに、推薦されたアイテムが購入に至った割合（CVR）を算出しました。

Test 群では上位表示のアイテムの CVR が Control 群と比べて明確に向上しており、購入につながりやすいアイテムを上位に配置できていることを裏付ける結果となりました。

表示位置別 CVR

補足: i2i レコメンドへの適用

i2i においても u2i と同様の 2-stage レコメンドシステムを採用しました。

1st-stage では各アイテムに対して Embedding 類似度 Top200 件を候補として収集し、2nd-stage では LightGBM の lambdarank によって並び順を最適化しました。学習時にはソースアイテムと候補アイテム双方の過去7日間の人気に基づく sampling_weight を設定し、人気バイアスを抑制しています。

特徴量は、アイテム×アイテム特徴量（候補生成段階の類似度スコア・元ランキング）、各アイテムの静的・動的特徴量から構成しています。 Feature Importance を見ると、候補生成段階の cos 類似度と元ランキングが重要ではありつつも、「掲載誌一致」や「出版社一致」も上位に入っており、u2i と同様に掲載誌・出版社の一致がレコメンド品質に寄与していることが確認できます。

A/B テストでは、ARPU および i2i 経由閲覧数のいずれも統計的に有意な改善が確認されました。u2i と同様に、i2i においても Reranking の有効性が示されています。