“他山之石，可以攻玉”，站在巨人的肩膀才能看得更高，走得更遠。在科研的道路上，更需藉助東風才能更快前行。為此，我們特別蒐集整理了一些實用的程式碼連結，資料集，軟體，程式設計技巧等，開闢“他山之石”專欄，助你乘風破浪，一路奮勇向前，敬請關注。

作者介紹：周遠（花名：位元組），觀遠資料聯合創始人與首席資料科學家。致力於演算法前沿技術在泛消費零售領域的應用落地，深度參與主導了多個AI專案在行業頭部，世界五百強客戶的應用和上線，也和團隊一起多次斬獲智慧零售方向的Hackathon冠軍。曾就職於微策略，阿里雲從事商業智慧產品與雲計算系統研發工作，擁有十多年的行業經驗。目前研究興趣主要包括可解釋機器學習，AutoML和雲原生機器學習系統方向。

在演算法專案落地過程中，如果只考慮機器學習相關部分，個人感覺最花時間的兩個部分是資料質量問題處理和模型實驗與迭代調優。在之前Fullstack Deep Learning[1]介紹的基礎上，我們在這篇文章中主要針對第二個問題做一些詳細的展開。

閱讀建議

一不小心，本文又寫的有點長……所以這裡大概給一個閱讀建議：

01、原則

先列舉一些模型最佳化過程中遵循的一些原則：

清晰的最佳化指標高質量Pipeline明確的實驗設計深入的結果分析

接下來我們逐步來分析與介紹。

02、總體介紹

2.1 什麼是一個好的指標

從廣義的指標定義來看，有幾個考量方面：

Actionable，可以指導具體行為。Accessible，簡單，容易理解。Auditable，可以進行驗證。

2.2 機器學習專案中的指標

在機器學習專案中，我們在遵循上述原則下，往往會定義不同型別的指標：

組織目標，例如增加整個公司的收入，降低成本，或者對社會的整體貢獻等。一般會比較宏觀，與具體技術的距離相對較遠。另外這些指標收到的影響因素也有很多，內外部因素都有。在技術專案實現週期，到能影響到組織目標的變化過程會非常緩慢。因此一般很難直接最佳化這個指標。業務指標，相對組織目標來說會更加具體和可衡量。注意在這個層面我們經常碰到一些情況是模型輸出預測是否符合使用者預期，這種較為模糊的指標定義往往難以衡量與改進。因此必須與使用者溝通，制定出明確可量化的指標來進行衡量。這個維度的指標也經常會比較複雜，從技術層面來看可能難以直接最佳化。模型指標，為了能快速迭代實驗，我們往往需要深入理解前面的組織目標，業務指標，再轉化為模型可以直接最佳化的指標，例如mae損失函式等。但這裡也需要非常小心，模型指標可能並未反映使用者的真實感受，或者與最終的業務目標有一些差距。

對於這幾類的指標，一個通常的做法是可以以不同的頻率在不同層級對這些指標進行評估驗證。例如在具體的實驗中，可以以非常高的每次試驗的頻率來評估模型指標是否有提升。在天或者周的級別去驗證模型效果的提升能夠帶來業務指標的提升。最後在月甚至更長的維度上去評估業務指標對組織整體目標的實現是否有正向促進作用。

實際專案中，往往會出現業務方面的指標不止一個的情況。例如我們既需要預測在細粒度上的squared error較低，又需要預測總量上的偏差較小。為了能較好的評估模型，我們一般會設定一個主要的最佳化指標（可以是多個誤差項的綜合），將其它指標轉化為限制條件。例如在模型預測時間不超過1秒的情況下，取得儘量高的AUC。

03、實驗流程

很多機器學習課程上介紹的做法和很多行業新人在進行實驗時會採取隨機嘗試的策略。例如，我先使用某種方法，得到了一個結果，然後腦子裡又蹦出一個新的想法，繼續嘗試新方法，看結果是否有提升，依此不斷迴圈。

But，這樣做的效率太低了，很多時候就算效果有提升，也並不知道為什麼，是否穩定，是否對最終的業務效果是正向的促進作用。因此我們更提倡採用資料分析驅動的方式來做各類建模實驗。在分析基礎上，實驗設計的出發點一般需要有明確的假設，然後透過實驗結果來驗證假設是否成立。一般的步驟如下：

