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

2017-08-08?何滄平?AI前線 作者｜何滄平編輯｜陳思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 個勞工都執行了第 13142、13144、13146、13148 步，但都沒有執行 13143、13145、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

今日薦文

點擊下方圖片即可閱讀

? ? ? ? ? ? ? ? ? ? ? ? ? ??? ??? ?

2017 年已經過去 218 天，大數據雜談 80 篇精選文章千萬別又雙叒叕錯過啦

---

CNUTCon 全球運維技術大會將于 9 月 10-11 日在上海舉行，大會主題是“智能時代的新運維”，并特設“大數據運維”專場，邀請了來自騰訊、蘇寧等公司大咖分享他們在最新運維技術實踐過程中遇到的坑與經驗，更有 Google、Uber、eBay、BAT 等一線技術大牛現場為你解疑答惑，點擊“閱讀原文”了解更多精彩！9 折限時優惠，本文的讀者在報名時輸入 CNUTCon666 還可再減 200 哦！

?

---

?

閱讀原文

微信掃一掃
關注該公眾號

總結

以上是生活随笔為你收集整理的https://mp.weixin.qq.com/s?src=11timestamp=1509090286ver=477signature=cgdv6tbrM5s58sUA9FGT7bBpm*a的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。