LLM4Rec 在业界的应用范式梳理

LLM4Rec 在业界的应用范式梳理 | 极客日志

LLM4Rec 在业界的应用范式梳理

随着近年来 LLM 的各种突破性进展，工业界也在不断尝试将 LLM 与推荐系统结合起来，以期吃到 LLM 带来的技术红利。最近一年各大互联网公司相继提出了各种落地 LLM4Rec 的方案。本文希望能从更加全面且细致的维度梳理这些技术方案，以期对 LLM4Rec 形成更加体系性的认识。

最近一年业界 LLM4Rec 的工作整体可以划分成 3 类范式：

LLM-to-Rec: 以推荐系统为主导，主要使用 LLM 的能力做特征增强/样本增强等，以提升推荐系统的整体效果。这种方式成本相对可控，是工业界尝试最多也是相对比较容易拿到收益的方式。

Rec-to-LLM: 以 LLM 为主导，将推荐系统的用户行为用自然语言形式描述，以期 LLM 能捕获用户兴趣。这种方式主要应用在对 LLM 特别擅长领域有特别要求的业务场景，比如对会话能力有要求的对话式推荐系统，以及对推理能力有要求的可解释性推荐场景等。

Towards RecLM: 这里的目标是探索推荐系统的 Scale Law，以期能通过拓展模型参数量、数据量、算力或其它要素显著提升推荐效果。这种方法可能非常吃算力/成本，其中最引起广泛讨论的就是 Meta 提出的 GRs 了。

本文整体的思维导图如下图所示，基本上覆盖了最近一年 LLM4Rec 的重点工作：

LLM4Rec 思维导图

1. LLM-to-Rec 范式

随着 ChatGPT 的爆火，各大公司&机构纷纷加入了 LLM 军事竞赛之中，LLM 的综合能力也是屡破新高。预训练的 LLM 现在已经具备非常丰富的世界知识，这是传统以 ID 为主并以协同信息为监督信号的推荐算法所欠缺的。相对而言，将预训练 LLM 应用于推荐场景是一种成本比较可控的方式。但在将 LLM 应用于推荐系统的过程中，根据不同的业务场景特点及成本因素考虑，工业界在使用 LLM 的方法上有着很大的区别。

LLM-to-Rec 细分结构

1.1 利用 LLM 的哪些信息？

LLM 拥有非常优秀的综合能力，并且积累了很多可被推荐借鉴的一些实践经验，在 LLM-to-Rec 的范式下，首先要回答的第 1 个问题是，在实际应用中，LLM 有哪些实践经验或者有用信息可以被推荐借鉴或使用的呢。

1.1.1 借鉴 LLM 的有效经验

LLM 领域的发展沉淀了很多不错的实践，比如 LLM 的架构的有效性已被大量验证，检索增强是提升 LLM 表现的一大利器，好的 Prompt 对 LLM 的效果提升至关重要等。

1) 借鉴 LLM 架构 (快手 KuaiFormer 方法)

快手这里的 KuaiFormer 直接以 Llama Transformer 架构作为 Backbone，并结合快手的业务场景进行训练上的适配和优化，除了用了架构，基本上和 LLM 本身没有太大关系了，其整体框架如下图所示：

KuaiFormer 框架

这里只简单做些介绍，主要的思想包括：

扩展至更长的序列长度 (从 64->256): 作者将用户历史行为序列，按交互时间顺序分成了早中晚 3 部分（早 642 组、中 165 组、晚 164 组），对早中部分分别做了聚合处理。
扩展至多兴趣: 作者这里使用了多个特殊的 token 作为用户的各兴趣 query token，将这个 token 对应位置的输出作为用户的多兴趣表示。
加速训练: 在数十亿候选 Item 量级下，基于 Transformer 架构下，传统 softmax 的效率太低，为加速训练，使用 In-batch softmax + LogQ 方法。
标签平滑: 作者引入标签平滑方法，避免使用严格的 0-1 标签进行模型训练。

2) 借鉴检索增强思想 (WWW'24|华为 RAT 方法)

华为这里提出 RAT 方法借鉴 LLM 的检索增强的思想来提升推荐效果，其整体框架如下图所示：

RAT 框架

这里也简单介绍其思想，主要包括：

使用 BM25 算法基于 target sample 从内容池里检索出个样本，用于下面的样本增强。
为检索样本与目标样本增加一个 Field 标识，使得样本对应的输入变成特定格式。
解耦样本内&跨样本间的特征交叉，以提高计算效率。

RAT 细节

3) 借鉴提示学习思想 (快手 RecGPT 方法)

快手这篇论文提出的 RecGPT 首先会预训练个性化自回归生成的 Transformer 模型，然后会使用这个预训练模型，为每个用户请求基于 user id 和用户行为序列 item id 构建生成个性化提示，得到个性化提示后再加入原用户行为序列中作为补充。其大致流程简化如下，有种流水线作业的即视感：

RecGPT 流程

上图中的个 Item 就充当着个性化提示的作用，加入到用户行为序列中作为片段进行补充。不过这种强加 Item 作提示的方法，有效性并不令人信服，线上也没有特别好的收益，不过多陈述。

1.1.2 利用 LLM Embedding

传统基于 ID 的推荐模型在语义信息/内容理解上是比较缺乏的，这也使得其在新冷内容/长尾内容上表现欠佳。LLM 可以基于用户和物品信息生成用户和物品的 Embedding 向量，而这些 Embedding 向量蕴含着丰富的语义信息，可以作为传统基于 ID 的推荐模型的一个很好的信息补充。LLM(以及多模态 LLM) 的 Embedding 由于具有格式统一&语义信息丰富&易于获取等诸多优点，现有 LLM-to-Rec 的主流方法多是利用 LLM Embedding 信息。

常见的获取 LLM Embedding 的方式有三种：

1) 通过 Embedding API 方式 (Google STAR 方法)

Google 提出的 STAR 方法首先将 Item 的标题、描述、类目、品牌、销售量排名以及价格等信息都输入到提示中，然后再通过 LLM 的 Embedding API 直接获取语义向量。下图给出了一个提示的示例：

STAR Prompt

