1.1 機器學習的生命周期

機器學習永遠不會真正完成。無論是技術上還是結構上，它也不會在任何一個地方開始或者停止。機器學習模型的開發人員通常希望他們的工作十分簡單，只需要收集一次數據，訓練一次模型。但是，這種情況很少發生。

一個簡單的思想實驗便可以幫助我們理解其中的原因。假設有一個機器學習模型，我們正在評估這個模型是否足夠好（參考一個確定的閾值）。如果它沒有達到我們的要求，那么數據科學家、商業分析師以及機器學習工程師通常會針對如何理解模型的故障并加以改進來進行協作。正如你可能想到的，這將涉及大量的工作：可能會修改現有的訓練管道以改進一些功能，還可能會添加或刪除一些數據，以及重構模型以迭代已經完成的工作。

相反，如果模型效果很好，整個組織都會為之興奮。自然的想法是一次不成熟的嘗試便取得了如此大的進步，那么想象一下，如果我們更加努力，使模型更加復雜的話，將會取得多么好的成果。你猜對了，這通常涉及修改現有訓練管道、更改特征、添加或刪除數據，甚至可能重構模型。無論哪種方式，無論相同的工作我們做了多少，我們做的第一個模型都只是下一步工作的起點。

讓我們一起看一下機器學習的生命周期，或者說機器學習循環的細節（如圖1-1所示）。

由于機器學習都是由數據開始，所以讓我們從圖的左側開始更詳細地了解這個循環。我們將詳細了解每個階段，并且在這個購物網站的背景下，解釋每個階段有哪些人參與以及他們的主要職責是什么。

1.1.1 數據收集與分析

首先，團隊會盤點并評估所擁有的數據。團隊成員需要確認所需數據是否齊全，之后優先將數據用于業務和組織需求。接著他們必須收集和處理數據。

盡管涉及程度因公司而異，但與數據收集及分析相關的工作基本上涉及了公司的所有人。例如，業務分析師會存在于金融、會計或者產品團隊，每天使用平臺提供的數據進行分析。還有數據和平臺工程師也許會搭建可重復使用的用于提取、清洗和處理數據的工具，盡管他們可能不涉及任何的業務決策。（在小公司中，他們也許全是軟件工程師或產品工程師。）有些地方會有正式的數據工程師的角色。還有一些數據科學家、產品分析師和用戶體驗（U X）研究員會使用這個階段產出的數據。

對于網店運營商YarnIt，絕大多數的組織成員都參與了這一步驟，其中包括業務與產品團隊這些對要優化的業務領域最了解的團隊。舉個例子，他們可以決定是小幅增加每單銷售利潤對企業更重要，還是稍微增加訂單頻率更有意義。他們能夠指出高、低利潤產品的問題與機會，并且將客戶分類為高利潤客戶和低利潤客戶。產品工程師與機器學習工程師也會參與其中，考慮如何處理所有的數據。站點可靠性工程師會對整個管道提出建議和決策，使其更加可靠、易于監控和管理。

為機器學習管理數據是一個非常復雜的話題，我們會在第2章專門討論數據管理原則，訓練數據稍后將在第4章和第10章中進行討論。目前，假設數據收集和處理系統的正確設計和管理是所有好的機器學習系統的核心要素。一旦數據被存儲在合適的位置并轉換為合適的格式，我們就將開始訓練模型。

1.1.2 機器學習訓練管道

機器學習訓練管道由數據工程師、數據科學家、機器學習工程師和站點可靠性工程師指定、設計、構建和使用。它們是專用的提取、轉換、加載（ETL）數據處理管道，用于讀取未處理的數據，并將模型的結構與機器學習算法應用于數據^[1]。它們的工作是利用訓練數據生成完整的模型，以備評估和使用。這些模型要么一次生成完整的，要么以各種方式增量生成。有些模型不完整是因為它們只覆蓋了一部分可用數據，而有些則是因為在范圍上不完整，它們被設計為只覆蓋整個機器學習的一部分。

訓練管道是機器學習系統中唯一直接明確使用機器學習特定算法的部分，但即使在這里，這些算法也大部分被打包在相對成熟的平臺和框架中，如TensorFlow和PyTorch。

