LLM 時代の personalization ── Shivam Verma (Spotify AI Foundation) が公開する Foundational User Modeling / Semantic IDs / Soft Tokenization の三層設計 (AI Engineer 2026)

AI Engineer 2026 / 約 20 分

シヴァム・ヴェルマ / Shivam Verma · 19:03 「embeddings が users を、 semantic IDs が content の圧縮版を、 soft tokenization が users をモデルの token 空間に射影する。この 3 つで、旧来の recommended system モデルから sequential modeling フレームワークへと移行している」

AI Engineer 2026 (context engineering トラック、約 20 分)。講師はシヴァム・ヴェルマ / Shivam Verma (Spotify AI Foundation org、 User Representations team の Tech Lead、 London 拠点、元 Twitter ML Engineer)。同じ Spotify からは Code w/ Claude London 2026 でニクラス・グスタフソンが engineering 組織変容を公開したが、こちらは「モデル変容」 ── 個別 product ごとに siloed だった recsys が、単一の generative backbone へ統合されていく過程を、 AI Foundation 内部の視点で解説する 20 分。

Shivam の講演は、 AI Engineer 2026 の context engineering トラックに置かれている。ただし冒頭で本人が断る通り、「conventional agentic な意味の context engineering ではなく、モデル側の context engineering の話」 ── ユーザーの履歴、 query、 product surface、推薦アイテム、これらを「prompt の context」として transformer に流し込む設計の話である。 Spotify の AI Foundation org が、 product 横断で再利用される foundational model を作り、各 product team はそれを起点に推薦・検索を構築する ── という分業構造が前提にある。

MEMEX 編集視点で重要なのは、講演が描く「モデル進化のスケジュール」が、同じ Spotify から発信された Niklas Gustavsson の Honk V2 講演 (組織変容) と双子の関係にある点。 Niklas が描いたのは「engineer の働き方が AI で変わる」物語、 Shivam が描くのは「ユーザーに届く推薦の生成方式そのものが変わる」物語。一社の中で「組織」と「モデル」の二つの変容が同時進行している、という現状の縮図として読める。

Spotify の規模感 ── 7.5 億 MAU / 100M+ tracks / 184 markets

Shivam が冒頭で提示する数字:

月間アクティブユーザー (MAU) 約 750M ── アメリカ人口の 2 倍超
カタログ: 1 億曲超 + audiobook 約 40 万冊 + millions of podcasts + 動画エピソード多数
提供市場: 184 markets
user embedding model は 1B+ users に対して毎日生成される (= 毎日 10 億人分の vector を作り直す工場)

この規模で「個別 user 全員を training data に乗せる」ことは原理的に不可能。 750 M を超えるユーザー全員を一つの model の重みに焼き込むことはできない、という制約が後半の soft tokenization 設計の必要性を生む。

旧来 TradRecs ── candidate generation → ranking の多段 pipeline

Shivam は前提として「TradRecs」 (= traditional recommended systems) と呼ぶ旧来パラダイムを整理する。仕組みは:

巨大カタログ (1 億曲) から Candidate Generation 段階で数百件に絞る
Ranking 段階 (場合により多段) で並び替え
最終的に画面に出る数十曲を出力

問題は「product ごとに team が違い、 model も違う」という構造。 home shelf ranking、 personalized playlist、 search、 podcast、 ads ── それぞれが独自の team を持ち、独自の features と独自の model を抱える siloed 構造になっていた。結果として model 品質に team 間でばらつきがあり、改善が他 product に伝播しない。飲食店で言えば、同じ食材庫から調達しているのに各テーブルで別シェフが別レシピを使っているような状態。

ここから Spotify が向かっているのが単一 unified generative model ── LLM のような単一 backbone をベースに、 user が自然言語で誘導できる仕組みへ。同会場で Leonie Monigatti (Elastic) が context engineering を「80% は agentic search」と整理したのと同じく、推薦領域でも「context をどう設計するか」の問題が中核に座っている。

Foundational User Modeling ── 全 down-stream の起点となる user 表現

Shivam が率いる User Representations team の仕事は、全 down-stream model の起点となる User Embedding を生成すること。これは Spotify が保有するユーザーの全履歴 ── 何年も前からのセッション、再生、 skip、 search、滞在 ── を圧縮した dense vector で、その vector が全 product の model の入力に乗る。

生成 pipeline 自体が massive: 1B+ users 分を毎日再生成する。講演内で Shivam は「非常に高価」と認める ── 単純計算で 10 億 vector × 数日に一度では追いつかないため日次再生成、そのコストは Spotify の AI infrastructure 全体の相当部分を占めると示唆される。

