RecSysOps：奈飛運維大型推薦系統的最佳實踐

問題檢測
在 RecSysOps 的四個元件中，問題檢測是最關鍵的一個，因為它會觸發其餘步驟。缺乏良好的問題檢測設定類似於閉著眼睛開車。

形式上，問題檢測非常簡單。如果生產中出現問題，我們需要能夠快速檢測到它。然而，出錯的方式有無數種，其中許多我們可能還沒有遇到過。以下是我們學到的一些經驗教訓，以增加我們在檢測問題方面的覆蓋面。

第一步是整合相關學科的所有已知最佳實踐。因為建立推薦系統涉及軟體工程和機器學習，這包括所有 DevOps 和 MLOps 實踐，例如單元測試、整合測試、持續整合、資料量檢查和模型指標檢查。幸運的是，有許多可用資源，例如本文[1] 以及可用於檢查 ML 系統並確定其差距的清單。

第二步是從您的角度對系統進行端到端的監控。在大型推薦系統中，經常會涉及到許多團隊，從 ML 團隊的角度來看，我們既有上游團隊（提供資料），也有下游團隊（使用模型）。我們學到的一件事是不要只依賴合作伙伴團隊的審計。最好（從我們自己的角度）稽核所有輸入和輸出，例如模型和這些模型生成的分數。例如，我們可能對上游團隊生成的資料的特定部分感興趣，而這部分的變化可能不會顯示在該團隊的整體審計中。再舉一個例子，如果一個團隊有興趣使用我們的模型並進行預測，我們可以與他們合作記錄模型預測的詳細資訊，例如特徵、獲取一小部分流量並從我們自己的角度對其進行稽核。這種端到端的審計幫助我們發現了下游和上游的許多問題，尤其是在涉及新資料來源的新專案開始時。

獲得全面報導的第三步是瞭解利益相關者的擔憂。這是增加問題檢測元件覆蓋率的最佳方式。在我們的推薦系統的上下文中，我們有兩個主要觀點：我們的成員和專案。

從成員的角度來看，問題非常簡單。如果成員選擇了服務排名模型排名不高的專案，這是一個潛在的問題。因此，監控和分析這些案例對於發現問題很重要，也是未來創新的重要靈感來源。
從專案的角度來看，我們需要確保與負責專案的團隊合作並瞭解他們的擔憂。就 Netflix 而言，這些團隊表示擔心適當的專案冷啟動和潛在的生產偏差。這些都是 RecSys 社群中活躍的研究領域，但首先我們幫助這些團隊圍繞他們的關注點定義指標並構建工具來監控它們。我們還幫助他們深入瞭解這些問題是否在每個專案的基礎上發生。後來我們將這些工具直接整合到我們的問題檢測元件中。這使我們能夠 1) 擴大問題檢測範圍，2) 主動解決與專案相關的關鍵問題並與利益相關者建立信任。

概括：

• 實施所有已知的最佳實踐
• 以自己的方式端到端監控系統
• 瞭解利益相關者的擔憂

問題預測
快速檢測生產問題固然很棒，但如果我們能夠預測這些問題並在它們投入生產之前修復它們，那就更好了。例如，一個專案（例如新電影、節目或遊戲）的正確冷啟動在 Netflix 很重要，因為每個專案只啟動一次。所以我們想知道我們是否可以預測一個專案是否會在釋出日期之前出現冷啟動問題。這需要預測我們未來的生產模型，這是具有挑戰性的。使用歷史資料點，我們構建了一個模型，可以預測我們的生產模型在釋出當天的行為統計資料。該模型使我們能夠提前一週或更長時間發現與專案冷啟動相關的潛在問題，這樣我們就有時間在專案進入服務之前解決問題。

概括：

• 嘗試在問題發生之前對其進行預測，而不是在問題投入生產後進行檢測

