企业中的推荐系统包括哪几个部分

随着互联网的发展和人工智能的进步，各个厂家都开始针对性的向用户推荐自己的内容，这些内容包括了文章、视频、商品以及一些其他的希望被用户看到的内容了，能够让用户有好的内容的体验，更好的捕捉到用户所需要的内容，这背后的成功都归功于推荐系统。

企业中的推荐系统包括哪几个部分

上面是企业中一个常见的推荐系统的架构图，一般来讲，一个完整的推荐系统企业级的架构应该包括数据的存储、业务模型、服务层以及上层对于用户来讲可见的 App 或者一些其他可视化是产品。

数据存储

对于数据存储来讲，几乎是每一个完整的推荐系统必不可少的一个部分，所有的用户数据、候选内容的所有的信息、日志系统以及缓存等，全都属于数据存储的一部分，后续我们要做的与用户相关的画像、内容画像以及其他需要提取的特征信息也全都来自于数据系统。

一般来讲，数据系统是一个很大的概念，它不仅限于某一个数据库，或者某一个数据处理逻辑，而是一整套与数据相关的系统，用于存储用户信息的关系型数据库、用户存储商品信息的数据模型、用于进行大数据运算的数据湖和数据集群等，我们把这些处理数据的系统整合，形成了推荐系统的数据存储部分。

业务模型

业务模型是推荐系统的核心。推荐系统的效果好坏可以说 90% 以上是由于业务模型决定的。在一个推荐系统中，数据系统一般包含三个部分，数据逻辑层、召回层和排序层。

一般来讲，我们当从用户进入到我们的系统的时候，推荐系统就已经在发挥作用了。首先，我们会将用户的数据通过各种数据处理、深度学习或者机器学习的方法进行数据的处理，这一部分的处理一般包括类似于用户日志采集，分词、内容画像、用户画像等，这里可用使用大量的深度学习方式来做。

接下来，我们可以使用这些画像和特征来进行针对于特定用户的内容召回，这里的召回实际上就是通过各种方法来找到用户可能感兴趣的内容。

当找到用户可能感兴趣的内容之后，我们一般会对这些内容进行进一步的筛选和排序，找到在这些内容中，用户最感兴趣的前面的几个或者几十个内容分别是什么，这一步，一般我们称之为排序层。

最后，我们可以将排序后的结果输出给用户进行界面的展示，从而达到最后的推荐效果。

使用 TensorFlow Serving 赋能

目前来讲，无论是数据逻辑、召回层还是排序层，都可以使用很多深度学习的方法来做。例如数据逻辑中有关命名实体识别的部分可以使用 TensorFlow 来实现，召回层可以使用 TensorFlow 来实现 YoutubeDNN 模型并部署到生产环境中，在排序层我们也可以使用 xDeepFM 等深度学习方法来实现。

那么对于这些深度学习模型来讲，最好的模型上线和部署方式莫过于使用 TensorFlow Serving 进行部署了。

由于 TensorFlow Serving 本身就是 Google 自家的产品，也是 TensorFlow 大家族的一部分，因此，使用 TensorFlow Serving 对 TensorFlow 的模型进行部署无疑是最好的选择。

在我所在的企业中，几乎所有的深度学习所涉及到的模型都会被转换成 TensorFlow Serving 的模式进行部署。在使用 TensorFlow Serving 进行模型部署的时候，实际上会有很多个 tricks。

例如，在实际的操作当中，很多人会发现，自己也把模型转换成了 PB 模型，也能自己使用代码的方式加载这个 pb 模型进行推理，但是，放到 TensorFlow Serving 上之后就无法进行推理，然后还会报各种各样莫名其妙的错误。一般来讲，造成这个问题的原因有以下几种。

1. pb 模型转换的类型错误

