摘要：機(jī)器學(xué)習(xí)作為時(shí)下最為火熱的技術(shù)之一受到了廣泛的關(guān)注。文中給出的個(gè)建議都是針對(duì)機(jī)器學(xué)習(xí)系統(tǒng)的，沒有包含通用軟件工程里那些單元測試，發(fā)布流程等內(nèi)容，在實(shí)踐中這些傳統(tǒng)最佳實(shí)踐也同樣非常重要。

圖片描述

「觀遠(yuǎn)AI實(shí)戰(zhàn)」
欄目文章由觀遠(yuǎn)數(shù)據(jù)算法天團(tuán)傾力打造，觀小編整理編輯。這里將不定期推送關(guān)于機(jī)器學(xué)習(xí)，數(shù)據(jù)挖掘，特征重要性等干貨分享。本文8千多字，約需要16分鐘閱讀時(shí)間。

機(jī)器學(xué)習(xí)作為時(shí)下最為火熱的技術(shù)之一受到了廣泛的關(guān)注。我們每天打開公眾號(hào)都能收到各種前沿進(jìn)展、論文解讀、最新教程的推送。這些文章中絕大多數(shù)內(nèi)容都跟酷炫的新模型、高大上的數(shù)學(xué)推導(dǎo)有關(guān)。但是Peter Norvig說過，“We don’t have better algorithms. We just have more data.”。在實(shí)際機(jī)器學(xué)習(xí)應(yīng)用中，對(duì)最終結(jié)果起到?jīng)Q定性作用的往往是精心收集處理的高質(zhì)量數(shù)據(jù)。

從表面看好像也不難，但略微深究就會(huì)發(fā)現(xiàn)機(jī)器學(xué)習(xí)系統(tǒng)與傳統(tǒng)的軟件工程項(xiàng)目有著非常大的差異。除了廣受矚目的模型算法，良好的工程化思考與實(shí)現(xiàn)是最終達(dá)到機(jī)器學(xué)習(xí)項(xiàng)目成功的另一大關(guān)鍵因素。

谷歌在2015年發(fā)表的論文《Hidden Technical Debt in Machine Learning Systems》中就很好的總結(jié)了機(jī)器學(xué)習(xí)工程中的各種不佳實(shí)踐導(dǎo)致的技術(shù)債問題。主要有以下幾種：

在傳統(tǒng)的軟件工程中，一般會(huì)進(jìn)行細(xì)致的設(shè)計(jì)和抽象，對(duì)于系統(tǒng)的各個(gè)組成部分進(jìn)行良好的模塊劃分，這樣整個(gè)系統(tǒng)的演進(jìn)和維護(hù)都會(huì)處于一個(gè)比較可控的狀態(tài)。但機(jī)器學(xué)習(xí)系統(tǒng)天然就與數(shù)據(jù)存在一定程度的耦合，加上天然的交互式、實(shí)驗(yàn)性開發(fā)方式，很容易就會(huì)把數(shù)據(jù)清洗、特征工程、模型訓(xùn)練等模塊耦合在一起，牽一發(fā)而動(dòng)全身，導(dǎo)致后續(xù)添加新特征，做不同的實(shí)驗(yàn)驗(yàn)證都會(huì)變得越來越慢，越來越困難。

傳統(tǒng)的軟件工程開發(fā)中，可以很方便的通過編譯器，靜態(tài)分析等手段獲取到代碼中的各種依賴關(guān)系，快速發(fā)現(xiàn)不合理的耦合設(shè)計(jì)，然后借助于單元測試等手段快速重構(gòu)改進(jìn)。在機(jī)器學(xué)習(xí)系統(tǒng)中這類代碼耦合分析同樣不可或缺。除此之外還多了數(shù)據(jù)依賴問題。

比如銷售預(yù)測系統(tǒng)可能會(huì)對(duì)接終端POS系統(tǒng)數(shù)據(jù)，也會(huì)引入市場部門的營銷數(shù)據(jù)，還有倉儲(chǔ)、運(yùn)輸?shù)鹊榷喾N數(shù)據(jù)來源。在大多數(shù)情況下這些數(shù)據(jù)源都是不同部門維護(hù)的，不受數(shù)據(jù)算法團(tuán)隊(duì)的控制，指不定哪天就悄悄做了一個(gè)變更。如果變更很大，可能在做數(shù)據(jù)處理或者模型訓(xùn)練時(shí)會(huì)直接拋出錯(cuò)誤，但大多數(shù)情況下你的系統(tǒng)還是能正常運(yùn)行，而得到的訓(xùn)練預(yù)測結(jié)果很可能就有問題了。

在一些復(fù)雜業(yè)務(wù)系統(tǒng)中，這些數(shù)據(jù)本身還會(huì)被加工成各種中間數(shù)據(jù)集，同時(shí)被幾個(gè)數(shù)據(jù)分析預(yù)測任務(wù)共享，形成復(fù)雜的依賴關(guān)系網(wǎng)，進(jìn)一步加大了數(shù)據(jù)管理的難度。