訓練管道也是機器學習系統中為數不多最初就不可避免地要關注算法細節的部分。在機器學習工程師大概依靠相對成熟的庫構建并驗證了一個訓練管道之后，該管道可以安全地被其他人重用和操作，而不需要許多專業的統計知識^[2]。

訓練管道面臨著與其他任何數據轉換管道相同的可靠性挑戰，以及一些特定于機器學習的挑戰。最常見的機器學習訓練管道故障如下：

● 數據缺失

● 正確格式數據的缺失

● 實現數據解析或機器學習算法時的軟件缺陷或報錯

● 管道或模型的錯誤配置

● 資源不足

● 硬件故障（由于機器學習的計算十分龐大且持續時間長，某種程度上這是一個常見故障）

● 分布式系統故障（為了避免硬件故障，會使用分布式數據處理系統進行訓練，所以這經常發生）

所有這些故障也是常規（非機器學習）ETL數據管道的故障模式的特征。但是，機器學習模型可能會因數據分布、數據丟失、采樣不足或常規ETL世界中未知的一系列問題而毫無征兆地失敗^[3]。第2章將詳細介紹一個具體示例，它所依據的想法是，數據丟失、錯誤處理數據或無法使用數據子集是機器學習訓練管道失敗的普遍原因。在第7章和第9章中，我們將討論如何通過監控訓練管道來發現這些問題（通常稱為分布的變化）?，F在，讓我們記住，由于這些不易察覺的故障模式，機器學習管道確實比其他數據管道更難可靠地運行。

如果還不清楚的話，機器學習訓練管道絕對完全是一個生產系統，像服務二進制文件或數據分析一樣值得關注。（如果你所處的環境中，除了你之外，其他人都不相信這一點，那么知道有足夠多的反例可以最終說服他人可能會令人略感欣慰。）舉個有關“如果你對生產不夠重視會發生什么”的例子，我們知道有這樣的故事：公司建立的模型是由已經離開公司的實習生創建的，沒有人知道如何重新生成它們。這說起來好像沒什么，但我們建議你永遠不要陷入那種境地。養成一個習慣，把你所做的事情寫下來，并將其轉化為自動化的東西，這會在很大程度上避免我們之前提到的結果。好消息是，這完全可以從小規模開始，只需要手動操作，不需要特別的重復性。然而，要想獲得成功，需要自動化和審計，我們認為，越早將模型訓練自動化并進行一些簡單的正確性檢查和模型保存越好。

在任何情況下，假設我們能夠成功構建一個模型，我們都需要將其集成到面向客戶的環境中。

1.1.3 構建與驗證應用程序

機器學習模型基本上是一組需要解鎖以提供價值的軟件功能。你不能只盯著模型，你需要審問它——問它一些問題。最簡單的方法是提供一個直接的機制來查找預測（或報告模型的另一方面）。然而，最常見的情況是我們必須與更復雜的東西集成：無論模型具有什么目的，通常最好通過將模型與另一個系統集成來實現。將機器學習模型集成到應用程序中的工作將由產品和業務職能部門的員工指定，由機器學習工程師和軟件工程師完成，并由質量分析師監督。關于這方面的更多細節，請參見第12章。

至于我們的在線購物網站yarnit.ai，各行各業和世界各地的人都可以在這里找到最好的針織或鉤編紗線，所有這些都是基于AI的推薦！作為一個示例，讓我們研究一個向購物者推薦額外購買的模型。該模型可以獲取用戶的購物歷史和當前購物車中的產品列表，以及其他的一些方面，如他們通常要求配送的國家、他們通常購買的價格范圍等。該模型可以使用這些功能生成一個購物者可能會考慮購買的產品的排名列表。

為了向公司和用戶提供價值，我們必須將該模型集成到網站中。我們需要決定在哪里利用模型進行查詢以及如何處理查詢結果。一個簡單的答案也許是，當用戶考慮結賬時，在購物車下方的水平列表上顯示一些結果。這看起來是一個合理的開始，為購物者提供一些實用性，也可能為YarnIt帶來一些額外收入。