pb 模型转换的类型错误是大部分 TensorFlow 开发人员常见的错误之一，一般来讲，TensorFlow 可以转换的 pb 文件大致可以分成两种，一种是直接转换成一个 pb 文件，这种文件只是一个以模型名称命名，以 .pb 为格式的单个文件，这个文件一般使用在终端的推理中，比如移动端的推理，或者是给到 C++ 等语言进行模型的调用，但是如果把它直接使用 TensorFlow Serving 进行部署的话，往往就会出错。

实际上，如果想使用 TensorFlow Serving 进行部署，那么我们就需要将我们的模型转换成 Saved Model 格式的 pb 文件。Saved Model 格式的 pb 文件与一般的 pb 文件相比不同之处在于，Saved Model 格式的 pb 文件一般是冻结图文件，它可以更方便的部署。一般来讲，使用 Saved Model 格式进行打包之后，除了模型文件本身，会生成 variables 目录，其中 pb 文件是模型的定义文件，variables 目录下存放的是模型的各个推理所需要的参数。

因此，如果你生成了一个 pb 文件在本地可以推理，但是放在 TensorFlow Serving 中部署的时候不能推理的话，首先看看是不是这里的问题。

2. 在 TensorFlow Serving 中推理的时候没有加入版本标识

有些同学在使用 TensorFlow Serving 的时候，也能够转换成 Saved Model 格式的 pb 文件了，而且在本地验证也没有问题了，但是放到 TensorFlow Serving 的相关服务上就会报错，总是提示找不到版本，一般来讲，这种问题是你导出的模型中没有添加模型的版本号所导致的，我们在 TensorFlow Serving 中进行模型部署的时候，往往都需要在最外层定义一个模型的版本号，而 TensorFlow Serving 也会通过判断模型的版本号来进行模型的更新。

3. 模型没有标明正确的输入输出

有些同学在模型转换完之后，发现无法在推理环境中运行，一直提示输入的 tensor 不正确，这种情况下一般来讲是在对模型进行导出时，没有对输入输出的参数进行命名，从而使得模型使用了标准的命名，导致无法进行推理。

TensorFlow Serving 的性能优化

之前很多人在使用 TensorFlow Serving 在做模型部署的时候，都跟我说它的性能不好，部署 Albert tiny 模型的 QPS 连 50 都不到，还不如使用传统的部署方法，当我跟大家说，我使用 TensorFlow Serving 部署时，在 CPU 服务器上 QPS 能上到 2000 多，在 GPU 服务器上 QPS 甚至能达到 5000 以上，那么，为什么差异会这么大呢？

实际上，如果按照正常的部署方式，没有带任何参数的话，它的并发确实会很低，但是实际上，TensorFlow Serving 给我们提供了针对于高并发的部署方案，在 http://tensorflow.google.cn/tfx/serving/serving_config 中，有一个叫做 Batching Configuration 的配置的示例：

max_batch_size { value： 128 }

batch_timeout_micros { value： 0 }

max_enqueued_batches { value： 1000000 }

num_batch_threads { value： 8 }

这个示例，很大程度上决定了并发的性能。一般来讲，在使用 CPU 部署的时候，我们可以将 num_batch_threads 设置为 CPU 核数的 2 倍加 1，例如我们的 CPU 是 48 核，这里可以设置为 97；当我们使用 GPU 进行部署的时候，这里面的 num_batch_threads 最好设置为 GPU 的个数。这样的设置，能够最大的程度上利用到我们的 CPU 和 GPU，使得并发提高。

在部署方面，TensorFlow Serving 给我们提供了 2 种大类别的 docker，一个是 GPU 的一个是 CPU 的，这个在做 docker 部署的时候一定要注意区分，否则很容易导致部署之后的性能低；另外，在 TensorFlow Serving 所提供的 docker 中，又可以分为 devel 版本和正常版本，其中 devel 里面带有一些内置的开发环境，一般用于调试用，在正式环境中，我们更建议使用正常的 docker 版本。

实际上，在工业界，将 TensorFlow 与推荐系统结合的例子很多，我们可以利用好 TensorFlow Serving 做好模型的推理，从而更好的提供相关的服务。

责任编辑：haq