【工业级成熟设计方案】一个完整的推荐系统的架构设计

推荐漏斗

从算法侧的视角来看，我们通常看到的是推荐系统召回、粗排、精排和混排（重排）这样的漏斗链路，对应着一次推荐的请求下，从千百万的候选侧底池中一次“捞出”用户最感兴趣的几个候选。候选根据业务场景的指代有所不同，在广告业务下是广告计划，在电商业务下是商品，在推荐业务下是短视频等。这些环节的具体作用如下：

• 召回：从海量数据中快速筛选出候选集，平衡速度与覆盖率，召回的候选数量级一般在千级～万级；
• 粗排：简单模型快速过滤低质量候选，减少精排计算压力，粗排的候选数量级一般在千级；
• 精排：使用复杂模型融合多维度特征（用户行为序列、上下文、交叉特征等），输出个性化得分进行候选筛选，精排的候选数量级一般在百级；
• 混排：一般应用在多题材的聚合后统一排序，例如短视频、广告、直播等混合的推荐场景，输出最终的推荐列表，混排的候选数量级一般在个级～十级；
• 重排：可以理解为在单题材情况下的混排模块，例如只出短视频的场景，一般是综合整个列表的排序综合打分，输出最终的推荐列表。
  上述我们从算法侧迭代的环节分析了各个推荐漏斗模块的作用，也是最好理解的最粗粒度的推荐系统的概括。

推荐系统的工程链路

在实际的工业场景下，推荐服务会封装成一个下游各业务场景可调用的接口，推荐服务本身与业务无关，不同的业务场景根据当前场景的业务需求构造推荐请求来调用推荐服务，同时各业务场景会有独立静态策略配置，在请求推荐服务时会将配置参数一并拉取合并，构造出最终的完整请求。
举个例子🌰：电商App首页的猜你喜欢场景，一般都是需要保障多样性的，即避免连续出相似的商品影响用户体验；但是在标有食品Tag的子页面下，就不需要保障多样性，这两个场景便可以通过静态策略配置设定，通过一个参数开关让多样性策略在前者场景生效，在后者场景不生效。
推荐服务中请求参