機器學習的平台化發展趨勢

01-30

背景

機器學習在經過近些年的野蠻生長之後，其有效性已經被無數成功應用所驗證，在這一點上已經不需要更多證明。在使用方法和常用模型方面也已經沒有什麼太新奇的東西了。例如在模型方面，經過實踐檢驗過的模型基本還是LR和GBDT，以及這兩者的一些變種和結合，例如FM、LR+GBDT等等；再例如在特徵處理方面，常用的包括離散化、歸一化、平滑等等。學術界對這些方面的進一步改進，從效果上來說就像在從95分到98分，對整個工業界應用來講不是目前最重要的[1]。那麼最重要的是什麼呢？很有可能，最重要的是機器學習系統的平台化，以及圍繞平台化展開的一系列工作。

什麼是機器學習平台？

什麼叫做「機器學習系統的平台化」呢？簡單來說，就是要把機器學習系統做成一個簡單易用的、更加通用的平台，讓各種業務都能夠方便地接入這個平台，從而享受到機器學習帶來的紅利。這裡的業務，從大方面來說包括例如搜索、推薦等大業務，從小方面來說包括不同位置的推薦模塊等小業務。說到平台，很容易和「大規模」這個詞聯繫到一起，給人一種只有大規模才用得上平台的感覺。但其實不然，用不用得上平台的核心因素並不僅僅是數據量，而更是在於要使用機器學習的業務的多樣性。如果你的數據量很大，但是只有一個地方在使用，例如某個模塊的點擊率預估，那麼這個時候並不一定要做平台，只需要對這一個系統做充分地調優即可。但如果你想在更多的業務上使用機器學習技術的話，即使每個業務的數據量都沒有達到海量，那麼對每個業務分別走一套完整的機器學習系統流程也是成本很高的做法。這裡的成本至少包括兩個方面：開發成本和維護升級成本。

開發成本方面，因為多個業務很有可能用的都是同一套模型，甚至在樣本和特徵的採集處理流程上也會有比較大的重合，那麼就有很多東西是可以復用的，這種情況下每一套業務都做一套開發顯然就是很大的浪費。在維護升級方面，由於多個業務底層依賴的基礎特徵和模型都是類似的，那麼在這種開發模式下，對這些數據和模型的升級和維護對應的工作量也會放大好多倍，顯然也是一種浪費。這兩種成本的產生，從軟體工程的角度來說，其實就是違反了DRY原則[2]。

那麼平台化是如何解決這些問題的呢？回答這個問題之前，需要先了解在平台的模式下一個完整的機器學習流程是怎樣的。為了方便理解，我們可以使用電商平台（例如天貓、京東等）的例子來做類比。想要使用機器學習技術的業務方可以看做是想要在電商平台上開店的小商家，而機器學習平台無疑就是電商平台了。作為一個商家，如果選擇自己建網站開店，就好比每個業務自己搭建機器學習流程，顯然是一個低效的選擇。如果在電商平台上開店，平台會提供支付、訂單管理、庫存管理、店面建設、促銷管理等等核心的功能，也就是「電子商務」中「電子」的部分。而商家需要負責的，就是「電子商務」中「商務」的部分，也就是和自己業務核心相關的部分，例如選擇銷售什麼樣的商品，決定使用什麼樣的促銷策略，如何建設會員制度等等，而這其中的大部分，商家也不需要自己搭建實現，只需要通過平台提供的工具將自己的想法進行落地即可。

回到機器學習的業務中來，業務在接入平台之後，需要做的應該也僅僅是（或者說盡量是）和業務核心相關的部分，例如業務數據如何接入平台，決定使用什麼特徵，特徵之間如何組合，使用什麼樣的模型（甚至模型也不用指定）等。而具體這些特徵如何被抽取出來，和樣本形成對應關係，又是如何進入模型訓練的，訓練時使用了什麼參數配置，都是平台應該負責的東西，業務方都不用關心。如果類比「電子商務」這個詞來造一個「智能業務」的詞的話，那麼平台負責的應該是「智能」的部分，而業務方負責的應該是「業務」部分。只有做到這樣，才能讓更多的業務使用到機器學習系統，享受到這個「大殺器」帶來的便利，從而將機器學習的紅利最大化。

上面提到的兩種平台的類比關係可以用下圖來簡單表示：

構建機器學習平台的挑戰

從上面的圖可以看出，在機器學習平台的支持下，業務接入機器學習功能變得非常簡單，在理想狀況下，只需要點幾個按鈕，寫一些配置文件就夠了。但是俗話說得好：「天下沒有免費的午餐」，業務方使用起來簡單是因為將機器學習核心相關的部分都轉嫁到了平台上面，由平台來實現。所以，平檯面對的核心挑戰就是如何如何提供足夠的通用性，從而讓各個業務都能夠簡單接入，而這顯然不是一件簡單的事情。這裡面的核心挑戰包括但不限於：

