作者·黄崇远

『数据虫巢』

全文共4520字

题图ssyer.com

“ 所有的技术架构并不是一蹴而就的，都是在需求迭代中逐步的探索，并且不断的适应业务的发展，才逐步发展成最终我们所看到的样子。”

模型只是其中一环，在高速发展的这几年，各个场景，各个层面的模型探索可谓到了极致，所以有迹可循，有很多可以参考的方式方法，建模套路，横向以及纵向的模型选型，结合自身业务特点，对于样本、特征，或者目标的确定去做决定。

但在早期，其实推荐系统就等同于推荐的算法模型，包括早期协同推荐流行的时期，这是因为这是从人肉时代向机器时代过渡的阶段，其核心目标是建立一个比去过更为高效的流量分配机制，因此模型起到了决定性作用。

任何大机制的演变，都有其核心影响要素作为核心推动力，让推荐模型只是模型而不是推荐系统的变化最核心的因素是，数据在持续暴涨，甚至暴涨到单纯将数据灌入到模型然后直接输出结果的方式再也行不通，这里的行不通在于对效果以及性能的要求。

其次是业务的复杂性进一步被放大，例如电商场景中典型的ITEM数量巨大，上个章节中提到的酒旅行业的数据稀疏性问题，以及新闻资讯中ITEM实时性的问题等等。除了业务本身的复杂度不断的提升，其商业目标也在不断的进化，从过去单纯追求推荐流量粘性上升，提高到融合不同的商业目的，例如电商的品牌扶持，对于购买，甚至是留存追求等等，视频播放中对于时长的追求，直播领域对于打赏关注等深度转化的要求等等。

如上业务问题，单纯通过一个模型或者几个模型是解决不了的，需要一套相对成熟的解决方案来处理，而这个解决方案核心依托的就是系统架构的设计。

所以，叠加以上因素，最终是一个精益求精的演进过程，这里所谓的精益求精，不单纯是效果的提升，还有性能的要求。

于是，就衍生了分工，明确分工、各司其职是推荐系统设计的最核心原则。但聊框架的完全形态之前，笔者希望从推荐系统的发展逻辑出发，逐步陈述推荐技术框架的演化。从这种变化逻辑中看我们的推荐逻辑在技术框架维度是如何变化的，并且由于读者朋友们所处的业务场景肯定也同样会有不同阶段，不同的人力和成本的预算，从这个变迁逻辑中能够找到最适合自己的方案，以及逐步迭代的方向。

我们还是从“远古”时代说起。早期的推荐逻辑的初始目标大多为在不降低效果的前提下，替换掉人肉的推荐或者精选逻辑。

这个目标是非常容易实现的，简单到可以用统计逻辑来统计历史优质ITEM，大概率都会人工做精选效果会好一些，并且还可以实现数据的自动更新。

此时，从技术实现或者说技术架构的角度来说，并无严格的技术架构的逻辑，只需要做一个定时的历史数据统计逻辑，然后把数据推送到服务端离线加载即可。

图2.2.4.1 基于优质ITEM统计的简单推荐架构

如图2.2.4.1所示，基于优质ITEM简单技术架构是非常简单的，只需要按天以一定的优质逻辑统计，即可将优质ITEM同步到数据库中，然后在相应的ITEM展示栏位进行数据调用即可。

这是一种最简单的推荐逻辑实现，并且是离线的，非个性化的推荐，基本上只能满足于用于替换最基本的人肉配置推荐的逻辑，且提供一种自动的数据更新逻辑。

图2.2.4.2 基于ITEM相似的简单推荐架构

简单统计可迭代的空间很大，进一步可以做到物品的相似推荐，用户浏览某个ITEM时，在相关位置进行推荐逻辑的陈列，是一个非常常见的推荐场景。因此，基于相似ITEM的推荐逻辑在此基础上是一个较大的提升。

与简单统计的技术架构相比，相同点在于同样是一个离线的逻辑，最终在推荐服务中都是走查询获取推荐结果的方式，不同之处在于计算更为复杂，且推荐的入参从无变成了ITEM的唯一标志，最终输出的结果虽然依然不是USER层面的个性化，但是可以随着ITEM的变化进而推荐结果产生变化，实现一定程度上的场景个性化。

