当前位置:首页 > 快手培训 > 正文

快手推荐云建设

2020-12-03 18:16:08 暂无评论 快手培训

点击蓝字关注我们



作者:张翼 | 快手推荐中台负责人

出品:百林哲



导语:

推荐系统作为移动互联网时代和人工智能发展的共同产物,在现如今的常用手机里 APP中几乎无处不在。推荐系统本身是一个复杂的系统,有比较高的建设和维护成本,在唯快不破的互联网竞争中,如何实现推荐系统的快速迭代,使业务可以低成本快速试错,是一个很有挑战的话题。


快手出于自身业务发展的上述需求,建设了一站式的推荐云平台。推荐云不仅实现了业务独立的统一架构,加速迭代的同时保障了系统稳定,还为业务间推荐经验的分享复用提供了很高的便利。发展至今,快手推荐云已经支撑了上百个不同场景的推荐业务,并通过推荐系统演进有力的加速业务发展。



推荐中台整体架构




推荐云核心架构是快手推荐中台(Kuaishou Recommendation Platform,简称KRP)。推荐中台从层次上讲位于前台和后台之间。


推荐中台依赖快手基础架构和基础平台,将底层不具备业务属性的通用能力搭建成为沉淀了快手主站推荐系统经验的中台,往上支撑着各个业务前台,为不同业务定制和运行不同的推荐算法,优化不同的产品目标。


推荐云为推荐中台提供快速迭代和统一管理的操作入口,使得算法工程师们规范且高效的在推荐中台上迭代算法。



离线部分,推荐中台首先提供了基于用户日志的实时数据流,以及模型在线学习的能力,保证我们用户在使用产品中,体现出来的兴趣爱好被第一时间学到。


当在线推荐模块返回推荐结果的时候,会同时上传一份推荐日志,里面包含和此次推荐相关的多数原始信息。当用户拿到推荐结果,并且在手机上操作时(如点击、点赞、转发、举报等),相关的行为日志会通过日志作为反馈发送过来。这一部分的日志会由于推荐标的物的类型不同,格式有一些区别,所以日志会先经过转换,以统一的格式和在线推荐日志一起分发给不同的后台模块,如物品索引和用户画像生产,样本拼接,以及 A/B 实验秒级 / 分钟级实时指标等。



离线数据传输经常用到消息队列。常见消息队列(如Kafka)应用于推荐场景,有时会面临一类困境,即一份模型或索引数据需要同时分发到上千台甚至更多的机器,服务器出口带宽可能会被打爆。


为了解决这个问题,我们使用的是一种基于P2P的传输方式,从数据源开始,每份数据只发送给少量节点,每个节点承载着往其它节点分发的功能,最终形成树型分发结构。

好处:

每台机器的出入口流量都是固定的,完全不会随着集群的膨胀而膨胀。

整个树的深度是log(n)的,作为当集群膨胀的时候,数据整体更新的最大延迟也是log(n)。

当节点故障时,整个集群会通过选举算法,选出新的替代节点继续承担数据分发的职责。



在线推荐的流程,首先是触发(也叫召回),从全量作品池中获取用户相对可能感兴趣的一个子集。这里面包括包括基于倒排检索,基于模型,基于向量ANN(包括U2I、I2I等),基于ItemCF,基于热门内容,基于运营等等。


接下来是排序,这部分往往会经过一些以各种概率的预测目标的模型推理(如CTR、LTR等),然后经过打分公式或另外的模型,得到一个综合排序的结果。


在较大体量的业务里,排序可能会拆分成粗排和精排两个阶段,前者会用相对简单的模型结构,用更快的在线推理速度,比如说类似于embedding点积的方式,快速的过滤出一部分较优的作品,再经过相对复杂的网络结构,完成更精准的模型推理。


最后是重排阶段,这里会进行如多样性打散,不良结果过滤,运营强插等等。



通用接口设计



有了基础的推荐系统之后,我们将其抽象为跨业务通用的推荐中台,支持了任意类型的标的物推荐,如视频(分双列和单列)、直播、商品、好友、动态、音乐、魔法表情等等。


要做到平台对于多标的物推荐的全面支持和快速迭代,接口设计尤为关键。这里涉及两类接口:一类是业务接口,其使用方为各业务服务端工程师,作用为推荐结果的获取和用户行为上报;另一类是算法策略接口,其使用方为各业务算法工程师,作用为定义推荐算法细节,如推荐策略,模型参数和网络结构等。


业务接口设计



业务接口的设计关键是分层设计。


最上层的业务层,是服务开发工程师的角度,关心业务方最熟悉的业务数据形态,比如说对于视频单列,关心播放、点赞、转发等字段,直播关心进入直播间、打赏、送礼等字段。我们为每一类业务定制了设计一套业务友好的接口SDK。


