上面介绍完了这两种方案的优缺点，我们用一个表格整理一下，方便对比查看它们之间的异同点 。
文章插图
六、影响web服务方案的因素及选择原则在上一节中，我们对两种推荐web方案的优缺点进行了对比介绍，每种方案都有各自的优缺点，没有哪一个方案是完全胜于另一个方案的 。那么在实际业务落地时，有哪些因素是会影响我们选择具体的方案呢？我们应该怎样选择？有什么判断依据和准则吗？在这一节中我们试图从多个角度来回答这些问题 。
1.推荐产品形态的实效性对推荐web服务选择的影响
如果推荐产品形态是T+1型推荐，由于每天只更新一次推荐结果，可以选择事先计算型先将推荐结果计算出来 。如果产品形态是实时信息流推荐，需要整合用户的实时兴趣变化，用户的每一次行为都会触发更新推荐结果，这时采用临时装配型是更好的选择 。当然这也不是绝对的，作者所在公司的短视频信息流推荐，就采用的事先计算型，事先计算型也可以做到近实时更新用户推荐结果，前面已经提到，对实现细节感兴趣的读者可以参考《基于标签的实时短视频推荐系统》这篇文章 。
2.团队架构能力、工程实现能力对推荐web服务选择的影响
【推荐系统提供web服务的2种方式】实时装配型架构相对复杂，耦合度相对更高，在推荐时需要处理的逻辑更多，因此各个子模块都需要相当稳定，并且需要具备较高的性能，因此对整个推荐软件系统的要求更高 。因此，如果推荐团队架构能力强，人力比较充足的情况下可以选择实时装配型方案 。
为了更好地整合用户的实时行为，为用户提供可见即所得的推荐服务，很多信息流推荐需要对推荐算法进行实时训练，比如Google在2013年推广的FTRL算法就是对logistic在实时推荐场景下的工程实现，具备更高的工程实现难度，因此，对推荐团队的工程实现能力是有较高要求的 。实时装配型一般需要处理用户的实时行为日志，用于挖掘用户实时兴趣，构建实时模型，这就要求整个系统有更高的实时性，需要一套完善的实时处理架构体系的支撑，这也增加了构建这类系统的复杂性 。
前面也提到实时计算型一般需要有一套类似FAISS这样的实时匹配库，为用户在极短的时间内搜寻到最喜欢的标的物 。而搭建这样一套系统，需要将推荐模型做成独立的服务，并且保证推荐模型web服务具备稳定性、高并发能力、可拓展性等能力，这也对架构能力有极高要求 。如果希望采用容器等新技术来更好地管理推荐模型服务，这也需要新的学习成本和运维成本 。
3.推荐阶段对推荐web服务选择的影响
我们知道企业级推荐系统生成推荐结果的过程一般分为召回和排序两个阶段(参考《推荐系统产品与算法概述》这篇文章第一节的介绍)，先使用召回推荐算法从海量标的物中筛选出一组(一般几百上千个)用户可能感兴趣的标的物，然后在排序阶段利用更加精细化的推荐算法对结果进行重排序 。
由于召回是从所有标的物中筛选用户可能感兴趣的，当标的物数量庞大时(比如今日头条有千亿级文本、淘宝有上亿级商品)，即使召回算法简单，计算量也是非常大的，一般可以采用事先计算型召回策略(为了整合用户最近的行为，也可以基于用户的兴趣标签或者用户最近浏览的标的物进行近实时召回，这类召回策略也属于事先计算型，比如根据用户最近浏览的标的物召回相似的标的物，每个标的物相似标的物是事先计算好的) 。而对于排序推荐算法，只需要从有限的(成百上千)的标的物中过滤出用户最喜欢的几十个，可以在较短时间内计算完，因此排序算法可以采用实时装配型策略 。
当然，排序阶段也是可以采用事先计算型的，这就相当于先召回，再排序将推荐结果计算好，只不过整个推荐过程将事先计算拆解为召回和排序两个阶段来进行了 。
其实，直接跟推荐接口衔接的是排序阶段，召回阶段是不直接参与web服务的，因此根据第二节的定义，严格意义上事先计算型、实时装配型是不能用于描述召回阶段的 。不过有些产品的标的物数量不大(比如电影只有几万个)，也可以将召回排序融合为一个阶段，只用一个算法就可以获得推荐结果，或者排序可以采用简单的规则和策略，这时排序逻辑可以整合到推荐web接口中，这两种情况召回阶段所起的作用就相当于排序阶段的作用了，这时可以说召回直接跟web接口进行了交互，因此也可以用事先计算型、实时装配型来描述召回阶段 。
推荐阅读
- 3000元价位的智能电视推荐，能选择的产品太多了
- 推荐几款前端开发编辑器
- 熬夜|张雨绮鲨疯了！晒健身美照细腿腹肌超吸睛，曾推荐吃肉减肥
- 补肾五宝茶配方和比例,五宝茶推荐牌子
- 护肤品|30天让你变美的好用护肤品推荐 真正有效的护肤品排行榜前十名
- 让Android更安全 谷歌推荐开发者使用Rust编写系统代码
- 冬季里最耐寒的15种花卉,推荐几种耐寒的室内常绿花卉
- 比较大众的韩国化妆品牌推荐
- 生命的存在对于氧气和二氧化碳是极为重要的 地球的氧气主要由什么提供
- 女生书龄十年良心推荐,好良心是柔和的枕头