推荐系统提供 web 服务的 2 种方式 (二十四)

写在前面：

大家好，我是强哥，一个热爱分享的技术狂。目前已有 12 年大数据与 AI 相关项目经验， 10 年推荐系统研究及实践经验。平时喜欢读书、暴走和写作。

业余时间专注于输出大数据、AI 等相关文章，目前已经输出了 40 万字的推荐系统系列精品文章，今年 6 月底会出版「构建企业级推荐系统：算法、工程实现与案例分析」一书。如果这些文章能够帮助你快速入门，实现职场升职加薪，我将不胜欢喜。

想要获得更多免费学习资料或内推信息，一定要看到文章最后喔。

内推信息

如果你正在看相关的招聘信息，请加我微信：liuq4360，我这里有很多内推资源等着你，欢迎投递简历。

免费学习资料

如果你想获得更多免费的学习资料，请关注同名公众号【数据与智能】，输入“资料”即可！

学习交流群

如果你想找到组织，和大家一起学习成长，交流经验，也可以加入我们的学习成长群。群里有老司机带你飞，另有小哥哥、小姐姐等你来勾搭！加小姐姐微信：epsila，她会带你入群。

推荐系统是一种信息过滤技术，通过从用户行为中挖掘用户兴趣偏好，为用户提供个性化的信息，减少用户的找寻时间，降低用户的决策成本，让用户更加被动地消费信息。推荐系统是伴随着互联网技术的发展及应用深入而出现的，并在当前得到广泛的关注，它是一种软件解决方案，是 toC 互联网产品上的一个模块。用户通过与推荐模块交互，推荐系统通过提供的 web 服务，将与用户兴趣匹配的标的物筛选出来，组装成合适的数据结构，最终展示给用户。推荐系统 web 服务是前端和后端沟通的桥梁，是推荐结果传输的最后通道。信息传输是否通畅，传输是否足够快速，对用户体验是有极大影响的。本章我们就来讲解推荐系统提供 web 服务的两种主要方式，这两种方式是企业级推荐系统最常采用的两种形式。

具体来说，本章我们会从什么是推荐系统 web 服务、推荐系统提供 web 服务的 2 种方式、事先计算型 web 服务、实时装配型 web 服务、两种 web 服务方式的优劣对比、影响 web 服务方案的因素及选择原则等 6 个部分来讲解。通过本章的介绍，期望读者可以深刻理解这 2 种 web 服务方式的具体实现方案以及它们之间的差别，并具备结合具体的业务场景来决策采用哪种方式的能力。

21.1 什么是推荐系统 web 服务

作者在第《构建优质的推荐系统服务》中已经对推荐系统 web 服务进行了简单介绍，这里为了让读者更好地理解本文的知识点，以及为了内容的完整性，对推荐系统 web 服务进行简略介绍。

用户与推荐系统交互的服务流程见下面图 1，用户在使用产品过程中与推荐模块(产品上提供推荐能力的功能点)交互，前端(手机、PC、Pad、智能电视等)请求推荐 web 服务，推荐 web 服务获取该用户的推荐结果，将推荐结果返回给前端，前端通过适当的渲染将最终的推荐结果按照一定的样式和排列规则在产品上展示出来，这时用户就可以看到推荐系统给他的推荐结果了。

图 1：用户通过推荐 web 服务获取推荐结果的数据交互流程

上图中的绿色虚线框中的数据交互能力就是推荐 web 服务的范畴，它是前端(也叫终端)与后端的互动。图中蓝色方块(推荐 web 服务模块)是部署在服务器上的一类软件服务，它提供 HTTP 接口，让前端可以实时与之交互。用户与终端的交互属于视觉及交互设计范畴，虽然与推荐 web 服务无直接关系，但是是整个推荐服务能力完整实现必不可少的一环，也是用户可以肉眼直接感知到的部分，在整个推荐系统中非常重要，对推荐系统发挥价值有极大影响，不过不在本章的讨论范围内，我们会在第 24 章《推荐系统的 UI 交互与视觉展示》详细讲解这方面的知识点。

