機器學習與微博：TensorFlow在微博的大規模應用與實踐

AI前線

做者｜何滄平
編輯｜Vincent
AI前線出品｜ ID：ai-front

TensorFlow 在微博業務中有豐富的應用場景，文字、圖片、視頻，各具特點。微博機器學習平臺集成 TensorFlow 服務，支持分佈式訓練，在廣告點擊預測應用中，本輪分享的主講人何滄平積累了一些 TensorFlow 優化經驗，在 8 月 3 日晚 AI 前線社羣分享活動中，他將本身的這些經驗分享給了你們。本文首發於 InfoQ 垂直公衆號 AI 前線。

借 AI 前線提供的交流機會，我給各位彙報一下 TensorFlow 在微博的使用狀況和在分佈式計算上的一點經驗，錯誤疏漏不足之處，敬請批評指教。

TensorFlow 在微博的應用場景

今天的分享內容由虛到實，由歸納到具體。

微博的日活和月活數量都在增加，移動端比例很高，佔 91%。2017 年 4 月份的財報顯示，營收同比增漲 67%，一個重要緣由就是移動端搶到了用戶的碎片時間。

微博裏隨處可見推薦信息：推薦的新聞、推薦的視頻、推薦的新帳號。最重要還有推薦的廣告。

用戶登陸之後，馬上就要計算推薦什麼內容。拿推薦廣告來講，備選的廣告數以萬計，須要排序給出最可能被點擊的幾條廣告。

若是切中用戶的購買須要，廣告就再也不是打擾。

垃圾嚴重影響用戶體驗，色情、暴力、反動、低俗，寧肯錯殺不可漏網，十分嚴格。

人工智能反垃圾的目標是提升準確度、下降成本。

圖像質量也是用戶體驗的基本要求。

用戶能夠容忍不感興趣的圖片，但很難容雜亂的圖像。

例如左邊的美女圖，看起來賞心悅目，手機上刷過，即便不停下細看，也不會反感。

右邊的圖片，裏面也是美女，但加上文字以後，馬上變得雜亂，版式與酒店裏的小卡片相仿。極可能被認定爲騙子。

明星是微博制勝的法寶。明星是公衆人物，話題多、熱度高、影響力大。明星粉絲狂熱，消費力強。

爲粉絲推薦她他喜歡的明星的行程、事件、各類評價，粉絲愛看。甚至明星代言的廣告，粉絲可能都會喜歡。停留在微博的時間越長，有意無心瀏覽的廣告就越多。正確識別明星就很重要了，若是不巧推薦了用戶討厭的明星，可能就沒了刷微博的心情。

明星臉識別是微博的特點，有海量的明星圖片，也有巨大的識別需求。

明星臉識別有特別的困難：經常使用人臉識別研究所用的照片表情、造型較少，不一樣人之間的差異較大。而明星表情豐富，造型多變，不管男女都化妝！很多人妝容近似，有些整容臉連人腦都傻傻分不清，計算機就更難分清了。

上部的圖片可能歸屬兩個及以上類別，所以稱爲「兼類」。

圖片、視頻分類的最終目的都是爲了關聯廣告。喜歡旅遊的用戶就給她他推薦旅遊景點、線路、酒店、機票、戶外裝備等。

若是廣告可以切中用戶原本就要買的物品，就沒必要費盡心機說服用戶購買沒必要要的商品，只須要將購買場所由一個地點（網站、實體店）轉移到另外一個地點，將購買時間由未來轉移到如今，將商品品牌由 A 切換爲 B。這樣廣告效果天然會好不少，點擊率高，用戶還不反感。

例如，印度電影《三個白癡》中幾回提到太空筆，我當時就特別想買一支，在京東上搜了半個小時。若是可以提早識別到這個廣告點，並在播放過程當中推薦購買連接，極可能當即就下單了。

可是，圖像分類難，視頻精細分類更難，又不得不分。短視頻（5 分鐘之內）方興未艾，變現模式還不成熟，處於燒錢階段。相對於文本、圖片，短視頻的帶寬成本更高，消耗的用戶時間更多。若是關聯廣告的轉化率不高，入不敷出，沒法長久。

