FAISS之所以能够用于推荐系统提供实时推荐服务，主要是因为很多推荐算法最终将用户和标的物都表示为向量，通过用户向量与标的物向量的内积来衡量用户对标的物的偏好程度，典型的矩阵分解算法就是这种形式 。FAISS所起的作用相当于图7中的推荐模型服务，利用它进行推荐的web服务架构就是图7这种架构 。最终的推荐模型用数学公式表示就是
文章插图
文章插图
是内积计算，u、v分别是用户和标的物标向量，它们之间的内积表示用户对标的物的偏好程度 。FAISS提供计算用户最相似的标的物的能力，并基于该相似度降序排列，取TopN最相似的标的物作为最终的推荐结果 。
五、两种web服务方式的优劣对比前面两节已经对推荐系统两种提供web服务方案的技术细节进行了详细介绍，在真实业务场景中可能比这个更复杂，可能不是单纯的某种方案，会有一些变体，在这两种方案的基础上做适当调整与变化，可能同一产品的不同推荐形态采用不同的方式，同一种推荐方案也可能会融合这两种方式 。
在这一节我们对比一下这两个方案的优缺点，让大家更好地理解这两种web服务方案，同时也为大家在具体推荐业务中进行选择提供参考 。
1.事先计算型web服务的优缺点
事先计算型最大的优势是提前将推荐结果准备好了，这样在提供推荐服务时可以直接获取推荐结果，因此大大提升了接口服务的响应速度，减少了响应时间，对用户体验是有极大帮助的 。另外，事先计算好了，当模型出现问题(比如调度模型计算的服务挂了)，最坏的情况是不更新推荐结果(这时无法插入最新推荐结果)，用户访问时还是可以获得推荐的，只不过给用户的是过去一天的推荐结果 。如果是实时计算推荐结果(实时装配型)，当模型出现问题时就无法获得推荐结果，如果接口没做保护，这时接口可能会挂掉，导致前端出现无法展示任何推荐结果的故障，出现开天窗现象(不过好的推荐系统web服务一般会增加保护，在这种极端情况下，给定一组默认数据作为推荐结果，默认推荐是提前缓存在前端的，不受短期网络故障影响)，因此，有更好的鲁棒性 。
事先计算型另一个优点是架构更加简单，web接口服务跟生成推荐过程解耦，可以分别对web接口和推荐结果计算优化升级，而不会互相影响 。
事先计算型最大的缺点是，由于要事先为每个用户生成推荐，实际上很多用户不是每天都访问的，真正日活用户占总活跃用户(比如月活用户)的比例是很低的(当然像微信这类国民级App除外)，推荐模块访问用户数一般也远小于当天日活数，这就浪费了很多计算和存储资源，特别是有海量用户的APP，这时有大量的用户没有登录反而需要每天为其计算推荐结果，这时浪费是非常明显的 。
事先计算型另外一个缺点是，事先计算好了，这就失去了灵活性，要调整修改用户的推荐结果成本代价更高(信息流推荐等实时推荐产品是需要对推荐结果进行近实时调整的) 。就像前面的案例讲的，套餐做好了，没法满足用户特定的口味了，比如用户想要重辣，那也没办法了 。
2.实时装配型web服务的优缺点
实时装配型跟事先计算型基本是对称的，事先计算型的优点是它的缺点，事先计算型的缺点反而是它的优点 。
实时装配型需要临时为用户生成推荐结果，因此web接口服务需要多做一步处理，对接口性能有一定负面影响 。另外，当推荐模型需要升级调整或者模型服务出现问题时(实时装配型另一种实现方案是推荐模型作为一个独立web服务)，会有短暂时间的不可用，这时会导致推荐web接口无法计算出推荐结果，进而无法给前端提供反馈信息 。这两种情况都会影响用户体验(当然做得好的系统会有热更新，模型升级不会导致无法响应的情况出现，TensorFlow Serving就具备这种能力) 。
实时装备型的架构也更加复杂，耦合度更高(在推荐web接口整合了推荐模型这种实时装配型中，推荐web接口跟推荐结果计算是完全耦合在一起的，参见图6) 。
实时装配型由于是实时为用户计算推荐结果，因此相比事先计算型不会占用太多的存储、计算资源，对于节省费用是有极大帮助的，特别是在海量用户场景下，这种节省更加明显 。它的另一个优点是对推荐结果调整空间大，因为是临时计算，可以在计算过程中增加一些场景化的处理逻辑，对推荐算法有更好的干预能力，更加适合实时推荐场景 。
推荐阅读
- 3000元价位的智能电视推荐，能选择的产品太多了
- 推荐几款前端开发编辑器
- 熬夜|张雨绮鲨疯了！晒健身美照细腿腹肌超吸睛，曾推荐吃肉减肥
- 补肾五宝茶配方和比例,五宝茶推荐牌子
- 护肤品|30天让你变美的好用护肤品推荐 真正有效的护肤品排行榜前十名
- 让Android更安全 谷歌推荐开发者使用Rust编写系统代码
- 冬季里最耐寒的15种花卉,推荐几种耐寒的室内常绿花卉
- 比较大众的韩国化妆品牌推荐
- 生命的存在对于氧气和二氧化碳是极为重要的 地球的氧气主要由什么提供
- 女生书龄十年良心推荐,好良心是柔和的枕头