往下是中台内部的层次。中台模块之间的交互,不能用定制化的字段去进行数据交互,否则必然会导致大量重复代码。所以推荐中台内部使用一种和标的物类型完全无关的通用的prototype,用于在各模块之间进行数据交互。


这样设计有两个好处。一是业务友好;二是维护成本低,当有全新的推荐标的物类型时,唯一需要做的事是开发一组新的业务友好的SDK,和定制化字段到通用product type的转换函数,完全不需要修改中台内部各模块。


算法策略接口设计



相比业务接口,算法策略接口相对复杂,设计时也更有挑战。


一个良好的算法接口,应该同时具备三个属性。第一,它要对功能进行封装和复用,这也是中台的存在意义。第二,它要简单易用,以降低学习门槛,加速业务迭代效率。最后是运行效率,因为我们面临的是规模如此庞大的用户群体,如此高的在线 QPS。


为了做到三全其美,我们将很多个推荐策略相似的功能进行提炼,拆分成若干个完全正交的原子化的功能,即底层的basic recommendation functionality,这些基本的功能和存储一次推荐请求所有上下文信息的 context一起构成我们整个架构最基础的部分。


在此之上是对下层的调用。我们对基础能力进行一些排列组合,定义一些function parameter schema,组装成具有完整推荐功能的pipeline。


在最上层,为了简化算法工程师的学习成本,提供优秀的代码可读性,我们设计了一套用于快手推荐中台的DSL (Domain Specific Language)并命名为Dragonfly,作为推荐中台统一算法接口。



在线推荐的每一个步骤(即前文所述“最基础的通用能力”)定义为一个processor,可以串行执行,也可以局部的并行化。特别的,涉及远程RPC调用的步骤,用一种异步的processor实现,它在发起远程的请求之后立即退出执行其它步骤,直到其指定的下游processor执行时,才会等待和解析远程RPC返回结果。


一个容易想到的问题是,推荐的策略被拆得很散,processor的类型会很多,其输入、输出数据各不相同,在自由组合时如何做到统一高效的对齐字段和逻辑呢?


KRP的解决方案是统一以context作为唯一数据交换的中心,它包含一次推荐请求的所有上下文信息,包括请求,推荐结果,所有中间数据等;同时定义一套统一的数据交换接口,用于往context中读写数据。每个processor不关心自己的上下游是谁,只需要从context中取出一部分数据,做某种特定处理,再把处理结果写回context。


这种数据交互方式,相比较processor之间直接交互数据,会多一次数据交互。因此数据交互接口需要尤其关注性能。我们开发了高性能的data accessor,针对不同的数据类型定制化的不同的数据交互接口以及实现,保证了足够高的执行效率。


所有这些设计串联在一起,我们将其命名为Dragon,作为推荐中台通用推荐流程框架的定义。Dragon提供了一整套推荐能力库(如U2I触发、I2I触发,PID流控,CTR预估等),每个算法工程师都可以从中选出若干个基础组件,配置以定制化的参数,组装成多个各自独立的完整推荐系统。


最后,为将整个流程给串联起来,用精简可读的方式进行表达,我们创造了推荐中台的通用DSL - Dragonfly。Dragonfly实际是一种脚本语言,负责将各个processor的参数,在程序运行时通过固定的Schema去传给C++编写的各个的基础的processor,并且将推荐链路组织成一个有向无环图,完成推荐过程。

Dragonfly的优点

  • 首先,它非常易用和易读,只要你会某一种编程语言,切换到dragonfly都是非常低成本的。

  • 其次,它提供了基础功能随意组装的能力。

  • 第三,运行效率很高,实际上线上服务里面并不存在C++和其它任何一种语言之间的跨语言交互,性能可以做到极致优化。

  • 再次,扩展性好。除了提供非常多的基础processor以供直接使用,对于可能存在的特别特殊的需求,仍然有开放的可扩展的接口用于业务方完全定制自己的个性化策略。

  • 第五,配置对齐。相比较手写配置文件,多个推荐流程输入输出参数的对齐可能因为大意而写错,但是在dragonfly里可集成为一行代码一次填写,避免了这类风险。

  • 最后,是参数自动检查。这里面包括参数类型,参数值域等,dragonfly会在代码提交前做好检查,避免将错误遗留到运行时。

Dragonfly的诞生,将公司迭代一个新推荐策略上线所需的时间,压缩到了约1/6,提供的基础processor数目已经上百,支持的业务数也已上百,累计已经为全公司所有使用它的业务方节约了数以万计人日的开发成本。



触发技术演进



基于Embedding相似性的触发算法,有着良好的适用性和理想的效果。在生产环境线上,通常使用的是ANN(Approximate Nearest Neighbors)算法。推荐中台的ANN算法经历了两次演进。