膠水代碼：隨著各種開源項(xiàng)目的百花齊放，很多機(jī)器學(xué)習(xí)項(xiàng)目都會(huì)調(diào)用各種開源庫來做數(shù)據(jù)處理、模型訓(xùn)練、參數(shù)調(diào)優(yōu)等環(huán)節(jié)。于是自然而然在整個(gè)項(xiàng)目中大量的代碼都是為了把這些不同的開源庫粘合在一起的膠水代碼，同樣會(huì)導(dǎo)致之前提到過的邊界模糊，與特定的庫緊耦合，難以替換模塊快速演進(jìn)等問題。

流水線叢林：在數(shù)據(jù)處理特征工程與模型調(diào)優(yōu)的迭代演進(jìn)過程中，稍不注意你的整個(gè)系統(tǒng)流水線就會(huì)變得無比冗長，各種中間結(jié)果的寫入和前后依賴極其復(fù)雜。這時(shí)候想添加一個(gè)新特征，或是調(diào)試某個(gè)執(zhí)行失敗都變得如此困難，逐漸迷失在這混亂的叢林中……如果只具備機(jī)器學(xué)習(xí)知識(shí)而缺少工程經(jīng)驗(yàn)，用這種做實(shí)驗(yàn)的方式來開發(fā)系統(tǒng)顯然是不靠譜的，必須有良好的工程化思維，從總體上把控代碼模塊結(jié)構(gòu)，才能更好的平衡實(shí)驗(yàn)的靈活性與系統(tǒng)開發(fā)效率，保證整體的高效運(yùn)作。

失效的實(shí)驗(yàn)性代碼路徑：這一點(diǎn)也是承接前面，很多時(shí)候如果以跑實(shí)驗(yàn)的心態(tài)來給系統(tǒng)“添磚加瓦”，很可能到后面各種小徑交叉的代碼庫就這么出現(xiàn)了，誰都搞不清楚哪些代碼有用哪些是不會(huì)執(zhí)行到的。如何復(fù)現(xiàn)別人的實(shí)驗(yàn)結(jié)果，要用哪些數(shù)據(jù)集和特征，設(shè)置哪些變量、做哪些微調(diào)都會(huì)成為難解之謎。

缺乏好的系統(tǒng)抽象：個(gè)人覺得sklearn的各種API設(shè)計(jì)還算蠻好的，現(xiàn)在很多其它庫的高層API都參考了這個(gè)準(zhǔn)業(yè)界標(biāo)準(zhǔn)來實(shí)現(xiàn)。文中主要提到在分布式訓(xùn)練中缺乏一個(gè)很好的業(yè)界標(biāo)準(zhǔn)，比如MapReduce顯然是不行的，Parameter Server看起來還算靠譜但也還未成為標(biāo)準(zhǔn)。沒有好的抽象標(biāo)準(zhǔn)也就導(dǎo)致了各種庫在功能、接口設(shè)計(jì)時(shí)不一致，從而有了以上提到的一系列邊界模糊，膠水代碼等問題。

相對(duì)于傳統(tǒng)軟件系統(tǒng)，機(jī)器學(xué)習(xí)系統(tǒng)的配置項(xiàng)往往會(huì)更多更復(fù)雜。比如要使用哪些特征、各種數(shù)據(jù)選擇的規(guī)則、復(fù)雜的預(yù)處理和后置處理、模型本身的各種參數(shù)設(shè)置等等。因此除了工程代碼外，配置項(xiàng)的精心設(shè)計(jì)、評(píng)審也成了一個(gè)不容忽視的點(diǎn)。否則很容易造成系統(tǒng)在實(shí)際運(yùn)行中頻繁出錯(cuò)，難以使用。

機(jī)器學(xué)習(xí)系統(tǒng)很多時(shí)候都是直接與外部世界的數(shù)據(jù)做交互，而外部世界總是變化無常。而且機(jī)器學(xué)習(xí)系統(tǒng)本身的輸出也會(huì)影響到外部世界，從而進(jìn)一步回饋到機(jī)器學(xué)習(xí)系統(tǒng)的輸入中來。比如推薦系統(tǒng)給用戶展示的內(nèi)容會(huì)影響用戶的點(diǎn)擊行為，而這些點(diǎn)擊瀏覽行為又會(huì)成為訓(xùn)練數(shù)據(jù)輸入到推薦系統(tǒng)來。如何獲取到外部世界變化的信息，進(jìn)而及時(shí)改進(jìn)甚至自動(dòng)更新算法模型就成了一個(gè)非常重要的問題。

在谷歌的這篇原始論文中對(duì)各種坑都給了一些解決的建議，歸納總結(jié)一下，總體上來說就是要轉(zhuǎn)變團(tuán)隊(duì)整體的文化氛圍，強(qiáng)調(diào)良好的工程思維和實(shí)踐。一個(gè)設(shè)計(jì)良好的機(jī)器學(xué)習(xí)項(xiàng)目系統(tǒng)中往往真正跟機(jī)器學(xué)習(xí)相關(guān)的代碼只占了很小的一部分。

圖片描述

