Uber ATG AI前線
作者 | Uber ATG
譯者 | 王強
策劃 | 鈺瑩
這些年來，Uber 的增長速度是指數級的，如今我們公司每天支持 1400 萬次出行，我們的工程師也證明了他們可以實現大規模擴展。這種價值還延伸到了其他領域，其中就包括 Uber ATG（先進技術小組）和他們開發自動駕駛汽車的努力。
這項工作中的一個關鍵環節，就是創建機器學習（ML）模型來處理諸如傳感器輸入、對象識別以及預測這些對象可能去向這樣的任務。解決這一問題所需的諸多模型，以及致力於解決這些問題的龐大工程師團隊本身，催生了管理和版本控制問題。
為了解決這個問題，我們一開始定義了一個五步驟生命週期，以在我們的自動駕駛汽車中訓練和部署 ML 模型。這個生命週期從數據攝取開始，一直髮展到模型服務，接下來還要確保模型運行良好。這個流程使我們能夠有效加快自動駕駛汽車組件的迭代，從而不斷改善其表現以實現最高標準。
我們還能進一步自動化這一流程以更好地管理開發涉及的諸多模型。由於自動駕駛領域中 ML 模型的深度依賴性和開發的複雜性，我們開發了 VerCD，這是一套支持 ML 工作流的工具和微服務集合。VerCD 使我們可以使用自動化持續交付（CD）來追蹤和管理 ML 工件的依賴項版本。
開發大規模模型的 ML 團隊可能會發現，這裡提到的 Uber ATG 為自動駕駛技術開發的五步模型生命週期，與 VerCD 的實踐和工具可應用於多種用例，從而幫助他們迭代自己的基礎設施。
自動駕駛汽車組件
我們的自動駕駛汽車組件有很多都使用 ML 模型，從而使車輛能夠安全、準確地行駛。一個組件會包含一個或多個 ML 模型，所有組件在一起構成我們的自動駕駛汽車軟件：
- 感知：該組件使用來自車輛的傳感器信息，通過 ML 模型檢測給定場景中的角色（actor）。它會標識每種對象類型（車輛、行人、自行車等）的概率及其 3D 座標。通過檢測，無人駕駛車輛可以看到環境中的不同物體，並解析它們的類型和位置。
- 預測：該組件基於感知組件的輸出（場景中所有角色的類型和 3D 座標）以及高清地圖，使用 ML 模型來預測給定場景中 n 秒內各個角色的未來軌跡。預測組件使自動駕駛汽車可以預測各個角色在未來最有可能位於何處。
- 運動計劃：該組件使用自動駕駛汽車的目的地、場景中所有角色的預測軌跡、高清地圖和其他機制來規劃汽車的行駛路徑。
- 控制：該組件操縱自動駕駛汽車的車輪，並操作其制動器和加速器，以遵循運動計劃組件創建的路徑行駛。
每個組件都建立在前一個組件生成的輸出的基礎上，以將我們的自動駕駛汽車正確地引導到目的地。包含這些組件的 ML 模型都會經過我們的五步迭代流程處理，以確保它們能有最佳的操作。
Uber 機器學習模型生命週期
機器學習模型基於歷史數據的訓練來預測、展望和估計。對於 Uber ATG 的自動駕駛車輛開發需求，我們使用各種交通狀況下從配備傳感器（包括 LiDAR、攝像頭和雷達）的車輛收集的數據，用作我們的訓練數據。我們將這些數據從車輛轉移到我們的服務器，然後由標籤團隊創建標籤，這些標籤構成了我們希望 ML 模型學習的真值（ground truth）輸出。
通常來說，標籤團隊將標籤手動分配給指定場景中的角色。這些標籤為場景中的每個角色提供位置、形狀和對象類型等屬性。我們使用這些標籤來訓練 ML 應用程序，這樣它們以後就能為從傳感器捕獲的新數據，預測其標籤會包含的信息（對象的類型及座標）。
收集到足夠的數據後，我們將使用真值標籤處理這些信息來開發 ML 模型，其中包括所有對象類型、座標及高清地圖。我們開發和運行 ML 模型的 ML 技術棧由多層組成，從最高層的 ML 應用程序本身到最底層的硬件部分。中間層包括常見的 ML 庫，例如 TensorFlow 和 PyTorch，以及 GPU 加速等。
我們的 ML 模型生命週期（如下圖 1 所示）包括五個階段。
我們讓 ML 模型走過這一生命週期的每個階段，以確保在將其部署到自動駕駛車輛之前，它們能夠展現出高質量的模型、系統和硬件指標。
圖 1：選擇並拆分了用於訓練模型的數據（數據攝取）之後，我們會確保信息質量（數據驗證），使用經過驗證的數據訓練模型（模型訓練），還會測試我們的模型以保障其性能（模型評估）。如果通過了這一評估，我們會將其部署到自動駕駛汽車（模型服務）。如果在任何階段遇到問題，我們都可以重新開始。
數據攝取
一旦我們收集到了用於 ML 模型訓練的數據，它就會被我們的 ML 棧攝取。數據攝取過程會選擇我們計劃使用的日誌，並從中攝取數據。
我們將這些日誌數據分為訓練數據、測試數據和驗證數據。75％的日誌用於訓練，15％的日誌用於測試，10％的日誌用於驗證。這種比例是為了用大部分數據訓練 ML 模型，提高模型的準確性，然後隨著訓練的進展來做驗證。最後，我們在訓練過程中沒用過的一小部分數據上測試模型效率。在以後的文章中我們將介紹 GeoSplit，這是一個數據管道，用於選擇日誌，並根據其地理位置分類為訓練、測試和驗證用途。
劃分數據後，我們使用 Uber ATG 的深度學習開源數據訪問庫 Petastorm（https://eng.uber.com/petastorm/），從數據生成日誌中攝取數據。我們從日誌中攝取的數據包括：
- 來自車輛攝像頭的圖像
- LiDAR 3D 點信息
- 雷達信息
- 車輛狀態，包括位置、速度、加速度和方向
- 地圖信息，例如車輛的路線和所走的車道
- 真值標籤
我們將這些信息按日誌一個個保存在 HDFS 上。然後使用 ApacheSpark 從多個日誌中並行攝取數據。以這種方式攝取數據會將數據保存為優化格式，以便訓練管道可以輕鬆、快速地使用它們。當我們運行訓練管道時，並不想等待漫長而繁重的 API 調用來查找某些信息。有了這套系統，我們從 HDFS 加載模型後，就將所有需要的信息（攝取的數據）存儲在 GPU 的內存中，以確保管道可以高效地讀取訓練數據。
下面的圖 2 顯示了在 CPU 群集上運行，將攝取的數據保存到 HDFS 的提取流程的示例：
圖 2：我們的自動駕駛汽車會生成各種日誌（此處展示了相機和 LiDAR 信息，此外還有雷達信息和真值標籤）。然後我們立即從 CPU 群集上的每個日誌中提取這些數據，並將提取到的數據保存到 HDFS，以便管道處理。
數據驗證
數據管道選擇並提取了用於訓練、測試和驗證的數據後，我們將運行查詢以拉出場景中的幀數和數據集中不同標籤類型的出現次數。我們將這些查詢的結果與之前的數據集做對比，以瞭解情況如何變化，變化是否符合預期。例如，如果某個標籤類型的出現次數相比其他類型增加得太快，就將觸發進一步的分析以理解這種更改及其對模型的影響。
模型訓練
正確選擇，提取和驗證數據後，我們便擁有了訓練模型所需的資源。我們利用 Horovod 的分佈式訓練，基於提取到的數據快速訓練。我們通過數據並行將數據分佈在不同的 GPU 上，如下圖 3 所示，這意味著要在擁有各個數據部分的不同 GPU 上訓練相同的模型。例如，如果我們使用兩個 GPU，則將數據分為兩部分，並且在具有第一部分數據的第一個 GPU，和具有第二部分數據的第二個 GPU 上訓練相同的模型。
圖 3：我們使用提取到的數據（包括此處顯示的圖像以及其他傳感器數據）來在 GPU 群集上使用 Horovod 進行分佈式訓練，並將數據保存到 HDFS。
每個過程都獨立於其他過程來執行正向和反向傳遞（正向傳遞是指為網絡所有層的輸入計算輸出，以及損耗函數的損耗；而反向傳遞是指計算網絡中每個節點損耗變化的速率）。
接下來，我們使用 Horovod 的環減少算法，使 worker 節點能夠平均梯度，並將其分散到所有節點，過程中無需參數服務器就能每個過程所學的知識分配給其他所有過程。
利用 TensorFlow 和 PyTorch 打造的 ML 框架，工程師可以通過 TensorBoard 來監視訓練作業，以驗證訓練是否按預期進行。
Uber ATG 使用一種混合方法來處理 ML 計算資源，訓練作業既可以在由 GPU 和 CPU 集群支持的本地數據中心中運行，也能在雲上運行。
為了在帶有 GPU 的本地數據中心內編排訓練作業，我們使用了 Peloton（https://eng.uber.com/peloton/），這是 Uber 開發的開源統一資源調度程序。Peloton 將我們的容器部署到群集上的各個進程，從而輕鬆地將作業擴展到許多 GPU 或 CPU 上。對於基於雲的訓練，我們使用的是 Kubernetes，它能跨主機群集部署和擴展應用程序容器。
使用選定的，提取的和經過驗證的數據訓練完機器學習模型後，我們便可以評估它們完成任務的能力，包括識別場景中的物體和預測角色的路徑等。
模型評估
訓練了給定的模型後，我們將評估模型本身的性能以及整個系統的性能。我們使用特定於模型的指標和系統指標來測試 ML 模型。我們還評估了硬件指標，以瞭解我們的模型在最終部署的硬件上的執行速度。
特定於模型的指標
我們在給定的測試集上計算各種特定於模型的指標。例如，對於感知組件中的對象檢測模型，我們會計算精度（被證明是正確的檢測百分比）和召回率（被模型正確識別的真值對象的比例）這些模型指標。
查看這些指標可為我們提供有關模型性能的重要見解，進而不斷提升性能。當我們找到模型表現不佳的場景時，我們會包含類似案例來調整數據管道，從而為模型提供更多可用數據。在這些情況下，有時我們會對那些場景給予更多的權重（這意味著與其他場景相比，這些數據實例將為訓練模型做出更大的貢獻），從而優化相關模型。
當我們使用更多場景訓練模型後，模型在這些場景中的表現就會變好。此外，我們還要確保模型不會在已經表現良好的場景上出現性能退化。
系統指標
系統指標包括對整個車輛運動的安全性和舒適性測量，這些測量是通過大型測試集執行的。一旦給定模型的特定模型指標顯示出良好的結果，我們就會在模型開發的後期階段評估系統指標。鑑於自動駕駛棧中的不同 ML 模型彼此依賴（例如，我們的預測組件使用感知組件的輸出），系統指標為我們提供了一個重要而全面的概覽，展示了系統各部分的表現與各個組件版本之間的關係。衡量系統指標，有助於團隊更全面地瞭解新模型是如何影響系統中其他組件的。定期評估系統指標可以讓我們發現並修復由於 ML 模型更新，而在其他組件中發生的問題。
硬件指標
Uber ATG 有一套內部基準測試系統，開發人員可以使用它來分析軟件的特定部分，例如特定模型的推理，並評估其在自動駕駛汽車硬件上的運行速度。我們使用自動駕駛車輛記錄的真實世界數據進行評估，以在部署模型之前瞭解模型的性能表現。
模型部署
一旦我們訓練好了一個模型，驗證了它在孤立狀態下是否可以正常運行，並確認它在系統的其餘部分上都能正常運行後，我們便將其部署在自動駕駛汽車的推理引擎上。該系統通過訓練好的模型運行輸入以生成輸出。例如，運行感知組件將提供場景對象類型及其座標，而預測組件將提供對象的未來軌跡。
在部署模型後，我們會通過五步流程不斷迭代所有模型來改進它們，重點放在模型需要改進的地方，通常是在模型評估步驟中發現的。
通過持續集成和交付來加速機器學習研究
儘管我們將流程簡化為從數據集攝取到模型部署的五個步驟，但每個步驟本身都涉及諸多系統，整個端到端的工作流程可以輕鬆跨越數週時間。流程由人工驅動時存在很多人為錯誤的可能，因此我們開發了更好的工具和平臺，以使工作流程儘可能地自動化。
VerCD 就是這樣一個平臺，它可以跟蹤整個流程中代碼、數據集和模型之間的依賴關係，還可以編排這些 ML 工件的創建，所以它成為了流程中的重要組成部分。具體來說，VerCD 涵蓋的流程從數據集提取階段開始，涵蓋模型訓練，然後以指標計算結束。
由於自動駕駛領域中 ML 模型的深層依賴性和開發複雜性，我們需要一個持續交付（CD）系統，利用敏捷原理專門跟蹤和管理 ML 工件的版本化依賴項。儘管諸如 Kubeflow 和 TensorFlow Extended 之類的開源工具提供了高級編排能力來構建數據集和訓練模型，但是它們需要大量的集成工作。此外，它們交付單個工作流的表現不佳，並且沒有很好地支持持續交付（CD）和持續集成（CI）。
另一方面，市面上也有支持版本控制和 CI/CD 的傳統軟件工具，例如 Git 和 Jenkins。儘管這些工具無法在我們的自動駕駛軟件中處理 ML 工件，但我們從它們中得到了構建 VerCD 的靈感。
機器學習流程中敏捷原則的應用
多數軟件開發人員使用版本控制、依賴項跟蹤、持續集成和持續交付，基於敏捷開發流程頻繁發佈軟件。由於這些概念是眾所周知的，因此這裡我們只關注它們在 ML 工作流領域的應用。
應用於 ML 域的版本控制原則可以分析 ML 工作流某些部分的一項更改對下游依賴的影響。例如，如果同時跟蹤代碼和 ML 工件版本，則更新特定數據集或模型的 ML 工程師，或用來生成這些工件的支持軟件，就可以更好地理解這些更改的影響。在這裡，版本控制使我們能夠獨立於其他開發人員的更改來跟蹤特定開發人員的更改的影響，即使他們是並行工作的也不影響。
關於 ML 域中依賴項跟蹤的一個例子，就是對標籤和原始數據的調整會更改數據集的性質，進而影響訓練結果。此外，數據提取或模型訓練代碼和配置中的更改會影響它們負責構建的工件。因此，先在舊數據集上訓練模型然後提取新的數據集是沒有意義的，因為數據將與訓練好的模型不一致。在這種情況下應先提取數據集，然後再建立模型，這是依賴項約束決定的順序。
儘管有許多成熟的工具可以實現傳統軟件代碼庫的持續交付，但我們發現在同樣的成熟度和標準化水平下，如今還不存在用於機器學習的同類工具。與 CD 工作流相比，ML 工作流涉及代碼、數據和模型，並且只有第一個由傳統軟件工程工具處理。下面的圖 4 說明了 CD 工作流程中的某些差異，而圖 5 說明了構建最終 ML 工件所需的系統範圍和複雜性：
圖 4：傳統的持續交付週期與 ML 的不同之處在於，ML 開發人員不僅要構建並測試代碼，還必須構建數據集、訓練模型和計算模型指標。
圖 5：與所有支持系統和代碼（例如配置、數據收集、特性提取、數據驗證、機器資源管理、分析工具、過程管理工具、服務架構和監控等）相比，ML 工作流的最終結果只是一個很小的工件。
通過實施敏捷流程，CD 使工程師能夠快速適應不斷變化的需求，及早並經常發現錯誤，並促進所有 ML 塊的並行開發，從而提高開發人員的生產率。但是，重度 ML 的組織中常見的頻繁更改和並行模型開發需要解決版本控制問題，且由於自動駕駛軟件棧中的依賴關係圖很深，因此該領域的問題更加棘手，如上所述。這樣的依賴圖不僅涵蓋單個 ML 模型的代碼、數據和模型，而且涉及各種 ML 模型之間的依賴關係。
自動駕駛領域的深度依賴圖
在自動駕駛汽車開發中，依賴圖是特別深的。這種深度是自動駕駛軟件棧中分層架構的產物，其中每一層都提供了不同的 ML 功能。為了說明這一點，我們在下面的圖 6 中展示了順序連接的三個 ML 模型的高級架構：
圖 6：左側顯示的對象檢測模型的依賴圖，以及右側顯示的其他兩個 ML 模型，描述了由版本控制系統處理的代碼和配置（綠色），及未由版本控制系統處理的項目（灰色）。
在上面的圖 6 中，我們的 ML 層包括：
- 一個對象檢測模型，其輸入是原始傳感器數據，
- 路徑預測模型，其輸入是對象檢測模型檢測到的對象集合，
- 一個規劃模型，其輸入是路徑預測模型的輸出。
每一個模型都有一個複雜的，涉及代碼和工件的依賴圖，如圖 6 左側所示。這一層本身還有好幾層深，涉及三個工件的生成：
- 數據集，由原始源數據、源圖像數據（即標籤）中不同對象周圍的邊界框，以及數據集生成代碼組成。
- 經過訓練的模型，需要數據集工件、模型訓練代碼和管理模型訓練的配置文件作為輸入。
- 指標報告，該報告需要訓練的模型工件、數據集和指標生成代碼作為輸入。
路徑預測和計劃模型的依賴圖都像對象檢測模型一樣複雜。在某些情況下，當我們查看整個系統時，完全展開的圖至少 15 級深。圖的深度對 CD 構成了特殊的挑戰，因為這些 ML 組件的並行開發極大地增加了 CD 系統必須管理的版本數量。
為 Uber ATG 構建 VerCD
我們開發了 VerCD，這是一套工具和微服務集合，旨在為 Uber ATG 的自動駕駛車輛軟件提供所有 ML 代碼和工件的版本控制和持續交付能力。組成 VerCD 的許多組件都是公開可用的，因此我們的大部分工程工作都花在了添加公司特定的集成上，以使現有的編排器能夠在整個端到端 ML 流程中與各種異構系統交互。
與傳統的版本控制和持續交付系統不同，VerCD 會跟蹤每個 ML 組件的所有依賴項，除了代碼外通常還包括數據和模型工件。VerCD 提供的元數據服務跟蹤依賴關係圖，而持續集成編排器用它來定期運行整個 ML 工作流管道，以生成數據集、訓練好的模型和指標。對於經常需要將新實驗與歷史基準做對比，或檢查歷史構建以跟蹤錯誤的工程師來說，VerCD 確保了 ML 工件始終可重現和可追溯。
VerCD 的系統架構
在設計 VerCD 時，我們同時結合了實驗和生產工作流程。我們不僅需要該系統來支持由編排器驅動的持續集成和持續交付（CI/CD）工作流，而且還希望 VerCD 擁有在實驗期間代表工程師構建數據集、訓練模型和運行指標的功能。這些要求意味著 VerCD 接口需要同時支持人類和機器的訪問。為了獲得可重用的接口，我們選擇了帶有 Python 庫綁定的 RESTAPI，如下圖 7 和 8 所示。
圖 7：VerCD 包括版本和依賴項元數據服務以及編排器服務。我們使用例如Flask、SQLAlchemy、MySQL 和 Jenkins 的常規框架，但通過 ATG 特定的集成來增強其功能。
圖 8：版本和依賴項元數據服務具有用於數據集構建、模型訓練和指標計算的各個端點。REST API 是一個 Flask and SQLAlchemy 應用，由 MySQL 支持以保存依賴項元數據。黃色的 API 處理程序和數據訪問層是為 ATG 特定的用例設計的。
出於相同的原因，VerCD 被設計為一組單獨的微服務，用於數據集構建、模型訓練和指標計算。我們選擇了基於微服務的架構，這是 Uber 的流行選擇，其中每個微服務負責特定的功能，從而允許系統擴展並在服務之間提供隔離。VerCD 的 CI/CD 流程是線性且固定的，而實驗流程需要更大的靈活性，通常涉及自定義流程和臨時的運行作業，這些工作可能只專注於數據集提取、模型訓練或指標評估工作的子集。有了一組單獨的微服務，就能獲得必要的靈活性，從而在這兩種流程之間充分利用相同功能。
為了實現依賴項跟蹤，用戶提供向 VerCD 註冊的任何數據集、模型或指標構建的顯式依賴項，然後系統在數據庫後端管理這些信息。如下面的圖 9 所示，我們使用一個 Jenkins 編排器開始常規構建，並提供連接器和集成代碼來增強編排器的功能，以便它可以解析依賴元數據並操作 ATG 特定的系統。
圖 9：VerCD 的編排器服務負責管理用於構建數據集、訓練模型和計算指標的工作流管道。它由現成的 Jenkins 發行版組成，並增加了我們自己的 ATG 特定集成（黃色），使編排器能夠與外部 ATG 系統交互。
例如，我們的編排器可以調用這些原語來構建自動駕駛汽車的運行時以進行測試、與我們的代碼庫交互，還能使用深度學習或 Apache Spark 庫創建圖像。其他原語包括在數據中心之間以及雲之間複製數據集（如果模型在這些位置訓練）。
事件序列示例：註冊一個新數據集
在用戶註冊新數據集後，VerCD 數據集服務會將依賴項元數據存儲在我們的數據庫中。對於數據集、模型和指標來說，依賴項將包括存儲庫的 Git 哈希和代碼入口點的路徑。根據要構建的工件，還將引用其他版本化的元素（例如標籤和源數據的版本化集合，或另一個版本化的數據集 / 模型）。我們期望所有依賴項都是版本化且不可變的；例如數據集這邊，依賴項將是來自版本化源的傳感器數據的時間序列。
註冊的最後一步，元數據服務使用編排器服務啟動一個構建。這將啟動 Apache Spark 作業來運行代碼，監視作業（如有必要就重新啟動），最後將數據集複製到管理的存儲位置（本地數據中心或雲）。然後使用數據複製到的各個位置來更新元數據服務。
微服務 API
我們每種微服務的 API 旨在提供生產和實驗流程的編程訪問接口。由於系統的目標是確保數據集構建、模型訓練和指標運行的可重複性和可追溯性，因此我們要求在註冊過程中指定這三個流程的所有版本化不可變依賴項。API 提供了對構建信息（例如生成工件的位置以及構建生命週期等）的訪問來確保可追溯性。在嘗試調試 ML 工件或性能下降時，此類信息特別重要。
數據集服務 API
數據集服務負責跟蹤用於構建給定數據集的依賴項。REST API 支持以下功能：創建新數據集、讀取數據集的元數據、更新數據集的元數據、刪除數據集以及獲取數據集的工件位置（例如 S3 或 HDFS）。當用戶註冊新數據集時，後端編排器將立即繼續構建和驗證數據集。
數據集由名稱和版本號唯一標識，而 VerCD 跟蹤的依賴項使我們每次都能重現完全相同的數據集工件，這些依賴項包括：
- 來自自動駕駛車輛的傳感器日誌 ID，用於每次的訓練、測試和驗證
- 用於從原始傳感器數據中提取數據集的代碼的 Git 哈希
- 提取腳本的入口點
- 描述數據集生命週期以及特定版本是否為最新狀態的元數據
數據集可以使用其當前生命週期狀態進行註釋，例如何時註冊、何時構建失敗或中止、何時構建成功且狀態良好、何時棄用數據集，最後是數據集的生命週期何時結束。
模型服務 API
模型訓練服務負責跟蹤用於訓練給定模型的依賴項。REST API 支持以下功能：訓練新模型、讀取新模型的元數據、更新已註冊模型的元數據，以及升級為生產版本。當用戶註冊新模型時，後端編排器將立即開始訓練它。
模型通過名稱和版本唯一標識，VerCD 跟蹤的依賴項使我們能夠重現相同的訓練運行作業，這些依賴項有：
1. 如上一節所述，版本化的數據集
2. 用於訓練的代碼的 Git 哈希
3. 訓練腳本的入口點
4. 訓練配置文件的路徑
5. 最終訓練好的工件的路徑
6. 描述數據集生命週期以及特定版本是否為最新狀態的元數據
實驗、驗證和生產流程
幾乎所有新的 ML 模型都是從實驗開始的，因此 VerCD 支持驗證步驟，以允許在實驗模型和生產模型之間平穩過渡。驗證步驟對模型訓練施加了額外的約束，以確保生產環境所需的可重複性和可追溯性；而在實驗過程中，這種約束可能已經以快速開發的方式實現了。
如下圖 10 所示，一旦 ML 工程師在 VerCD 的模型服務 API 中定義了實驗模型，我們的系統就會開始訓練它。
圖 10：在 VerCD 工作流程中，“實驗”和“驗證”狀態彼此獨立，但是在模型可以轉換到“生產”狀態之前，這兩個狀態必須是成功的。
根據其表現不同，我們將模型指定為失敗、中止或成功。如果模型失敗或必須中止，則 ML 工程師可以選擇使用一組新參數來重建。
VerCD 可以異步啟動模型驗證。如圖 10 所示，我們的實驗和驗證過程包括相同的基本步驟，不同之處是實驗圖運行模型訓練代碼，而驗證圖運行模型驗證代碼。我們的驗證代碼在模型訓練管道上執行各種健全性檢查，例如驗證構建是否成功，輸出工件是否存在，以及依賴項是否是不可變和版本化的。具體的檢查內容取決於要訓練的特定模型。
僅當實驗構建成功且驗證成功，並且可以在任何時間點以任何順序調用它們時，才可以將模型提升到生產狀態。在模型升級過程中，用戶提供命名空間、名稱、主要版本和次要版本。然後，端點對訓練工件生成快照，並將其與模型訓練元數據一起版本化，以備將來參考。在實驗階段，代碼和模型的性能經常會出現波動。到開發人員準備升級時，實驗輸出的結果大部分都應該是正向的，並且系統會批准將結果存檔。
指標服務 API
VerCD 涉及的機器學習工作流的最後一步，是評估訓練模型的指標。與我們其他的微服務一樣，為了確保指標的可追溯性和可重複性，該架構的指標服務有一個元數據服務，該元數據服務可跟蹤運行指標作業及其結果工件所需的依賴項。與數據集和模型的情況類似，我們會跟蹤：
- 上一節中所述的版本化模型
- 用於運行指標作業的代碼的 Git 哈希
- 指標運行代碼的入口點
- 配置文件的路徑
- 描述數據集生命週期以及特定版本是否為最新狀態的元數據
數據集和模型部署及結果
如今，VerCD 在為我們的許多數據集構建、模型訓練和指標管道提供定期的日常集成測試。這些頻繁的集成測試讓我們能知道這些工作流當前的可追溯性和可再現性狀態，即使有無數版本的代碼、數據和模型工件，以及將整個系統聯繫在一起的深層依賴圖也不在話下。
例如，VerCD 數據集服務已成為 Uber ATG 自動駕駛傳感器訓練數據的可靠來源。擁有可以持續交付傳感器數據的服務之前，無論是在業務流程還是在記錄保存方面，我們的數據集生成過程都是非常依賴人工的。將數據集構建流程納入 VerCD 後，我們將新數據集構建的頻率提高了 10 倍以上，顯著提高了效率。維護一個常用數據集的清單也提高了 ML 工程師的迭代速度，因為開發人員可以立即繼續實驗，而無需等待幾天時間來構建新的數據集。
此外，我們還為自動駕駛汽車的重點目標檢測和路徑預測模型提供了每日和每週的訓練作業。這種頻繁的訓練節奏將檢測和修復某些錯誤的時間縮短到了幾天時間，而在實現 CICD 訓練之前，錯誤的窗口在很大程度上是未知的，需要許多工程師費心注意。
繼續前進
我們的 ML 模型生命週期流程，以及為簡化此流程而構建的工具（如 VerCD）可幫助我們管理所使用的諸多模型，並更快地迭代它們。這些實踐和解決方案都是源於我們在開發高水平的自動駕駛汽車系統時對高效率的需求。
我們在 ML 開發中建立多個流程階段，進而開發諸如 VerCD 的支持系統來管理 ML 流程日益增加的複雜性的過程中已經取得了長足的進步。隨著我們技術的不斷成熟，以及複雜性和精巧程度的增長，依靠人為干預來管理各個 ML 流程階段的做法變得越來越不可行。這些工具使工程師能夠更快地迭代 ML 組件，從而提升我們自動駕駛汽車的性能表現。
原文鏈接：
https://eng.uber.com/machine-learning-model-life-cycle-version-control/
閱讀更多 工信智媒 的文章
