經驗教訓：Instacart 的實時機器學習之旅 - shu

​

圖 1 描繪了 Instacart 的典型購物旅程，由數百個機器學習模型提供支援。所有這些操作都是實時發生的，這意味著實時利用機器學習可以為業務提供重要價值。我們經歷的主要變化之一是將我們的許多面向批處理的 ML 系統轉換為實時系統。在這篇文章中，我們描述了我們的過渡過程，回顧了主要挑戰和決定，並吸取了重要的教訓，可以幫助其他人從我們的經驗中學習。

面向批處理的機器學習系統的歷史

​
圖 2：面向批處理的 ML 系統

生產中的大多數機器學習都是關於利用源自原始資料的訊號（特徵）來預測目標（標籤）。特徵的質量至關重要，特徵主要按新鮮度分為兩類：

• 批次特徵：從歷史資料中提取的特徵，通常透過批處理。這些型別的特徵通常很少更改，例如食品的類別或營養資訊。
• 實時特徵：從實時資料中提取的特徵，通常透過流處理。這些型別的特徵通常會頻繁變化，這些變化對於模型預測和決策至關重要。一些示例包括實時商品可用性、供應（線上購物者數量）和需求（訂單數量）以及客戶實時購物會話。

• 1）機器學習模型只能訪問批處理功能；
• 2) 這些模型批次離線生成預測，然後離線使用這些預測進行分析，或者使用查詢表線上使用這些預測。

1. 陳舊的預測：預計算的預測在許多應用程式中提供了較差的體驗，因為它們只對過去發生的請求產生陳舊的響應。例如，批次預測只允許我們對歷史查詢進行分類，但在新查詢上表現不佳。
2. 資源使用效率低下：每天為所有客戶生成預測是一種資源浪費，因為許多客戶並非每天都處於活躍狀態。
3. 有限的覆蓋範圍：該系統提供有限的覆蓋範圍。例如，由於基數很大，不可能快取所有使用者-專案對的預測，我們必須截斷長尾中的對。
4. 響應滯後：模型對最近的變化響應較慢，因為模型無法訪問實時功能，例如客戶在當前購物會話中的意圖和實時產品可用性。
5. 次優：資料新鮮度會影響模型輸出的質量。如果沒有最新的訊號（例如供需），履行過程可能不是最理想的，因為模型無法訪問實時變化，而且決策滯後會導致資源分配效率低下。

• 實時服務：從提供預先計算的預測到實時服務，以減少陳舊性、有限的覆蓋範圍和資源利用不足。
• 實時特性：從批處理特性到實時特性，確保資料新鮮，並使模型能夠響應最新的變化。

過渡 1：從提供預先計算的預測到實時服務

​
圖 3：具有實時服務的 ML 平臺

兩種產品使過渡到實時服務系統成為可能：特徵商店和線上推理平臺。特徵儲存是用於快速特徵檢索的鍵值儲存，線上推理平臺是將每個模型作為 RPC（遠端過程呼叫）端點託管的系統。Real-Time Serving 透過整合新功能（例如個性化）改進了機器學習應用程式，透過消除未使用的預測的執行來最佳化計算資源，以及透過最佳化長尾查詢來增加轉換。最重要的是，它還提供了更好的客戶體驗，因為它結合了個性化結果併為新使用者/查詢改進了結果。

儘管這種轉變對於機器學習應用來說是一個重大勝利，但引入實時服務帶來了許多技術挑戰。
轉向實時服務的挑戰

• 延遲：延遲在使用者體驗中起著重要作用；沒有人喜歡在購物時等待搜尋結果載入。實時服務系統引入了對特徵檢索、特徵工程和模型預測的依賴性，並且使得這些過程必須快速並且可以在緊張的延遲預算下進行訪問。
• 可用性：實時推理系統引入了可能導致後端服務停機的故障點。確保模型服務的高可用性需要更好的監控、錯誤處理和部署實踐。
• 陡峭的學習曲線：該系統涉及理解許多新的元件和過程。它主要對機器學習工程師具有挑戰性，因為它改變了開發過程並引入了許多新工具。

• 統一介面：開發統一介面Griffin使我們能夠整合單元測試、整合測試和金絲雀部署等最佳實踐。它還透過提供標準工作流模板和用於快速故障排除的工具來縮短機器學習工程師的學習曲線。此外，為我們的系統建立單個入口點使我們能夠標準化監控、可觀察性和其他可靠性所需的流程。
• 通用服務格式：我們選擇了在 Instacart 廣泛用於服務間通訊的 RPC 框架。重用現有工具使我們能夠快速開發生產級平臺並支援多種語言之間的通訊，例如 Ruby、Scala、Python 和 Go。此外，它允許機器學習工程師在團隊之間共享知識，並透過協作更快地成長。

過渡 2：從批處理功能到實時功能

​
圖 4：具有實時服務和實時功能的 ML 平臺

透過消除預先計算的預測的陳舊性和有限的覆蓋範圍，向實時服務的過渡改善了使用者體驗。然而，所有的預測仍然基於批次特徵。購物旅程中的最佳體驗需要批次功能和實時功能。為了實現實時特性，我們開發了一個帶有流技術的實時處理管道，如圖 4 所示。管道監聽儲存在Kafka中由服務釋出的原始事件，使用Flink將它們轉換為所需的特性，並將它們下沉到 Feature儲存按需訪問。儘管流媒體是一項相對成熟的技術，但我們在轉型過程中仍面臨不少挑戰。

