摘要：它使用機(jī)器學(xué)習(xí)來解釋用戶提出的問題，并用相應(yīng)的知識庫文章來回應(yīng)。使用一類目前較先進(jìn)的機(jī)器學(xué)習(xí)算法來識別相關(guān)文章，也就是深度學(xué)習(xí)。接下來介紹一下我們在生產(chǎn)環(huán)境中配置模型的一些經(jīng)驗。

我們?nèi)绾伍_始使用TensorFlow ?

在Zendesk，我們開發(fā)了一系列機(jī)器學(xué)習(xí)產(chǎn)品，比如的自動答案（Automatic Answers）。它使用機(jī)器學(xué)習(xí)來解釋用戶提出的問題，并用相應(yīng)的知識庫文章來回應(yīng)。當(dāng)用戶有問題、投訴或者查詢時，他們可以在線提交請求。收到他們的請求后，Automatic Answers將分析請求，并且通過郵件建議客戶閱讀相關(guān)的可能最有幫助的文章。

Automatic Answers使用一類目前較先進(jìn)的機(jī)器學(xué)習(xí)算法來識別相關(guān)文章，也就是深度學(xué)習(xí)。 我們使用Google的開源深度學(xué)習(xí)庫TensorFlow來構(gòu)建這些模型，利用圖形處理單元（GPU）來加速這個過程。Automatic Answers是我們在Zendesk使用Tensorflow完成的第一個數(shù)據(jù)產(chǎn)品。在我們的數(shù)據(jù)科學(xué)家付出無數(shù)汗水和心血之后，我們才有了在Automatic Answers上效果非常好的Tensorflow模型。

但是構(gòu)建模型只是問題的一部分，我們的下一個挑戰(zhàn)是要找到一種方法，使得模型可以在生產(chǎn)環(huán)境下服務(wù)。模型服務(wù)系統(tǒng)將經(jīng)受大量的業(yè)務(wù)。所以需要確保為這些模型提供的軟件和硬件基礎(chǔ)架構(gòu)是可擴(kuò)展的、可靠的和容錯的，這對我們來說是非常重要的。接下來介紹一下我們在生產(chǎn)環(huán)境中配置TensorFlow模型的一些經(jīng)驗。

順便說一下我們的團(tuán)隊——Zendesk的機(jī)器學(xué)習(xí)數(shù)據(jù)團(tuán)隊。我們團(tuán)隊包括一群數(shù)據(jù)科學(xué)家、數(shù)據(jù)工程師、一位產(chǎn)品經(jīng)理、UX /產(chǎn)品設(shè)計師以及一名測試工程師。

Data Team At Zendesk Melbourne

TensorFlow模型服務(wù) ?

經(jīng)過數(shù)據(jù)科學(xué)家和數(shù)據(jù)工程師之間一系列的討論，我們明確了一些核心需求：

預(yù)測時的低延遲

橫向可擴(kuò)展

適合我們的微服務(wù)架構(gòu)

可以使用A/B測試不同版本的模型

可以與更新版本的TensorFlow兼容

支持其他TensorFlow模型，以支持未來的數(shù)據(jù)產(chǎn)品

TensorFlow Serving ?

經(jīng)過網(wǎng)上的調(diào)研之后，Google的TensorFlow Serving成為我們推薦的模型服務(wù)。TensorFlow Serving用C++編寫，支持機(jī)器學(xué)習(xí)模型服務(wù)。開箱即用的TensorFlow Serving安裝支持：

TensorFlow模型的服務(wù)

從本地文件系統(tǒng)掃描和加載TensorFlow模型