新模型固然酷炫，但是機(jī)器學(xué)習(xí)工程實(shí)踐的總結(jié)與推廣與它在整個(gè)項(xiàng)目中扮演的角色的重要性顯然是不成正比的。所以今天我們要著重來講一下這個(gè)方面：機(jī)器學(xué)習(xí)系統(tǒng)的最佳工程實(shí)踐是什么樣的？

這時(shí)候就要請(qǐng)出谷歌的另外一篇論文《The ML Test Score》了。前一篇論文在具體實(shí)踐落地方面缺乏細(xì)節(jié)，在這篇論文里，谷歌總結(jié)了28個(gè)非常具體的機(jī)器學(xué)習(xí)系統(tǒng)相關(guān)工程實(shí)踐準(zhǔn)則，可謂是干貨滿滿，十分接地氣。

文中給出的28個(gè)建議都是針對(duì)機(jī)器學(xué)習(xí)系統(tǒng)的，沒有包含通用軟件工程里那些單元測試，發(fā)布流程等內(nèi)容，在實(shí)踐中這些傳統(tǒng)最佳實(shí)踐也同樣非常重要。這些實(shí)踐在谷歌內(nèi)部團(tuán)隊(duì)廣泛使用，但沒有一個(gè)團(tuán)隊(duì)執(zhí)行的覆蓋率超過80%，因此這些測試點(diǎn)都是非常值得關(guān)注并有一定的實(shí)踐難度的。

特征期望值編寫到schema中：很多特征的分布情況或數(shù)值期望是有一些先驗(yàn)知識(shí)可以去校驗(yàn)的。比如一般人身高都在0-3米的范圍內(nèi)、英語中最常見的詞是”the”、整體的詞頻一般服從冪律分布等。我們可以把這些先驗(yàn)領(lǐng)域知識(shí)，或是從訓(xùn)練集中計(jì)算出的數(shù)學(xué)期望值編寫在數(shù)據(jù)schema文件中，后續(xù)對(duì)于新的輸入數(shù)據(jù)，構(gòu)建完特征后的模型訓(xùn)練數(shù)據(jù)以及最終上線使用模型時(shí)都能進(jìn)行自動(dòng)化的檢查，避免因?yàn)閿?shù)據(jù)不符合預(yù)期而導(dǎo)致的錯(cuò)誤預(yù)測情況。

確保所有的特征都是有用的：在之前的機(jī)器學(xué)習(xí)技術(shù)債論文中也有提到研發(fā)人員總是傾向于不斷往系統(tǒng)中添加新的特征，尤其在上線時(shí)間比較緊迫的情況下，缺少細(xì)致的特征選擇和有效性驗(yàn)證工作。這會(huì)導(dǎo)致特征數(shù)量越來越多，構(gòu)建訓(xùn)練集需要花費(fèi)的時(shí)間也越來越長，后續(xù)的維護(hù)成本也會(huì)更高。所以跟業(yè)務(wù)代碼一樣，沒有幫助的特征也要及時(shí)清理，輕裝前行。文中給出的方法基本是常見的特征選擇法，比如計(jì)算特征相關(guān)度，使用多帶帶或小批量特征來跑模型看是否有預(yù)測能力等。

去除性價(jià)比低的特征：計(jì)算添加任何一個(gè)特征都需要消耗資源，包括生成和訓(xùn)練模型開銷，模型預(yù)測開銷，甚至還要考慮到對(duì)上游數(shù)據(jù)的依賴，額外的庫函數(shù)引入，特征本身的不穩(wěn)定性等等。對(duì)于任何一個(gè)特征的添加，都要綜合考慮這些開銷與它能帶來的性能提升來決定是否引入。如果只是非常有限的效果提升，我們應(yīng)該果斷放棄那些過于復(fù)雜的特征。

特征必須遵循業(yè)務(wù)規(guī)范需求：不同的項(xiàng)目對(duì)機(jī)器學(xué)習(xí)系統(tǒng)可以使用的數(shù)據(jù)可能有不同的規(guī)范需求，比如可能有些業(yè)務(wù)禁止我們使用從用戶數(shù)據(jù)中推演出來的特征。所以我們也需要從代碼工程層面把這些規(guī)范需求進(jìn)行實(shí)現(xiàn)，以避免訓(xùn)練與線上特征出現(xiàn)不一致或違反了業(yè)務(wù)規(guī)范等問題。

數(shù)據(jù)流水線必須有完善的隱私控制：與上一條類似，機(jī)器學(xué)習(xí)系統(tǒng)從數(shù)據(jù)源獲取用戶相關(guān)隱私數(shù)據(jù)時(shí)已經(jīng)通過了相應(yīng)的控制校驗(yàn)，后續(xù)在系統(tǒng)內(nèi)部流水線做處理時(shí)我們也要時(shí)刻注意對(duì)隱私數(shù)據(jù)的訪問控制。比如各種中間數(shù)據(jù)集，數(shù)據(jù)字典的存放與訪問控制，上游系統(tǒng)的用戶數(shù)據(jù)刪除能夠級(jí)聯(lián)更新到機(jī)器學(xué)習(xí)系統(tǒng)的整個(gè)鏈路中，諸如此類需要特別注意的問題。