为了给前端提供个性化推荐服务，上图中的推荐 web 服务模块需要完成 3 件事情。首先需要获得该用户的推荐结果(直接获得已经计算好的推荐结果，这就是 21.3 节要讲的，或者通过临时计算获得推荐结果，这就是第 21.4 节要讲的)，其次是将结果组装成前端最终需要的数据结构(第一步获得的推荐结果一般是标的物 id 的列表，实际展示给前端还需要标的物的各种 metadata 信息，如名称，价格，海报图等，这些信息的组装就是在这一步完成的，这些信息一般会存放到关系型数据库中，或者采用 json 的形式存放到 Redis、文档型 NoSQL 中，所以这里至少还有一次额外的数据库访问)，最后是响应前端的 HTTP 请求(一般是 GET 请求)，将最终推荐结果返回给前端。本文我们讲解的推荐系统提供 web 服务的两种方式，就是这里讲的第一件事情，即推荐 web 服务怎么获得给用户的推荐结果。

推荐 web 服务模块是最终为用户提供推荐能力的部分，它设计得好不好直接影响用户体验，一般来说，该模块需要满足稳定、响应及时、容错、可以随着用户规模线性扩容等多个条件，具体什么是优质的推荐服务，我们在第 20 章《构建优质的推荐系统服务》已经做过深入讲解。这里提一下，随着 Docker 等容器技术及 kubernetes 等容器管理软件的发展和成熟，推荐 web 服务中的各个子模块都可以分别部署在容器中，采用微服务的方式进行数据交互，这样就可以高效管理这些服务，更好地进行服务的监控、错误恢复、线性扩容等。

上图只是一种简化的交互模型，在实际企业级服务中，往往比这个更加复杂，在前端和后端之间往往存在一层 CDN 层做缓存加速，以减轻前端服务对后端并发访问的压力(在用户量大的情况下，推荐系统属于高并发服务)，并且一般推荐 web 服务中还存在一层 Nginx 代理层，通过 Nginx 代理，让推荐 web 服务可以水平扩容，以满足推荐系统高并发的要求。下面图 2 就是一种可行的完整推荐系统服务方案。

图 2：完整的推荐系统业务架构图

如前面所讲，虽然推荐 web 服务包含前端与后端的交互，前端与后端一般还会有 CDN 层和 Nginx 代理层，但本文我们着重关注的是后端真正提供 Web 服务接口模块及数据存储模块的实现方案，也即上图中红色模块怎么获取推荐结果的架构实现方案。该模块的实现方案可以多样，主流的实现方式有两种，我们在下面分三节来进行介绍。

21.2 推荐系统提供 web 服务的两种方式

推荐系统提供 web 服务一般有两种方式，一种是事先计算型，另一种是实时装配型。在具体介绍之前，这里我先举一个比较形象的例子，让大家更好地理解这两种实现方式。

假设我们开了一家餐厅专门送外卖，餐厅提供 10 种不同的备选套餐。在午市或者晚市叫餐高峰时段，餐厅可以采用如下两种方案来准备套餐：第一种方案是事先将这 10 种套餐每种都做若干份，当有客户叫外卖时，将该客户叫的这个套餐(已经做好了)直接送出去；第二种方式是将这 10 种套餐需要的原材料都准备好，部分材料做成半成品(比如比较花时间的肉类)，当有用户叫餐时，将该套餐需要的原材料下锅快速做好再送出去。

通过上面非常简化的案例介绍，大家应该不难理解，上面提到的第一种准备套餐的方式就是“事先计算型”，事先将套餐做好，而第二种方式就是“实时装配型”，当用户叫餐时，临时做并快速做好。

现在让我们回到推荐 web 服务上，来介绍两种推荐 web 服务方案。事先计算型就是将用户的推荐结果事先计算好，放到数据库中存放起来，当该用户在使用产品过程中访问推荐模块时，推荐 web 服务模块直接将该用户计算好的推荐结果取出来，进行适当加工(比如过滤掉用户已经看过的视频)，将最终推荐结果展示给用户。实时装配型是将计算推荐结果需要的数据(一般是各种特征)提前准备好，当用户访问推荐模块时，推荐 web 服务通过简单的计算和组装(利用前面准备好的各种特征灌入推荐模型)，生成该用户的推荐结果，再将推荐结果返回给前端并展示给用户。

理解了这两种不同的 web 服务方式的基本原理，我们在接下来的两节中分别对它们的实现细节进行详细介绍，让读者更好地理解它们的特性及技术实现细节。

21.3 事先计算型 web 服务

这一节我们来讲解推荐系统事先计算型 web 服务的架构实现与基本原理(参见下面图 3)。这种方式可能是业界比较多地采用的一种推荐 web 服务架构实现方式，作者公司的所有推荐服务基本都是采用的该模式。

图 3：事先计算型 web 服务架构(绿色虚线框中的模块即是图 2 中的红色模块的细化)

