TalkingData大規(guī)模機器學(xué)習(xí)的應(yīng)用

本文由TalkingData首席數(shù)據(jù)科學(xué)家張夏天撰寫

作者簡介：張夏天，TalkingData首席數(shù)據(jù)科學(xué)家，負責(zé)TalkingData機器學(xué)習(xí)和數(shù)據(jù)挖掘工作，為TalkingData的數(shù)據(jù)產(chǎn)品和服務(wù)提供支持。曾在IBM中國研究院、騰訊數(shù)據(jù)平臺部和華為諾亞方舟實驗室任職。對大數(shù)據(jù)環(huán)境下的機器學(xué)習(xí)、數(shù)據(jù)挖掘有深入的研究和實踐經(jīng)驗。

TalkingData誕生于2011年，目前提供應(yīng)用統(tǒng)計分析、游戲運營分析、移動廣告監(jiān)測、移動數(shù)據(jù)DMP平臺、移動行業(yè)數(shù)據(jù)分析和洞察，以及企業(yè)級移動數(shù)據(jù)分析和挖掘的解決方案等產(chǎn)品和服務(wù)。隨著各項業(yè)務(wù)快速發(fā)展，需要機器學(xué)習(xí)支撐的需求也越多越多，數(shù)據(jù)規(guī)模也越來越大，帶來很大的挑戰(zhàn)。而且TalkingData作為一個新興企業(yè)，資源相對有限，沒有辦法通過大量增加硬件資源、增加計算能力來應(yīng)對大數(shù)據(jù)問題，這給我們帶來了更大的挑戰(zhàn)。本文將簡要介紹我們應(yīng)對這些挑戰(zhàn)的一些經(jīng)驗。

計算平臺

TalkingData的數(shù)據(jù)處理集群目前僅有32臺機器，除了承擔(dān)機器學(xué)習(xí)任務(wù)外，更多的工作是數(shù)據(jù)處理，集群的負荷是非常繁重的。為了盡可能提高集群計算效率和程序開發(fā)效率，我們選擇了Spark。我們認為Spark最大的兩個優(yōu)點。一是數(shù)據(jù)處理效率高（相對于Hadoop MapReduce而言）。二是開發(fā)效率高，Scala語言的特性和Spark的DAG機制使得復(fù)雜的數(shù)據(jù)處理流程和計算邏輯能夠很簡潔地編寫，雖然Scala語言的特性也非常多，但是Spark對Scala語言的掌握程度要求不高，對一般程序員而言，一周時間足夠掌握，而且程序開發(fā)效率相比Hadoop MapReduce能夠提高一倍以上。 而且Spark社區(qū)的發(fā)展也很快(活躍開發(fā)者人數(shù)已經(jīng)超過Hadoop MapReduce)，能夠得到較好的社區(qū)支持和未來更多新功能。當(dāng)然也有人質(zhì)疑Spark在大規(guī)模集群上的穩(wěn)定性，但對我們來說目前這還不是一個問題。

算法分析

大數(shù)據(jù)給機器學(xué)習(xí)帶來了很大的機遇，也給機器學(xué)習(xí)帶來了很多的挑戰(zhàn)。大量的訓(xùn)練樣本和豐富的特征維度，使得學(xué)習(xí)算法更容易學(xué)到較好的模型。數(shù)據(jù)更新速度很快，我們也可以更快地更新模型。同時，由于數(shù)據(jù)規(guī)模的增大使得機器學(xué)習(xí)算法的效率問題越來越突出。首先，從算法復(fù)雜度來說，有些算法的復(fù)雜度與訓(xùn)練樣本數(shù)（如SVM）或者特征數(shù)量（如決策樹）的關(guān)系是超線性關(guān)系。有一些模型學(xué)習(xí)中用到的優(yōu)化方法，如牛頓法，需要計算訓(xùn)練特征維度規(guī)模的海塞矩陣的逆矩陣及其乘法，其計算復(fù)雜度為 O(n^3)）。隨著數(shù)據(jù)量和特征數(shù)量的增長，模型訓(xùn)練的計算量急速增加，使得訓(xùn)練時間變得越來越長而不可接受。而硬件數(shù)量的擴充，帶來的計算效率提升往往是低于線性的增長。因此，在進行大數(shù)據(jù)問題時，我們始終面臨著計算資源相對不足的問題。