問題診斷
一旦透過檢測或預測模型確定了問題，下一階段就是找到其根本原因。此過程的第一步是單獨重現問題。然而，大規模推薦系統是非常動態的，我們可能無法透過簡單地重新執行程式碼來重現問題，例如底層輸入資料或特徵值可能已經改變。因此，要重現該問題，我們需要提前設定正確的日誌記錄。這包括記錄候選專案、上下文、功能、服務模型 ID 或重現問題所需的任何內容。為了降低成本，會為一小部分流量記錄此資訊。在這種情況下，我們需要精心設計一種取樣方法，使其能夠充分覆蓋所有重要的流量切片。

重現問題後的下一步是確定問題是否與 ML 模型的輸入或模型本身有關。要了解問題是否與輸入資料有關，我們需要驗證輸入是否準確有效。雖然某些特徵值可能可以將它們追溯到其原始事實並進行驗證，但可能有許多特徵涉及複雜的資料處理或機器學習模型本身的特徵。因此，在實踐中驗證輸入值是一個具有挑戰性的問題。

一個簡單的解決方案是將特徵值與​​可比較項或成員的對應值進行比較。這使我們能夠確定特徵值是否在預期範圍內。雖然簡單，但這種方法對於標記異常非常有效。例如，在一種情況下，此方法標記了與專案的語言特徵相關的異常值。經過進一步調查，我們發現該專案的語言在上游資料庫中沒有正確配置。

如果所有輸入特徵都正確，下一步就是深入挖掘 ML 模型及其訓練資料，找出問題的根本原因。有許多用於模型檢查和模型解釋的工具，例如 Shap [2] 和 Lime [3]。基於模型的架構，我們還可以開發自定義工具來檢查預期的屬性。例如，視覺化決策樹的節點或神經網路的層。這種型別的分析曾經幫助我們識別處理缺失值的錯誤，在另一種情況下幫助我們識別訓練資料的錯誤片段。

摘要：

• 設定日誌記錄以重現問題
• 開發工具來檢查輸入的有效性
• 開發工具來檢查 ML 模型的內部元件

問題解決
一旦確定了問題的根本原因，下一步就是解決問題。這部分類似於典型的軟體工程：我們可以有一個短期的修補程式或一個長期的解決方案。但是，為 ML 模型應用修補程式具有挑戰性。這是因為這些模型是高度最佳化的，可能需要一段時間來訓練，並且任何手動更改都可能導致次優推薦。那麼，我們如何才能在解決問題的同時最大限度地降低生態系統其他部分的成本呢？該解決方案需要高度依賴於產品、平臺和利益相關者的領域洞察力和創造力。由於每個修補程式都有自己的取捨，因此最好提前準備好修補程式解決方案的選單。這使我們能夠為每種情況快速選擇和部署最合適的一個。

除了解決問題之外，問題解決的另一個階段是改進 RecSysOps 本身。例如：

是否可以更快地發現問題？或者也許預測它？
是否可以改進我們的工具以更快地診斷問題？
最後，重要的是讓 RecSysOps 儘可能順暢。這使操作更順暢，系統更可靠。例如：

確保檢測或預測元件的檢查定期自動執行。
如果在某些步驟（例如診斷或解決方案）需要人為判斷，請確保該人已準備好所有必需的資訊。這將使他們能夠迅速做出明智的決定
確保部署修補程式就像單擊幾下一樣簡單

摘要：

• 準備好一系列修復策略並量化與每個策略相關的權衡
• 每一次事件都讓 RecSysOps 變得更好
• 使 RecSysOps 儘可能順暢

結論
在這篇博文中，我們介紹了 RecSysOps 以及我們在 Netflix 學到的一組最佳實踐和經驗教訓。RecSysOps 由四個部分組成：問題檢測、問題預測、問題診斷和問題解決。我們認為這些模式對於任何操作真實世界推薦系統的人來說都是有用的，可以讓它保持良好的效能並隨著時間的推移而改進。為大型推薦系統開發此類元件是一個迭代過程，對於未來的工作具有自身的挑戰和機遇。例如，可能需要不同型別的模型來進行問題檢測和預測。對於問題診斷和解決，需要對 ML 架構和設計假設有更深入的瞭解。總體而言，將這些方面放在一起幫助我們顯著減少了問題，