题目重点:比较流行度、协同过滤、双塔与交互排序,按数据、延迟和冷启动选择。
题意与假设
这道练习题保留了面经中值得训练的核心约束,并将需要澄清的条件单独列出。现场拿到变体时,先和面试官确认这些条件。
- 没有指定推荐场景、数据量或实时目标;先问召回/排序职责,不给一种模型万能结论。
解题路线
- 建立可测基线:热门/规则与简单线性模型。确认曝光日志、用户/物品ID、反馈延迟和负采样,避免模型复杂度掩盖数据问题。
- 协同过滤擅长已有交互的相似关系;内容特征补冷启动,双塔支持向量召回和预计算物品表示,但受分离表达限制。
- 排序可用线性/树/神经交互模型,在候选小集合用更丰富特征;crossencoder更强交互但不能默认对全库执行。
- 离线分时间/实体验证,测Recall@K、ranking指标与校准;线上关注业务目标、长期体验和实验护栏。架构选择同时受实时特征成本约束。
- 端到端服务先定用户/视频/曝光事件与candidate IDs,多路召回后rank/rerank并过滤不可用内容。线上特征需时间版本与fallback,模型发布绑定feature/index版本;离线训练样本与线上实时状态不能混淆。
- 曝光、播放/完播、skip和反馈进入日志,negative sampling保留曝光偏差,数据按时间/用户组去泄漏。模型比较外还测端到端延迟、覆盖、冷用户/冷item与线上实验护栏,不用单一offline AUC证明整个推荐完成。
手动走一遍
新物品无交互时协同过滤不易建可靠表示,商品文本/图像特征可以补充。百万物品先双塔召回几百,再精排,而非让大模型逐一评分。
规模与取舍
召回向量预计算降低在线成本但引入更新延迟;排序成本随K、特征获取与模型规模增长。参数少不等于整个服务便宜。
易错点与追问
容易失分的边界
- 模型名清单无取舍。
- 用随机split造成时间泄漏。
- 只以AUC决定整个推荐系统。
继续深挖
- 如何做冷启动与探索?
- 特征延迟超过预算怎样降级?
