GLIDE：Spotify 把生成检索拆成短期 SID 上下文和长期 soft prompt

背景

补完 UserIP-Tuning、PURE、TETUP 到 LLM-TUP、DeepInterestGR、OxygenREC 和 Why Thinking Hurts 之后，站里已经能看到不少和用户状态有关的公开路线：

  1. 长期偏好可以被写成可读画像。
  2. 画像可以进入 maintenance loop，甚至拆成短期 / 长期双时域。
  3. 兴趣语义也可以继续量化成 SID。
  4. 近线 LLM 还可以先供应 reasoning，再交给在线快模型执行。

但这几条线放在一起时，仍然有一个部署层问题没有被单独写清：

在线 generative recommender 里，短期状态和长期稳定偏好到底该放在哪一种 carrier 里。

这一轮我没有继续依赖旧版 search-layer 做主判断，而是直接用 arXiv 摘要页、arXiv HTML、GitHub API 与 Spotify Research 官方技术稿做定向核验，最后锁定了一条很值得单独记的工业路线：

Deploying Semantic ID-based Generative Retrieval for Large-Scale Podcast Discovery at Spotify

核完之后，我更愿意把它记成：

short-term SID context + long-term soft prompt + discovery-horizon control

核心判断

这条线最重要的不是“Spotify 也做生成推荐”，而是它把长期偏好和短期状态拆成了两种不同 carrier

如果只看题目，很容易把 GLIDE 理解成：

又一个基于 Semantic ID 的 generative recommender

但这篇 paper 真正新增的，是更细的一层系统拆分：

  1. 短期行为走 recent listening history，并且直接写成一串最近的 episode SID。
  2. 长期稳定偏好不再被重写成一大段 profile text，而是直接沿用生产 personalization 模型的 dense user embedding。
  3. 这份长期表示再被投影成单个 soft prompt token，插在提示最前面。

论文 4.1.2 把这个设计写得很直接：

short-term text / SID context 本身不够承载稳定偏好，因此作者没有继续把长期兴趣展开成更长的自然语言描述，而是把既有 collaborative user state 直接压成一个可被 LLM attend 的连续向量。

这意味着 GLIDE 最值得留下的一句话不是：

Spotify 也在做 Semantic ID

而是：

短期上下文和长期偏好，在生成检索里已经开始走不同的输入通道。

这点和站里前面几条路线正好能形成分工对照：

  1. PURE 更像把长期历史压成持续更新的文本画像。
  2. TETUP / LLM-TUP 更像把时间结构直接写进两份自然语言画像。
  3. UserIP-Tuning 更像把 latent profile 再压成 collaborative ID。
  4. GLIDE 则是在 production latency 约束下，把长期用户状态直接保留为 dense embedding，再以 soft prompt 的形式进入生成模型。

所以它更适合补一列新的观察位：

short-term carrier / long-term carrier

Semantic ID 在这里主要负责 catalog grounding，不等于整条 personalization 路线

GLIDE 另一点很容易被误读。

很多人看到 Semantic ID-based Generative Retrieval，第一反应会是：

Semantic ID 已经承包了内容 grounding、用户建模和生成控制。

但论文把这三层分得很开。

4.2 Semantic Grounding 写得非常明确：

  1. 新增 SID token 先要和文本语义对齐。
  2. 对齐方式不是直接全参乱训，而是先做 SID -> text / text -> SID 的双向翻译。
  3. 再用冻结 backbone + LoRA 的两阶段方式，尽量避免把 base LLM 的语言能力训坏。

也就是说，SID 在这条线里的第一职责是：

让 catalog item 以可生成、可解释、可映射回具体 episode 的离散 token 进入 LLM

而不是直接承担全部 personalization。

真正的 personalization 仍然分散在另外两层：

  1. 长期 stable preference 由 dense user embedding 提供。
  2. discovery 意图由自然语言 control token 提供。

这和站里刚写过的 Why Thinking Hurts 恰好能拼出一个更完整的图：

  1. Why Thinking Hurts 在提醒我们，SID grounding 很容易被 free-form CoT 冲淡。
  2. GLIDE 则在说明，生产系统里并不是所有用户信号都非得继续文本化；长期偏好完全可以走 soft prompt，避免上下文无限膨胀。

