小團隊撬動大數(shù)據(jù)——當當推薦團隊的機器學(xué)習(xí)實踐-CSDN.NET http://www.csdn.net/article/2015-10-16/2825925

• Github項目: awesome-coder-resources：編程/學(xué)習(xí)/閱讀資源---開源項目,面試題,網(wǎng)站,書,博客,教程等等...歡迎Star,歡迎圍觀...

由于機器學(xué)習(xí)系統(tǒng)的特殊性恨憎，構(gòu)建一個靠譜好用的系統(tǒng)卻并不是件容易的事情租悄。每當看到同行們精彩的分享時哥谷，我都會想到雌芽，這些復(fù)雜精妙的系統(tǒng)猜谚，是怎樣構(gòu)建起來的败砂？構(gòu)建過程是怎樣的？這背后是否有一些坑魏铅？有一些經(jīng)驗昌犹？是否可以“偷”來借鑒？

所以我希望做一個更側(cè)重“面向過程”的分享览芳，與大家分享一下我們在構(gòu)建系統(tǒng)時的一些實踐斜姥，一些坑，以及如何從坑里爬出來沧竟。

摘要：當當個性化推薦開發(fā)經(jīng)理張相於深度分享當當推薦團隊的機器學(xué)習(xí)實踐經(jīng)驗铸敏。本次分享更側(cè)重“面向過程”——在構(gòu)建系統(tǒng)時的一些實踐，一些坑屯仗，以及如何從坑里爬出來搞坝，以及“小團隊”。
【編者按】當當個性化推薦開發(fā)經(jīng)理張相於深度分享當當推薦團隊的機器學(xué)習(xí)實踐經(jīng)驗魁袜，側(cè)重介紹一個小團隊在構(gòu)建系統(tǒng)時的一些實踐桩撮，一些坑敦第，以及如何從坑里爬出來。當當構(gòu)建機器學(xué)習(xí)系統(tǒng)過程中踩過的坑主要包括：只見模型店量，不見系統(tǒng)芜果；不重視可視化分析工具；過于依賴算法融师；關(guān)鍵流程和數(shù)據(jù)沒有掌握在自己團隊右钾；團隊不夠“全棧”旱爆；巨型系統(tǒng)舀射。工具方面，當當在探索階段選擇的是R和Python怀伦，大數(shù)據(jù)階段則主要依靠Hadoop和Spark脆烟，目前集群是幾百臺的規(guī)模。在“全流程構(gòu)建”的不斷迭代中房待，當當還總結(jié)提取出的一套特征工程相關(guān)的工具——dmilch邢羔。
先說一下我的初衷。機器學(xué)習(xí)系統(tǒng)現(xiàn)在多紅多NB這件事情我已不必贅述桑孩。但是由于機器學(xué)習(xí)系統(tǒng)的特殊性拜鹤，構(gòu)建一個靠譜好用的系統(tǒng)卻并不是件容易的事情。每當看到同行們精彩的分享時流椒，我都會想到敏簿，這些復(fù)雜精妙的系統(tǒng)，是怎樣構(gòu)建起來的镣隶？構(gòu)建過程是怎樣的极谊？這背后是否有一些坑？有一些經(jīng)驗安岂？是否可以“偷”來借鑒？
所以我希望做一個更側(cè)重“面向過程”的分享帆吻，與大家分享一下我們在構(gòu)建系統(tǒng)時的一些實踐域那，一些坑，以及如何從坑里爬出來猜煮。
另外次员，我本次分享更側(cè)重的是“小團隊”，一是因為當當目前做ML的團隊確實還比較小王带，其次是因為據(jù)我了解并不是每個企業(yè)都像BAT那樣陣容龐大整齊淑蔚。所以小團隊的經(jīng)歷和實踐或許會有獨特的借鑒意義，希望這次分享能從不一樣的角度給大家提供一些參考愕撰。

今天分享的實踐經(jīng)歷來自當當推薦組的ML小團隊刹衫。