Autoencoder model から sequential transformer model へ

過去パラダイム: Autoencoder モデル。 Spotify は前年の論文で user embedding model を公開しており、これが autoencoder ベースだった ── ユーザーの全 features を encoder で低次元に圧縮し、 decoder で元 features を再構成させる。圧縮 → 展開を学習させることで、中間 vector が user の本質を捉える、という標準的設計。

現行パラダイム: Sequential Transformer Model へ移行。 transformer の attention 機構を使い、 user の過去の行動 sequence を「prompt の context」として扱う。 Shivam が示すスライドでは:

user の interactions = prompt の context 部分
request context (query / product surface / 時刻等) = もう一段の context
推薦対象アイテム = 評価対象

これらを transformer layer + 多数の head で受けて、数百 millions of users のデータで学習する。比喩を借りれば「料理人が客の好みを推察するのに、過去の注文履歴を 1 枚の vector に要約してから判断する」のが autoencoder、「過去の注文を時系列で並べて、各料理に至る文脈ごと読み解く」のが sequential transformer。後者の方が「金曜の夜に頼みがちなもの」「梅雨時に頼みがちなもの」のような時間依存パターンを掬える。

同じ空間に user / track / episode を埋め込む

新しい sequential model のもう一つの性質: tracks (青)、 podcast episodes (pink)、 users (green) を同一の embedding 空間に埋め込む。 Shivam 本人の vector が big tech ポッドキャストに近接していること、「hypersphere の上でどの content の近くに自分が住んでいるか」が可視化できること、を実例として示す。これは TradRecs の siloed model では構造的に得られなかった性質 ── product ごとに別空間だった世界が、 single space に統合された。

Catalog Understanding ── Spotify 知識 + 世界知識 LLM の hybrid

user 側の話が終わると、 Shivam は content 側 (catalog 側) に話を移す。 Catalog understanding には伝統的アプローチもある ── user 側と同じく content の vector を学習する、という方式。ただし Spotify が現在組み合わせているのは:

Spotify 内部の content / entity 知識 (= 自社カタログ)
世界知識を持つ open-weight LLM (Llama、 Qwen 等)

Shivam の team は open-weight LLM を CPT / SFT で post-training し、 Spotify の catalog 知識を model に流し込む。これによって得られるもの:

Steerability ── user が自然言語で誘導できる
Better recommendations ── 世界知識との結合で品質が向上
Explainability ── なぜこの曲を推したかを言語で説明可能

ただし trade-off も明示される ── Catastrophic Forgetting のリスク。 catalog 知識を流し込む過程で世界知識が劣化する可能性。 Shivam は「これは課題だが、我々が観測してきた範囲では、これらの model は world knowledge と platform 知識をうまく組み合わせる」と述べる。

Semantic IDs ── 1000 次元 vector を 4-6 token に圧縮する

catalog 知識を LLM に教える具体的な手段が Semantic IDs 。 Google が数年前の論文で YouTube の文脈で提唱した概念で、 Spotify がそれを音楽・音声に適用している。

仕組み: content を表す 1000 次元程度の vector があったとして、それをトークン化 (= LLM の word tokenization と同じ発想) して 4-6 個の token に圧縮する。これにより LLM は通常のテキスト生成と同じ方式で、次の autoregressive 生成で「次の曲 / 次の episode」を生成できる。

階層構造の実例 ── Ariana Grande と Bruno Mars

Shivam がスライドで示す具体例: Ariana Grande と Bruno Mars はそれぞれ 6 個の token で表現される。そして先頭 2 token は両者で共有されている ── 共に pop artist だから。残る 4 token は別の値で、それぞれの niche (vocal style / 年代 / コラボレーションのパターン等) を表現する。

ここに hierarchical structure がある。比喩で言えば、郵便番号の先頭桁が国・地域、末尾桁が街区を示すのと同じ ── token 列の前半が大カテゴリ、後半が niche を担う。これは vector のままでは得られない、「LLM が解釈可能な圧縮表現」という性質を生む。

実際の推論時には、 user の Spotify URI 履歴 (例: イタリアの podcast を聴いてきた user) を semantic ID 列に変換、 model に流し、「次に聴かれる episode」の semantic ID を autoregressive に生成し、それを実 episode に紐付けて返す ── という pipeline が動く。

Soft Tokenization ── user を LLM の token 空間に注入する