2) 取某一隐含向量做 Pooling (AAAI'25|快手 LEARN 方法)

快手提出的 LEARN 方法首先对用户行为序列中的每个 Item，先按下图的提示组织其文本描述 (包括标题、类别、品牌、价格、关键词和属性)：

LEARN Prompt

然后，再将这些 Item 描述输入到参数冻结的预训练 LLM(论文使用了 Baichuan2-7B) 中，最后，再将最后一层的隐含向量做 AvgPooling 后得到该 Item 最后的内容表征。

3) 通过增加特殊 Token 方式 (WWW'24|NoteLLM 方法)

这种方式业界使用的也比较多，比如 Meta 里的 EmbSum 方法，字节的 HLLM 方法，小红书的 NoteLLM 方法。以小红书 NoteLLM 为例，作者使用统一的笔记压缩提示 (Note Compression Prompt) 同时用于 I2I 推荐以及主题标签/类目生成任务。具体的，输入 NoteLLM 的 Prompt 的格式模板如下：

NoteLLM Template

其中，[BOS], [EMB] 和 [EOS] 为特殊 token，特别注意的是，[EMB] 占位符是为了学习目标笔记的表征。而，, 和为占位符，对于不同的任务会使用不同特定的内容来替换。

类别生成任务的笔记压缩提示模板如下：
主题标签生成任务的笔记压缩提示模板如下：

然后，小红书这里对每个笔记提取 [EMB] 前一 Token 位置对应的隐含层状态作为给定笔记压缩后的语义信息和协同信号的表征。正常来说，这里应该可能直接取 [EMB] 对应位置的隐含向量会更直接，不知道小红书这里取前一 Token 还有没其它考虑。

1.1.3 利用 LLM Token (KDD'24|Adobe CoRAL)

也有一些方法提出使用 LLM 根据用户和物品信息生成用户偏好的描述，如 Adobe 这里就在提示中使用了这一信息。对于每个 item 都会有对应的 meta 信息描述，记为，作者将用户行为的协同信息整合到提示中，作为提示的一部分：

角色扮演: 假设你作为推荐系统，请解决以下问题 协同信息: 对于中的每个内容，内容被用户群体喜欢内容被用户群体不喜欢 总结: 尝试基于上述信息理解内容会被哪些用户喜欢的模式

这种方式虽然看起来比较直接，但由于输出格式不统一，将其应用到推荐系统时还需要做特定的兼容处理，这种方式笔者暂时还没发现在工业界落地应用比较好的案例，就不过多陈述，大家如有发现，可以做下补充。

1.1.4 利用 LLM Summary (RecSys'24|Meta:EmbSum 方法)

相比于小模型，LLM 具有非常不错的长程记忆能力，在处理长文本内容上有非常强的优势。严格意义上讲，LLM 的摘要能力也是属于 LLM token 的一种形式，只是由于比较特殊，这里单独拎出来。为了更好的理解&捕获用户兴趣，Meta 提出了 EmbSum 方法 (类似双塔)，利用 LLM 的摘要能力辅助训练小模型，其整体框架如下图所示，具体地

EmbSum Framework

Step1: 用户历史行为 Session 编码

由于 Transformer Encoder(论文使用 T5-small, 60M) 能处理的行为序列长度有限，作者将用户历史交互的行为序列按时间顺序将其划分成若干个 Session，然后每个 Session 会单独过 Transformer Encoder 进行编码，再把每个文本内容开始符号 [SOS] 所对应的隐层状态作为该文本内容的表征。整体流程示例图如下：

Session Encoding

Step2: 使用 LLM 生成用户兴趣摘要

具体地，LLM 作者使用 Mixtral-8x22B-Instruct，输入用户历史交互内容，生成一些用户兴趣摘要。这里，作者给了个求例，如下图所示：

Interest Summary Interest Summary 2

Step3: 监督 Transformer Decoder 训练

前面用户 Session 编码环节 Encoder 所有 token 隐含状态会输入到 T5 decoder 中，而大模型生成的这些用户兴趣摘要，在自回归训练方式下，大模型摘要的 next token 则起到监督信号的作用，辅助 Decoder 更好的总结用户兴趣，而最后位置所对应的隐含层表示则充当着小模型 Decoder 对用户交互内容的全局表征，如下图所示。

Decoder Training

Step4: User 侧 Poly-attention 机制

前面所对应的维隐含状态作为用户交互内容的全局表征，再与个维 Concat 起来得到的矩阵，再做 poly-attention，如下图所示：

Poly Attention

这里最后会得到个向量，拼接起来得到，作为最终的用户表征，论文这里称它们为 User Poly-Embedding(UPE)。

Step5: Item 侧 Content Modeling

在前面 Session 编码中，作者直接使用每个文本内容开始符号所对应的隐含状态来作为相应 Item 的表征，这里对于候选 Item，作者并没有这么去做，而是将该候选 Item 内容过 Encoder 后的所有隐含状态也像 User Poly-Embedding 类似处理，如下图所示：

Content Modeling

在这个过程中，可以得到的个表征，将它们拼接起来就可以得到矩阵，这个矩阵就作为最终的候选 Item 的内容表征，论文这里称它们为 Content Poly-Embedding (CPE)

Step6: 用于 CTR 预估

对于用户和内容，在前面得到的用户 poly embed 和内容 poly embed 后，作者使用下面方式预估相关性得分。

首先，将用户表征和候选内容表征相乘后再做 flatten:

这样就得到的向量，然后再做 attention:

1.2 冻结 LLM Vs 微调 LLM

预训练的 LLM 虽然已经具备了非常丰富的世界知识，但很多研究都提到，使用下游任务对 LLM 进一步微调能显著提高 LLM 在下游任务的性能。根据是否使用推荐场景数据微调 LLM 可以分成以下两类

1.2.1 使用冻结的 LLM

微调 LLM 虽好，但使用冻结的 LLM 也有一些好处，一是不会导致世界知识的灾难性遗忘问题，二是最经济&便捷，无需额外训练，工业界很多业务场景可能没有太多的成本投入。使用冻结的 LLM 主要指 LLM 的语义向量，比如设计特定的 prompt，使用文本描述内容信息，再通过 LLM 的 Embedding API 获取语义向量。然后再基于这种冻结的 LLM 的语义 Embed 进一步处理成推荐模型所需的输入。

1) 用于构造语义相似度信息 (Google STAR 方法)

谷歌提出的 STAR 模型的召回环节就用冻结的 LLM 来计算用户历史行为与 Target Item 的语义相似度，再与 User-Item 的协同信号进行融合。其框架如下图所示：

STAR Recall

整体流程如下：

Step1: 首先通过 LLM 的 Embedding API 获取全量 Item 集的语义向量。 Step2: 然后使用余弦相似度计算用户行为序列中的 Item(如上图左上角的#1~3 号) 与候选 Item(如上图左上角的#4 号) 的语义相似度得分，记为。 Step3: 接着，作者统计出每个 Item 的用户交互，得到 User-Item 交互矩阵 (如使用 0-1 值表示该 User 和 Item 是否有过交互)，其中是 Item 数，是用户数，再通过余弦相似度计算两两 Item 的得分得到协同共现得分，记为 Step4: 在得到候选 Item 与用户行为序列中每个 Item 的语义得分和协同共现得分之后，作者将这两个分数按下面的方式进行融合:, 其中，是用户对历史交互 Item 的评价得分，比如用户对看过的电影进行评分，是以用户行为序列中的顺序为指数的时间衰减因子，是融合的超参。 Step5: 召回流程以得分最高的 top 个 item 作为最终输出：

2) 用于获取用户行为的浅层语义表示 (SIGIR'24|蚂蚁 BAHE 方法)

严格意义上讲，蚂蚁提出的 BAHE 方法没有太特别的地方，也是使用 LLM 去获取用户行为序列以及候选 Item 的语义 Embedding，只不过它获取的是 LLM 的浅层原子行为的表征，再使用去做用户行为序列的理解。这里更多的是出于业务场景和计算效率上的考虑。

在蚂蚁金服的业务场景，用户的历史行为可以使用简单的自然语言描述，如"Purchase Starbucks", "Order takeout"等。这些用户历史行为存在大量的重复，如果每个用户的每种行为都过下 LLM，那会造成很多重复编码计算。为此，作者提出从这些用户行为里，得到去重的原子性的行为，事先使用 LLM 编码&聚合后得到维的表征，离线存储在数据库中。

BAHE Process

具体地：

Step1: 构建全量的原子行为集合 Step2: 使用预训练大语言模型的浅层对每个原子行为进行编码得到对应的隐含层状态 Step3: 将隐含层状态做 pooling 得到原子行为表征，其中是 pooling 函数。

这些编码后的原子行为表征后续使用时就变成 embedding lookup table 方式，然后再做深层次的行为交互，这样就可以减少 LLM 浅层的冗余计算。

3) 用于 User/Item 的 SideInfo 特征增强 (QQ 音乐推荐)

将 LLM 处理后的物品的语义 Embedding 视作 SideInfo，用于推荐模型的特征增强也是一种很常见的做法。但是，一些语义 Embedding 的维度很高，并且由于语义空间与 ID 行为空间的差异，如果直接将 LLM 的语义 Embedding 与推荐系统的 ID Embedding 拼接起来，那基本上是没有效果的，甚至可能因为引入额外的噪声导致数据负向。

为了克服原始的 LLM 语义表征维度过高且与 ID 行为空间不一致的问题，笔者提出额外增加一个 Encoder 实现对高维语义表征做降维映射的方案，而这个 Encoder 可以无痛兼容现有的推荐 DNN 模型支持一起 End2End 训练。

SideInfo Encoder

通过 Encoder 降维映射后表征可当作常规 SideInfo 的 Embedding 去使用，这种方式有很高的灵活性，比如下文 1.4 章节将介绍的将 SideInfo 与 ID Embed 进行融合的方案都可以直接尝试。这种 End2End 映射降维训练的方式在我们 QQ 音乐的多个业务场景中都有落地并取得不错的业务收益。

1.2.2 微调 LLM 的方法

使用下游任务的数据进一步微调 LLM 通常可以让 LLM 更加适配推荐下游任务。根据用于微调 LLM 任务的数据是否涉及协同共现信息，可分成两类：

1) 使用领域模态数据微调 (WWW'24|京东 PPM 方法)

预训练 LLM 使用的语料信息比较泛，不一定能很好的适配下游推荐场景的模态信息。为此，可以补充下游推荐场景高质量的语料数据，以使预训练 LLM 能更好的学习&理解下游任务的领域模态知识。这一部分不涉及下游推荐场景的共现数据。

京东提出的 PPM 方法中，基于电商场景数据，在模态编码层 (Modality Encoder Layer) 使用查询匹配 (Query Matching) 任务和实体预测 (Entity Prediction) 任务对预训练模型 (BERT 和 ResNet) 进行微调，以期获取高质量的文本模态表征和图像视觉模态表征。具体地：

查询匹配任务: 同 SimCSE，作者结合用户行为反馈 (是否点击)，使用对比查询匹配任务来微调文本模型。记为文本的 pair 对，分别表示搜索的 Query 以及对应用户点击商品的文本序列信息，在经过文本模型编码后，得到对应的文本表征，分别记为和。然后使用对比学习 (InfoNCE) 进行训练:, 其中，表示 batch size，而为温度系数.

实体预测任务: 作者使用 ResNet-101 作为 Vision 的基模型，然后使用电商场景数据，基于物品预测任务来进行模型微调。具体地，在给定商品的图片，模型的目标是要去预测图片中的关键实体，训练目标是：。

2) 使用推荐协同共现数据微调 (WWW'24|小红书 NoteLLM 等)

与其它领域对比，推荐系统最大的一个特色就是协同信号，而现代推荐系统主要也是基于协同信号驱动的。LLM4Rec 其中的一个核心问题就是要解决模态语义信息与推荐协同信号的融合。业界的实践表明，在微调 LLM 的过程中，引入下游推荐任务的协同信号做监督对下游任务的整体性能会有帮助。出于模型性能和训练成本等多方面的考虑，业界一般会构造推荐的共现数据去做微调。这些方案整体思路差异不大，大多都直接使用对比学习的方式训练，核心的差异点在于数据集的构造。比如小红书的 NoteLLM(以及 NoteLLM-v2) 方法，淘宝的 MAKE 方法，快手的 QARM 方法，他们在各自的业务场景下，数据集的构造以及训练细节上会有一些差异，大家可以做下对比，下面分别介绍：

小红书 NoteLLM(WWW'24)

NoteLLM-V2 和 NoteLLM 在使用共现数据上的方式是类似的，这里就只介绍 NoteLLM。NoteLLM 的整体框架如下图所示。

NoteLLM Framework

Step1: 使用笔记压缩提示获取目标笔记表征

作者使用前面提到的笔记压缩提示方法来获取笔记表征，这里不做赘述。

Step2: 提取共现笔记数据

作者从用户行为数据中提取共现笔记，构建相关笔记的 Pair 对数据，具体的

Co-occurrence

统计一周内行为数据中用户看了笔记随后又点击了笔记的数据，计算笔记笔记的共现分数:, 其中，表示所收集的行为数据中用户的数量，表示行为数据中第个用户点击的笔记的数量。这里，可以理解为，基于不同用户的活跃程度给不同用户赋予了不同的点击权重，可以规避掉特别活跃用户数据的误导。

对于每个笔记，计算得到其它笔记与它的共现分数后，过滤掉共现分数不在 () 区间的相关笔记，再对剩下的相关笔记依共现分数取 top 笔记作为笔记的相关笔记。

Step3: 生成式对比学习 (Generative-Contrastive Learning,简称 GCL)

构造出相关笔记 pair 对数据 (, ) 后，再使用对比学习将协同信号融入到 LLMs 中，具体的

GCL Loss

作者对每个笔记提取 [EMB] 之前一个 Token 的隐含层状态作为给定笔记压缩后的语义信息和协同信号的表征，再通过一个 linear layer 映射成维的 embedding 向量。然后，使用 Batch 内对比学习计算 Loss

其中，为对应的 pair 对与该笔记相关的笔记的 embedding 向量，表示 BatchSize，由于输入的是 pair 对笔记，因此总共有个笔记，为温度系数，这里使用余弦相似计算相似度。

淘宝 MAKE(CIKM'24)

与 NoteLLM 只构造共现笔记方式不同，淘宝这里基于电商场景的用户行为数据，人为定义了语义相似 (正样本) 和不相似 (负样本) 的样本对。

Step1: 相似样本构造

相似样本需要结合用户行为来构造，在电商场景，用户的搜索 - 购买行为链可以用来定义语义相似商品 Pair

Similar Pair

对于图片，可以拿用户搜索的图片，与用户最终所购买的商品的图片，作为视觉模态的正样本 Pair。

对于文本，也是类似，拿用户搜索的文本，与用户最终所购买商品的文本描述作为文本模态的正样本 Pair。

同时，论文作者认为，像 swing i2i 这样常见的基于用户行为定义的相似度指标，可能并不适合作为多模态预训练的 label，因为这样可能会导致多模态 Encoder 的学习退化为 ID 表征，学习不到商品的多模态语义信息。关于这点，大家看法不一，比如下面介绍的快手 QARM 倒是这么做的。

Step2: 负样本构造

负样本的构造最简单的方式就是 in-batch 负采样，但这种方式会受限于 batch size 的大小。

通常认为，扩大负样本的数量可以进一步提升效果。因此，作者参考 MoCo 的动量更新方法，设置了个更大的 memory bank 用于采样更多的负样本。

此外，作者还额外增加了一些难负样本的学习，作者把一次搜索返回的结果中，那些被用户点击但没有购买行为的商品所对应的图片，作为难负样本，认为它们与正样本具有一定的视觉相似，但又有一些差别。

Step3: 训练 Loss

对于普通的负样本，与 NoteLLM 一样，作者使用 InfoNCE 损失，以期在表征空间拉近语义相似样本对的距离，疏远语义不相似样本对的距离。

其中，为温度系数，是 memory bank 的大小，作者设置为 196800。

对于难负样本，作者使用 Triplet 损失强化正负样本的距离差距。

最后，将两者进行按一定超参进行融合

快手 QARM

与淘宝 MAKE 单独微调各模态的方式不同，快手这里同时微调对齐多模态 (文本/图片/视频) 表征，另外快手这里倾向于使用现有模型来辅助构造生成高质量的 Item2Item 的 Pair 对 (Trigger Item, Target Item) 数据集来做微调。具体地，pair 对样本的构造有两种方式：

基于 U2I 召回模型: 对于每个用户正向点击的目标 Item，从最近的 50 个点击 Item 中选择与目标 Item 在 ID 表征空间中最相似的 Item 作为触发 Item

基于 I2I 召回模型: 利用现有模型学习到的具有高相似度的稳定 Item Pair 对作为数据源，比如 Swing 召回

在生成高质量的 Item Pair 对数据集后，训练一个纯多模态表征的 Item 对齐模型：

其中，/为 Batch 内的多模态表征，而表示各种模态输入。

然后，同样的，也是在 Batch 内优化 Item 对齐损失，鼓励多模态模型表征适配推荐下游任务的协同信号。

1.3 如何使用 LLM 语义 Embedding?

由于 LLM Embedding 有着结构一致、信息丰富等诸多优点，LLM 的语义 Embedding 是业界 LLM-to-Rec 范式下使用&尝试最多的信息了。但是，最直接的将 LLM Embedding 与推荐常规的 ID Embedding 直接拼接起来的方式，基本上是无效的，因为 LLM 的语义空间与推荐行为空间天然就无法对齐，直接引入 LLM Embedding 甚至可能因为加入额外的噪声带来数据负向。在这一方面，近年来业界也是做了比较多的探索，也有了一些相对成熟的处理方案。

1.3.1 直方图统计 (CIKM'24|淘宝 SimTier 方法)

SimTier 的思想是通过构造 Target Item 与用户行为序列的语义相似度分桶的频次分布，然后把这个分布当作特征来使用。下面结合一个例子来解释。

假设 target Item 的多模态表征为，用户的行为序列长度为 100，可以基于与这 100 个行为序列所对应的多模态表征分别计算 Cos 相似度得分，这样会得到范围在[-1.0, 1.0]的 100 个相似度分数，基于预设定的等宽分桶后，如按 0.1 大小分成 20 个分桶，就会得到 20 个频次统计分布，如 (3, 2, …, 0, 3) 这样 20 维大小的数据，然后再把这 20 维的数据作为特征与其它 ID Embed 一起使用。

作者还很贴心地给出了 TensorFlow 版的伪代码实现，就 4 行代码也是相当直接。

SimTier Code

1.3.2 量化编码 (快手 QARM)

动机

在得到基于下游任务微调后的多模态表征后，最简单的方法是使用这个固定的表征作为输入，直接给到下游推荐模型中，但这种表征不更新的特征输入对下游推荐任务并不友好。

对于这个问题，业界一种最直接&广泛应用的 trick，是使用多模态表征来构造语义相似 Item 的 ID list，然后以 ID List 作为该 item 的语义特征输入到推荐模型，一定程度上间接规避了多模态表征不更新的问题。

快手 QARM 是把这类思路做的更极致了，首先是将多模态表征量化压缩成语义 ID，再将语义 ID 输入到推荐模型中。这种方式的好处有两个：

量化压缩后的语义 ID 一定程度上保留了原始多模态表征的语义信息
和推荐模型其它 ID Embed 一样，输入的语义 ID 的 embedding 是可学习的。

下面介绍作者使用的两种量化机制。

向量量化机制 (Vector-Quantized, 简称 VQ)

Vector-Quantized 是最常使用的量化方法，它首先训练一个大规模的编码表 (codebook matrix)，然后利用 top-k 最近邻搜索来哈希表示。

这里，作者没有重新训练编码表，而是直接将所有 Item 的多模型表征直接作为 codebook matrix，这样，向量量化机制其实就等价于从全表查找最近邻的 top-k 的 item 的索引，再把这些索引作为 VQ Code

这种方式，其实就是前面提到的 trick 了，就是对应的向量量化编码。

残差量化机制 (Residual-Quantized, 简称 RQ)

与向量量化使用一个大的编码表方式不同，残差量化会使用固定大小的层编码表，比如下图中就有 3 层的 codebook。

RQ Codebook

Step1: 残差量化编码表的构造

层的编码表通过递归方式得到。具体地，每一层使用 Kmeans 算法对 Item 表征集合做聚类，得到个聚类中心，然后每个 Item 都减去最近邻的聚类中心后得到新的 Item 表征集合。形式化描述如下：

Step2: 获取残差量化编码

在得到个 codebook 之后，每个 Item 的多模态表征都可以做量化。逐层地基于当前的残差表征从对应的 codebook 中查找最近邻的聚类中心的下标作为 code id，如上图的示例中，依次的 code id 为 (3, 4, 1, …)。这里的过程形式化描述如下：

这样，得到的 () 即为对应的残差量化编码了。

1.3.3 用作 (ID) Embedding 初始化 (微信 PRECISE)

腾讯于 RecSys'24 上 Rethinking-PLM-in-RS 的那篇文章提出将经过行为微调的 LLM Embedding 直接用作 ID Embedding 的初始化是一种比较经济实用的方式。

而在微信提出的 PRECISE 方法里，笔者认为其思想也是类似的。在微信中，各种模态的内容都可以用文本形式来表示，因此，作者这里主要使用 LLM 提取物品语义信息，当然，也可以使用多模态 LLM 来提取内容语义信息来替换。

将物品的文本 token 输入 LLM 中，获取对应的 token embeddings，如下图所示：

PRECISE Embed

注意到这里 LLM 是冻结的，但 token embedding 是 learnable 的，所以某种程度上也可以认为这里它是使用 LLM 去做 token embedding 的初始化。

然后，微信还使用了 MoE 框架去聚合 Token Embeding. 具体地，使用门控网络计算每个专家 (共 8 个) 的得分，再基于这些得分取 topk(取=2) 个最高得分的专家进行激活，并进行融合得到最终的文本模态表征。

PRECISE MoE

1.3.4 使用语义相似与行为共现做聚合 (CIKM'24|小红书 AlignRec)

小红书提出的 AlignRec 使用了聚合模块来做 ID Embed 与多模态 Embed 的聚合，其核心思想是引入了内容语义先验，使用内容语义相似来聚合 ID Embed 从而得到物品侧的模态感知的 Item MM Embed，再通过行为聚合得到用户侧的模态感知的 User MM Embed，其示意图如下：

AlignRec Flow

这个聚合模块的流程根据输出的依赖关系，可以分成以下 3 个步骤完成

Step1: User 侧和 Item 侧的 ID 模态

这里直接使用了 LightGNN 来做聚合得到 User 侧和 Item 侧的 ID 表征，这里没有什么细节，不详细展开。

Step2: 物品侧的多模态表征

对于物品侧的多模态表征，作者首先将前面统一的内容模态表征经过一个 MLP 进行映射，再做 Element-wise 乘积与 ID Embed 进行融合，得到融合了内容先验知识的内容表征

然后，作者会基于前面统一的内容模态表征，构造物品侧的相似矩阵，每个物品取与它最相似的 10 个 Item 做聚合，得到物品侧的多模态表征输出

Step3: 用户侧的多模态表征

对于 User 侧，通过聚合用户历史交互过的 Item 得到用户侧的多模态表征

其中，为归一化后的交互矩阵。

1.3.5 处理成 SideInfo (RecSys'24|快手 M3CSR)

某种意义上，LLM Embedding 也是一种 SideInfo，但是，和其它 SideInfo(如类目 ID Embed) 不同的是，在模型训练过程中 LLM 的 Embedding 是静态的 (Non-trainable)，无法更新。由于 LLM Embedding 语义空间与推荐行为空间的不一致，为了能将 LLM 的 Embedding 也当成 SideInfo 使用，业界验证可能比较行之有效的两种方案是，表征映射和模态聚类 ID 方法。

多模态表征映射: 将原始的 LLM Embedding 过一个映射函数映射，正如前面 1.2.1 章节笔者在 QQ 音乐推荐场景介绍的，所以在这问题大家思路还是比较一致的，这种方式相对 Soft 一些。

多模态聚类 ID: 将原始的 LLM Embedding 做-mean 聚类，得到聚类 ID，作为分类型特征使用，再过 embedding layer 得到 Cluster Embed。这种方式可以看成是上面残差量化编码中只有一个 codebook 的简化版了，相对 Hard 一些。

快手提出的 M3CSR 方法里，在 Modal Encoder 模块将这两种方法后的 Embedding 一起 Concat 起来了，得到的表征可以当作一般的 SideInfo 去使用，如下图所示：

M3CSR Encoder

当 LLM Embedding 处理成 SideInfo 有很多好处，可以将这种 Embedding 形式的多模态 SideInfo 与 ID Embedding 做融合。将 SideInfo 与 ID Embed 融合也是推荐系统的一个子问题，今年有不少论文也都提出的一些想法。将 LLM Embedding 处理成 SideInfo 之后，可以直接借鉴现有关于 SideInfo 与 ID 融合的文献，思路是不是一下就打开了。所以从这一点来看，笔者认为 SideInfo 与 ID 的融合还蛮重要的，为此，笔者下面的单独一个章节做介绍。

1.4 融合 SideInfo 与 ID Embedding 的若干方法

SideInfo 与 ID Embedding 的融合主要体现在注意力机制上，基于不同的业务场景、业务理解以及其它模型输入上的差异，大家在做法上会有区别，这里给出几篇比较有代表性的案例。

1.4.1 ID Embed 引导 SideInfo 学习 (RecSys'24|快手 M3CSR 方法)

现代推荐系统里 ID Embed 还是起主导作用，它是最适配推荐系统的，因此，可以用它来引导 SideInfo 的学习，让 SideInfo 起到补充的作用，实现 1+1>1 的效果。

注意，笔者这里所说的'ID Embed 指导 SideInfo 的学习'，并不是指直接拿 ID Embedding 去做 Label 让多模态 Embed 这样的 SideInfo 逼近的意思，当然，业界确实是有这么去做的，比如用 MSE Loss 让多模态 Embed 收敛到 DSSM Item Embed 的方法，但笔者并不认为这是一种正确的做法。笔者比较认可的是快手提出的 M3CSR 方法，其整体框架如下图所示：

M3CSR Framework

其中，这里的 Modal Encoder 模块用于产出多模态的表征，在 M3CSR 框架下它是 learnable 的，这个在 1.3.4 章节里已经做介绍了，这里就不做赘述，这里重点看 User Tower 的注意力机制以及 Item Tower 表征融合。

User Tower 注意力机制

对于文本、图片、音频模态的表征，作者会分别计算多头注意力机制。

这里，ID Embed 会作为多头注意力计算的 Query，它是 Stop Gradient 的，而为对应模态的模态表征，会作为多头注意力的 Key 和 Value。所以它其实是让冻结的 ID Embed 去引导多模态 Embed 学习。

快手这里处理的是多模态的信息输入，考虑到不同用户对不同模态的兴趣偏好/强度会有差异，作者还使用了基于 ID 计算出来的注意力结果去做多模态注意力结果的缩放，具体地：

首先，计算各模态表征的缩放因子 (兴趣强度)

再将对应的多模态表征进行缩放

然后，再将缩放后的多模态表征与 ID Embed 直接 Concat 起来作为 User 塔最后的表征

Item Tower 表征融合

考虑到新冷内容的 ID Embedding 可能学习不充分，因此，作者这里引入受欢迎程度的门控网络来控制 ID Embed 和多模态 Embed 的表达，让热门内容更多依赖 ID Embed，而新冷内容则减少 ID Embed，以使在冷启阶段更好的捕获内容的多模态信号，具体的：

作者使用了视频的交互次数来做分桶，使用可学习的分桶 embed，即上面的。其实，理想情况下，笔者认为使用 Item 被参与训练的次数作为这里门控机制的输入会可能会更合适，因为离在线的可能存在的一些 diff，即使是热门的 Item 在推理时它的 Item Embedding 可能学习的也不充分。可能这个被参与训练的次数信息在获取会比较麻烦，但确实是可以直接在框架层去实现的，笔者前阵子就借鉴 LogQ 的方法实现了对应的方案，有兴趣的同学也可以试试这个思路。

最后，将门控的权重加上再拼接起来后，就得到 Item 塔最后的表征：

1.4.2 对注意力 QKV 的改写 (WWW'24|闲鱼 MetaSplit 方法)

闲鱼商品推荐作为 B2C 和 C2C 共存的业务场景，其 User 侧的用户行为序列以及 Item 侧都大量存在未训练充分的孤品信息。

作者首先将用户行为序列按照是否为孤品 (即数量只有 1 件), 序列可以拆分成和，分别对应常规商品行为序列，以及孤品行为序列。

出发点

作者提出，在 C2C 的业务场景下，现有 DIN 的序列建模方案存在一些缺陷。回顾下 DIN 序列建模的计算逻辑

先看和。这里和是用来做相似度计算，作为 Attention Score 来使用。如果或所对应的 Item 是孤品，这时 ID Embed 是学习不充分的，计算相似度得分时应该强化 Side Info 的表达.

再看。是最终用来返回向量做聚合使用的，当对应的 Item 是孤品时，它的 ID Embed 是有偏的，直接返回对应的 ID Embed 可能也是有偏的，应该借助 Side Info 做改进后再返回。

针对上述两个分析，作者分别提出元缩放网络和元位移网络。

元缩放网络

元缩放网络旨在学习在孤品和中，Side Info 应该要被强化的程度。它会使用 ID Embed 去学习生成各个 Side Info Embed 的权重系数 (或称缩放系数)

其中，表示 Stop Gradient。这里的思想是，如果 ID Embed 学习的不充分，则应该强化 Side Info 的作用。

然后，再使用对应的缩放系数，对 Side Info Embed 进行缩放。

这样，最终孤品的和可被改写成：

元位移网络

元位移网络旨在使用 Side Info 改进孤品中的 ID Embed 部分。它会使用 Side Info 的 Embed 去生成一个"元 Id 表征"，作为当前 ID Embed 学习不充分时的补充：

同样地，在这个过程中，Side Info Embed 是被的，而是一个与 ID Embed 同维度大小的向量，这个向量会与 ID Embed 做如下方式融合，得到修正后的 ID Embed

其中，为融合系数，它由元 ID 表征的模与当前 ID Embed 的模做归一化计算得到：

这样，就可以实现对孤品部分的改写：

1.4.3 SideInfo 注意力与 ID Embed 注意力的融合 (WWW'24|蚂蚁 ASIF)

蚂蚁的这篇文章对 SideInfo 注意力与 ID Embed 注意力融合的方法做了很详细的归类与总结。

现有的序列推荐场景基于 self attention 方式在做 Side Info 融合时，其方法大致可以分成以下 3 类，如下图所示

ASIF Fusion

Early Fusion: 将 ID 与 Side Info 在注意力计算之前融合，但这种方式可能会干扰 ID 的学习 (即信息入侵) 从而带来负向影响。代表方法是。

Late Fusion: 将 ID 与 Side Info 单独进行注意力计算，在后期对两者的注意力做融合，但这种方式缺少了 ID 和 Side Info 的有效交叉。代表方法有 FDSA。

Hybrid Fusion: Side Info 仅参与到 Attention Score 的计算，即只在和中融合 Side Info，还是只使用 ID，在引入 ID 和 Side Info 交叉的同时，也规避信息入侵风险。代表方法有 NOVA, DIF-SR 等，但这类方法也存在一些缺点。

论文对现有 Hybrid Fusion 方法做了些改进，这里不做详细解说，有兴趣的同学可以看对应的论文或笔者的历史公众号文章。

1.4.4 使用 GNN 融合 SideInfo (WWW'24|港大 PromptMM 等)

也有一些文献是使用 GNN 来融合 SideInfo，比如港大提出的 PromptMM，不过这篇论文写的相当复杂，工业界实操性不强，另外，GNN 最近在推荐领域也有失宠的趋势，这里就不花笔墨再介绍了。

1.5 生成式训练 or 判别式训练

在谈论生成式推荐和判别式推荐之前，我们先明确下生成式推荐的定义。文献 [1] 提到"A generative recommender system directly generates recommendations or recommendation-related content without the need to calculate each candidate's ranking score one by one." 对应到推荐系统里，生成式推荐一般采用类似 LLM "next token prediction"的训练方式。

Gen vs Disc

下面结合案例做下介绍。

1.5.1 生成式训练范式 (微信 PRECISE 方法)

生成式训练有两种训练方式：SASRec 方式和 CPC 方式，形式化描述就是作者使用交叉熵作为 Loss：

微信所提出的 PRECISE 方法采用生成式训练范式，在所提方案中同时用到了这两者。其所提方案的整体框架如下图所示，分成 Embedding Fusion, Universal Training 以及 Targeted Training 三个模块。Embedding Fusion 在前面的内容中已经提过，这里不做赘述，主要看下后面两个模块。

PRECISE Framework

1) 通用训练模块

中间的通用训练模块是基于全域 (包括看一看/听一听/视频号等) 行为序列数据做预训练的，它基于 decoder-only 的 Transformer 模型 (因果解码器) 进行训练，每个 Transformer 层最终会输出一系列 embedding，位置的 embedding 用于预测序列下一位置的物品 (即自回归的方式)。

对于 Loss 部分，考虑到推荐系统中候选 Item 数以亿计，直接全部计算 Softmax 是不现实的。因此，对于序列中的每个 Item，作者会从其它序列中采样一些 Item 作为负样本，再使用 Cross Entropy 进行 Loss 计算：

其中，表示从其他序列中随机采样的 Item 集合。关于加速训练的方法，除了这种采样方式，还可以前面快手的 KuaiFormer 的使用 In-batch softmax+LogQ 的方法。

2) 目标场景训练模块

目标场景训练模块，是基于前面预训练的通用模型中参数热启动的，不过为了更好地适应目标场景的推荐任务，这里作者做了两处改动：

在计算行为序列中物品之间的注意力权重时，作者使用了双向注意力机制，也就是去掉了掩码矩阵。这种方法的优点是序列中的每个 Item 的表示是基于完整序列计算的。
为了利用每个用户行为序列中的所有 Item 的 Embedding，作者将最终 Transformer 层所有 Item 的 Embedding 都拼接起来，再过一个 MLP 去学习计算用户最终的 Embedding。

Loss 部分，对于长度为的序列，仅预测第个 Item：

1.5.2 判别式训练范式 (字节 HLLM 方法)

字节所提的 HLLM 方法其实是判别式和生成式融合的方法，不过由于它对判别式训练范式介绍的比较好，这里就以它来介绍了。字节 HLLM 的整体框架如下图所示，分为 Item LLM 和 User LLM。

HLLM Framework

1) Item LLM

Item LLM 的作用是作为特征提取器，如下图所示，使用 Item 的标题、标签、描述的文本信息作为输入，并在最后位置额外增加了一个特殊 Token，最终的输入为，其中为文本 token 的长度，而特殊 Token 对应的输出的隐含状态则作为该 Item 的 Embedding。

2) User LLM

User LLM 的输入是用户历史交互序列，前面的 Item LLM 就起到传统深度模型的 Embedding Lookup Table 的作用，这样就将用户行为序列转化成，再将这些 Embedding 作为输入，进行 Next Item Prediction，预测下一位置的 Item Embedding。这里 User LLM 对于 Next Item Prediction 的训练目标，按照训练方式的差异，可以分成生成式训练与判别式训练，而 HLLM 同时使用了这两种，使用超参做了融合。生成式训练的 Loss 和前面 HLLM 没有太大区别，这里不做追溯，重点看下判别式训练这里。

判别式推荐的训练方式主要有两种：Early Fusion 和 Late Fusion，作者在实际在落地使用的是 Late Fusion。

Disc Fusion

Early Fusion

Early Fusion 是将 Target Item 的 Embedding 拼接在用户行为序列的最后，再输入给 User LLM，然后再将对应位置的输出做分类预测。Early Fusion 方式的优点是，Target Item 可与用户行为序列在 User LLM 中进行充分的特征交叉，它的效果一般会更好，但效率较低。这个类比于常规推荐的精排。

Late Fusion

Late Fusion 首先在用户行为序列的最后拼接一个特殊 Token，类似 Item LLM 的方式，再使用 User LLM 编码用户行为序列，提取得到用户的 Embedding(即位置对应的输出)，再将其与拼接起来去预测分类。Late Fusion 在后期再实现特征交叉，效果一般会差一些，但在推理时效率更高。比如当 Prediction Head 是使用内积去计算 User Embedding 与 Target Item 的 Logit 时，那 Late Fusion 的 User LLM 就是一个双塔模型，就可以直接使用向量索引做召回。

对于预测部分，它是个二分类问题，训练损失函数如下：

其中，表示训练样本的 Label，表示预测的 logit。

1.6 LLM-to-Rec 范式下的训练&推理策略

LLM-to-Rec 范式下，需要特别注意模型训练效率以及模型更新效率的问题。以最常见的使用 LLM Embed 方法为例，与 ID Embedding 对比：

LLM Embedding 的维度 (如 2048) 可能是推荐的 ID Embed(如 32 维) 数十倍，会使存储和训练计算上都会有一定的压力
LLM Embedding 是静态的，与它相关的模型参数多为 Dense 参数，其参数更新过程相对缓慢&平稳
ID Embeding 初始化后，随着流式或 batch 方式的训练，推荐系统的 ID Embed 通常更新是比较快的
对于新内容，预训练的 LLM Embed 通常可以异步实时拉取，但基于多模态的模型由于计算较重，模型的更新频率一般较慢，推理时会出现 OOV 的问题。

为此，业界提出的 LLM4Rec 的方案里，也会适配一些特定的训练/推理策略。这里介绍下一些方案。

1.6.1 插件式的异步训练策略 (WWW'24|京东 PPM)

京东 PPM 的整体框架如下图所示，左侧是与多模态 Embed 相关的预训练的 CTR 模块部分，CTR 模块这里的输出会用于右侧统一排序模型 (URM) 的特征增强，右侧统一排序模型倒没太特别的，我们主要看下左侧的多模态预训练 CTR 模型。

PPM Framework

多模态预训练 CTR 模型 PPM

首先，京东这里会基于电商的领域场景数据对模态编码层做微调，这部分在 1.2.2 章节中已经做过介绍，不做赘述。模态编码层的输出就是多模态 Embedding，如下图所示，其中，为用户的交互历史的物品多模态表征。

PPM Embed

然后再使用双向 Transformer 去捕获上下文信息，如下图所示：

PPM Transformer

从示意图来看，这里是 self-attention + target attention 的双层 attention 方法，一步步来看这里的过程：

Step1: 以用户交互历史的模态表征为输入，同时也考虑位置编码和时间间隔编码，即：

这里位置编码和时间间隔编码一开始是做随机初始化。

Step2: 拼接用户交互历史表征：

Step3: 基于双向 Transformer 模块计算：

其中，表示 Transformer 模块的第层，表示双向 Transformer 模块，其对应的输入都使用。

Step4: 以 Target Item 的模态表征作为 Query，上面的输出作为 Key 和 Value，再做 Target Attention，最后一层的输出即作为融合 User 和 Item 后的表征。

然后，通过将 Transformer 模块得到的 user 和 target item 的表征 concat 起来，再过几层 MLP 去预测点击率。需要留意的是，这里只使用点击单目标，不同于后面的 URM 会使用点击&下单的多目标。损失函数使用交叉熵损失：

异步更新策略

URM 在线上的整体流程如下图所示，PPM 是 T-2 更新的，URM 是 T-1 更新的：

Async Update

笔者猜测，这里异步更新的原因主要在于 PPM 由于 Embedding 维度比较大，这部分的训练开销还是比较大的，更新比较缓慢，并且这里由于只是纯多模态的输入，可以多 Epoch 训练，并不需要像 ID 模型那样对实时性要求这么强。这里不确定 URM 在增量训练时，PPM 的结果是否需要缓存起来去做加速，看上面的流程图貌似是没有的。

1.6.2 分离式的异步训练策略 (CIKM'24|淘宝 MAKE 方法)

由于泛化能力的不同，基于 ID 的模型和基于多模态的模型对于训练所需 epoch 数存在差异。基于 ID 的模型通常只训练一个 epoch，以避免过拟合。而基于纯多模态表征的模型由于其良好的泛化性，可以进行多个 epoch 的训练，并且随着训练 epoch 数的增加，其模型效果还能提一步提升。

MAKE Epoch

淘宝这里提出的 MAKE(多模块知识抽取模块，Multimodal Knowledge Extractor) 方法其实也是采用了与 PPM 类似的训练策略，将与多模态表征相关参数的优化与其他参数优化分离开来，以支持多模态模块的多 Epoch 训练，如下图 (b) 所示。

MAKE Structure

MAKE 模块主要包括以下两个步骤

1) 多 Epoch 训练纯多模态序列建模模块

这一部分使用了常规的 DIN，只是将 ID Embed 替换成多模态表征。

2) 多模态知识与 ID 模型融合

为了让 ID 模型主导的模型也能融合多模态知识，作者将 DIN 的输出，MAKE 模块浅层 MLP 的中间层输出，以及最后的 Logits 分别与 ID 模型对应地进行拼接，再进行联合训练。

1.6.3 两阶段的交替训练策略 (微信 PRECISE 方法)

微信提出的 PRECISE 方法里，会将使用 MoE 处理后的 LLM token Embedding(处理方式见 1.3.3 章节) 与 ID embedding 拼接起来，得到物品的最终表征，即：

这里 ID embedding 和 token 都是可训练的变量。但是，在模型训练过程中，作者观察到由于文本表示来自训练有素的 LLM，因此模型训练严重依赖语义 Embedding，导致 ID 表示训练不足。

PRECISE Train Issue

以上图 (b) 来说明这个问题，作者基于物品的 Embedding 采样了被认为彼此相似的物品对<,>, 然后，计算他们的 ID Embedding 的余弦相似度。蓝色线表示 ID Embedding 与 Token Embedding 一起训练的 ID Embedding 的相似度分布，而橙色线表示在 token embedding 冻结起来时，训练的 ID Embedding 的相似度分布。蓝色的线的相似度基本在 0.55 左右，略高于 0.5，说明这时 ID Embedding 的更新幅度很小。为此，作者采取了两阶段交替训练的策略：

首先固定 token embedding，仅训练 ID embedding
当 IDembedding 收敛后，才允许训练 token embedding

1.6.4 多阶段预训练的训练策略 (字节 HLLM 方法)

字节提出的 HLLM 其实是计算很重的方法，论文后面的实验介绍了它使用多阶段的训练方式：End2End -> Finetune -> Freeze。

HLLM Stages

具体地，训练过程分成 3 个阶段：

Stage1: 对 HLLM 的所有参数进行 End2End 训练，包括 Item LLM 和 User LLM，采用判别损失函数。另外，为加速训练，用户历史序列长度被截断至 150。

Stage2: 首先使用 Stage1 训练好的 Item LLM 对所有 Item 进行编码并存储其 Embedding，然后再继续训练 User LLM。这个过程由于仅训练 User LLM，训练成本没那么高，因此，作者把用户序列长度从 150 扩展至 1000，以进一步提升 User LLM 的效果

Stage3: 经过前两个阶段的大规模数据训练后，HLLM 模型参数不再更新。作者为所有用户提取 User LLM 的 User Embedding，并将其与 Item LLM 输出的 Embedding 以及其他现有特征结合，输入在线推荐模型进行训练。

字节果然豪横，Stage1 的 End2End 训练这里做了笔者想做但没资源做的一个事情，可能也确实是成本太高了，最终在 Stage3 使用时只是作为离线的多模态的特征提取器。

1.6.5 内容与模型的异步更新策略 (QQ 音乐)

在 1.2.3 章节里，笔者介绍了在自己的业务场景里使用了模态编码 Encoder 来对音频表征做降维映射处理成 SideInfo 的方式，在训练时这个 Encoder 与其它 DNN 模块是 End2End 学习的。由于数据依赖、计算成本以及业务逻辑上的一些考虑，这个模型现阶段还是天级更新的。

模型天级更新存在的一个问题是，对于新上架的歌曲，模型侧多模态 Embed 是缺失的，为此，笔者提出的缓解方案是，在推理时，对于新歌 Target Item，会实时拉取音频表征并输入给模型，其它 Item 的音频表征由于已经存在于模型中，只需要模型侧通过 lookup table 操作即可，这样可以保证在 Target Item 侧音频表征基本都能覆盖的，且不会额外增加多少推理的时延。

2. Rec-to-LLM 范式

Rec-to-LLM 范式以 LLM 为主，大多数是将用户历史行为数据以自然语言描述作为输入，再由 LLM 给出具体的输出。从笔者了解到的一些文献来看，Rec-to-LLM 目前在工业界的应用比较少，即使是工业界发表的论文，大多没有直接说明业务落地应用的具体场景以及在线实验的数据对比。

笔者将 Rec-to-LLM 范式简单分成三类：

2.1 使用 LLM 作为 Ranking Function(Google STAR 方法)

Google 提出的 STAR 方法，将 LLM 当成了 Ranker，具体地包含两个步骤：

Step1: 构造 Item 提示信息

下图给出了排序过程的 prompt 构造，除了一些 Item 的 meta 信息之外，还额外补充了流行度信息以及共现信息

STAR Prompt Sort

流行度信息: 统计 Item 在数据集中的交互次数，如"购买该 Item 的用户数：###"

共现信息: 统计两个 Item 的共现交互次数，如"同时购买该商品和用户历史商品#1 的用户数量：###"

Step2: 制定排序策略

作者将检索部分得到的 Item 按得分顺序作为输入，然后使用了三种不同的排序策略：

point-wise: 基于用户序列独立评估每个 Item 的得分，以确定用户将与 Item 交互的可能性有多大。如果两个 Item 得分相同，则将检索的得分打的排前面。

pair-wise: 基于用户序列评估两个 Item 之间的偏好。具体地，作者使用滑动窗口方法，对列表按检索分数从低到高比较列表，进行位置交换，类似冒泡排序。

list-wise: 也是使用滑动窗口方法，对窗口大小个 Item 进行比较，并按步幅进行滑动。pair-wise 可以看作是 () 的 list-wise。

论文没有给出在实际业务中的应用场景，另外，这种方式感觉很弱啊，不建议参考。

2.2 使用 LLM 获取推荐结果 (RecSys'24|Spotify:Text2Tracks)

Spotify 的这篇文章笔者认为算是 Rec-to-LLM 范式里比较完整的一个工作了，除了没有实际落地业务的相关收益描述外，不过大概可以拆测到应该是在 AI 助手这样 LLM 赋能的对话式推荐场景使用的。比如"可以推荐一些经典摇滚风格的歌曲吗？", 作者将这种基于提示词的音乐推荐问题看成是生成式检索问题Generative Retrieval problem(简称 GR)。

传统的基于 LLM 的方法流程如下图所示：

Text2Tracks Old

但是，这种方式存在着一些缺点：

严重依赖于文本 token 而不是歌曲 item 本身: 歌名相似的两首歌曲的流派风格可能完全不同
需要单独的实体解析去得到对应的歌曲 ID: 即使给了正确的歌手&歌名，但一首歌经常有很多版本 (如 live，翻唱等), 要得到对应的歌曲 ID 也需要费一些工夫
解码步数与歌手歌名的长度呈线性关系: 有些"歌手 + 歌名"长度会很长，导致推理速度很慢

为此，作者提出了 Text2Tracks 的框架，如下图所示：

Text2Tracks New

其中，为对应的 Query，在对话式推荐中，，会将截至到当前对话轮数的历史对话语句 concat 起来，为 ID 策略，用于将每首歌曲映射成 String 形式的标识符，再作为语言模型输入的一部分，这是论文最核心的内容。论文的核心其实就是这里的 ID 策略了，作者给出了 3 种类型的 ID 策略，如下图所示：

ID Strategies

基于内容的 ID 策略

基于内容的 ID 策略是把歌曲的一些元信息 (文本) 用分隔符"_"拼接起来，如"周杰伦_夜曲"这种以"歌手_歌名"的方式。这种方式的优点是预训练语言模型中关于这些元信息的知识 (权重) 可以被充分利用起来，也不需要额外将这些元信息文本加入到 LLM 的词表中。

三种基于整数的 ID 策略

基于整数的 ID 策略是使用随机整数来表示歌曲或用于表示歌曲的元信息，具体地，作者给了 3 种策略：

track-int: 每首歌随机分配一个整数 ID，其实就是平常推荐系统里的 ItemId，如周杰伦的《夜曲》可以表示成"10001", 这种策略下的这些整数 ID 是不会加入到 LLM 的词表中的，因为这些 ItemID 并不具备可扩展性。
artist-int-track-seq: 由于歌曲的元信息本身是层次结构的，因此可以为每种元信息内容都按顺序分配一个整数，再用分隔符"_"拼接起来，如周杰伦的《夜曲》可以表示成"1001_1001",《晴天》可以表示成"1001_1002", 前面是给歌手分配的整数，后面是给歌名分配的整数。同样的，这些给歌曲元信息分配的整数也不会加入到词表中。
artist-iid-track-seq: 这个策略与 artist-int-track-seq 的区别在于，给头部歌手 (论文这里是 top5W) 所分配的整数会被加入到词表，这样，周杰伦的《夜曲》可以表示成"<1001>_1", 这里的<1001>表示它是被加入到词表中，而其它部分与前面策略没有差异。

这里的策略设置其实是有比较多的细节的，感兴趣的同学可以看我公众号文章的解读。

可学习的树结构 ID 策略

在离线实验中，作者发现这种方法其实效果不太行，这里不做详细展开描述。效果最好的是前面比较简单的"artist-iid-track-seq"策略。

2.3 使用 LLM 构造推荐响应 (RecSys'24 最佳长论文 | 腾讯 ECR)

近年来，对话系统的发展促使自然语言对话与推荐系统深度融合，催生了对话式推荐系统 (conversational recommender system, 简称 CRS)。CRS 通常包含内容推荐和回复生成两个子任务，它通过多轮对话与用户产生互动以更好的捕捉用户偏好。腾讯这篇论文提出的 ECR 方法主要是为了解决传统 CRS 方法经常忽略了用户语言中的情感而导致推荐不合适内容以及给用户的响应内容里过于生硬缺乏情感的问题。其整体框架如下图所示，主要包含情感感知的内容推荐模块和情感对齐的回复生成模块，这里不做详细介绍。

ECR Framework

3. Towards RecLM 范式

这里的核心在于探讨如何实现推荐系统的 Scale Law。

3.1 简单堆叠模型参数 (ICML'24|Meta:WuKong 方法)

Meta 在设计 Wukong 架构时，主要目标有两个：

可以有效地捕获复杂的高阶特征交互能力
确保模型性能上存在缩放规律

Wukong 的整体结构比较简洁，低层是 embedding 层，上面堆叠了多层的交互模块，最后是一个 MLP，如下图所示：

Wukong Arch

Wukong 的结构非常简洁，本质上是把 DeepFM 做了很多层的堆叠，实现特别高阶的特征交叉，是一种比较暴力的方案。这个方案直觉上上限不高，没听说业界有哪些团队在 follow 的。

3.2 极致的工程优化 (快手海外 MARM)

相比于 Meta 提出的一些验证 Scale Law 的方法，快手海外 Kwai 提出的 MARM 方案，感觉更接地气一些。由于有着更加严格的成本约束，并且需要在已经迭代多年的推荐模型上持续拿到增量收益（模型中已经包含 SIM 等多种序列建模方案），难度是更大的，所以作者希望能够有一个更加务实高效的方案能够验证推荐系统中的 Scaling Law。

MARM Arch

上面的示例图非常简介明了的阐述了论文的核心思想，其本质上是用空间换时间，做了多层缓存机制。

考虑到 Masked-Self-Attention 计算复杂度的问题，作者将它都替换成复杂度低的 Target Attention，并且将中间结果都直接缓存起来，大大减少模型的推理复杂度&时延。

MARM Cache

作者在快手海外版 Kwai 拿到了非常不错的收益。这里的实现比较依赖工程能力改造。

3.3 重构推荐范式 (ICML'24|Meta:GRs)

Meta 提出的 GRs 基本上属于对现有推荐范式的重构了，在生成式推荐系统 GRs 里，作者将推荐系统的 sparse 特征和 dense 特征转换成了统一的时间序列来处理，如下图所示，具体处理如下：

GRs Transform

然后，标准的召回和排序，在 GRs 框架下，其输入输出可以表示如下：

GRs IO

关于 GRs，一经提出后，现网已经在非常多的论文解读，业界也有一些业务在 follow 这种方式的实现并且已经取得一些业务收益，这里就不再详细陈述了。

4. 总结

本文基于 24 年各大互联网公司公开发表的论文，从各个维度拆解现在 LLM4Rec 落地的各种实践方法，方便大家在各自业务场景中，按图索骥，互相验证。

LLM 的突破性进展给推荐带来了一定的想象空间，24 年 LLM 在推荐领域的应用落地确实也取得了一定的进展，虽然这个进展与 NLP/CV 等领域相比可能还是有点小巫见大巫了，但 24 年这个领域的发展确实也带来了一些惊喜。

回首过去，受制于 ID 模型及传统推荐模型的训练范式，推荐模型在新冷内容推荐上效果不佳，难以见到推荐领域的 scale law。立足现在，随着 LLM 对现在推荐模型能力的补充，特别是 LLM Embedding 的利用，笔者相信现在 LLM-to-Rec 的范式一定能实现 1+1>1 的效果。展望未来，相信推荐系统的 scale law will be is coming.

LLM4Rec 在业界的应用范式梳理