小團隊撬動大資料——噹噹推薦團隊的機器學習實踐

標籤：

先說一下我的初衷。機器學習系統現在多紅多NB這件事情我已不必贅述。但是由於機器學習系統的特殊性，構建一個靠譜好用的系統卻並不是件容易的事情。每當看到同行們精彩的分享時，我都會想到，這些複雜精妙的系統，是怎樣構建起來的？構建過程是怎樣的？這背後是否有一些坑？有一些經驗？是否可以“偷”來借鑒？

所以我希望做一個更側重“面向過程”的分享，與大家分享一下我們在構建系統時的一些實踐，一些坑，以及如何從坑裡爬出來。

另外，我本次分享更側重的是“小團隊”，一是因為噹噹目前做ML的團隊確實還比較小，其次是因為據我瞭解並不是每個企業都像BAT那樣陣容龐大整齊。所以小團隊的經曆和實踐或許會有獨特的借鑒意義，希望這次分享能從不一樣的角度給大家提供一些參考。

 

今天分享的實踐經曆來自噹噹推薦組的ML小團隊。

 

我們的團隊負責噹噹推薦/廣告中機器學習系統從0開始的搭建、調優、維護和改進。除計算平台為其他團隊負責維護以外，ML pipeline中的每個環節均要負責。生產的模型用於部分推薦模組和部分廣告模組的排序。

 

分享開始之前，有必要闡明一下本次分享的定位。如所示，本次分享不涉及這些內容，對此有需求的同學可參考CSDN上其他精彩的分享。

 

上面這些，是本次分享所涉及到的，其中“面向過程”是本次的重點。分享的人群定位如下：

 

無論你處於構建機器學習系統的哪個階段，如果能從本次分享有所收穫，或者有所啟發，那筆者帶著“長假後綜合症”做的這個PPT就沒白忙活……

 

這是我們本次分享的大綱：先簡單談一下我對“小團隊”的一些認識，再花主要的時間和大家分享一下噹噹的小團隊機器學習實踐。接著我會總結一些我們實踐中猜到的坑，以及從這些坑中學到的東西。然後我會以一些參考文獻為例，做一些對未來工作和可能方向的展望。最後是問答環節。

簡論小團隊

首先談談我對小團隊的認識。

 

為什麼會出現小團隊？這個問題乍一看有點像是句廢話，因為每個團隊都是從小到大發展起來的。這沒錯，但是機器學習的團隊還是有一些屬於自己的特點的。

 

1. 相比一些功能性系統，機器學習系統的特點之一是不確定性，也就是這個系統搭起來的效果，是無法從開頭就量化的。這導致決策層在投入上比較謹慎，不會在剛開始就投入太多人。
2. 這方面人才確實比較稀缺，招聘難。簡曆看著漂亮的挺多，有實際能力或經驗的其實很少。本著寧缺毋濫的原則，小而精的團隊是一個更好的選擇。

 

 

小團隊做系統的挑戰在哪裡？這是我們關心的首要問題。小團隊挑戰的本質其實就是兩個字：人少。從這個根本限制會衍生出多個具體的挑戰。

 

1. 首先是對單兵能力的高要求。這很容易理解，人少就意味著每個人都需要發揮很大的作用，因此對單兵能力要求比較高。對於這個問題，其實沒有太多好的辦法，主要就是外部招聘和內部培養。
2. 其次是在系統開發過程中，大家一般都需要交叉負責多個任務，這既是對個人能力的挑戰，也是對協作能力挑戰。但是另一方面，這其實是對員工最好的培養，能夠讓大家以最快的速度成長。
3. 再次就是方向和需求選擇的問題。因為人少，所以在決定下一步行動時，需要非常謹慎，盡量減少無產出的投入。這有時確實是一種限制，但是換個角度來看，這“逼迫”我們把精力集中在最重要的部分，好鋼都是用在刀刃上。
4. 最後一點，就是單點風險較高。由於每個人都負責了比較多的部分，所以每個人的離職、休假等異動，都會對系統造成較大影響。這個問題同樣主要是通過內部培養和外部招聘來解決，不過還有一個方法，就是用有挑戰的事情留住人。哪種方法好使，就要看具體環境的具體情況了。

 