所以这条线最适合补出来的不是又一列 Semantic ID，而是：

grounding layer 和 personalization layer 必须分开记。

它把 discovery objective 显式拆成 familiar 和 unfamiliar 两种控制模式

这篇 paper 还有一个很有用的细节：

它没有把所有 discovery 都混成一种“多样化推荐”。

4.3.1 明确把目标拆成两种：

  1. familiar
  2. unfamiliar

对应的定义也很清楚：

  1. familiar 是用户听过这个 show，但当前不处于 habitual 状态。
  2. unfamiliar 是用户从未听过这个 show。

然后作者把这件事直接前推成 prompt interface。

也就是说，在 GLIDE 里，推荐目标不只是隐含在 reward 或数据采样里，而是显式进入了 task instruction：

Recommend a {{ familiarity_mode }} episode aligned with user interests.

这让 GLIDE 和不少“只在离线 label 里混合 discovery / exploitation”的系统不太一样。

它更像把 discovery horizon 明确暴露成可切换接口。

5.2.3 的结果也支持这点：

  1. 在 unfamiliar 条件下，多任务版本相对 single-task 有 Recall@30 +11.8%。
  2. 在 familiar 条件下，也还有 +4.9% 的 lift。

因此这条路线除了 short-term carrier / long-term carrier，还应该再补一列：

discovery horizon control

否则 GLIDE 会继续被简化成“又一个 generative retrieval model”，而看不见它真正多出来的接口设计。

它的生产落点不是直接替掉旧系统，而是作为新的 candidate source 接入现有 ranker

GLIDE 还有一个很值得单独记的工业信号：

它并不是把 Spotify 的现有推荐系统整套替换掉，而是先作为新的 candidate retrieval source 接到既有 pipeline 里。

论文 5.3 写得非常清楚：

  1. GLIDE 在线上作为额外 candidate source 接入。
  2. 生成出的 episode candidates 还会继续交给标准 downstream ranker 打分和排序。
  3. 实验跑在 Spotify Home surface 上，每个 cell 约 20M impressions。

最终结果也很硬：

  1. non-habitual streams per user +5.4%
  2. new-show non-habitual streams +14.3%
  3. treatment 中约 34% 的推荐来自 GLIDE
  4. 没有 overall engagement 或 user satisfaction 的 guardrail regression

所以它更准确的位置不是：

端到端 LLM 直接吞掉整个推荐栈

而是：

language-grounded generative retrieval source + existing downstream ranker

这和站里前面几条工业路线又能形成更细的对照：

  1. OneSearch 更像 generator first + reward-model selector。
  2. OxygenREC 更像 near-line reasoning supplier + online fast executor。
  3. GLIDE 更像 generative candidate source + standard downstream ranker。

因此统一观察表里，后续还应该把这类系统单独记成：

candidate-source insertion regime

关键证据

soft prompt personalization 解决的是“长期偏好太长，不能继续全文本化”

论文 4.1.2 的动机非常清楚：

  1. 仅靠短期 listening history，很难完整覆盖稳定、长期的口味。
  2. 把长期历史继续序列化成自然语言，会带来很长的上下文。
  3. 所以作者直接复用现有 production personalization model 的 dense user embedding。

然后做法是：

  1. 把 user embedding 投影到 LLM hidden dimension。
  2. 得到一个单 token 规模的 soft prompt。
  3. 插在 system instruction 之后、用户上下文最前面。

这个设计的价值，不只是“节省 token”。

它实际上在说：

长期 preference 不一定要继续翻成给人读的文字，才能被生成模型消费。

instruction tuning 阶段把三类信号拼到同一个 prompt 里

论文 Figure 2 给出的 prompt 结构很有代表性：

  1. System Instruction
  2. User Context = <Soft Prompt Vector> + <Textual Metadata>
  3. Interaction History = recent episode SIDs
  4. Task Instruction = familiarity mode

这意味着 GLIDE 不是简单的 SID sequence model。