图2.2.4.3 基于USER的标签匹配、协同推荐架构

在上面两个简单逻辑中，始终没有进行USER层面的数据引入，那么就达不到用户级别的个性化结果输出。因此，如图2.2.4.3这种技术架构，核心支持的是动态的输出USER的特征，并且进行ITEM层面的特征匹配，从而实现有限程度的USER个性化。

这种技术架构的改动点在于虽然大部分数据都是离线计算好，但是匹配逻辑是实时进行匹配计算，因此引入检索匹配的组成成分，用于替换直接的数据或者内存查询。

对于ITEM和USER的关联数据，由于其关联关系数据量过大，通常我们无法提前存储好他们之间的关联关系，因此才要借助于索引匹配或者矩阵检索等方式进行实时查询。

除此之外，我们在2.2.2章节中提到的协同过滤，同样可以复用这个架构，本质上是经过离线的协同过滤，然后在匹配的时候做相似检索，或者依托于矩阵做矩阵检索，从而实现USER的个性化推荐。

图2.2.4.4 基于USER的在线预估推荐架构

在上面的技术实现中，大部分都是支持离线计算好结果，然后在线服务中进行直接查询，或者通过索引进行快速查找匹配，又或者是通过矩阵计算来快速获取推荐结果。

对于推荐来说，很多短期的行为更能体现用户的兴趣偏向，同时对于用户进行建模，在兴趣预测的准确度上有较大的提升，因此，必然会提出一种新的技术架构用于承载这种偏向于实时推荐的逻辑。

如图2.2.4.4，我们在离线部分里做的只是样本和特征的获取，以及进行离线模型的训练和定期同步，然后将模型部署在线上，当有用户进来时，实时进行用户特征的获取，然后进行在线的概率预测，将预测概率最大的一个或者若干ITEM推送给用户。这里用户的特征，一部分是实时的行为特征，一部分是离线计算好的特征。

用户的行为数据以及用户是否转化的结果数据也会反馈到模型中，最终不断的优化模型，使得整个逻辑进入良性循环周期中。

图2.2.4.5 当前较主流的推荐技术架构

图2.2.4.4的技术逻辑只能支持ITEM数量较少的推荐场景，又或者需要先进行推荐候选集的优质筛选之后，进行建模然后进行推荐。因为在线的推荐对于性能是有较高要求的，但当我们的候选推荐以数十万、数百万甚至是千万量级时，我们需要一个更加完善的逻辑来优选候选集。甚至，随着业务不断的发展，更多的商业考虑也会持续不断的融入到推荐的技术架构中，来解决商业价值最大化的问题。

如图2.2.4.5，这就是一个当前比较主流的一种推荐技术架构，其核心思路是围绕初始海量候选集不断缩小的方向进行分层处理，并且在这个过程中去解决推荐中需要解决的一些问题，例如商业逻辑、用户体验逻辑等等。

从2.2.4.4到2.2.4.5最大的改动点在于以前单层的处理逻辑变成了分阶段的处理逻辑，当然这种变化过程不是一蹴而就的，可能依然经过了多个小阶段的发展和迭代。但核心逻辑都是数据量的暴涨，使得过往的那种直接做实时预测的方案行不通，因此分阶段核心的逻辑就是拆分阶段之后不同的阶段解决不同的问题，但最终目标是从海量的候选集中如何最高效且最精准的把待推荐的ITEM给找出来了。

第一个阶段是召回，召回需要解决的是如何快速且体系化的从百、千万级的候选数据集中快速召回一批可用于做下一步推荐精选的候选集出来。

通常如果这块逻辑进一步细化的话，会以多路召回的方式进行，例如通过近实时计算短期用户兴趣点，通过兴趣点做索引的检索召回，以及通过用户的稳定长期兴趣做标签检索召回。

通过用户当前正在浏览的内容做相似内容召回，即我们上面所提到的相似内容推荐，在这里只是把它当成一种初始候选集的召回方式而已。或者基于离线协同计算好的结果，基于KNN近邻检索等工程实现方式，如FaceBook开源的Faiss等大规模向量检索工具等，实现协同计算的相近ITEM召回。