為了解決計算復(fù)雜度的問題，也出現(xiàn)一些計算量較小的優(yōu)化方法，如隨機梯度下降（Stochastic Gradient Decent）、小批量梯度下降（mini-Batch Gradient Decent）等方法。但是，機器學(xué)習(xí)算法大部分都是迭代算法，需要反復(fù)使用數(shù)據(jù)多次，而在處理大規(guī)模問題的時候，訓(xùn)練數(shù)據(jù)集可能無法全部裝載到內(nèi)存中，而需要一次一次的從分布式文件系統(tǒng)中讀取，帶來巨大的重復(fù)I/O開銷。即使Spark這樣具有In-Memory計算能力的分布式計算框架，同樣受制于集群資源和任務(wù)隊列資源的限制，很多情況下并不能夠把訓(xùn)練數(shù)據(jù)全部裝載到內(nèi)存中，還是需要多次從分布式文件系統(tǒng)中讀取數(shù)據(jù)文件。

數(shù)據(jù)迭代是機器學(xué)習(xí)算法處理大數(shù)據(jù)問題的“阿格硫斯之踵”。因此，盡可能降低算法迭代次數(shù)，是提高大規(guī)模機器學(xué)習(xí)任務(wù)的有效方法。在實踐中，我們盡可能使用那些只需掃描數(shù)據(jù)一遍的算法。 如用SimHash來進行聚類， 用關(guān)聯(lián)表算法來做推薦等。同時，我們也會優(yōu)化算法實現(xiàn)，使其無需迭代即可訓(xùn)練出較好的模型，如隨機決策樹算法（Random Decision Tree）、線性回歸(Linear Regression)和邏輯斯特回歸（Logsitic Regression）等。另外，雖然我們以Spark為計算平臺，但是并沒有太多的使用Spark內(nèi)嵌的MLLib來完成機器學(xué)習(xí)任務(wù)。最主要的原因也是因為MLLib中的算法基本都是迭代算法，其效率達不到我們的要求。

實際應(yīng)用

TalkingData的業(yè)務(wù)比較多，需要機器學(xué)習(xí)提供支持的地方也比較多。目前大致可分為四個方面：移動應(yīng)用推薦，廣告投放優(yōu)化，用戶畫像和游戲數(shù)據(jù)挖掘等四大塊。這里分別簡要介紹下這幾個方面的工作。

【移動應(yīng)用推薦】

TalkingData為幾家移動應(yīng)用市場提供過移動應(yīng)用推薦解決方案如機鋒和同步推，使用用戶的下載和瀏覽行為數(shù)據(jù)，來進行移動應(yīng)用的關(guān)聯(lián)推薦和個性化推薦。但是這種外包模式顯然無法充分利用我們的數(shù)據(jù)優(yōu)勢，也不是一種便捷的服務(wù)提供模式。前幾年當(dāng)推薦系統(tǒng)成為工業(yè)界和學(xué)術(shù)界都非常關(guān)心的技術(shù)時，國內(nèi)外都出現(xiàn)了以提供推薦系統(tǒng)解決方案的公司。但目前這些公司都已經(jīng)轉(zhuǎn)型，比如MyStrands.com, 目前已專注于提供金融客戶數(shù)據(jù)管理和分析工具，而不再把推薦系統(tǒng)解決方案作為重點。

實踐已經(jīng)證明第三方提供技術(shù)解決方案（包括提供SaaS服務(wù)）的模式并不具備很大的市場。我們通過這些外包項目，發(fā)現(xiàn)這種模式最大的問題在于數(shù)據(jù)的收集處理。如果我們要求客戶按照我們提供的數(shù)據(jù)格式，為我們準備好數(shù)據(jù)，則會給客戶帶來很大的負擔(dān)。由于客戶對推薦系統(tǒng)了解不多，對于如何把已有的數(shù)據(jù)映射成我們的數(shù)據(jù)格式通常會感到比較困惑，而難以正確完成。而如果我們根據(jù)用戶提供的現(xiàn)有數(shù)據(jù)進行轉(zhuǎn)換，又使得我們的服務(wù)難以標準化而快速復(fù)制。另外就是一旦我們把推薦系統(tǒng)交付給客戶后，我們也很難給客戶提供持續(xù)及時的效果優(yōu)化服務(wù)。