（小編注：TensorFlow和TensorFlow Serving的區(qū)別：TensorFlow項目主要是基于各種機(jī)器學(xué)習(xí)算法構(gòu)建模型，并為某些特定類型的數(shù)據(jù)輸入做適應(yīng)學(xué)習(xí)，而TensorFlow Serving則專注于讓這些模型能夠加入到產(chǎn)品環(huán)境中。開發(fā)者使用TensorFlow構(gòu)建模型，然后TensorFlow Serving基于客戶端輸入的數(shù)據(jù)使用前面TensorFlow訓(xùn)練好的模型進(jìn)行預(yù)測。）

TensorFlow Serving將每個模型視為可服務(wù)對象。它定期掃描本地文件系統(tǒng)，根據(jù)文件系統(tǒng)的狀態(tài)和模型版本控制策略來加載和卸載模型。這使得可以在TensorFlow Serving繼續(xù)運行的情況下，通過將導(dǎo)出的模型復(fù)制到指定的文件路徑，而輕松地?zé)岵渴鸾?jīng)過訓(xùn)練的模型。

? ?

TensorFlow Serving Architecture

根據(jù)這篇Google博客中報告的基準(zhǔn)測試結(jié)果，他們每秒記錄大約100000個查詢，其中不包括TensorFlow預(yù)測處理時間和網(wǎng)絡(luò)請求時間。

有關(guān)TensorFlow Serving架構(gòu)的更多信息，請參閱TensorFlow Serving文檔。

通信協(xié)議（gRPC） ?

TensorFlow Serving提供了用于從模型調(diào)用預(yù)測的gRPC接口。gRPC是一個開源的高性能遠(yuǎn)程過程調(diào)用（remote procedure call，RPC）框架，它在HTTP/2上運行。與HTTP/1.1相比，HTTP/2包含一些有趣的增強(qiáng)，比如它對請求復(fù)用、雙向流和通過二進(jìn)制傳輸?shù)闹С?，而不是文本?/p>

默認(rèn)情況下，gRPC使用Protocol Buffers (Protobuf)作為其信息交換格式。Protocol Buffers是Google的開源項目，用于在高效的二進(jìn)制格式下序列化結(jié)構(gòu)化數(shù)據(jù)。它是強(qiáng)類型，這使它不容易出錯。數(shù)據(jù)結(jié)構(gòu)在.proto文件中指定，然后可以以各種語言（包括Python，Java和C ++）將其編譯為gRPC請求類。 這是我第一次使用gRPC，我很想知道它與其他API架構(gòu)（如REST）相比誰性能更好。

模型訓(xùn)練和服務(wù)架構(gòu) ?

我們決定將深度學(xué)習(xí)模型的訓(xùn)練和服務(wù)分為兩個管道。下圖是我們的模型訓(xùn)練和服務(wù)架構(gòu)的概述：

Model Training and Serving Architecture

模型訓(xùn)練管道

模型訓(xùn)練步驟：

我們的訓(xùn)練特征是從Hadoop中提供的數(shù)據(jù)生成的。

生成的訓(xùn)練特征保存在AWS S3中。

然后使用AWS中的GPU實例和S3中的批量訓(xùn)練樣本訓(xùn)練TensorFlow模型。

一旦模型被構(gòu)建并驗證通過，它將被發(fā)布到S3中的模型存儲庫。

模型服務(wù)管道

驗證的模型在生產(chǎn)中通過將模型從模型庫傳送到TensorFlow Serving實例來提供。

基礎(chǔ)結(jié)構(gòu) ?

我們在AWS EC2實例上運行TensorFlow Serving。Consul在實例之前設(shè)置，用于服務(wù)發(fā)現(xiàn)和分發(fā)流量?？蛻舳诉B接從DNS查找返回的第一個可用IP?；蛘邚椥载?fù)載平衡可用于更高級的負(fù)載平衡。由于TensorFlow模型的預(yù)測本質(zhì)上是無狀態(tài)操作，所以我們可以通過旋轉(zhuǎn)加速更多的EC2實例 來實現(xiàn)橫向可擴(kuò)展性。