我們的團隊負責(zé)當當推薦/廣告中機器學(xué)習(xí)系統(tǒng)從0開始的搭建醋寝、調(diào)優(yōu)、維護和改進带迟。除計算平臺為其他團隊負責(zé)維護以外音羞，ML pipeline中的每個環(huán)節(jié)均要負責(zé)。生產(chǎn)的模型用于部分推薦模塊和部分廣告模塊的排序仓犬。

分享開始之前嗅绰，有必要闡明一下本次分享的定位。如上圖所示搀继，本次分享不涉及這些內(nèi)容窘面，對此有需求的同學(xué)可參考CSDN上其他精彩的分享。

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

無論你處于構(gòu)建機器學(xué)習(xí)系統(tǒng)的哪個階段险毁，如果能從本次分享有所收獲制圈，或者有所啟發(fā)，那筆者帶著“長假后綜合癥”做的這個PPT就沒白忙活……

這是我們本次分享的大綱：先簡單談一下我對“小團隊”的一些認識畔况，再花主要的時間和大家分享一下當當?shù)男F隊機器學(xué)習(xí)實踐鲸鹦。接著我會總結(jié)一些我們實踐中猜到的坑，以及從這些坑中學(xué)到的東西跷跪。然后我會以一些參考文獻為例馋嗜，做一些對未來工作和可能方向的展望。最后是問答環(huán)節(jié)吵瞻。
簡論小團隊
首先談?wù)勎覍πF隊的認識葛菇。

為什么會出現(xiàn)小團隊？這個問題乍一看有點像是句廢話橡羞，因為每個團隊都是從小到大發(fā)展起來的眯停。這沒錯，但是機器學(xué)習(xí)的團隊還是有一些屬于自己的特點的卿泽。

相比一些功能性系統(tǒng)莺债，機器學(xué)習(xí)系統(tǒng)的特點之一是不確定性，也就是這個系統(tǒng)搭起來的效果签夭，是無法從開頭就量化的齐邦。這導(dǎo)致決策層在投入上比較謹慎，不會在剛開始就投入太多人第租。
這方面人才確實比較稀缺措拇，招聘難。簡歷看著漂亮的挺多慎宾，有實際能力或經(jīng)驗的其實很少丐吓。本著寧缺毋濫的原則浅悉，小而精的團隊是一個更好的選擇。

首先是對單兵能力的高要求苛坚。這很容易理解，人少就意味著每個人都需要發(fā)揮很大的作用色难，因此對單兵能力要求比較高泼舱。對于這個問題，其實沒有太多好的辦法枷莉，主要就是外部招聘和內(nèi)部培養(yǎng)娇昙。
其次是在系統(tǒng)開發(fā)過程中，大家一般都需要交叉負責(zé)多個任務(wù)笤妙，這既是對個人能力的挑戰(zhàn)冒掌，也是對協(xié)作能力挑戰(zhàn)。但是另一方面蹲盘，這其實是對員工最好的培養(yǎng)股毫，能夠讓大家以最快的速度成長。
再次就是方向和需求選擇的問題召衔。因為人少铃诬，所以在決定下一步行動時，需要非常謹慎苍凛，盡量減少無產(chǎn)出的投入趣席。這有時確實是一種限制，但是換個角度來看醇蝴，這“逼迫”我們把精力集中在最重要的部分宣肚，好鋼都是用在刀刃上。
最后一點悠栓，就是單點風(fēng)險較高钉寝。由于每個人都負責(zé)了比較多的部分，所以每個人的離職闸迷、休假等異動，都會對系統(tǒng)造成較大影響俘枫。這個問題同樣主要是通過內(nèi)部培養(yǎng)和外部招聘來解決腥沽，不過還有一個方法，就是用有挑戰(zhàn)的事情留住人鸠蚪。哪種方法好使今阳，就要看具體環(huán)境的具體情況了师溅。

這樣一看，小團隊挑戰(zhàn)不小盾舌，但是反過來看墓臭，小團隊也有一些獨特的優(yōu)勢。