catalog の話と user の話を合流させる最後のピースが Soft Tokenization 。

問題設定: catalog 知識を LLM に焼き込んでも、 user 個別の personalization はまだ実現できない。 750M users 全員を training data に乗せることは不可能だから ── どうしても collaborative filtering 的な汎化に頼ることになる。でも model は本来 personalized であるべき。

Shivam の team の答え: user model (= 前半で説明した user embedding) を、 LLM の token 空間に射影する。ある user 用に推薦を生成する瞬間、その user の embedding vector が線形変換を経て LLM 内部の「1 個の token」として扱える形になる ── これが soft token。

流れを比喩で言えば:

通常の token = 辞書から拾った単語 (離散、固定)
soft token = 「この user の魂を蒸留した 1 滴の油」を prompt の中に垂らす (連続、 user ごとに変わる)

生成時、 LLM は context に注入された soft token を経由して、「この user に対して」の推薦を返す。同じ catalog 知識・同じ system prompt でも、 user の soft token が変われば出力も変わる ── これが unified backbone + per-user personalization を両立させる仕掛け。

Shivam は内部 metric で positive な結果を確認していると述べる。さらに「実際に Spotify で podcast を聴いていて、 next episode を提示されているなら、それは this のような pipeline から来ている」と本番投入を明言。講演時点で productionized されている事実が、単なる研究発表ではなく現場稼働の報告である点を強調する。

Discover Weekly (2015) からの 10 年 ── 機能の系譜

Spotify の personalization 進化を、ユーザー向け機能の系譜で振り返ると:

Discover Weekly (2015) ── 機械学習 recsys の象徴的 product。当時の Shivam は大学院生
AI DJ ── 自然言語で対話、曲を勧めてもらう / 流してもらう
Prompted Playlists ── prompt を入れるとカスタムプレイリスト生成。講演時点 (この週) で podcast にも拡張
Taste Profile ── Spotify が user について把握している内容を可視化し、「これは残す / これは忘れて」を選べる product。一部 market 先行、 2026 後半により拡大予定

最後の Taste Profile は、後半の soft tokenization と直接結びつく。 user が profile を編集すると、その edit が generative model 側に戻り、 model の user 理解と推薦能力が更新される ── 「context をユーザー側から編集できる recsys」という新しい product 形態。

「sequence → vectors → tokens」という設計 evolution

Shivam が講演全体を通して描く evolution は明快:

Sequence of actions ── user の行動履歴 (生データ)
Vectors ── autoencoder / sequential transformer で圧縮された embeddings
Tokens ── semantic IDs / soft tokens に変換された LLM 互換表現
LLM ── tokens + vectors + LLM を組み合わせて personalized 推薦を生成

これは Karpathy が AI Ascent 2026 で語った Software 1.0 / 2.0 / 3.0 の進化の recsys 版とも読める ── 明示的ルール → 学習された重み → LLM プロンプティング、という流れが、 recsys では多段 pipeline → embedding model → semantic ID + soft token + LLM、という形で現れている。

着眼点

業界全体の「siloed → unified」シフトと Spotify の先導役

recsys 業界では長く、 product ごとに専用 model を抱える siloed 構造が標準だった。 Shivam の講演は、業界全体がそこから「単一 unified backbone」へシフトしている事実、そして Spotify がその leading 例の一つである事実を確認する。 LLM の汎用性を recsys に持ち込むことで、個別 product の改善が他 product にも自動的に伝播する ── ここに pre-LLM 時代との断絶がある。

Niklas Gustavsson の Honk V2 講演で言及された「Pre-AI infrastructure 投資が AI 時代に二次効果を生む」構造論と相似形 ── 個別 model 群を統合する unified backbone があれば、そこに soft tokenization のような後発手法を「上に乗せる」ことができる。統合層を持たない競合は、個別 product ごとに同じ改善を 1 つずつ実装し直す必要がある。

Semantic IDs の階層構造 ── Ariana Grande と Bruno Mars が共有する先頭 2 token

semantic ID の最も興味深い性質は、 token 列に階層が宿ること。先頭 2 token が一致 = 大カテゴリ (pop) の共有、残り 4 token が異なる = niche の差異。これは vector のままでは陽に観測できない構造で、 LLM が autoregressive 生成する時に有用に働く ── 「先頭 token は pop の何か」と決まれば、後続 token の探索空間が劇的に絞られる。