另一個選擇是使用Google Cloud平臺提供的Cloud ML，它提供TensorFlow Serving作為完全托管服務(wù)。 但是，當(dāng)我們在大概2016年9月推出TensorFlow Serving時，Cloud ML服務(wù)處于alpha階段，缺少生產(chǎn)使用所需的功能。因此，我們選擇在我們自己的AWS EC2實例中托管，以實現(xiàn)更精細(xì)的粒度控制和可預(yù)測的資源容量。

模型服務(wù)的實現(xiàn) ?

下面是我們實現(xiàn)TensorFlow Serving部署和運行所采取的步驟：

1.從源編譯TensorFlow Serving

首先，我們需要編譯源代碼來產(chǎn)生可執(zhí)行的二進(jìn)制文件。然后就可以從命令行執(zhí)行二進(jìn)制文件來啟動服務(wù)系統(tǒng)。

假設(shè)你已經(jīng)配置好了Docker，那么一個好的開端就是使用提供的Dockerfile來編譯二進(jìn)制文件。請按照以下步驟：

運行該gist中的代碼以構(gòu)建適合編譯TensorFlow Serving的docker容器。

在正在運行的docker容器中運行該gist中的代碼以構(gòu)建可執(zhí)行二進(jìn)制文件。

一旦編譯完成，可執(zhí)行二進(jìn)制文件將在你的docker鏡像的以下路徑中：/work/serving/bazel-bin/tensorflow_serving/model_servers/tensorflow_model_server

2.運行模型服務(wù)系統(tǒng)

上一步生成的可執(zhí)行二進(jìn)制文件（tensorflow_model_server）可以部署到您的生產(chǎn)實例中。 如果您使用docker編排框架（如Kubernetes或Elastic Container Service），您還可以在docker容器中運行TensorFlow Serving。

現(xiàn)在假設(shè)TensorFlow模型存儲在目錄/work/awesome_model_directory下的生產(chǎn)主機(jī)上。你可以在端口8999上使用以下命令來運行TensorFlow Serving和你的TensorFlow模型：

/tensorflow_model_server — port=8999 — model_base_path=/work/awesome_model_directory

默認(rèn)情況下，TensorFlow Serving會每秒掃描模型基本路徑，并且可以自定義。此處列出了可作為命令行參數(shù)的可選配置。

3.從服務(wù)定義（Service Definitions）生成Python gRPC存根

下一步是創(chuàng)建可以在模型服務(wù)器上進(jìn)行預(yù)測的gRPC客戶端。這可以通過編譯.proto文件中的服務(wù)定義，從而生成服務(wù)器和客戶端存根來實現(xiàn)。.proto文件在TensorFlow Serving源碼中的tensorflow_serving_apis文件夾中。在docker容器中運行以下腳本來編譯.proto文件。運行提交版本號為46915c6的腳本的示例：

./compile_ts_serving_proto.sh 46915c6

運行該腳本后應(yīng)該在tensorflow_serving_apis目錄下生成以下定義文件：

model_pb2.py

predict_pb2.py

prediction_service_pb2.py

你還可以使用grpc_tools Python工具包來編譯.proto文件。

4.從遠(yuǎn)程主機(jī)調(diào)用服務(wù)

可以使用編譯后的定義來創(chuàng)建一個python客戶端，用來調(diào)用服務(wù)器上的gRPC調(diào)用。比如這個例子用一個同步調(diào)用TensorFlow Serving的Python客戶端。

如果您的用例支持異步調(diào)用預(yù)測，TensorFlow Serving還支持批處理預(yù)測以達(dá)到性能優(yōu)化的目的。要啟用此功能，你應(yīng)該運行tensorflow_model_server同時開啟flag?—enable_batching。這是一個異步客戶端的例子。

從其他存儲加載模型

如果你的模型沒有存儲在本地系統(tǒng)中應(yīng)該怎么辦？你可能希望TensorFlow Serving可以直接從外部存儲系統(tǒng)（比如AWS S3和Google Storage）中直接讀取。