该模式最大的特点是事先将每个用户的推荐结果计算出来，存到数据库中(一般是 NoSQL，如 Redis、CouchBase 等 NoSQL 数据库，采用 key-value 的方式存储，key 就是用户 id，value 就是给用户的推荐结果，如果是用 Redis 存，value 的数据结构可以使 Sorted Sets，这种数据结构比较适合推荐系统，Sorted Sets 中的 element 可以是推荐的标的物 id，score 是标的物的预测评分或者预测概率值等，还可以根据 Sorted Sets 中的 score 进行分页筛选等操作)，当有用户请求时，前端访问 web 接口服务器(前端会带上用户的唯一识别 id 进行 HTTP 请求，这样就知道是哪个用户，方便找到该用户的推荐结果)，web 服务器从推荐结果库中获取该用户的推荐结果(推荐结果一般只存储给用户推荐的标的物 id 列表及部分需要的其他信息，比如算法标识，方便后面做 AB 测试，下面图 4 就是一种推荐结果存储的数据格式，其中 id 就是标的物的唯一识别 id)，同时还需要访问标的物 metadata 数据库(一般存放在关系型数据库中)，将前端展示需要的其他信息(如标的物的名称、价格、缩略图等)拼接完整，最终以 json 的形式(下面图 5 就是视频推荐系统最终拼接好的 json 格式，互联网企业一般采用的数据交互协议，也可以是其他协议，Google 内部就采用 protobuf 协议)返回给前端展示给用户。

图 4：推荐结果存储的数据结构(json 形式存储)

图 5：最终返回给用户的推荐结果(json 格式)

该架构既可以支持 T+1 推荐模式和实时推荐模式，对于 T+1 型推荐产品形态，每天为用户生成一次推荐结果，生成推荐结果时直接替换昨天的推荐结果就可以了。而对于实时推荐，情况会复杂一些，实时推荐可能会调整用户的推荐结果(而不是完全替换)，对用户推荐结果进行增删形成新的推荐结果，这时可行的方法有两个：一是从推荐结果存储数据库中读出该用户的推荐结果，按照实时推荐算法逻辑对推荐结果进行修改，再将推荐结果存进去替换掉；另外一种做法是，增加一个中间的镜像存储(可以采用 HBase 等，现在业界很多推荐算法都基于 Hadoop/Spark 平台实现，用大数据生态系的 HBase 是比较好的选择)，所有的算法逻辑修改只对镜像存储进行操作，操作完成后，将镜像存储中修改后的推荐结果同步到最终的推荐库中，这跟 T+1 更新就保持一致了，只不过现在是实时推荐，同一个用户可能一天会更新多次推荐结果。作者公司的短视频实时推荐更新就是采用后面的这种方案，我们会在第 28 章《基于标签的实时短视频推荐系统》28.3.1 节进行详细介绍。

21.4 实时装配型 web 服务

本节我们来讲解实时装配型 web 服务的实现原理与架构(参考下面图 6)。这种方式事先不计算用户的推荐结果，当有用户请求时，web 接口服务器从特征数据库(一般也是存放在 Redis、HBase 这种非关系型数据库中)中将该用户需要的特征取出来，并将特征灌入推荐模型，获得该用户的推荐结果，跟事先计算型一样，还需要加载推荐标的物的 metadata 信息，拼接成完整的推荐结果，并返回给前端展示给用户。

图 6：实时装配型 web 服务架构(web 接口服务加载推荐模型)

该 web 服务架构需要将推荐模型加载到 web 接口服务中，可以实时基于用户特征获得推荐结果，这就要求推荐模型可以在极短的时间(毫秒级)内获得推荐结果，计算一定要快，否则会影响用户体验。当然另外一种可行的方案是，将推荐模型做成独立的 web 模型服务，web 接口服务通过 HTTP 或者 RPC 访问模型服务获得推荐结果。具体架构如下面图 7，这种方式的好处是推荐模型服务跟 web 服务解耦，可以分别独立升级模型服务和推荐接口服务，互相之间不会影响，只要保证它们之间数据交互的协议不变就可以了。

图 7：通过推荐模型服务来获取推荐结果的实时装配型 web 服务架构

实时装配型架构在实际提供推荐服务时就与具体的推荐范式是 T+1 推荐还是实时推荐没有关系了，因为在任何时候 web 接口服务都是临时调用推荐模型为用户生成推荐结果，只不过 T+1 推荐的模型可以一天训练一次，而实时推荐的模型是实时训练的(用户的每一次操作行为都会产生日志，通过实时日志处理，生成实时特征，灌入实时模型训练流程中，最终完成对模型的实时训练，让模型实时得到更新)。