第一次演进是用Faiss取代Annoy,解决了Annoy线上服务准确率和召回率不够高的问题。为解决问题,我们针对快手ANN面临的三大难点进行了调研。第一是索引量大,生产环境索引量少则几百万,多则达到若干个亿。第二是索引更新的QPS很高,可以达到百万的级别。第三是严格的在线响应时间约束,单个ANN触发往往只允许10毫秒以下平均响应时间。综合以上三个特点,我们最终选择了Faiss IVF,同时其直观的检索参数也方便在多业务间推广。


此外,我们还和Intel进行了合作,在Faiss上集成了Read-once优化,在优化CPU Cache命中率的同时,减少了多线程同步等待的时间,单机QPS可提升一倍以上。



第二次演进基于Google新出的ScaNN算法库。ScaNN实现了在其论文中提出的一种对Quantization的优化,并且通过分桶的检索算法实现了性能提升。


ScaNN的检索算法大致可以分为三步,第一步和partitioning,这一步和其它分桶算法思想类似,在线从n个partition中选择和源向量最接近的若干个分桶作为检索范围。第二步是scoring,使用了相对简单但更快的打分,选出k’个可能最近邻向量。第三步是re-scoring,在k’的粗结果基础上,通过更精确的打分,选出真正最好的k个最近邻向量并返回。


我们在实际生产环节中的测试,在不同的中台业务中,ScaNN向量的检索,在相同召回率的约束下,可取得大概40%~100%的单机最大QPS收益。


另一个项目是触发的平台化。ANN类型的触发以ANN算法作为核心,不同触发策略有不同的前置、后置处理逻辑。我们将各个零散的ANN服务整合成了一个通用的出发平台,将触发能力池化,各个不同的ANN触发的流程使用统一的ANN核心算法库,不同的前置和后置的处理流程作为可选项供业务方配置。


通过触发平台,我们实现了接口统一,数据流共享,算力共享,以及线上算法流量的灵活调配。不仅优化了机器成本,而且由于接口的统一,上文调用方法简化和收敛,大大降低了整个系统的维护成本。未来我们计划将其它类型的触发统一融合到平台当中。



机器学习平台



在模型训练和推理这一块,在快手内部存在着多个不同的机器学习平台,都分别都接入了推荐中台。大多数平台我们同时支持GPU和CPU的训练,并且结合AEP机型,利用其NVM(非易失性存储)低成本实现在线TB级的模型存储服务。



在这多个机器学习平台当中,较为典型和广泛实用的,是快手自研的Kuiba机器学习平台,它针对DNN模型进行了一些适配和优化,提供了非常简便直观的模型配置接口。另外我们将TensorFlow和Kuiba进行了融合,用统一的上下游数据接口进行了流程的串联,并且用Kuiba的高性能参数服务器辅助TensorFlow完成实时的在线学习。我们为所有的这些机器学习平台设计的通用的样本接口,模型数据格式等等,使得上下游之间尽可能的解耦。算法工程师们在平台之间的切换变得更加方便。



提升模型推理性能的实验项目,最近是TensorRT。在推荐系统里面,GPU之所以在模型训练的时候比CPU有明显的优势,主要是面对海量训练样本的时,选择比较大的batch size可充分利用GPU矩阵运算能力实现高吞吐。而在预估的阶段,往往因batch size不够大,外加耗时敏感,GPU矩阵运算能力利用没有那么充分。对此,NVidia TensorRT为我们提供了一套GPU模型推理的SDK,利用预估阶段模型的网络结构和参数固定这一特点,通过对计算图的针对性优化(如合并、裁剪等),针对不同batch size的tuning,针对不同的GPU硬件优化等方法,优化线上预估耗时。


经过我们的测试,在某些业务的模型预估场景中,已经取得50%的性能收益。针对不同的模型和不同的在线预估参数,TensorRT的优化实验还会继续进行。


和触发平台类似的,模型训练和预估我们也在建设统一平台。以训练为例,我们将训练的流程抽象成为几个阶段(如提取基本字段,生成特征,拼接样本,发送到不同的训练内核进行训练等),每一个步骤进行抽象,提供给算法工程师灵活的组合搭配,使平台之间实现最小成本迁移,线上线下特征高度复用等等。



云平台建设



我们将推荐中台提供给用户之后,遇到了不小的挑战,即算法工程师使用中台像操作一个黑盒,使用中产生了大量各种各样的疑问。因此,我们希望有更加自动化更智能的办法,去解决用户“希望更高效的使用推荐能力”这一痛点。



