在小红书 APP 中,引荐体系的实效性对引荐作用有着特别重要的影响,特别是作为 UGC 平台,小红书的引荐体系假如能更快地捕捉用户与笔记之间的变化和联系,就能够给引荐带来更好的作用。在2021年上半年,主页引荐的召回、粗排、精排的首要模块都保持在天级更新的状况,咱们通过持续迭代,将召回 CF 途径、召回索引更新、召回模型/粗精排模型的练习都做到了分钟级更新,为主页引荐的分发功率带来飞跃式提高,并给事务侧带来十分明显的收益。

1. 为什么做小红书引荐体系的高时效更新

小红书站内“最近一天内发布的新笔记”在主页的曝光占比一向很高,这段时间更是快速增长,几乎占到了一半。

不过,也经常会有这种情况呈现:用户发了笔记后,过了大半天浏览量却还停留在两位数。这种现象给部分的笔记创作者带来的困扰。要想协助这些内容快速形成滚雪球的效应,就得尽早地让引荐体系了解这些内容到底在哪个赛道上、质量是什么水平、谁或许感爱好等问题。引荐体系时效性进步后,就能够更快地学习到这篇笔记的信息,然后更快地将这篇新笔记分发给适宜的人,在更短的时间内获得用户的正向反应;一起,发布笔记的作者也会因而受到鼓动。‍‬⁢‪⁢ ‭‭‌

‍‬⁢‪⁢‭‭‌一个用户刚刚对一篇笔记发生了交互行为(点赞/保藏等),这代表用户对这篇笔记是有爱好的。假如这个爱好仍是用户在刷小红书的历史行为中从未呈现过的,这代表一个用户新的爱好呈现。引荐体系时效性进步后,这个爱好会更快地被引荐体系学习到,那么在用户持续向下刷的进程中,引荐体系能够以很快的速度推送和这个爱好相关的其他笔记,然后进步用户的个性化体会。‍‬⁢‪⁢ ‭‭‌

‍‬⁢‪然而在2021年初,咱们引荐体系中最重要的召回/初排/精排模块的时效性还停留在天级,也便是一天更新一次,‍‬⁢‪⁢ ‭‭‌新发布的内容一天有一次上车的机会,错过了就得等明日,今日的笔记就只能和一些不那么适宜的用户凑合着过了‍‬⁢‪⁢ ‭‭‌。‍‬⁢‪⁢ ‭‭‌

因而,咱们决议分阶段地对排序、召回模块进行高时效的改造。详细地,排序模型首要经历了从天等级到小时级,进一步到分钟级的晋级;后续在召回模块中咱们也进行了全面的时效性晋级。

2. 先头部队-排序模型:从天级到小时级‍‬⁢‪⁢ ‭‭‌

排序/召回模型运用链路

引荐体系的时效性牵扯面极端广泛,排在第一位的,自然是咱们的排序部分。精排模型作为咱们的试点项目,经历了最初探究式的天级到小时级的迭代,以及打破式的分钟级晋级。下图描述了一个典型的排序/召回模型从数据出产开端到终究运用的链路,首要分为数据流/离线练习/线上推理三个部分:‍‬⁢‪⁢ ‭‭‌

小红书高时效推荐系统背后的技术升级

模型时效性的提高在每个模块中都面临巨大的应战:

行为归因‍‬⁢‪⁢: 传统的做法往往会在 item 展现后等待30min左右的时间来收集交互 label,这使得分钟等级的模型时效性成为一大难题。

特征拼接‍: ‭‭‌需求处理快速 join 归因完的前端日志及后端日志,并低时延地送给后续流程。

◇ ‭‭‌模型练习‍: 实时化的练习方法往往会面临作用不稳定/模型不鲁棒等问题。

模型发布‍: 动则几百个节点的大规模推理服务如何在确保稳定性的前提下低时延地同步练习成果也是一个极具应战的工程问题。‍‬⁢‪⁢ ‭‭‌

在晋级到小时等级的第一阶段中,咱们快速对齐了一版可进化的计划,在数据流上核心确保的是链路 SLA 以及实时化,在模型练习上研发了实时化的练习方法以及鲁棒性相关的战略,在模型发布层面也推倒了原先全量重启的方法趟出了 PS-worker 别离发布的架构。

模型练习:整体 AUC 提高巨大但存在动摇

