共计 4878 个字符，预计需要花费 13 分钟才能阅读完成。
日前，由又拍云举办的大数据与 AI 技术实际|Open Talk 杭州站沙龙在杭州西溪科创园顺利举办。本次流动邀请了有赞、个推、方得智能、又拍云等公司核心技术开发者，现场分享各自畛域的大数据技术教训和心得。以下内容整顿自有赞数据智能团队负责人尹越现场分享：
尹越，有赞数据智能团队负责人，与团队成员一起承当有赞搜寻、举荐、客服机器人、智慧批发、风控、会员营销等多场景的数智化建设的职责。
大家好，我是来自有赞的尹越，明天次要和大家分享有赞数据智能团队在个性化举荐能力的演进与实际。我将首先介绍有赞公司和咱们团队，其次是分享下咱们从事的业务以及遇到的问题，最初聊下有赞举荐技术是如何逐渐演进的。
有赞数据智能团队
有赞是一家批发科技服务公司，致力于帮助商家经营挪动社交电商和全渠道新批发，服务好每一个商家的上门客户。我所在的有赞数据智能团队曾负责线上场景的有赞微商城，当初负责线下批发，包含批发门店网店的有赞批发业务，波及医美行业的有赞美业和波及线下教育的有赞教育。
有赞数据智能团队自身是一个间接面向业务的团队，咱们的主要职责是负责引领有赞数据智能过程，波及的业务包含举荐与搜寻、风控、精准营销、智能会员以及智慧批发。
有赞举荐业务及场景
业务场景
举荐业务 ：波及微商城、批发线上门店、教育、精选、分销、有赞客、爱逛，其中有赞精选是面向 C 端的平台业务，有赞分销是面向 B 端商家选货的平台业务，有赞客是面向网红主播选货的 CPS 平台业务，爱逛则是视频直播平台。
场景 ：有赞提供帮忙商家在本人微页面进行装修的自定义插件，笼罩商详页、购物车、付款胜利、营销流动页等外围交易链路。此外，还有商家和消费者进行沟通的晋升商品转化率的客服商品举荐场景。
展现模式 ：能够分为下拉的瀑布流举荐、广告 banner 举荐，以及综合了消费者的历史浏览行为、店铺热销行为和猜你喜爱等多种举荐模式的举荐橱窗。
标的物 ：波及商品举荐、优惠券举荐、店铺笔记举荐以及视频举荐。
模式 ：分只举荐商家店铺外部的店内举荐、波及其余店铺内商品的跨店举荐，还有前文提到的有赞精选的 2C 平台举荐和有赞分销的 2B 平台举荐。
场景示例
咱们能够先通过测试店铺理解有赞的商家是如何经营本人的店铺的。如上图所示，商家能够通过后盾治理，从店铺级别、商品级别、订单级别、数据以及资产等不同的维度实现整个外围交易链路的日常经营治理。
装修组件反对个性化举荐插件性能。如上图所示，右侧是一个微页面装修的局部，商家能够通过本人的需要配置如积分商城、常识付费等不同插件，组成本人所须要的微页面；也能够依据本人的需要，抉择以后场景所须要适配的举荐规定。
有赞举荐零碎的问题与挑战
店内商品丰盛度差别大。有赞次要是服务商家经营私域流量，不同的商家店内商品的数量会相差很大。有的商家可能多一点，成千盈百；而有的商家商品较少，可能只有几个。当商品数量非常少的时候，或者咱们的举荐价值没有那么地显著，这是一个问题。
跨店用户行为比拟少。这波及到以后 SaaS 经营模式的一个限度，即很难产生跨店的行为。它并不像淘宝、京东是一个平台型的产品，消费者能够很容易在不同的店铺之间逛来逛去。
业务场景复杂度高。有赞举荐业务既有面向 C 端的，也有面向 B 端的，还有面向客服场景的。整个业务场景以及团队须要对接的业务方绝对较多。
业务需求量大。简单的业务场景和对接的泛滥业务方，使得对团队举荐业务接到的需求量比拟大。
埋点数据易缺失。咱们的日志信息多在业务前端进行埋点，可能业务前端在进行其余性能降级的时候，会造成举荐相干的埋点数据失落。
有赞举荐技术演进
既然问题呈现了，咱们总要解决问题，上面咱们看一下有赞的举荐技术到底是如何一步一步演进，解决这些问题的。
有赞举荐零碎 1.0：竖井式架构
最底层的根底数据次要是业务数据和原始日志数据。业务数据个别是业务写在 MySql 当中的，比如说商品的原始信息、店铺的原始信息；日志数据包含商家在 B 端的操作行为日志以及消费者在 C 端的消费行为日志。
第二层是离线数仓层，这里包含了三局部：数仓 ODS 层大部分是将原始业务的数据在数仓中做一个表的映射，做一些简略的荡涤与补全；数仓 DW 层会将上面的异构的 ODS 层数据以通用的格例如以星型模型或者以其余的宽表模式，整合成适宜上游业务方应用的中间层数据表表；数仓 DM 层更贴近于业务，进行一些指标的聚合等相干的操作。
第三层是举荐相干的一些性能分层，首先看召回与特色这一层：在 1.0 版本不同的业务线会有独立的存储介质以及存储表，比如说像有赞精选和有赞分销都有本人的 HBase 表，还有一些特色可能本人存在在 MySql 当中，彼此之间也没有去通用。
第四层是线上服务层，在 1.0 版本当中，有赞的举荐零碎没有独自抽离出一个独立的零碎，而是把咱们的业务逻辑与业务方的 Java 代码绝对严密地耦合在一起，将不同业务当中的召回、排序都嵌入在业务代码当中。咱们过后应用的算法模型是传统的逻辑回归，通过 SparkPi MLlib 进行训练，再在通过 Java 在线上动静加载 PM 模型产生的排序成果。再往上是业务的前端跟业务的后端进行对接，前端负责展现和埋点相干的工作。
竖井式架构的缺点
可用的辅助零碎绝对较少。例如离线数仓生成不同的 Hive 表会须要有任务调度的有赞 DP 零碎，咱们须要有赞的 Meta 零碎查到不同的 Hive 表，相当于一个数据字典晓得有哪些表、哪些表有哪些字段。而为了分区成果以及比照做 AB 试验，在有赞 Bi 当中，数据组和算法组须要本人开发报表剖析业务成果。
还有一个显著的缺点是如果有新业务进来，起码从召回与特色层就要从新进行特色的制作。我可能须要独自抽出一个服务和业务方、前端进行对接。整个开发周期十分长，反复工作十分多。例如同样的商品，可能近 7 天销量、近 7 天退款率等一些数据很有可能在不同业务方会存多份，这个造成数据应用上的冗余。
有赞举荐零碎 2.0：集中式架构
2.0 期间将之前 1.0 的竖井模式转变为了集中模式，架构上带来了很多变动：
根底数据层引入实时数据
根底数据中除了离线数据外新引入了实时数据。引入实时数据的益处在于当消费者搜寻、浏览或者购买当前，基本上能在秒级别捕捉到他的行为日志。过后咱们是通过 Druid 做实时数仓，将行为日志落在 Druid 当中，提供上游的举荐引擎进行调用。
召回与特色层
为缩小不同业务对于同样特色数据应用的冗余的开发，咱们尽量将不同业务方都能够应用到的特色，对立地存储在同样的 HBase 表当中。在模型抉择上，咱们也从传统的机器学习模型迁徙到了 TensorFlow 架构下的模型服务，而后通过 TFServing 向线上提供模型的推理服务。
Java 版本举荐引擎
在新的架构中，咱们形象出了专门的 Java 版本的举荐引擎，并依照不同的性能进行分层，即触发——召回——粗排——精排——干涉。精排过程中会调用前文提到的 TFServing 的服务，进行商品等其余标的物的精排打分，最初的干涉更偏差于业务，例如将某些店铺内的商品打散或者要对一些条件进行过滤，是一个干涉重排层。
业务场景更简单
相较而言，2.0 版本对接的业务场景会更多，除了之前的有赞精选，像有赞微商城、有赞批发、有赞教育以及有赞客等，各个业务场景会通过新的零碎接入。
辅助零碎更欠缺
新增更标准化的记录埋点计划的埋点平台，专门用来做算法实现好坏的 ABTest 零碎以及帮忙咱们治理实时调度工作的有赞 RP 平台。
有赞举荐零碎 2.5：半开放式架构
尽管 2.0 版本比 1.0 好了很多，很多开发工作做到了资源复用，但仍有一些问题是没有解决的。Java 版本的举荐引擎中次要是提供一个对外的接口，而前端的展现以及埋点仍然要业务方的前端进行开发，这会给后续追踪业务成果以及 ABTest 实验所必须强依赖的日志信息的埋点准确性带来很大水平的挑战。
咱们之前遭逢过埋点和上线测试都验好了，但因为业务方其余性能降级引起埋点某些字段失落，最终导致前期成果没有方法跟踪，不得不推动业务方反向把埋点再补全的事件。在理论开发的过程当中，这十分影响开发效率和对接效率。
为了解决这些问题，咱们在举荐引擎与具体业务场景对接之间，新减少了一个举荐的前端服务化组件 。这样就把举荐各展现位的展现模式、如何埋点、和前面的举荐引擎以什么样的参数去交互等问题，和业务方的前端齐全隔离。只有前端告知是哪一个业务（所须要的是瀑布流模式、横排滑动模式还是其余模式的展现模式）、场景 ID 以及必要的参数信息就行了。这里可能通过七八行代码就能够疾速对接一个举荐业务场景，一天对接、一天测试，第三天就上线了。事实上，咱们曾经胜利通过有赞云开放平台向很多商家用户提供了该版本举荐引擎服务，帮忙商家能够在非有赞域内的页面展现本人的商品。
此外，2.5 版本中辅助零碎同步启用了有赞的算法平台，蕴含训练板块的 Sunfish 以及治理线上 TFServing 的分流与高可用的小盒子。
有赞举荐零碎 3.0：开放式架构
上图出现的 3.0 版本是有赞举荐团队心愿以后举荐架构的方向。目前有赞对接的商家从中等体量到大体量都有，而大商家对在各个场景都有定制化需要：教育类的商家心愿本人的商品能够依照教育课程、上课人群的年龄或者课程的级别要求进行关联举荐，而有一些商家又心愿肯定要本人设定的某几个商品呈现在某些展位前。面对这种定制化需要多样的问题，如果是单靠有赞举荐团队本人去开发、一直的迭代，老本是十分高的，而且也不太事实。所以咱们心愿可能通过不同的环节凋谢出更多的组件与插件，满足商家本人在不同场景的个性化需要，从而达到一个有赞举荐零碎整体的开放式成果。
目前整个举荐业务迭代过程中须要在多个平台之间来回切换，咱们也心愿后续可能有对立的举荐治理平台的形式，整合多个管理系统的性能，一站式解决整个举荐业务的对接。
召回、排序演进
召回和排序是举荐零碎当中比拟要害的两个环节，咱们具体开展介绍。
召回演进
目前召回局部的召回源大略分为四大类：I2I、U2I、T2I、兜底。
I2I：商品找商品的召回模式
- FPGrowth，开掘不同商品之间的关联性
- Item-CF，Item-base 协同过滤的算法
- I2T2I，通过标签将不同的商品之间建设关系
- GraphSAGE，基于图卷积的标的物进行向量化的召回模式
- 题目类似，将题目通过 Bert 产生题目向量，在题目向量之上基于部分敏感哈希做向量类似进行的召回
- 头图类似，将商品的头图通过图片分类模型抽取出图片对应的向量，在头图的向量上进行头图类似的一些召回
U2I：人找商品的召回模式
- DMP 召回源，指的是通过消费者的性别、年龄等一些用户维度的属性和商品进行关联
- U2T2I，和 I2T2I 相似，也是通过标签建设用户跟商品之间的关系
- User-CF，基于用户和用户之间类似的协同过滤
T2I：通过标签去找商品的召回模式
咱们有基于商品的类目分类模型，基于产品词、题目产品词的抽取模型，以及用户在搜寻过程当中搜索词和商品之间的点击购买关系所产生的关系模型。这一类召回源次要会用在前文提到的实时召回以及此前没有用户行为的场景
兜底的策略
当上述所有模式都生效且无奈取得任何上下文的时候，不能什么也不举荐，总得有一个兜底的策略，所以会有热销、爆款。
排序演进
最初跟大家分享一下有赞排序算法的演进过程。1.0 版本采纳的是绝对比拟传统的基于逻辑回归的一个排序算法，2.0 版本初期在应用深度学习框架之后，引入了绝对比较简单的入门级的 Wide & Deep 的模型。在经验了多版本的迭代、比照多个多任务学习框架后，咱们最初选用了阿里巴巴在 2018 年提出的 ESMM 模型，它能够把 CTCVR 以及 CTR 同时作为训练指标去训练。
当然在这些模型的尝试过程当中，咱们也在不同业务场景应用了其余的一些模型形式去做尝试。比方咱们在有赞分销业务中已经尝试过基于 ListWise 的 Learning to rank 的 LambdaMart 模型；而客服对话场景可能会更偏搜寻，咱们为了捕捉两个搜寻问句以及答案题目之间的语句相关性，咱们应用了 PairCNN 相干的深度学习模型，最初发现 ESMM 模型可能是现阶段比拟实用的。
举荐浏览
有赞对立接入层架构演进
聊聊风口上的 eBPF