這樣一看，小團隊挑戰不小，但是反過來看，小團隊也有一些獨特的優勢。

 

 

1. 首先就是團隊易於凝聚。這也是任何小團隊的天然優勢。
2. 其次是易於協作。很多事情不需要開會，轉身幾句話就可以搞定。
3. 再次是迭代速度的優勢。由於流程所涉及的事情全部由少數幾個人負責，不需要協調過多的資源，那麼只要這幾個人使勁，迭代速度就會快起來。
4. 最後一點，也是非常重要的一點，就是團隊的成長。由於大家都要負責很多事情，那麼成長速度自然就會很快，同時個人的成就感也會比較高，如果調配得當，會讓整個團隊處於一種非常有活力的積極狀態。

 

噹噹推薦機器學習實踐

下面我們花一些時間來分享一下噹噹的機器學習團隊是如何撬動機器學習系統這塊大石頭的。

所示的是我們推薦背景整體架構。從上面的架構簡圖中可以看出，機器學習系統是作為一個子系統存在的，與推薦作業平台（產生推薦結果的離線作業平台）發生直接互動。

這幾個架構圖只是讓大家知道機器學習系統在在整個推薦系統中的位置和作用，不是本次分享的重點，沒必要一定看懂。

 

這一頁的架構圖是上一頁圖中紅框中部分的細節放大。可以看出，機器學習系統是在結果排序中發揮作用的。關於這個架構的細節我在這裡不做展開，感興趣的同學可參照美團的同學前段時間的分享，是比較類似的架構。

 

上面的架構圖是上一頁架構中紅框部分的進一步展開，也就是機器學習系統本身的一個架構簡圖。有經驗的同學能看出來，這張簡圖中包括了機器學習系統的主要流程組件。

後面我們會說到這一套系統是如何搭建起來的，經曆的過程是怎樣的。系統初始階段，是一個探索的階段。這個階段的意義在於，搞明白你的問題究竟是不是一個適合用ML技術解決的問題。

機器學習很厲害，但不是萬能的，尤其是某些需要強人工先驗的領域，可能不是最合適的方案，尤其不適合作為系統啟動的方案。在這個階段，我們使用的工具是R和Python。

 

上頁右側的圖中，紅色框住的部分是可以用R來解決的，藍色框住的部分是用Python更合適的，綠色框住的部分是兩者都需要。

為什麼選擇R和Python呢？

先說R。

 

1. 是因為R的全能性，堪稱資料科學界的瑞士軍刀。
2. 是因為R已經流行很多年了，屬於成熟的工具，遇到問題容易找到解決方案。
3. 當時（2013年）sklearn之類的還不夠完善好用，而且有問題也不容易找到解決方案。

 

再說Python。

 

1. Python的開發效率高，適合快速開發、迭代，當然要注意工程品質。
2. Python的文本處理能力較強，適合處理文本相關的特徵。
3. Python和Hadoop以及Spark等計算平台的結合能力較強，在資料量擴張時具有可擴充性。

 

不過，R的部分現在其實也可以用Python來替代，因為以sklearn，Pandas，Theano等為代表的工具包都已經更加成熟。

但是當過了初期探索的階段，到了大資料量的系統時，R就不再適合了。主要原因就是兩個：可處理資料量小和處理速度慢。

 

1. 第一個是因為純的R只支援單機，並且資料必須全部載入記憶體，這顯然對於大資料處理是個很明顯的障礙，不過現在的一些新技術對這一問題或許會有所緩解，但是我們沒有嘗試過。
2. 其次就是計算速度相對慢，這當然指的也是在大資料量下的速度。

 