能夠快速開發(fā)新特征：一個(gè)新特征從提出到實(shí)現(xiàn)，測試，上線的整個(gè)流程所需要花費(fèi)的時(shí)間決定了整個(gè)機(jī)器系統(tǒng)迭代演進(jìn)，響應(yīng)外部變化的速度。要實(shí)現(xiàn)這一點(diǎn)，良好的工程結(jié)構(gòu)、不同模塊的抽象設(shè)計(jì)都是非常重要的。文中沒有給具體的例子，不過我們可以借鑒sklearn中pipeline模塊設(shè)計(jì)的思想，以及類似FeatureHub這樣的開源系統(tǒng)的實(shí)現(xiàn)來不斷優(yōu)化完善特征工程實(shí)踐。

為特征工程代碼寫相應(yīng)的測試：在實(shí)驗(yàn)探索階段，我們經(jīng)常會(huì)寫完一個(gè)特征之后，粗略地取樣一些數(shù)據(jù)，大致驗(yàn)證通過后就認(rèn)為這個(gè)特征基本沒有問題了。但這其中可能就隱藏了不少bug，而且不像業(yè)務(wù)代碼中的錯(cuò)誤，要發(fā)現(xiàn)這些bug極其困難。所以必須養(yǎng)成良好的習(xí)慣，在特征開發(fā)階段就寫好相應(yīng)的測試代碼，確保特征的正確性，后續(xù)應(yīng)對(duì)各種系統(tǒng)變更也都能很快通過測試來進(jìn)行快速驗(yàn)證。

圖片描述

模型說明必須通過review并記錄在案：隨著機(jī)器學(xué)習(xí)模型技術(shù)的發(fā)展，各種復(fù)雜模型，大量的參數(shù)配置往往讓模型訓(xùn)練和執(zhí)行變得無比復(fù)雜。加上在多人協(xié)同的項(xiàng)目中，很多時(shí)候需要使用不同的數(shù)據(jù)，或者做一些特定的調(diào)整來重新評(píng)估模型效果，這時(shí)候有詳細(xì)的模型說明記錄就顯得尤為重要了。除了簡單的文本記錄，市面上也有不少開源項(xiàng)目（比如ModelDB，MLflow等）專注于幫助開發(fā)者管理模型，提高實(shí)驗(yàn)的可復(fù)現(xiàn)性。

模型優(yōu)化指標(biāo)與業(yè)務(wù)指標(biāo)一致：很多機(jī)器學(xué)習(xí)的應(yīng)用業(yè)務(wù)中，實(shí)際的業(yè)務(wù)指標(biāo)并不能直接拿來作為目標(biāo)函數(shù)優(yōu)化，比如業(yè)務(wù)營收，用戶滿意度等等。因此大多數(shù)模型在優(yōu)化時(shí)都會(huì)選擇一個(gè)“代理指標(biāo)”，比如用戶點(diǎn)擊率的logloss之類。因此在建模，評(píng)估過程中必須要考慮到這個(gè)代理指標(biāo)與真實(shí)業(yè)務(wù)指標(biāo)是否有比較強(qiáng)的正相關(guān)性。我們可以通過各種A/B測試來進(jìn)行評(píng)估，如果代理指標(biāo)的改進(jìn)無法提升真正的業(yè)務(wù)指標(biāo)，就需要及時(shí)進(jìn)行調(diào)整。

調(diào)優(yōu)模型超參數(shù)：這點(diǎn)相信大家都會(huì)做，畢竟各種機(jī)器學(xué)習(xí)教程中都會(huì)有很大篇幅講解如何進(jìn)行調(diào)參來提升模型效果。值得注意的是除了暴力的網(wǎng)格搜索，隨機(jī)搜索同樣簡單而效果往往更好。另外還有許多更高級(jí)的算法例如貝葉斯優(yōu)化，SMAC等也可以嘗試使用。對(duì)于同一個(gè)數(shù)據(jù)集，在使用不同的特征組合，數(shù)據(jù)抽樣手段的時(shí)候理論上來說都應(yīng)該進(jìn)行參數(shù)調(diào)優(yōu)以達(dá)到最佳效果。這部分的工作也是比較容易通過自動(dòng)化工具來實(shí)現(xiàn)的。

對(duì)模型時(shí)效性有感知：對(duì)于很多輸入數(shù)據(jù)快速變化的業(yè)務(wù)例如推薦系統(tǒng)，金融應(yīng)用等，模型的時(shí)效性就顯得極其重要了。如果沒有及時(shí)訓(xùn)練更新模型的機(jī)制，整個(gè)系統(tǒng)的運(yùn)行效果可能會(huì)快速下降。我們可以通過保留多個(gè)版本的舊模型，使用A/B測試等手段來推演模型效果與時(shí)間推移的關(guān)系，并以此來制定整體模型的更新策略。