如果是這種情況，你將需要通過Custom Source來拓展TensorFlow Serving以使其可以讀取這些源。TensorFlow Serving僅支持從文件系統(tǒng)加載模型。

一些經(jīng)驗 ?

我們在產(chǎn)品中已經(jīng)使用TensorFlow Serving大概半年的時間，我們的使用體驗是相當(dāng)平穩(wěn)。它具有良好的預(yù)測時間延遲。以下是我們的TensorFlow Serving實例一周內(nèi)的預(yù)測時間（以秒為單位）的第95百分位數(shù)的圖（約20毫秒）：

然而，在生產(chǎn)中使用TensorFlow Serving的過程中，我們也有一些經(jīng)驗教訓(xùn)可以跟大家分享。

1.模型版本化

到目前為止，我們已經(jīng)在產(chǎn)品中使用了幾個不同版本的TensorFlow模型，每一個版本都有不同的特性，比如網(wǎng)絡(luò)結(jié)構(gòu)、訓(xùn)練數(shù)據(jù)等。正確處理模型的不同版本已經(jīng)是一個重要的任務(wù)。這是因為傳遞到TensorFlow Serving的輸入請求通常涉及到多個預(yù)處理步驟。這些預(yù)處理步驟在不同TensorFlow模型版本下是不同的。預(yù)處理步驟和模型版本的不匹配可能導(dǎo)致錯誤的預(yù)測。

1a.明確說明你想要的版本

我們發(fā)現(xiàn)了一個簡單但有用的防止錯誤預(yù)測的方法，也就是使用在model.proto定義中指定的版本屬性，它是可選的（可以編譯為model_pb2.py）。這樣可以始終保證你的請求有效負(fù)載與預(yù)期的版本號匹配。

當(dāng)你請求某個版本（比如從客戶端請求版本5），如果TensorFlow Serving服務(wù)器不支持該特定版本，它將返回一個錯誤消息，提示找不到模型。

1b.服務(wù)多個模型版本

TensorFlow Serving默認(rèn)的是加載和提供模型的版本。當(dāng)我們在2016年9月首次應(yīng)用TensorFlow Serving時，它不支持同時提供多個模型。這意味著在指定時間內(nèi)它只有一個版本的模型。這對于我們的用例是不夠的，因為我們希望服務(wù)多個版本的模型以支持不同神經(jīng)網(wǎng)絡(luò)架構(gòu)的A / B測試。

其中一個選擇是在不同的主機(jī)或端口上運行多個TensorFlow Serving進(jìn)程，以使每個進(jìn)程提供不同的模型版本。這樣的話就需要：

用戶應(yīng)用程序（gRPC客戶端）包含切換邏輯，并且需要知道對于給定的版本需要調(diào)用哪個TensorFlow Serving實例。這增加了客戶端的復(fù)雜度，所以不是推薦。

一個可以將版本號映射到TensorFlow Serving不同實例的注冊表。

更理想的解決方案是TensorFlow Serving可以支持多個版本的模型。

所以我決定使用一個“l(fā)ab day”的時間來擴(kuò)展TensorFlow Serving，使其可以服務(wù)多個版本的時間。在Zendesk，“l(fā)ab day”就是我們可以每兩周有一天的時間來研究我們感興趣的東西，讓它成為能夠提高我們?nèi)粘Ｉa(chǎn)力的工具，或者一種我們希望學(xué)習(xí)的新技術(shù)。我已經(jīng)有8年多沒有使用C++代碼了。但是，我對TensorFlow Serving代碼庫的可讀性和整潔性印象深刻，這使其易于擴(kuò)展。支持多個版本的增強(qiáng)功能已經(jīng)提交，并且已經(jīng)合并到主代碼庫中。