从一天练习一次改为一小时练习一次的形式,咱们在增量测验中发现,AUC 能够提高接近1个百分点。但是偶然也会呈现作用下滑乃至不如基线的情况。在多轮试验验证下,咱们发现全衔接网络比较简单受到一天中数据分布 bias 的影响,而练习实时化的收益来源却大部分来自 sparse embedding 的更新。因而咱们尝试了一种 base+ 增量模型的计划:

base 模型: 与传统的天级练习共同,每天凌晨练习前一天完整的数据

增量模型: 依据当天跑出来 base 模型,持续一小时一次练习今日实时的数据,但固定全衔接网络参数不更新,只更新 sparse embedding

此外,咱们的全衔接网络中还包含了 BN 层,这儿咱们也发现 BN 层也需求和全衔接网络一起固定才能到达最佳的鲁棒性。

小红书高时效推荐系统背后的技术升级

模型发布:全量重启的形式无法支撑高频的发布需求

在天级模型的阶段,咱们往往会挑选重启的方法进行模型发布,一则简单二则能够做更多的测验流程确保稳定性。在实时化的形式下,高频发布是个硬要求,就此咱们将发布流程改造成了 worker-PS 别离发布的形式,worker 只担任全衔接参数的更新,PS 担任 sparse embedding 的更新。合作前文说到的 base+ 增量模型的计划,worker 只需一天发布一次,而 PS 需求每小时发布一次。这儿 PS 作为一个 embedding kv 服务,每次加载最新一小时的增量文件仍是比较快的。

3. 精雕细镂-排序模型:从小时级‭‭‌‭‭到分钟级

从小时等级到分钟等级的跨过,在事务收益上,收窄是可预期的,因为一小时内发布的新内容的曝光量占比大盘有限。但还算不低的预期收益 +show muscles 的技能才能促使了咱们快速将分钟级更新提上议程,咱们在每一个上述模块上,做了进一步的优化:‍

行为归因:如何越过传统的固定半小时左右的等待窗口?‬⁢‪⁢ ‭‭‌

依据小红书的事务场景,咱们引入了额定的提早下发样本的逻辑。通过提早判别用户是否现已完毕了对当时笔记的消费,咱们越过了大部分无谓的等待时间。详细逻辑为当用户在双列进步一步发生了必定数量的曝光或许下拉刷新时,则提早下发当时样本,不然依然沿用原战略。

小红书高时效推荐系统背后的技术升级

模型练习:按时序的练习方法存在稳定性问题?

更实时的练习方法,就无法再依靠传统的 shuffle 数据的手法带来的稳定性。比较传统的 shuffle 数据再练习的形式,纯实时的模型练习往往会面临 pcoc 动摇较大的问题。在试验进程中,咱们也观测到了一个现象:经常在小时整点刚开端的时候 pcoc 简单发生误差。通过深入的分析研究,咱们定位到原因是因为整点前后的数据分布存在必定差异:因为样本提早下发的逻辑,负样本一般会比正样本更早下发,因而如下图所示请求发生时间在9点的样本 ctr 会明显低于来自8点的样本,而模型中的小时特征就会吸收这部分过错的信息。处理这类问题的方法便是在实时练习的进程中停止这类特征的更新,只依靠天等级模型供给的信息。

小红书高时效推荐系统背后的技术升级

模型发布:高效且鲁棒的实时更新形式?

在模型练习进程中咱们会保护一个需求发布的行列,每隔1分钟将行列中一切参数发布 Kafka。

此外,1小时导出一次文件的逻辑依然保存,一起会添加对应的 Kafka offset,首要用于稳定性确保,能够支撑离线练习重启时,线上 PS 主动从最近的一个小时级文件重启;也可用于线上 PS 发版时削减 Kafka 数据的消费量。

小红书高时效推荐系统背后的技术升级

以下是整个改造工程前后每个模块的延迟数据比照。

小红书高时效推荐系统背后的技术升级

4. 全面提高-召回模块:打破瓶颈‍

对召回来说,在初精排都现已到达分钟级更新的状况下,召回模块现已变成了整个引荐体系到达高时效性的最大瓶颈。但比较排序来说,召回模块显得更繁杂,打个简单的比如,‍‬⁢‪⁢ ‭‭‌假如提高初精排模型的时效性是在带两兄弟上大学的话,那提高召回模块的时效性便是在带一个班级考大学‍‭‭‌。‍‬⁢‪⁢ ‭‭‌

在项目启动之初,小红书召回模块的状况如下:

◇ 点召回: ‬⁢‪包含依据内容了解特点构建的新笔记倒排和依据用户特点构建的精选笔记倒排,其间前者现已能够做到分钟级更新,后者为小时级更新。

◇ 协同过滤召回‍‬⁢‪: 包含 i2i、u2u、a2a 等多种类型的召回途径,悉数处于天级更新状况,u2i2i 这种依靠 u2i 的高阶版 i2i 召回才能更是没有树立。

‭‭

◇ 模型召回‍: 首要指 u2i 类型的模型召回途径,一起 u2i 线上召回依靠向量检索服务(ANN)。其间召回模型练习和更新的频率当时也是天级,而全量可分发笔记索引更新的时效性停留在天级,新笔记索引更新的时效性在小时级,因而整个模型召回途径的时效性也停留在天级。

◇ 图召回‍: 首要指依据 GNN 技能构建的召回途径。在项目开端之前曾完成过天级的版别,但作用不抱负。

‍‬⁢‪能够看出,除了少部分召回途径外,其他大多的召回途径均处于天级更新的状况,所以召回模块成为整个引荐体系到达高时效性的最大瓶颈。因为上述不同的召回途径的原理不同,想要晋级成分钟级更新需求的技能栈各不相同,有些晋级乃至对整个工程体系架构都提出了很高的要求。召回组的同学一步一个脚印,花了将近一年的时间,将上述途径逐渐悉数变成了分钟级更新的状况,使得高时效性的引荐体系终究成为或许。‍‬⁢‪⁢

整个进程分为三块进行:

CF 召回实时化

CF 召回,即协同过滤召回,是召回算法领域的一个经典算法。就小红书的场景来说,算法的思想便是许多用户一起看过的笔记/作者之间一般会比较类似 (i2i/a2a),看过许多相同笔记/作者的用户之间也会比较类似 (u2u),所以算法的核心动作便是核算不同笔记之间/用户之间/作者之间的共现次数。规范的 CF 算法一般是天级频率更新,这样离线的核算流程和代码完成都比较简单。但这样做就导致无法快速的学习用户的实时爱好。

以 OnlineSwing 为例,规范 Swing 算法的公式如下:

S(i,j)=∑u∈Ui∩Uj∑v∈Ui∩Uj1+|Iu∩Iv|S(i,j)=\sum_{u\in U_i\cap U_j} \sum_{v\in U_i\cap U_j} \frac {1}{\alpha\ +|I_u\cap I_v|}

其间UiU_i表示看过笔记ii的用户调集,IuI_u表示用户uu看过的笔记调集。

比较传统的 ItemCF 算法,Swing 的首要差异在于引入了不同用户 pair 的奉献度,对于一起看过笔记 ii 和笔记 jj 的用户uu 和用户vv ,两个用户一起看过的笔记越多,则对笔记 ii 和笔记 的类似度的奉献越低。因为引入了二跳关系,且小红书的活泼用户数和可分发笔记数是比较大的,因而在小红书的场景下跑天级 Swing 算法的资源消耗十分巨大。而从另一个视点来说,即使天级 Swing 能够跑得起来,也无法得到用户的实时行为,然后无法捕捉到用户的实时行为信号。

综上,将 Swing 算法晋级为实时化更新是十分有必要的。因而咱们对算法做了改造,将天级 Spark 使命晋级为分钟级 Flink 使命,并结合使命特点在中心存储环节选取了公司自研的 KV 存储 RedKV,确保了使命的功率和稳定性,终究以比天级 Swing 更少的练习资源拿到了更大的收益。

OnlineSwing 整个架构规划如下:

小红书高时效推荐系统背后的技术升级

仿照此思路,咱们将一切的 CF 途径都进行了晋级,然后将 CF 类召回的时效性悉数说到了分钟级。

此外,在 Swing 晋级到实时化后,咱们重新尝试了图召回算法。咱们将实时 Swing 的倒排用在了异构图 GraphSAGE 召回途径的建图阶段,使得图中笔记与笔记之间连边也能够做到实时更新,并通过分布式 GNN 结构进行练习,使得图召回模型的才能得到了有效发挥并终究落地。

召回模型练习更新实时化

与初精排类似,u2i 模型召回要到达实时化更新,首要需求有一个高时效的模型被练习出来。召回模型的练习结构采用了和初精排一样的结构,但和初精排不同的是召回练习数据一般由多种类型的样本组成,因而实时数据流的 Flink 使命杂乱度更甚。以 DSSM 模型召回数据流为例,正样本提取、曝光负样本采样、召回未曝光样本采样(咱们称为纯负样本)以及三者按比例 union,咱们通过许多的 Flink 流式使命改造,终究将召回模型练习样本同样做到了实时化,如图所示。