為了能夠確定我們在集成的相關方面做得如何，系統應該將顯示的內容記錄在日志中，還要將用戶之后采取的行動記錄下來，即他們是否將顯示的商品添加到購物車并最終購買它們。通過記錄這些事件，集成將為我們的模型提供新的反饋，以便它能夠訓練自己的推薦質量并做出改進^[4]。然而在這個階段，我們會簡單地驗證整個流程的有效性：加載到服務系統中的模型、由Web服務器應用程序發出的查詢、顯示給用戶的結果、被記錄的預測、被存儲以用于未來模型訓練的日志。接下來是評估模型質量和性能的過程。

1.1.4 質量和性能評估

機器學習模型當然只在有效時才是實用的。事實證明，要真正回答這個問題，需要進行非常詳細的工作——首先我們必須決定如何量化機器學習模型的有效性，以及我們將如何根據目標結果來評估模型性能。這通常涉及識別我們試圖創建的效果，并在不同子集（或切片）上利用代表性查詢或用例測量它。第5章將對此進行更詳細的介紹。

一旦我們確定了要評估什么，就應該進行離線評估?？紤]到這一點，最簡單的方法是進行一組我們認為具有代表性的查詢并分析結果，將返回結果與一組“正確”或“真實”的答案進行比較。這將幫助我們確認模型在生產環境中的工作狀況。當我們對模型的基本性能有信心的時候，無論是實時發布還是灰度發布，我們都可以進行初始集成。在實時發布中，該模型會占用實時生產流量，這會影響到網站和相關系統等。如果我們足夠小心和幸運，那么只要監控好關鍵指標以確保用戶體驗不會受到損害，這就是一個合理的步驟。

灰度發布包括查詢模型并記錄結果，但當用戶看到它時，不會在網站上積極地使用它。這可能讓我們對模型與We b應用程序的技術集成充滿信心，但對模型的質量可能不會有太多信心。

最后，還有一個中間方案：我們可以為應用程序構建有時能讓一小部分用戶使用模型的功能。雖然選擇這一小部分用戶是一個更高等級的話題，超出了本書范圍^[5]，但總體想法很簡單：在一些查詢中嘗試該模型，并同時在集成與模型質量方面獲得信心。

一旦確信該模型不會損害用戶體驗，并且還會幫助用戶（以及我們的收入，希望如此?。?，我們就差不多準備好發布了。但首先，我們仍需要關注監控、測量和持續改進。

1.1.5 定義與度量服務等級目標

服務等級目標（Service-Level Objective，SLO）是特定度量的預定義閾值，通常稱為服務等級指標（Service-Level Indicator，SLI），用于定義系統是否按照要求運行。一個具體的例子是“99.99%的HTTP請求在150 ms內成功完成（即返回20開頭的代碼）”。SLO是站點可靠性工程師所擅長的領域，但對于指定產品需要做什么和如何對待用戶的產品經理，以及數據科學家、機器學習工程師和軟件工程師來說，SLO也是至關重要的。一般來說，確定SLO是具有挑戰性的（https://www.alex-hidalgo.com/the-slo-book），而為機器學習系統指定SLO具有雙重挑戰，因為數據中甚至我們周圍世界中的細微變化的方式，都會顯著降低系統的性能。

話雖如此，在考慮機器學習系統的SLO時，我們可以從區分顯而易見的關注點來開始。首先，我們可以使用服務、訓練和應用程序之間的劃分。第二，我們有四個傳統的黃金指標（https://oreil.ly/hl4Vd）（延遲、流量、錯誤、飽和度）之間的區分，以及機器學習操作的內部區分，它們本身遠不如黃金指標更加通用，但并不完全特定于某一領域。第三，我們有與機器學習應用程序優化工作相關的SLO。

讓我們更加細致地看一下將這些關于SLO的想法直接應用于yarnit.ai的一些簡單建議。我們應該為每個系統設置獨立的SLO：服務、訓練和應用程序。從模型服務來看，我們可以像對待任何其他系統一樣，簡單查看一下錯誤率。對于訓練，我們應該查看吞吐量（當模型的復雜性相當時每秒訓練的樣例數或訓練數據的字節數）。我們還可以為完成模型訓練建立一個整體SLO（例如，95%的訓練運行在幾秒內完成）。在應用程序中，我們應該監控諸如最終顯示的建議數量，以及對模型服務的成功調用數量等指標（從應用程序的角度來看，這可能與模型服務系統報告的錯誤率匹配，也可能不匹配）。