不同業務數據格式和語義上的統一。不同業務涉及到的日誌數據、業務數據在存儲格式，更新方法等方面都可能存在著很大不同，這些數據從機器學習的角度來看涉及樣本和特徵兩個大的維度。作為平台方，要求各個業務方將數據使用統一的方式存儲更新顯然是不現實的，那麼就需要將通用的運算部分進行運算元層面的抽象，同時對這種強異構性的數據進行多個維度的統一處理，才能保證後續流程的統一性和高效性。
不同業務策略的統一表達語言。由於分處不同的業務領域，不同業務的策略（例如排序策略）有著不同的語言。例如商品詳情頁的推薦需要多考慮推薦商品和主商品的價格相關性，而在feed流推薦中又需要多強調時間上的新鮮性。那麼如何用一套統一的DSL[3]將這些需求進行有效的組合表達，是決定能否建成機器學習的巴別塔[4]的重要因素。這一部分要求平台設計者具有高度的抽象和總結能力，如果某個業務的需求不能方便的被這個DSL所表達，那麼這個業務就很難接入到平台中來。
多業務場景下的在線/離線實驗支持。效果評測和分流實驗是任何演算法系統中都不能缺少的部分，多業務場景下的評測和分流有著獨特的挑戰，例如實驗之間可能出現相互影響的情況，所以需要設計能夠支持多維度分層實驗的在線實驗平台[5]。而為了在不浪費流量的情況下對多個業務的策略做出評測，還需要建立一套合理的離線評測系統。

除此以外還有很多其他挑戰，這些挑戰多數都是圍繞「異質性」、「大規模」這些特點展開的。但需要指出的是，在實現一個機器學習平台的時候，上面提到的平台層的東西不一定都要自己來做，一些機器學習核心組件的部分可以充分利用一些開源工具，甚至一些開放平台來做，例如Amazon、微軟以及阿里的雲服務都提供了機器學習的組件，那麼公司內部需要實現的就是這些以外的部分，或者說是在這些平台提供的工具上再做進一步的封裝和處理。這兩者的區別，一定程度上有點像雲計算領域「公有雲」和「私有雲」之間的區別，私有雲犧牲了一定程度的通用性，但是由於只需要對企業內部服務，所以可能搭建更適合企業業務特點的架構和功能。二者孰優孰劣，還需要根據每個公司的業務特點來具體判斷。

開源的野心

從上面的討論可以看出，要想將機器學習的能力最大程度發揮，平台化可以說是必經之路，因為電商平台等其他平台的成功已經證明，只有平台才能成為技術的槓桿，將技術的能量最大化。

從這個角度再來看各個大廠為什麼爭相開源平台級框架級的工具，也就很容易理解了，因為平台和框架，既是行業的未來，一定程度上也是大廠門平台化發展的自然產物。但是開源對大廠們有什麼好處呢？只是為了學雷鋒做好事，讓世界充滿愛嗎？為了深究大廠們的心路歷程，不得不提到另一個領域的著名開源平台：安卓操作系統。

讓我們回想一下安卓操作系統誕生的背景[6]。在安卓系統誕生之前，手機領域基本是沒有太強烈的「操作系統」的概念的，一如計算機剛誕生，Windows出現之前的年代。每款手機都長不同的樣子，系統的可定製性也非常的差，智能機時代看似遙遙無期。但是這時出現了打著開源旗號的安卓系統，大家可以隨意使用，一下子讓手機行業活躍了起來，後來的故事大家都知道了，開源的安卓系統已經為谷歌賺取了310億美元的營收，220億美元的利潤，利潤率高達70%[7]。

俗話說「無利不起早」，這些開源系統以開源作為起點，但目的很有可能還是賺錢。安卓就是很好的例子，而且谷歌已經在用安卓的套路來運作TensorFlow了[8]。有了安卓的先例，相信國內外其他巨頭們也都不會放過這個機會，這也就可以解釋大家爭相開源機器學習系統的原因了。

總結展望

人工智慧的時代是否來到我們還不能確定，但是機器學習的時代的到來已經是確定無疑的。在當今的時代，對機器學習的利用程度可以看做是衡量一個組織技術先進性的一個重要指標。對平台建設和利用的重視程度一定程度上會決定一個企業的技術高度和業務效率，在這個群雄逐鹿的戰場上，有人開始默默跟耘，有人已經亮出獠牙，鹿死誰手還未可知。但無論如何，對我們這些從業者來說，都是好事，因為這說明這個行業的春天已經徹底來到。

這麼說並不是說這些細微的改進不重要，相反，當數據規模和業務規模足夠大的時候，1%的提升也會帶來很可觀的收益。這裡說的不重要意思是這通常來說不是最優先需要解決的問題。
DRY == Don』t Repeat Yourself
DSL == Domain Specific Language，可譯為「領域特定語言」，指的是為某一領域設計的語言，目的是將這一領域中的操作進行統一抽象表達。例如SQL可看做是資料庫領域的一種DSL。
據聖經記載，巴別塔指的是人類聯合起來興建希望能通往天堂的高塔。為了阻止人類的計劃，上帝讓人類說不同的語言，使人類相互之間不能溝通，計劃因此失敗。
在線實驗平台的建設可參考google的經典文章：Overlapping Experiment Infrastructure: More, Better, Faster Experimentation
筆者不是移動開發領域專家，此處的背景全憑不靠譜的記憶。
數字來源：狂賺310億美元！安卓系統的錢究竟是怎麼來的_科技_騰訊網
用「谷歌機器學習安卓」作為關鍵字去搜索，你可以得到很多相關的新聞。