🤖 machine learning

UniPinRec: Unifying Generative Retrieval and Ranking at Pinterest Scale

UniPinRecは、検索（retrieval）とランキング（ranking）を、入力、学習、およびサービングのインフラストラクチャを共有する単一のトランスフォーマーベースのパイプラインへと完全に統合した初のプロダクションシステムであり、Pinterest規模において大幅なエンゲージメントの向上と効率性の改善を実現しました。

原著者： Hanyu Li, Yi-Ping Hsu, Aditya Mantha, Prabhat Agarwal, Laksh Bhasin, Jialu Wang, Hongtao Lin, Bella Huang, Yaxin Li, Xinyi Li, Chuxi Wang, Kousik Rajesh, Hooshmand Shokri Razaghi, Shunyao Li, Zongyue

公開日 2026-06-02

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Hanyu Li, Yi-Ping Hsu, Aditya Mantha, Prabhat Agarwal, Laksh Bhasin, Jialu Wang, Hongtao Lin, Bella Huang, Yaxin Li, Xinyi Li, Chuxi Wang, Kousik Rajesh, Hooshmand Shokri Razaghi, Shunyao Li, Zongyue Qin, Jaewon Yang, James Li, Dhruvil Deven Badani, Jiajing Xu, Charles Rosenberg

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

Pinterestを、数十億もの本（ピン）が並ぶ、巨大で賑やかな図書館だと想像してみてください。あなたがその図書館に入ると、システムは次の2つのことを非常に素早く行う必要があります。

検索 (Retrieval): 図書館全体をスキャンして、あなたに興味を持ちそうな数千冊の本を見つけ出す。
ランキング (Ranking): その数千冊の本を手に取り、その要約を注意深く読み、あなたにとって完璧な順番に並べ替える。

旧来の手法：2人の別々の司書

長い間、Pinterestはこれを行うために、2つの異なる「司書」（AIモデル）を使用してきました。

**司書A（検索担当）**は、スピード狂でした。彼は本の内容を深く読み込むことはしませんでしたが、大量の本を高速でスキャンし、潜在的な一致候補の山をかき集めました。
**司書B（ランキング担当）**は、丁寧な読書家でした。彼はその集められた山の中から、一冊一冊の詳細を読み込み、完璧にソートしました。

問題点: 両方の司書は、あなたの過去の行動（クリックした、保存した、あるいは非表示にしたなど）に関する全く同じメモを読んでいました。両者がそれぞれ別々に「記憶」するという重労働を行っていたのです。これは、電話帳を一度覚えるだけで、2つの異なるリストを作るために、2人に同じ電話帳を暗記させるようなものでした。これは、お金、コンピューターの計算資源、そして時間の無駄でした。

新しい解決策：UniPinRec（スーパー司書）

この論文では、一つの「脳」、一つの「メモ」、そして一つの「ワークフロー」を用いて、両方の仕事を同時にこなす単一の「スーパー司書」であるUniPinRecを紹介しています。

彼らがどのようにこれを実現したのか、3つの巧妙なトリックを使って説明します。

1. 「マスクされたアクション」のトリック (MAM)

通常、「検索」の司書は、あなたが「いいね」をしたアイテムのリストだけを見ます。「ランキング」の司書は、それらのアイテムに対してあなたが「何をしたか」（クリックしたのか？保存したのか？非表示にしたのか？）を知る必要があります。

旧来の問題: もし「何をしたか」という情報をリストに混ぜてしまうと、検索司書のスピードが落ちてしまいます。
UniPinRecによる解決策: 彼らは「マスキング」技術を使用しました。イメージとしては、司書があなたの履歴リストを持っているとします。彼らは「何をしたか」という部分を、付箋で隠して（マスクして）しまいます。
- 司書は、アイテムに基づいて「あなたが何をしたか」を推測することを学びます。
- これにより、司書はリストを長くしたり混乱させたりすることなく、「アイテムを見つける方法（検索）」と「アイテムを判断する方法（ランキング）」の両方を学ぶことができます。これは、パーキングブレーキをかけた状態で練習することで、運転と駐車を同時に学ぶようなものです。

2. 「共有メモリ」のトリック (KV Cache Reuse)

これが最大のスピードアップ要因です。

旧来の問題: 「ランキング」の司書が仕事を始める際、あなたは誰であるかを理解するために、最初からあなたの履歴をすべて読み直さなければなりませんでした。
UniPinRecによる解決策: 「検索」の司書が、まずあなたの履歴を読むという重労働を済ませます。そして、そのメモを捨ててしまうのではなく、ランキング司書へと引き継ぎます。
- 「ランキング」の司書は、履歴を読み直す必要はありません。最初の司書がすでに書き留めたメモを見るだけで済みます。
- 例え: これは、野菜を切る作業をすべて済ませたシェフが、その後、スパイスを加えるだけの副料理長にボウルを手渡すようなものです。副料理長は、野菜を切り直す必要はありません。これにより、膨大な時間が節約されます。