然而，請注意，這些示例都不是關于模型的機器學習性能的。為此，我們需要設置與應用程序本身的業務目的相關的SLO，并且這方面的度量需要的時間可能比我們預想中的要長。模型生成的建議和模型排名搜索結果的點擊率對于我們網站來說也許是一個良好起點。我們還應該為該模型的收入建立一個端到端的SLO，并且不僅在總體上，還應該在我們客戶的合理子集（按地理位置或按客戶類型）中進行衡量。

我們將在第9章對此進行更詳細的研究，但目前請你接受有一些合理的方法可以在機器學習中實現SLO，并且它們涉及許多其他非機器學習SLO話題中使用的技術（盡管由于機器學習工作的細節我們需要更久的時間探討此類話題）。但是，不要讓復雜性妨礙了基本事務。歸根結底，產品和業務領導必須明確他們可以容忍哪些SLO，不能容忍哪些SLO，這樣公司的生產工程資源才能集中用于實現正確的目標。

一旦收集了數據，構建了模型，將其集成到我們的應用程序中，測量了其質量，并明確了SLO，我們就可以進入激動人心的發布階段了！

1.1.6 發布

現在，我們將第一次從客戶那里直接獲得輸入！產品軟件工程師、機器學習工程師和站點可靠性工程師都在這里一起工作，將我們最新版本的應用程序交付給最終用戶。如果我們使用的是基于計算機或移動端的應用程序，這將涉及軟件版本發布以及這些發布所需的所有質量測試。然而，在我們的案例中，我們發布了一個新版本的網站，其中將包含由機器學習模型驅動的推薦和結果。

發布機器學習管道與發布任何其他線上系統有共通的部分，但也有很多特定屬于機器學習系統的問題。關于一般線上系統的發布建議，請參閱由Betsy Beyer等人編輯的Site Reliability Engineering：How Google Runs Production Systems一書（O'Reilly，2016）第32章（https://oreil.ly/OsNL3）。包括基本的檢查/觀測、發布的控制以及回滾在內的這些措施是必需的，一個沒有定義回滾計劃的發布是十分危險的。如果你的基礎設施實現回滾操作十分困難，或者根本不允許回滾，我們強烈建議你在發布之前先解決此問題。下面將詳細介紹一些特定于機器學習的問題。

模型即代碼

請記住，模型與訓練系統二進制文件、服務路徑和數據處理的代碼一樣，都是代碼。部署一個新模型一定會使你的服務系統崩潰并破壞你的在線推薦模型。部署新模型甚至會影響某些系統中的訓練（例如，使用遷移學習開始訓練另一個模型）。以相同的方式對待代碼和模型發布很重要：盡管一些組織在（比如）假期發布新模型，但模型完全有可能出錯，而且從某種程度上說，如果發生這種情況，就需要在短時間內進行代碼修復。在我們看來，它們具有同等的風險，應該采取相同的應對措施。

緩慢發布

在部署新版本的在線系統時，我們通常能夠逐步進行部署，從所有服務器或用戶的一小部分開始，只有當過一段時間我們對系統的正確運行和機器學習改進的質量有信心時才會逐步擴大規模。這里要明確的是，我們需要盡力限制損失并在兩個維度上獲得信心：用戶和服務器。如果我們碰巧生產了一個糟糕的系統或模型，我們肯定不想讓它影響到所有用戶；相反，我們首先將它展示給一小部分終端用戶，然后逐漸增長。類似地，對于我們的服務器群，如果碰巧構建了一個無法運行或運行不佳的系統，我們也不想它影響到所有的服務器群的計算空間。

其中最棘手的方面是確保新系統在部署過程中不會干擾舊系統。對機器學習系統來說，最常見的是通過中間存儲工件來實現。具體來說，格式的變化和語義的變化會導致數據解釋中的錯誤。第2章會介紹這些內容。

發布，而不是重構

“每一次改變盡可能少”這種常見的原則適用于許多系統，但在機器學習系統中尤為明顯。整個系統的行為很容易發生變化（通過底層數據的變化等），因此在任何其他環境中都很微不足道的重構可能導致無法找到問題所在。

在數據層隔離部署