比喩で言えば、数百万曲を 4-6 桁の郵便番号で「住所」として圧縮するようなもの。国・地域・市・番地、と階層的に絞っていくと、 1 億曲が 4-6 個の整数列で識別可能になり、 LLM の語彙に組み込める。この階層性が catalog understanding を計算可能にする鍵。

Soft Tokenization で「個別 user」を generative model に注入する設計

soft tokenization は、「training data に乗らない user をどう personalize するか」という根本問題への解答。 750M users 全員を model の重みに焼き込むことはできない、けれど推論時に「この user の vector」を 1 個の soft token として prompt に混ぜることはできる。これにより、 unified backbone が generic な model でいながら、推論時に user ごとに違う出力を返せる。

設計思想として注目すべきは、「user は学習対象ではなく context として扱う」という整理。 model は全 user を学ぶのではなく、「ある user の vector を受け取った時にどう推薦を出すか」を学ぶ。 user を context として扱う、という発想転換がこの設計の中核。同じ AI Engineer 2026 で Leonie Monigatti が論じた「context engineering」が recsys 領域で具体化した一例とも読める。

動画の構成

(00:00) 自己紹介、 Spotify ユーザー挙手
(00:36) 「conventional な意味の context engineering ではなく、モデル側の context engineering の話」
(01:04) Shivam の役割 ── User Representations team Tech Lead in AI Foundation org
(01:23) 経歴 ── 元 Twitter ML Engineer、 London 拠点
(01:30) 講演 3 本柱の宣言 ── Foundational User Modeling / Catalog Understanding / Combining
(02:09) 「sequence of actions → vectors → tokens → LLM」の設計 evolution
(03:00) Spotify の規模 ── 750M MAU / 100M+ tracks / 184 markets
(03:46) 機能進化 ── Discover Weekly (2015) → AI DJ → Prompted Playlists → Taste Profile
(05:19) TradRecs の整理 ── candidate generation → ranking の siloed pipeline
(06:05) siloed model から unified backbone への業界シフト
(06:53) Foundational User Modeling の説明開始
(07:20) 1B+ users 分の embedding を毎日生成する pipeline 規模
(07:41) 旧 autoencoder model の説明 (前年論文)
(08:26) sequential transformer model への移行
(09:13) user interactions = context として transformer に流し込む
(09:35) 同一空間に user / track / episode を埋め込む実例 (Shivam 本人の embedding 可視化)
(11:33) Catalog Understanding の話に移行
(11:50) Spotify 知識 + 世界知識 LLM (Llama / Qwen) の hybrid 設計
(12:18) catastrophic forgetting の trade-off 言及
(13:02) semantic IDs の導入
(13:17) Google 論文起源、 YouTube で実証、 Spotify で適用
(13:50) Ariana Grande / Bruno Mars の 6 token 表現、先頭 2 token 共有 (pop)
(15:02) Italian user の listening 履歴を semantic ID に変換して LLM に流す pipeline
(15:38) prompt 構造の実例 (Spotify URI → semantic ID → next episode 予測)
(16:14) 3 つ目の柱 ── catalog と user を combine する話
(16:37) Taste Profile product の紹介と soft tokenization との接続
(17:25) user 個別の personalization が collaborative filtering だけでは不十分な理由
(17:45) soft tokenization の説明 ── user 表現を LLM token 空間に射影
(18:11) soft token を prompt に挿入 → personalized 推薦生成
(18:30) 内部 metric で positive な結果、 productionized 済み (podcast next episode)
(19:03) 全体まとめ ── embeddings / semantic IDs / soft tokenization の三層
(19:48) 締め、 connect の呼びかけ

出典

Personalization in the Era of LLMs — Shivam Verma (Spotify、 AI Engineer 2026、約 20 分)
Spotify Research blog ── user embedding / foundational model 系の公開研究
Recommender Systems with Generative Retrieval (Google、 Semantic IDs 提唱論文)
Spotify Engineering blog

シヴァム・ヴェルマ

Shivam Verma

Spotify AI Foundation org / User Representations team Tech Lead (London 拠点、元 Twitter)

用語集