为解决上述痛点,我们建设了一站式的云平台,对推荐中台的迭代尽可能的自动化,为算法工程师们屏蔽掉它们不需要关注的所有细节,只需要打开浏览器,进入云平台,选择自己的业务或者服务,点一点鼠标就可以完成推荐业务的迭代。


云平台的下层是所有必要的公司底层的,基础平台的能力,云平台对其调用和组装,抽象成为推荐业务能力。算法工程师如果要上一个实验,它们只需要提交模型的配置,然后点个按钮启动实验。这背后实际上可能需要在配置中心生成配置,分配机器资源,申请数据中间件,启动一些训练的服务和算子……所有这些工作由云平台自动化完成。同时在每个实验相关的页面,我们可以直接给出监控和回查调试的入口,方便在实验进行过程中快速对自己的算法进行评估和调优。



推荐云具备的能力大致可以分为迭代和管理这两类。


迭代能力按业务特点可分为离线实验、在线实验和全流量三类,每一类有着不同的迭代流程。离线实验会涉及任务排队、实验评估等等,在线实验会涉及在线学习、指标分析等等。全量服务则主要关注于故障处理,还有扩缩容等。


管理能力方面,推荐云提供了权限管理、资源管理、服务监控、调试回查等众多管理功能。每一类就会细分为若干的功能,运维工程师和其它管理角色,可以通过推荐云对各个业务的资源进行盘点和管理。


目前平台上运行的推荐场景数已经过百,不同的推荐子模块的类型有数十个,正在运行中的服务模块有2000多个。


推荐云将推荐业务迭代管理流程,进行有效的抽象,通过一站式的简便的操作体验,自动化的流程,使推荐的业务迭代更加快,使管理更高效,系统更稳定。帮助快手的算法工程师们,在平台上进行各业务的推荐算法迭代,协助支持用户(如资源管理和运维团队)通过平台为算法工程师提供业务的支持和辅助。推荐云位于快手各个和业务无关的基础平台之上,调用基础平台的能力,按推荐业务尤其是推荐中台的业务特点,串联成一个全流程自动化的平台。


在当前的计划当中,我们会整合更多基础平台的能力,开发更丰富的业务迭代管理功能,并且在进一步提供更高效更稳定服务的基础上,提供更智能的,更强大的推荐系统,全面助力业务加速。



作者简介

张翼,快手推荐中台负责人。清华计算机本科,2009 年中科院硕士毕业后加入搜狗,多年搜索、推荐系统经验,横跨互联网、金融科技等行业。2017 年加入快手推荐团队,担任推荐系统核心架构师,职责涵盖服务治理、架构升级、性能优化等等。协同团队从无到有研发快手推荐中台,并担任团队负责人,打造出快手全业务通用的全品类推荐系统完整解决方案。本职工作聚焦于整体架构设计,核心基础算法能力提升,并提供高效强大的一站式推荐系统支持,支撑着快手新老业务共计上百个推荐场景。


会 / 议 / 回 / 顾 


参会企业:微软、阿里巴巴、小米、腾讯、华为、360、平安集团、渣打银行、巟商银行、招商银行、随行付、易方达、长亮科技、乐融软件、广州银联、穆迪信息、拍拍贷、宇信集团、投哪儿金融、天维信息、萨摩耶、招商证券、国信证券、陆金所、广发基金、中国银联、恒天软件、天阳宏业、中数通、电信规划设计院、oppo、步步高、vivo、爱立信、百富计算机、厦门航空、福建联迪、恒大物联网、星网视易、升腾科技、视睿电子、飞利浦、金山软件、金山游戏、欧特克、顺丰、深信服、yy、虎牙信息、珠海健康云、优视科技(UC)52TT、21cn、凯米网络、苏州耕耘无忧、ADmaster、博思软件、网宿科技、珍爱网、金蝶、唯品会、大宇无限、华讯网络、传动数码、无限极、云湾信息、珠海网博、上海别样红、同盾科技、杭州顺网、蓝凌软件、诚毅科技、长园深瑞、中南民航、远光软件、中国移动、中国电信、中国联通、物理研究所、深研院等。



特 / 别 / 鸣 / 谢 



精 / 彩 / 推 / 荐

物联网企业SDL理念与实践

中台团队管理建设

从传统运维走向智能运维

阿里饿了么SRE的演进和AIOps实践

小蜜DEEPQA深度问答技术在智能办公场景的实践



精品推荐





欢迎点击“阅读原文”,时刻学习一线大咖技术经验,同时欢迎大家分享、评论

文章转载自微信公众号百林哲

猜你喜欢

博客主人破茧短视频培训
破茧短视频为你分享抖音、快手等短视频平台的视频拍摄、剪辑和运营技巧,另有短视频培训学习教程,海量干货助你玩转短视频运营!。
  • 51952 文章总数
  • 4875944访问次数
  • 2205建站天数