Snap：如何加速推薦系統的特徵工程

Snap 的特徵工程挑戰
對於許多 Snap 團隊來說，提取建模訊號一直是一項高難度的活動。從歷史上看，團隊僅依賴於需要在關鍵服務元件中實現和記錄功能的前向填充過程。然後，他們在訓練任何模型之前等待特徵日誌數週。
隨著時間的推移，這個過程被證明是一個主要瓶頸：

1. ML 工程師通常不熟悉線上服務元件，接觸它們是有風險的。另一方面，委派給基礎設施工程師會引入協調開銷。
2. 判斷一個功能是否有用的週轉時間非常長。
3. 每個團隊都構建自己的具有重疊功能的基礎架構。雖然擁有更多工程資源的團隊可以構建更復雜的系統，但較小的團隊無法輕鬆訪問更高階的功能。此外，幾乎不可能共享功能。

Robusta
功能自動化框架 Robusta（以咖啡豆命名）是我們解決痛點的初步嘗試。它側重於關聯和交換聚合特徵。這些特徵在我們的 ML 應用程式中被廣泛使用，有時佔 ML 模型中超過 80% 的訊號。關聯和交換屬性對分散式系統非常友好，允許我們做出方便的假設。事實上，業內許多公司都有類似的系統，例如Airbnb Zipline [1] 和Uber Palette [2]。我們從他們那裡得到了很大的啟發。
在設計和實施 Robusta 時，我們必須克服的一些顯著挑戰是：

• Velocity：如何透過單一的宣告性功能規範端到端啟用新功能，無需手動服務部署，也不會給 ML 基礎架構帶來風險。
• 規模：典型的 ML 用例具有數千個具有不同屬性的聚合功能。例如，它們可能有不同的滑動視窗，有時按使用者 ID 聚合，有時按快照 ID 或多個鍵的組合（即使用者 ID + 發現頻道 + 一天中的小時）。有些操作可以很容易地表示為關聯和交換操作，但也有一些操作需要一些工作來調整和適應。我們需要設計一個框架來實現這些可能性，同時每天有效地處理數十億個事件。
• 正確性：如何支援近實時特徵的離線生成，也就是解決所謂的時間點正確性問題 [3]。我們必須回答線上推理時的特徵值是什麼。當我們擁有可以以分鐘級粒度更新的滑動視窗功能時，這尤其具有挑戰性，因為對於大多數使用者來說，即使沒有任何新的參與事件，隨著時間的推移，特徵值可能每分鐘都在變化。