在進行漸進式上線時，請記住必須在數據層以及代碼/請求/服務層進行隔離。具體來說，如果新模型或服務系統的日志輸出被舊版本代碼或模型使用，則對問題的診斷可能會十分漫長且棘手。

這不僅是一個機器學習問題，未能將新代碼的數據路徑與舊代碼隔離開來，在過去幾年中導致了一些驚人的運行事故。盡管機器學習系統中的故障往往更微妙且更難檢測，但這可能發生在任何處理數據的系統上，這些數據由系統的不同部分產生。

在發布期間測量SLO

確保你至少有一個能夠顯示最新和最敏感指標的儀表盤，并在發布期間跟蹤這些指標。當你找出最關心的指標以及最有可能表明某種發布失敗的指標時，可以將這些編碼到一個服務中，如果未來出現問題，該服務會停止發布。

回顧發布

無論是手動還是自動，確保在任何類型的發布過程中進行監控。較小的組織或較大的（或更不尋常的）發布應該由人監控。如前所述，當你對其有信心時，便可以開始依靠自動化系統來完成此操作，并且可以顯著提高發布速度！

1.1.7 監控和反饋循環

與任何其他分布式系統一樣，關于機器學習系統功能是否正確運行的信息是有效且可靠地操作它的關鍵。確定“正確”運行的主要指標顯然仍是產品和業務人員的職責。數據工程師將識別信號，軟件工程師和站點可靠性工程師將幫助實施數據收集、監控和發出警報等。

這與之前的SLO討論密切相關，因為監控信號通常直接用于SLO的選擇或構建。在這里，我們稍微深入地探討一下監控信號的類別：

系統健康或黃金指標信號

這些與任何非機器學習信號都沒有什么不同。將端到端系統視為數據提取、處理和服務系統，并相應地對其進行監控。進程是否正在運行？他們是否有改進？是否有新數據到達等（第9章會有更多詳細信息）。機器學習的復雜性很容易讓人分心。然而，重要的是，要記住機器學習系統也是系統。它們具有所有與其他分布式系統相同的故障模式，以及一些新穎的故障模式。不要忘記最基本的，這是黃金指標監控方法背后的理念：找到能夠代表系統整體行為的通用的、高級別的指標。

基本模型健康或通用機器學習信號

檢查機器學習中的基本模型健康指標與檢查系統健康等價：它不是特別復雜，也不是與領域緊密耦合，而是包括關于建模系統的基本和代表性的事實。新模型是否符合預期大??？它們可以無誤地加載到我們的系統中嗎？在這種情況下，關鍵的標準是，是否需要了解模型的內容才能進行監控。如果不需要，所做的監控就是基本模型健康問題。這種與模型內容無關的方法具有很大的價值。

模型質量或特定領域信號

最難監控和檢測的是模型質量。在與運行相關的模型質量問題和改進模型質量的機會之間并沒有嚴格的界限。例如，如果我們的模型為我們網站上購買針而不是紗線的人所生成的推薦很差，這可能是一個改進模型的機會（如果這種質量水平滿足發布標準），或者這可能是一個需要立即響應的緊急事件（如果這是最近的回歸）^[7]。不同之處在于其背景。對于大多數站點可靠性工程師，這也是機器學習系統最難的方面：沒有能夠客觀衡量模型質量“足夠好”的標準，更糟糕的是，這是一個難以衡量的多維度問題。最終，產品和業務負責人將不得不建立真實世界的指標，以驗證模型是否滿足他們的要求，而機器學習工程師和站點可靠性工程師需要共同努力確定與那些要求最相關的質量指標。

作為循環中的最后一步，我們需要確保我們的終端用戶與模型交互的方式能夠返回到下一輪數據收集中，并準備好再次進行循環。機器學習服務系統應該記錄所有其認為有用的內容，以便將來進行改進。通常情況下，收到的查詢、提供的答案以及為什么提供這些答案都會被記錄下來?！盀槭裁础笨梢韵駟我坏南嚓P性評分一樣簡單，也可以是更復雜的甚至影響決策的因素的集合。

我們完成了第一次機器學習循環，并準備好重新開始。至此，yarnit.ai應該至少添加了最小限度的機器學習功能，我們也應該開始不斷地改進它，要么通過改進第一個模型，要么通過確認可以用機器學習手段改進的網站的其他方面。