機(jī)器學(xué)習(xí)43條軍規(guī):解密谷歌機(jī)器學(xué)習(xí)工程最佳實踐(上)
文章把在產(chǎn)品中應(yīng)用機(jī)器學(xué)習(xí)的過程從淺到深分成了三個大的階段,又在這三個大的階段中細(xì)分出了一些方面,以此對43條規(guī)則進(jìn)行邏輯分類。一起來學(xué)習(xí)下。
本文是對<Rules of Machine Learning: Best Practices for ML Engineering>一文的翻譯+解讀??催^我翻譯文章的同學(xué)知道我翻譯文章一般都不太老實,沒有那么“忠于原著”,本篇也不例外,本篇對于原文的解讀大概有三種形式:
- 原文翻譯。對于作者本身闡述的比較好,而我也沒什么可補(bǔ)充的部分,基本會原文翻譯。
- 半翻譯半解讀。有的條目我覺得有些自己的經(jīng)驗和感想可以和大家分享,就會加一些自己的解讀在里面。
- 省略。還有一些時候我覺得作者說的太仔(luo)細(xì)(suo),或者這個條目說得比較基本,無需太多解釋,我就會不同程度的省略原文。
這種形式對于有的同學(xué)來講可能會對原文信息有所損失,所以想要讀到原文的同學(xué),可以在這里找到原文。 或者去搜一些其他人比較忠于原著的翻譯。
作者介紹
什么樣的NB人物寫東西敢起號稱”Rules of Machine Learning”這種不怕閃了腰的題目?首先我們來簡單介紹一下本文的作者M(jìn)artin Zinkevich。
Martin Zinkevich現(xiàn)在是谷歌大腦的高級科學(xué)家,負(fù)責(zé)和參與了YouTube、Google Play 以及Google Plus等產(chǎn)品中的機(jī)器學(xué)習(xí)項目。在加入谷歌之前是雅虎的高級科學(xué)家,曾在2010年和2011年兩度獲得雅虎的最高榮譽(yù)Yahoo Team Superstar Awards,對雅虎的廣告系統(tǒng)做出過很多杰出貢獻(xiàn)。
擁有如此NB的背景,我們有理由相信這哥們兒寫出來的東西還是具有足夠的參考價值的。
梗概介紹
本文把在產(chǎn)品中應(yīng)用機(jī)器學(xué)習(xí)的過程從淺到深分成了三個大的階段,又在這三個大的階段中細(xì)分出了一些方面,以此對43條規(guī)則進(jìn)行邏輯分類。簡單來說,如果你是從頭開始做機(jī)器學(xué)習(xí)系統(tǒng),那么就可以在不同階段參考這里面對應(yīng)的條目,來保證自己走在正確的道路上。
正文開始
To make great products:
do machine learning like the great engineer you are, not like the great machine learning expert you aren’t.
這句話一定程度上是對整篇文章(叫手冊可能更合適)的一個高度概括,ML在實際工作確實更多是工程問題,而不是算法問題。優(yōu)先從工程效率中要效果,當(dāng)把這部分榨干后,再考慮算法的升級。
Before Machine Learning
Rule #1: Don’t be afraid to launch a product without machine learning.
規(guī)則1:不要害怕上線沒有機(jī)器學(xué)習(xí)的產(chǎn)品。
中心思想一句話概括:If you think that machine learning will give you a 100% boost, then a heuristic will get you 50% of the way there.
Rule #2: First, design and implement metrics.
規(guī)則2:在動手之前先設(shè)計和實現(xiàn)評價指標(biāo)。
在構(gòu)建具體的機(jī)器學(xué)習(xí)系統(tǒng)之前,首先在當(dāng)前系統(tǒng)中記錄盡量詳細(xì)的歷史信息,留好特征數(shù)據(jù)。這樣不僅能夠留好特征數(shù)據(jù),還能夠幫助我們隨時了解系統(tǒng)的狀態(tài),以及做各種改動時系統(tǒng)的變化。
Rule #3: Choose machine learning over a complex heuristic.
規(guī)則3:不要使用過于復(fù)雜的規(guī)則系統(tǒng),使用機(jī)器學(xué)習(xí)系統(tǒng)。
簡單來講,復(fù)雜的規(guī)則系統(tǒng)難以維護(hù),不可擴(kuò)展,而我們很簡單就可以轉(zhuǎn)為ML系統(tǒng),變得可維護(hù)可擴(kuò)展。
ML Phase I: Your First Pipeline
構(gòu)建第一個ML系統(tǒng)時,一定要更多關(guān)注系統(tǒng)架構(gòu)的建設(shè)。雖然機(jī)器學(xué)習(xí)的算法令人激動,但是基礎(chǔ)架構(gòu)不給力找不到問題時會令人抓狂。
Rule #4: Keep the first model simple and get the infrastructure right.
規(guī)則4:第一個模型要簡單,但是架構(gòu)要正確。
第一版模型的核心思想是抓住主要特征、與應(yīng)用盡量貼合以及快速上線。
Rule #5: Test the infrastructure independently from the machine learning.
規(guī)則5:獨立于機(jī)器學(xué)習(xí)來測試架構(gòu)流程。
確保架構(gòu)是可單獨測試的,將系統(tǒng)的訓(xùn)練部分進(jìn)行封裝,以確保其他部分都是可測試的。特別來講:
- 測試數(shù)據(jù)是否正確進(jìn)入訓(xùn)練算法。檢查具體的特征值是否符合預(yù)期。
- 測試實驗環(huán)境給出的預(yù)測結(jié)果與線上預(yù)測結(jié)果是否一致。
Rule #6: Be careful about dropped data when copying pipelines.
規(guī)則6:復(fù)制pipeline時要注意丟棄的數(shù)據(jù)。
從一個場景復(fù)制數(shù)據(jù)到另一個場景時,要注意兩邊對數(shù)據(jù)的要求是否一致,是否有數(shù)據(jù)丟失的情況。
Rule #7: Turn heuristics into features, or handle them externally.
規(guī)則7:將啟發(fā)規(guī)則轉(zhuǎn)化為特征,或者在外部處理它們。
機(jī)器學(xué)習(xí)系統(tǒng)解決的問題通常都不是新問題,而是對已有問題的進(jìn)一步優(yōu)化。這意味著有很多已有的規(guī)則或者啟發(fā)式規(guī)則可供使用。這部分信息應(yīng)該被充分利用(例如基于規(guī)則的推薦排序時用到的排序規(guī)則)。下面是幾種啟發(fā)式規(guī)則可以被使用的方式:
- 用啟發(fā)規(guī)則進(jìn)行預(yù)處理。如果啟發(fā)式規(guī)則非常有用,可以這么用。例如在垃圾郵件識別中,如果有發(fā)件人已經(jīng)被拉黑了,那么就不要再去學(xué)“拉黑”意味著什么,直接拉黑就好了。
- 制造特征。可以考慮從啟發(fā)式規(guī)則直接制造一個特征。例如,你使用啟發(fā)式規(guī)則來計算query的相關(guān)性,那么就可以把這個相關(guān)性得分作為特征使用。后面也可以考慮將計算相關(guān)性得分的原始數(shù)據(jù)作為特征,以期獲得更多的信息。
- 挖掘啟發(fā)式規(guī)則的原始輸入。如果有一個app的規(guī)則啟發(fā)式規(guī)則綜合了下載數(shù)、標(biāo)題文字長度等信息,可以考慮將這些原始信息單獨作為特征使用。
- 修改label。當(dāng)你覺得啟發(fā)式規(guī)則中包含了樣本中沒有包含的信息時可以這么用。例如,如果你想最大化下載數(shù),同時還想要追求下載內(nèi)容的質(zhì)量。一種可行的方法是將label乘以app的平均star數(shù)。在電商領(lǐng)域,也常常用類似的方法,例如在點擊率預(yù)估的項目中,可考慮對最終下單的商品或者高質(zhì)量的商品對應(yīng)的樣本增加權(quán)重。
已有的啟發(fā)式規(guī)則可以幫助機(jī)器學(xué)習(xí)系統(tǒng)更平滑的過渡,但是也要考慮是否有同等效果更簡單的實現(xiàn)方式。
Monitoring
概括來講,要保持好的監(jiān)控習(xí)慣,例如使報警是可應(yīng)對的,以及建設(shè)一個Dashboard頁面。
Rule #8: Know the freshness requirements of your system.
規(guī)則8:了解你系統(tǒng)對新鮮度的要求。
如果模型延遲一天更新,你的系統(tǒng)會受到多大的效果影響?如果是一周的延遲呢?或者更久?這個信息可以讓我們排布監(jiān)控的優(yōu)先級。如果模型一天不更新收入就會下降10%,那么可以考慮讓一個工程師全天候監(jiān)控它。了解系統(tǒng)對新鮮度的要求是決定具體監(jiān)控方案的第一步。
Rule #9: Detect problems before exporting models.
規(guī)則9:在模型上線之前檢測問題。
模型上線前一定要做完整性、正確性檢查,例如AUC、Calibration、NE等指標(biāo)的計算確認(rèn)等。如果是模型上線前出了問題,可以郵件通知,如果是用戶正在使用的模型出了問題,就需要電話通知了。
Rule #10: Watch for silent failures.
規(guī)則10:關(guān)注靜默失敗。
這是一個非常重要,而又經(jīng)常容易被忽略的問題。所謂的靜默失敗指的是全部流程都正常完成,但是背后依賴數(shù)據(jù)出了問題,導(dǎo)致模型效果逐步下降的問題。這種問題在其他系統(tǒng)中并不常出現(xiàn),但是在機(jī)器學(xué)習(xí)系統(tǒng)中出現(xiàn)幾率會比較高。例如訓(xùn)練依賴的某張數(shù)據(jù)表很久沒有更新了,或者表中的數(shù)據(jù)含義發(fā)生了變化等,再或者數(shù)據(jù)的覆蓋度忽然變少,都會對效果產(chǎn)生很大的影響。解決方法是是對關(guān)鍵數(shù)據(jù)的統(tǒng)計信息進(jìn)行監(jiān)控,并且周期性對關(guān)鍵數(shù)據(jù)進(jìn)行人工檢查。
Rule #11: Give feature column owners and documentation.
規(guī)則11:給特征組分配負(fù)責(zé)人,并記錄文檔。
這里的feature column指的是一個特征組,例如用戶可能屬于的國家這組特征就是一個feature column。
如果系統(tǒng)龐大,數(shù)據(jù)繁多,那么知道每組數(shù)據(jù)由誰生成就變得非常重要。雖然數(shù)據(jù)都有簡單描述,但是關(guān)于特征的具體計算邏輯,數(shù)據(jù)來源等都需要更詳細(xì)的記錄。
Your Fist Objective
objective是模型試圖優(yōu)化的值,而metric指的是任何用來衡量系統(tǒng)的值。
Rule #12: Don’t overthink which objective you choose to directly optimize.
規(guī)則12:不要過于糾結(jié)該優(yōu)化哪個目標(biāo)。
機(jī)器學(xué)習(xí)上線的初期,即使你只優(yōu)化一個目標(biāo),很多指標(biāo)一般都會一起上漲的。所以不用太糾結(jié)究竟該優(yōu)化哪個。
雖然大佬這么說,但是在我自己的實踐經(jīng)驗中,只優(yōu)化一個目標(biāo),系統(tǒng)的整體效果卻未必會上漲。典型的如推薦系統(tǒng)的CTR模型,上線之后CTR確實會提升,但是對應(yīng)的CVR很有可能會下降,這時還需要一個CVR模型,兩個模型同時使用才能真正提升系統(tǒng)效果。究其原因,是因為每個目標(biāo)只關(guān)注系統(tǒng)整個過程的一個子過程,貪心地去優(yōu)化這個子過程,不一定能夠得到全局的最優(yōu)解,通常需要把主要的幾個子過程都優(yōu)化之后,才能取得整體效果的提升。
Rule #13: Choose a simple, observable and attributable metric for your first objective.
規(guī)則13:為你的第一個objective選擇一個簡單可觀測可歸因的metric。
objective應(yīng)該是簡單可衡量的,并且是metric的有效代理。最適合被建模的是可直接觀測并被歸因的行為,例如:
- 鏈接是否被點擊?
- 軟件是否被下載?
- 郵件是否被轉(zhuǎn)發(fā)?
……
盡量不要在第一次就建模非直接效果的行為,例如:
- 用戶第二天是否會訪問?
- 用戶在網(wǎng)站上停留了多久?
- 日活用戶有多少?
非直接指標(biāo)是很好的metric,可以用ABTest來進(jìn)行觀測,但不適合用作優(yōu)化指標(biāo)。此外,千萬不要試圖學(xué)習(xí)以下目標(biāo):
- 用戶對產(chǎn)品是否滿意?
- 用戶對體驗是否滿意?
……
這些指標(biāo)非常重要,但是非常難以學(xué)習(xí)。應(yīng)該使用一些代理指標(biāo)來學(xué)習(xí),通過優(yōu)化代理指標(biāo)來優(yōu)化這些非直接指標(biāo)。為了公司的發(fā)展著想,最好有人工來連接機(jī)器學(xué)習(xí)的學(xué)習(xí)目標(biāo)和產(chǎn)品業(yè)務(wù)。
Rule #14: Starting with an interpretable model makes debugging easier.
規(guī)則14:使用可解釋性強(qiáng)的模型可降低debug難度。
優(yōu)先選擇預(yù)測結(jié)果有概率含義、預(yù)測過程可解釋的模型,可以更容易的確認(rèn)效果,debug問題。例如,如果使用LR做分類,那么預(yù)測過程不外乎一些相乘和相加,如果特征都做了離散化,就只有加法了,這樣很容易debug一條樣本的預(yù)測得分是如何被計算出來的。所以出了問題很容易debug。
Rule #15: Separate Spam Filtering and Quality Ranking in a Policy Layer.
規(guī)則15:將垃圾過濾和質(zhì)量排序的工作分離,放到策略層(policy layer)。
排序系統(tǒng)工作的環(huán)境中數(shù)據(jù)分布是相對靜態(tài)的,大家為了得到更好的排序,會遵守系統(tǒng)制定的規(guī)則。但是垃圾過濾更多是個對抗性質(zhì)的工作,數(shù)據(jù)分布會經(jīng)常變動。所以不應(yīng)該讓排序系統(tǒng)去處理垃圾信息的過濾,而是應(yīng)該有單獨的一層去處理垃圾信息。這也是一種可以推廣的思想,那就是:排序?qū)又蛔雠判驅(qū)拥氖虑?,職?zé)盡量單一,其他工作讓架構(gòu)上更合適的模塊去處理。此外,為了提升模型效果,應(yīng)該把垃圾信息從訓(xùn)練數(shù)據(jù)中去除。
ML Phase II: Feature Engineering
前面第一階段的重點是把數(shù)據(jù)喂到學(xué)習(xí)系統(tǒng)中,有了基礎(chǔ)的監(jiān)控指標(biāo),有了基礎(chǔ)的架構(gòu)。等這一套系統(tǒng)建立起來后,第二階段就開始了。
整體來講,第二階段的核心工作是將盡量多的有效特征加入到第一版的系統(tǒng)中,一般都可以取得提升。
Rule #16: Plan to launch and iterate.
規(guī)則16:做好持續(xù)迭代上線的準(zhǔn)備。
簡單來說,就是要深刻認(rèn)識到,系統(tǒng)優(yōu)化永遠(yuǎn)沒有終點,所以系統(tǒng)設(shè)計方面要對迭代非常友好。例如增加刪除特征是否足夠簡單,正確性驗證是否足夠簡單,模型迭代是否可以并行運行,等等。
這雖然不是一條具體可行動的(actionable)規(guī)則,但是這種思想上的準(zhǔn)備對整個系統(tǒng)的開發(fā)很有幫助。只有真正深刻意識到了系統(tǒng)持續(xù)迭代上線的本質(zhì),才會在設(shè)計在線和離線架構(gòu)時為持續(xù)迭代最好相應(yīng)的設(shè)計,并做好相應(yīng)的工具,而不是做一錘子系統(tǒng)。
Rule #17: Start with directly observed and reported features as opposed to learned features.
規(guī)則17:優(yōu)先使用直接觀測或收集到的特征,而不是學(xué)習(xí)出來的特征。
所謂學(xué)習(xí)出來的特征,指的是用另外的算法學(xué)習(xí)出來的特征,而非可以直接觀測或收集到的簡單特征。學(xué)習(xí)出來的特征由于存在外部依賴,或者計算邏輯復(fù)雜,不一定適用于你當(dāng)前的模型,所以穩(wěn)定性和有效性會有風(fēng)險。而直接可觀測的特征由于是相對比較客觀的,依賴較少的,所以比較穩(wěn)定。
Rule #18: Explore with features of content that generalize across contexts.
規(guī)則18:探索使用可以跨場景的內(nèi)容特征。
中心思想是在說,要多利用可以在多個場景下使用的特征,例如全局的點擊率、瀏覽量這些特征,可以在多個場景下作為特征使用。這樣可以在一些冷啟動或者缺乏有效特征的場景下作為特征使用。
Rule #19: Use very specific features when you can.
規(guī)則19:盡量使用非常具體的特征。
如果數(shù)據(jù)量足夠大,那么相比少數(shù)復(fù)雜特征,使用海量簡單特征是更簡單有效的選擇。
所謂非常具體,指的是覆蓋樣本量比較少的特征,例如文檔的ID或者query的ID等。這樣的特征雖然每個只覆蓋很少一部分特征,但是只要這一組特征整體能夠覆蓋率比較高,例如90%,那就是OK的。而且還可以通過正則化來消除覆蓋率過低或者相關(guān)性差的特征。這也是大家都偏愛大規(guī)模ID特征的一個原因,現(xiàn)在很多大廠的排序模型特征都大量使用了大規(guī)模ID特征。
Rule #20: Combine and modify existing features to create new features in human--understandable ways.
規(guī)則20:用人類可理解的方式對已有特征進(jìn)行組合、修改來得到新特征。
離散化和交叉是最常用的兩種特征使用方式。其本質(zhì)都是用特征工程的方式,在不改變使用模型本身的情況下增加模型的非線性。這兩種方法本身沒什么好說的,值得一致的是,在大規(guī)模ID類特征的交叉時,例如一段是query里的關(guān)鍵詞,另一端是文檔里的關(guān)鍵詞,那就會產(chǎn)生很大量級的交叉特征,這時有兩種處理方法:
- 點積。其實計算query和文檔共同包含的關(guān)鍵詞數(shù)量。
- 交集。每一維特征的含義是某個詞同時出現(xiàn)在了query和文檔中,同時出現(xiàn)則該維特征為1,否則為0。
所謂“人類可理解的方式”,我的理解就是離散化和交叉要基于對業(yè)務(wù)邏輯的理解,不能亂交叉。
Rule #21: The number of feature weights you can learn in a linear model is roughly proportional to the amount of data you have.
規(guī)則21:線性模型中可學(xué)到的特征權(quán)重數(shù)量,與訓(xùn)練數(shù)據(jù)的數(shù)量大體成正比。
這背后有復(fù)雜的統(tǒng)計原理做支撐,但你只需要知道結(jié)論就可以了。這個原則給我們的啟示,是要根據(jù)數(shù)據(jù)量來選擇特征的生成方式,例如:
- 如果你的系統(tǒng)是一個搜索系統(tǒng),query和文檔中有百萬級的詞,但是你只有千級別的標(biāo)注樣本。那你就別用ID級關(guān)鍵詞特征了,而是要考慮點積類特征,把特征數(shù)量控制在幾十個這個級別。
- 如果你擁有百萬級樣本,那么可以將文檔和query的關(guān)鍵詞進(jìn)行交叉特征,然后用正則化進(jìn)行特征選擇。這樣你會得到百萬級特征,但是正則化之后會更少。所以說,千萬級樣本,十萬級特征。
- 如果你有十億級或者更高級別的樣本,那么你可以使用query和文檔的ID級特征,然后加上特征選擇和正則化。十億級樣本,千萬級特征。
總結(jié)起來就是,根據(jù)樣本決定特征使用方式,樣本不夠就對特征進(jìn)行高層次抽象處理,指導(dǎo)和樣本量級相匹配。
Rule #22: Clean up features you are no longer using.
規(guī)則22:清理不再使用的特征。
如果某個特征已經(jīng)沒有用,并且它與其他特征的交叉也已經(jīng)沒有用,就應(yīng)該將其清理掉,保持架構(gòu)的整潔性。
在考慮添加或保留哪些特征時,需要統(tǒng)計一下特征的樣本覆蓋率,例如一些整體覆蓋率很低的個性化feature column,只有很少用戶能覆蓋到,那么大概率這組特征作用不大。但另一方面,如果某個特征覆蓋率很低,例如只有1%,但是其區(qū)分度非常大,例如90%取值為1的樣本都是正樣本,那么 這個特征就值得加入或保留。
未完待續(xù)……
End.
作者:張相於
來源:http://www.36dsj.com/archives/100052
本文來源于人人都是產(chǎn)品經(jīng)理合作媒體@36大數(shù)據(jù),作者@張相於
題圖來自PEXELS,基于CC0協(xié)議
- 目前還沒評論,等你發(fā)揮!