业界流行的 TensorFlow Serving 就是一种实时装配型服务架构，它提供 web 服务的架构模式类似上面图 6 的形式，下面对其进行简单介绍，让读者更好地理解这种模式。读者可以查看参考资料 1、2、3 对 TensorFlow Serving 进行更深入的了解。

TensorFlow Serving 是一个灵活的、高性能的机器学习模型在线服务框架，设计用于生产系统，可以与训练好的 TensorFlow 模型高效整合，将训练好的模型部署到线上，使用 gRPC 作为接口接受外部调用。TensorFlow Serving 支持模型热更新与自动模型版本管理。

下图为 TensorFlow Serving 整个框架图。Client 端会不断给 Manager 发送请求，Manager 会根据版本管理策略管理模型更新，并将最新的模型计算结果返回给 Client 端。

图 8：TensorFlow Serving 架构，图片来源于 TensorFlow Serving 官方文档

FaceBook 开源的 FAISS(见参考资料 4)框架也是业界用的比较多的一款用于实时装配型 web 服务的框架。FAISS 包含几种相似性搜索方法，它假设用户或者标的物被表示为向量并由整数标识(用户和标的物用整数来唯一标识，即用户 id 和标的物 id)，可以在海量向量库中搜索出按照某种相似性计算的最相似的向量列表。FAISS 提供了向量之间计算 L2(欧几里德)距离或内积距离的方法，与查询向量最相似的向量是那些与查询向量具有最小 L2 距离或最大内积的向量。FAISS 具备在极短的时间(毫秒级)内计算某个向量最相似的一组向量的能力。它还支持 cosine 余弦相似性查询，因为 cosine 余弦只不过是向量内积的归一化。

FAISS 之所以能够用于推荐系统提供实时推荐服务，主要是因为很多推荐算法最终将用户和标的物都表示为向量，通过用户向量与标的物向量的内积来衡量用户对标的物的偏好程度，典型的矩阵分解算法就是这种形式。FAISS 所起的作用相当于图 7 中的推荐模型服务，利用它进行推荐的 web 服务架构就是图 7 这种架构。最终的推荐模型用数学公式表示就是

，

 是内积计算，u、v 分别是用户和标的物标向量，它们之间的内积表示用户对标的物的偏好程度。FAISS 提供计算用户最相似的标的物的能力，并基于该相似度降序排列，取 TopN 最相似的标的物作为最终的推荐结果。

21.5 两种 web 服务方式的优劣对比

前面两节已经对两种推荐系统提供 web 服务的方案的技术细节进行了详细介绍，在真实业务场景中可能比这个更复杂，可能不是单纯的某种方案，会有一些变体，在这两种方案的基础上做适当调整与变化，可能同一产品的不同推荐形态采用不同的方式，同一种推荐方案也可能会融合这两种方式。

在这一节我们对比一下这两个方案的优缺点，让读者更好地理解这两种 web 服务方案，同时也为读者在具体推荐业务场景中进行选择提供参考。

21.5.1 事先计算型 web 服务的优缺点

事先计算型最大的优势是提前将推荐结果准备好了，这样在提供推荐服务时可以直接获取推荐结果，因此大大提升了接口服务的响应速度，减少了响应时间，对用户体验是有极大帮助的。另外，事先计算好了，当模型推断出现问题(比如调度模型推断的计算服务挂了)，最坏的情况是不更新推荐结果(这时无法插入最新推荐结果)，用户访问时还是可以获得推荐的，只不过给用户的是过去一天的推荐结果。如果是实时计算推荐结果(实时装配型)，当模型出现问题时就无法获得推荐结果，如果接口没做很好的保护，这时接口可能会挂掉，导致前端出现无法展示任何推荐结果的故障，出现开天窗现象(不过好的推荐系统 web 服务一般会增加保护，在这种极端情况下，给定一组默认数据作为推荐结果，默认推荐是提前缓存在前端的，不受短期网络故障影响)，因此，有更好的鲁棒性。

事先计算型另一个优点是架构更加简单，web 接口服务跟生成推荐过程解耦，可以分别对 web 接口和推荐结果计算优化升级，而不会互相影响。