分析：模型問題是什麼？提出假設：可能的根源問題是什麼？設計實驗：改進方案是什麼？執行與驗證：改進方案是否有效？迴圈迭代

另外在實驗涉及的嘗試方向上，資料相關的處理往往佔據了主要的位置，包括資料修正，轉換，更新，增強，取樣等，可能佔比在80%以上。剩下20%是與模型相關的嘗試。這也是業界的一個相對普遍的情況，需要在考慮實驗內容方向時多加判斷，避免做了一系列高大上的前沿模型嘗試，總體產出卻非常有限。

3.1 問題分類

對於模型中可能出現的問題，我們作如下分類：

程式碼實現中的bug。對於機器學習pipeline來說，很多情況下即使有隱藏的bug，程式也完全能跑通。這對問題排查造成了更大的困擾。超引數設定不合理。很多模型對各類超引數的設定比較敏感，需要針對不同的問題和表現進行超引數的調整。資料相關問題。資料量不足，分佈不均衡，出現錯誤的標籤，缺少特定資訊，有概念漂移問題等。模型選擇問題。針對特定的問題及資料情況，我們需要選擇合適的模型。

3.2 整體流程

為了避免這些問題，構建出高效，準確率高的演算法模型，我們可以遵循如下的通用步驟：

從簡單的pipeline開始，例如選擇最簡單的規則，或者基礎模型。以深度學習模型為例，我們可以選擇最基礎的MLP模型，adam最佳化方法，不加任何regularization，使用標準歸一化方法，選取一個子集資料進行嘗試。實現並跑通pipeline。確保模型能夠執行，並在小資料集上overfit，或復現一些已知結果。評估並分析結果。後續會詳細介紹分析手段方法。引數調優。對模型的各種引數，模型結構進行各種調整。資料與模型調優。修復資料中的問題，做資料增強，引入不同型別的資料，收集更多資料，或者特徵工程預處理方面的操作。模型方面可以使用更加高階/複雜的模型結構，引入ensemble等。

這方面比較好的資料可以參考Andrew Ng的《Machine Learning Yearning》[2]，後續我們也會做一些具體闡述。

04、實驗執行與管理

4.1 Pipeline

模型上線之後，需要有高質量的pipeline來進行系統化的執行，debug，及版本管理。這裡不做詳細展開。從實驗與模型最佳化角度看，對於經常需要嘗試迭代更新的部分，應該做好模組分割，便於靈活進行針對性的實驗。

實驗pipeline對執行效率會有更高要求，通常是針對整個流程中的一小部分，來反覆修改嘗試，快速獲取到實驗結果。舉例來說，如果我們想做一個新特徵的嘗試，應該基於歷史的特徵資料集來進行增量的嘗試，而不是修改原有的特徵工程程式碼，觸發全量的特徵構建流程。一個簡單的評估標準是，每次實驗執行的總時間中，有多少百分比的時間實際上是在做重複的操作。理想情況下，這部分重複執行的佔比要低於10%。

對於實驗pipeline的程式碼質量方面，一個簡單的原則就是越需要重複高頻使用的實驗，越需要做更好的抽象和程式碼質量保證。建議在notebook中寫完草稿後，複製到PyCharm等專業IDE中進行程式碼重構與質量檢查。

4.2 版本管理

在pipeline基礎上，我們需要對實驗使用到的各類依賴進行版本管理，主要包括：

資料版本，如果使用的產品帶資料版本，直接使用即可。否則可以考慮用sha1等檔案校驗碼來記錄資料的版本資訊。程式碼版本，對於庫函式這類有git管理部分的程式碼，可以直接使用git的版本號。對於臨時的notebook檔案，可以每天做一個notebook版本的備份。對於重要結果，例如當前最好效果，也可以隨時做版本備份。引數配置，大多數情況下，引數配置可以在程式碼或者資料的版本中cover。但需要額外注意使用了外部配置檔案的情況，對於這些配置檔案，也需要與實驗的其它執行組成來一起管理(例如放在同一個資料夾下)。模型版本，對於模型訓練非常耗時的場景，訓練出來的模型也需要進行版本管理，以便於後續的分析與重用。

實驗版本管理對於專案過程中review進度，確定下一步計劃，復現結果並部署上線等方面都非常重要。

