LLM怎么融入推荐系统？意图理解与生成

这道题其实问的是，在大模型时代，推荐系统怎么「吃」上LLM的能力，不是简单替换，而是找到最经济的融合点。我主要从三个技术路径来看：特征表示、用户意图理解，还有生成式推荐。先说特征表示。传统推荐靠ID [[embedding]]，冷启动很弱。LLM能把商品标题、用户评论这些非结构化文本变成高质量向量，本质上是用语义理解补上ID的盲区。具体落地时，我会把物品侧和用户侧分开处理。物品侧直接用LLM编码文本，用户侧聚合历史行为生成动态画像。但这里有个坑：LLM推理太慢，维度又高，线上扛不住。所以实际我会把LLM特征离线预计算，再[[蒸馏]]到轻量模型，或者和ID特征做门控融合，线上只走[[双塔]]后期拼接。前提是离线更新频率要够，如果商品信息秒级变化，这条路就走不通。再说用户意图理解。传统推荐是匹配，LLM能做推理。比如用户搜「平价手机」，传统靠关键词，LLM能理解成「2000元档骁龙机型」，做语义改写或需求扩展。但LLM不适合直接做实时排序，我倾向于把它放在上游模块，输出意图标签或改写后的query，喂给下游精排。这样既利用了推理能力，又不影响实时性。边界很清楚：LLM适合session级或跨域推理，不适合逐请求实时响应。第三个路径是生成式推荐，直接让LLM生成结果。一条路是生成Item ID，把ID当token，seq2seq预测下一个视频ID。好处是统一框架，但ID无语义，需要配合语义ID或分层索引，否则生成出来不存在的东西就是[[幻觉]]。另一条路更成熟：生成推荐理由，比如快手「为你推荐」的个性化话术，提升点击率。但生成推荐理由有个风险：如果文案和实际内容不符，用户点进去发现被骗，长期体验会崩。所以我会用约束解码加[[RAG]]，先召回候选集，再让LLM基于候选集生成文案，确保内容真实。落地时核心挑战是幻觉、实时性和成本。幻觉靠检索增强和约束解码；实时性靠LLM只做离线特征或粗排，精排保持轻量；成本靠大小模型级联，简单请求走小模型，复杂请求才触发LLM。具体到短视频场景，我会把LLM定位成session级兴趣总结工具，比如识别用户从搞笑转向知识，小时级更新用户画像，而不是逐帧推理。如果只让我选一个路径，我更倾向特征表示加意图理解组合，因为生成式推荐在实时性和幻觉上风险太大，现阶段更适合做锦上添花。

还有一个我没展开的点：LLM特征和ID特征怎么融合效果最好？直接拼接还是门控？我最近看到一些工作用[[MoE]]动态选择特征来源，但线上工程复杂度很高。