首先就是團隊易于凝聚妖谴。這也是任何小團隊的天然優(yōu)勢窿锉。
其次是易于協(xié)作。很多事情不需要開會膝舅，轉(zhuǎn)身幾句話就可以搞定嗡载。
再次是迭代速度的優(yōu)勢。由于流程所涉及的事情全部由少數(shù)幾個人負責(zé)仍稀，不需要協(xié)調(diào)過多的資源洼滚，那么只要這幾個人使勁，迭代速度就會快起來技潘。
最后一點遥巴，也是非常重要的一點，就是團隊的成長享幽。由于大家都要負責(zé)很多事情铲掐，那么成長速度自然就會很快，同時個人的成就感也會比較高琉闪，如果調(diào)配得當迹炼，會讓整個團隊處于一種非常有活力的積極狀態(tài)。

當當推薦機器學(xué)習(xí)實踐
下面我們花一些時間來分享一下當當?shù)臋C器學(xué)習(xí)團隊是如何撬動機器學(xué)習(xí)系統(tǒng)這塊大石頭的颠毙。

這一頁的架構(gòu)圖是上一頁圖中紅框中部分的細節(jié)放大。從圖中可以看出霎奢，機器學(xué)習(xí)系統(tǒng)是在結(jié)果排序中發(fā)揮作用的户誓。關(guān)于這個架構(gòu)的細節(jié)我在這里不做展開，感興趣的同學(xué)可參照美團的同學(xué)前段時間的分享幕侠，是比較類似的架構(gòu)帝美。

上面的架構(gòu)圖是上一頁架構(gòu)中紅框部分的進一步展開，也就是機器學(xué)習(xí)系統(tǒng)本身的一個架構(gòu)簡圖晤硕。有經(jīng)驗的同學(xué)能看出來悼潭，這張簡圖中包括了機器學(xué)習(xí)系統(tǒng)的主要流程部件庇忌。
后面我們會說到這一套系統(tǒng)是如何搭建起來的，經(jīng)歷的過程是怎樣的舰褪。系統(tǒng)初始階段皆疹，是一個探索的階段。這個階段的意義在于占拍，搞明白你的問題究竟是不是一個適合用ML技術(shù)解決的問題略就。
機器學(xué)習(xí)很厲害，但不是萬能的刷喜，尤其是某些需要強人工先驗的領(lǐng)域残制，可能不是最合適的方案，尤其不適合作為系統(tǒng)啟動的方案掖疮。在這個階段初茶，我們使用的工具是R和Python。

上頁右側(cè)的圖中浊闪，紅色框住的部分是可以用R來解決的恼布，藍色框住的部分是用Python更合適的，綠色框住的部分是兩者都需要搁宾。
為什么選擇R和Python呢折汞？
先說R。

是因為R的全能性盖腿，堪稱數(shù)據(jù)科學(xué)界的瑞士軍刀爽待。
是因為R已經(jīng)流行很多年了，屬于成熟的工具翩腐，遇到問題容易找到解決方案鸟款。
當時（2013年）sklearn之類的還不夠完善好用，而且有問題也不容易找到解決方案茂卦。

再說Python何什。

Python的開發(fā)效率高，適合快速開發(fā)等龙、迭代处渣，當然要注意工程質(zhì)量。
Python的文本處理能力較強蛛砰，適合處理文本相關(guān)的特征罐栈。
Python和Hadoop以及Spark等計算平臺的結(jié)合能力較強，在數(shù)據(jù)量擴張時具有可擴展性泥畅。

不過悠瞬，R的部分現(xiàn)在其實也可以用Python來替代，因為以sklearn，Pandas浅妆，Theano等為代表的工具包都已經(jīng)更加成熟。
但是當過了初期探索的階段障癌，到了大數(shù)據(jù)量的系統(tǒng)時凌外，R就不再適合了。主要原因就是兩個：可處理數(shù)據(jù)量小和處理速度慢涛浙。

第一個是因為純的R只支持單機康辑，并且數(shù)據(jù)必須全部載入內(nèi)存，這顯然對于大數(shù)據(jù)處理是個很明顯的障礙轿亮，不過現(xiàn)在的一些新技術(shù)對這一問題或許會有所緩解疮薇，但是我們沒有嘗試過。
其次就是計算速度相對慢我注，這當然指的也是在大數(shù)據(jù)量下的速度按咒。