05、初級建模調優

5.1 資料流驗證

首先檢驗data flow沒有問題。例如使用簡單的規則，替代模型模組，檢視整個pipeline的流程是否有問題。對pipeline中大塊環節的輸出做檢查。

5.2 跑通模型訓練

接下來將規則替換成真實的簡單模型，進行訓練與預測，看是否能跑通。過程中會出現各種拋錯，列舉一些最常見的bug：

Tensor shape錯誤預處理錯誤Loss function錯誤資料中有NaN/Inf等值沒有正確的設定訓練模式，或其它框架相關常見錯誤引數或資料處理問題導致的OOM庫版本不匹配導致的奇怪exception

應對策略：

使用標準化的流程pipeline，比如框架內建方法，或者自己整理的針對某類問題的標準receipe。搜尋StackOverflow，Github上相關問題，尋求解決方案。使用debugger和profiler進行深入除錯。藉助一些專用工具來輔助排查，例如tensor-sensor[4]。

5.3 在小資料集上過擬合

模型可以訓練了，我們會使用小批次資料來看是否能讓模型在這部分資料上過擬合。這裡會碰到的一些常見問題例如：

誤差不降反升誤差爆炸誤差震盪誤差停留在一個高位無法下降

應對策略：

誤差上升的可能原因，學習率太高，loss function定義錯誤誤差爆炸的可能原因，學習率太高，各種數值操作的問題，如exp，log，除法等誤差震盪的可能原因，學習率太高，原始資料問題如資料錯位，預處理bug等，可以進一步透過結果分析定位誤差停留在一個高位，可能由於學習率太低，最佳化器相關設定，正則項過大，模型過於簡單，loss function欠佳，部分資料有錯誤，沒有做資料歸一化，缺乏有效特徵等

5.4 模型引數搜尋

在模型可以在小資料量上正常最佳化後，接下來通常的建議可能是增加資料量並做一定的模型引數搜尋。不過根據我們的經驗，這部分的整體計算開銷較大，但回報率相對比較一般（可以參考AutoML文中的一些research結論）。所以如果模型訓練開銷不大的情況下，我們可以考慮在每天空閒時間（例如晚上下班後），掛一些自動引數搜尋的任務進行調優嘗試。而在工作時間段，還是應該集中精力做誤差分析和問題定位。

5.5 後續深入最佳化

在初始的pipeline跑通，模型可以產出有意義的預測之後，再接下來就逐漸開始進入深水區了。一方面我們要不斷降低模型訓練誤差，另一方面也要開始關注模型的泛化能力，根據場景的不同會出現各種複雜的表現，並需要我們在各類問題中進行權衡與選擇。從這裡開始，我們的實驗過程中會有很大一部分精力放在結果誤差分析，以及資料模型層面各類問題的處理上，具體可以參考下面的資料分析環節。

例如模型泛化能力差問題，可能由於train/test資料分佈變化，模型/超參複雜度過高，data leak，資料量不足，有干擾特徵，缺乏資料歸一化操作等。具體原因可以根據詳細的誤差分析來挖掘。

對於深度學習模型的最佳化，還有一些非常不錯的資料可以參考，例如Karpathy[5]的這篇blog post。

06、深入調優分析

構建有效模型的關鍵是能夠迅速且準確的定位到當前模型失敗的原因具體是什麼。這也是結果分析的主要目標。

理想情況下，我們需要能明確定義：

模型當前問題，例如在節假日期間，辦公型門店的預測銷量不準。各個問題導致的誤差佔比，例如上述問題在總體誤差中佔了12%。問題對應的典型資料集，例如我們可以收集一系列節假日，辦公型門店的歷史資料，用於後續調優改進的檢驗集。

當然，如果以整體思維來考慮，我們在分析過程中還需要考慮：

模型的錯誤型別有哪些，是否能在目前的最佳化指標中反映出來。使用者真實體驗如何。模型錯誤可能導致的最嚴重後果是什麼。

關於產品與使用者體驗方面，可以參考Google這篇非常好的文章[6]中的闡述。

6.1 資料分析

人工檢查樣本，獲取一個對資料的整體感受。比如可以注意觀察資料是否分佈均勻，是否有重複資料，label是否正確，是否能直觀發現比較重要的特徵。在任何時候，親眼看一看資料細節都會是很有幫助的。