TensorFlow Serving維護(hù)人員對補(bǔ)丁和功能增強(qiáng)的反饋非常迅速。從的主分支，你可以啟動TensorFlow Serving，用model_version_policy中附加的flag來服務(wù)多個模型版本：

/work/serving/bazel-bin/tensorflow_serving/model_servers/tensorflow_model_server — port=8999 — model_base_path=/work/awesome_model_directory — model_version_policy=ALL_VERSIONS

一個值得注意的要點是，服務(wù)多個模型版本，需要權(quán)衡的是更高的內(nèi)存占用。所以上述的flag運行時，記住刪除模型基本路徑中的過時模型版本。

2.活用壓縮

當(dāng)你部署一個新的模型版本的時候，建議在復(fù)制到model_base_path之前，首先將導(dǎo)出的TensorFlow模型文件壓縮成單個的壓縮文件。Tensorflow Serving教程中包含了導(dǎo)出訓(xùn)練好的Tensorflow模型的步驟。導(dǎo)出的檢查點TensorFlow模型目錄通常具有以下文件夾結(jié)構(gòu)：

一個包含版本號（比如0000001）和以下文件的父目錄：

saved_model.pb：序列化模型，包括模型的圖形定義，以及模型的元數(shù)據(jù)（比如簽名）。

variables：保存圖形的序列化變量的文件。壓縮導(dǎo)出的模型：

tar -cvzf modelv1.tar.gz 0000001

為什么需要壓縮？

壓縮后轉(zhuǎn)移和復(fù)制更快

如果你將導(dǎo)出的模型文件夾直接復(fù)制到model_base_path中，復(fù)制過程可能需要一段時間，這可能導(dǎo)致導(dǎo)出的模型文件已復(fù)制，但相應(yīng)的元文件尚未復(fù)制。如果TensorFlow Serving開始加載你的模型，并且無法檢測到源文件，那么服務(wù)器將無法加載模型，并且會停止嘗試再次加載該特定版本。

3.模型大小很重要

我們使用的TensorFlow模型相當(dāng)大，在300Mb到1.2Gb之間。我們注意到，在模型大小超過64Mb時，嘗試提供模型時將出現(xiàn)錯誤。這是由于protobuf消息大小的硬編碼64Mb限制，如這個TensorFlow Serving在Github上的問題所述。

最后，我們采用Github問題中描述的補(bǔ)丁來更改硬編碼的常量值。（這對我們來說還是一個問題。如果你可以找到在不改變硬編碼的情況下，允許服務(wù)大于64Mb的模型的替代方案，請聯(lián)系我們。）

4.避免將源移動到你自己的分支下

從實現(xiàn)時開始，我們一直從主分支構(gòu)建TensorFlow Serving源，的版本分支（v0.4）在功能和錯誤修復(fù)方面落后于主分支。因此，如果你只通過檢查主分支來創(chuàng)建源，一旦新的更改被合并到主分支，你的源也可能改變。為了確保人工制品的可重復(fù)構(gòu)建，我們發(fā)現(xiàn)檢查特定的提交修訂很重要：

TensorFlow Serving

TensorFlow（TensorFlow Serving里的Git子模塊）

期待未來加入的一些功能增強(qiáng)清單 ?

這里是一些我們比較感興趣的希望以后TensorFlow Serving會提供的功能：

健康檢查服務(wù)方法

一個TensorFlow Serving實例可以支持多種模型類型

直接可用的分布式存儲（如AWS S3和Google存儲）中的模型加載

直接支持大于64Mb的模型

不依賴于TensorFlow的Python客戶端示例

商業(yè)智能與數(shù)據(jù)分析群

興趣范圍包括各種讓數(shù)據(jù)產(chǎn)生價值的辦法，實際應(yīng)用案例分享與討論，分析工具，ETL工具，數(shù)據(jù)倉庫，數(shù)據(jù)挖掘工具，報表系統(tǒng)等全方位知識

QQ群：81035754