所以，如架構(gòu)圖中左邊但骨，一旦到了大數(shù)據(jù)量階段励七，以****Hadoop****和Spark****為代表的工具們就會登上舞臺，成為主要使用的工具奔缠。
過了初期探索掠抬、驗證的階段后，就要進入工程迭代的步驟了校哎。

其實這個開發(fā)流程，特別像蓋房子的流程帐要，先要打地基把敞，之后建一個毛坯房，之后就是不斷裝修榨惠，各種驗工奋早，直到可以入住。住進去一段時間可能覺得哪里又不滿意了赠橙，或者又出現(xiàn)了什么新的耽装、更漂亮的裝修方法，那可能又會再次裝修期揪。如此反復(fù)掉奄。直到有一天你發(fā)財了，要換房子了凤薛，那也就是系統(tǒng)整體重構(gòu)姓建、升級的時候了。

這一頁介紹的我們使用的工具缤苫，都是一些市面上常見的主流工具速兔，除了dmilch這套工具。
dmilch（milch為德語牛奶的意思）：Dangdang MachIne Learning toolCHain是我們在不斷迭代中總結(jié)提取出的一套特征工程相關(guān)的工具活玲。包含了一些特征處理的常用工具涣狗，例如特征正則化谍婉、歸一化，常用指標計算等镀钓。和linkedin前段時間開源出來的FeatureFu目的類似穗熬，都是為了方便特征處理，但是角度不同掸宛。