嘗試讓自己作為演算法來進行預測，例如選取幾條資料，看是否能根據自己的理解作出正確的預測。以此來更好的理解預測目標，資料狀態，以制定模型/規則策略。

統計分析，藉助一些工具如pandas_profiling等做統計和視覺化分析。例如繪製相關度矩陣，觀察特徵與預測目標之間的關聯度，或者特徵分佈的箱線圖，觀察是否有異常值離群值等。

統計分析中還有很重要的一點是Drift分析，觀察輸入和預測目標隨著時間變化是否出現了分佈偏移。這對我們後續模型設計，以及構建驗證集的分割方式選取上也會有參考意義。

人工檢查模型輸出。指標一般是一個統計型結果，而往往容易覆蓋一些比較嚴重的問題。以LinkedIn推薦系統的為例，他們設計了一個向用戶推薦感興趣的群組功能。一個比較簡單的方法是推薦包含公司名的熱門群組，結果給Oracle的員工推薦裡有一個排名挺高的群組名叫"Oracle Sucks!"。如果只關心指標，可能只是非常微小的一個precision/recall變化變化。但對於使用者感受來說，差別是巨大的。

6.2 模型指標分析

選取少量資料（例如1000條），確保模型可以訓練並過擬合。後續逐步增加訓練資料觀察資料量增加對模型效果的影響。這麼做一方面可以在少量資料上驗證整體訓練的pipeline，最佳化器模型結構等都可以正常工作。另一方面獲取到資料量增加情況下模型效果的變化，也有助於後續判斷在模型調優時是否還需要收集更多的資料或進行資料增強操作以提升效果。

與已知結果相比來判斷當前model的效果處於一個什麼水平。如果沒有對比，我們只能與真實值比較與分析模型表現，但並不知道模型指標的上下限大致情況如何。對於模型效果下限，可以使用簡單的baseline model來對比，例如直接輸出佔比最大的類別作為最簡單的分類模型。對於模型的上限/調優目標，我們可以選擇幾個可能的來源，例如公開發表的類似問題的模型效果，利用已知SOTA模型跑出來的對比效果（例如ResNet，BERT等），或者與人工專家預測的結果進行對比。這些上下限模型給出的結果，可以作為更多的資訊來源，幫助我們分析目前模型的問題在哪。例如發現人工預測在某些subgroup中明顯超過了我們的模型效果，則可以深入分析其中是否包含了未知的業務資訊需要捕捉。

Learning curve檢查，觀察模型在訓練集和驗證集的表現，也就是經典的bias/variance trade-off，判斷模型狀態是否為欠擬合/過擬合，從而引導到控制模型複雜度的實驗嘗試。另外train，valid的效果相差較大，也有可能是在特徵資料處理上出現了data leak，資料分佈偏移，資料離群點等相關問題，可以透過資料分析視覺化或模型解釋手段來進行排查。後續涉及到特徵工程修復，異常資料剔除，train/valid分割方式改進或目標函式的修改等操作。

也可以繪製一些更復雜的模型指標視覺化，例如混淆矩陣，ROC曲線，Calibration曲線等，幫助評估模型問題。例如Calibration曲線走勢相反，可能是train/test資料分佈不一致導致。如果出現走勢平穩，可能是由於特徵缺乏區分度引起。

另一大塊是模型解釋方法的使用。例如檢視模型的特徵權重，feature importance，或者藉助一些黑盒解釋手段如LIME，SHAP等。藉助這些工具，可以輔助我們判斷模型為何給出了不符合預期的預測。例如當我們發現某一組樣本的預測整體偏高，就可以透過模型解釋工具找到對這些樣本的預測有正向影響最大的那些特徵是哪些。另外一個例子是在特徵選擇最佳化中，我們可以在訓練資料中加入隨機值形成的一列特徵，然後觀察模型訓練後這個隨機特徵的重要度排名。一般在這個隨機特徵重要度之下的那些特徵，很可能並不具有預測能力，可以考慮移除。

還有類似tensorboard之類的模型配套開發工具，可以更進一步提供模型訓練過程中更加詳細的視覺化資訊，包括每一層的gradient變化情況，有助於我們針對性分析神經網路中出現的最佳化問題或數值問題。我們也可以針對不同的模型對應開發類似的“SDK”，提高我們排查模型問題的效率。