3. 「混合トレーニング」のトリック

モデルを「見つける人」として先に訓練し、その後に「並べ替える人」として訓練するのではなく、両方を同時に行うように訓練しました。

彼らは、モデルに対して「あなたが気に入った履歴」と「見たけれどクリックしなかったアイテムのリスト」の両方を含む例を与えました。
これにより、モデルは「判断する方法」を知ることでより優れた「発見者」になり、「発見する方法」を知ることでより優れた「判断者」になるよう学習しました。

結果：より速く、より賢く、より安価に

この「スーパー司書」を実際のPinterestアプリに投入したところ、その結果は驚くべきものでした。

より良いレコメンデーション: ユーザーのピンの保存数や通知の開封数が増加しました。「発見者」と「判断者」が互いに連携することで、システムはより良いアイテムを見つけられるようになりました。
より高速なスピード: ユーザーの履歴を読み直す工程をなくしたため、システム全体が11%高速化しました。
より大きな容量: システムは、速度を落とすことなく、同時に63%多くのユーザーを処理できるようになりました。

まとめ

UniPinRecは、2つの別々の部門を1つの効率的なチームに統合するようなものです。同じ「脳（モデル）」、同じ「メモ（ユーザー履歴）」、そして同じ「ワークフロー」を共有することで、Pinterestはコンピューターのコストを節約し、アプリを高速化し、ユーザーが本当に望むコンテンツを表示できるようにしました。彼らは図書館のシステム全体を置き換えたのではなく、既存の司書たちが完璧に協力できるようにしたのです。

技術サマリー: UniPinRec

問題提起
Pinterestのような現代的な産業用レコメンデーションシステムは、通常、リトリーバル（検索）とランキング（順位付け）が別々のモデルとして訓練されるマルチステージのファンネルとして動作しています。両方のステージが、同じユーザー行動データをエンコードするために大規模なTransformerバックボーンに依存するようになっているにもかかわらず、この分離は重大な冗長性を生み出しています。現在のパラダイムでは、リトリーバルとランキングが学習された信号やモデルの重みを共有できないため、パラメータ、訓練計算、およびサービングコストが重複しています。先行研究ではモデルアーキテクチャの統一（例：HSTU、OnePiece）が試みられてきましたが、これらのアプローチは多くの場合、フルパイプラインの統一には至っていません。それらは入力フォーマット、訓練手順、およびサービングスタックにおいて断片的なままであったり、既存の候補ソースとの統合や運用制御を困難にするエンドツーエンドの生成的手法に依存したりしています。

手法
著者らは、リトリーバルとランキングのフルスタックの統一を実現するシステムであるUniPinRecを提案しています。このアプローチは、Pinterestの既存のプロダクション環境内にデプロイされた、入力フォーマット、モデルアーキテクチャ、訓練、およびサービングインフラストラクチャを単一の結束したパイプラインへと統合するものです。この手法は、以下の3つの核心的な技術革新に基づいています。

Masked Action Modeling (MAM):
単一のモデルが、コンテキスト長を倍増させたり入力の互換性を損なったりすることなく、リトリーバル（次アイテム予測）とランキング（アクション予測）の両方の役割を果たすことを可能にするために、著者らはMAMを導入しました。
- アーキテクチャ: アクショントークンをアイテムの間にインターリーブ（交互に挿入）するとシーケンス長が膨張するため、アクションはアイテムの表現と特徴量次元方向に結合された高密度な埋め込みとしてエンコードされます。
- マスキング: 訓練中、ユーザー履歴内のアクションは確率 $p_{mask}$ でランダムにマスクされます。推論時、未来のアクションは常にマスクされます。これにより、モデルはリトリーバル（次アイテム予測）に使用されるものと同じ非インターリーブのシーケンス上で、アクション予測（ランキング）の目的を学習することができます。
- アテンションパターン: システムは、修正された因果的マスク（M-FALCONパターン）を使用しており、候補ポジションは過去の履歴すべてにアテンションを向けますが、互いには向けません。これにより、アテンションの複雑さが $O((n+k)^2)$ から $O(n^2 + nk)$ に軽減され、効率的なKVキャッシュの共有が可能になります。
混合訓練と結合損失 (Blended Training and Joint Loss):
システムは、ユーザーの過去のエンゲージメント履歴と、未来のフィードビュー・インプレッション・スレート（ネガティブな結果を含む）をペアリングした統一された訓練例を構築します。
- データインフラストラクチャ: Rayベースのイン・トレーナー・ジョイン（in-trainer join）が、ユーザー履歴とフィードビュー・インプレッションの別々のIcebergテーブルを結合し、データの重複を避けつつ柔軟なサンプリング比率を可能にします。
- 目的関数: モデルは、結合損失関数 $L = L_{item} + L_{action}$ $L = L_{i t e m} + L_{a c t i o n}$ で訓練されます。
  - $L_{item}$ : 次アイテム予測（リトリーバル）のためのサンプリングソフトマックス損失。
  - $L_{action}$ : マスクされたポジションにおける特定のアクションタイプ（クリック、保存、非表示）を予測するためのバイナリクロスエントロピー損失。