這一頁介紹幾個我們在工作流程中的關(guān)鍵點死陆。其實小團隊在這個方面是有著天然優(yōu)勢的，所以我們的中心思想就是“小步快跑”唧瘾。
第一個關(guān)鍵點就是改動之間的串行性。這或許是機器學(xué)習(xí)這種算法類系統(tǒng)的獨有特點别凤，多個改進一起上的話饰序，有時就無法區(qū)分究竟是什么因素起到了真正的作用，就像一副中藥一樣规哪，不知道起效的是什么求豫，而我們希望的是能把真正的“青蒿素”提取出來。
第二點就是項目推進機制诉稍。我們大概每周會有一到兩次的會議討論蝠嘉，主要內(nèi)容是驗證改進效果，方案討論等杯巨，并當場確認下一步的動作蚤告。
技術(shù)人員其實是不喜歡開會的，那為什么每周還有開呢服爷？我認為最重要的一個目的就是讓大家參與討論杜恰，共同對項目負責(zé)，共同成長仍源。承擔的工作有分工心褐，但是在討論時無分工，每個人都要對系統(tǒng)有想法笼踩，有建議逗爹。這也能確保大家互相吸收自己不熟悉的地方，更有利于成長嚎于。
還有一個不得不說的話題就是關(guān)于新技術(shù)的嘗試掘而。如果沿用我們之前的蓋房子的例子，新技術(shù)就好比高大上的家具擺設(shè)之類的匾旭，家里沒個一兩件鎮(zhèn)宅的镣屹，都不好意思跟人打招呼。
這方面我們的經(jīng)驗是价涝，先把已有的技術(shù)吃透女蜈，用透，再說新技術(shù)，不遲伪窖。例如推薦中的協(xié)同過濾算法逸寓，一般會在購買、瀏覽覆山、評論竹伸、收藏等不同數(shù)據(jù)，不同維度都去加以計算簇宽，看哪個效果更好勋篓。當把熟悉的技術(shù)的價值都“榨取”干了之后，再嘗試新技術(shù)也不遲魏割。
還有一點很重要譬嚣，就是別人的技術(shù)，未必適合你钞它。不同公司的業(yè)務(wù)場景拜银，數(shù)據(jù)規(guī)模，數(shù)據(jù)特點都不盡相同遭垛，對于他人提出的新技術(shù)尼桶，要慎重采納。
我們曾經(jīng)滿懷信心的嘗試過某國際大廠的某技術(shù)锯仪，但是反復(fù)嘗試都沒有得到好的效果泵督，反而徒增了很大的復(fù)雜性。后來和一些同行交流之后發(fā)現(xiàn)大家也都沒有得到好的效果卵酪。所以外國的月亮幌蚊，有可能只是在外國比較圓。上什么技術(shù)溃卡，還是要看自己系統(tǒng)所在的土壤適合種什么樣的苗溢豆。
這部分結(jié)束之前我簡單介紹一下我們的模型在推薦廣告上上線后的效果：推薦首屏點擊率提升了15%~20%。廣告的點擊率提升了30%左右瘸羡，RPM提升了20%左右漩仙。可以看出效果還是很明顯的犹赖。
那些年队他，我們踩過的坑
下面進入今天分享的下一個重要環(huán)節(jié)，那就是我們踩過的各種坑峻村。
“前事不忘麸折，后事之師”，坑或許是每個分享中最有價值的一部分粘昨。我們在構(gòu)建系統(tǒng)時也踩過很多坑垢啼，在這里和大家分享幾個我認為比較大的坑窜锯，希望對大家有所幫助。我會先介紹幾個坑芭析，之后再說一下我們從坑里爬出來的感覺锚扎、收獲。
只見模型馁启，不見系統(tǒng)驾孔。
如果要把我們踩過的坑排個名，這個坑一定是第一名惯疙。因為如果掉進了這個坑翠勉，那么指導(dǎo)你系統(tǒng)方向的依據(jù)有可能完全是錯的积糯。
具體來說轨淌，這個問題指的是在構(gòu)建系統(tǒng)時正压，我們一開始基本只關(guān)注機器學(xué)習(xí)模型的好壞边苹，AUC如何，NE如何踏枣，但是沒有關(guān)注這個模型到了線上的最終效果是如何。這樣做的后果是，我們覺得模型從指標等各方面來看已經(jīng)非常好了酥郭，但是一上線發(fā)現(xiàn)完全沒有效果。因為我們忽略了模型是被如何使用的愿吹，一直在閉門造成一樣的“優(yōu)化”模型不从，最后的效果自然不會好。
那正確的姿勢是怎樣的呢犁跪？從我們的經(jīng)驗來看椿息，在系統(tǒng)搭建的初期，就要明確地知道：你構(gòu)建的不是一個模型坷衍，而是一個以模型為中心的系統(tǒng)寝优。時刻要知道模型出來之后要干什么，要怎么用枫耳，這種大局觀非常重要乏矾。
模型雖然是系統(tǒng)的中心，但不是系統(tǒng)的全部迁杨。在系統(tǒng)設(shè)計钻心、開發(fā)、調(diào)優(yōu)的各個階段铅协，都要從系統(tǒng)的角度去看問題捷沸，不能眼里只有模型，沒有系統(tǒng)（產(chǎn)品）狐史。否則可能等你調(diào)出一個AUC=0.99的模型的時候痒给，一抬頭發(fā)現(xiàn)已經(jīng)和系統(tǒng)越走越遠了说墨。
所以，做機器學(xué)習(xí)系統(tǒng)要注意模型和系統(tǒng)并重侈玄，如果只看到模型而看不到系統(tǒng)婉刀，很可能會做出指標漂亮但是沒有實效的“花瓶系統(tǒng)”來。
不重視可視化分析工具
這是一個開始很容易被忽視序仙，但是到后期會導(dǎo)致你很難受的一個問題（這里指的是非深度學(xué)習(xí)的系統(tǒng)）突颊。
因為機器學(xué)習(xí)系統(tǒng)某種程度上是個黑盒子，所以我們的精力會習(xí)慣性地集中在參數(shù)潘悼、模型這些東西上律秃，本能地覺得模型的內(nèi)部工作是不需要關(guān)心的。但是我們的經(jīng)驗是治唤，如果只關(guān)注黑盒子的外面棒动，完全不關(guān)心里面，那么如果模型效果不好宾添，那么將很難定位到問題的所在船惨。反過來，如果效果好了缕陕，也會有點莫名其妙粱锐，就好比你家?guī)臒艉鋈蛔约毫亮耍蛘唠娨暀C忽然自己開了扛邑，總會讓人很不踏實怜浅。
這個問題上我們的感觸是很深的。我們最早在做系統(tǒng)的時候蔬崩，發(fā)現(xiàn)效果不好恶座，其實是沒有太多章法能夠幫助定位問題的。只能是把各種特征來回特征沥阳，樣本處理上變一下花樣跨琳，如果效果好了，就好了沪袭，不好湾宙，接著折騰。
后來我們做了一套web頁面冈绊，上面把每條樣本侠鳄、每個case的特征及其參數(shù)，樣本的出現(xiàn)次數(shù)死宣，在候選集里的排序等等伟恶，全部展示出來。如同把整個系統(tǒng)加模型給做了一次解剖毅该，希望能夠盡量多地看到系統(tǒng)的內(nèi)部細節(jié)博秫，對于分析問題有很大幫助潦牛。
這個系統(tǒng)幫了我們很大的忙，雖然也不能算是“有章法”的做法挡育，但是把很多東西呈現(xiàn)在你面前之后巴碗，你會發(fā)現(xiàn)有些東西和你想的不一樣，也會發(fā)現(xiàn)一些你壓根不會想到的東西即寒。這對于機器學(xué)習(xí)這種有點像黑盒子的系統(tǒng)來說橡淆，尤為寶貴。到現(xiàn)在母赵，這個系統(tǒng)是我們每次效果驗證時非常依賴的一個東西逸爵，可以說是我們的另一雙眼睛。
過于依賴算法
這個坑相信很多同學(xué)也遇到過凹嘲。我就舉一個例子吧师倔。我們當時遇到一個文本處理的問題，要過濾掉大量無關(guān)無用的文本詞匯周蹭。一開始上了很多各種算法趋艘，各種調(diào)優(yōu)，但是遲遲得不到滿意的效果凶朗。
最后我們亮出了絕招：人肉過濾致稀。具體說就是三個人花了三天時間純?nèi)斯ぐ盐谋具^了一遍（幾千個上萬個詞），效果立竿見影俱尼。當時那個問題，或許是存在效果更好的算法的萎攒，但是從系統(tǒng)遇八、工程角度整體衡量一下，還是人工的ROI最高耍休。
所以雖然機器學(xué)習(xí)是以算法為主的系統(tǒng)刃永，但是也不能思維僵化，凡事都只想著用算法解決羊精，有的地方斯够，還是小米加步槍比較合適。
關(guān)鍵流程和數(shù)據(jù)沒有掌握在自己團隊
這個坑喧锦，可以說不是一個容易發(fā)現(xiàn)的坑读规，尤其是在系統(tǒng)初期，是比較隱蔽的燃少。我們也是在吃了一些虧之后才發(fā)現(xiàn)這個問題的束亏。
在很多公司里，前端展示阵具，日志收集等工作是有專門的團隊負責(zé)的碍遍，而諸如推薦廣告這樣的團隊是直接拿來用的定铜。這樣做的好處很明顯，可以讓機器學(xué)習(xí)團隊專注于本職工作怕敬，但是不好的一面是揣炕，他們收集到的數(shù)據(jù)并不總是我們期望得到的。
舉個例子东跪。我們一開始使用的曝光數(shù)據(jù)是兄弟團隊幫我們做的畸陡，但是我們拿來之后發(fā)現(xiàn)和其他數(shù)據(jù)不太對的上，找了很久才找到問題越庇。這個問題直接影響到我們拿到的樣本的正確與否罩锐，所以對我們的影響非常的大。
那造成這個問題的原因是什么呢卤唉？其實并不是兄弟團隊不認真涩惑，而是他們并不完全理解我們對數(shù)據(jù)的需求，他們也不使用該數(shù)據(jù)桑驱，所以數(shù)據(jù)的質(zhì)量就會有風(fēng)險竭恬。吃了這一虧之后，我們現(xiàn)在把這部分工作也拿來自己做熬的，這樣數(shù)據(jù)正確與否我們可以全程監(jiān)控痊硕，出了問題也可以自己內(nèi)部解決，不用協(xié)調(diào)各種資源押框。
團隊不夠“全棽沓瘢”
這個坑是一個比較復(fù)雜的坑。在上一個坑中橡伞，我提到我們發(fā)現(xiàn)了數(shù)據(jù)質(zhì)量有問題盒揉，之后自己做了這部分曝光收集的工作。但是定位問題原因和自己接手并不是在數(shù)據(jù)一有問題的時候就做到的兑徘。原因既簡單又殘酷：我們組里當時沒有前端人才刚盈。
因為曝光問題涉及到從瀏覽器到后臺系統(tǒng)的一系列動作，而前端是這些動作的第一個環(huán)節(jié)挂脑。但是我們在組件機器學(xué)習(xí)團隊的時候藕漱，并沒有意識到這里面會有前端什么事，以為有后臺+模型的人就夠了崭闲。所以導(dǎo)致我們面對這個問題比較無力肋联。直到后來有一位有著豐富前端經(jīng)驗的同事加入我們組，我們才定位到問題刁俭，并且做出了自己接手的決定牺蹄。
這個問題給我們的教訓(xùn)是：組建團隊的時候要更謹慎一些，要從更系統(tǒng)的角度看待薄翅，不能說做機器學(xué)習(xí)就只招算法工程師沙兰，這樣會導(dǎo)致團隊級的短板氓奈，為一些問題埋下伏筆。
不過有的問題在遇到之前可能也難以預(yù)測鼎天，所以這個坑確實比較復(fù)雜舀奶。
巨型系統(tǒng)
最后一個坑，當然也要留給一個大坑斋射。這個坑我稱之為“巨型系統(tǒng)”育勺。
巨型系統(tǒng)是什么意思呢？簡單來說罗岖，就是把整個系統(tǒng)做成“一個”系統(tǒng)涧至，而不是分模塊做成多個子系統(tǒng)。做成一個系統(tǒng)的含義就是系統(tǒng)內(nèi)部的模塊之間有著高耦合性桑包，強關(guān)聯(lián)性南蓬，樣本、特征哑了、訓(xùn)練赘方、預(yù)測等等全部粘在一起，無法分離弱左。這樣做的后果是什么窄陡？
直接舉例子。我們第一版的系統(tǒng)拆火，光上線就上了得有一周跳夭。而且之后的維護相當困難，想改東西非常困難们镜。為什么會做成這樣的优妙，我的反思是：在學(xué)習(xí)理論的時候，就想當然得把樣本憎账、特征、訓(xùn)練這個pipeline當做一套東西了卡辰，這種思維直接反應(yīng)到系統(tǒng)里就是一個巨型系統(tǒng)胞皱。或許在你只有十幾個特征九妈，幾百條樣本的時候沒有問題反砌。但是當你特征漲到幾百萬，樣本漲到幾千萬的時候萌朱，就需要好好想一下宴树，你的系統(tǒng)是不是有點大得失控了。
那更好的做法是什么呢晶疼？我們后來的解決方法是：大系統(tǒng)小做酒贬∮趾“大系統(tǒng)小做”這個說法不是我發(fā)明的，是今年春節(jié)后（或者是去年）看到微信團隊在說搶紅包系統(tǒng)架構(gòu)時說到的一個概念锭吨。我覺得這個說法提煉得很好蠢莺，表示非常贊同。這個做法的意思就是零如，雖然你的系統(tǒng)很龐大躏将，很復(fù)雜，但是做的時候還是要做好模塊分離考蕾，這樣利于開發(fā)祸憋，也利于擴展、維護肖卧。
機器學(xué)習(xí)系統(tǒng)的特點在于蚯窥，剛開始你可能用的特征什么的都很少，所以覺得一個系統(tǒng)里就可以搞定喜命，但是做著做著沟沙，需要對特征做各種變換，樣本做各種處理壁榕，系統(tǒng)會在不知不覺中變得龐大矛紫，而如果你只關(guān)注模型的話，很容易造出一個無法維護的巨型系統(tǒng)來牌里。
萬里長征剛起步
我們的團隊在經(jīng)歷了剛剛這許多“坑”之后颊咬，一個系統(tǒng)可以說是搭建起來了，但是這只是萬里長征的第一步牡辽。對于我們?nèi)绱嗽鋵崒τ跈C器學(xué)習(xí)系統(tǒng)這個新事物，本身也有著不同于傳統(tǒng)軟件系統(tǒng)的諸多復(fù)雜之處态辛，還有很多的挑戰(zhàn)需要去解決麸澜。我在這里用兩篇參考文獻簡單介紹一下這些復(fù)雜之處，以及面對的挑戰(zhàn)奏黑。有興趣深入了解的同學(xué)可以找文章具體看看炊邦。