對於分類問題，可以在決策邊界上找出模型不確定性較大的例子，再進行分析看是否是缺少資料，還是相關label有錯誤。Active learning也是類似的想法。

6.3 Generalize模型問題

在分析模型問題時，一個關鍵的目標是能夠找到具有普遍意義的問題（而不是特例），並能準確描述這個問題的共通特點。

前面提到的各類模型指標分析與視覺化，都可以進一步分割資料集，做多個維度上的指標分析。分割的維度的選擇可以從資料中已經存在的業務維度開始，例如產品品類等，後續可以根據分析結果，構造一些特定的分組。對於不同維度下發現的問題，例如預測整體偏差較大或誤差較大，資料量偏少等，引導到具體的validation集分割策略，新資料收集，重取樣，預測結果後處理，或者分別構建模型等實驗手段。

Top-k方法，觀察預測最準的，最差的，和最不確定的top-k個樣本。如果樣本過多，則可考慮聚合到上一個層級來分析。透過尋找預測最準的部分，可以分析出模型中較為有效的特徵，並確認這些是符合邏輯的。例如有個經典的例子，在圖片分類問題中，模型學習到判別北極熊的特徵其實是來自於雪地，而並不是動物本身。對於預測最差的部分，可能可以排查到是否是標籤錯誤，或者特徵資料中有異常。也可能是缺少了某些重要的資訊輸入，需要引入額外資料或構建新的特徵。最不確定的樣本方面，例如對一個二分類模型，我們可以考察模型預測輸出在0.5左右的sample。這裡往往可能存在有衝突的label訓練樣本，或訓練資料不足的問題。

除了按照維度分割資料來評估指標，我們還可以使用聚類，降維等手段來輔助。例如使用k-means/k-prototypes，DBSCAN等聚類方法，將top誤差項進行聚類，檢視各個類的代表性例子，以及判別一些離群點。同理，在特徵維度較高的情況下，使用PCA，UMAP，TriMAP等降維方法，再進行聚類，也是一種常見方法。甚至我們可以對誤差大小本身來構建一個預測模型，然後根據模型學習到的結構和權重來輔助我們發現誤差問題中的隱藏pattern。

6.4 模型報告

對於上述的各類分析發現，我們還可以設定相應的模型報告模板，例如可以參考Model Cards[7]的形式，總結問題，並向業務相關人員提供更直觀易理解的展現形式，而不再是一個黑盒模型。

6.5 誤差分析深入

6.5.1 誤差分類

在A Characterization of Prediction Errors[8]中，作者建議我們可以把預測誤差分為四類：

Mislabeling errors，標籤錯誤。即原始的訓練資料裡就有問題，例如資料漏傳，資料處理錯誤等。Learner errors，最佳化錯誤或目標函式引入的誤差，例如正則項。透過修改正則項，檢查是否可以在目標函式error與泛化error之前取得平衡。Representation errors，特徵不足，或模型表達能力不足。技術上無法與mislabeling error區分，可以使用consistent learner(無正則項的lr，1-nn)，找到invalidation set人工確認。Boundary errors，資料不足。泛化錯誤。檢測方式：將資料加入訓練集後，看錯誤是否仍然存在。Uncertainty sampling for active learning也是基於這個思想。

根據這個誤差分類，可以設計一些迭代調優方式：

使用無正則項的學習器(1-NN, LR)，修復label error(correct label)和representation error(add feature)，反覆迭代。驗證boundary error，透過加入正則項來平衡泛化誤差與learner error。

6.5.2 Identifying Unknown Unknowns

在這篇文章[9]中，作者提出了處理模型unknown unknowns錯誤的方法，可以作為前面誤差聚類方法的補充。其中第一步是做Descriptive Space Partitioning：

首先獲取需要調查的資料集X，例如迴歸問題，選擇誤差top 10000條，或者分類問題，選擇confidence很高但預測錯誤的條目。候選特徵pattern集合Q，透過頻繁項挖掘，獲取到調查資料集X中特徵組合的頻繁項。開始迭代搜尋分割條件，其中pattern q來自於集合Q，計算X中符合q的條目數/g(q)，取argmax時的q值。將第三步中找到的q加入到partition條件集合P中，同時將其從候選集合Q中移除，另外也將q覆蓋的條目從X中移除，繼續第3步，直到X中所有條目都被覆蓋。最終的集合P就是partition方案，如果一個條目屬於多個q，則取距離中心最近的那個q。

