ML Production 101 — data distribution shift
在資料圈工作一陣子之後發現，不論是 rule-based 的解法， ML 的解法，還是 DL 的解法，都時常會遇到，訓練的資料分佈和上線後的資料分佈不一致的情況，例如以下 :
- 自動駕駛車需要辨識紅綠燈，訓練資料都是晴天，但將模型上線時會遇到下雨，濃霧、沙塵甚至是月蝕。
- 電商推薦系統因為
雙11，黑色星期五等短時間的大型促銷，促使使用者會買平常不會買的商品。 - 吃喝玩樂部落格因
COVID-19，使用者的閱讀興趣改變。
而近期筆者也正在讀 CS329S — Machine Learning System Design，其中也提到了 data distribution shift[1, 2]，因此就在特別紀錄這個觀念，如果想直接看課程 PPT 的讀者們也可以直接下拉到 Reference 看哦 !
若想要在這篇文章中快速跳轉，可參考以下 Outline :
Data Distribution Shift 的種類
事實上 data distribution shift 在 1986年就被提及，2008年就有書籍描述[3]，而近期由於 ML 被各大科技巨頭大兩使用在產品中，才又引起了廣泛討論 要討論 distribution shift 之前，先借用 transfer learning 的術語來描述接下來我們要說的 :
- Source distribution — 訓練資料分佈，也可稱為 training distribution。
- Target distribution — 預測 / 產品上線時的資料分佈，也可稱為 testing distribution / production distribution。
而在監督式學習中，測試集資料分佈 / 產品上線時資料分佈 、模型學到的分佈
特徵集的分佈，標籤集的分佈 可以透過貝氏定理表示成以下 :
- P(X, Y) = P(Y|X)P(X)
- P(X, Y) = P(X|Y)P(Y)
- P(X, Y) —
測試集資料分佈 / 產品上線時資料分佈 - P(Y|X) —
模型學到的分佈 - P(X) —
特徵集的分佈 - P(Y) —
標籤集的分佈
而課程中將資料分佈的改變拆解成三項 :
- Covariate Shift — 特徵集分佈改變
- Label Shift — 標籤集分佈改變
- Concept Shift — 特徵和標籤之間的關係改變
在進入這三種 shift 之間，我們先來看看我們理想的狀況，也就是沒有資料分佈改變的狀況為何。
No Data Distribution Shift
考慮一份極為簡單的電商 log 資料集，只有一個特徵，年齡層，以及一個我們關心的標籤，點擊了什麼頁面
以 dataset, user_id, age_band, click_page_at_yyyymmdd 來做討論 :
source : 訓練用的資料集
production : 即上線後的收到的 log
dataset user_id age_band click_page_at_20220701
source abc 20-25 包包 A
source def 20-25 包包 A
source hij 20-25 包包 A
source xyz 20-25 包包 B
source 111 30-40 包包 A
source 222 30-40 包包 B
source 333 30-40 包包 B
source 444 30-40 包包 B
dataset user_id age_band prediction click_page_at_20220702
production !!! 20-25 包包 A 包包 A
production @@@ 20-25 包包 A 包包 A
production ### 20-25 包包 A 包包 A
production $$$ 20-25 包包 A 包包 B
production %%% 30-40 包包 B 包包 A
production ^^^ 30-40 包包 B 包包 B
production &&& 30-40 包包 B 包包 B
production *** 30-40 包包 B 包包 Bsource :
- 年齡層 20–25 偏好
包包A，有 3/4 的比例會點擊包包A - 年齡層 30–40 偏好
包包B，有 3/4 的比例會點擊包包B
production :
- 年齡層 20–25 偏好
包包A，有 3/4 的比例會點擊包包A - 年齡層 30–40 偏好
包包B，有 3/4 的比例會點擊包包B
以上例子可以看到 source, production 的資料分佈是一致的。
考慮一個監督式學習的模型，在只有一個特徵的情況下，有以上的 prediction 是極其合理的，也能夠在 production 資料集上有不錯的表現。
Covariate Shift
Covariate shift — 特徵集(feature set)的分佈改變了，但特徵集和標籤集的關係沒有改變。
其中又可以根據 training / production 階段產生 shift 來分類 :
Shift in Training Phase
假設在建構 source 資料集的階段，經由某種資料收集的方式，我們建構出以下 source 資料集 :
dataset user_id age_band click_page_at_20220701
source xyz 20-25 包包 B
source 111 30-40 包包 A
source 222 30-40 包包 B
source 333 30-40 包包 B
source 444 30-40 包包 B而根據 source 資料集訓練了模型，並且將其上線了，得到了以下 log :
dataset user_id age_band prediction click_page_at_20220702
production !!! 20-25 包包 B 包包 A
production @@@ 20-25 包包 B 包包 A
production ### 20-25 包包 B 包包 A
production $$$ 20-25 包包 B 包包 B
production %%% 30-40 包包 B 包包 A
production ^^^ 30-40 包包 B 包包 B
production &&& 30-40 包包 B 包包 B
production *** 30-40 包包 B 包包 B年齡層 20–25 僅收到一筆資料，並且點擊 包包B ，這使得模型認為年齡層 20-25 都喜歡 包包B，進而在 production set 預測 年齡層 20-25 都會點擊 包包B，在此例子中，對 production 的影響會是 :
年齡層 20-25 的預測失準，造成較低的點擊率。
我們可以說我們的 source set 有 sampling bias，或說某些特徵的資料太少，那麼可能的解決方法 :
- 在抽樣時特地檢視，使得 source set 和 production set 的特徵集分佈盡可能是一致的，在筆者的經驗中 minority sub-group 特別容易產生 sampling bias。
- 使用課程中所提到的 importance sampling [4] 的技巧。
Shift in Production Phase
這裡借用課程中的舉例
source : 假設你正在訓練一個偵測 COVID-19 的辨識模型，可以藉由每位病患在診間的咳嗽聲來識別是否得了 COVID-19，因此透過麥克風在診間收集了病人得咳嗽聲音頻譜資料。
production : 然而隨著 COVID-19 越來越嚴重，醫院 / 政府覺得還要請人到鄰近診間，中間多了許多傳染風險，因此希望預測時能夠透過電話設備來偵測，意即 production 環境是在電話中收集病人的咳嗽聲，來識別是否得了 COVID-19。
以上 source 和 production 中的資料分佈顯然是不同的，屬於 covariate shift。
因為 咳嗽聲 和 COVID-19 之間的關係並沒有改變， 主要的改變是來自於 source 的收音環境和 production 的收音環境不同，這可能導致收到的特徵集表現不一致，例如診間收到的聲音頻譜有更大的背景噪音，電話收到的聲音頻譜隨著病患所在的環境有不同的背景噪聲等等。
在這樣的情況下，可能的解決方法 :
- 調整收集資料和預測場景，使得 source set 和 production set 的特徵集分佈盡可能是一致的，比如收集資料時也使用電話，或者預測時要求病患在安靜的場所等等。
- 在 特徵歸一化 / 特徵工程 / 資料擴增上下功夫，在此場景下可能是濾波或其他訊號處理技巧，看有沒有方式能夠將 source set 和production set 輸入的特徵集經過處理後盡可能地相似(normalization)。
Concept Shift
Concept shift — 特徵集和標籤集的關係改變了，且標籤集的分佈和特徵集的分佈都沒有改變。
回到我們的人造電商資料集，我們根據了以下 source 資料集訓練了模型 :
dataset user_id age_band click_page_at_20220701
source abc 20-25 包包 A
source def 20-25 包包 A
source hij 20-25 包包 A
source xyz 20-25 包包 B
source 111 30-40 包包 A
source 222 30-40 包包 B
source 333 30-40 包包 B
source 444 30-40 包包 B而隨著時間的推移，發生了以下事件 :
- 該電商對於 包包B 找了 KOL 行銷，且目標族群年齡層是 20–25 歲
- 廠商又上了新款的 包包 C，也是針對年齡層 20–25 歲
production 收到 log 發生以下變化 :
dataset user_id age_band prediction click_page_at_20220702
production !!! 20-25 包包 A 包包 C
production @@@ 20-25 包包 A 包包 B
production ### 20-25 包包 A 包包 B
production $$$ 20-25 包包 A 包包 B
production %%% 30-40 包包 B 包包 A
production ^^^ 30-40 包包 B 包包 B
production &&& 30-40 包包 B 包包 B
production *** 30-40 包包 B 包包 B- 該電商對於
包包B找了 KOL 行銷，且目標族群年齡層是 20-25 歲 - 而該行銷活動奏效了，因此在 production 中 年齡層 20-25 的使用者轉向買包包B - 廠商又上了新款的
包包C，也是針對年齡層 20-25 歲 - 因此年齡層 20-25 歲的使用者也點擊了包包C
以上兩種情況不難看出是 年齡層 20–25 歲的使用者對於包包的喜好度改變了，而這樣的改變就被稱為 concept shift，也可以看到預測 20–25 歲喜歡包包 A，可能沒有跟進到 production 分佈的改變，使得預測失準。
- 那麼面對這樣的情況，一間值得省思的事情就是，隨著時間的推進，你的產品場景中，資料分佈改變得多快? 是每小時，每天，還是每雙週的檔期活動?
- 每一次檔期活動真的都有對目標族群產生影響嗎? 還是行銷活動沒有如實產生效果?
- 這也衍生了 ML Production 中 continual learning 的概念，其實概念上，筆者覺得和微積分有幾分神似:
既然 ML 只能預測 i.i.d. 那麼只要重新訓練的頻率夠快，跟得上 production 的 concept drift，那麼就能夠使 ML 做到 non-stationary 的預測。
Label Shift
Label shift — 標籤集的分佈改變了，但特徵集和標籤集的關係沒有改變。
我們考慮另一個優惠活動 :
該電商對於包包B做了優惠活動，分享連結給自己的朋友可獲得 包包B 的8折優惠，source / production 資料如下 :
dataset user_id age_band click_page_at_20220701
source abc 20-25 包包 A
source def 20-25 包包 A
source hij 20-25 包包 A
source xyz 20-25 包包 B
source 111 30-40 包包 A
source 222 30-40 包包 B
source 333 30-40 包包 B
source 444 30-40 包包 B
dataset user_id age_band prediction click_page_at_20220702
production !!! 20-25 包包 A 包包 A
production @@@ 30-40 包包 B 包包 B
production ### 30-40 包包 B 包包 B
production $$$ 30-40 包包 B 包包 B
production %%% 30-40 包包 B 包包 A
production ^^^ 30-40 包包 B 包包 B
production &&& 30-40 包包 B 包包 B
production *** 30-40 包包 B 包包 B- 該電商對於
包包B做了優惠活動，分享連結給自己的朋友可獲得包包B的8折優惠 - 且假設多吸引到很多年齡層 30-40 的使用者，因此在 production set / production 中，點擊包包B的使用者變多了，但年齡層和喜愛包包的比例之間的關係並沒有改變。 - 這個例子也發現了，在年齡層和喜愛包包的比例之間的關係沒有改變的情況下，產生 label shift 時，通常也會跟著產生 covariate shift
NOTE: 這裡其實課程中並沒有提到解決方案，不過筆者自己反思過後，如果確實是 label shift, 沒有產生 concept shift，其實不需要做任何動作，還是能夠準確的預測，因為模型學到的其實是 P(Y|X)。Continual Learning
經由以上三種 shift 的分析探討後，可以發現資料分佈隨著不同的行銷活動，季節性，節慶，或者使用者意圖的不同都會持續改變，除了能夠主動偵測 data distribution shift[5]之外，主動地重新訓練模型，或者 fine tune 模型，讓模型能夠適應新的資料分佈也是一個解法，稱之為 Continual Learning，這也是筆者在業界較常看到的解訣方案，而在課程中，講師將 Continual Learning 又拆解成 :
- continuously learn from fresh data — 持續地使用新的資料讓模型學習
- stateful training — 有狀態地學習 (筆者認為這種做法非常神似 transfer-learning)
Continuously Learn from New Data
這裡使用 Online Learning for Recommendations at Grubhub [9] 的圖示來說明 :
從上圖左(a)可以看到，在收集訓練資料時，設定一個 past n 的 time window，例如 過去60天、過去4天、過去7小時等時間區段，時間卻短越能夠確保收集到的資料分佈和 production 是接近的[6]，並且每隔一個時間區間就重新進行訓練(例如每天訓練一次)。
而要收集多長的時間通常會是一個 trade off，考慮以上資料集設計，不考慮每筆資料有不同的權重，不可慮其他模型後處理手法的情況下 :
收集越長時間的資料則 — 模型傾向反應使用者長期偏好 [7]
- 如果沒有 data shift，訓練資料越多，模型準確度有可能越高
2. 使用者最新喜歡的內容 / 物品並不會高比例的出現在推薦列表中
3. 前處理/特徵工程的計算負擔上升、訓練成本 (開機時間) 提升
收集越短時間的資料則 — 模型傾向反應使用者的短期偏好
- 如果沒有 data shift，訓練資料越少，模型準確度有可能越低
2. 使用者最新喜歡的內容 / 物品會高比例的出現在推薦列表中
3. 前處理/特徵工程的計算負擔下降、訓練成本 (開機時間) 下降
筆者在實務中考慮過的條件如下 :
- 若是運算條件允許，常用的做法是找幾個關心的指標，比如準確度或者計算時間，觀察收集資料的天數 n 帶來的效益，是否有個效益最大的點，來選出 n 值，這會隨著每個場景不同而有不同的選法。
- 若是運算條件較為吃緊，需要 near realtime 的產特徵，並做模型預測，那麼則更適合使用短的 time window[8]。
此外，每一次訓練時到底能夠拿到多新的資料? 24 hour / 12 hour / 3 分鐘以內 也決定了模型能夠多快地反應 data drift，特別是 concept drift。
Stateful Training
在課程中看到的觀念，想一想也覺得蠻直覺的，如果每天凌晨都會做一次模型訓練，撈去過去4天的 log 來做訓練，那麼其實每天過去，有很多的資料是重複被訓練的，花時間也花錢，能不能夠重用訓練過的模型，對該模型做 tuning 就好 ?
a.k.a. 我要拿昨天訓練好的模型，和今天多出來的資料，在 fine tune 一個新模型，同樣地借用 Online Learning for Recommendations at Grubhub [9] 的圖示來說明 :
從上圖 (b) 可以看出，隨著你撈取過去的天數 n 越大，每一次 stateful training 能夠省下的訓練時間和花費就會是 n 倍。
那麼這種做法會有什麼缺點呢?
筆者思考了一番大概就是回補資料不是很方便，由於是當天的訓練任務都需要前一天的模型，所以較難平行化的操作
看到這裡讀者們可能會想，既然 Continual Learning 的做法能夠讓 ML 適應 concept drift，那麼如果能做到 realtime / near-realtime，就再也不用怕使用者的興趣/意圖改變了不是嗎?
TikTok 也是這麼想的，這在他們的論文 — TikTok : Monolith: Real Time Recommendation System With Collisionless Embedding Table[10] 有表達，主要用在短影音推薦以及廣告排序中，主要架構如下 :
根據論文中所述 :
- PS — Parameter Server。
- batch training 是讀取 micro-batch 來做訓練，如同一般的模型訓練，但並沒有明說是採用 Stateful training or traning from scrath，訓練好之後就會把 model push 到 serving PS。
- 當模型開始進行服務時，online training 會啟動，吃的是 realtime data stream，會在 training PS 進行訓練和更新，再透過 sync scheduler 將訓練好的參數上線服務。
- 由於 TikTok 的 model size 屬於 TB 等級，要整包 sync 到 serving PS 會花上不少時間、網路頻寬和記憶體，所以 TikTok 採用的是 incremental update，大致概念是由於每次 realtime data 吃進來，只有部分的 embedding 以及部分的參數會被改變，因此不需要整個 model 都 sync ， 只要 sync 有變動的部分就行了，這也是工程上需要較精細設計和反覆驗證的部分。
在論文中，TikTok 說他們的設計確實能夠做到 realtime 的 online-learning ，模型更新頻率則在分鐘級，原文如下 :
We push the subset of sparse parameters whose
keys are in the touched-keys set with a minute-level time interval
from the training PS to the online serving PS
該論文說了蠻多實務上的設計，實驗設計上採用大家唾手可得的 MovieLens來模擬，挺有趣的，讀者們如果有興趣讀可以一起討論 =)
後記
以上是筆者近期讀了 CS329S — Data Distribution Shift & Continual Learning 並結合自己的一些經驗的紀錄。
如果各位讀者覺得有地方怪怪的話，可以直接留言讓我知道，我再進行調整，而對應的解決方式也是依照筆者所看過的場景和經驗，如果讀者們有其他解法，也歡迎留言分享!
也希望讀者們看完這篇文章後，更了解了 Data Distribution Shift & Continual Learning， 再依此標準檢視一下自己家的 ML System 囉！
最後，近期筆者也在找尋對推薦系統有興趣的夥伴一起啃食各大科技公司的推薦系統(Facebook, Netflix, Pinterest, …)，有興趣的讀者可以填這個
一起啃食 Paper, Tech Blog 了解各大公司的推薦系統架構!
Reference
- Data Distribution Shifts & Monitoring — CS329S
- Continual Learning Data Distribution Shifts on Streams — CS329S
- Dataset Shift in Machine Learning
- Rethinking Importance Weighting for Deep Learning under Distribution Shift 2020
- source distribution 和 target distribution 的差異能夠視為兩個資料分佈是否來自同個母體，統計學有很多檢定都能夠使用，此外也有 whylogs， evidently，alibi-detect等 open source library 能夠協助偵測資料分佈的改變
- 此論述只適用於漸進式(gradual)的改變，突發性(sudden)的分佈變化或是季節性的(cyclic)的分佈變化建議從資料搜集面以及特徵工程面著手
- 此描述是以預測的實體為一個 user 來描述，如果是預測實體是 item，那麼論述就會變成 item 長期/短期 的 profile
- 此條件下可能是 micro-batch 的資料流，雖然比起 batch 可以使用較少的運算資源，但運算機器 / 運算叢集可能要一直開著，也要計算效益和成本的比值是否符合專案/產品要求
- Online Learning for Recommendations at Grubhub 2021
- Monolith: Real Time Recommendation System With Collisionless Embedding Table 2022
