面试题 · RAG
搜索「漏斗」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
从模型架构、训练方式、推理效率或应用场景等角度，探讨生成式推荐系统未来可能的改进方向和发展趋势。
传统推荐是判别式（打分排序），生成式推荐则是直接生成用户可能感兴趣的item或内容，范式更接近"预测下一个token"。
按学习路线查看教程、项目和面试题。
| 挑战 | 应对思路 |
|---|---|
| ID空间巨大 | 采用语义ID或分层编码 |
| 实时性要求 | 边缘部署+云端大模型协同 |
| 多样性-准确性权衡 | 引入可控生成（Constrained Decoding） |
建议系统学习该知识点
场景切入
假设你在做小红书的推荐，现在不是简单把历史点击过的笔记召回排序，而是让模型直接生成一条用户可能喜欢的笔记文案和图片。你觉得从模型架构到训练，未来要落地这种生成式推荐，还有哪些坑要填？
层层追问
传统推荐你是怎么做的？……那如果让你用生成式的方式，直接生成推荐结果，你感觉最大挑战在哪？……比如模型架构上，怎么把item ID和属性统一成token？训练时用户反馈怎么对齐？推理速度怎么跟上？
直球架构
从模型架构、训练方式、推理效率和应用场景四个角度，谈谈生成式推荐系统未来可能的改进方向和发展趋势。
这道题其实是在问，生成式推荐这个新范式，从模型到落地还有哪些坑要填、哪些路能走。我觉得核心要抓住一点：传统推荐是判别式，打分排序；生成式推荐是直接生成用户可能喜欢的内容，本质更像语言模型预测下一个token。所以改进方向都围绕怎么让生成更准、更快、更可控。
先说模型架构。现在很多做法还是割裂的，召回用SASRec这类ID序列模型，精排又换成别的，漏斗很重。我倾向用生成式统一框架，把召回、排序、[[重排]]合并成一个过程，关键就是设计一个适配推荐的[[Tokenizer]]，把item ID、属性、内容都编码成统一token。但这里有个边界：统一框架适合内容理解强的场景，比如小红书笔记推荐，内容本身就是文本和图片；如果场景是纯ID的电商推荐，ID空间太大，Tokenizer编码会丢信息，反而退化成降级方案。所以落地时我常把统一框架只用在重排阶段，前几级还是多路召回，这样既保留效率又提升生成质量。
训练方式上，一个明显趋势是引入[[RLHF]]或[[DPO]]。生成式推荐容易有曝光偏差，模型只学到用户看了什么，没学到用户真正喜欢什么。用用户真实反馈，比如点击、收藏、观看时长，来优化生成策略，就能对齐真实偏好。举个例子，在小红书场景下，笔记生成的优化目标应该是收藏率而不是点击率，因为收藏代表用户觉得有用。但这里有个前提：反馈信号要区分短期和长期，点击可能是误触，收藏才是强信号。如果反馈稀疏，比如冷启动用户，RLHF效果会打折扣，我可能会先用行为模仿预训练，等数据积累够了再上对齐。
推理效率是痛点，生成式逐token解码太慢，推荐系统要求毫秒级。我主要关注两个方向：一个是投机采样，用小模型快速生成草稿，大模型验证修正，能压到接近小模型的延迟；另一个是[[KV Cache]]复用，把用户长期兴趣的缓存持久化，每次请求不用从头算。但这里有个风险：KV Cache复用会引入过时兴趣，用户口味变了，缓存还是旧的。所以我会加一个时效性衰减，比如一周以上的缓存权重降低，或者用用户最近行为做增量更新。
应用场景上，[[多模态]]是小红书的天然优势。图文和视频内容可以直接作为生成目标，从推荐现有笔记演进到生成个性化摘要，甚至组合生成穿搭方案。但落地要小心生成质量不可控，比如生成的内容和用户真实兴趣偏离，或者多样性下降。我倾向用可控生成，比如Constrained Decoding限制输出必须包含某些核心属性，再配合线上A/B测试，先小流量验证，不然生成出离谱内容用户直接流失。
其实还有一个有意思的方向是把用户长期兴趣和短期意图解耦，分别建模再融合生成。比如长期兴趣用离线大模型，短期意图用在线小模型，这样既保证个性化又满足实时性。这个解耦的思路在传统推荐里也有，但生成式框架下怎么做，值得深挖。
所以整体上，我更倾向于把生成式推荐看成一种补充能力，而不是完全替代传统范式。在内容理解强、延迟容忍度高的场景优先落地，同时用混合架构兜底风险。