這裡g(q)的定義是組內特徵距離和 - 組間特徵距離和 + 組內信心指數和 - 組間信心指數和 + size(q)，如果是迴歸問題，信心指數(confidence score)即為預測值。這個DSP方法總體上相比kmeans，entropy更小，不過在有些資料集上的優勢並不明顯。

接下來需要人工分析這些錯誤聚類中的sample，作者提出了Bandit for Unknown Unknowns方法來提高檢查分析的回報效率。背後的思想還是多臂老虎機演算法，具體操作如下：

在前k步(k等於partition數量)，從每一個partition中取樣來query oracle，看是否是unknown unknowns(or 具有代表性的模型問題？)。後續使用UCB方法來取樣來選擇partition。評估收益的utility function，是否是unknown unknowns減去oracle驗證的cost。

6.5.3 Error Analysis Visualization

Errudite[10]，主要使用於NLP任務，跟ACL 2020上CheckList的想法有點類似，但是從誤差分析角度出發，並提供了工具層面的支援，便於更高效率的誤差分析。核心的三個步驟：

分析error sample，構建起誤差背後共通特性的DSL描述。將上述的DSL描述作為filter，apply到全量資料上，評判誤差佔比。使用conterfactual方法來分析產生誤差的具體原因。

Google的這篇教程[11]中也提出了非常類似的框架。

CrossCheck[12]，除了指標的更細維度的對比展示，還提供了notes記錄等協作功能，有點意思。

Dark Sight[15]。結合了模型壓縮和降維來對樣本進行視覺化，相比t-SNE這類降維方法，Dark Sight可以比較好的還原出模型的決策行為。例如在MNIST問題中，3和5兩個類別的邊界上，可以看到很多長得像3的5和長得像5的3，而t-SNE這類降維方法則沒有這種性質，無法體現出模型在預測confidence上的平滑變化。應用這類技術，我們可以更好的理解模型決策，並針對誤差資料點做更深入的分析。美中不足的是這個方法主要用於分類問題，如何應用於迴歸問題還需要進一步的探索。

07、相關測試

排查與調優中，我們會發現許多資料，處理流程，模型輸出等方面的問題。除了對這些問題進行修復，我們也需要注意積累這些問題對應的系統性測試case，並新增到pipeline的測試流程中去。這對後續模型的各類迴歸驗證測試，上線與運維都會有非常大的好處。由於本文並不是以MLOps為主題，這裡只簡單列舉一下可以開發部署的測試型別。

資料輸入測試，可以考慮使用各類資料質量檢查庫，比如著名的:https://github.com/great-expectations/great_expectations

資料轉換測試。可以在資料進入到模型訓練之前，加一層對訓練集驗證集的測試。例如對於feature encoding，空值處理，欄位型別，以及train/valid的資料分佈情況等做一些檢查。

輸出測試，例如一些固定的重要/hard case，輸出合理的值。這些測試case還有助於在部署後進行快速驗證，尤其是在訓練與serving框架有所不同的情況下，就顯得更為關鍵。

系統層面整合測試，驗證整體pipeline，上下游資料流和多個模型的協同。另外從終端使用者層面出發，需要考慮各類安全性測試，防止adversarial attack或各類abuse操作。

08、工程化與上線

在選擇具體上線的模型時，需要參考多個模型之間的離線評估比較，穩定性，效能，準確率，可解釋性，線上更新能力等多方面綜合考慮。

模型具體的上線和運維是另一個比較大的話題，可以採用Interleaving，A/B test，影子模型等手段，實現模型的持續部署與整合。

還有一個很現實的問題是當線上模型出現問題時，我們如何處理，是否有plan B流程可以給出一個使用者可以接受的預測值。

各類監控體系，運維平臺等也非常重要。前面提到的很多線下的分析排查工具，也可以為線上問題排查定位服務。持續的監控，在效果下降時觸發模型自動更新訓練，實現模型效果的持續穩定。

另外有一些公司分享了他們內部的實驗管理框架，例如：

Airbnb在這篇文章[16]中介紹了他們的實驗管理平臺，不過主要側重在海量的實驗結果檢視與分析上。

