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