今天我會(huì)簡單介紹一下Twitter機(jī)器學(xué)習(xí)平臺(tái)的設(shè)計(jì)與搭建,也希望從規(guī);瘷C(jī)器學(xué)習(xí)平臺(tái)的角度來主要講一些我們在這個(gè)過程中所遇到的各種坑,以及我們做的各種的努力,也希望能對大家有一點(diǎn)用處。
咱們今天下午的專題是“大數(shù)據(jù)”專題,機(jī)器學(xué)習(xí)和大數(shù)據(jù)是密不可分的。如果我們將數(shù)據(jù)比作一座金礦,機(jī)器學(xué)習(xí)就是挖掘金礦的工具。俗話說:順勢而為。那么機(jī)器學(xué)習(xí)在近些年來也是發(fā)展越來越好,應(yīng)用越來越廣,我認(rèn)為主要得益于以下幾個(gè)趨勢:
1. Data Availability
我們可以獲得的數(shù)據(jù)量越來越大,一會(huì)在下一張slide中也會(huì)講到如果數(shù)據(jù)量越大,我們模型的質(zhì)量會(huì)有顯著提高;
2. Computation Power越來越強(qiáng)
比如最近出現(xiàn)的云計(jì)算、GPU、TPU等等。在上世紀(jì)九十年代其實(shí)神經(jīng)網(wǎng)絡(luò)的理論就已經(jīng)有了,也就是深度學(xué)習(xí)的這些理論已經(jīng)有了,但是當(dāng)時(shí)并沒有火起來,甚至一度被學(xué)術(shù)界認(rèn)為這是一個(gè)沒有前途的方向,就是因?yàn)楫?dāng)時(shí)這個(gè)computation power沒有到位。
隨著近些年來這些方面的不斷提高,使得我們可以訓(xùn)練更復(fù)雜的模型。大家都知道如果你沒有太多的數(shù)據(jù)或者computation power不夠多,則只能在一個(gè)小數(shù)據(jù)集上做訓(xùn)練,如果模型非常復(fù)雜就會(huì)出現(xiàn)過度擬合(Overfit)。所以只有當(dāng)我們把這些問題全都克服之后,我們才可以訓(xùn)練更復(fù)雜的模型,得到一些更好的結(jié)果;
3. Development in Algorithms
整個(gè)算法的發(fā)展,會(huì)有無數(shù)機(jī)器學(xué)習(xí)的研究者,他們不斷地去push the boundary of machine learning。
從大數(shù)據(jù)和模型的表現(xiàn)關(guān)系來看,在十幾年前有兩個(gè)研究者他們將當(dāng)時(shí)幾個(gè)機(jī)器學(xué)習(xí)比較常用的算法,在一個(gè)具體的機(jī)器學(xué)習(xí)的問題上做了一個(gè)實(shí)驗(yàn):
這張圖的橫軸是數(shù)據(jù)量,即訓(xùn)練數(shù)據(jù)的數(shù)據(jù)量,它是一個(gè)指數(shù)的規(guī)模(Scale)。最左邊的刻度應(yīng)該是10萬個(gè)數(shù)據(jù)點(diǎn)、100萬個(gè)數(shù)據(jù)點(diǎn)和1000萬個(gè)數(shù)據(jù)點(diǎn)以此類推;縱軸是模型的表現(xiàn),即訓(xùn)練出來模型的質(zhì)量。
大家可以非常清楚地在圖中看到,當(dāng)數(shù)據(jù)量很小的時(shí)候,例如10萬個(gè)數(shù)據(jù)點(diǎn)時(shí)這幾個(gè)算法的質(zhì)量非常差,當(dāng)數(shù)據(jù)量逐漸增大的時(shí)候,模型的質(zhì)量顯著地提高,而且任何一個(gè)算法在大數(shù)據(jù)量時(shí)的表現(xiàn)都比任何一個(gè)算法在小數(shù)據(jù)級(jí)的表現(xiàn)下要好很多。當(dāng)然這是在某一個(gè)具體的機(jī)器學(xué)習(xí)問題上面做的實(shí)驗(yàn),但是我覺得它有一定的推廣價(jià)值。它給我們的啟示是:如果機(jī)器學(xué)習(xí)的平臺(tái)架構(gòu)不夠規(guī);荒茉谛(shù)據(jù)級(jí)上做訓(xùn)練,哪怕你算法做得再好也是徒勞,不如先解決規(guī)模化的問題,先在大數(shù)據(jù)上能夠做這樣一個(gè)訓(xùn)練,然后在算法上再做提高。
說到Twitter,機(jī)器學(xué)習(xí)在Twitter是非常重要的。我們有內(nèi)部的研究表明:大概80%的DAU都是直接和機(jī)器學(xué)習(xí)相關(guān)產(chǎn)品相關(guān)的,90%的營收來源于廣告,而廣告完全是由機(jī)器學(xué)習(xí)來支持的。我們現(xiàn)在做的機(jī)器學(xué)習(xí)平臺(tái)支持了Twitter很核心的業(yè)務(wù),包括:
-
timeline ranking(feed ranking);
Twitter的機(jī)器學(xué)習(xí)規(guī)模也非常大,我們拿廣告來舉例子,每天在Twitter大概是做10個(gè)trillion量級(jí)的廣告預(yù)測,每個(gè)模型的weights個(gè)數(shù)大概是10個(gè)million的量級(jí),每個(gè)training example大概是有幾千到1萬個(gè)features,每一個(gè)數(shù)據(jù)點(diǎn)上有這么多,整個(gè)Feature Space大概是百億的量級(jí),訓(xùn)練的數(shù)據(jù)也是TB量級(jí),所以大家可以看到對機(jī)器學(xué)習(xí)平臺(tái)的挑戰(zhàn)是非常大的。
機(jī)器學(xué)習(xí)在Twitter有比較獨(dú)特的一點(diǎn)是Realtime(實(shí)時(shí)性),Twitter本身的產(chǎn)品非常的realtime,Twitter is all about realtime,like news、events、videos、trends,比如大家去Twitter上更多地是更新自己的狀態(tài),或者是看一些新聞,去了解一些最新的動(dòng)態(tài);廣告商也會(huì)根據(jù)產(chǎn)品的特點(diǎn)去投放一些廣告,他們往往投放的廣告持續(xù)的時(shí)間都非常短,比如就是一個(gè)事件,如NBA總決賽,三個(gè)小時(shí)內(nèi)做一個(gè)廣告投放,所以要求我們機(jī)器學(xué)習(xí)的模型就必須根據(jù)實(shí)時(shí)的traffic的情況來不斷地做調(diào)整和變化。否則,如果我們每天訓(xùn)練和更新一次模型,這樣的速度就實(shí)在是太慢了,所以我們也是投入非常多精力做了一個(gè)規(guī);脑诰學(xué)習(xí)的系統(tǒng)。你在Twitter上點(diǎn)擊任何一個(gè)廣告,那么在百毫秒的量級(jí)的延遲內(nèi),我們的模型就會(huì)更新。
下面我簡單地過一下機(jī)器學(xué)習(xí)在Twitter上幾個(gè)具體的產(chǎn)品應(yīng)用。
1. Ads Ranking
它的具體問題是當(dāng)你上了Twitter,我后面有1千個(gè)或者1萬個(gè)廣告可以展示給你,我到底展示哪個(gè)廣告給你你最可能感興趣?因?yàn)門witter采取的是CPC(Cost Per Click) Model,只有你點(diǎn)擊了廣告,廣告商才會(huì)給我們錢,如果你只是看了廣告,不感興趣沒有點(diǎn),廣告商是不會(huì)給我們錢的,所以選取最合適的廣告不光是給用戶更好的用戶體驗(yàn),同時(shí)也是Twitter盈利的關(guān)鍵;
2. Timeline Ranking(Feed Ranking)
將你的時(shí)間軸進(jìn)行排序,把最好的Tweet能放在比較靠上的位置,這樣容易被看得到;
3. Recommendation
推薦你可能最感興趣的人;
4. Anti-Spam
比如抓僵尸粉,或者是Abuse Detection,例如大家在Twitter上罵起來了,要做一些檢測并且把它隱藏掉,還有NSFW Detection基本上是鑒別一些黃色圖片之類的。
大家也可以看到,機(jī)器學(xué)習(xí)平臺(tái)面臨的挑戰(zhàn)其實(shí)主要是規(guī);奶魬(zhàn)。規(guī);艺J(rèn)為主要是兩方面:
-
一方面是組織架構(gòu)上的規(guī);,我們作為機(jī)器學(xué)習(xí)平臺(tái)的組如何更好地去支持這樣七八個(gè)Twitter的核心產(chǎn)品,并且能夠讓我們的client team(我們的用戶)能夠非?斓剡M(jìn)行prototype(產(chǎn)品迭代);
-
另一方面是整個(gè)系統(tǒng)的規(guī);阂环矫婺愕碾x線訓(xùn)練如何能更快,在線預(yù)測如何能夠更快;還有一方面,當(dāng)我們的用戶把整個(gè)pipeline搭建起來之后,他們要不斷優(yōu)化整個(gè)pipeline,我們有沒有足夠的工具支持我們這些用戶做到這一點(diǎn)(我說的用戶是Twitter內(nèi)部的這些產(chǎn)品團(tuán)隊(duì))。我們怎么讓我們的用戶非?焖俚剡M(jìn)行迭代和實(shí)驗(yàn)?
一、組織結(jié)構(gòu)的規(guī);
我們相信我們的用戶真正了解他們具體做的事情、他們的產(chǎn)品和他們的問題,所以我們采取的合作模式是:
我們開發(fā)各種的工具、很多的框架,去定義feature(特征)、transform(變換)、model(模型)等等的格式,然后把工具交給我們的用戶,讓他們從特征提取到離線訓(xùn)練、如果這個(gè)模型好再推到在線生產(chǎn)環(huán)境當(dāng)中、以至后面持續(xù)不斷地優(yōu)化提高,在整個(gè)過程中我們希望把每一步都做到足夠的簡便。同時(shí)我們還對于一些新的用戶提供一些onboarding的支持;
我們的client team負(fù)責(zé)做特征提取的,因?yàn)橹挥兴麄兞私饩唧w的自己的問題,知道什么樣的信號(hào)可以對他們的問題有更好的提升。
我們也會(huì)把整個(gè)特征的共享做到非常好,比如其他team有一個(gè)很好的特征,你可以非?斓丶尤肽愕哪P椭羞M(jìn)行實(shí)驗(yàn)。同時(shí)我們的client team他們負(fù)責(zé)去own和maintain training pipeline和serving runtime,例如on call完全不是我們的事,完全由client team來做;
二、系統(tǒng)的規(guī)模化
主要分幾個(gè)方面:
1. 準(zhǔn)備數(shù)據(jù),既然要進(jìn)行模型訓(xùn)練當(dāng)然要把數(shù)據(jù)準(zhǔn)備好;
2. 離線的訓(xùn)練,會(huì)有workflow management;
3. Online Serving(在線服務(wù)),比如模型訓(xùn)練好了,要推到市場環(huán)境中去,要可以承受這種high QPS、low latency這些要求,還要做A/B testing,在1%的數(shù)據(jù)上先做一些實(shí)驗(yàn),然后過一段時(shí)間,真正它在實(shí)際的traffic上更好的話我們就把它launch到100%。與此同時(shí)還做很多工具,來幫助我們的用戶更好地去理解他們的數(shù)據(jù)和模型,以及還有一些工具去做比如參數(shù)的掃描、特征的選擇等等。
三、準(zhǔn)備數(shù)據(jù)
首先,我們要做的是統(tǒng)一數(shù)據(jù)格式,定義一個(gè)數(shù)據(jù)格式很簡單,但是我覺得意義非常重大,就像秦始皇統(tǒng)一六國以后先統(tǒng)一度量衡,因?yàn)橹挥写蠹矣靡粯拥母袷酱蠹也拍鼙舜嘶ハ鄿贤、交流和分享?/div>
舉個(gè)例子:比如某個(gè)產(chǎn)品團(tuán)隊(duì)在他們在模型中加了某一種信號(hào)或特征,結(jié)果特別好,我是做廣告的,我想把數(shù)據(jù)拿過來用,如果數(shù)據(jù)的格式都不一樣,我還得過去去研究你們這個(gè)組的數(shù)據(jù)格式到底是什么樣子的,我們怎么轉(zhuǎn)換成我們的格式,有非常非常多時(shí)間浪費(fèi)在這個(gè)地方,這是我們希望解決的,Enable feature sharing across teams and make machine-learning platform iteration very easy.
我們的特征向量的格式,其實(shí)本質(zhì)上是feature identifier to feature value mapping,它支持4種dense types:
2種sparse feature types:
為了去優(yōu)化效率,我們feature identifier是用64位feature id存的,這個(gè)feature id是feature name的一個(gè)hash。之所以這樣去做,是因?yàn)槿绻阍谟?xùn)練的過程或者在你的生產(chǎn)環(huán)境中,你去操作很多個(gè)string的話,特別費(fèi)CPU,所以我們采取的方式是使用feature id,而在別的地方存一個(gè)feature id to feature name的mapping。比如我們存在數(shù)據(jù)倉庫中的數(shù)據(jù)都是feature id的,但是每個(gè)機(jī)器學(xué)習(xí)的數(shù)據(jù)集旁邊我們都會(huì)存一個(gè)metadata,就是feature id to feature name的mapping。
說到數(shù)據(jù)準(zhǔn)備,大家可以想象一下:如果讓一個(gè)數(shù)據(jù)科學(xué)家用語言描述怎么樣準(zhǔn)備他的數(shù)據(jù),往往這個(gè)數(shù)據(jù)科學(xué)家在非常短的時(shí)間比如1分鐘時(shí)間之內(nèi)就可以描述清楚:比如我們把這個(gè)production中scribe的數(shù)據(jù)拿過來,然后和另外一個(gè)數(shù)據(jù)集做join,然后做一些sampling和transform,然后寫到persistent storage里面去。
我們開發(fā)了一套DataAPI,對機(jī)器學(xué)習(xí)的數(shù)據(jù)集以及數(shù)據(jù)集的操作在很高的層次上做的一些抽象,當(dāng)你用我們這一套API去描述你想對數(shù)據(jù)進(jìn)行操作過程時(shí),這個(gè)代碼就跟你描述出來你要做什么事情和我們期望達(dá)到的效果一樣的簡單,我們希望這使得我們大部分的machine-learning task在訓(xùn)練過程中的數(shù)據(jù)準(zhǔn)備都能夠通過20行或者30行代碼就搞定。
它是基于Scala的API,一個(gè)fluent的interface,并且在整個(gè)過程中去保證我們的數(shù)據(jù)正確,以及剛才我們說的feature id to feature name mapping的metadata是keep consistency。之后我們簡單看一小段代碼,舉一個(gè)例子來讓大家感受一下,這是用Scala寫的,看這個(gè)代碼的話,其實(shí)從代碼上你完全就能明白我要做一件怎樣的事情:
首先我是從FeatureSource里面讀出了我機(jī)器學(xué)習(xí)里的數(shù)據(jù)集,并存在了tweetTopic這樣一個(gè)變量里,然后我再從另外一個(gè)地方,從我的一個(gè)input path里讀出另外一個(gè)數(shù)據(jù)集,并且把他filter/sample by 10% randomly,然后 用我給定的discretizer來進(jìn)行transform,然后把它和我剛才的tweetTopic數(shù)據(jù)集進(jìn)行join,它們的join key是tweet id,并且使用的是LeftJoin,最后我再把這個(gè)數(shù)據(jù)集寫出去,這樣我整個(gè)過程就準(zhǔn)備好了。
其實(shí)讀一下代碼你會(huì)發(fā)現(xiàn)整個(gè)代碼其實(shí)是非常好懂的,在寫代碼的過程其實(shí)就像在描述。我們的目標(biāo)就是希望算法工程師在寫這個(gè)代碼的時(shí)候就像描述他們想做的事情一樣。比如我們對數(shù)據(jù)的位置、格式等進(jìn)行抽象。不管你的數(shù)據(jù)到底在哪里,比如你的數(shù)據(jù)可以在hdfs上,可以在database里,可以在很多其他地方,但是在這個(gè)API里,其實(shí)都抽象在FeatureSource里,然后用read就可以把它讀出來,所以用戶在使用的時(shí)候是不需要操心數(shù)據(jù)到底存在哪里等等這類事情。
四、Trainer
我們也提供了很多的trainer,讓我們的用戶把這些trainer進(jìn)行一定的組合作為他們的offline training pipeline。首先是large scale logistic regression learner,我們有兩個(gè)解決方案:
1. Vowpal Wabbit
是John Langford開源的C++ trainer;
2. Lolly
是Twitter內(nèi)部開發(fā)的基于JVM的online learning trainer,因?yàn)門witter整個(gè)stack(技術(shù)棧)都是基于JVM的,比如Java、Scala,所以我們開發(fā)了這個(gè)learner會(huì)和Twitter Stack會(huì)結(jié)合地更好一些。
在discretizer方面我們都比較標(biāo)準(zhǔn)了,像Boosting tree(GBDT、AdaBoost)、Random forest、MDL discretizer等;
在Deep Learning方面,我們是基于torch做的,也有一些Deep Learning的libraries。
五、PredictionEngine
剛剛提到Twitter這種實(shí)時(shí)性是非常非常重要的,所以我開發(fā)了一個(gè)在線學(xué)習(xí)的一個(gè)引擎,叫PredictionEngine,這是專門為Large scale online SGD learing來做的,我們整個(gè)廣告包括我們的Feeds Ranking都是用的這個(gè)PredictionEngine。
在offline training其實(shí)整個(gè)PredictionEngine簡單地包一層application layer;在online serving的時(shí)候,PredictionEngine包一層online service layer,加這個(gè)layer去處理一些像RPC等等這方面的東西,它基本的架構(gòu)是:
第一層是Transform,用戶可以去定義或者用我們提供的transform來對feature vector(特征向量)進(jìn)行一定的變換;
第二層是Cross,Cross的意思是我可以把我的特征分組,比如分成四五組,然后第一組和第二組所有特征進(jìn)行Cross,比如在廣告上這個(gè)好處是可以把a(bǔ)dvertiser id,即把每個(gè)廣告商的id分到一組,把其它的features分到第二組,然后第一組和第二組一Cross,其實(shí)effectively給每一個(gè)廣告商一個(gè)personalized feature,這是非常有效的;
第三層是Logistic Regression;
這個(gè)Architecture一方面很方便地讓我們進(jìn)行在線的學(xué)習(xí),同時(shí)在transform layer和cross layer我們也加進(jìn)去了足夠多的這種nonlinearity(非線性)元素。如果只是簡單的logistic regression,那是線性的,效果并沒有那么好,于是我們加了transform layer和cross layer會(huì)解決一些非線性變換的問題。
那么對PredictionEngine我們做了非常多的優(yōu)化,在這個(gè)地方我會(huì)詳細(xì)地講:
1. 我們希望減少序列化和反序列化的代價(jià):
第一點(diǎn)是model collocation,model collocation是什么意思呢?就比如在廣告的預(yù)測中,我們預(yù)測的不是一個(gè)概率,即用戶有多少可能性去點(diǎn)擊這個(gè)廣告,我們可能是預(yù)測很多個(gè)概率,比如用戶可能轉(zhuǎn)發(fā)這個(gè)tweet的概率,用戶點(diǎn)擊這個(gè)的tweet里面的鏈接的概率,或者是用戶點(diǎn)擊了這個(gè)鏈接還購買的概率,或者用戶直接把這個(gè)廣告叉掉的概率。
對于一個(gè)用戶和廣告的這么一個(gè)pair,我們會(huì)預(yù)測很多個(gè)概率,比如你要預(yù)測5個(gè)概率,本來是應(yīng)該去做5次RPC call的,但是我們會(huì)把這五個(gè)模型都放在一physical container里面,這樣的話一個(gè)call過去,我可以在5個(gè)模型中都進(jìn)行計(jì)算并把5個(gè)prediction都給你返回,這是第一個(gè)優(yōu)化。
第二點(diǎn)是Batch request API,還是拿廣告問題舉例,對于一個(gè)用戶我要去評估可能成百上千甚至上萬的廣告的數(shù)量,對于任何一個(gè)用戶和這個(gè)廣告的pair,其實(shí)用戶的特征其實(shí)都是一樣的,所以有一個(gè)Batch的API的話,我可以amortise cost for user feature;
2. 我們希望減少CPU的Cost
也是做了幾方面的優(yōu)化:
所有的feature identifier全都是用id而不是feature name;
Transform sharing:剛才可以看到PredictionEngine里面,第一步是做transform,由于我們有model collocation可能有五六個(gè)模型,但其實(shí)可能有些模型他們的tramsform是一樣的,所以在這個(gè)層面上我們不要做重復(fù)的transform,如果不同的model的Transform都是一樣的話,我們就把它識(shí)別出來并且只做一次;
最后是feature cross done on the fly,因?yàn)閒eature cross其實(shí)是特征從幾百個(gè)變到幾千個(gè)甚至幾萬個(gè)的過程,比如原始特征幾百個(gè),cross之后特征數(shù)量可能大量增加。如果這時(shí)候我們把cross完的feature的再存到我們的內(nèi)存中去,這個(gè)cross就太大了,即使只是對這個(gè)cross后的結(jié)果掃描一遍的代價(jià)都非常地大,所以要做成on the fly的cross。
3. Training/Serving throughput
在整個(gè)在線學(xué)習(xí)過程之中,它的瓶頸在于最后trainer的模型update,在update模型的時(shí)候就要對這個(gè)模型加鎖。如果不優(yōu)化的話,只能有一個(gè)線程來對整個(gè)模型進(jìn)行更新。如果你的模型特別大,比如我們每一個(gè)模型都是上GB(Gigabyte)的,在這個(gè)情況下就會(huì)嚴(yán)重的影響training throughput。
所以我們的優(yōu)化會(huì)對整個(gè)模型進(jìn)行sharding,比如用多線程。比如有10個(gè)線程,每個(gè)線程分別負(fù)責(zé)這個(gè)模型的十分之一,算出來整個(gè)模型的update的時(shí)候把它切成10塊,扔到10個(gè)queue或buffer里面去,讓這10個(gè)線程來更新自己相應(yīng)的模型的那一塊,所以只是需要每一塊的worker自己更新自己那塊的時(shí)候?qū)δ菈K進(jìn)行加鎖就可以了;
第二個(gè)是把training和prediction分離,因?yàn)樵诰學(xué)習(xí)的話,我們需要在線去響應(yīng)很多的請求,如果每一個(gè)模型、每一個(gè)instance里面都有一個(gè)training都在做在線學(xué)習(xí)其實(shí)是很重復(fù)的。比如你有1千個(gè)instances都在做在線學(xué)習(xí),并且都在做實(shí)時(shí)響應(yīng)請求,1千個(gè)instances里面的training部分是冗余的,所以我們會(huì)把training這部分單獨(dú)拿出來作為training service,定期會(huì)把這個(gè)模型的更新去放到一個(gè)queue里面,然后fanout到所有的predition service instance里面去;
第三個(gè)是彈性負(fù)載,比如我們的client端要call我們的prediction service的時(shí)候,我們會(huì)在client端加一個(gè)檢測請求延遲,當(dāng)我們在client端檢測到prediction service不堪重負(fù),這個(gè)時(shí)候我們會(huì)動(dòng)態(tài)地減少對prediction service的請求,以保證我們的prediction service是良性和健康地運(yùn)轉(zhuǎn)的。
因?yàn)榇蠹抑烂刻斓牧髁繒?huì)有周期變化,比如某些時(shí)段流量特別高,某一些時(shí)段比如在夜里流量相對比較低。通過彈性負(fù)載動(dòng)態(tài)調(diào)整的機(jī)制,比如等到白天上午十點(diǎn)或者晚上八點(diǎn)特別忙的時(shí)候,我們可以做到對每一個(gè)用戶評估少一點(diǎn)的廣告,比如評估2000個(gè)廣告;如果是到半夜,每一個(gè)用戶可以評估多一點(diǎn)的廣告,如1萬個(gè)廣告。這樣動(dòng)態(tài)地去保證CPU的使用率都是在固定的level上。這個(gè)Level的制定是要考慮不同數(shù)據(jù)中心中間的failover,比如數(shù)據(jù)中心掛了,所有的這些traffic都要failover到某一個(gè)數(shù)據(jù)中心,然后還要留一點(diǎn)余量,所以我們一般CPU的utilization是在40%左右。
4. Realtime feedback
在線學(xué)習(xí)很重要一點(diǎn)是feedback一定要及時(shí),但是有一個(gè)很不好解決的問題,如果用戶他點(diǎn)了這個(gè)廣告,這是正向的反饋你馬上能知道,但是用戶沒有點(diǎn)這個(gè)廣告你這事就不能馬上知道,說不定用戶過五分鐘以后才點(diǎn)呢。
常用的解決方式是:我先把這個(gè)廣告先存起來,然后等十五分鐘,看看用戶有沒有點(diǎn),如果用戶在十五分鐘內(nèi)點(diǎn)了,我們就說這個(gè)用戶點(diǎn)了,這是一個(gè)positive training example,然后把它發(fā)到在線學(xué)習(xí)服務(wù)中去;如果用戶沒有點(diǎn),這就是negative training example。
這樣的問題就是說我們會(huì)有十五分鐘的延時(shí),這一點(diǎn)是非常不好的,所以我們做了一個(gè)優(yōu)化:每當(dāng)我們展示一個(gè)廣告的時(shí)候,我們馬上給在線學(xué)習(xí)服務(wù)發(fā)一個(gè)negative training example,當(dāng)成一個(gè)用戶沒有點(diǎn)擊的事件,然后當(dāng)用戶后面真正去點(diǎn)了這個(gè)廣告的話,那時(shí)我們會(huì)對這個(gè)事情進(jìn)行一定的修正,這樣就保證所有的事件實(shí)時(shí)性都非常高,是沒有延遲的。
5. Fault tolerance
我們的模型可能有幾千個(gè)instances,這些instances經(jīng)常地掛。我們需要每隔一段時(shí)間對我們的模型進(jìn)行一個(gè)snapshot,如果某一個(gè)instance掛了,另外一個(gè)重新啟動(dòng)的時(shí)候,它會(huì)去把最新最近的model snapshot load進(jìn)來,然后再開始進(jìn)行在線學(xué)習(xí);
還有一個(gè)問題是anomaly traffic detection,因?yàn)樵诰學(xué)習(xí)十分危險(xiǎn),因?yàn)樯嫌螖?shù)據(jù)任何的錯(cuò)誤都會(huì)馬上影響到這個(gè)模型的質(zhì)量。舉個(gè)例子,比如你有個(gè)pipeline,有兩個(gè)queue,一個(gè)queue專門發(fā)positive training example,另一個(gè)是發(fā)negative training example,結(jié)果你的positive的queue給掛了,這樣在線學(xué)習(xí)的模型一直只能接到negative training example,于是模型的預(yù)測在非常短的時(shí)間內(nèi)整個(gè)模型就全亂了,像Twitter這種公司肯定都是有非常嚴(yán)格的on call制度,但是on call不能解決問題,為什么呢?當(dāng)on call被page的時(shí)候,5分鐘之后打開電腦去進(jìn)行干預(yù)那個(gè)時(shí)候就已經(jīng)晚了,所以我們是需要做anomaly traffic detection做到在線學(xué)習(xí)當(dāng)中,如果一旦發(fā)現(xiàn)traffic這個(gè)構(gòu)成發(fā)生了很嚴(yán)重的變化,我們會(huì)馬上停止訓(xùn)練。當(dāng)然還是要page on call啦,然后讓on call來進(jìn)行人工干預(yù)解決。
六、Tooling
剛才說的是在線學(xué)習(xí),我們還給用戶提供很多工具,這些工具是為了幫助我們用戶很方便地區(qū)對整個(gè)模型進(jìn)行研究或者做一些改進(jìn)。這個(gè)工具叫Auto Hyper-parameter Tuning,就是變量的自動(dòng)選擇。機(jī)器學(xué)習(xí)的模型尤其包括像深度學(xué)習(xí)模型都有很多的變量。往往大家選變量的時(shí)候都是拍腦袋,比如我覺得這個(gè)learning-rate應(yīng)該是多少然后放進(jìn)去,好一點(diǎn)的呢就暴力搜一下,或者有些就是Random Search;
但是我們基于貝葉斯做了自動(dòng)的hyper-parameter選擇,我們會(huì)根據(jù)之前不同的parameter setting所跑出來的模型的結(jié)果去計(jì)算:我下一個(gè)parameter選擇什么使得在期望意義下我對目標(biāo)函數(shù)的提高會(huì)做到最大,而不像無頭蒼蠅一樣到處去搜,而是充分地利用已經(jīng)模型跑出來的數(shù)據(jù)和peformance來選擇下一步嘗試的參數(shù)。
其他的tooling,比如:
workflow management:就是整個(gè)offline的訓(xùn)練,你需要對它進(jìn)行監(jiān)測,需要可復(fù)現(xiàn),可以互相地分享;
Insight和Int
ERPretation:我們不希望我們的用戶用我們的東西是一個(gè)黑盒,所以我們也會(huì)搞一些tool幫助他們看數(shù)據(jù)、看模型、去分析特征的權(quán)重和貢獻(xiàn)等等;
Feature selection tool:進(jìn)行簡單地forward/backward 的greedy search。
七、Work in Progress
我們的機(jī)器學(xué)習(xí)也是在不斷的探索之中,這是我們努力的一些方向:
1. 最主要的方向是我們要平衡規(guī);挽`活性的問題。因?yàn)橐?guī);挽`活性往往是非常矛盾的,如果你用一些R、Matlab、Scikit-Learn等等一些工具,它們很多東西做得不錯(cuò),靈活性是可以的,但是在這些工具上要搞規(guī);,這個(gè)事情是非常困難的;
反過來如果要規(guī);,你的系統(tǒng)要做的非常非常專,要針對某些情況做出很多優(yōu)化,但是這種情況下就會(huì)影響算法的發(fā)揮。舉個(gè)例子,我們的PredictionEngine分三層,第一層Transform、第二層Cross、第三層是Logistic Regression,如果你說我想試一點(diǎn)別的框架和步驟,和這個(gè)假設(shè)如果不是那么一樣的話,可能你就沒有辦法用我們的這個(gè)工具。
所以,規(guī);挽`活性一直是一個(gè)非常沖突和難以平衡的問題,也是大家在不斷在這方面做更多的努力,我們也期望用一些torch-based的large scale機(jī)器學(xué)習(xí), 因?yàn)閠orch在靈活性方面是足夠的,如果我們能夠解決規(guī);膯栴}就會(huì)非常好;
2. 我們也會(huì)嘗試把深度學(xué)習(xí)的一些東西在廣告或者是feeds流上做一些實(shí)驗(yàn),雖然在業(yè)界現(xiàn)在成功的并不多,只有Google他們聲稱在這個(gè)方面做得還可以;
3. 為我們的用戶提供更好的工具,比如visualization和interactive exploration。
我今天的分享就到這里,謝謝大家!
Q&A
主持人:好,謝謝曉江。曉江請留步,今天你講的這一場非常爆滿。我想替大家問你幾個(gè)問題,第一個(gè)問題是,你們做數(shù)據(jù)和推薦這一塊,能直觀的給幾個(gè)數(shù)據(jù)來度量一下對你們Twitter業(yè)務(wù)的價(jià)值嗎?
郭曉江:剛才我可能提到了,Twitter90%的營收來自廣告,所有廣告都是機(jī)器學(xué)習(xí)支撐的。我四年前進(jìn)Twitter的時(shí)候,廣告組的規(guī)模的確剛剛起步,當(dāng)時(shí)那一代機(jī)器學(xué)習(xí)的架構(gòu)也非常簡單,模型也非常的簡陋。在我們上了大規(guī)模的在線學(xué)習(xí)的東西之后,把整個(gè)Twitter的營收提高了大概30%左右,這對于Twitter是幾十億美金的business,30%是一個(gè)非常非?捎^的數(shù)字,一般模型能提高1%、2%就已經(jīng)非常不錯(cuò)了。
在一些基礎(chǔ)架構(gòu)的革新使得我們可以在大規(guī)模的數(shù)據(jù)上面進(jìn)行訓(xùn)練,比如模型的復(fù)雜度和feature的規(guī)模都擴(kuò)大了好幾個(gè)數(shù)量級(jí),的確會(huì)對我們整個(gè)business和整個(gè)模型的質(zhì)量都有顯著地提高。
主持人:30%的提升,很酷的數(shù)字,很困難的動(dòng)作,所以在場的CTO、架構(gòu)師加油整,我們數(shù)據(jù)的價(jià)值很大。第二個(gè)問題,你提到在架構(gòu)上踩過很多的坑,這四年來整個(gè)過程中,你覺得最難的地方是什么?
郭曉江:因?yàn)槲覀兪且粋(gè)和業(yè)務(wù)結(jié)合蠻緊密的組織,我覺得其實(shí)最難的事情是要統(tǒng)一所有組的機(jī)器學(xué)習(xí)的架構(gòu)。因?yàn)樵谧铋_始,可能每個(gè)組都有自己的一套機(jī)器學(xué)習(xí)的東西,但是如果大家都自己一套東西,互相的share就非常的困難,所以我們花了非常多努力,比如就非常簡單的數(shù)據(jù)特征格式的定義,要推到所有的組都相當(dāng)困難。
我覺得很多時(shí)候這個(gè)挑戰(zhàn)更多還是來自于非技術(shù)的那一塊,也就是說服大家用我們的這一套系統(tǒng)。也許因?yàn)槲易黾夹g(shù),我覺得技術(shù)的東西還好,但是非技術(shù)的東西要推的話確實(shí)會(huì)稍微難一些。我們現(xiàn)在大家都用一套機(jī)器學(xué)習(xí)平臺(tái),之后我們把學(xué)習(xí)平臺(tái)進(jìn)行一些更新?lián)Q代,其實(shí)基本上代碼一般的生命周期也就是兩年左右,過兩年我們又有一套新的東西來更好地替代,這時(shí)候大家都用這一套,我們替代的時(shí)候也會(huì)方便很多,所以我覺得這是一個(gè)很大的挑戰(zhàn)吧。
主持人:好,最后一個(gè)問題,你們Twitter的這件事情做得很牛,架構(gòu)也做的很牛,你們有沒有更多的文檔更多知識(shí)能在網(wǎng)上跟大家分享嗎?
郭曉江:我們現(xiàn)在并沒有太多對外開放的文檔,我們也考慮過有一些東西能不能open source。因?yàn)闄C(jī)器學(xué)習(xí)和業(yè)務(wù)結(jié)合實(shí)在太緊密了,它和整個(gè)公司的技術(shù)戰(zhàn)略也非常緊密,我要開源這個(gè)東西,可能所有依賴的東西都得開源,而且機(jī)器學(xué)習(xí)這個(gè)東西更新實(shí)在太快了,所以我們花了好多時(shí)間,把這套開源了,實(shí)際上更好的東西已經(jīng)出來了,所以暫時(shí)我們這方面還沒有考慮。
郭曉江,四年前加入Twitter,先后供職于廣告組和機(jī)器學(xué)習(xí)平臺(tái)組。在廣告組設(shè)計(jì)和構(gòu)建了ads ranking后端平臺(tái),之后從無到有領(lǐng)導(dǎo)團(tuán)隊(duì)搭建了Twitter的機(jī)器學(xué)習(xí)平臺(tái),應(yīng)用在廣告推薦、Timeline Ranking、反欺詐等多個(gè)產(chǎn)品中,是每年幾十億美元的營收與內(nèi)容推薦背后的核心。本科畢業(yè)于清華電子工程系,碩士畢業(yè)于斯坦福電子工程系。
轉(zhuǎn)載請注明出處:拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題:Twitter機(jī)器學(xué)習(xí)平臺(tái)的設(shè)計(jì)與搭建
本文網(wǎng)址:http://www.ezxoed.cn/html/solutions/14019319953.html
關(guān)鍵詞標(biāo)簽:
Twitter機(jī)器學(xué)習(xí)平臺(tái)的設(shè)計(jì)與搭建,Twitter 機(jī)器學(xué)習(xí),ERP,ERP系統(tǒng),ERP軟件,ERP系統(tǒng)軟件,ERP管理系統(tǒng),ERP管理軟件,進(jìn)銷存軟件,財(cái)務(wù)軟件,倉庫管理軟件,生產(chǎn)管理軟件,企業(yè)管理軟件,拓步,拓步ERP,拓步軟件,免費(fèi)ERP,免費(fèi)ERP軟件,免費(fèi)ERP系統(tǒng),ERP軟件免費(fèi)下載,ERP系統(tǒng)免費(fèi)下載,免費(fèi)ERP軟件下載,免費(fèi)進(jìn)銷存軟件,免費(fèi)進(jìn)銷存,免費(fèi)財(cái)務(wù)軟件,免費(fèi)倉庫管理軟件,免費(fèi)下載,
本文轉(zhuǎn)自:e-works制造業(yè)信息化門戶網(wǎng)
本文來源于互聯(lián)網(wǎng),拓步ERP資訊網(wǎng)本著傳播知識(shí)、有益學(xué)習(xí)和研究的目的進(jìn)行的轉(zhuǎn)載,為網(wǎng)友免費(fèi)提供,并盡力標(biāo)明作者與出處,如有著作權(quán)人或出版方提出異議,本站將立即刪除。如果您對文章轉(zhuǎn)載有任何疑問請告之我們,以便我們及時(shí)糾正。聯(lián)系方式:QQ:10877846 Tel:0755-26405298。