機器學習在自動駕駛中落地，核心不是模型，是管道
- WBOY轉載
- 2023-05-05 11:46:061466瀏覽
本文轉自雷鋒網，如需轉載請至雷鋒網官網申請授權。
當我大學畢業後開始第一份工作時，我自認為對機器學習了解不少。我曾在 Pinterest 和可汗學院（Khan Academy）有過兩次實習，工作內容是建立機器學習系統。在柏克萊大學的最後一年，我展開了電腦視覺深度學習的研究，並在 Caffe 上工作，這是最早流行的深度學習庫之一。畢業後，我加入了一家名為「 Cruise 」的小型新創公司，Cruise專門生產自動駕駛汽車。現在我在 Aquarium，幫助多家公司部署深度學習模式來解決重要的社會問題。
這些年來，我建立了相當酷的深度學習和電腦視覺堆疊。與我在柏克萊做研究的時候相比，現在有更多的人在生產應用程式中使用深度學習。現在他們面臨的許多問題，與我2016年在 Cruise 所面臨的問題是一樣的。我有很多在生產中進行深度學習的經驗教訓想與你們分享，希望大家可以不必透過艱難的方式來學習它們。
圖註：作者團隊開發第一個部署在車上的機器學習模式
1 將ML模型部署到自動駕駛車上的故事
首先，讓我談談Cruise 公司有史以來第一個部署在汽車上的ML模型。在我們發展模型的過程中，工作流程感覺很像我在研究時期所習慣的。我們在開源資料上訓練開源模型，將其整合到公司產品軟體堆疊中，並部署到汽車上。經過幾個星期的工作，我們合併的最終 PR， 在汽車上運行模型。
「任務完成了！」我心想，我們該繼續撲滅下一場大火。我不知道的是，真正的工作才剛開始。
模型投入生產運行，我們的 QA 團隊開始注意到它的效能方面的問題。但是我們還有其他的模型要建立，還有其他任務要做，所以我們沒有立即去解決這些問題。 3個月後，當我們研究這些問題時，我們發現訓練和驗證腳本已經全部崩潰，因為自從我們第一次部署以來，程式碼庫已經改變了。
經過一個星期的修復，我們查看了過去幾個月的故障，意識到在模型生產運行中觀察到的許多問題不能通過修改模型代碼輕鬆解決，我們需要去收集和標記來自我們公司車輛的新數據，而不是依賴開放原始碼的數據。這意味著我們需要建立一個標籤流程，包括流程所需的所有工具、操作和基礎設施。
又過了3個月，我們運行了一個新的模型，這個模型是根據我們從車上隨機選取的資料進行訓練的。然後，用我們自己的工具進行標記。但是當我們開始解決簡單的問題時，我們不得不對哪些變化可能產生結果變得更加敏銳。
大約90% 的問題是透過對艱難或罕見的場景進行仔細的資料整理來解決的，而不是透過深度模型架構變更或超參數調整。例如，我們發現模型在下雨天的表現很差（在舊金山很罕見），所以我們標記了更多雨天的數據，在新的數據上重新訓練模型，結果模型的表現得到了改善。同樣，我們發現該模型在綠色視錐上的性能較差（與橙色視錐相比較少見），因此我們收集了綠色視錐的數據，經過了同樣的過程，模型的性能得到了改善。
我們需要建立一個可以快速辨識和解決這類問題的流程。
花費數個星期，這個模型的 1.0 版本組裝好了，又花了6個月，新推出一個改進版本模型。隨著我們在一些方面（更好地標記基礎設施、雲端資料處理、培訓基礎設施、部署監控）的工作越來越多，大約每月到每週都能重新訓練和重新部署模型。
當我們從頭開始建立更多的模型管道，並努力改善它們，我們開始看到一些共同的主題。將我們所學到的知識應用到新的管道中，更快更省力地運行更好的型號變得容易了。
2 保持迭代學習
圖註：許多不同的自動駕駛深度學習團隊，其模型管道的迭代週期都相當相似。由上至下: Waymo，Cruise 和 Tesla。
我曾經認為，機器學習主要是模型。實際上，工業生產中的機器學習主要是管道。成功的最佳預測因素之一是在模型管道上有效迭代的能力。這不僅意味著快速迭代，還意味著智慧迭代，第二部分很關鍵，否則你的管道很快就會產生糟糕的模型。
大多數傳統軟體都強調快速迭代和敏捷交付過程，因為，產品需求是未知的，必須透過適應來發現，所以與其在前期用不穩定的假設做詳盡的規劃，不如快速交付一個MVP並進行迭代。
就像傳統軟體需求是複雜的一樣，機器學習系統必須處理的資料輸入領域確實很龐大。與正常的軟體開發不同，機器學習模型的品質取決於它在程式碼中的實現，以及程式碼所依賴的資料。這種對資料的依賴意味著機器學習模型可以透過資料集建立/管理來「探索」輸入領域，允許它理解任務要求，並隨著時間的推移適應它，而不必修改程式碼。
為了利用這個特性，機器學習需要一個連續學習的概念，這個概念強調對資料和程式碼的迭代。機器學習團隊必須：
- 發現資料或模型效能中的問題
- 診斷問題發生的原因
- 改變資料或模型程式碼以解決這些問題
- 驗證模型在重新訓練之後變得更好
- 部署新模型並重複
團隊應該嘗試至少每個月都要經歷這個週期。如果你表現好，也許每週都要進行。
大型公司可以在不到一天的時間內完成模型部署週期，但是對於大多數團隊來說，快速且自動地建立基礎設施是非常困難的。如果更新模型的頻率低於這個頻率，就可能導致程式碼腐化（模型管道因程式碼庫的變更而中斷）或資料域轉移（生產中的模型無法泛化到資料隨時間的變化）。
大型公司可以在一天之內完成模型的部署週期，但是對於大多數團隊來說，快速且自動地建立基礎架構是非常困難的。更新模型的頻率如果低於這個頻率，就會導致程式碼腐化（模型管道因程式碼庫的變更而中斷）或資料域轉移（生產中的模型無法泛化到資料隨時間的變化）。
然而，如果處理得當，團隊可以進入一個良好的節奏，他們將改進的模型部署到生產環境中。
3 建立回饋迴路
校準模型的不確定性是一個誘人的研究領域，模型可以標記它認為可能失敗的地方。
對模型進行有效迭代的關鍵部分是集中精力解決最具影響力的問題。要改進一個模型，你需要知道它有什麼問題，並且能夠根據產品/業務的優先順序對問題進行分類。建立回饋迴路的方法有很多，但是首先要發現和分類錯誤。
利用特定領域的回饋迴路。
如果有的話，這可能是獲得模型回饋的非常強大和有效的方法。例如，預測任務可以透過對實際發生的歷史數據進行訓練來「免費 」獲得標籤數據，使他們能夠不斷地輸入大量的新數據，並相當自動地適應新情況。
設定一個工作流程，讓人們可以檢視你的模型的輸出，並在發生錯誤時標記。
當人們很容易透過許多模型推斷捕獲錯誤時，這種方法尤其適用。這種情況最常見的發生方式是當客戶注意到模型輸出中的錯誤並向機器學習團隊提出投訴。這是不可低估的，因為這個管道可以讓您直接將客戶回饋納入開發週期！一個團隊可以讓人類雙重檢查客戶可能錯過的模型輸出：想像一個操作人員看著一個機器人在傳送帶上對包進行分類，當他們發現一個錯誤發生時，就點擊一個按鈕。
設定一個工作流程，讓人們可以檢視你的模型的輸出，並在發生錯誤時標記。當人類審查很容易捕捉到大量模型推論中的錯誤時，這就特別適合。最常見的方式是當客戶注意到模型輸出中的錯誤並向ML團隊投訴時。這一點不容小覷，因為這個管道可以讓你直接將客戶的回饋納入開發週期中一個團隊可以讓人類仔細檢查客戶可能錯過的模型輸出：想想一個操作人員看著機器人在傳送帶上分揀包裹，每當他們發現有錯誤發生時就點擊一個按鈕。
當模型運行的頻率太高，以至於人們無法進行檢查時，可以考慮設定自動複查。
當很容易針對模型輸出編寫「健全性檢查」時，這尤其有用。例如，每當雷射雷達目標偵測器和二維影像目標偵測器不一致時，或當幀到幀偵測器與時間追蹤系統不一致時，請標記。當它工作時，它提供了許多有用的回饋，告訴我們哪裡出現了故障情況。當它不起作用時，它只是暴露了你的檢查系統中的錯誤，或者漏掉了所有系統出錯的情況，這是非常低風險高回報的。
最通用（但困難）的解決方案是分析它所運行的資料的模型不確定性。
一個簡單的例子是查看模型在生產中產生低置信度輸出的範例。這可以表現出模型確實不確定的地方，但不是100% 精確。有時候，模型可能是自信地錯誤的。有時模型是不確定的，因為缺乏可用的資訊進行良好的推理（例如，人們很難理解的有雜訊的輸入資料）。有一些模型可以解決這些問題，但這是一個活躍的研究領域。
最後，可以利用模型對訓練集的回饋。
例如，檢查模型與其訓練/驗證資料集（即高損失的例子）的不一致表明高可信度失敗或標記錯誤。神經網路嵌入分析可以提供一種理解訓練/驗證資料集中故障模式模式的方法，並且可以發現訓練資料集和生產資料集中原始資料分佈的差異。
圖註：大多數人的時間很容易從一個典型的再訓練週期中移除。即使這樣做的代價是降低機器時間的效率，它也消除了許多手動操作的痛苦。
加快迭代的主要內容是減少完成一個迭代週期所需的工作量。然而，總是有辦法讓事情變得更簡單，所以你必須優先考慮要改進什麼。我喜歡用兩種方式來思考努力：時鐘時間和人類時間。
時鐘時間指的是執行某些計算任務所需的時間，如資料的 ETL、訓練模型、運行推理、計算指標等。人工時間指的是人工必須主動介入以通過管道運行的時間，例如手動檢查結果、運行命令或在管道中間觸發腳本。
例如，多個腳本必須透過手動在步驟之間移動檔案按順序手動運行，這種情況非常常見，但是很浪費。一些紙巾背面的數學: 如果一個機器學習工程師每小時花費90美元，手工運行腳本每週浪費2個小時，那麼每個人每年加起來就是9360美元！
將多個腳本和手動中斷結合成一個全自動腳本，可以更快、更容易地運行一個模型管道循環，節省大量資金，並且使您的機器學習工程師不那麼古怪。
相較之下，時鐘時間通常需要「合理」（例如，可在一夜之間完成）。唯一的例外是機器學習工程師正在進行大量的實驗，或有極端的成本/縮放限制。這是因為時鐘時間通常與資料規模和模型複雜度成正比。當從本地處理轉移到分散式雲端處理時，時鐘時間會顯著減少。在此之後，雲端中的水平擴展往往可以解決大多數團隊的大多數問題，直到問題的規模擴大。
不幸的是，將某些任務完全自動化是不可能的。幾乎所有的生產機器學習應用程式都是監督式學習任務，而且大部分依賴一定數量的人機互動來告訴模型它應該做什麼。在某些領域，人機互動是免費的（例如，社交媒體推薦用例或其他有大量直接用戶回饋的應用程式）。在其他情況下，人類的時間更有限或更昂貴，例如訓練有素的放射科醫師為訓練資料「標記」CT 掃描。
無論哪種方式，將改進模型所需的人工時間以及其他成本最小化都很重要。雖然早期的團隊可能依賴機器學習工程師來管理資料集，但是讓一個沒有機器學習知識的操作使用者或領域專家來承擔資料管理的繁重工作通常更經濟（或者對於放射學家來說，是必要的） 。在這一點上，使用良好的軟體工具建立一個操作流程來標記、檢查、改進和版本控制資料集就變得非常重要。
5 鼓勵ML工程師健身
建立足夠的工具來支援一個新的領域或一個新的使用者群組可能需要花費大量的時間和精力，但是如果做得好，結果將是非常值得的。在 Cruise 公司，我的一位工程師特別聰明（有人會說他很懶）。
這個工程師建立了一個迭代循環，在這個循環中，操作回饋和元資料查詢的組合將從模型效能較差的地方抽取資料進行標記。然後，一個離岸作業團隊將標記數據，並將其新增至新版本的訓練資料集中。此後，工程師建立基礎設施，讓他們在電腦上執行一個腳本，並啟動一系列雲端任務，自動對新添加的資料進行再訓練和驗證一個簡單的模型。
每週，他們都會執行 retrain 腳本。然後，在模型訓練和驗證自己的時候，他們去了健身房。經過幾個小時的健身和晚餐後，他們會回來檢查結果。無獨有偶，新的和改進的數據將導致模型的改進，經過快速的雙重檢查確保一切都有意義，然後他們將新模型運送到生產中，汽車的駕駛性能將得到改善。然後，他們花了一周的時間來改進基礎設施，實驗新的模型架構，並建立新的模型管道。這名工程師不僅在本季末獲得了晉升，而且狀況很好。
6 結語
總結一下: 在研究和原型開發階段，重點是建立和發布一個模型。但是，隨著一個系統進入生產階段，核心任務是建立一個系統，這個系統能夠以最少的努力定期發布改進的模型。這方面你做得越好，你可以建造的模型就越多！
為此，我們需要關注以下方面:
- 以規律的節奏運行模型管道，並專注於比以前更好的運輸模型。每週或更短的時間內獲得一個新的改良型號投入生產！
- 建立一個良好的從模型輸出到開發過程的回饋迴路。找出模型在哪些範例上做得不好，並向您的培訓資料集中添加更多的範例。
- 自動化管道中特別繁重的任務，並建立一個團隊結構，使您的團隊成員能夠專注於他們的專業領域。特斯拉的Andrej Karpathy稱理想的最終狀態為「假期行動」。我建議，建立一個工作流程，讓你的機器學習工程師去健身房，讓你的機器學習管道來完成繁重的工作！
最後，我需要強調一下，在我的經驗中，絕大多數關於模型效能的問題可以用資料來解決，但是有些問題只能透過修改模型程式碼來解決。
這些變化往往是非常特殊的模型架構在手頭，例如，在圖像物件偵測器工作了若干年後，我花了太多的時間擔心最佳先前的盒子分配為某些方位比和提高特徵映射對小物件的解析度。
然而，隨著Transformer顯示出成為許多不同深度學習任務的萬能模型架構類型的希望，我懷疑這些技巧中的更多將變得不那麼相關，機器學習發展的重點將進一步轉向改進數據集。
以上是機器學習在自動駕駛中落地，核心不是模型，是管道的詳細內容。更多資訊請關注PHP中文網其他相關文章！