Chip Huyen
在與美國、歐洲和中國的主要網際網路公司的機器學習和基礎設施工程師交談後，我注意到兩組公司。一組已經對基礎設施進行了大量投資（數億美元），以實現實時機器學習，並且已經看到了投資的回報。另一組公司仍然懷疑實時ML是否有價值。
對於實時ML的含義，似乎沒有什麼共識，業界也沒有對它的做法進行深入討論。在這篇文章中，我想分享我與十幾家正在做的公司交談後所瞭解到的情況。
實時機器學習有兩個層次，我將在這篇文章中進行介紹。
- 第1級：你的ML系統實時進行預測（線上預測）。
- 第2級：你的系統可以納入新的資料並實時更新你的模型（持續學習）。
我用 "模型 "來指代機器學習模型，用 "系統 "來指代它周圍的基礎設施，包括資料管道和監控系統。
第1級：線上預測--你的系統可以實時進行預測
這裡的實時被定義為在毫秒到秒的範圍內。
使用案例
延遲很重要，特別是對於面向使用者的應用程式。2009年，谷歌的實驗表明 將網路搜尋延遲增加100至400毫秒，每個使用者每天的搜尋次數減少0.2%至0.6%。在2019年。 Booking.com發現，延遲增加30%會使轉換率下降約0.5%--"對我們的業務來說是一個相關的成本"。
無論你的ML模型有多棒，如果它們做預測的時間只需要幾毫秒，使用者就會點選其他東西。
批次預測的問題
一個不可行的解決方案是避免線上進行預測。你可以在離線情況下批次生成預測，儲存它們（例如在SQL表中），並在需要時拉出預先計算的預測。
當輸入空間是有限的時候，這就可以發揮作用--你確切地知道有多少可能的輸入要進行預測。一個例子是當你需要為你的使用者生成電影推薦時--你確切地知道有多少使用者。所以你定期為每個使用者預測一組推薦，比如每隔幾個小時。
為了使使用者的輸入空間有限，許多應用程式讓使用者從類別中選擇，而不是隨意輸入查詢。例如，如果你去TripAdvisor，你首先必須選擇一個預定義的大都市地區，而不是能夠輸入任何地點。
這種方法有很多侷限性。TripAdvisor的結果在其預先定義的類別中還不錯，如 "舊金山 "的 "餐館"，但當你試圖輸入 "Hayes Valley的高評級泰國餐館 "這樣的瘋狂查詢時，結果就相當糟糕。
批次預測造成的限制甚至存在於像Netflix這樣技術上更先進的公司。比如，你最近看了很多恐怖片，所以當你第一次登入Netflix時，恐怖片在推薦中占主導地位。但你今天感覺很興奮，所以你搜索 "喜劇 "並開始瀏覽喜劇類別。Netflix應該學習並在你的推薦列表中向你展示更多的喜劇，對嗎？但它不能更新列表，直到下一次生成批次推薦。
在上面的兩個例子中，批次預測導致了使用者體驗的下降（這與使用者參與/保留緊密相連），而不是災難性的失敗。其他例子還有廣告排名、Twitter的趨勢標籤排名、Facebook的新聞提要排名、估計到達時間等。
還有許多應用，如果沒有線上預測，就會導致災難性的失敗，或者就是無法工作。例如，高頻交易、自動駕駛汽車、語音助手、使用面部/指紋解鎖手機、老年人護理的跌倒檢測、欺詐檢測等等。能夠檢測到3小時前發生的欺詐性交易仍然比完全沒有檢測到好，但能夠實時檢測到可以防止它透過。
從批次預測轉換到實時預測，可以使用動態特徵來進行更多的相關預測。靜態特徵是變化緩慢或很少的資訊--年齡、性別、工作、鄰居等。動態特徵是基於現在正在發生的事情的特徵--你正在看什麼，你剛剛喜歡什麼，等等。瞭解使用者現在的興趣，將使你的系統能夠做出與他們更相關的推薦。
解決方案
為了使你的系統能夠進行線上預測，它必須有兩個組成部分。
- 快速推理：可以在幾毫秒的時間內做出預測的模型
- 實時管道：能夠處理資料，將其輸入模型，並實時返回預測結果的管道。
快速推理
當一個模型太大，花太多時間來進行預測時，有三種方法。
1.讓模型更快（推理最佳化）。
例如，融合操作、分佈計算、記憶體佔用最佳化、編寫針對特定硬體的高效能核心等。
2.使模型更小（模型壓縮）。
最初，這個系列的技術是使模型更小，以使它們適合邊緣裝置。使模型變小通常會使它們執行得更快。最常見的、通用的模型壓縮技術是量化，例如，用16位浮點（半精度）或8位整數（定點）代替32位浮點（全精度）來表示你的模型權重。在極端情況下，有些人嘗試用1位表示（二進位制權重神經網路），例如 BinaryConnect和 Xnor-Net.Xnor-Net的作者從Xnor.ai分拆出來，這是一家專注於模型壓縮的初創公司，它被蘋果公司以2億美元的價格收購。
另一種流行的技術是 knowledge distillation 一個小的模型（學生）被訓練來模仿一個較大的模型或一個模型集合（教師）。儘管學生通常是用預先訓練好的老師來訓練的，但兩者也可以同時進行訓練。生產中使用的蒸餾網路的一個例子是 DistilBERT它將一個BERT模型的大小減少了40%，同時保留了97%的語言理解能力，並且速度快了60%。
其他技術包括修剪（找到對預測最沒用的引數，並將其設定為0）和低秩因子化（用緊湊的塊來取代過度引數化的卷積過濾器，以減少引數數量並提高速度）。見 A Survey of Model Compression and Acceleration for Deep Neural Networks (Cheng等人，2017）的詳細分析。
關於模型壓縮的研究論文的數量正在增長。現成的實用程式也在激增。令人敬畏的開源專案有一個列表，其中包括 The Top 121 Model Compression Open Source Projects.
3.讓硬體更快
這是另一個正在蓬勃發展的研究領域。大公司和初創公司都在競相開發硬體，使大型ML模型能夠在雲端，特別是在裝置上更快地進行推理，甚至訓練。IDC預測，到2020年，做推理的邊緣和移動裝置的組合將總共37億臺，還有1.16億臺在做訓練。
實時管道
假設你有一個搭車應用，想檢測欺詐性交易，例如使用被盜信用卡付款。當真正的信用所有者發現未經授權的付款時，他們會向銀行提出爭議，而你則必須退還費用。為了實現利潤最大化，欺詐者可能會連續撥打多個乘車電話，或者從多個賬戶撥打。2019年，商家估計欺詐性交易平均佔到了其年度線上銷售額的27%。你發現被盜信用卡的時間越長，你的損失就越大。
要檢測一項交易是否是欺詐性的，僅看該交易是不夠的。你至少需要調查參與該交易的使用者最近的歷史，他們最近在應用中的旅行和活動，信用卡最近的交易，以及在同一時間發生的其他交易。
為了快速訪問這些型別的資訊，你希望儘可能多地把它們儲存在記憶體中。每當你關心的事件發生時--使用者選擇地點、預訂行程、聯絡司機、取消行程、新增信用卡、刪除信用卡等等。- 有關該事件的資訊就會進入你的記憶體儲存中。只要它們是有用的（通常以天為單位），它就會留在那裡，然後要麼進入永久儲存（如S3），要麼被丟棄。這方面最常見的工具是 Apache Kafka，Kafka是一種流式儲存：它是一種流式儲存方式，它是由Amazon Kinesis提供的。Kafka是一個流儲存：它在資料流中儲存資料。
流資料與靜態資料不同--靜態資料已經完整地存在於某處，如CSV檔案。當從CSV檔案中讀取時，你知道工作何時結束。而資料流永遠不會結束。
一旦你有了管理流媒體資料的方法，你就想提取特徵來輸入你的ML模型。除了來自流媒體資料的特徵外，你可能還需要來自靜態資料的特徵（這個賬戶是什麼時候建立的，使用者的評價是什麼，等等）。你需要一個工具，允許你處理流媒體資料以及靜態資料，並將它們從各種資料來源連線起來。
流處理與批處理
人們一般用 "批處理 "指的是靜態資料處理，因為你可以成批地處理它們。這是與 "流處理 "相對的，後者在每個事件到達時進行處理。批處理是高效的--你可以利用MapReduce等工具來處理大量的資料。流處理是快速的，因為你可以在每一個數據到來時立即處理。Apache Flink的PMC成員Robert Metzger對流處理可以像批處理一樣高效提出異議，因為批處理是流處理的一個特例。
處理流資料更加困難，因為資料量是無限制的，而且資料進來的速率和速度是可變的。讓一個流處理器做批處理比讓一個批處理器做流處理更容易。
Apache Kafka有一定的流處理能力，一些公司在Kafka流儲存的基礎上使用這種能力，但Kafka流處理在處理各種資料來源方面的能力是有限的。人們一直在努力擴充套件SQL，這種用於靜態資料表的流行的查詢語言，以處理資料流。然而，最流行的流處理工具是 Apache Flink它具有對批處理的本地支援。
在機器學習生產的早期，許多公司在現有的MapReduce/Spark/Hadoop資料管道之上建立了他們的ML系統。當這些公司想做實時推理時，他們需要為流式資料建立一個單獨的管道。
有兩個不同的管道來處理你的資料是ML生產中出現錯誤的常見原因，例如，一個管道的變化沒有正確地複製到另一個管道，導致兩個管道提取兩個不同的特徵集。如果這兩個管道由兩個不同的團隊維護，這種情況尤其常見，例如，開發團隊維護用於訓練的批處理管道，而部署團隊維護用於推理的流管道。公司包括 Uber和 Weibo等公司已經進行了重大的基礎設施改造，用Flink統一了他們的批處理和流處理管道。
事件驅動與請求驅動
在過去的十年裡，軟體世界已經走向了微服務。其理念是將你的業務邏輯分解成小的元件--每個元件都是一個自足的服務--可以獨立維護。每個元件的所有者可以快速更新和測試該元件，而不必諮詢系統的其他部分。
微服務往往與REST攜手並進，REST是一套讓這些微服務進行溝通的方法。REST APIs是請求驅動的。客戶端（服務）透過POST和GET等方法傳送請求，告訴它的伺服器到底要做什麼，它的伺服器會對結果作出回應。伺服器必須監聽請求，才能註冊請求。
因為在一個請求驅動的世界裡，資料是透過對不同服務的請求來處理的，沒有人對資料如何在整個系統中流動有一個總體的瞭解。考慮一個有3個服務的簡單系統。
- A 管理司機的可用性
- B 管理乘坐需求
- C 在顧客每次要求乘車時，預測可能的最佳價格，向他們展示。
因為價格取決於可用性和需求，服務C的產出取決於服務A和B的產出。首先，這個系統需要服務間的溝通。C需要ping A和B進行預測，A需要ping B知道是否調動更多的司機，ping C知道給他們什麼價格激勵。其次，將沒有簡單的方法來監測A或B的邏輯變化如何影響服務C的效能，或者在服務C的效能突然下降時對映資料流來進行除錯。
只有3項服務，事情就已經變得複雜了。想象一下，如果沒有成千上萬的服務，就像主要網際網路公司所擁有的那樣。服務間的通訊會爆炸的。在HTTP上以JSON blobs的形式傳送資料--REST請求通常採用的方式--也很慢。服務間的資料傳輸會成為一個瓶頸，使整個系統變慢。
與其讓20個服務向服務A索取資料，不如說每當服務A內發生一個事件，這個事件就會被廣播到一個流中，任何一個想從A獲得資料的服務都可以訂閱這個流並挑選出它所需要的資料。如果有一個流，所有的服務都可以廣播他們的事件並訂閱，那會怎麼樣？這種模式被稱為pub/sub：釋出和訂閱。這就是像Kafka這樣的解決方案所允許你做的。由於所有的資料都是透過一個流來流動的，你可以設定一個儀表盤來監控你的資料和它在整個系統中的轉變。因為它是基於服務所廣播的事件，這種架構是事件驅動的。
Beyond Microservices: Streams, State and Scalability(Gwen Shapira, QCon 2019)
請求驅動的架構對那些更依賴邏輯而非資料的系統來說效果很好。事件驅動架構對重資料的系統效果更好。
挑戰
許多公司正在從批處理轉向流處理，從請求驅動的架構轉向事件驅動的架構。我與美國和中國的主要網際網路公司交談的印象是，這種變化在美國仍然很緩慢，但在中國則快得多。流媒體架構的採用與Kafka和Flink的普及有關。Robert Metzger告訴我，他觀察到在亞洲使用Flink的機器學習工作負載比在美國要多。谷歌趨勢中的 "Apache Flink "與這一觀察一致。
流處理沒有更受歡迎的原因有很多。
- 公司沒有看到流處理的好處
- 他們的系統還沒有達到服務間通訊成為瓶頸的規模。
- 他們沒有受益於線上預測的應用。
- 他們有可能從線上預測中受益的應用，但他們還不知道，因為他們以前從未做過線上預測。
2.對基礎設施的初始投資高
基礎設施的更新是昂貴的，並可能危及現有的應用程式。管理者可能不願意投資升級他們的基礎設施以允許線上預測。
3.心態轉變
從批處理轉換到流處理需要一個心理轉變。在批處理中，你知道一項工作何時完成。而在流處理中，它永遠不會完成。你可以制定一些規則，比如獲得過去2分鐘內所有資料點的平均值，但如果2分鐘前發生的事件被延遲了，還沒有進入資料流怎麼辦？在批處理中，你可以有定義明確的表並將它們連線起來，但在流處理中，沒有表可以連線，那麼對兩個流進行連線操作是什麼意思？
4.Python的不相容性
Python是機器學習的通用語言，而Kafka和Flink則執行在Java和Scala上。引入流可能會在工作流程中造成語言不相容。Apache Beam在Flink之上提供了一個Python介面，用於與流進行通訊，但你仍然需要能夠使用Java/Scala的人。
5.更高的處理成本
批次處理意味著你可以更有效地使用你的計算資源。如果你的硬體能夠一次處理1000個數據點，那麼用它來一次只處理1個數據點就是浪費了。
第二級：持續學習--你的系統可以納入新的資料並實時更新
這裡的實時被定義為幾分鐘的時間。
定義 "持續學習"
我使用了 "持續學習"，而不是 "線上訓練 "或 "線上學習"，因為後兩個詞讓人們想到從每個傳入的資料點中學習。真正做到這一點的公司非常、非常少，因為。
- 這種方法受到災難性遺忘的影響--神經網路在學習新的資訊時，會突然忘記以前學習的資訊。
- 在一個數據點上執行一個學習步驟可能比在一個批次上執行更昂貴（這可以透過擁有足夠強大的硬體來處理正好一個數據點來緩解）。
即使一個模型在每個傳入的資料點上都在學習，也不意味著每個資料點之後都會部署新的權重。由於我們目前對ML演算法如何學習的理解有限，更新的模型需要首先被評估，以瞭解它的表現如何。
對於大多數做所謂的線上訓練或線上學習的公司來說，他們的模型在微型批次中學習，並在一定時間後進行評估。只有在其效能被評估為令人滿意之後，模型才會被更廣泛地部署。對於微博來說，他們從學習到部署模型更新的迭代週期是10分鐘。
Machine learning with Flink in Weibo(于謙，Flink Forward 2020)
然而，持續學習並不是指重新訓練的頻率，而是指重新訓練模型的方式。
大多數公司做的是無狀態再訓練--模型每次都是從頭開始訓練。持續學習意味著允許有狀態的訓練--模型在新資料上繼續訓練（微調）。
一旦你的基礎設施被設定為做有狀態的訓練，訓練頻率就只是一個旋鈕。你可以每小時更新一次模型，每天一次，也可以在你的系統檢測到分佈變化時更新你的模型。
使用案例
TikTok是令人難以置信的上癮。它的秘密在於其推薦系統能快速學習你的喜好，並推薦你接下來可能會看的影片，給使用者帶來難以置信的滾動體驗。這是可能的，因為TikTok背後的公司位元組跳動已經建立了一個成熟的基礎設施，使他們的推薦系統能夠實時學習使用者的喜好（用他們的行話說是 "使用者檔案"）。
推薦系統是持續學習的完美人選。它們有自然的標籤--如果一個使用者點選了一個推薦，那就是一個正確的預測。並非所有的推薦系統都需要持續的學習。使用者對房屋、汽車、航班、酒店等物品的偏好不太可能從一分鐘到下一分鐘發生變化，所以系統持續學習的意義不大。然而，使用者對線上內容--影片、文章、新聞、推特、帖子、備忘錄--的偏好可能變化非常快（"我剛剛讀到章魚有時會無緣無故地打魚，現在我想看它的影片"）。由於對線上內容的偏好是實時變化的，廣告系統也需要實時更新以顯示相關的廣告。
持續的學習對於系統適應罕見事件至關重要。考慮一下黑色星期五的網上購物。因為黑色星期五每年只發生一次，亞馬遜或其他電子商務網站不可能獲得足夠的歷史資料來了解使用者在那一天的行為，所以他們的系統需要在那一天不斷地學習以適應。
或者考慮當某個著名的人在推特上釋出一些愚蠢的東西時的推特搜尋。例如，關於 "四季全面美化 "的新聞一上線，很多人就會去搜索 "全面美化"。如果你的系統沒有立即瞭解到這裡的 "全面美化 "是指新聞釋出會，那麼你的使用者就會得到大量的園藝推薦。
持續的學習也可以幫助解決冷啟動問題。一個使用者剛剛加入你的應用程式，你還沒有他們的資訊。如果你沒有任何形式的持續學習的能力，你將不得不為你的使用者提供一般的建議，直到下一次你的模型被離線訓練。
解決方案
由於持續學習仍然相當新，而且大多數正在做的公司還沒有公開談論它的細節，所以沒有標準的解決方案。
持續學習並不意味著 "沒有批次訓練"。那些最成功地使用持續學習的公司也在離線情況下平行訓練他們的模型，然後將線上版本與離線版本相結合。
挑戰
持續學習面臨著許多挑戰，包括理論和實踐。
理論上
持續學習將我們所學到的很多關於機器學習的知識翻了個底朝天。在機器學習的入門課上，學生們可能會被教導不同版本的 "用足夠數量的歷時來訓練你的模型，直到收斂。"在持續學習中，沒有歷時，你的模型對每個資料點只看一次。也沒有所謂的收斂。你的基礎資料分佈一直在變化。沒有什麼固定的東西可以收斂。
持續學習的另一個理論挑戰是模型評估。在傳統的批次訓練中，你在固定的測試集上評估你的模型。如果一個新的模型在相同的測試集上比現有的模型表現得更好，我們就說新的模型更好。然而，持續學習的目標是讓你的模型適應不斷變化的資料。如果你的更新模型是為了適應現在的資料而訓練的，而我們知道現在的資料與過去的資料不同，那麼用舊的資料來測試你的更新模型就沒有意義了。
那麼我們怎麼知道在過去10分鐘的資料上訓練的模型比20分鐘前的資料上訓練的模型要好呢？我們必須在當前資料上比較這兩個模型。線上訓練需要線上評估，但是把一個沒有經過測試的模型提供給使用者，聽起來就像一個災難的秘訣。
許多公司還是這樣做了。新的模式首先要經過離線測試，以確保它們不是災難性的，然後透過複雜的A/B測試系統與現有模式並行評估。只有當一個模型被證明在公司關心的某些指標上優於現有模型時，它才能被更廣泛地部署。(不要讓我開始為線上評估選擇一個指標）。
實用
目前還沒有線上培訓的標準基礎設施。一些公司已經將流媒體架構與引數伺服器，但除此之外，與我交談過的做線上訓練的公司必須在內部建立大量的基礎設施。我不願意在網上討論這個問題，因為一些公司要求我對這些資訊進行保密，因為他們正在為自己建立解決方案--這是他們的競爭優勢。
美國和中國之間的MLOs競賽
我讀過很多關於美國和中國之間的人工智慧競賽的文章，但大多數比較似乎都集中於美國的人工智慧數量。 論文，專利，引用， 資金 只有在我開始與美國和中國的公司討論實時機器學習之後，我才注意到他們的MLOps基礎設施有驚人的差異。
很少有美國網際網路公司嘗試持續學習，即使在這些公司中，持續學習也是用於簡單的模型，如邏輯迴歸。透過與中國公司直接交談以及與兩國公司合作的人交談，我的印象是，持續學習在中國更普遍，中國的工程師也更渴望實現這一跳躍。你可以看到一些談話的內容。
總結
機器學習正在走向實時，無論你是否準備好了。雖然大多數公司仍在爭論線上推理和持續學習是否有價值，但其中一些做得正確的公司已經看到了投資回報，他們的實時演算法可能是幫助他們領先於競爭對手的一個主要因素。
我對實時機器學習還有很多想法，但這篇文章已經很長了。如果你有興趣聊一聊這個問題。
鳴謝
這篇文章是與以下優秀的工程師和學者多次談話的綜合結果。我要感謝Robert Metzger, Neil Lawrence, Savin Goyal, Zhenzhong Xu, Ville Tuulos, Dat Tran, Han Xiao, Hien Luu, Ledio Ago, Peter Skomoroch, Piero Molino, Daniel Yao, Jason Sleight, Becket Qin, Tien Le, Abraham Starosta, Will Deaderick, Caleb Kaiser, Miguel Ramos。
還有幾個人選擇保持匿名。沒有他們，這個帖子將是不完整的。
感謝 Luke Metz謝謝你成為一個了不起的第一個讀者!