TensorFlow 在微博的應用技術 & 案例

務虛內容結束，下面是具體點的技術。

微博機器學習平臺承擔了離線訓練和在線預測任務。微博實時產生的文本、圖片、視頻顯示後轉入後臺，用於提取特徵、離線訓練。

愈來愈多的業務使用深度學習方法，TensorFlow/Caffe 框架被集成進來。

離線訓練主要使用 GPU 機羣。因爲業務增加過快，計算機羣有一部分來自阿里雲。

這一頁徹底是我的理解。

對規模巨大的訓練任務，TensorFlow 提供了分佈式的模式。

TensorFlow 分佈式計算與 HPC 的 MPI(Message Passing Interface) 分佈計算區別很大。用過 MPI 的人都知道，MPI 進程相互平等，保證沒有瓶頸進程。MPI-IO 也設計得每一個主機都能均勻分擔 IO 壓力。MPI 進程上的計算任務也要求均勻劃分，保證各個進程的計算進度保持一致。MPI 進程之間也只交換數據塊的邊界，儘可能減小網絡流量，壓縮通訊時間。

TensorFlow 的分佈式計算設計得簡單粗暴。

若干參數服務器 (parameter server) 和若干勞工 (worker) 組成一個機羣 (cluster)，勞工承擔運算任務，將每步運算獲得的參數（權重和 bias）提交給參數服務器，參數服務器未來自全部 worker 的參數合併起來，獲得全局參數，而後將全局參數發送給勞工。勞工在全局參數的基礎上繼續下一步運算。

TensorFlow 採用主從模式，參數服務器是瓶頸。每步都要傳遞全部的參數，網絡流量太大，假設每一個勞工上參數佔用內存 1GB，機羣包含 1 個參數服務器和 10 個勞工，那麼每一個迭代步將產生 20GB 的網絡流量，按照 10GbE 網絡計算，通訊時間至少需 16 秒。而實際上，每一個 batch 數據的運算時間可能還不足 1 秒，模型參數佔用的內存可能遠大於 1GB。從理論分析來看，TensorFlow 分佈式運算的效率不如 MPI。

有人說深度學習只是高性能計算的一個特殊應用，我認爲不是這樣。

如圖中表格所列，TensorFlow 機羣就與 HPC 機羣有重大區別。

HPC 機羣的 3 大特色：高性能計算芯片（高端 CPU、GPU）、高速網絡、並行存儲。TensorFlow 機羣只須要其中的 1 個：高端 GPU。

勞工在一批數據上訓練獲得∆W 和∆b（合稱爲∆P），稱爲一步訓練。

如上圖所示，全部的勞工（Device A/B/C）在完成一步訓練後，暫停訓練，將本身獲得的∆P 發送到參數服務器（Parameter Device）。參數服務器一直等待，直到來自全部的勞工的參數變化量∆P 都接收成功。參數服務器將全部的∆P 相加取平均，而後用這個均值更新舊參數（更新公式請參見隨機梯度算法），獲得新參數 P，接着將 P 發送給全部的勞工。勞工在接收到新參數 P 之後，才進行下一步的訓練。

與用 1 臺服務器訓練相比，用 N 臺勞工同時訓練 + 同步更新參數等價於將 batch 的規模擴大了 N 倍。具體來講，若是用 1 臺服務器時，每步訓練採用 100 張數字圖片（batch=100）, 那麼用 4 個勞工獲得的參數變化量（即∆P）同步更新，就至關於每步訓練採用 400 張數字圖片（batch=400）。從而，參數變化得更平穩，收斂更快。

同步更新也有缺點：總體速度取決於最慢的那個勞工。若是勞工之間的軟硬件配置差異較大，有明顯的速度差別，同步更新計算速度較慢。

爲了不勞工有快有慢形成的等待，TensorFlow 提供了異步更新策略。

如圖下部所示，當有一個勞工訓練獲得一個參數變化量∆P 時，不妨假設是圖中的 Device A，該勞工當即將∆P 發送給參數服務器。參數服務器接收到來自勞工 Device A 的∆P 後，不等待其它的勞工，當即用∆P 更新全局參數，獲得全局參數 P，緊接着將 P 發送給勞工 Device A。勞工 Device A 接收到全局參數 P 後，當即開始下一步訓練。