小红书高时效推荐系统背后的技术升级

现在召回模型现已完成序列化建模、多爱好建模、Session 图建模、比照学习建模、EE等多种爱好建模和多种负采样方法的落地,均到达分钟级更新的才能。

另外在小红书杂乱召回技能的探究进程中,也处处体现着对高时效性的追求。以 LR 召回和近线召回为例(包含但不限于这两种召回,更多的前沿召回技能也在持续调研和落地中)。

◇ LR 召回:LR 召回为模型版的 i2i 召回战略,LR 模型更新同样采取了分钟级更新的结构,实时的将模型的最新 PS 推送至 model converter 完成倒排的快速更新

◇ 近线召回:最开端是为了凌晨搁置资源的高效运用,后续为进步该途径的时效性以及搁置资源的运用率,咱们将形式改为在线异步核算,将近线扫库运用的模型晋级为更杂乱的模型,一起将 CPU 晋级为 GPU,完成了近似实时全量扫库的作用。

LR 召回架构图(Larc 为小红书自研大规模分布式离线 DNN 模型练习结构)

小红书高时效推荐系统背后的技术升级

近线召回初版架构图

小红书高时效推荐系统背后的技术升级

最后值得一提的是,后来咱们还引入了 u2i2i 这种 u2i 和 i2i 相结合的召回途径。这种召回分为 u2i 和 i2i 两阶段,因为 u2i 和 i2i 都具有了快速更新的才能,使得 u2i2i 召回也做到了分钟级更新。

小红书高时效推荐系统背后的技术升级

向量检索服务实时化

模型召回包含召回模型练习和索引构建两阶段,因而做到实时化还需求进行索引构建和更新也到达分钟级的时效性。‍‬⁢‪⁢ ‭‭‌

ANN,全称近邻检索服务,是用在向量召回场景的一种特殊的服务。向量召回模型一般是以双塔的形式存在,即一个 User Vector 的预估塔和一个 Item Vector 的预估塔,别离预估用户和笔记的高维笼统表达,两个向量通过余弦类似度/内积等方法来衡量两者的类似度。假如一个用户对一个笔记发生了正向行为,则两个 Vector 也应该比较类似,反之亦然。而向量召回模型在线上 serving 时,面临海量的候选笔记池,是无法做到实时全库暴力核算的,ANN 正是为了处理这个问题而呈现的。ANN 的功用在于,离线部分将一切笔记的 vector 组织成一个索引发布到线上,在线部分通过 User Vector 对该索引进行检索得到最类似的笔记作为返回成果,而这个索引是通过一些特殊的算法进行构建的,能够将检索的速度提高到 ms 级,然后满足线上请求的实时性。‍‬⁢‪⁢ ‭‭‌

从上面的描述能够看出,ANN 服务涉及到离线笔记id获取、笔记特征获取、笔记 vector 预估、离线索引构建、索引发布到线上、在线 serving 这几个流程,老版别的 ANN 服务全量笔记完成一轮更新需求12个小时左右。想要将这个服务做到分钟级,需求将上述每个环节都做到分钟级乃至秒级的程度。‍终究,在咱们的通力合作下,霸占了一个又一个难题,成功的将 ANN 做到了分钟级,内部称之为 RedANN。‍‬⁢‪⁢ RedANN 的规划图如下:

小红书高时效推荐系统背后的技术升级

此次晋级包含以下方面:

整个服务 C++ 化: 原有 ANN 离在线服务首要通过 Java 完成,只要底层检索库采取了 C++ 完成,本次晋级将离在线服务改为纯 C++ 完成,提高服务功率。

离线规矩引擎晋级: 自带实时正排(EdgeStorage),并支撑自定义过滤&分库功用,供事务方定制化运用。

检索算法晋级: 除 HNSW 外,支撑多种业界先进检索算法(包含现在工业界表现最好的 ScaNN 检索库),供事务方自行挑选运用。

时效性晋级: 将全量索引更新时效性提高至10min内,将天级小时级索引更新时效性提高至1min以内。从笔记 id 呈现到进入索引一共经历三个阶段:

