TLDR

微小な性能向上は、実装コストに見合わない — これこそが XGBoost や LightGBM の“手軽さ”の最大の魅力。
Embedding と相性が悪い ため、新規 ID が大量に流入する本番環境では DNN に太刀打ちできない。
とはいえ モデルが必要だが DNN をデプロイできない場面 ではツリーモデルが活路を見いだせる。
- ツリーモデルを選ぶべき 2 つの条件
  1. 新しい ID 系の特徴量がほぼ発生しない
    - 例：年齢、都市など列挙可能なカテゴリ
  2. カテゴリ型と数値型が混在し、行動回数などの計数特徴量が多い
    - 例：動画視聴回数、購入数、滞在時間
リランキングモデルに“必要条件”（十分条件ではない）となるのは、新しく登場する特徴量やその値が、学習フローやデプロイを中断・変更させないことである。

ツリーモデルが抱える根本的な問題

実務でツリーモデルを採用するかどうかを判断する最大のポイントは、オンライン学習中に次々と現れる新規 ID をどう扱うかに尽きます。

デフォルト値で埋める
- 時間とともにデフォルト値が増え、モデル性能が劣化
新規 ID が出るたびに再学習
- “ほぼリアルタイム”を目指すオンライン学習の哲学に反する

大規模プラットフォームでは、新規アイテム比率が 50% を超えることも珍しくありません。未学習サンプルが大量に存在する状況では、ツリーモデルは手詰まりになります。

Facebook の“1 日 1 回再学習”は万能ではない

論文 Practical Lessons from Predicting Clicks on Ads at Facebook では、ツリーモデルを毎日更新しています。しかし、1 日 1 回のリトレーニングで収束しないケースでは同じ手法は通用しません。

Embedding + DNN が無敵な理由

新しい ID が出現するたびに Embedding テーブルへスロットを追加するだけ
トレーニング／デプロイのフロー自体は一切変えずに済む

現在主流のリランキングモデルはこの問題を埋め込みで解決しています。新しい ID が現れるたびに、そのための埋め込み空間を割り当て、特徴情報を保持します。コールドスタート問題はあるものの、トレーニングやデプロイのワークフロー自体に変更が不要なため、Embedding＋DNN のパラダイムはほぼ無敵です。

ツリーモデルと埋め込みの融合の難しさ

現時点では、ツリーモデルと埋め込みをうまく組み合わせた例はほとんど見られません。Embedding は低次元の ID を高次元空間にマッピングしますが、決定木は特徴量そのものの情報を用いて分割を行います。そのため、Embedding の利点を十分に活かすことが難しく、Rerank の現場からツリーモデルは姿を消しています。

ツリーモデルの強さ

ツリーモデルの省スペース性

Embedding は強力ですが、ストレージコストも莫大です。例えば埋め込み次元が 64 であれば、論理回帰モデルで１台に収まっていた特徴量が 64 台分のストレージを必要とします。Parameter Server を用いても大きな空間消費を招きます。

推薦システムには Rerank 以外にも多くの小さな予測タスクがあり、すべてに Embedding＋DNN を適用するのは合理的とは言えません。ここでツリーモデルが活躍します。埋め込み不要でストレージを大幅に節約でき、軽量モデルが求められる場面で手軽に導入できます。

ツリーモデル活用の典型シナリオ

物料のライフサイクル段階判定
コンテンツや広告のライフサイクル段階を予測。物料 ID ではなく「累計露出量」「公開からの経過期間」「各段階での露出・コンバージョン数」などを特徴量とするタスク。
ユーザー翌日来訪予測
「カテゴリ内で視聴した動画数」「利用開始からの経過時間」「当日の総再生時間」など行動計数情報を用いて、翌日もサービスに戻るかを予測。

いずれも数値型・カテゴリ型の組み合わせで高精度を出せる典型的事例で、広告配信最適化やユーザー定着改善に直結します。

「クローズドセット vs. オープンセット」

テストに現れる ID は学習時にすべて観測済み（＝クローズドセット）

Kaggle 競技でツリーモデルが多用されるのは、まさにこのクローズドセットだからです。一方、実際のサービスはオープンセットで、新規ユーザーや新規アイテムが次々と現れ、Embedding 構造の変更や頻繁なリトレーニングが求められます。