隨著互聯網的發展和人工智能的進步，各個廠家都開始針對性的向用戶推薦自己的內容，這些內容包括了文章、視頻、商品以及一些其他的希望被用戶看到的內容了，能夠讓用戶有好的內容的體驗，更好的捕捉到用戶所需要的內容，這背后的成功都歸功于推薦系統。

企業中的推薦系統包括哪幾個部分

上面是企業中一個常見的推薦系統的架構圖，一般來講，一個完整的推薦系統企業級的架構應該包括數據的存儲、業務模型、服務層以及上層對于用戶來講可見的 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