因為上述這些問題，我們的推薦系統(tǒng)服務(wù)，就從提供外包轉(zhuǎn)向了提供輕量級的移動應(yīng)用推薦服務(wù)接口。這一服務(wù)也可以算是一種SaaS模式，但是與之前其他公司提供的推薦SaaS服務(wù)的重大區(qū)別是我們不需要客戶提供推薦模型訓(xùn)練數(shù)據(jù)，客戶僅需要調(diào)用我們的接口獲得關(guān)聯(lián)推薦和個性化推薦的結(jié)果。這就樣也就沒有轉(zhuǎn)換客戶數(shù)據(jù)的問題，從而極大地降低推薦系統(tǒng)服務(wù)的使用門檻。而通過SaaS服務(wù)，我們也可以持續(xù)優(yōu)化和升級推薦算法的效果。

我們能夠提供這樣的服務(wù)，主要是隨著TalkingData積累的數(shù)據(jù)量越來越大，我們逐漸積累了大量的移動應(yīng)用使用情況數(shù)據(jù)，這些數(shù)據(jù)比下載和瀏覽行為數(shù)據(jù)能更準確地反映用戶的移動應(yīng)用興趣偏好，我們完全具備了不使用客戶的數(shù)據(jù)而提供更好的推薦結(jié)果的能力。移動應(yīng)用服務(wù)是作為TalkingData DMP里的一組接口向外提供服務(wù)的，我們將其作為TalkingData向外提供數(shù)據(jù)能力的一個出口。目前TalkingData推薦服務(wù)接口，每天要處理上億的移動應(yīng)用使用行為Session來建立推薦模型，覆蓋30萬以上的移動應(yīng)用。現(xiàn)在，已經(jīng)有一些移動應(yīng)用換量平臺使用我們的服務(wù)接口，也有一些移動應(yīng)用市場準備嘗試使用我們的推薦接口來為用戶提供移動應(yīng)用推薦。

近些年來，推薦算法是數(shù)據(jù)挖掘，機器學(xué)習(xí)學(xué)術(shù)會議上非常熱門的主題之一?？梢哉f相關(guān)的文獻是汗牛充棟，各種新算法和算法改進層出不窮。Netflix懸賞100萬美元的推薦系統(tǒng)競賽更是推動了推薦算法研究的熱潮。然而眾多的推薦算法，在實際應(yīng)用中并不是那么好用。首先對于最基礎(chǔ)的協(xié)同過濾算法，即通過計算用戶或者物品之間相似性的方法，由于其計算復(fù)雜度與用戶或者物品的數(shù)量是超線性的關(guān)系，而且需要計算矩陣乘法，難以并行化，用來處理大規(guī)模問題比較困難。而基于矩陣分解的方法，除了效率問題外，就是難以保證有較好的訓(xùn)練數(shù)據(jù)。因為這些算法的假設(shè)是基于每個用戶和物品都有足夠多的評分，但是實際上這是不可能的。另外，矩陣分解算法的目標是預(yù)測評分值與實際評分值最小化， 而實際應(yīng)用中我們真正關(guān)心的是用戶對不同物品感興趣程度的排序。最小化評分誤差，是否就能最小化排序誤差？當(dāng)然，也有一些矩陣分解算法被提出來用以最小化排序誤差，但是其計算量的增長又是十分巨大的。

因此，我們基于現(xiàn)實的數(shù)據(jù)情況（都是隱式反饋，設(shè)備規(guī)模較大， 和應(yīng)用較多）， 采用了在工程上比較好實現(xiàn)，計算效率較高，結(jié)果也較好解釋， 但是一點也不先進的算法，或者說算法框架—關(guān)聯(lián)表。關(guān)聯(lián)表算法原理比較簡單，可以看做是對關(guān)聯(lián)規(guī)則挖掘的一種簡化。該算法通過統(tǒng)計物品兩兩之間同時出現(xiàn)的頻次（如一個設(shè)備在一段時間內(nèi)使用了哪些應(yīng)用），構(gòu)建出物品到物品的關(guān)聯(lián)表。在進行關(guān)聯(lián)推薦時，通過在關(guān)聯(lián)表中查找目標物品的Top N關(guān)聯(lián)物品進行推薦。而在進行個性化推薦時，使用用戶最近有行為的那些物品分別查詢關(guān)聯(lián)表，然后再合并這些結(jié)果作為最后的推薦結(jié)果。