所以，如架構圖中左邊，一旦到了大資料量階段，以Hadoop和Spark為代表的工具們就會登上舞台，成為主要使用的工具。

過了初期探索、驗證的階段後，就要進入工程迭代的步驟了。

 

的是我們開發的一個典型流程。

驗證通過之後，就進入下一個重要環節，我稱之為“全流程構建”，指的是將要構建的ML系統，以及後面的使用方，全部構建起來，形成一個完整的開發環境。

這裡需要強調的是“完整”，也就是不只是要搭建起ML模型相關的樣本、特徵、訓練等環節，後面使用模型的環節，例如排序展示等，也要一同搭建起來。關於這一點在後面還會再次提到。

如果是初次構建系統，那麼“全流程構建”將會花費比較長的時間完成。但這一步是後面所有工作的基石，投入的時間和精力都是值得的。

這個步驟完成之後，一個系統其實就已經構建好了 ，當然是一個只有型沒有神的系統，因為每個部分可能都是完全未最佳化的，而且有的部分可能是只有軀殼沒有內容。

之後就進入最佳化迭代這個“無間道”了，這部分的工作就是不斷尋找可以最佳化的點，然後嘗試各種解決方案，做線下驗證，如何覺得達到上線標準，就做線上AB。在系統流程構建起來之後，後面基本就是在不停的在這個迭代中輪迴。（無間道的本來含義是指18層地獄的第18層，寓意著受苦的無限輪迴。）

 

其實這個開發流程，特別像蓋房子的流程，先要打地基，之後建一個毛坯房，之後就是不斷裝修，各種驗工，直到可以入住。住進去一段時間可能覺得哪裡又不滿意了，或者又出現了什麼新的、更漂亮的裝修方法，那可能又會再次裝修。如此反覆。直到有一天你發財了，要換房子了，那也就是系統整體重構、升級的時候了。

 

這一頁介紹的我們使用的工具，都是一些市面上常見的主流工具，除了dmilch這套工具。

dmilch（milch為德語牛奶的意思）：Dangdang MachIne Learning toolCHain是我們在不斷迭代中總結提取出的一套特徵工程相關的工具。包含了一些特徵處理的常用工具，例如特徵正則化、歸一化，常用指標計算等。和linkedin前段時間開源出來的FeatureFu目的類似，都是為了方便特徵處理，但是角度不同。

 

這一頁介紹幾個我們在工作流程中的關鍵點。其實小團隊在這個方面是有著天然優勢的，所以我們的中心思想就是“小步快跑”。

第一個關鍵點就是改動之間的串列性。這或許是機器學習這種演算法類系統的專屬特點，多個改進一起上的話，有時就無法區分究竟是什麼因素起到了真正的作用，就像一副中藥一樣，不知道起效的是什麼，而我們希望的是能把真正的“青蒿素”提取出來。

第二點就是項目推進機制。我們大概每周會有一到兩次的會議討論，主要內容是驗證改進效果，方案討論等，併當場確認下一步的動作。

技術人員其實是不喜歡開會的，那為什麼每周還有開呢？我認為最重要的一個目的就是讓大家參與討論，共同對項目負責，共同成長。承擔的工作有分工，但是在討論時無分工，每個人都要對系統有想法，有建議。這也能確保大家互相吸收自己不熟悉的地方，更有利於成長。

還有一個不得不說的話題就是關於新技術的嘗試。如果沿用我們之前的蓋房子的例子，新技術就好比高大上的傢具擺設之類的，家裡沒個一兩件鎮宅的，都不好意思跟人打招呼。

這方面我們的經驗是，先把已有的技術吃透，用透，再說新技術，不遲。例如推薦中的協同過濾演算法，一般會在購買、瀏覽、評論、收藏等不同資料，不同維度都去加以計算，看哪個效果更好。當把熟悉的技術的價值都“榨取”幹了之後，再嘗試新技術也不遲。