第一篇是Google Research****的一篇paper****，講的是機器學(xué)習(xí)技術(shù)債熟史。題目也很有意思馁害，可以翻譯為：“機器學(xué)習(xí)：高利息的技術(shù)債信用卡”。
這篇文章主要說的是機器學(xué)習(xí)系統(tǒng)的搭建非常地復(fù)雜蹂匹，如果缺乏經(jīng)驗碘菜，或者不夠謹慎，在許多環(huán)節(jié)就容易“欠債”，這些債務(wù)當時覺得影響不大忍啸，但是由于“利息”很高仰坦，到后來會讓你還起來很痛苦。
上圖是我看了文章之后根據(jù)文章自己整理的吊骤，技術(shù)債的幾個具體維度缎岗。這幾個維度和我們自己的實踐也是高度吻合的，當時看文章也是滿膝蓋的箭白粉。
例如圖中右上提到的“子系統(tǒng)邊界模糊”传泊，和我之前說過的“巨型系統(tǒng)”有類似之處，說的也是系統(tǒng)內(nèi)部無分割鸭巴。
再例如右下提到的“system-level spaghtti(系統(tǒng)級意大利面)”眷细。意大利面代碼常用來指代亂成一團的代碼，由于機器學(xué)習(xí)系統(tǒng)一般都是在探索中搭建起來的鹃祖，不像其他系統(tǒng)那樣完全設(shè)計好再搭建溪椎，所以很容易產(chǎn)生意大利面代碼。
如果能在搭系統(tǒng)之前參照這些維度加以考慮恬口，那么系統(tǒng)的開發(fā)校读、升級和維護會輕松很多。相信這些經(jīng)驗也是Google這樣的巨頭公司摔了很多坑總結(jié)出來的祖能。巨頭尚且如此歉秫，對我們來說自然也不簡單。

