算法模型調(diào)優(yōu)指南
在算法項目落地過程中，如果只考慮機器學(xué)習(xí)相關(guān)部分，個人感覺最花時間的兩個部分是數(shù)據(jù)質(zhì)量問題處理和模型實驗與迭代調(diào)優(yōu)。在之前Fullstack Deep Learning介紹的基礎(chǔ)上，我們在這篇文章中主要針對第二個問題做一些詳細(xì)的展開。
閱讀建議
一不小心，本文又寫的有點長……所以這里大概給一個閱讀建議：
對于初級算法工程師，希望了解基礎(chǔ)的算法建模流程的，可以主要閱讀1~5部分。 從第6部分開始是更深入的通過數(shù)據(jù)分析來進(jìn)行模型調(diào)優(yōu)的一些介紹，以及后續(xù)的測試，工程化，上線的簡介，比較適合有經(jīng)驗的算法工程師閱讀。
對于文中有任何描述不明確的地方，歡迎提出寶貴建議，先提前感謝大家啦！
1 原則
先列舉一些模型優(yōu)化過程中遵循的一些原則：
清晰的優(yōu)化指標(biāo) 高質(zhì)量Pipeline 明確的實驗設(shè)計 深入的結(jié)果分析
接下來我們逐步來分析與介紹。
2 指標(biāo)定義
2.1 什么是一個好的指標(biāo)
從廣義的指標(biāo)定義來看，有幾個考量方面：
Actionable，可以指導(dǎo)具體行為。 Accessible，簡單，容易理解。 Auditable，可以進(jìn)行驗證。
2.2 機器學(xué)習(xí)項目中的指標(biāo)
在機器學(xué)習(xí)項目中，我們在遵循上述原則下，往往會定義不同類型的指標(biāo)：
組織目標(biāo)，例如增加整個公司的收入，降低成本，或者對社會的整體貢獻(xiàn)等。一般會比較宏觀，與具體技術(shù)的距離相對較遠(yuǎn)。另外這些指標(biāo)收到的影響因素也有很多，內(nèi)外部因素都有。在技術(shù)項目實現(xiàn)周期，到能影響到組織目標(biāo)的變化過程會非常緩慢。因此一般很難直接優(yōu)化這個指標(biāo)。 業(yè)務(wù)指標(biāo)，相對組織目標(biāo)來說會更加具體和可衡量。注意在這個層面我們經(jīng)常碰到一些情況是模型輸出預(yù)測是否符合用戶預(yù)期，這種較為模糊的指標(biāo)定義往往難以衡量與改進(jìn)。因此必須與用戶溝通，制定出明確可量化的指標(biāo)來進(jìn)行衡量。這個維度的指標(biāo)也經(jīng)常會比較復(fù)雜，從技術(shù)層面來看可能難以直接優(yōu)化。 模型指標(biāo)，為了能快速迭代實驗，我們往往需要深入理解前面的組織目標(biāo)，業(yè)務(wù)指標(biāo)，再轉(zhuǎn)化為模型可以直接優(yōu)化的指標(biāo)，例如mae損失函數(shù)等。但這里也需要非常小心，模型指標(biāo)可能并未反映用戶的真實感受，或者與最終的業(yè)務(wù)目標(biāo)有一些差距。
對于這幾類的指標(biāo)，一個通常的做法是可以以不同的頻率在不同層級對這些指標(biāo)進(jìn)行評估驗證。例如在具體的實驗中，可以以非常高的每次試驗的頻率來評估模型指標(biāo)是否有提升。在天或者周的級別去驗證模型效果的提升能夠帶來業(yè)務(wù)指標(biāo)的提升。最后在月甚至更長的維度上去評估業(yè)務(wù)指標(biāo)對組織整體目標(biāo)的實現(xiàn)是否有正向促進(jìn)作用。
實際項目中，往往會出現(xiàn)業(yè)務(wù)方面的指標(biāo)不止一個的情況。例如我們既需要預(yù)測在細(xì)粒度上的squared error較低，又需要預(yù)測總量上的偏差較小。為了能較好的評估模型，我們一般會設(shè)定一個主要的優(yōu)化指標(biāo)（可以是多個誤差項的綜合），將其它指標(biāo)轉(zhuǎn)化為限制條件。例如在模型預(yù)測時間不超過1秒的情況下，取得盡量高的AUC。
3 實驗流程
很多機器學(xué)習(xí)課程上介紹的做法和很多行業(yè)新人在進(jìn)行實驗時會采取隨機嘗試的策略。例如，我先使用某種方法，得到了一個結(jié)果，然后腦子里又蹦出一個新的想法，繼續(xù)嘗試新方法，看結(jié)果是否有提升，依此不斷循環(huán)。
But，這樣做的效率太低了，很多時候就算效果有提升，也并不知道為什么，是否穩(wěn)定，是否對最終的業(yè)務(wù)效果是正向的促進(jìn)作用。因此我們更提倡采用數(shù)據(jù)分析驅(qū)動的方式來做各類建模實驗。在分析基礎(chǔ)上，實驗設(shè)計的出發(fā)點一般需要有明確的假設(shè)，然后通過實驗結(jié)果來驗證假設(shè)是否成立。一般的步驟如下：
分析：模型問題是什么？ 提出假設(shè)：可能的根源問題是什么？ 設(shè)計實驗：改進(jìn)方案是什么？ 執(zhí)行與驗證：改進(jìn)方案是否有效？ 循環(huán)迭代
另外在實驗涉及的嘗試方向上，數(shù)據(jù)相關(guān)的處理往往占據(jù)了主要的位置，包括數(shù)據(jù)修正，轉(zhuǎn)換，更新，增強，采樣等，可能占比在80%以上。剩下20%是與模型相關(guān)的嘗試。這也是業(yè)界的一個相對普遍的情況，需要在考慮實驗內(nèi)容方向時多加判斷，避免做了一系列高大上的前沿模型嘗試，總體產(chǎn)出卻非常有限。
3.1 問題分類
對于模型中可能出現(xiàn)的問題，我們作如下分類：
代碼實現(xiàn)中的bug。對于機器學(xué)習(xí)pipeline來說，很多情況下即使有隱藏的bug，程序也完全能跑通。這對問題排查造成了更大的困擾。 超參數(shù)設(shè)置不合理。很多模型對各類超參數(shù)的設(shè)置比較敏感，需要針對不同的問題和表現(xiàn)進(jìn)行超參數(shù)的調(diào)整。 數(shù)據(jù)相關(guān)問題。數(shù)據(jù)量不足，分布不均衡，出現(xiàn)錯誤的標(biāo)簽，缺少特定信息，有概念漂移問題等。 模型選擇問題。針對特定的問題及數(shù)據(jù)情況，我們需要選擇合適的模型。
3.2 整體流程
為了避免這些問題，構(gòu)建出高效，準(zhǔn)確率高的算法模型，我們可以遵循如下的通用步驟：
從簡單的pipeline開始，例如選擇最簡單的規(guī)則，或者基礎(chǔ)模型。以深度學(xué)習(xí)模型為例，我們可以選擇最基礎(chǔ)的MLP模型，adam優(yōu)化方法，不加任何regularization，使用標(biāo)準(zhǔn)歸一化方法，選取一個子集數(shù)據(jù)進(jìn)行嘗試。 實現(xiàn)并跑通pipeline。確保模型能夠運行，并在小數(shù)據(jù)集上overfit，或復(fù)現(xiàn)一些已知結(jié)果。 評估并分析結(jié)果。后續(xù)會詳細(xì)介紹分析手段方法。 參數(shù)調(diào)優(yōu)。對模型的各種參數(shù)，模型結(jié)構(gòu)進(jìn)行各種調(diào)整。 數(shù)據(jù)與模型調(diào)優(yōu)。修復(fù)數(shù)據(jù)中的問題，做數(shù)據(jù)增強，引入不同類型的數(shù)據(jù)，收集更多數(shù)據(jù)，或者特征工程預(yù)處理方面的操作。模型方面可以使用更加高級/復(fù)雜的模型結(jié)構(gòu)，引入ensemble等。
這方面比較好的資料可以參考Andrew Ng的《Machine Learning Yearning》，后續(xù)我們也會做一些具體闡述。
4 實驗執(zhí)行與管理
4.1 Pipeline
模型上線之后，需要有高質(zhì)量的pipeline來進(jìn)行系統(tǒng)化的運行，debug，及版本管理。這里不做詳細(xì)展開。從實驗與模型優(yōu)化角度看，對于經(jīng)常需要嘗試迭代更新的部分，應(yīng)該做好模塊分割，便于靈活進(jìn)行針對性的實驗。
實驗pipeline對運行效率會有更高要求，通常是針對整個流程中的一小部分，來反復(fù)修改嘗試，快速獲取到實驗結(jié)果。舉例來說，如果我們想做一個新特征的嘗試，應(yīng)該基于歷史的特征數(shù)據(jù)集來進(jìn)行增量的嘗試，而不是修改原有的特征工程代碼，觸發(fā)全量的特征構(gòu)建流程。一個簡單的評估標(biāo)準(zhǔn)是，每次實驗運行的總時間中，有多少百分比的時間實際上是在做重復(fù)的操作。理想情況下，這部分重復(fù)運行的占比要低于10%。
對于實驗pipeline的代碼質(zhì)量方面，一個簡單的原則就是越需要重復(fù)高頻使用的實驗，越需要做更好的抽象和代碼質(zhì)量保證。建議在notebook中寫完草稿后，拷貝到PyCharm等專業(yè)IDE中進(jìn)行代碼重構(gòu)與質(zhì)量檢查。
另外有一些業(yè)界研究，例如HELIX就是為了提升實驗效率，希望能夠自動存儲中間結(jié)果，來減少重復(fù)計算，達(dá)到使用同一個pipeline，但重復(fù)執(zhí)行的效率會變得很高的效果。
4.2 版本管理
在pipeline基礎(chǔ)上，我們需要對實驗使用到的各類依賴進(jìn)行版本管理，主要包括：
數(shù)據(jù)版本，如果使用的產(chǎn)品帶數(shù)據(jù)版本，直接使用即可。否則可以考慮用sha1等文件校驗碼來記錄數(shù)據(jù)的版本信息。 代碼版本，對于庫函數(shù)這類有g(shù)it管理部分的代碼，可以直接使用git的版本號。對于臨時的notebook文件，可以每天做一個notebook版本的備份。對于重要結(jié)果，例如當(dāng)前最好效果，也可以隨時做版本備份。 參數(shù)配置，大多數(shù)情況下，參數(shù)配置可以在代碼或者數(shù)據(jù)的版本中cover。但需要額外注意使用了外部配置文件的情況，對于這些配置文件，也需要與實驗的其它運行組成來一起管理(例如放在同一個文件夾下)。 模型版本，對于模型訓(xùn)練非常耗時的場景，訓(xùn)練出來的模型也需要進(jìn)行版本管理，以便于后續(xù)的分析與重用。
實驗版本管理對于項目過程中review進(jìn)度，確定下一步計劃，復(fù)現(xiàn)結(jié)果并部署上線等方面都非常重要。
5 初級建模調(diào)優(yōu)
5.1 數(shù)據(jù)流驗證
首先檢驗data flow沒有問題。例如使用簡單的規(guī)則，替代模型模塊，查看整個pipeline的流程是否有問題。對pipeline中大塊環(huán)節(jié)的輸出做檢查。
5.2 跑通模型訓(xùn)練
接下來將規(guī)則替換成真實的簡單模型，進(jìn)行訓(xùn)練與預(yù)測，看是否能跑通。過程中會出現(xiàn)各種拋錯，列舉一些最常見的bug：
Tensor shape錯誤 預(yù)處理錯誤 Loss function錯誤 數(shù)據(jù)中有NaN/Inf等值 沒有正確的設(shè)置訓(xùn)練模式，或其它框架相關(guān)常見錯誤 參數(shù)或數(shù)據(jù)處理問題導(dǎo)致的OOM 庫版本不匹配導(dǎo)致的奇怪exception
應(yīng)對策略：
使用標(biāo)準(zhǔn)化的流程pipeline，比如框架內(nèi)置方法，或者自己整理的針對某類問題的標(biāo)準(zhǔn)receipe。 搜索StackOverflow，Github上相關(guān)問題，尋求解決方案。 使用debugger和profiler進(jìn)行深入調(diào)試。 借助一些專用工具來輔助排查，例如tensor-sensor。
5.3 在小數(shù)據(jù)集上過擬合
模型可以訓(xùn)練了，我們會使用小批量數(shù)據(jù)來看是否能讓模型在這部分?jǐn)?shù)據(jù)上過擬合。這里會碰到的一些常見問題例如：
誤差不降反升 誤差爆炸 誤差震蕩 誤差停留在一個高位無法下降
應(yīng)對策略：
誤差上升的可能原因，學(xué)習(xí)率太高，loss function定義錯誤 誤差爆炸的可能原因，學(xué)習(xí)率太高，各種數(shù)值操作的問題，如exp，log，除法等 誤差震蕩的可能原因，學(xué)習(xí)率太高，原始數(shù)據(jù)問題如數(shù)據(jù)錯位，預(yù)處理bug等，可以進(jìn)一步通過結(jié)果分析定位 誤差停留在一個高位，可能由于學(xué)習(xí)率太低，優(yōu)化器相關(guān)設(shè)置，正則項過大，模型過于簡單，loss function欠佳，部分?jǐn)?shù)據(jù)有錯誤，沒有做數(shù)據(jù)歸一化，缺乏有效特征等
5.4 模型參數(shù)搜索
在模型可以在小數(shù)據(jù)量上正常優(yōu)化后，接下來通常的建議可能是增加數(shù)據(jù)量并做一定的模型參數(shù)搜索。不過根據(jù)我們的經(jīng)驗，這部分的整體計算開銷較大，但回報率相對比較一般（可以參考AutoML文中的一些research結(jié)論）。所以如果模型訓(xùn)練開銷不大的情況下，我們可以考慮在每天空閑時間（例如晚上下班后），掛一些自動參數(shù)搜索的任務(wù)進(jìn)行調(diào)優(yōu)嘗試。而在工作時間段，還是應(yīng)該集中精力做誤差分析和問題定位。
5.5 深入優(yōu)化
在初始的pipeline跑通，模型可以產(chǎn)出有意義的預(yù)測之后，再接下來就逐漸開始進(jìn)入深水區(qū)了。一方面我們要不斷降低模型訓(xùn)練誤差，另一方面也要開始關(guān)注模型的泛化能力，根據(jù)場景的不同會出現(xiàn)各種復(fù)雜的表現(xiàn)，并需要我們在各類問題中進(jìn)行權(quán)衡與選擇。從這里開始，我們的實驗過程中會有很大一部分精力放在結(jié)果誤差分析，以及數(shù)據(jù)模型層面各類問題的處理上，具體可以參考下面的數(shù)據(jù)分析環(huán)節(jié)。
例如模型泛化能力差問題，可能由于train/test數(shù)據(jù)分布變化，模型/超參復(fù)雜度過高，data leak，數(shù)據(jù)量不足，有干擾特征，缺乏數(shù)據(jù)歸一化操作等。具體原因可以根據(jù)詳細(xì)的誤差分析來挖掘。
對于深度學(xué)習(xí)模型的優(yōu)化，還有一些非常不錯的資料可以參考，例如Karpathy的這篇blog post。
6 深入調(diào)優(yōu)分析
構(gòu)建有效模型的關(guān)鍵是能夠迅速且準(zhǔn)確的定位到當(dāng)前模型失敗的原因具體是什么。這也是結(jié)果分析的主要目標(biāo)。
理想情況下，我們需要能明確定義：
模型當(dāng)前問題，例如在節(jié)假日期間，辦公型門店的預(yù)測銷量不準(zhǔn)。 各個問題導(dǎo)致的誤差占比，例如上述問題在總體誤差中占了12%。 問題對應(yīng)的典型數(shù)據(jù)集，例如我們可以收集一系列節(jié)假日，辦公型門店的歷史數(shù)據(jù)，用于后續(xù)調(diào)優(yōu)改進(jìn)的檢驗集。
當(dāng)然，如果以整體思維來考慮，我們在分析過程中還需要考慮：
模型的錯誤類型有哪些，是否能在目前的優(yōu)化指標(biāo)中反映出來。 用戶真實體驗如何。 模型錯誤可能導(dǎo)致的最嚴(yán)重后果是什么。
關(guān)于產(chǎn)品與用戶體驗方面，可以參考Google這篇非常好的文章中的闡述。
6.1 數(shù)據(jù)分析
人工檢查樣本，獲取一個對數(shù)據(jù)的整體感受。比如可以注意觀察數(shù)據(jù)是否分布均勻，是否有重復(fù)數(shù)據(jù)，label是否正確，是否能直觀發(fā)現(xiàn)比較重要的特征。在任何時候，親眼看一看數(shù)據(jù)細(xì)節(jié)都會是很有幫助的。
嘗試讓自己作為算法來進(jìn)行預(yù)測，例如選取幾條數(shù)據(jù)，看是否能根據(jù)自己的理解作出正確的預(yù)測。以此來更好的理解預(yù)測目標(biāo)，數(shù)據(jù)狀態(tài)，以制定模型/規(guī)則策略。
統(tǒng)計分析，借助一些工具如pandas_profiling等做統(tǒng)計和可視化分析。例如繪制相關(guān)度矩陣，觀察特征與預(yù)測目標(biāo)之間的關(guān)聯(lián)度，或者特征分布的箱線圖，觀察是否有異常值離群值等。
統(tǒng)計分析中還有很重要的一點是Drift分析，觀察輸入和預(yù)測目標(biāo)隨著時間變化是否出現(xiàn)了分布偏移。這對我們后續(xù)模型設(shè)計，以及構(gòu)建驗證集的分割方式選取上也會有參考意義。
人工檢查模型輸出。指標(biāo)一般是一個統(tǒng)計型結(jié)果，而往往容易覆蓋一些比較嚴(yán)重的問題。以LinkedIn推薦系統(tǒng)的為例，他們設(shè)計了一個向用戶推薦感興趣的群組功能。一個比較簡單的方法是推薦包含公司名的熱門群組，結(jié)果給Oracle的員工推薦里有一個排名挺高的群組名叫"Oracle Sucks!"。如果只關(guān)心指標(biāo)，可能只是非常微小的一個precision/recall變化變化。但對于用戶感受來說，差別是巨大的。
6.2 模型指標(biāo)分析
選取少量數(shù)據(jù)（例如1000條），確保模型可以訓(xùn)練并過擬合。后續(xù)逐步增加訓(xùn)練數(shù)據(jù)觀察數(shù)據(jù)量增加對模型效果的影響。這么做一方面可以在少量數(shù)據(jù)上驗證整體訓(xùn)練的pipeline，優(yōu)化器模型結(jié)構(gòu)等都可以正常工作。另一方面獲取到數(shù)據(jù)量增加情況下模型效果的變化，也有助于后續(xù)判斷在模型調(diào)優(yōu)時是否還需要收集更多的數(shù)據(jù)或進(jìn)行數(shù)據(jù)增強操作以提升效果。
與已知結(jié)果相比來判斷當(dāng)前model的效果處于一個什么水平。如果沒有對比，我們只能與真實值比較與分析模型表現(xiàn)，但并不知道模型指標(biāo)的上下限大致情況如何。對于模型效果下限，可以使用簡單的baseline model來對比，例如直接輸出占比最大的類別作為最簡單的分類模型。對于模型的上限/調(diào)優(yōu)目標(biāo)，我們可以選擇幾個可能的來源，例如公開發(fā)表的類似問題的模型效果，利用已知SoTA模型跑出來的對比效果（例如ResNet，BERT等），或者與人工專家預(yù)測的結(jié)果進(jìn)行對比。這些上下限模型給出的結(jié)果，可以作為更多的信息來源，幫助我們分析目前模型的問題在哪。例如發(fā)現(xiàn)人工預(yù)測在某些subgroup中明顯超過了我們的模型效果，則可以深入分析其中是否包含了未知的業(yè)務(wù)信息需要捕捉。
Learning curve檢查，觀察模型在訓(xùn)練集和驗證集的表現(xiàn)，也就是經(jīng)典的bias/variance trade-off，判斷模型狀態(tài)是否為欠擬合/過擬合，從而引導(dǎo)到控制模型復(fù)雜度的實驗嘗試。另外train，valid的效果相差較大，也有可能是在特征數(shù)據(jù)處理上出現(xiàn)了data leak，數(shù)據(jù)分布偏移，數(shù)據(jù)離群點等相關(guān)問題，可以通過數(shù)據(jù)分析可視化或模型解釋手段來進(jìn)行排查。后續(xù)涉及到特征工程修復(fù)，異常數(shù)據(jù)剔除，train/valid分割方式改進(jìn)或目標(biāo)函數(shù)的修改等操作。
也可以繪制一些更復(fù)雜的模型指標(biāo)可視化，例如混淆矩陣，ROC曲線，Calibration曲線等，幫助評估模型問題。例如Calibration曲線走勢相反，可能是train/test數(shù)據(jù)分布不一致導(dǎo)致。如果出現(xiàn)走勢平穩(wěn)，可能是由于特征缺乏區(qū)分度引起。
另一大塊是模型解釋方法的使用。例如查看模型的特征權(quán)重，feature importance，或者借助一些黑盒解釋手段如LIME，SHAP等。借助這些工具，可以輔助我們判斷模型為何給出了不符合預(yù)期的預(yù)測。例如當(dāng)我們發(fā)現(xiàn)某一組樣本的預(yù)測整體偏高，就可以通過模型解釋工具找到對這些樣本的預(yù)測有正向影響最大的那些特征是哪些。另外一個例子是在特征選擇優(yōu)化中，我們可以在訓(xùn)練數(shù)據(jù)中加入隨機值形成的一列特征，然后觀察模型訓(xùn)練后這個隨機特征的重要度排名。一般在這個隨機特征重要度之下的那些特征，很可能并不具有預(yù)測能力，可以考慮移除。
還有類似tensorboard之類的模型配套開發(fā)工具，可以更進(jìn)一步提供模型訓(xùn)練過程中更加詳細(xì)的可視化信息，包括每一層的gradient變化情況，有助于我們針對性分析神經(jīng)網(wǎng)絡(luò)中出現(xiàn)的優(yōu)化問題或數(shù)值問題。我們也可以針對不同的模型對應(yīng)開發(fā)類似的“SDK”，提高我們排查模型問題的效率。
對于分類問題，可以在決策邊界上找出模型不確定性較大的例子，再進(jìn)行分析看是否是缺少數(shù)據(jù)，還是相關(guān)label有錯誤。Active learning也是類似的想法。
6.3 Generalize模型問題
在分析模型問題時，一個關(guān)鍵的目標(biāo)是能夠找到具有普遍意義的問題（而不是特例），并能準(zhǔn)確描述這個問題的共通特點。
前面提到的各類模型指標(biāo)分析與可視化，都可以進(jìn)一步分割數(shù)據(jù)集，做多個維度上的指標(biāo)分析。分割的維度的選擇可以從數(shù)據(jù)中已經(jīng)存在的業(yè)務(wù)維度開始，例如產(chǎn)品品類等，后續(xù)可以根據(jù)分析結(jié)果，構(gòu)造一些特定的分組。對于不同維度下發(fā)現(xiàn)的問題，例如預(yù)測整體偏差較大或誤差較大，數(shù)據(jù)量偏少等，引導(dǎo)到具體的validation集分割策略，新數(shù)據(jù)收集，重采樣，預(yù)測結(jié)果后處理，或者分別構(gòu)建模型等實驗手段。
Top-k方法，觀察預(yù)測最準(zhǔn)的，最差的，和最不確定的top-k個樣本。如果樣本過多，則可考慮聚合到上一個層級來分析。通過尋找預(yù)測最準(zhǔn)的部分，可以分析出模型中較為有效的特征，并確認(rèn)這些是符合邏輯的。例如有個經(jīng)典的例子，在圖片分類問題中，模型學(xué)習(xí)到判別北極熊的特征其實是來自于雪地，而并不是動物本身。對于預(yù)測最差的部分，可能可以排查到是否是標(biāo)簽錯誤，或者特征數(shù)據(jù)中有異常。也可能是缺少了某些重要的信息輸入，需要引入額外數(shù)據(jù)或構(gòu)建新的特征。最不確定的樣本方面，例如對一個二分類模型，我們可以考察模型預(yù)測輸出在0.5左右的sample。這里往往可能存在有沖突的label訓(xùn)練樣本，或訓(xùn)練數(shù)據(jù)不足的問題。
除了按照維度分割數(shù)據(jù)來評估指標(biāo)，我們還可以使用聚類，降維等手段來輔助。例如使用k-means/k-prototypes，DBSCAN等聚類方法，將top誤差項進(jìn)行聚類，查看各個類的代表性例子，以及判別一些離群點。同理，在特征維度較高的情況下，使用PCA，UMAP，TriMAP等降維方法，再進(jìn)行聚類，也是一種常見方法。甚至我們可以對誤差大小本身來構(gòu)建一個預(yù)測模型，然后根據(jù)模型學(xué)習(xí)到的結(jié)構(gòu)和權(quán)重來輔助我們發(fā)現(xiàn)誤差問題中的隱藏pattern。
6.4 模型報告
對于上述的各類分析發(fā)現(xiàn)，我們還可以設(shè)定相應(yīng)的模型報告模板，例如可以參考Model Cards的形式，總結(jié)問題，并向業(yè)務(wù)相關(guān)人員提供更直觀易理解的展現(xiàn)形式，而不再是一個黑盒模型。
6.5 誤差分析深入
6.5.1 誤差分類
在A Characterization of Prediction Errors中，作者建議我們可以把預(yù)測誤差分為四類：
Mislabeling errors，標(biāo)簽錯誤。即原始的訓(xùn)練數(shù)據(jù)里就有問題，例如數(shù)據(jù)漏傳，數(shù)據(jù)處理錯誤等。 Learner errors，優(yōu)化錯誤或目標(biāo)函數(shù)引入的誤差，例如正則項。通過修改正則項，檢查是否可以在目標(biāo)函數(shù)error與泛化error之前取得平衡。 Representation errors，特征不足，或模型表達(dá)能力不足。技術(shù)上無法與mislabeling error區(qū)分，可以使用consistent learner(無正則項的lr，1-nn)，找到invalidation set人工確認(rèn)。 Boundary errors，數(shù)據(jù)不足。泛化錯誤。檢測方式：將數(shù)據(jù)加入訓(xùn)練集后，看錯誤是否仍然存在。Uncertainty sampling for active learning也是基于這個思想。
根據(jù)這個誤差分類，可以設(shè)計一些迭代調(diào)優(yōu)方式：
使用無正則項的學(xué)習(xí)器(1-NN, LR)，修復(fù)label error(correct label)和representation error(add feature)，反復(fù)迭代。 驗證boundary error，通過加入正則項來平衡泛化誤差與learner error。
6.5.2 Identifying Unknown Unknowns
在這篇文章中，作者提出了處理模型unknown unknowns錯誤的方法，可以作為前面誤差聚類方法的補充。其中第一步是做Descriptive Space Partitioning：
首先獲取需要調(diào)查的數(shù)據(jù)集X，例如回歸問題，選擇誤差top 10000條，或者分類問題，選擇confidence很高但預(yù)測錯誤的條目。 候選特征pattern集合Q，通過頻繁項挖掘，獲取到調(diào)查數(shù)據(jù)集X中特征組合的頻繁項。 開始迭代搜尋分割條件，其中pattern q來自于集合Q，計算X中符合q的條目數(shù)/g(q)，取argmax時的q值。 將第三步中找到的q加入到partition條件集合P中，同時將其從候選集合Q中移除，另外也將q覆蓋的條目從X中移除，繼續(xù)第3步，直到X中所有條目都被覆蓋。 最終的集合P就是partition方案，如果一個條目屬于多個q，則取距離中心最近的那個q。
這里g(q)的定義是組內(nèi)特征距離和 - 組間特征距離和 + 組內(nèi)信心指數(shù)和 - 組間信心指數(shù)和 + size(q)，如果是回歸問題，信心指數(shù)(confidence score)即為預(yù)測值。這個DSP方法總體上相比kmeans，entropy更小，不過在有些數(shù)據(jù)集上的優(yōu)勢并不明顯。
接下來需要人工分析這些錯誤聚類中的sample，作者提出了Bandit for Unknown Unknowns方法來提高檢查分析的回報效率。背后的思想還是多臂老虎機算法，具體操作如下：
在前k步(k等于partition數(shù)量)，從每一個partition中采樣來query oracle，看是否是unknown unknowns(or 具有代表性的模型問題？)。后續(xù)使用UCB方法來采樣來選擇partition。評估收益的utility function，是否是unknown unknowns減去oracle驗證的cost。
6.5.3 Error Analysis Visualization
Errudite，主要使用于NLP任務(wù)，跟ACL 2020上CheckList的想法有點類似，但是從誤差分析角度出發(fā)，并提供了工具層面的支持，便于更高效率的誤差分析。核心的三個步驟：
分析error sample，構(gòu)建起誤差背后共通特性的DSL描述。 將上述的DSL描述作為filter，apply到全量數(shù)據(jù)上，評判誤差占比。 使用conterfactual方法來分析產(chǎn)生誤差的具體原因。
Google的這篇教程中也提出了非常類似的框架。
CrossCheck，除了指標(biāo)的更細(xì)維度的對比展示，還提供了notes記錄等協(xié)作功能，有點意思。
AnchorViz，這個工作的主要動機是希望能更好的結(jié)合人類的知識能力，來提升active learning的效率。作者通過Anchor的概念，來讓用戶定義數(shù)據(jù)實例的“概念”，再通過RadViz的方法來展示各個Anchor影響下的實例的分布的可視化。從演示視頻看還可以利用Anchor做很多有意思的操作，高效率的分析模型問題，快速定位到feature blindness error(類似于前面誤差分類中的representation/label error)，并迭代改進(jìn)。
Dark Sight。結(jié)合了模型壓縮和降維來對樣本進(jìn)行可視化，相比t-SNE這類降維方法，Dark Sight可以比較好的還原出模型的決策行為。例如在MNIST問題中，3和5兩個類別的邊界上，可以看到很多長得像3的5和長得像5的3，而t-SNE這類降維方法則沒有這種性質(zhì)，無法體現(xiàn)出模型在預(yù)測confidence上的平滑變化。應(yīng)用這類技術(shù)，我們可以更好的理解模型決策，并針對誤差數(shù)據(jù)點做更深入的分析。美中不足的是這個方法主要用于分類問題，如何應(yīng)用于回歸問題還需要進(jìn)一步的探索。
7 相關(guān)測試
排查與調(diào)優(yōu)中，我們會發(fā)現(xiàn)許多數(shù)據(jù)，處理流程，模型輸出等方面的問題。除了對這些問題進(jìn)行修復(fù)，我們也需要注意積累這些問題對應(yīng)的系統(tǒng)性測試case，并添加到pipeline的測試流程中去。這對后續(xù)模型的各類回歸驗證測試，上線與運維都會有非常大的好處。由于本文并不是以MLOps為主題，這里只簡單列舉一下可以開發(fā)部署的測試類型。
數(shù)據(jù)輸入測試，可以考慮使用各類數(shù)據(jù)質(zhì)量檢查庫，比如著名的: https://github.com/great-expectations/great_expectations
數(shù)據(jù)轉(zhuǎn)換測試?？梢栽跀?shù)據(jù)進(jìn)入到模型訓(xùn)練之前，加一層對訓(xùn)練集驗證集的測試。例如對于feature encoding，空值處理，字段類型，以及train/valid的數(shù)據(jù)分布情況等做一些檢查。
輸出測試，例如一些固定的重要/hard case，輸出合理的值。這些測試case還有助于在部署后進(jìn)行快速驗證，尤其是在訓(xùn)練與serving框架有所不同的情況下，就顯得更為關(guān)鍵。
系統(tǒng)層面集成測試，驗證整體pipeline，上下游數(shù)據(jù)流和多個模型的協(xié)同。另外從最終用戶層面出發(fā)，需要考慮各類安全性測試，防止adversarial attack或各類abuse操作。
8 工程化與上線
關(guān)于模型上線這塊，涉及到大量的MLOps相關(guān)的知識內(nèi)容，并不是本文的重點。這里只簡單列舉一下我們在上線時會考慮的一些因素，更詳細(xì)的內(nèi)容后續(xù)有機會在展開討論。
在選擇具體上線的模型時，需要參考多個模型之間的離線評估比較，穩(wěn)定性，性能，準(zhǔn)確率，可解釋性，在線更新能力等多方面綜合考慮。
模型具體的上線和運維是另一個比較大的話題，可以采用Interleaving，A/B test，影子模型等手段，實現(xiàn)模型的持續(xù)部署與集成。
還有一個很現(xiàn)實的問題是當(dāng)線上模型出現(xiàn)問題時，我們?nèi)绾翁幚?，是否有plan B流程可以給出一個用戶可以接受的預(yù)測值。
各類監(jiān)控體系，運維平臺等也非常重要。前面提到的很多線下的分析排查工具，也可以為線上問題排查定位服務(wù)。持續(xù)的監(jiān)控，在效果下降時觸發(fā)模型自動更新訓(xùn)練，實現(xiàn)模型效果的持續(xù)穩(wěn)定。
另外有一些公司分享了他們內(nèi)部的實驗管理框架，例如：
Airbnb在這篇文章中介紹了他們的實驗管理平臺，不過主要側(cè)重在海量的實驗結(jié)果查看與分析上。
Uber在這篇文章中介紹了他們的大規(guī)?；販y平臺，更接近于我們之前提到的離線的模型開發(fā)與驗證環(huán)節(jié)中使用的工具。而這篇文章中介紹的實驗平臺，則主要服務(wù)于在線上進(jìn)行各類復(fù)雜測試，并為他們迭代演進(jìn)產(chǎn)品與服務(wù)設(shè)計提供數(shù)據(jù)指導(dǎo)。
最后，對于線上實驗，還有一些開源項目可以參考，例如：Wasabi，PlanOut等。
9 Some Future Work
與AutoML結(jié)合：Why we need hybrid approach：人工建模往往效率更高，在比較少的嘗試下達(dá)到較好的模型效果。主要操作是更換模型或者預(yù)處理方法。AutoML往往最終達(dá)到的效果更高，但需要的嘗試次數(shù)往往遠(yuǎn)遠(yuǎn)大于人工。會有大量的操作花費在超參搜索調(diào)優(yōu)上。
Human-in-the-Loop & AutoML：
也是一個非常有意思的工作，用數(shù)據(jù)庫系統(tǒng)的分層思想來考慮human-in-the-loop人機結(jié)合AutoML系統(tǒng)的設(shè)計。例如像SQL般易于使用的DSL來便于用戶輸入問題定義與描述，然后在下層有優(yōu)化器去形成經(jīng)過優(yōu)化的物理執(zhí)行計劃（在這里變成了ML workflow），并最終返回結(jié)果。
這個從成熟軟件系統(tǒng)中汲取營養(yǎng)的想法還是很有想象空間的。延展一下聯(lián)想到我們做算法的debugging，非常缺少類似Linux, JDK下各類tracing工具。所以軟件工程的排查調(diào)優(yōu)，一般來說都是能用工具確定性的抓到整個系統(tǒng)到底是如何在運行的，從應(yīng)用層一直drill down到系統(tǒng)資源層都能得到相應(yīng)的信息。而模型和數(shù)據(jù)的問題排查，很多時候只能在應(yīng)用層改一些參數(shù)，觀察這個黑盒的產(chǎn)出，成了所謂的“玄學(xué)”。如何能在數(shù)據(jù)，模型上開發(fā)出一套類似的tracing工具，把模型效果的排查成為相對確定性的追蹤，是一個值得深入思考的方向。
從上一點延展到數(shù)據(jù)流方面，軟件工程中也有很多值得借鑒的思想。例如編譯器可以幫助程序員進(jìn)行代碼邏輯，類型等方面的自動化檢查，提前發(fā)現(xiàn)問題。但是到了數(shù)據(jù)流這塊（例如ETL），往往都只能到運行起來了才能發(fā)現(xiàn)問題。是否能夠開發(fā)一些工具，做到數(shù)據(jù)轉(zhuǎn)換邏輯和schema（可能還需要一些統(tǒng)計信息）結(jié)合的靜態(tài)檢查，來保障數(shù)據(jù)流的質(zhì)量？
同理DevOps方面也有很多機器學(xué)習(xí)系統(tǒng)設(shè)計可以借鑒的地方，包括把數(shù)據(jù)因素結(jié)合進(jìn)來，形成一套新的測試運維體系，達(dá)到持續(xù)集成，持續(xù)交付，持續(xù)調(diào)優(yōu)的系統(tǒng)形態(tài)等（聯(lián)想的有點遠(yuǎn)了……）。
Machine Teaching：
跟上面的思路類似，考慮人與模型的交互式開發(fā)與應(yīng)用，從軟件工程/人機交互角度去設(shè)計整體系統(tǒng)越來越成為一種趨勢。下面這個對比表格也是非常典型的體現(xiàn)：
在這個方向上，Snorkel給出了不少實踐的路徑方案，比如他們提出的labeling function和slicing function的概念，可以很好的把人類專家經(jīng)驗跟機器學(xué)習(xí)結(jié)合起來，形成更加明確的迭代方向。