模型應(yīng)該優(yōu)于基準(zhǔn)測試：對(duì)于我們開發(fā)的復(fù)雜模型，我們應(yīng)該時(shí)常拿它與一些簡單的基準(zhǔn)模型進(jìn)行測試比較。如果需要花費(fèi)大量精力調(diào)優(yōu)的模型效果相比簡單的線性模型甚至統(tǒng)計(jì)預(yù)測都沒有明顯提升的話，我們就要仔細(xì)權(quán)衡一下使用復(fù)雜模型或做進(jìn)一步研發(fā)改進(jìn)的必要性了。

模型效果在不同數(shù)據(jù)切片上表現(xiàn)都應(yīng)達(dá)標(biāo)：在驗(yàn)證模型效果時(shí)，我們不能僅依賴于一個(gè)總體的驗(yàn)證集或是交叉驗(yàn)證指標(biāo)。應(yīng)該在不同維度下對(duì)數(shù)據(jù)進(jìn)行切分后分別驗(yàn)證，便于我們對(duì)模型效果有更細(xì)粒度上的理解。否則一些細(xì)粒度上的問題很容易被總體統(tǒng)計(jì)指標(biāo)所掩蓋，同時(shí)這些更細(xì)粒度的模型問題也能指導(dǎo)我們做進(jìn)一步細(xì)化模型的調(diào)優(yōu)工作。例如將預(yù)測效果根據(jù)不同國家的用戶，不同使用頻率的用戶，或者各種類別的電影等方式來分組分析。具體劃分方式可以根據(jù)業(yè)務(wù)特點(diǎn)來制定，并同時(shí)考察多個(gè)重要的維度。我們可以把這些測試固化到發(fā)布流程中，確保每次模型更新不會(huì)在某些數(shù)據(jù)子集中有明顯的效果下降。

將模型的包容性列入測試范圍：近些年來也有不少關(guān)于模型包容性，公平性相關(guān)問題的研究。例如我們?cè)谧鯪LP相關(guān)問題時(shí)通常會(huì)使用預(yù)訓(xùn)練的word embedding表達(dá)，如果這些預(yù)訓(xùn)練時(shí)使用的語料與真實(shí)應(yīng)用的場景有偏差，就會(huì)導(dǎo)致類似種族，性別歧視的公平性問題出現(xiàn)。我們可以檢查輸入特征是否與某些用戶類別有強(qiáng)關(guān)聯(lián)性，還可以通過模型輸出的切分分析，去判斷是否對(duì)某些用戶組別有明顯的差異對(duì)待。當(dāng)發(fā)現(xiàn)存在這個(gè)問題時(shí)，我們可以通過特征預(yù)處理（例如文中提到的embedding映射轉(zhuǎn)換來消除例如性別維度的差異），模型開發(fā)中的各種后置處理，收集更多數(shù)據(jù)以確保模型能學(xué)習(xí)到少數(shù)群體的特性等方式來解決這個(gè)問題。

圖片描述

模型訓(xùn)練是可復(fù)現(xiàn)的：在理想情況下，我們對(duì)同一份數(shù)據(jù)以同樣的參數(shù)進(jìn)行模型訓(xùn)練應(yīng)該能獲取到相同的模型結(jié)果。這樣對(duì)于我們做特征工程重構(gòu)驗(yàn)證等都會(huì)非常有幫助。但在實(shí)際項(xiàng)目中做到穩(wěn)定復(fù)現(xiàn)卻非常困難。例如模型中用到的隨機(jī)數(shù)種子，模型各部分的初始化順序，多線程/分布式訓(xùn)練導(dǎo)致的訓(xùn)練數(shù)據(jù)使用順序的不確定性等都會(huì)導(dǎo)致無法穩(wěn)定復(fù)現(xiàn)的問題。因此我們?cè)趯?shí)際工程中對(duì)于這些點(diǎn)都要額外注意。比如凡是用到了隨機(jī)數(shù)的地方都應(yīng)該暴露接口方便調(diào)用時(shí)進(jìn)行隨機(jī)數(shù)種子的設(shè)置。除了盡量寫能確定性運(yùn)行的代碼外，模型融合也能在一定程度上減輕這個(gè)問題。

模型說明代碼需要相應(yīng)測試：雖然模型說明代碼看起來很像“配置文件”，但其中也可能存在bug，導(dǎo)致模型訓(xùn)練沒有按預(yù)期方式執(zhí)行。而且要測試這種模型說明代碼也非常困難，因?yàn)槟Ｐ陀?xùn)練往往牽涉到非常多的外部輸入數(shù)據(jù)，而且通常耗時(shí)較長。文中提到谷歌將會(huì)開源一些相關(guān)的框架來幫助做相關(guān)的測試，一些具體的測試方法如下：

用工具去生成一些隨機(jī)數(shù)據(jù)，在模型中執(zhí)行一個(gè)訓(xùn)練步驟，檢驗(yàn)梯度更新是否符合預(yù)期。模型需要支持從任意checkpoint中恢復(fù)，繼續(xù)執(zhí)行訓(xùn)練。

針對(duì)算法特性做簡單的檢驗(yàn)，比如RNN在運(yùn)行過程中每次應(yīng)該會(huì)接受輸入序列中的一個(gè)元素來進(jìn)行處理。