由異步更新參數的過程可知，它等價於只用 1 臺服務器訓練：都是每次用一小批（batch）圖像訓練更新參數，只是各批數據的上場順序不能事先肯定，上場順序由勞工的隨機運行狀態肯定。

剛開始運算時，勞工 0(左邊) 先算了 10100 步（對應 localstep）, 此後勞工 1（右邊）纔開始運算。這說明，在異步運算模式下，勞工之間確實不相互等待。勞工 0 和勞工 1 都運算了全局第 10100 步 (global_step_value)，說明運算的剖分並不十分準確。

2 個勞工都執行了第 1314二、1314四、1314六、13148 步，但都沒有執行 1314三、1314五、13147 這 3 步。這說明 Tensorflow 異步更新的任務指派會隨機出錯，並非絕對不重不漏。所幸隨機梯度法對更新順序沒有要求，少許的錯誤對最終計算結果影響不大。

同步更新模式不能真正地同步執行，將程序殺死的時候，2 個勞工執行完的步數相差不少。勞工 0 本地執行了 11023 步以後，全局步數居然只有 7072，確定出錯了。

網絡上也有人報告了這個錯誤：

https://github.com/tensorflow/tensorflow/issues/9596，

TensorFlow 開發者已經確認這是一個漏洞，但還沒有修復。

公式預警。。。。

以 MNIST 手寫數字識別爲例，上部分公式迭代一步就使用全部 n 個樣本。

下部公式將全部樣本分割成若干批次（batch）。

TensorFlow 的異步更新，就是不一樣的勞工使用不一樣的小批訓練樣原本更新權重和 bias，不能事先肯定每一個勞工的更新順序。具體舉例：假設有 2 個勞工執行訓練任務，勞工 0 負責更新奇數批次樣本 b1/b3/b5…b499，勞工 1 負責更新偶批樣本 b2/b4,…,b500。

因爲各類隨機因素，樣本的使用順序多是 b1àb3àb5àb2àb7àb4à…由於樣本的批次劃分自己就是隨機的，這樣亂序更新仍然是隨機的，對最終結果沒有什麼影響。

TensorFlow 同步更新時，對全部勞工獲得的梯度求平均，而後更新權重和截距。仍然假設有 2 個勞工，它們分別訓練第 1 批和第 2 批樣本獲得梯度∆w1 和∆b1 截距分別爲∆w2 和∆b2，同步以後的梯度如圖中所示。

從而，同步更新等價於一次使用 2m 個訓練樣本，正則化係數和 batch 大小都擴大爲原來的 2 倍而已。若是勞工數量不少（例如 20 個），那麼同步更新就等價於一次使用 2000 個訓練樣本，與劃分 batch 的初衷不符。所以，建議不要使用同步更新。

注意公式裏紅色的（2m）

下面是一個具體優化案例：

CTR（Click-Through-Rate，點擊經過率）是營收的關鍵。

對候選廣告按點擊可能性排序，而後插入到用戶信息流之中。

deepCTR 不徹底是特徵工程，輸入層與隱層的鏈接關係也是不全鏈接。

千億樣本數據近百 TB，爲提升效率，採用多人推薦過的 TensorFlow 隊列。

我的理解，隊列的設計初衷很好（如圖中表格所示），但實際性能不好，GPU 利用率只有 5%。查找緣由發現，程序卡在線程同步操做上，而這個線程同步就來自於 TensorFlow 隊列。因而嘗試用別的方式讀取訓練樣本文件。

左圖橫軸採用對數座標。

隊列讀以 CSV 帶寬只有極限帶寬的 1/467，隊列讀取 tfrecord 格式文件帶寬提高至 1.24MB/s，提升至 3.2 倍。因爲 tfrecord 格式文件較小，讀完一個文件的耗時下降至 15%(272.6/1789.9)。

用 pandas 讀取文件帶寬達到極限帶寬的 35%。最終捨棄 TensorFlow 隊列，選用 pandas 讀 CSV 文件。