除此之外，还可以做热点ITEM召回，或者纯粹新进入候选池的ITEM召回等。

我们可以看到，这里召回的逻辑中从工程技术实现的角度上看，要么是使用了标签这种直接可以通过倒排检索进行大规模快速检索的方式，要么是向量近邻检索等方式，从工程技术上追求的是如何从百万级千万级的数据集中高效的查找数据。

并且，从多路的逻辑中，例如短期兴趣、长期兴趣、协同相似、内容相似、热点内容，新内容等，包含了各个逻辑和维度，本身就是解决推荐多样性的一种策略。至于多样性的持续讨论，我们将会在后续章节中有所涉及，这里更多讨论的是技术和工程逻辑。

第二个阶段是粗排。其实在过度阶段的技术架构中，很多时候会省略掉粗排这一层，直接将召回的候选进入到在线精排预估中去。随着技术和算法模型的迭代，以及数据量的持续保障，导致了追求性能和兼顾预估效果的粗排阶段出现。

粗排阶段基本上不太可能上正式的在线推理逻辑，因为其候选的作用在于将候选集如何从十万量级缩减几百一千，那么必然对于性能的要求就很高。因此，在实现技术逻辑上大多还是偏向于离线检索的方式，因此DSSM这种兼顾了目标预估训练以及通过检索提升性能的逻辑就非常适用于这个阶段。

由于模型是经过了充分的训练的，所以其预估的目标与精排是保持一致的，但是通过获取到user embedding向量与item embedding向量计算内积的方式，或者进行向量查找的方式，都能比较高效的解决性能问题。

关于更多的DSSM相关的内容，我们在后续广告的算法应用相关章节中，会详细的介绍，这里就不过多展开讨论。

第三个阶段是精排。这个阶段输入的需要排序的候选集相对较少，需要实时的将候选输入过我们的预估模型，例如当前主流的深度网络模型，然后输出预估结果，最终给数百或者上千的候选结果排序，然后取TopN输出到下个阶段里。

从工程技术的角度上看，本质上就是模型的在线加载，然后进行在线预估。但在实际实施中还需要考虑离线模型如何更新，在线的模型如何小时间颗粒度的增量训练，甚至如何结合离线的复杂网络，然后通过蒸馏等方式精简网络之后加载到在线，从而提升在线实时预估的性能等等。

除此之外，精排逻辑为了进一步追求性能，还可以从技术的语言选型上进行考虑，如使用性能更好的C++等做服务构建。

最后一个阶段是重排。重排这里更多考虑的是商业逻辑，例如针对商家需要重点扶持的类目做加权，一些体验上的优化考虑做排序的微调整等。在技术工程上倒没有过多的难点，更多的是商业策略在里头。

剩下就是数据的闭环，包括离线数据和实时数据的打通，其中实时数据中需要考虑的是实时特征的构建，实时数据用于做模型的增量训练，实时数据用于实时的召回策略等等。

整个架构图中，还差一个逻辑没有补充上去，即推荐系统中比较重要的在线实验系统，从技术实现的逻辑上，即将用户进行分流标记。举个例子，如精排阶段，同时支持若干个模型在线，然后控制不同的流量，即用户接受不同版本模型的结果，最终在输出结果获得用户的实际反馈之后，按版本标记信息做效果回收，从而实现在线的流量切割，和效果对比。

综上整个架构的演进和迭代，可以看到演进的过程是有一定规律的，演进的核心驱动力在于业务所处的阶段，要解决什么问题，数据如何一步步精选。而我们在实际推进自身推荐系统落地时，同样需要考虑当前业务是否需要最完善的方案，还是说结合实际情况一步步迭代。

总之，从技术架构的角度上说，没有最完美的技术架构，只有最合适的，选择对于当前业务阶段来说最合适的技术架构，就是最好的技术架构。

参考文献

【01】参考内容来自《计算广告与算法：商业化本质和数据的价值》初稿，推荐系统架构简单介绍章节节选。

文章都看完了，还不点个赞来个赏~

作为一个成熟的非典型程序猿，怎么能不对外部世界保持关注呢，欢迎关注笔者的另一个公众号【夏虫悟冰】，以非技术的视野观测这个世界，成长自己。