笔记 id 获取: 采取 Batch 和 Realtime 相结合的方法,Batch 是指每隔一段时间获取全量可分发笔记,从公司内部自研的分布式 p2p 数据传输服务 Redcast 获取;Realtime 是指新笔记或笔记状况发生变化的笔记,从 Kafka 获取;

☐ 笔记 embedding 生成和存储: 走独立部署的特征获取和模型预估服务(Hamster),得到笔记的 embedding,并存入依据 RocksDB 完成的embedding kv;

☐ 笔记索引构建: 依据规矩引擎过滤后的笔记调集,从 embedding kv 中获取最新的 embedding,采取索引构建算法分钟级构建索引;

上述三个阶段通过三个独立的进程并发执行,到达 id 更新、embedding 生成和索引构建解耦的作用。

在线装备化接入晋级: 之前的在线服务新增索引需求发版,等待时间较久。此次晋级中咱们重建在线服务,支撑在线索引装备化接入,一起合作离线模块同步做检索算法晋级。

晋级进程中遇到的困难

◇ 纯 C++ 服务,但公司 C++ 基建相对单薄,需求许多的准备作业,如需求处理十分多的编译问题,许多问题是公司前人从未遇到过的。

◇ 项目规划之初就将易用性作为最首要的目标之一,期望在事务方零代码开发的前提下支撑各场景下的分库&过滤需求。分库&过滤的易用性本便是业界普遍存在的难点,团队成员调研许多业界主流做法和多种胶水言语(Lua、Julia 等),多次讨论后自研依据 Lua 的规矩引擎,事务方只需求在装备文件中编写 Lua 脚本就能够依据正排信息做过滤&分库,大幅提高分库&过滤的易用性。因为 Lua 执行时需求拓荒栈空间、Lua变量为动态类型等原因导致 Lua 的执行功率比 C++ 慢30倍以上,全库笔记过滤一轮需求 8min 左右,团队成员以更高的规范不断优化,最后将耗时从 8min 左右降到 2min 左右。

◇ 本项目依据 RocksDB 对 embedding 做耐久化,RocksDB 原本是为磁盘型存储引擎规划,上线后全量笔记 embedding 查询需求 6min,成为全量笔记索引更新到达 10min 以内的目标的最大瓶颈。为了处理这个问题,团队成员对 RocksDB 进行了一系列调优,包含 hash index block 调优 → 内存文件 → plaintable 优化,终究将时延从 6min 优化到 1.5min 以内,为全量索引更新到达分钟级扫清障碍。

◇ ScaNN 是相对较新的检索库,很难找到业界其他公司揭露的成功运用参考事例,接入进程中遇到许多编译问题,如:ScaNN 是依据 Clang 编译,代码与 GCC 编译器不兼容;ScaNN 要求 protobuf 版别不低于 v3.9.2,但公司内的第三方库依靠的protobuf版别都较低,需求同步晋级公司内部许多的第三方库。通过耗时一个月的对 ScaNN 的二次开发和封装,处理了各种编译问题,终究成功将 ScaNN 检索算法接入 RedANN 服务。

至此,召回模块首要离在线服务悉数晋级至分钟级更新状况,小红书高时效性引荐体系正式成型。

5. 总结

高时效项目累计供给小红书主页信息流人均时长 10% 以上,一起也带来了交互 15% 以上和新笔记功率近 50% 的提高,是算法侧最大收益项目之一。这儿面包含了咱们团队许多的试验尝试,其间也不乏一些失利的探究,‍‬⁢‪⁢ ‭‭‌每一次看似轻松的 Full Launch 背后,或许都有不为人知的故事‍‬⁢‪⁢ ‭‭‌。

现在咱们的技能也现已逐渐在信息流广告等场景进一步得到运用,未来咱们期望能够将相关的技能推广到公司其他更多事务线,为公司整体带来更大的事务提高。‍‬⁢‪⁢

6. 作者简介

青雉(祁明良):技能部/智能分发部

小红书引荐算法工程师,毕业于上海交通大学核算机系,在小红书长期致力于提高主页引荐作用,现首要担任精排模型方向的相关研究和探究。

大辅(苏睿龙):技能部/智能分发部

小红书主站引荐召回技能担任人,毕业于上海交通大学核算机系APEX试验室,前国内顶尖围棋AI团队核心成员,在引荐、AI、广告等方面深耕多年,尤其在内容引荐领域有着丰富的实战经验,现担任小红书社区多场景召回技能迭代和事务支撑,以及召回技能平台化的作业。

特别感谢:智能分发部悉数项目组成员