接下來這篇文章是現(xiàn)在在FB****的SGD****大牛Leon Bottou****在ICML 2015****上做的一個tutorial养铸。題目叫：Two big challenges in machine learning雁芙，是一篇比較偏系統(tǒng)實踐的文章，說的是機器學(xué)習(xí)面臨的兩個新的挑戰(zhàn)钞螟。
第一點就非常地駭人聽聞：機器學(xué)習(xí)破壞了軟件工程兔甘。但是仔細想來，確實如此鳞滨。機器學(xué)習(xí)系統(tǒng)的開發(fā)流程大多是探索式洞焙、漸進式的，這一點和傳統(tǒng)的軟件工程非常不同拯啦，這就給系統(tǒng)開發(fā)者們提出了挑戰(zhàn)澡匪。我覺得以后很可能會出現(xiàn)專門的“機器學(xué)習(xí)系統(tǒng)架構(gòu)師”職位。
第二點說的是當前的實驗方式方法也遇到了極限提岔。這一點乍一看是說科學(xué)實驗的，其實不然笋敞。機器學(xué)習(xí)系統(tǒng)開發(fā)由于是探索式的碱蒙，所以在開發(fā)中要經(jīng)常做各種實驗，驗證各種效果，這個整體方法框架赛惩，也是需要精心設(shè)計的哀墓。顯然在Bottou看來，目前的方法都不太合適喷兼。