TSPORec:学会挑信息量最大的 token,64 个顶 HLLM 的 256 个

TSPORec: Token Selection via Preference Optimization for LLM-Based Sequential Recommendation

Wenqiao Zhu, Chao Xu, Haipang Wu, Ji Liu

cs.IR, cs.AI

2026-08-10

TSPORec 为 LLM 序列推荐学一个 token 选择策略,挑出物品描述里最关键的 token;64 个顶 HLLM 的 256 个,NDCG 最高 +31.25%,推理省六成。

这篇在解决什么

用大模型做序列推荐(sequential recommendation,根据用户最近的点击序列预测下一个要推什么)有个绕不开的贵:一次推理要把用户历史里每件物品的文本描述都喂进去,历史长 S 件、每件 n 个 token,就是 S×n 个 token 全过一遍 LLM,又吃算力又吃显存。

业界一个常见省法是只取每件物品描述的前 k 个 token。问题是文本信息大量丢在后面:一本书的题材、一个游戏的玩法关键词,往往不在开头。论文给了一组对照说明这有多伤:在 Amazon Books 上,HLLM(一个有代表性的 LLM 序列推荐框架)取前 k 个 token 能比传统 ID 基线 SASRec 高 24.4%,但改成随机取 token,增益就掉到 2.14%。取哪些 token,比取多少更决定效果。更反直觉的是,取「logit 最大的 k 个 token」(一个看似更聪明的选法)并不比朴素取前 k 个好,作者把这归因于标准 LLM 注意力是单向的,token 的隐藏状态抓不到足够的协同信号。

TSPORec 要回答的问题是:能不能学一个策略,从全文里挑出对推荐真正最有信息量的那些 token。

方法

三阶段管线。

第一阶段,照常用 InfoNCE 损失(对比学习里把正样本拉近、负样本推开的常用目标)预训练一个 LLM 序列推荐模型,分物品 LLM 和用户 LLM。物品 embedding 取特殊 [ITEM] 位置最后一层隐藏状态。

第二阶段,冻结刚训好的 LLM 主干,挂一个小的策略头,专门学「挑哪些 token」。关键是怎么定义「有用」,又不用穷举所有子集(组合爆炸)。作者设计了代理奖励:对同一件物品,用策略采样出两份不同的 token 子集,分别拼进用户历史、过冻结的 LLM 算出两个用户 embedding,再分别和该物品的完整 embedding 算交叉熵(带 128 个负样本)。哪份子集的交叉熵更低,说明它替用户「锁住」这件物品锁得更准,就更 informative。奖励就是 +1 或 −1 的偏好信号,目标函数最大化这个期望奖励。

这里有个设计上的讲究。策略打分用的是双向的 query-key 注意:把每个 token 的隐藏状态和物品级表征 h{k+1} 算对齐,得到该 token 的信息量分数。这绕开了上面那个「单向注意力抓不到协同信号」的毛病,让语义信号和协同信号一起进来。选择还做成 chunk 级(连续 c 个 token 一组,取 ⌊k/c⌋ 组),粒度可控;实测 chunk 越小效果越好,论文取 c=8。

第三阶段,用训好的策略给每件物品挑出高概率的 token 组,重构数据集,把 LLM 在精简后的输入上重训一遍。

论文还给了一个定理(Theorem 1)给这套做法兜底:交叉熵越小,对应的用户分布对真值偏好分布的 KL 散度越小(即更贴近真偏好);两份子集里重叠的 chunk 对策略梯度没有贡献;优化目标确实在抬升 informative chunk 的概率、压低其它的。

结果

两个公开数据集(Amazon Books、Pixel),两个 backbone(Qwen3-Embedding-0.6B、TinyLlama-1.1B),文本截到 64 token。指标是 Recall@K 和 NDCG@K。

Qwen3-Embedding-0.6B,64 token,Amazon Books:

方法R@5R@10N@5N@10
SASRec(ID 基线)3.385.092.242.79
HLLM(first-k)4.166.292.803.48
TSPORec4.376.552.943.64

Amazon Books 上相对 SASRec 最高 Recall +29.29%、NDCG +31.25%,六个指标平均 +29.43%;Pixel 数据集上最高 Recall +19.63%、NDCG +18.24%,平均 +16.79%。换 TinyLlama-1.1B backbone 仍稳定领先 HLLM 平均 +4.12%,把 TSPORec 选的 token 喂给另一个推荐模型 LLMinit 也能涨 3.76%,说明选出来的 token 带的是可迁移的信息,不是某个 backbone 的偏好。

效率方面,TSPORec 只用 64 个 token 就追平甚至超过 HLLM 用 256 个 token 的效果。在 H100 上测,64 token 一条推理 326 ms,256 token 要 843 ms。物品 embedding 离线算时省 63.4%,全在线服务时省 61.3%。代价是多花训练时间:三阶段比单阶段多约 21.5 小时(8 张 H100),但模型只训一次。

为什么重要

对做推荐的人来说,LLM 进推荐系统的最大阻力一直是推理成本,而这篇把成本刀砍在了「输入长度」上,同时没拿效果换。更值钱的观察是那个反直觉结论:选哪些 token 比选多少重要,朴素的「取前 k 个」和看似聪明的「取 top-k logit」都不如学一个带协同信号的选择策略。这套「学一个 token 选择器加代理奖励」的范式,理论上不绑死推荐,任何「长文本喂进 LLM 太贵、又只需要其中信息密集片段」的场景都能借。

局限与存疑

方法本身有两段没完全说透。一是代理奖励依赖「子集交叉熵更低等于更 informative」这个假设,它用完整 embedding 当锚,但完整 embedding 本身就是被截断文本训出来的,存在循环依赖的风险,论文没讨论。二是评估只在两个数据集、两个 backbone 上,两个都是文本密集型推荐场景,对文本稀疏、强依赖 ID 协同信号的工业场景能不能迁移,没有证据。三阶段多出来的 21.5 小时训练成本,作者以「模型只训一次」来豁免,但对频繁重训的线上推荐系统这个前提不一定成立。最后,论文的 case study 显示策略偏好内容词、过滤高频虚词,但这只是事后解释,没有对照实验证明「正是这种偏好带来了增益」。

术语

原文与代码

社区讨论

相关论文

全部论文解读