在互联网信息爆炸的今天，推荐系统是我们身边一个无法躲避的存在。在淘宝上浏览商品，在抖音上刷视频，以及无处不在的广告等等。本文探讨闲鱼商品推荐系统的同时，结合所面临的多推荐场景工程维护任务重、算法模型优化难以自动辐射多场景的痛点，介绍如何构建通用的推荐中台。
背景推荐系统
用户在网络上浏览时，如果能准确描述自己的需求，可以通过主动搜索来找到自己需要的信息。但是在不少情况下，用户并不一定能准确的描述自己的需求，或者用户就是来逛的，这个时候用户往往希望产品能主动把感兴趣的信息直接推送到自己面前。此时，推荐系统即发挥其中介作用，来连接用户与信息。
而在互联网信息蓬勃发展的今天，每时每刻都在生产大量的信息与内容。因此，推荐系统需要解决的问题，便是从海量的候选信息中，挑选出用户最感兴趣的信息。
为了完成这一挑选最优过程，典型的闲鱼商品推荐系统，涉及模块如下图所示。
• 数据
推荐系统本质是架构于数据之上的，这里的数据包括用户自身的年龄、性别、所属地域，用户所发布的商品、内容结构化数据，以及用户浏览过程中产生的曝光、点击、互动等行为数据。通过对海量的用户&商品&行为数据进行分析与计算处理，从而生成用户的trigger信息，生成样本数据辅助算法模型的训练，构建生成引擎索引数据表等。
• 用户信息
用户请求到来时，需要先识别出用户是谁，进而实现后续的个性化推荐。这里我们通常会根据用户的唯一id，查询用户中心服务系统，得到用户维度的基本信息。
• trigger
trigger，作为触发阶段，是推荐的源头，一般为用户历史浏览、点击、互动行为的商品，以及用户偏好等。在数据处理阶段，我们对这些trigger信息进行提炼。通过数据回流链路，最终将trigger信息存储于在线系统，在线请求服务时，根据用户唯一id实时查询出数据，参与后续的流程。
• 召回
上文有提到，全量的推荐候选集，数据量级往往突破千万，甚至级别。如果每一次的用户请求，我们均采用全局排序的思路，遍历整个推荐候选集，进行模式算分后，再找出topK个最佳预测的商品。这样的推荐效果可能很不错，但是对计算资源与性能要求过于苛刻，在生产环境中难以实现。因此，我们通过召回，来解决在候选集上进行全量排序的资源&性能问题。 在召回阶段，基于用户的特征与trigger信息，从全量的亿级别候选集中，挑选出万级别的商品，送入后续的算分排序阶段。而在召回手段上，主要有规则定义、协同过滤、向量召回等。
• 粗/精排
算分一般也分为粗排 精排两阶段。粗排针对召回的万级别商品进行模型算分，由于打分候选量级较大，这里模型网络结构上一般采用双塔结构，而不做复杂的交叉网络。有了粗排分，我们再挑选排在前面的千级别候选集，进行一轮精排模型算分。此时待打分的商品量级可控，因此这一环节通常采用更多的用户&商品&交叉特征与较为复杂的网络模型。
• 重排
前面的排序主要通过算法网络模型决定，而重排阶段，则会体现场景的业务诉求，做一下打散干预，比如类目打散、价格打散等。
• 结果返回
经过上面的链路后，推荐系统最终将topK个（一般为10~20个）最佳预测的商品，填充元信息后，返回给用户进行展示。
• 日志&埋点
对展现给用户的商品做日志记录与埋点，便于回收用户行为数据。
基于上面的分析，一条完整的推荐链路开发维护成本并不低，其中涉及离线数据分析处理、采集样本、算法模型训练、模型&内容表索引构建、在线查询&召回&算分引擎部署、在线推荐服务开发、日志&埋点回收等。
面临的问题
闲鱼目前推荐场景数10 ，在过去四个月新增了4个新的场景（闲鱼币，新品推荐，购后推荐，新发tab），同时更多推荐场景正在规划中（省心卖，首页tab feeds流等），这么多的tpp场景背后是闲鱼对个性化推荐的大量需求。 从工程角度来看每个新业务接入都需要从0到1搭建完整的推荐链路，除了大量重复的工作之外还伴随着不小的维护成本，如何才能降低如此众多场景的边际成本提升边际效益。 从算法视角来看，这些推荐场的算法模型都需要case by case迭代优化，如何实现模型迭代优化自动辐射到更多的场景。
