如何用MLOps保障時效表達穩定性
一、背景
消費者選擇電商平臺進行購物，除了獨特的商品，購物體驗也越來越成為消費者衡量平臺的重要標準。如何幫助客戶快速的檢索到自己想要購買的商品，如何讓客戶買到性價比最高的商品，如何幫助客戶在更短的時間內收到購買的商品，這些都是平臺為消費者提供的重要服務。筆者在訂單履約時效項目的參與過程中，主要負責通過算法，幫助平臺提升訂單履約率和準確率。
圖片
圖片
我們先來直觀感受一下時效對體驗的影響。從上面2張圖，我們能夠看到，右圖訂單的交付時效比較長，客戶對訂單支付意愿就會大大降低，有行業專業人士分析，時效表達多一天，影響的GMV就達千萬級，可見時效表達越短對應的收益越大，但也會給供應鏈履約帶來更大的成本。從運營的角度，如果想要給消費者更短時效的體驗，但卻超越了供應鏈當前的履約能力（比如告知消費者1天送達，實際是3天），則會帶來大量客訴，在得物平臺因為有“晚到必賠”規則，會額外增加超時賠付優惠券的負擔，引發資損。所以在得物做時效表達，需要同時兼顧時效的準確率（告知消費者1天送達，實際也是1天）和履約率（告知消費者1天送達，實際不超過1天）。
在我們長期探索過程中，模型逐漸經歷了統計模型、ML模型、DL模型的演化。商業環境上也經歷了惡劣天氣、春節、大促等各種極端場景的考驗，算法模型也在一次次的挑戰中，變得越來越堅實，并從手工操作逐步實現自動化流程。為了讓流程更加高效、穩定，我們引入了MLOps的理念，本文拋磚引玉，與大家一起聊聊，我們在結合MLOps應用的心路歷程，期待能與大家碰撞出思維的火花。
二、什么是MLOps
附：MLOps方法論：
https://ml-ops.org/content/mlops-principles
MLOps的核心理念
隨著算法模型在工業界的應用越來越深，越來越廣，業界逐漸實踐出一些標準，讓我們能更高效、更穩定、低成本且長久地管理模型的整個生命周期， 涉及模型訓練、模型發布、灰度或AB，及模型的長期監控等等。
其核心理念，主要有以下7個方面的模型管理規范：
- Versioning， 數據、模型、代碼等是否有版本記錄，是否能便捷地回溯；
- Testing， 數據、特征、模型的生成是否有邏輯校驗；代碼是否有單元測試等；
- Automation，數據、特征的生成是否有自動調度，模型訓練、搜參是否自動，代碼提交合并是否CI/CD；
- Reproducibility，基于Versioning的保障，是否能在任意時間復現歷史某次模型預測結果；
- Deployment，發布在生產、AB、陪跑等環境，是否能保證入參一致性，代碼一致性；
- Monitoring，模型精度下降是否能感知，數據漂移、數據泄露等是否會被發現；
- Documentation & Project Structure， 文檔、項目結構是否具備可讀性，結構性。
MLOps核心理念落地關鍵問題
MLOps的核心理念，應用到業務的過程，并不是一個完全由機器完成，全自動化的過程，而是需要業務團隊根據實際業務的情況，不斷調整入參，調整模型的過程，會涉及大量的人與機器的交互。因此，如何將這些核心理念應用到具體的業務中，我們需要思考2個方面的問題：
算法模型在設計過程中，要保障業務執行的效果
- 模型復現問題：預測模型是如何生成的，如果模型丟失了，能否重新訓練找回丟失的模型？
- 線上一致性問題線上時效表達時，訂單是由哪個模型預測的？同樣的入參給到同一個模型預測，是否保持冪等？發布新模型時，如何保障模型上線后的效果符合預期？
- 模型快速升級問題：線上指標下降了，模型更新流程需要多少人工介入？更新頻次的增加，是否帶來人工成本線性增長？
如何降低業務使用算法模型的門檻
- 運營模型的門檻是否可以降低？
- 業務、產品是否能配置化地訓練、選擇自己需要的模型？
- 是否能讓更多樣化的業務決策能落地，獲得更好的業務收益呢？
三、MLOps關鍵理念的實踐--時效仿真產品
基于上述的思考，我們設計并開發了時效仿真產品，并將MLOps的理念融入其中。
模型的可復現性
對于模型訓練環節來說，訓練集、代碼版本和模型參數是三個非常重要的因素。其中代碼版本、模型超參可以通過git和數據庫控制， 比較容易忽略的是訓練集的狀態，我們通過數據分層和業務日期隔離兩種方法確保了訓練集的可追溯性。
數據分層，保障數據版本一致性
如下左圖所示，在訓練環節，時效仿真產品的用戶可以圈選任意天的訂單用作訓練。同樣圈選了下列日期的樣本，站在不同日期訓練是不一樣的。比如站在20240903和20240902，那么對于20240901支付的訓練樣本，20240903會比20240902多一批已簽收訂單進入模型訓練。越近期的數據越能反映履約網絡的變化，一般20240903訓練得到的模型預測會更準一點。
時效仿真產品-訓練樣本的圈選
數據分層
這就說明了圈選同樣支付日期的訂單做訓練樣本，因為訓練日期不同導致已簽收訂單不同，進而影響實際進入模型訓練的樣本不同。
針對這個問題，我們做了數據分層，如上右圖所示，數倉會將每日訂單的最新狀態更新完畢， 用戶發起仿真任務后，服務端按需取對應訂單，通過仿真任務ID作為分區，落到訓練集和預測集表。隨后通過AI計算平臺調起訓練、預測任務，同樣傳入仿真任務ID，訓練預測任務取相應分區。這樣日后需要重新訓練，我們能保證同一個仿真任務得到的數據是一樣的。
業務日期隔離，防止數據泄露問題
數據分層雖然保障了數據版本的一致性，但時效場景因其特殊性，我們仍可能遇到數據泄露的問題。如下圖所示，按經驗訂單平均在4天內能被簽收，但是數據上從20240830開始訂單的簽收時間延長了，因為20240902是臺風摩羯登陸的日子，受到臺風天氣的影響，簽收時間也發生了變化。
針對20240830~20240901期間的支付訂單，做訂單簽收時長的時效預測，有一部分訂單會在臺風前簽收，有一部分會在臺風后簽收，在臺風到來前后訓練得到的模型是完全不同的，預測的結果也是不同的。
- 在臺風前訓練，模型平均預測時間就是4天，
- 在臺風后訓練，模型就會預測時間偏長。
如果臺風結束后模型沒及時調整，那整個時效表達的準確性就會大打折扣，不僅會破壞模型的可復現性，對模型準確性也造成了影響。我們做過測算，在不加干預情況下，臺風后預測樣本履約率會大幅上升(+2.3pt)，T日準確率大幅折損(-30.82pt)，模型表達過于保守。
同支付訂單 簽收區間示意圖
如何解決呢？
- 對于可復現性，我們在后臺記錄了每個仿真任務的執行業務日期， 根據業務執行日期來判斷，模型可以看到哪些天已簽收訂單做訓練數據， 這個場景里只要把業務日期固定在臺風前，那不管是哪天訓練的模型，其效果都是一樣的。
- 對于準確性而言，我們希望讓模型訓練正常日期，預測正常時長，臺風、暴雪等異常情況通過bcp（Business Continuity Planning）加時來保障，臺風過后指標能迅速回歸正常。基于此，我們在時效仿真產品里設計了訂單圈選時間類型，可以按支付或應履約日期來圈選，臺風情況就按應履約圈選臺風前的樣本即可，如下左圖。
圖片
通過上述的產品設計，我們能保證模型在任意時間訓練，任意歷史狀態下看到的數據都是一致的，為模型可復現性打下了基礎。每個模型訓練完成后，除了保存模型文件，我們也會記錄代碼版本、特征、后處理策略等模型必要參數。
線上的一致性保障
當我們得到理想的模型及仿真結果后，接下去要確保安全地上線，如何能確保也是知易行難。仿真可以失敗無數次，只要有一次成功就可以，上線卻不容許那么多次失敗，最好是一次成功。
在時效場景里更特殊的是：
- 隨著時間的推移我們的履約網絡能力是一個動態變化的過程，相應地模型也需要長期頻繁的更新。
- 每次模型上線后，其效果一般要等訂單走完支付到簽收的生命周期后才能回收效果，一般今天上線的模型，下周才知道線上效果如何。
那么如何保障模型每次更新都是可靠的，通過一段時間的探索，我們找到了模型可靠性三步曲，依靠流量回放、流程保障和自動發布來保障線上模型的效果。
流量回放，確保仿真入參和線上入參一致性，提升模型準確率
我們經常會遇到模型仿真效果很好，但線上陪跑就掉很多精度，排查后發現仿真和線上陪跑的入參存在不一致的情況。比如賣家發貨地址、承運商等信息，在支付的時候存在不確定性，線上有入參補齊邏輯，比如用子模型預測，或拿歷史眾數填充；但仿真時這些信息已成歷史，落在表里的是真實數據了。這就導致了線上、線下的入參不一致。
服務端同學為此建設了堅實的流量回放能力。平臺不同的業務流程，各環節的預測是不同的。以相對復雜的現貨流程為例，需要預測商家發貨、頭程運輸、庫內作業和尾程運輸，理論上每一段都可以用不同的模型來預測，每一段預測入參都可能不一樣。服務端同學設計的統一流量回放能力保障了在每一段的入參、出參、調用模型版本都記錄在案，做到了任意訂單的可追溯。
復雜的業務流程
統一的流量回放
對應到模型訓練、仿真環節， 我們用真實數據做訓練， 用線上實際入參來仿真，這樣最大化地保障模型精度，減少了仿真與上線之間的精度損失。
流程保障，取得模型穩定性和準確性之間的平衡，最大化業務效果
網絡履約能力會受到多種事件變化因素的影響，根據事件因素的特點，大致可分為臨時性變化和長久性變化。
- 臨時性變化：比如臺風惡劣天氣、兩會管控、春節打烊等事件觸發，事件開始時履約能力急劇變差，事件結束后馬上又恢復；
- 長久性變化：比如承運商班次調整、倉網變化等，其影響時間較長。
臨時性變化不應該放入模型訓練， 長久性變化應該讓模型去學習，并且越早學習到表達就越準。
如何判斷是臨時性還是長久性變化呢？如果不加約束，盡量用最新數據訓練，難以排除臨時性變化影響的樣本，這樣在事件結束后模型表達會偏保守，如上文的臺風后陪跑，會損失指標的穩定性。如果加以約束，用履約已完成的訂單做訓練，這樣可以通過履約時長等統計數據來判斷是否屬臨時性異常，可以減少異常樣本的干擾，但也會損失一定準確性。
與產品同學反復溝通了方案后，最終站在業務效果最大化的角度，我們選擇在穩定性和準確性之間取其平衡，每周會定時啟動較新樣本仿真，選其中較優模型進入陪跑，待部分簽收后決策是否選擇模型上線，詳細流程如下圖。
圖片
模型自動發布，確保模型落地效果
模型的發布涉及到一系列流程，流程中所做的配置和操作，對模型效果會有較大的影響。因此，模型的發布也是非常重要的環節。但模型發布，一般需要等一周后，有部分訂單簽收，才能看到實際的結果，存在滯后性。在早期曾發生過多起，因為模型發布流程問題，導致模型效果打了折扣，比如新特征模型取錯了線上Redis特征名、Ark開關配置錯誤、模型更新后部分服務器sdk未升級等等?；诖耍覀兘⒘四Ｐ妥詣影l布流程，將線上邏輯不符合預期的情況提前反映出來。
- 梳理了模型發布流程圖，將發布流程標準化，如下左圖所示；
- 取消發布流程中的手動操作，改為系統自動操作，同時沉淀了SLA；
- 接入了模型上線審批流：陪跑回收到符合預期的效果后，需要由業務方決策選用哪個模型上線，模型的上線，將直接決定業務運營的效果和管理成本，為此我們也接入了審批流，如下右圖所示；
- 建立離線陪跑相同模型的方法來驗證線上、仿真預測的一致性，離線陪跑的訂單及入參通過流量回放獲得，兩邊對比預測結果是否一致；
- 建立舊模型反向陪跑：尤其模型有新特征或新邏輯的情況下，未來的網絡履約能力可能存在較大的波動，如果舊模型直接下線，網絡履約能力波動帶來的影響將很難，需要有舊模型的陪跑，才能確定是線上邏輯問題，還是網絡履約能力變化問題。
發布流程
上線審批流
良好的自動化離不開合理的自動化流程設計，Automation作為MLOps的重要模塊，幫助我們較好的解決了手動操作帶來的風險和人工成本，在流量回放的一致性驗證、模型仿真陪跑流程、發布自動化三方面做的自動化為我們日常低成本運營帶來了很大幫助。
模型落地標準化、產品化、自動化，降低業務落地門檻
在模型線上表達比較穩定之后，公司希望在不同的業務場景嘗試模型的應用，比如經濟型快遞獨立模型、周末獨立模型、支付和應履約模型等，不同的場景應用目的雖然不同，但其底層基礎流程大致相同，為了能夠讓業務根據不同的管理訴求，能夠靈活的調整模型訓練集，我們跟時效工程、算法工程團隊合作，借助AI計算平臺的調度能力，結合自研的faas，將模型訓練、仿真做成了完全可自助的產品。其大致流程如下：
在產品前端，用戶可以按需選擇不同的樣本，選擇靈活性非常大，可以按不同周期、承運商、類目、訂單類型、線路等等各種維度來圈選需要訓練或仿真的訂單。服務端在接受訓練、仿真請求后，按需生成訓練集和預測集，再調度AI計算平臺執行相應任務。這里我們通過 faas解耦與仿真邏輯解析層隔離的方式支撐了產品靈活性和底層架構穩定性。
faas解耦，提升算法維護模型的靈活性
如下左圖，沒有faas，調用KubeAI的邏輯非常深地耦合在服務端的代碼里，算法同學想要調整這部分配置，就需要服務端同學改代碼去發版；
如下右圖，有了faas，服務端只需要關心調用了哪個function，關鍵的入參是什么就可以了，其調用如右圖。 鏡像版本、啟動命令、模板ID的更新就解耦給到算法同學去維護了，增加了算法迭代靈活性的同時，保障了服務端接口的穩定性。
服務端耦合過多調用AI計算平臺代碼
服務端只關心調用function和入參
仿真邏輯解析層隔離，計算任務原子化，適配多種業務場景
業務的需求往往是復雜的，靈活的，多變的，比如：
- 增加多種業務類型如品牌直發、現貨；
- 批量訓練、預測多個模型擇優，不同模型對應不同特征、超參等，最后將較優模型注冊到仿真產品；
- 支持多種預測目標，如支付-簽收、支付-到倉、發貨-簽收等不同模型。
面對業務多變的需求，我們需要讓計算任務具有原子性，穩定的特點。我們選擇在AI計算平臺實際執行的任務中增加解析層和后處理層的方法，與用戶的需求交互，按需生成不同的配置、啟動命令來調用pipline，中間執行的pipline是一直穩定的。
圖片
如此，我們將工程與算法的交互做了良好的解耦，讓工程與算法各司其職；讓底層穩定下來，解析層靈動起來。時效仿真產品就變得更敏捷，整個模型的訓練、預測可以更高效、自動地運轉。
目前，模型的仿真已經基本不需要算法同學介入，極大的解放了研發團隊在模型探索業務應用和模型更新上的精力，減少了研發在持續維護模型上的成本。
業務應用效果
綜上所述，在保證模型效果的同時，將模型的應用門檻降低，使得產品業務等非研發同學也能參與進模型的應用上來，借助其業務的敏感性和專業性，可以在更多的業務場景中創造進一步價值。
本期我們將為大家介紹，業務在模型使用中，兩個比較典型的創新方法，一個是時效AB方法，帶來了較好的貨幣化收益，一個是新特征挖掘，顯著提升了模型準確率兩個典型案例。
時效AB，貨幣化收益明顯
得物非常重視消費者的購物體驗，在時效上，也制定了賠付策略，為用戶提供訂單時效保障，超時則提供賠付補償。這套策略提升了客戶訂單的轉化，留存，但也對時效的保障提出了更高的要求，不僅要考慮時效的準確性，還需要兼顧賠付成本和GMV收益。如果時效表達過于激進，可能會促轉化提高GMV，但同時增大了訂單超時的風險，造成晚到必賠及客訴成本， 表達保守則反之。
那收益和成本之間的平衡點在哪兒呢？
產品同學由此牽頭做了AB實驗，通過仿真產品，我們得到多組履約率和準確率不同的組合，在不同用戶AB過程中找到了收益和成本之間的平衡點。
圖片
新特征挖掘，顯著提升模型準確性
業務產品在運營管理中發現，相對日常，周末、節假日期間，部分商家、承運商的網絡履約能力會有一定波動，模型預測準確度也會受到影響。
分析后發現，網絡履約能力的波動可以由一系列統計指標來刻畫，比如昨日支付單量、昨日未攬收單量比例等。那這些指標能否讓模型感知到呢？
通過仿真產品測算得到這些指標作為新特征，模型可以顯著提升準確率，上線后也能保持相應優勢，使得平臺在周末、節假日期間也能提供高質量履約服務。
通過產品化降低的使用門檻，我們也期望未來會有更多有意思的場景與產品業務同學共同挖掘，創造更大的價值！
五、延展scale的思考
經過近1年的建設，供應鏈算法團隊和時效團隊配合緊密做了完善的工程建設。但從長遠來看，供應鏈未來會有越來越多的場景要復用同樣的能力，從短期來看，當前合作模式也存在一定局限。
- 算法模型發布靈活性要求更高，預處理、后處理變動靈活，而業務代碼又期望穩定。
- 模型運營上對算法可見度較低，模型版本記錄、當前上線陪跑了哪些模型對算法無法有效感知。
- 模型推理耦合在業務應用里，對機器成本提高了要求。業務邏輯對機器配置要求低，但因為算法模型對機器要求配置高，所以拉高了業務域的機器成本，不便運維降本。
因此在最近供應鏈算法工程小分隊成立了，并且與AI計算平臺團隊強強聯合，希望把業務域邏輯和算法邏輯解耦開來，讓算法同學能更好地干預、運維模型，讓更多場景可以低成本地接入MLOps標準。
圖片
如上圖所示，讓AI負責底層調度，供應鏈工程負責抽象公共能力，供應鏈算法和業務開發團隊靈活地在各種場景落地。希望在不久的將來，我們有更多更好的故事可以與諸位分享，也歡迎各位業界大佬能加入我們團隊！