挑戰:

• 不同組織中的孤立流技術：不同團隊對流處理的需求各不相同，從簡單的通知到分析。因此，每個組織都採用了適合其各自需求的工具，我們最終得到了三種不同的流媒體工具。這在每個組織內部都可以正常工作，但對於機器學習來說卻是一個挑戰，因為它需要跨不同組織構建事件。
• 活動一致性和質量：活動主要由當地團隊根據其特定需求進行消費/管理。這在合併事件以生成實時特徵時帶來了兩個挑戰：1）不清楚哪些事件可用；2) 活動質量無法保證。
• 具有新開發流程的複雜管道：如圖 4 所示，實時功能管道引入了新的技術堆疊。它從服務釋出的原始事件開始，經過流處理和特徵儲存，並實時響應使用者請求。這方面的挑戰是雙重的。一方面，實時特徵（一般來說是流式傳輸）對於機器學習工程師和資料科學家來說並不是常識。另一方面，建立流式處理的開發環境涉及更多。資料流技術在 JVM（Java 和 Scala）中效果最好，而在 Python 中的支援並不理想，這一事實也使得學習曲線更加陡峭。

• 集中式事件儲存：鑑於不同組織中存在多個流式後端的挑戰性情況，我們選擇 Kafka 作為集中式儲存，將所有原始事件放在一起，以便我們可以從它們以一致的格式匯出 ML 特徵。這會給管道帶來一些額外的延遲（通常在 100 毫秒內）並使用更多資源，但好處大於這些缺點。首先，集中式儲存可以快速擴充套件，避免在實時 ML 系統和不同的流媒體工具之間構建多個介面。其次，這不會影響現有的事件使用模式，集中式事件儲存可以輕鬆整合模式驗證和資料質量檢查以提高事件質量。
• 獨立的事件儲存和計算：我們還選擇了獨立的事件儲存和事件計算。一方面，按照關注點分離的設計原則，對系統進行了模組化，採用了最好的工作工具。另一方面，它以一致的格式和可配置的保留期為單個持久儲存中的所有事件提供基本事實參考。這使得資料審計和合規審查更容易，並在需要時支援在保留期內重放事件。
• 儘早組建跨職能工作組：由於實時功能（或一般的實時 ML 計劃）是一項高度跨職能的工作，因此在流程的早期，我們在不同團隊中組建了一個工作組，其中包括產品/專家業務開發、流媒體技術和 ML 開發。這個小組對於我們討論和達成解決我們在啟用實時 ML 方面的現有挑戰的決策至關重要。它還有助於我們討論和評估實時 ML 的早期用例。例如，由於工作組的集體意見，我們優先考慮實時專案可用性作為第一個用例，因為它本身不僅是一個基本模型，而且還提供基本的專案可用性分數，以提高專案找到率和客戶體驗，提高 ETA 預測準確性，並改進許多需要最新專案可用性的服務資訊。這一基本用例的成功使得此後實時機器學習得以迅速採用。

回顧

​
圖 5：使用實時 ML 的 Instacart 購物之旅

透過兩個關鍵的轉變和其他改進，我們建立了一個具有實時服務和實時功能的 ML 平臺，如圖 5 所示。該平臺將購物之旅轉變為更加動態和高效，具有更好的個性化和最佳化的履行。以下是平臺上推出的應用程式的一些亮點：

• 實時專案可用性在幾小時內更新專案可用性分數。這直接提高了物品找到率，減少了不良訂單，並最終提高了客戶滿意度。
• 基於會話的推薦和個性化模型在購物會話中實時進行預測。例如，透過根據客戶在最近會話中的選擇刪除他們不感興趣的專案，我們已經透過實時使用者印象資料使 Instacart 店面更加新鮮和動態。
• 欺詐檢測演算法實時捕捉可疑行為，並在損失發生之前防止欺詐活動成為可能。僅此一項就直接減少了每年數以百萬計的欺詐相關成本。

得到教訓

• 基礎設施在實時 ML 中發揮著關鍵作用 向實時系統過渡需要對基礎設施工具和流程進行重大投資，以實現更好的可觀察性、高效計算、高可用性和可靠部署。我們使用了許多工具和流程來實現實時服務和實時功能，這使我們能夠快速生產平臺並在 Instacart 中展示影響力。使用允許使用多種工具的統一介面對於我們的成功至關重要。
• 逐步取得進展從面向批處理的 ML 系統到實時 ML 平臺是一大步。為了使其更易於管理，我們在上面詳述的兩個不同階段進行了過渡。我們還為每個過渡確定了至少一個有影響力的用例。因此，在每個過渡階段，我們都有明確的目標，並且可以輕鬆衡量增量影響。這不僅使平臺更新更加漸進，而且還減少了採用該平臺的機器學習工程師的學習曲線。
• 通用和專業的解決方案我們採用了通用的解決方案，幫助我們以出色的支援覆蓋了大多數案例。為了加速開發，我們開始構建更專業的產品，例如嵌入平臺，以專注於更有針對性的情況並減少支援請求。泛化和專業化之間的這種平衡提高了那些專業用例的生產力，並實現了整個系統的高可靠性。
• 使用產品發展基礎設施在早期開發過程中採用我們平臺的機器學習工程師透過提供反饋和透過向 Instacart 的其他產品團隊推銷平臺來提高採用率，在提高質量方面發揮了重要作用。