事先计算型最大的缺点是，由于要事先为每个用户生成推荐，实际上很多用户不是每天都访问的，真正日活用户占总活跃用户(比如月活用户)的比例是很低的(当然像微信这类国民级 APP 除外)，推荐模块访问用户数一般也远小于当天日活数，这就浪费了很多计算和存储资源，特别是有海量用户的 APP，这时有大量的用户没有登录反而需要每天为其计算推荐结果，这时浪费是非常明显的。

事先计算型另外一个缺点是，事先计算好了，这就失去了灵活性，要调整修改用户的推荐结果成本代价更高(信息流推荐等实时推荐产品是需要对推荐结果进行近实时调整)。就像前面的案例讲的，套餐做好了，没法满足用户特定的口味了，比如用户想要重辣，那也没办法了。

21.5.2 实时装配型 web 服务的优缺点

实时装配型跟事先计算型基本是对称的，事先计算型的优点是它的缺点，事先计算型的缺点反而是它的优点。

实时装配型需要临时为用户生成推荐结果，因此 web 接口服务需要多做一步处理，对接口性能有一定负面影响。另外，当推荐模型需要升级调整或者模型服务出现问题时(实时装配型另一种实现方案是推荐模型作为一个独立 web 服务)，会有短暂时间的不可用，这时会导致推荐 web 接口无法计算出推荐结果，进而无法给前端提供反馈信息。这两种情况都会影响用户体验(当然做得好的系统会有模型热更新，模型升级不会导致无法响应的情况出现，TensorFlow Serving 就具备这种能力)。

实时装备型的架构也更加复杂，耦合度更高(在推荐 web 接口整合了推荐模型这种实时装配型中，推荐 web 接口跟推荐结果计算是完全耦合在一起的，参见图 6)。

实时装配型由于是实时为用户计算推荐结果，因此相比事先计算型不会占用太多的存储、计算资源，对于节省费用是有极大帮助的，特别是在海量用户场景下，这种节省更加明显。它的另一个优点是对推荐结果调整空间大，因为是临时计算，可以在计算过程中增加一些场景化的处理逻辑，对推荐算法有更好的干预能力，更加适合实时推荐场景。

上面介绍完了这两种方案的优缺点，我们用一个表格整理一下，方便对比查看它们之间的异同点。

表 1：事先计算型和实时装配型的优缺点对比

21.6 影响 web 服务方案的因素及选择原则

在上一节中，我们对两种推荐 web 服务方案的优缺点进行了对比介绍，每种方案都有各自的优缺点，没有哪一个方案是完全胜于另一个方案的。那么在实际业务落地时，有哪些因素是会影响我们选择具体的方案呢？我们应该怎样选择？有什么判断依据和准则吗？在这一节中我们试图从多个角度来回答这些问题。

21.6.1 推荐产品形态的时效性对推荐 web 服务选择的影响

如果推荐产品形态是 T+1 型推荐，由于每天只更新一次推荐结果，可以选择事先计算型先将推荐结果计算出来。如果产品形态是实时信息流推荐，需要整合用户的实时兴趣变化，用户的每一次行为都会触发更新推荐结果，这时采用临时装配型是更好的选择。当然这也不是绝对的，作者公司的短视频信息流推荐，就采用的事先计算型，事先计算型也可以做到近实时更新用户推荐结果，前面已经提到，我们会在第 28 章《基于标签的实时短视频推荐系统》对算法原理进行详细介绍。

21.6.2 推荐团队架构能力、工程实现能力对推荐 web 服务选择的影响

实时装配型架构相对复杂，耦合度相对更高，在推荐时需要处理的逻辑更多，因此各个子模块都需要相当稳定，并且需要具备较高的性能，因此对整个推荐软件系统的要求更高。因此，如果推荐团队架构能力强，人力比较充足的情况下可以选择实时装配型方案。

为了更好地整合用户的实时行为，为用户提供可见即所得的推荐服务，很多信息流推荐需要对推荐算法进行实时训练，比如 Google 在 2013 年推广的 FTRL 算法就是对 logistic 在实时推荐场景下的工程实现，具备更高的工程实现难度，因此，对推荐团队的工程实现能力是有较高要求的。实时装配型一般需要处理用户的实时行为日志，用于挖掘用户实时兴趣，构建实时模型，这就要求整个系统有更高的实时性，需要一套完善的实时处理架构体系的支撑， 这也增加了构建这类系统的复杂性。

