在小红书 APP 中，推荐系统的实效性对推荐效果有着特别重要的影响，特别是作为 UGC 平台，小红书的推荐系统如果能更快地捕捉用户与笔记之间的变化和联系，就能够给推荐带来更好的效果。在2021年上半年，首页推荐的召回、粗排、精排的主要模块都保持在天级更新的状态，我们通过持续迭代，将召回 CF 渠道、召回索引更新、召回模型/粗精排模型的训练都做到了分钟级更新，为首页推荐的分发效率带来飞跃式提升，并给业务侧带来非常显著的收益。
小红书站内“最近一天内发布的新笔记”在首页的曝光占比一直很高，这段时间更是快速增长，几乎占到了一半。
不过，也经常会有这种情况出现：用户发了笔记后，过了大半天浏览量却还停留在两位数。这种现象给部分的笔记创作者带来的困扰。要想帮助这些内容快速形成滚雪球的效应，就得尽早地让推荐系统理解这些内容到底在哪个赛道上、质量是什么水平、谁可能感兴趣等问题。推荐系统时效性提高后，就可以更快地学习到这篇笔记的信息，从而更快地将这篇新笔记分发给合适的人，在更短的时间内获得用户的正向反馈；同时，发布笔记的作者也会因此受到鼓舞。
一个用户刚刚对一篇笔记产生了交互行为（点赞/收藏等），这代表用户对这篇笔记是有兴趣的。如果这个兴趣还是用户在刷小红书的历史行为中从未出现过的，这代表一个用户新的兴趣出现。推荐系统时效性提高后，这个兴趣会更快地被推荐系统学习到，那么在用户继续向下刷的过程中，推荐系统可以以很快的速度推送和这个兴趣相关的其他笔记，从而提高用户的个性化体验。
然而在2021年初，我们推荐系统中最重要的召回/初排/精排模块的时效性还停留在天级，也就是一天更新一次， 新发布的内容一天有一次上车的机会，错过了就得等明天，今天的笔记就只能和一些不那么合适的用户凑合着过了 。
因此，我们决定分阶段地对排序、召回模块进行高时效的改造。具体地，排序模型首先经历了从天级别到小时级，进一步到分钟级的升级；后续在召回模块中我们也进行了全面的时效性升级。
排序/召回模型应用链路
推荐系统的时效性牵扯面极其广泛，排在第一位的，自然是我们的排序部分。精排模型作为我们的试点项目，经历了最初探索式的天级到小时级的迭代，以及突破式的分钟级升级。下图描述了一个典型的排序/召回模型从数据生产开始到最终应用的链路，主要分为数据流/离线训练/线上推理三个部分：
模型时效性的提升在每个模块中都面临巨大的挑战：
◇ 行为归因：传统的做法往往会在 item 展示后等待30min左右的时间来收集交互 label，这使得分钟级别的模型时效性成为一大难题。
◇ 特征拼接：需要解决快速 join 归因完的前端日志及后端日志，并低时延地送给后续流程。
◇ 模型训练：实时化的训练方式往往会面临效果不稳定/模型不鲁棒等问题。
◇ 模型发布：动则几百个节点的大规模推理服务如何在保障稳定性的前提下低时延地同步训练结果也是一个极具挑战的工程问题。
在升级到小时级别的第一阶段中，我们快速对齐了一版可进化的方案，在数据流上核心保证的是链路 SLA 以及实时化，在模型训练上研发了实时化的训练方式以及鲁棒性相关的策略，在模型发布层面也推倒了原先全量重启的方式趟出了 PS-worker 分离发布的架构。
模型训练：整体 AUC 提升巨大但存在波动
从一天训练一次改为一小时训练一次的模式，我们在增量测试中发现，AUC 可以提升接近1个百分点。但是偶尔也会出现效果下滑甚至不如基线的情况。在多轮实验验证下，我们发现全连接网络比较容易受到一天中数据分布 bias 的影响，而训练实时化的收益来源却大部分来自 sparse embedding 的更新。因此我们尝试了一种 base+ 增量模型的方案：
◇ base 模型：与传统的天级训练一致，每天凌晨训练前一天完整的数据
◇ 增量模型：基于当天跑出来 base 模型，继续一小时一次训练今天实时的数据，但固定全连接网络参数不更新，只更新 sparse embedding
此外，我们的全连接网络中还包含了 BN 层
最低0.47元/天 解锁文章
扫一扫
6929
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