下面是一個關(guān)聯(lián)表構(gòu)建和使用的例子：

基于以上的關(guān)聯(lián)表，做Top 2的關(guān)聯(lián)推薦時, 如果目標物品是a2, 推薦的結(jié)果是a5和a3(排除a2)。如果要做Top 2個性化推薦，有d11: a1, a2, 用a1查關(guān)聯(lián)表(a1, a2)得到a5(3), a3(2), a4(2)用a2查關(guān)聯(lián)表得到a5(5), a3(4), a4(3). 合并以后得到a5(8), a3(6), a4(5), 取前兩個為a5, a3。在此基礎(chǔ)上，根據(jù)實際情況的需要，我們還需要對關(guān)聯(lián)表的結(jié)果進行去流行，已避免推薦出來的全都是最流行的那些應(yīng)用，在這里就不詳述了。

為了平衡長期興趣和短期興趣，我們采用不同時間內(nèi)的數(shù)據(jù)建立關(guān)聯(lián)表，比如一個月，一周和一天的數(shù)據(jù)分別建立關(guān)聯(lián)表。也可以使用不同的數(shù)據(jù)源來建立關(guān)聯(lián)表，比如使用應(yīng)用的數(shù)據(jù)和安裝應(yīng)用的數(shù)據(jù)。然后再通過多個關(guān)聯(lián)表的加權(quán)結(jié)果來獲得最后的結(jié)果。實際上，除了用用戶行為數(shù)據(jù)來統(tǒng)計應(yīng)用之間的關(guān)聯(lián)程度來建立關(guān)聯(lián)表外，還可以使用其他的數(shù)據(jù)和方法來構(gòu)建物品兩兩之間的關(guān)系。比如為了解決應(yīng)用的冷啟動問題，我們使用應(yīng)用的介紹文本，采用文本處理的一些技術(shù)建立應(yīng)用之間的關(guān)聯(lián)關(guān)系。因此，我們推薦系統(tǒng)的核心就是一系列這樣的關(guān)聯(lián)表。在做推薦時，通過一定的規(guī)則根據(jù)輸入?yún)?shù)查詢各個關(guān)聯(lián)表，然后融合也這些關(guān)聯(lián)表的結(jié)合，作為最終的推薦結(jié)果。關(guān)聯(lián)表方法，從算法的角度上看無疑是十分簡單的，但是是非常適合工程化的。從我們的實踐來看，在很多情況下，在精度上并不比先進算法有太大的差距。

【廣告投放優(yōu)化】

TalkingData積累了大量移動數(shù)據(jù)，完全具備進行廣告精準投放的能力。但是作為第三方數(shù)據(jù)平臺，我們嚴守中立，不會從事任何具體的廣告投放業(yè)務(wù)，我們僅僅是為移動廣告生態(tài)系統(tǒng)提供數(shù)據(jù)能力，提高整個生態(tài)系統(tǒng)的效率。

我們的移動DMP可以提供移動設(shè)備的應(yīng)用興趣等標簽，廣告主、網(wǎng)盟、DSP都可以通過我們的DMP平臺來獲得受眾數(shù)據(jù)來優(yōu)化廣告投放。但是也有一些合作伙伴，希望我們能夠直接提供投放的目標設(shè)備或者媒體。為了提供較好的結(jié)果，我們使用超過1.5億移動設(shè)備使用行為作為訓(xùn)練數(shù)據(jù)，特征空間超過180萬維，以使用過投放目標應(yīng)用的設(shè)備為正樣本進行訓(xùn)練。為了能夠?qū)λ性O(shè)備進行預(yù)測并輸出所有應(yīng)用與目標應(yīng)用的關(guān)系，我們選擇使用Logistic Regression算法進行訓(xùn)練。Logistic Regress也是處理大規(guī)模分類問題的常用算法，模型和訓(xùn)練過程相對簡單，模型的可解釋性也強。