Uber在這篇文章[17]中介紹了他們的大規模回測平臺，更接近於我們之前提到的離線的模型開發與驗證環節中使用的工具。而這篇文章[18]中介紹的實驗平臺，則主要服務於在線上進行各類複雜測試，併為他們迭代演進產品與服務設計提供資料指導。

最後，對於線上實驗，還有一些開源專案可以參考，例如：Wasabi[19]，PlanOut[20]等。

09、Some Future Work

與AutoML結合：Why we need hybrid approach[21]：人工建模往往效率更高，在比較少的嘗試下達到較好的模型效果。主要操作是更換模型或者預處理方法。AutoML往往最終達到的效果更高，但需要的嘗試次數往往遠遠大於人工。會有大量的操作花費在超參搜尋調優上。

Human-in-the-Loop & AutoML[22]：

也是一個非常有意思的工作，用資料庫系統的分層思想來考慮human-in-the-loop人機結合AutoML系統的設計。例如像SQL般易於使用的DSL來便於使用者輸入問題定義與描述，然後在下層有最佳化器去形成經過最佳化的物理執行計劃（在這裡變成了ML workflow），並最終返回結果。這個從成熟軟體系統中汲取營養的想法還是很有想象空間的。延展一下聯想到我們做演算法的debugging，非常缺少類似Linux, JDK下各類tracing工具。所以軟體工程的排查調優，一般來說都是能用工具確定性的抓到整個系統到底是如何在執行的，從應用層一直drill down到系統資源層都能得到相應的資訊。而模型和資料的問題排查，很多時候只能在應用層改一些引數，觀察這個黑盒的產出，成了所謂的“玄學”。如何能在資料，模型上開發出一套類似的tracing工具，把模型效果的排查成為相對確定性的追蹤，是一個值得深入思考的方向。從上一點延展到資料流方面，軟體工程中也有很多值得借鑑的思想。例如編譯器可以幫助程式設計師進行程式碼邏輯，型別等方面的自動化檢查，提前發現問題。但是到了資料流這塊（例如ETL），往往都只能到執行起來了才能發現問題。是否能夠開發一些工具，做到資料轉換邏輯和schema（可能還需要一些統計資訊）結合的靜態檢查，來保障資料流的質量？同理DevOps方面也有很多機器學習系統設計可以借鑑的地方，包括把資料因素結合進來，形成一套新的測試運維體系，達到持續整合，持續交付，持續調優的系統形態等（聯想的有點遠了……）。

Machine Teaching[23]：

跟上面的思路類似，考慮人與模型的互動式開發與應用，從軟體工程/人機互動角度去設計整體系統越來越成為一種趨勢。下面這個對比表格也是非常典型的體現：

外部連結：

[1] https://zhuanlan.zhihu.com/p/218468169[2] https://www.deeplearning.ai/programs/[3] https://helix-ml.github.io/[4] https://explained.ai/tensor-sensor/index.html[5] https://karpathy.github.io/2019/04/25/recipe/[6] https://pair.withgoogle.com/chapter/errors-failing/[7] https://arxiv.org/abs/1810.03993[8] https://arxiv.org/abs/1611.05955[9] https://arxiv.org/abs/1610.09064[10] https://github.com/uwdata/errudite[11] https://developers.google.com/machine-learning/guides/good-data-analysis[12] https://pnnl.github.io/crosscheck/[13] https://www.microsoft.com/en-us/research/uploads/prod/2018/04/AnchorViz-camera-ready.pdf[14] https://www.microsoft.com/en-us/research/video/anchorviz-facilitating-semantic-data-exploration-and-concept-discovery-for-interactive-machine-learning-2/[15] http://xuk.ai/darksight/[16] https://medium.com/airbnb-engineering/https-medium-com-jonathan-parks-scaling-erf-23fd17c91166[17] https://eng.uber.com/backtesting-at-scale/[18] https://eng.uber.com/xp/[19] https://github.com/intuit/wasabi[20] https://github.com/facebook/planout[21] https://arxiv.org/pdf/2005.01520.pdf[22] http://sites.computer.org/debull/A19june/p59.pdf[23] https://www.microsoft.com/en-us/research/publication/interactive-machine-teaching-a-human-centered-approach-to-building-machine-learned-models/