執(zhí)行少量訓(xùn)練步驟，觀察training loss變化，確定loss是按預(yù)期呈現(xiàn)不斷下降的趨勢。

用簡單數(shù)據(jù)集讓模型去過擬合，迅速達(dá)到在訓(xùn)練集上100%的正確率，證明模型的學(xué)習(xí)能力。

盡量避免傳統(tǒng)的”golden tests”，就是把之前一個(gè)模型跑的結(jié)果存下來，以此為基準(zhǔn)去測試后面新模型是否達(dá)到了預(yù)期的效果。從長期來看由于輸入數(shù)據(jù)的變化，訓(xùn)練本身的不穩(wěn)定性都會(huì)導(dǎo)致這個(gè)方法的維護(hù)成本很高。即使發(fā)現(xiàn)了性能下降，也難以提供有用的洞察。

機(jī)器學(xué)習(xí)pipeline的集成測試：一個(gè)完整的機(jī)器學(xué)習(xí)pipeline一般會(huì)包括訓(xùn)練數(shù)據(jù)的收集，特征生成，模型訓(xùn)練，模型驗(yàn)證，部署和服務(wù)發(fā)布等環(huán)節(jié)。這些環(huán)節(jié)前后都會(huì)有一定交互影響，因此需要集成測試來驗(yàn)證整個(gè)流程的正確性。這些測試應(yīng)該包括在持續(xù)集成和發(fā)布上線環(huán)節(jié)。為了節(jié)約執(zhí)行時(shí)間，對(duì)于需要頻繁執(zhí)行的持續(xù)集成測試，我們可以選擇少量數(shù)據(jù)進(jìn)行驗(yàn)證，或者是使用較為簡單的模型以便于開發(fā)人員快速驗(yàn)證其它環(huán)節(jié)的修改不會(huì)引起問題。而在發(fā)布流程中還是需要使用與生產(chǎn)環(huán)境盡可能一致的配置來執(zhí)行整體的集成測試。

模型上線前必須驗(yàn)證其效果：這點(diǎn)看起來應(yīng)該是大家都會(huì)遵守的原則。唯一要注意的是需要同時(shí)驗(yàn)證模型的長期效果趨勢（是否有緩慢性能下降），以及與最近一個(gè)版本對(duì)比是否有明顯的性能下降。

模型能夠?qū)蝹€(gè)樣本做debug：這個(gè)就有點(diǎn)厲害了，當(dāng)你發(fā)現(xiàn)一個(gè)奇怪的模型輸出時(shí)，你怎么去尋找問題的原因？這時(shí)候如果有一個(gè)方便的工具能讓你把這個(gè)樣本輸入到模型中去，單步執(zhí)行去看模型訓(xùn)練/預(yù)測的過程，那將對(duì)排查問題帶來極大的便利和效率提升。文中提到TensorFlow自帶了一個(gè)debugger，在實(shí)際工作中我們也會(huì)使用eli5，LIME之類的工具來做黑盒模型解釋，但從方便程度和效果上來說肯定還是比不上框架自帶的排查工具。

模型上線前的金絲雀測試：這點(diǎn)在傳統(tǒng)軟件工程中基本也是標(biāo)配，盡管我們有測試環(huán)境，預(yù)發(fā)布環(huán)境的各種離線測試，模型在正式上線時(shí)還是需要在生產(chǎn)環(huán)境中跑一下簡單的驗(yàn)證測試，確保部署系統(tǒng)能夠成功加載模型并產(chǎn)出符合預(yù)期的預(yù)測結(jié)果。在此基礎(chǔ)上還可以進(jìn)一步使用灰度發(fā)布的方式，逐漸把流量從舊模型遷移到新模型上來，增加一層保障。

模型能夠快速回滾：與其它傳統(tǒng)軟件服務(wù)一樣，模型上線后如果發(fā)現(xiàn)有問題應(yīng)該能夠快速，安全回滾。要做到這點(diǎn)必須在開發(fā)時(shí)就確保各種上下游依賴的兼容性。并且回滾演練本身也應(yīng)該成為常規(guī)發(fā)布測試的一環(huán)，而不是到出了問題才去手毛腳亂的操作，引出更多意料之外的問題。

圖片描述

依賴變更推送：機(jī)器學(xué)習(xí)系統(tǒng)一般都會(huì)大量依賴于各種外部系統(tǒng)提供的數(shù)據(jù)，如果這些外部系統(tǒng)的數(shù)據(jù)格式，字段含義等發(fā)生了變化而我們沒有感知，很容易就會(huì)導(dǎo)致模型訓(xùn)練和預(yù)測變得不符合預(yù)期。因此我們必須訂閱這些依賴系統(tǒng)的變更推送，并確保其它系統(tǒng)的維護(hù)者知曉我們?cè)谑褂盟麄兲峁┑臄?shù)據(jù)。