Foundational User Modeling: Spotify AI Foundation org が全 down-stream recsys の起点として構築する user 表現モデル。 1B+ users の embedding vector を毎日生成し、各 product team の model がそれを入力として使う。個別 product ごとに siloed だった model 設計から、「user 表現は共通基盤、 product は上で組み立てる」という分業構造への転換を象徴する。
Semantic IDs: content (曲 / artist / podcast episode 等) を表す vector を、 LLM が扱える 4-6 個の離散 token に圧縮する手法。 Google が数年前の論文で YouTube の文脈で提唱、 Spotify がそれを music / audio に適用。 token 列には階層構造があり、先頭 token ほど大きな分類、後ろの token ほど niche な特徴を表現する。 Ariana Grande と Bruno Mars は先頭 2 token を共有する (pop)。
Soft Tokenization: user の embedding vector を線形射影で LLM の token 空間に変換し、 prompt の中に「user を表すトークン 1 個」として埋め込む手法。通常の token (テキスト) は離散的だが、 soft token は連続的な vector のまま勾配を通せる。これにより、 750M users 個別の context を unified backbone モデルに注入できる ── 学習データに焼き込まずに personalization を実現する仕掛け。
Sequential Transformer Model: ユーザーの行動履歴を時系列の sequence として扱い、 transformer の attention 機構で「過去の何が現在に効くか」を学習させる model。 NLP の transformer が word 系列を扱うのと相似形。 Spotify では autoencoder ベースの user embedding から、この sequential transformer ベースへ移行している。
Candidate Generation: 多段 recsys の第一段。 1 億規模のアイテム集合から、ユーザーに関連しそうな候補数百件まで絞り込む。 ann (近似最近傍検索) や two-tower モデルが代表手法。後段の ranking model の計算コストを抑えるためのフィルタとして機能する。
Ranking: 多段 recsys の第二段以降。 candidate generation で絞られた数百件を、 user との適合度で並び替える。多くの場合 ranking model は複数段あり、最終的に画面に表示される 10-20 件の順序を決める。 Spotify では home shelf / search / podcast / ads 等の product ごとに ranking team が分かれていた。
Discover Weekly: 2015 年から Spotify が提供する、毎週月曜に user 固有の 30 曲プレイリストが自動生成される機能。業界に大きな影響を与えた、 personalization の代表事例。機械学習による協調フィルタリング + 自然言語処理 + 音響特徴量を組み合わせた当時最先端の構成。 Shivam は「2015 年、大学院生時代に最もクールに感じた tech 製品の一つ」と振り返る。
AI DJ: ユーザーが自然言語で対話できる AI DJ 機能。質問すると曲を提案し、再生する。 LLM の steerability を Spotify product に直接持ち込んだ事例。「次は 80 年代のロックで」のような誘導が会話形式で可能。
Prompted Playlists: ユーザーが自然言語の prompt を入力すると、それに合った曲のプレイリストを生成する機能。講演時点 (2026 春) で podcast にも拡張された。 LLM + Spotify catalog 知識 + user 個別 embedding を組み合わせた generative recsys の現れ。
Taste Profile: Spotify が user について何を知っているかを user 自身に open に提示し、「これは残す / これは忘れて欲しい」と編集できるようにする機能。一部 market で先行提供、 2026 後半により広く展開予定。 personalization の透明性と user agency を高める実装で、 soft tokenization で生成 model に user 編集を反映する pipeline と直接連動する。
Autoencoder: 入力データを低次元の latent vector に圧縮 (encoder)、そこから元データを再構成 (decoder) するニューラルネット。 NLP / computer vision で広く使われた古典的手法。 Spotify は前年公開の論文で user の features を autoencoder で圧縮し dense vector を得ていた。シンプルだが、 sequential な順序や時間構造を陽に扱わない欠点があった。
Catastrophic Forgetting: 既存知識を持つモデルに新しいデータで継続学習をかけると、元々持っていた知識が劣化する現象。言語モデルに domain 特化データだけで CPT をかけると、一般的な world knowledge が抜け落ちることがある。 Spotify は world knowledge を残しつつ catalog 知識を統合するために、学習データの混合比や training schedule に注意を払う必要がある。
CPT / SFT: CPT = Continued Pre-Training (継続事前学習)。既に事前学習済みのモデルに、ドメイン固有のデータでさらに事前学習を続けて知識を注入する。 SFT = Supervised Fine-Tuning (教師あり微調整)。 prompt と理想出力のペアでモデルを微調整する。 Spotify AI Foundation org は両方を組み合わせて Llama / Qwen 等の open-weight LLM に Spotify catalog 知識を埋め込んでいる。
AI Foundation org: Spotify 社内で全 down-stream recsys が依存する foundational model を構築する横断組織。 user representations / content representations / open-weight LLM の継続事前学習 (CPT) や教師あり微調整 (SFT) を担当。個別 product team が抱える siloed model を、単一の unified backbone へ収斂させる役割。 Shivam Verma は User Representations team の Tech Lead としてこの組織に属する。