前面也提到实时计算型一般需要有一套类似 FAISS 这样的实时匹配库，为用户在极短的时间内搜寻到最喜欢的标的物。而搭建这样一套系统，需要将推荐模型做成独立的服务，并且保证推荐模型 web 服务具备稳定性、高并发、可拓展性等能力，这也对架构能力有极高要求。如果希望采用容器等新技术来更好地管理推荐模型服务，这也需要新的学习成本和运维成本。

21.6.3 推荐阶段对推荐 web 服务选择的影响

我们知道企业级推荐系统生成推荐结果的过程一般分为召回、排序两个个阶段(其实还包括业务调控，业务调控更多的是运营和策略性的调整，不属于狭义的算法范畴，参考第 4 章《推荐算法概述》4.2 节的介绍)，先使用召回推荐算法从海量标的物中筛选出一组(一般几百上千个)用户可能感兴趣的标的物，然后在排序阶段利用更加精细化的推荐算法对结果进行重排序。

由于召回是从所有标的物中筛选用户可能感兴趣的，当标的物数量庞大时(比如今日头条有千亿级文本、淘宝有上亿级商品)，即使召回算法简单，计算量也是非常大的，一般可以采用事先计算型召回策略(为了整合用户最近的行为，也可以基于用户的兴趣标签或者用户最近浏览的标的物进行近实时召回，这类召回策略也属于事先计算型，比如根据用户最近浏览的标的物召回相似的标的物，每个标的物相似标的物是事先计算好的)。而对于排序推荐算法，只需要从有限的(成百上千)的标的物中过滤出用户最喜欢的几十个，可以在较短时间内计算完，因此排序算法可以采用实时装配型策略。

当然，排序阶段也是可以采用事先计算型的，这就相当于先召回，再排序将推荐结果计算好，只不过整个推荐过程将事先计算拆解为召回和排序两个阶段来进行了。

其实，直接跟推荐接口衔接的是排序阶段，召回阶段是不直接参与 web 服务的，因此根据第二节的定义，严格意义上事先计算型、实时装配型是不能用于描述召回阶段的。不过有些产品的标的物数量不大(比如电影只有几万个)，也可以将召回排序融合为一个阶段，只用一个算法就可以获得推荐结果，或者排序可以采用简单的规则和策略，这时排序逻辑可以整合到推荐 web 接口中，这两种情况召回阶段所起的作用就相当于排序阶段的作用了，这时可以说召回直接跟 web 接口进行了交互，因此也可以用事先计算型、实时装配型来描述召回阶段。

21.6.4 算法形态对推荐 web 服务选择的影响

推荐算法种类繁多，从简单的 KNN、item-based 协同过滤到复杂的深度学习、强化学习推荐算法，不同的算法实现方式、需要的数据来源、计算复杂度等都不一样。这也导致了算法的使用场景不一样。

像深层深度学习这种模型结构非常复杂的推荐算法，即使为单个标的物打分(即计算出用户对标的物的偏好度)，计算时间也是简单算法的若干倍，这时在短时间内(比如 100 毫秒之内)为大量的标的物打分是不现实的，因此这类算法一般用于排序阶段(排序阶段只对成百上千的标的物打分)，因此比较适合实时装配性的策略。

简单的推荐算法，如 item-based 协同过滤、矩阵分解，由于计算复杂度低，一般用于召回阶段，因此是比较适合事先计算型的。

总结

本章讲解了推荐系统提供 web 服务的两种主要方式。一种是事先计算型，提前将用户的推荐结果计算出来并存放到 NoSQL 中，当用户使用推荐模块时，推荐 web 服务直接将该用户的推荐结果取出来并组装成合适的数据格式最终在前端展示给用户。另一种是实时装配型，我们需要将计算推荐结果需要的原材料准备成“半成品”(就是各种特征)，将这些中间结果事先存起来，当用户使用推荐服务时，推荐 web 服务通过简单的组装与计算(调用封装好的推荐模型)，将“半成品”加工成该用户的推荐结果，并最终给到用户。

这两种提供 web 服务的推荐方案各有优缺点，我们需要根据公司现在的技术储备、人员能力、团队规模、产品形态等多个维度进行评估和选择。不管采用哪种方式，最终的目的是一样的，我们需要为用户提供个性化的、响应及时的优质推荐服务。

参考资料

1. [基于 TensorFlow Serving 的深度学习在线预估] https://zhuanlan.zhihu.com/p/46591057

2. [手把手教你使用 TF 服务将 TensorFlow 模型部署到生产环境] https://zhuanlan.zhihu.com/p/60542828

3. https://www.tensorflow.org/serving

4. https://github.com/facebookresearch/faiss