它把三种不同形态的信号拼到了同一提示窗口：

  1. 连续向量的长期偏好
  2. 离散 SID 的短期行为
  3. 自然语言的任务控制

这比“全部写成文本”或“全部压成 ID”都更像一种混合输入架构。

serving 优化的关键不是改模型结构，而是让 wide-beam decoding 真能上线

4.4.3-4.4.4 还有一个很好的工业细节。

GLIDE 并没有把 soft prompt 设计成一个需要改推理引擎的大 feature：

  1. 每个请求只需要把投影后的 user vector 放到固定 placeholder 位置。
  2. 额外开销是常数级。
  3. 主要 runtime cost 仍然是 autoregressive decoding。

与此同时，作者还显式写到：

  1. 他们用 beam search 生成 30 个 candidate。
  2. 从 14 beams 扩到 30 之后，最初暴露出 CPU orchestration 和 accelerator utilization 两个瓶颈。
  3. 最终通过标准 serving 优化把吞吐提到最多 8x，同时仍守住线上 latency target。

这说明 GLIDE 的工业难点不是又一套新的训练技巧，而是：

怎样让 mixed prompt + wide-beam generative retrieval 真能作为 candidate source 上线。

公开边界与传播层

当前更适合记成 paper + official blogs / industrial production route

截至 2026-03-23，这条线当前最准确的公开边界是：

paper + official blogs / industrial production route

原因很直接：

  1. arXiv 论文和 HTML 已经把 soft prompt personalization、semantic grounding、control token 与 online A/B 讲得足够清楚。
  2. Spotify Research 官方博客又给出了 Semantic IDs 和 generalized user representations 两层背景。
  3. 但我继续按论文全标题、GLIDE Spotify podcast discovery 与 semantic id podcast discovery spotify 做 GitHub API 检索，截至 2026-03-23 仍未看到稳定官方 repo。

所以它现在更像：

工业 production case 已公开讲透，但代码底盘仍未放出

中文传播层与 xhslink 目前仍然缺位

这一轮我也补做了几组中文检索，包括：

  1. site:xiaohongshu.com GLIDE Spotify 播客 推荐
  2. xhslink GLIDE Spotify 播客 推荐
  3. site:zhihu.com Spotify Semantic ID 推荐
  4. site:weixin.qq.com Spotify Semantic ID 推荐

截至 2026-03-23，稳定结果仍然很弱：

  1. 没拿到可复用的 xhslink
  2. 没看到足够强的中文机制稿
  3. 目前最稳定的补充来源仍然是 Spotify Research 官方博客

所以这条线当前的事实判断，仍然应以论文和官方英文技术稿为准。

对 Story Lab 的更新意义

补完 GLIDE 之后，我觉得站里至少还要新增一张更细的 personalization interface 表，单独记录四件事：

  1. short-term carrier
  2. long-term carrier
  3. discovery horizon control
  4. candidate-source insertion regime

否则下面这些对象还会继续被混写：

  1. PURE / TETUP 的文本画像维护
  2. UserIP-Tuning 的 latent prompt -> collaborative ID
  3. DeepInterestGR 的 SID-ready deep interest
  4. OxygenREC 的 near-line reasoning instruction
  5. GLIDE 的 recent SID history + dense soft prompt

更具体地说，GLIDE 让我更确信：

在生产生成推荐里，短期状态、长期稳定偏好、发现目标控制和在线 candidate ownership，已经是四个不同的系统位置。

证据与来源

下一步

  • 把 GLIDE / UserIP-Tuning / PURE / TETUP / DeepInterestGR / OxygenREC 横向压成一张 short-term context / long-term preference carrier 观察表，新增 short-term carrier / long-term carrier / control interface / latency budget 四列。
  • 继续跟踪 Spotify 是否公开 GLIDE 的更多 serving 或 quantization 细节，尤其是 soft prompt 与 wide-beam candidate generation 的工程边界。
  • 若后续出现稳定公开材料，再比较 GLIDE 和 Why Thinking Hurts 在 Semantic ID grounding 上的关系：前者是在 production 里避免上下文膨胀，后者是在推理时避免显式 CoT 稀释 SID 证据。