當 CSV 文件小於 1/3 內存時，直接用 pandas 一次性讀入內存。不用 tf 隊列，數據混洗就要程序員本身完成，所幸不麻煩。

對大於內存 1/3 的文件，直接拆分紅多個小文件。須要程序員自行保證均勻使用各個小文件。

最後給各位彙報一個小遊戲。

用 MNIST 訓練獲得的 CNN 網絡來識別漢字，「霸」字被識別爲 1。這點很容易理解，獲得的 CNN 網絡只有 10 個類別，不得不在 0~9 個數字中選一個。

由於「霸」字與任何數字都不像，識別爲任何數字的「機率」應該都不太大吧，例如都小於 0.2（隨便說的數值）。但是實際狀況倒是這樣：0~9 分類對應的機率差異很大，最大接近 0.8，最小接近 0，卷積網絡識別漢字的時候不會猶豫不決，錯得十分堅決。

從這個小實驗裏能夠發現幾個問題：

圖像的特徵到底是什麼？若是有，如何用這些特徵來區分不認識的圖像（好比這個例子裏的漢字）？

如何控制一個網絡的泛化能力？這個例子中的泛化能力看起來太強了，以至於把漢字都識別成數字了。目前看來，CNN 的泛化能力幾乎是聽天由命。

softmax 後的值真的表明機率嗎？看起來它們僅僅是和爲 1 正數。機率本質的隨機性體如今哪裏呢？

這些問題，我尚未想明白，這裏提出來，請各位朋友批評指教。

問答環節

問題 1：隊列讀取性能差是不是因爲設置 cache 的樣本數問題？回答：cache 基本沒有影響。batch_size 會有影響，最關鍵仍是線程鎖的問題。

問題 2：（反垃圾）這一步的準確率怎麼算的？是模型準確率嗎？

回答：這個涉及到業務，不便透露。能夠私下交流。

問題 3：千億級別 feature 沒有模型並行嗎？感受模型單機放不了，不能數據並行。

回答：數據並行，所以研究分佈式運算。

問題 4：1 億條評論的話，你怎麼判斷分類器是否分正確了？仍是說這裏的準確率只是在測試集上的準確率？

回答：業務上具體作法不便透露。這裏提醒一下，微博有舉報、屏蔽功能。

問題 5：微博的 TensorFlow 環境配置，資源管理和分佈式計算是用的第三方平臺嗎？仍是本身封裝的

回答：資源管理和分佈式計算嘗試過幾種方案，開源軟件 + 自行定製。多種機羣，安全級別和管理方式不徹底同樣，所以資源管理方式（網絡、存儲、權限）也不同。

問題 6：會考慮評價 GPU 的利用率嗎？好比用 deepbench 測？有什麼 GPU 提高利用率的經驗分享？

回答：GPU 利用率是成本覈算的重要指標，很重視。查看 GPU 利用率比較簡單：命令行 nvidia-smi，英偉達還有專門的庫，提供輕量級的 C、JAVA 等接口。

提升 GPU 利用率經驗：若是顯存能裝得下，儘可能使用 1 個模型訓練；設定顯存使用量（例如 0.5），將 2 個及以上做業放在同一個 GPU 上。IO 性能差的話，會致使數據供應不上，從而 GPU 利用低。PPT 中 deepCTR 優化案例就是這個狀況。batch 過小、權重矩陣太小，都會致使不能充分利用 GPU 的大量核心（一般有 4000-5000 個），利用率低。

問題 7：若是在龐大的 csv 上訓練, 用 tf 隊列和用 spark df 製做生成器的效果有比對過麼?

回答：目前沒有對比過 tf 隊列和 spark df。

做者介紹

何滄平，微博研發中心算法工程師，目前負責建設深度學習平臺。對高性能計算（HPC）較熟悉，著有《OpenACC 並行編程實戰》一書。若有相關技術問題能夠私下與講師討論，講師微信：272702575

－全文完－

AI前線提供最新最全AI領域技術資訊、一線業界實踐案例、蒐羅整理業界技術分享乾貨、最新AI論文解讀。歡迎關注咱們的專欄：AI前線

接下來會陸續更新一系列與 TensorFlow 理論與實踐案例相關的文章，這是第一篇，敬請期待。