訓(xùn)練與線上輸入數(shù)據(jù)分布的一致性：雖然模型內(nèi)部運(yùn)作過程極為復(fù)雜，難以直接監(jiān)控其運(yùn)行時(shí)正確性，但是模型的輸入數(shù)據(jù)這塊還是比較容易監(jiān)控的。我們可以用之前定義的特征數(shù)據(jù)schema文件來對(duì)線上輸入數(shù)據(jù)進(jìn)行檢測，當(dāng)出現(xiàn)較大偏差時(shí)自動(dòng)觸發(fā)告警，以便及時(shí)發(fā)現(xiàn)外部數(shù)據(jù)的變化情況。

訓(xùn)練與線上服務(wù)時(shí)生成的特征值一致：在機(jī)器學(xué)習(xí)項(xiàng)目中經(jīng)常會(huì)出現(xiàn)同一個(gè)特征在訓(xùn)練時(shí)和在線上使用時(shí)所采用的計(jì)算生成方式是不一樣的。比如在訓(xùn)練時(shí)特征是通過處理之前的歷史日志計(jì)算出來的，而到了線上的時(shí)候同樣的特征可能來自于用戶實(shí)時(shí)的反饋?；蛘呤怯?xùn)練時(shí)采用的特征生成函數(shù)是非常靈活，易于做各種實(shí)驗(yàn)嘗試的，而到了線上則改用固化的優(yōu)化計(jì)算性能版本以降低服務(wù)響應(yīng)時(shí)間。在理想情況下，雖然采用了不同的計(jì)算方式，但生成的特征值應(yīng)該是相同的，否則就會(huì)出現(xiàn)訓(xùn)練和預(yù)測使用的數(shù)據(jù)有偏移，導(dǎo)致模型效果變差等問題。所以我們需要通過各種手段來監(jiān)控線上線下數(shù)據(jù)的一致性。

例如可以通過對(duì)線上數(shù)據(jù)進(jìn)行采樣打標(biāo)記錄，來與訓(xùn)練集中的對(duì)應(yīng)條目進(jìn)行直接比較，計(jì)算出有偏差的特征數(shù)量，及這些特征中相應(yīng)的有偏差的樣本占比數(shù)量。另外也可以通過計(jì)算線上線下各個(gè)特征的統(tǒng)計(jì)分布的差別來衡量是否有這類問題的產(chǎn)生。

模型的時(shí)效性：這一點(diǎn)與之前的模型測試中的時(shí)效性類似，我們可以直接使用其中獲取到的模型效果與時(shí)間推移關(guān)系來推斷理想情況下模型訓(xùn)練更新的頻率，并以此來對(duì)模型持續(xù)運(yùn)行時(shí)間進(jìn)行監(jiān)控和告警。要注意過長的更新周期會(huì)提升模型的維護(hù)難度。另外哪怕模型本身更新比較可控，但是模型依賴的數(shù)據(jù)源也有類似的時(shí)效性問題，我們同樣需要對(duì)其進(jìn)行監(jiān)控以免出現(xiàn)數(shù)據(jù)過期的問題。

數(shù)值穩(wěn)定性：在模型訓(xùn)練中可能會(huì)在沒有任何報(bào)錯(cuò)的情況下出現(xiàn)奇怪的NaN，inf值，導(dǎo)致非預(yù)期的參數(shù)更新甚至最終得到不可用的模型。因此我們需要在訓(xùn)練中監(jiān)控任何訓(xùn)練數(shù)據(jù)中包含NaN或者inf的情況進(jìn)行適當(dāng)?shù)奶幚怼Ｍ瑫r(shí)對(duì)于各模型參數(shù)的取值范圍，ReLU層后輸出為0的單元數(shù)量占比等指標(biāo)進(jìn)行檢測，一旦超出預(yù)期范圍就進(jìn)行告警，便于及時(shí)定位排查相關(guān)問題。

模型性能相關(guān)監(jiān)控：機(jī)器學(xué)習(xí)模型的訓(xùn)練速度，預(yù)測響應(yīng)時(shí)間，系統(tǒng)吞吐量，以及內(nèi)存占用等性能指標(biāo)對(duì)于整體系統(tǒng)的可擴(kuò)展性來說都是至關(guān)重要的。尤其是隨著數(shù)據(jù)量的越來越大，越來越復(fù)雜模型的引入，更加劇了各種性能問題的出現(xiàn)。在模型演進(jìn)，數(shù)據(jù)變化以及基礎(chǔ)架構(gòu)/計(jì)算庫的更迭中，需要我們謹(jǐn)慎的評(píng)估模型性能變化，進(jìn)行快速響應(yīng)。在做性能監(jiān)控時(shí)不但要注意不同代碼組件，版本的表現(xiàn)，也要關(guān)注數(shù)據(jù)和模型版本的影響。而且除了容易檢測到的性能突變，長期，緩慢的性能下降也需要引起足夠的重視。

模型預(yù)測質(zhì)量的回歸問題：總體的目標(biāo)是希望新部署的模型相對(duì)于過去的模型在預(yù)測性能上沒有下降。但驗(yàn)證集相對(duì)于線上的真實(shí)情況來說總是有所區(qū)別的，只能作為一個(gè)性能評(píng)估的參考。文中列舉了幾種手段來做監(jiān)控：