但是這個規(guī)模的問題，如果采用一般的算法實現(xiàn)，如MLLib的實現(xiàn)，在我們的集群上最少也需要幾個小時的時間進行訓(xùn)練， 這會長時間占據(jù)集群資源影響其他任務(wù)的完成。 而且這個學(xué)習(xí)問題，除了數(shù)據(jù)規(guī)模比較大以外，還有一個挑戰(zhàn)就是正樣本數(shù)量通常較少。因為需要投放廣告的應(yīng)用，通常使用的用戶不會太多。我們遇到的情況，正樣本從幾百到幾百萬都有，但即使是幾百萬的正樣本，相對于1.5億的訓(xùn)練樣本，正樣本比例也是極低的，不過千分之幾。在這種情況下，一般很難訓(xùn)練得到較好的模型，我們使用過MLLib的LR算法進行訓(xùn)練，即使有幾百萬的正樣本，模型的AUC指標也僅比0.5高一點，基本不具備區(qū)分正負樣本的能力。

這種情況下，一般可以對訓(xùn)練數(shù)據(jù)采樣來增加正樣本的比例來改善的學(xué)習(xí)結(jié)果。采樣有兩種方式，一種是增加正樣本數(shù)量，另一種是減少負樣本數(shù)量。前者會增加訓(xùn)練樣本的數(shù)量而增加計算量。而后者又因為用戶行為數(shù)據(jù)是稀疏數(shù)據(jù)且維度很高，如果丟棄大量的負樣本，就會丟棄大量的特征，使得在預(yù)測時對只有這些特征的設(shè)備無法進行預(yù)測。因此我們不希望通過調(diào)整樣本比例的方式來解決這個問題。為了解決訓(xùn)練效率和樣本偏倚的問題，我們優(yōu)化了Logistic Regression算法求解的過程，使得訓(xùn)練過程只需要掃描數(shù)據(jù)一遍即可達到收斂，而且在樣本偏倚很嚴重的情況下也能達到較好的效果。在僅占用集群8%資源的情況下，Logistic Regression算法僅需5分鐘即可完成具有180萬維特征，1.5億樣本的訓(xùn)練。從測試情況來看，在正樣本較多的情況下（幾十萬到幾百萬），AUC基本都在0.7以上，很多時候超過0.8，甚至0.9。而在正樣本較少的情況下（幾百到幾千），一般也能達到0.6以上的AUC。 從實際廣告投放情況來看，通常能提高50%以上的轉(zhuǎn)化率。

雖然Logistic Regression算法已經(jīng)優(yōu)化得很快了，但是在有多個優(yōu)化任務(wù)的時候，還是可能會感到速度太慢。曾有過要跑500個任務(wù)的情況，一個任務(wù)跑5分鐘，就需要2500分鐘，接近42個小時。實際上500個任務(wù)，就需要掃描數(shù)據(jù)500次，這是最大的開銷。實際上，對于這500個任務(wù)，使用的都是同一份數(shù)據(jù)。其格式如下：

設(shè)備id, 應(yīng)用1， 應(yīng)用2， 應(yīng)用3……

只是每個任務(wù)會指定一個應(yīng)用為學(xué)習(xí)目標，其余的應(yīng)用則為特征。把原始數(shù)據(jù)根據(jù)指定應(yīng)用加工成訓(xùn)練數(shù)據(jù)，這在Spark中是非常容易完成的。但是每個任務(wù)都這么干一次，就會多次的讀取這個數(shù)據(jù)。顯然，這是非常不經(jīng)濟的。要提高效率，就需要消除這些冗余IO操作，只進行一次數(shù)據(jù)讀取。因為我們的算法是在每個數(shù)據(jù)分片上對數(shù)據(jù)逐條處理，因此對一條數(shù)據(jù)，進行多種不同的處理并沒有難度，只是在最后的Reduce階段，需要對不同分片上不同任務(wù)的模型結(jié)果進行整合，這在技術(shù)上不是什么難題。批量訓(xùn)練程序的效率是非常高的，對于500個任務(wù)，批量訓(xùn)練程序只需要50分鐘就可以完成訓(xùn)練，訓(xùn)練時間縮短到原來的2%。平均一個任務(wù)（有1.5億訓(xùn)練樣本，180萬的特征空間）的訓(xùn)練時間為6秒。批量訓(xùn)練程序的限制在于內(nèi)存，任務(wù)越多，對應(yīng)的模型越多，占用的內(nèi)存就越大。目前的數(shù)據(jù)情況能夠支撐大約1000個模型。