- この共同最適化により、アイテムエンベッダーは両方のタスクから同時に学習することができ、逐次的な事前学習およびファインチューニングと比較して汎化性能が向上します。
クロスステージKVキャッシュ共有 (Cross-Stage KV-Cache Sharing):
サービングの効率性に対処するため、UniPinRecはユーザー履歴のエンコーディングの計算をステージ間で再利用します。
- メカニズム: リトリーバルステージはユーザー履歴をエンコードし、その結果得られるKey-Value (KV) キャッシュを、事前に割り当てられたGPUメモリプールに格納します。ランキングステージは、別プロセスとして動作し、この同じGPUメモリをマップして、履歴を再エンコードすることなくキャッシュされた履歴を再利用します。
- 効率性: これにより、ランキングステージはフルフォワードパス（ $O(n^2)$ ）から、インクリメンタルなデコードステップ（$O(nk) $）へと変貌します（ここで$ n $は履歴長、$ k$ は候補数）。
- 実装: システムはNVIDIA Tritonを使用してサービングを行い、ANNルックアップにはFaissを使用します。Faissインデックスは、候補IDとその事前計算された埋め込みの両方を返すため、ランキング中の個別のエンベディング取得の必要性を排除します。

主な貢献

フルスタックの統一: UniPinRecは、プロダクションのレコメンデーションシステムにおいて、入力、モデル、訓練、およびサービングインフラストラクチャにわたってリトリーバルとランキングを統一した最初のシステムです。これは、2つの独立したモデルの必要性を、単一の生成デコーダーに置き換えます。
効率的なアーキテクチャ: MAMと非インターリーブシーケンスを導入することで、システムはコンテキスト長を膨張させることなく、完全な重み共有とパラメータ効率を実現します。
サービングの最適化: クロスステージKVキャッシュ共有メカニズムにより、ユーザー履歴の重複エンコーディングを回避することで、総FLOPsとレイテンシが大幅に削減されます。
運用の互換性: 設計は「ドロップイン」の置き換えが可能であり、既存の候補ジェネレーター（キーワード、トレンドなど）と構成可能であり、各ステージの独立したA/Bテストやロールバックを可能にします。

結果
システムはPinterestのコアサーフェスにデプロイされ、以下の結果をもたらしました。

オフライン性能: UniPinRecは、プロダクションのリトリーバルモデルのRecall@10に匹敵すると同時に、専用のプロダクションランカー（TransAct V2 + DCNv2）と比較して、ランキングのHit@3を14.8%向上させました。また、HSTUおよびファインチューニングされたPinRecのベースラインをも上回りました。
サービング効率: 統一されたアプローチにより、ナイーブな別々でのデプロイと比較して、エンドツーエンドのサービングレイテンシが11.1%減少し、Queries Per Second (QPS) が63.6%増加しました。KVキャッシュの再利用だけで、ランキングパスにおいて約2.4倍の高速化を実現しました。
オンラインエンゲージメント: 「Board More Ideas」および「Notifications」におけるA/Bテストにおいて：
- Board More Ideas: サーフェス保存数で**+0.95%の向上、サイト全体の保存数で+0.08%**の向上を達成しました。
- Notifications: プッシュ開封数で**+0.91%、休眠ユーザーで+1.72%、週間アクティブユーザー（WAU）で+0.09%**の向上を達成しました。

意義
本論文は、入力フォーマット、訓練、およびサービングインフラストラクチャの統一という「より困難な問題」が、プロダクション環境において解決可能であることをUniPinRecが示していると主張しています。アーキテクチャの統一を超えてフルスタックの統一へと移行することで、ユーザー履歴を2回エンコードする冗長性を排除し、コストを削減し、信号共有を通じてモデルの品質を向上させています。著者らは、これを、運用上の柔軟性を損なったり、レコメンデーションファンネルの完全な刷新を必要としたりすることなく、産業用システムが生成的リトリーバルとランキングを採用するための、実用的かつ漸進的な経路として位置付けています。今後の課題には、この統一をL2ランキングステージや、検索、広告などの他のサーフェスへ拡張することが含まれます。