還有一點很重要，就是別人的技術，未必適合你。不同公司的業務情境，資料規模，資料特點都不盡相同，對於他人提出的新技術，要謹慎採納。

我們曾經滿懷信心的嘗試過某國際大廠的某技術，但是反覆嘗試都沒有得到好的效果，反而徒增了很大的複雜性。後來和一些同行交流之後發現大家也都沒有得到好的效果。所以外國的月亮，有可能只是在外國比較圓。上什麼技術，還是要看自己系統所在的土壤適合種什麼樣的苗。

這部分結束之前我簡單介紹一下我們的模型在推薦廣告上上線後的效果：推薦首屏點擊率提升了15%~20%。廣告的點擊率提升了30%左右，RPM提升了20%左右。可以看出效果還是很明顯的。

那些年，我們踩過的坑

下面進入今天分享的下一個重要環節，那就是我們踩過的各種坑。

“前事不忘，後事之師”，坑或許是每個分享中最有價值的一部分。我們在構建系統時也踩過很多坑，在這裡和大家分享幾個我認為比較大的坑，希望對大家有所協助。我會先介紹幾個坑，之後再說一下我們從坑裡爬出來的感覺、收穫。

只見模型，不見系統。

如果要把我們踩過的坑排個名，這個坑一定是第一名。因為如果掉進了這個坑，那麼指導你系統方向的依據有可能完全是錯的。

具體來說，這個問題指的是在構建系統時，我們一開始基本只關注機器學習模型的好壞，AUC如何，NE如何，但是沒有關注這個模型到了線上的最終效果是如何。這樣做的後果是，我們覺得模型從指標等各方面來看已經非常好了，但是一上線發現完全沒有效果。因為我們忽略了模型是被如何使用的，一直在閉門造成一樣的“最佳化”模型，最後的效果自然不會好。

那正確的姿勢是怎樣的呢？從我們的經驗來看，在系統搭建的初期，就要明確地知道：你構建的不是一個模型，而是一個以模型為中心的系統。時刻要知道模型出來之後要幹什麼，要怎麼用，這種大局觀非常重要。

模型雖然是系統的中心，但不是系統的全部。在系統設計、開發、調優的各個階段，都要從系統的角度去看問題，不能眼裡只有模型，沒有系統（產品）。否則可能等你調出一個AUC=0.99的模型的時候，一抬頭髮現已經和系統越走越遠了。

所以，做機器學習系統要注意模型和系統並重，如果只看到模型而看不到系統，很可能會做出指標漂亮但是沒有實效的“花瓶系統”來。

不重視可視化分析工具

這是一個開始很容易被忽視，但是到後期會導致你很難受的一個問題（這裡指的是非深度學習的系統）。

因為機器學習系統某種程度上是個黑盒子，所以我們的精力會習慣性地集中在參數、模型這些東西上，本能地覺得模型的內部工作是不需要關心的。但是我們的經驗是，如果只關注黑盒子的外面，完全不關心裏面，那麼如果模型效果不好，那麼將很難定位到問題的所在。反過來，如果效果好了，也會有點莫名其妙，就好比你家廁所的燈忽然自己亮了，或者電視機忽然自己開了，總會讓人很不踏實。

這個問題上我們的感觸是很深的。我們最早在做系統的時候，發現效果不好，其實是沒有太多章法能夠協助定位問題的。只能是把各種特徵來回特徵，樣本處理上變一下花樣，如果效果好了，就好了，不好，接著折騰。

後來我們做了一套web頁面，上面把每條樣本、每個case的特徵及其參數，樣本的出現次數，在候選集裡的排序等等，全部展示出來。如同把整個系統加模型給做了一次解剖，希望能夠盡量多地看到系統的內部細節，對於分析問題有很大協助。