【用戶畫像】

TalkingData積累的數(shù)據(jù)以移動設(shè)備的行為數(shù)據(jù)為主，無法直接獲得設(shè)備的興趣標簽。而DMP向外提供數(shù)據(jù)時，又必須以標簽的形式向外提供數(shù)據(jù)，而且直接提供行為數(shù)據(jù)也對隱私保護不利。目前主要是利用移動應(yīng)用的標簽（由我們的專業(yè)團隊人工標注）和設(shè)備使用應(yīng)用的數(shù)據(jù)對設(shè)備進行標簽標注。除了為每個設(shè)備畫像，有時候我們需要對某個或者某類應(yīng)用的使用者進行群體畫像。

我們曾通過直接統(tǒng)計用戶群使用過的其他應(yīng)用比例作為用戶畫像的基礎(chǔ)，但是發(fā)現(xiàn)由于應(yīng)用活躍程度的長尾效應(yīng)，不管是什么人群，使用率最高的應(yīng)用基本都是微信，QQ這些平臺級應(yīng)用，也就沒有辦法總結(jié)出這個人群的特征了。而如果將這個人群的各個應(yīng)用的使用率除以所有設(shè)備上的應(yīng)用使用率，得到應(yīng)用使用率的提升率，又會突出那些使用率很低的應(yīng)用。通過調(diào)整公式和參數(shù)，可以在提升率和使用率之間做一些妥協(xié)，但很難達到理想的狀態(tài)。

為了解決這個問題，我們將這個問題作為分類問題，使用Logistic Regression模型來處理，以獲得模型中各個特征（即應(yīng)用）的系數(shù)作為關(guān)聯(lián)程度的分值，取得了非常好的效果。這個學(xué)習(xí)問題與廣告投放優(yōu)化中的問題是完全一樣的，都是以某個或者某些應(yīng)用的使用設(shè)備為正樣本，其他設(shè)備為負樣本，而以其他的應(yīng)用作為特征，訓(xùn)練Logistic Regression模型，從而得到各個應(yīng)用與目標人群的關(guān)聯(lián)程度。

從訓(xùn)練得到的結(jié)果來看，流行度高的應(yīng)用都得到了抑制，而關(guān)聯(lián)程度高的應(yīng)用使用率也不會太低。得到了人群的關(guān)聯(lián)應(yīng)用后，可以再利用這些應(yīng)用的標簽為這個人群標注興趣標簽。用這個方法，我們?yōu)檎猩蹄y行掌上生活，和一些廣告的受眾人群做了畫像，都取得了比較好的效果。

【游戲數(shù)據(jù)挖掘】

TalkingData的游戲運營分析平臺，是國內(nèi)手游運營分析工具的開創(chuàng)者。目前為超過3萬款游戲服務(wù)，其中包括消滅星星、植物大戰(zhàn)僵尸這些非常受歡迎的游戲。游戲運營分析平臺可以看作應(yīng)用統(tǒng)計平臺的游戲?qū)I(yè)版，在數(shù)據(jù)收集上增加了游戲相關(guān)的一些標準事件如升級，虛擬幣消費，付費等。

因為TalkingData的游戲運營分析平臺的定位，不僅僅是提供統(tǒng)計指標，還需要一定的預(yù)測能力，為游戲運營方預(yù)測哪些用戶可能流失，哪些用戶有可能付費。流失預(yù)測和付費預(yù)測，都是分類問題。因為我們需要考慮同時為3萬多款游戲提供這樣的預(yù)測，我們沒辦法逐個分析和抽取每款游戲收集的數(shù)據(jù)，特別是自定義事件來作為訓(xùn)練的特征。因此從規(guī)?；慕嵌瓤紤]，我們立足于使用十幾個標準化事件的數(shù)據(jù)作為特征。