衡量預(yù)測的統(tǒng)計(jì)偏差，正常情況下模型的預(yù)測偏差應(yīng)該為0，如果不是則說明其中有一定問題。

對(duì)于能在作出預(yù)測后很快得到正確與否反饋的任務(wù)類型，我們可以以此進(jìn)行實(shí)時(shí)監(jiān)控，迅速判斷模型效果相比之前是否有下降。

對(duì)于在模型提供服務(wù)時(shí)無法快速獲取到正確標(biāo)簽類型的任務(wù)類型，我們可以使用人工標(biāo)記的驗(yàn)證數(shù)據(jù)來比較模型效果的變化。

最后總結(jié)一下前面提到的各種監(jiān)控，基本上還有兩個(gè)共通點(diǎn)，一是各種告警的閾值要做精心選擇，過低的閾值容易出現(xiàn)警報(bào)泛濫導(dǎo)致根本沒人去管的情況，而過高的閾值又會(huì)掩蓋系統(tǒng)中已經(jīng)存在的各種問題。二是除了短時(shí)間內(nèi)明顯的指標(biāo)急劇下降外，同時(shí)也要關(guān)注長期的緩慢的下降，后者更難以發(fā)現(xiàn)，應(yīng)該引起足夠的重視。

圖片描述

文章后續(xù)還給出了這28個(gè)測試指標(biāo)的具體評(píng)分標(biāo)準(zhǔn)，幫助大家在實(shí)踐中更好的對(duì)照，應(yīng)用這些最佳實(shí)踐。還有很多在谷歌內(nèi)部使用這套評(píng)分系統(tǒng)的各種反饋，以及他們各個(gè)團(tuán)隊(duì)的平均得分情況等。

圖片描述

對(duì)于這個(gè)平均得分情況，作者強(qiáng)力安利了一把谷歌自家的TFX。

圖片描述

比如基礎(chǔ)架構(gòu)的集成測試，谷歌內(nèi)部的得分也很低（滿分為1的情況下平均為0.2分）。TFX可以方便的實(shí)現(xiàn)整個(gè)工程的pipeline，自然也很容易在此基礎(chǔ)上完成相應(yīng)的集成測試了。除了TFX，像Uber的Michelangelo，F(xiàn)acebook的FBLearner Flow也都是類似的機(jī)器學(xué)習(xí)平臺(tái)，雖然沒有開源，但都有比較詳細(xì)的介紹文章可以學(xué)習(xí)參考。

![圖片描述][9]

這些框架基本可以看作各家公司做機(jī)器學(xué)習(xí)工程的最佳實(shí)踐總結(jié)，總體架構(gòu)基本都遵循“數(shù)據(jù)管理->模型訓(xùn)練->模型測試驗(yàn)證->部署上線”這樣的流程。不過他們?cè)诰唧w設(shè)計(jì)實(shí)現(xiàn)上各有千秋，例如文中作者認(rèn)為“線下線上訓(xùn)練數(shù)據(jù)分布偏差監(jiān)控”是最為重要但卻鮮有實(shí)現(xiàn)的一個(gè)測試點(diǎn)，在很多項(xiàng)目組都曾經(jīng)因?yàn)槿鄙龠@個(gè)監(jiān)控而出現(xiàn)過多次線上故障。因此TFX提供了數(shù)據(jù)驗(yàn)證模塊來專門解決這個(gè)問題。而像Uber的Michelangelo則側(cè)重快速開發(fā)特征這個(gè)點(diǎn)引入了Feature Store模塊。在實(shí)際應(yīng)用中我們可以根據(jù)不同的業(yè)務(wù)特點(diǎn)靈活的選擇工程方案來進(jìn)行實(shí)現(xiàn)。

參考資料：https://papers.nips.cc/paper/...

https://ai.google/research/pu...

本文作者：觀遠(yuǎn)數(shù)據(jù)算法天團(tuán)-zijie

關(guān)注機(jī)器學(xué)習(xí)與分布式系統(tǒng)方向

知乎號(hào)：zijie0 | Blog：zijie0.github.io

觀遠(yuǎn)數(shù)據(jù)合伙人 / 知乎5000贊文章博主

觀遠(yuǎn)算法天團(tuán)又稱余杭區(qū)五常街道數(shù)據(jù)F4，成員多來自于帝國理工大學(xué)、紐約大學(xué)、清華大學(xué)、浙江大學(xué)、上海交大等國內(nèi)外知名學(xué)府，并有阿里大數(shù)據(jù)產(chǎn)品與技術(shù)研發(fā)的從業(yè)背景。2018年憑借先進(jìn)的算法能力，在微軟大中華區(qū)智慧零售（Smart Retail）AI挑戰(zhàn)大賽中，兩度斬獲冠軍，并從1500多家創(chuàng)新公司中脫穎而出，全票入選騰訊AI加速器第二期。作為本專欄特邀產(chǎn)出者，觀遠(yuǎn)算法天團(tuán)將在未來持續(xù)為大家分享更多精彩干貨，敬請(qǐng)期待！