這個系統幫了我們很大的忙，雖然也不能算是“有章法”的做法，但是把很多東西呈現在你面前之後，你會發現有些東西和你想的不一樣，也會發現一些你壓根不會想到的東西。這對於機器學習這種有點像黑盒子的系統來說，尤為寶貴。到現在，這個系統是我們每次效果驗證時非常依賴的一個東西，可以說是我們的另一雙眼睛。

過於依賴演算法

這個坑相信很多同學也遇到過。我就舉一個例子吧。我們當時遇到一個文本處理的問題，要過濾掉大量無關無用的文本詞彙。一開始上了很多各種演算法，各種調優，但是遲遲得不到滿意的效果。

最後我們亮出了絕招：人肉過濾。具體說就是三個人花了三天時間純人工把文本過了一遍（幾千個上萬個詞），效果立竿見影。當時那個問題，或許是存在效果更好的演算法的，但是從系統、工程角度整體衡量一下，還是人工的ROI最高。

所以雖然機器學習是以演算法為主的系統，但是也不能思維僵化，凡事都只想著用演算法解決，有的地方，還是小米加步槍比較合適。

關鍵流程和資料沒有掌握在自己團隊

這個坑，可以說不是一個容易發現的坑，尤其是在系統初期，是比較隱形。我們也是在吃了一些虧之後才發現這個問題的。

在很多公司裡，前端展示，日誌收集等工作是有專門的團隊負責的，而諸如推薦廣告這樣的團隊是直接拿來用的。這樣做的好處很明顯，可以讓機器學習團隊專註於本職工作，但是不好的一面是，他們收集到的資料並不總是我們期望得到的。

舉個例子。我們一開始使用的曝光資料是兄弟團隊幫我們做的，但是我們拿來之後發現和其他資料不太對的上，找了很久才找到問題。這個問題直接影響到我們拿到的樣本的正確與否，所以對我們的影響非常的大。

那造成這個問題的原因是什麼呢？其實並不是兄弟團隊不認真，而是他們並不完全理解我們對資料的需求，他們也不使用該資料，所以資料的品質就會有風險。吃了這一虧之後，我們現在把這部分工作也拿來自己做，這樣資料正確與否我們可以全程監控，出了問題也可以自己內部解決，不用協調各種資源。

團隊不夠“全棧”

這個坑是一個比較複雜的坑。在上一個坑中，我提到我們發現了資料品質有問題，之後自己做了這部分曝光收集的工作。但是定位問題原因和自己接手並不是在資料一有問題的時候就做到的。原因既簡單又殘酷：我們組裡當時沒有前端人才。

因為曝光問題涉及到從瀏覽器到後台系統的一系列動作，而前端是這些動作的第一個環節。但是我們在組件機器學習團隊的時候，並沒有意識到這裡面會有前端什麼事，以為有後台+模型的人就夠了。所以導致我們面對這個問題比較無力。直到後來有一位有著豐富前端經驗的同事加入我們組，我們才定位到問題，並且做出了自己接手的決定。

這個問題給我們的教訓是：組建團隊的時候要更謹慎一些，要從更系統的角度看待，不能說做機器學習就只招演算法工程師，這樣會導致團隊級的短板，為一些問題埋下伏筆。

不過有的問題在遇到之前可能也難以預測，所以這個坑確實比較複雜。

巨型系統

最後一個坑，當然也要留給一個大坑。這個坑我稱之為“巨型系統”。

巨型系統是什麼意思呢？簡單來說，就是把整個系統做成“一個”系統，而不是分模組做成多個子系統。做成一個系統的含義就是系統內部的模組之間有著高耦合性，強關聯性，樣本、特徵、訓練、預測等等全部粘在一起，無法分離。這樣做的後果是什嗎？