而對于自定義事件，我們也將其作為標準化事件來使用，僅使用自定義事件的總次數(shù)，和出現(xiàn)的不同的自定義事件的種數(shù)作為特征。我們認為一個玩家產(chǎn)生的自定義事件的次數(shù)和種類，與玩家對這個游戲的興趣和投入程度應(yīng)該是正相關(guān)的。這樣，既能利用一些自定義事件的信息，但是又不需要對每個游戲的自定義事件做深入分析。當(dāng)然，這個方案是預(yù)測精度向工程可行性的妥協(xié)方案，必然是要損失一定的精度。但是從我們的測試結(jié)果來看，預(yù)測精度還是可以接受的。這個工作與前面提到的廣告投放優(yōu)化問題，在規(guī)模上也有一些不同。對于每一個游戲而言，都不是一個大規(guī)模的機器學(xué)習(xí)問題，訓(xùn)練樣本和最多也就百萬規(guī)模，而特征數(shù)量僅有十幾維。用我們優(yōu)化過的Logistic Regression算法，這樣的規(guī)模單機訓(xùn)練僅需要十幾秒的事件即可完成計算。但另一方面，因為需要支持所有游戲，每次需要訓(xùn)練3萬多個模型。

這種情況下，運用Spark的并行能力來加速每個任務(wù)的訓(xùn)練速度沒有什么意義，反而會因為多節(jié)點之間的同步問題，浪費掉不少計算能力。因此，我們在每個游戲的訓(xùn)練數(shù)據(jù)和預(yù)測數(shù)據(jù)處理好以后，把每一個游戲的數(shù)據(jù)Shuffle到一起，然后在Reduce過程中進行單機的Logistic Regression算法模型訓(xùn)練，然后進行預(yù)測。實際上，這里利用了Spark的并行能力來調(diào)度多個單機任務(wù)在集群上執(zhí)行。

總結(jié)：機器學(xué)習(xí)能力服務(wù)化

前面介紹了我們在機器學(xué)習(xí)方面的一些工作。最后，總結(jié)一下我們的一點工作經(jīng)驗。TalkingData作為一個數(shù)據(jù)公司，很多業(yè)務(wù)都需要機器學(xué)習(xí)能力的支持，而我們的機器學(xué)習(xí)團隊規(guī)模并不大，無法對每一個業(yè)務(wù)需求都做到及時響應(yīng)。比如廣告投放優(yōu)化的工作，每次業(yè)務(wù)部門接到客戶的需求，都需要來聯(lián)系我們，讓我們跑結(jié)果。這種方式讓我們經(jīng)常要干一些重復(fù)勞動，每次修改一下腳本，然后向Spark集群提交任務(wù)，跑出結(jié)果，再篩選設(shè)備和媒體出來。而客戶的需求也得不到及時的響應(yīng)。

為了解決這個問題，我們就把這個機器學(xué)習(xí)的能力進行了服務(wù)化，提供了Web界面給我們的業(yè)務(wù)部門使用。他們收到客戶需求后，就不需要再找我們了，而是直接使用Web工具，自動生成結(jié)果。這個工具幾乎不涉及機器學(xué)習(xí)的專業(yè)知識，使用者僅需要指定投放的目標應(yīng)用是哪一個就行。這樣，我們免去了一些沒有太多意義的重復(fù)性勞動，又讓業(yè)務(wù)部門不再需要依賴我們來跑結(jié)果，提高了雙方工作效率。

移動應(yīng)用推薦服務(wù)接口也是一個機器學(xué)習(xí)能力服務(wù)化的例子，我們把為客戶部署推薦系統(tǒng)，改為了提供推薦服務(wù)，而且進一步利用了我們的數(shù)據(jù)能力，降低用戶使用門檻。而我們也可以把精力集中在提供更高質(zhì)量的標準化服務(wù)，而不是為客戶的需求變化而疲于奔命。

基于這些經(jīng)驗，我們認為一個機器學(xué)習(xí)團隊，不僅要能提供好的機器學(xué)習(xí)能力（高效精準的算法），還需要把這些能力盡可能的服務(wù)化，為其他部門或者是客戶提供簡單易用的機器學(xué)習(xí)服務(wù)。機器學(xué)習(xí)團隊的工作應(yīng)該是不斷解決新的問題，把這些問題的解決方案固化成服務(wù)給公司內(nèi)外的用戶來使用。當(dāng)我們解決了一個問題時，就不要再讓這個問題成為我們的日常性工作，而牽扯我們解決新問題的精力。

End.

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責(zé)任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。