為了解決大規(guī)模機(jī)器學(xué)習(xí)問(wèn)題，工業(yè)界和學(xué)習(xí)界都做了很多努力。最開(kāi)始是運(yùn)用MPI，這個(gè)相對(duì)來(lái)說(shuō)比較古老的并行接口來(lái)做大規(guī)模機(jī)器學(xué)習(xí)。MPI肯定本身還是比較靈活的，但是因?yàn)楸旧聿皇菫榇髷?shù)據(jù)、以數(shù)據(jù)為中心的計(jì)算來(lái)設(shè)計(jì)的，所以在處理做大規(guī)模機(jī)器學(xué)習(xí)的時(shí)候還是有不少問(wèn)題，首先開(kāi)發(fā)不夠友好，學(xué)習(xí)曲線(xiàn)比較高。容錯(cuò)性也比較差，如果跑一個(gè)大規(guī)模機(jī)器學(xué)習(xí)任務(wù)，跑了很久突然出問(wèn)題了就不好處理。
Hadoop興起后，很多人也嘗試用Hadoop來(lái)實(shí)現(xiàn)機(jī)器學(xué)習(xí)算法。但是很快大家認(rèn)識(shí)到在Hadoop上的MapReduce有很大的問(wèn)題，一是BSP模式，所以同步代價(jià)很大。同時(shí)要做Shuffle，網(wǎng)絡(luò)瓶頸也比較大。因?yàn)閱蝹€(gè)節(jié)點(diǎn)上的內(nèi)存限制，也不能把規(guī)模放得特別大。為了解決MapReduce，后面又提出了AllReduce，通過(guò)樹(shù)形通信來(lái)減少通信開(kāi)銷(xiāo)，這個(gè)機(jī)制在Spark里面就實(shí)現(xiàn)了。當(dāng)然還有一波人認(rèn)為MapReduce太粗了，所以就提出了Graph-Base的模型，這套模型的表達(dá)能力比較強(qiáng)、比較靈活，也可以處理比較大的模型。我個(gè)人認(rèn)為，這個(gè)模型稍微復(fù)雜了一點(diǎn)，對(duì)于開(kāi)發(fā)者來(lái)說(shuō)學(xué)習(xí)曲線(xiàn)相對(duì)高了一點(diǎn)，而且也不是對(duì)所有算法有比較好的效率。
最近幾年談到大規(guī)模機(jī)器學(xué)習(xí)的框架，經(jīng)常被提起的是Parameter Sever，它是為了解決超大規(guī)模、超大維度吸收數(shù)據(jù)的機(jī)器學(xué)習(xí)的問(wèn)題。因?yàn)樗芎?jiǎn)單，就分成了Parameter Sever和worker兩組的節(jié)點(diǎn)。Parameter Sever可以把模型分布式在各個(gè)節(jié)點(diǎn)上，每個(gè)Work去進(jìn)行算法的局部訓(xùn)練，然后同步地去跟Parameter Sever來(lái)更新模型或者獲取最新的模型。這種模式，如果是稠密數(shù)據(jù)，比如有億維度數(shù)據(jù)是密的，肯定是不可行的。為什么呢？因?yàn)橹虚g的通信會(huì)變得非常龐大。幸運(yùn)的是超大規(guī)模機(jī)器學(xué)習(xí)的問(wèn)題一般是稀疏的，所以目前Parameter Sever解決大規(guī)模機(jī)器學(xué)習(xí)最關(guān)注的一個(gè)方向。
市面上開(kāi)源的大規(guī)模機(jī)器學(xué)習(xí)的框架并不是特別多或特別成熟。比如基于Hadoop Map Reduce Mahout，有很大的問(wèn)題，效率很低。我曾經(jīng)跑過(guò)一個(gè)算法，在幾百臺(tái)機(jī)器上花了50分鐘，數(shù)據(jù)是100+G，找了大內(nèi)存機(jī)器去跑，自己寫(xiě)了一個(gè)算法5分鐘就跑完了。實(shí)際上，基于Hadoop來(lái)做機(jī)器學(xué)習(xí)的效率非常低。后來(lái)Spark出現(xiàn)了，各種機(jī)制、調(diào)度比Hadoop更加優(yōu)化一點(diǎn)。所以MLLib里面算法的效率是大大高于基于Hadoop的算法的效率。Graph-Basc有一個(gè)項(xiàng)目是Graphlab，后來(lái)基于Graphlab成立了一個(gè)公司叫Dato, 前幾個(gè)月剛改名Turi，剛剛被蘋(píng)果收購(gòu)了。Parameter Sever開(kāi)源的有ps-Lite，這個(gè)項(xiàng)目我們也做過(guò)一些調(diào)研，發(fā)現(xiàn)它總體來(lái)說(shuō)是比較輕量級(jí)的框架，但是對(duì)于實(shí)際應(yīng)用上來(lái)說(shuō)，可能還不夠完善。另外一個(gè)是Petuum，在機(jī)器學(xué)習(xí)界很多人應(yīng)該也知道它，我們現(xiàn)在也在跟他們?cè)谡勔恍┖献?，看看怎么把Petuum真正帶到實(shí)際應(yīng)用中來(lái)。
我們現(xiàn)在要反思一下，我們看到前面的大規(guī)模機(jī)器學(xué)習(xí)解決的路徑是什么？基本上是在考慮如何能夠更好地并行，提高并行的效率。然后通過(guò)增加機(jī)器，計(jì)算能力和內(nèi)存資源來(lái)解決計(jì)算的瓶頸。 但是大規(guī)模機(jī)器學(xué)習(xí)的計(jì)算瓶頸是算法本身造成的問(wèn)題，一個(gè)是計(jì)算量跟數(shù)據(jù)量的超線(xiàn)性增長(zhǎng)帶來(lái)的，一個(gè)是多次迭代帶來(lái)的。如果我們的算法能夠解決這兩個(gè)問(wèn)題，在進(jìn)行大規(guī)模機(jī)器學(xué)習(xí)的時(shí)候，對(duì)系統(tǒng)的壓力會(huì)減輕很多。我們的理想算法是什么樣子的？是線(xiàn)性算法，而且最好是迭代一次就能夠收斂并且取得很好的效果。
在這一塊，我們也做了很多的研究工作。之前我在IBM做機(jī)器學(xué)習(xí)研究的時(shí)候，看到了一個(gè)很有意思的算法，就是范偉博士在2003年提出來(lái)的隨機(jī)決策樹(shù)的算法。這個(gè)算法跟一般的決策樹(shù)或隨機(jī)決策樹(shù)有很大的不同，每一顆樹(shù)的構(gòu)建過(guò)程是完全隨機(jī)的，隨機(jī)構(gòu)建空樹(shù)以后，把數(shù)據(jù)灌進(jìn)去，然后統(tǒng)計(jì)每個(gè)節(jié)點(diǎn)的分布。預(yù)測(cè)的時(shí)候，每個(gè)樹(shù)給出一個(gè)正常的預(yù)測(cè)過(guò)程，給出一個(gè)預(yù)測(cè)的概率，然后把多顆樹(shù)的結(jié)果做平均就可以了。我在2010年對(duì)算法的復(fù)雜度做過(guò)一些分析，應(yīng)該說(shuō)這是一個(gè)線(xiàn)性的算法，計(jì)算了跟數(shù)據(jù)量增長(zhǎng)呈線(xiàn)性關(guān)系。