直接舉例子。我們第一版的系統，光上線就上了得有一周。而且之後的維護相當困難，想改東西非常困難。為什麼會做成這樣的，我的反思是：在學習理論的時候，就想當然得把樣本、特徵、訓練這個pipeline當做一套東西了，這種思維直接反應到系統裡就是一個巨型系統。或許在你只有十幾個特徵，幾百條樣本的時候沒有問題。但是當你特徵漲到幾百萬，樣本漲到幾千萬的時候，就需要好好想一下，你的系統是不是有點大得失控了。

那更好的做法是什麼呢？我們後來的解決方案是：大系統小做。“大系統小做”這個說法不是我發明的，是今年春節後（或者是去年）看到團隊在說搶紅包系統架構時說到的一個概念。我覺得這個說法提煉得很好，表示非常贊同。這個做法的意思就是，雖然你的系統很龐大，很複雜，但是做的時候還是要做好模組分離，這樣利於開發，也利於擴充、維護。

機器學習系統的特點在於，剛開始你可能用的特徵什麼的都很少，所以覺得一個系統裡就可以搞定，但是做著做著，需要對特徵做各種變換，樣本做各種處理，系統會在不知不覺中變得龐大，而如果你只關注模型的話，很容易造出一個無法維護的巨型系統來。

萬裡長征剛起步

我們的團隊在經曆了剛剛這許多“坑”之後，一個系統可以說是搭建起來了，但是這隻是萬裡長征的第一步。對於我們如此，其實對於機器學習系統這個新事物，本身也有著不同於傳統軟體系統的諸多複雜之處，還有很多的挑戰需要去解決。我在這裡用兩篇參考文獻簡單介紹一下這些複雜之處，以及面對的挑戰。有興趣深入瞭解的同學可以找文章具體看看。

 

第一篇是Google Research的一篇paper，講的是機器學習技術債。題目也很有意思，可以翻譯為：“機器學習：高利息的技術債信用卡”。

這篇文章主要說的是機器學習系統的搭建非常地複雜，如果缺乏經驗，或者不夠謹慎，在許多環節就容易“欠債”，這些債務當時覺得影響不大，但是由於“利息”很高，到後來會讓你還起來很痛苦。

是我看了文章之後根據文章自己整理的，技術債的幾個具體維度。這幾個維度和我們自己的實踐也是高度吻合的，當時看文章也是滿膝蓋的箭。

例中右上提到的“子系統邊界模糊”，和我之前說過的“巨型系統”有類似之處，說的也是系統內部無分割。

再例如右下提到的“system-level spaghtti(系統級意大利麵)”。意大利麵代碼常用來指代亂成一團的代碼，由於機器學習系統一般都是在探索中搭建起來的，不像其他系統那樣完全設計好再搭建，所以很容易產生意大利麵代碼。

如果能在搭系統之前參照這些維度加以考慮，那麼系統的開發、升級和維護會輕鬆很多。相信這些經驗也是Google這樣的巨頭公司摔了很多坑總結出來的。巨頭尚且如此，對我們來說自然也不簡單。

 

接下來這篇文章是現在在FB的SGD大牛Leon Bottou在ICML 2015上做的一個tutorial。題目叫：Two big challenges in machine learning，是一篇比較偏系統實踐的文章，說的是機器學習面臨的兩個新的挑戰。

第一點就非常地駭人聽聞：機器學習破壞了軟體工程。但是仔細想來，確實如此。機器學習系統的開發流程大多是探索式、漸進式的，這一點和傳統的軟體工程非常不同，這就給系統開發人員們提出了挑戰。我覺得以後很可能會出現專門的“機器學習系統架構師”職位。

第二點說的是當前的實驗方式方法也遇到了極限。這一點乍一看是說科學實驗的，其實不然。機器學習系統開發由於是探索式的，所以在開發中要經常做各種實驗，驗證各種效果，這個整體方法架構，也是需要精心設計的。顯然在Bottou看來，目前的方法都不太合適。

小團隊撬動大資料——噹噹推薦團隊的機器學習實踐