本文根據(jù)美團(tuán)配送資深技術(shù)專家鄭艷偉在2019 SACC（中國(guó)系統(tǒng)架構(gòu)師大會(huì)）上的演講內(nèi)容整理而成，主要介紹了美團(tuán)配送技術(shù)團(tuán)隊(duì)在建設(shè)一站式機(jī)器學(xué)習(xí)平臺(tái)過(guò)程中的經(jīng)驗(yàn)總結(jié)和探索，希望對(duì)從事此領(lǐng)域的同學(xué)有所幫助。

0. 寫(xiě)在前面

AI是目前互聯(lián)網(wǎng)行業(yè)炙手可熱的“明星”，無(wú)論是老牌巨頭，還是流量新貴，都在大力研發(fā)AI技術(shù)，為自家的業(yè)務(wù)賦能。配送作為外賣(mài)平臺(tái)閉環(huán)鏈條上重要的一環(huán)，配送效率和用戶體驗(yàn)是配送業(yè)務(wù)的核心競(jìng)爭(zhēng)力。隨著單量上漲、騎手增多、配送場(chǎng)景復(fù)雜化，配送場(chǎng)景的各種算法在更快（算法需要快速迭代、快速上線）、更好（業(yè)務(wù)越來(lái)越依賴機(jī)器學(xué)習(xí)算法產(chǎn)生正向的效果）、更準(zhǔn)（算法的各種預(yù)測(cè)如預(yù)計(jì)送達(dá)時(shí)間等，需要準(zhǔn)確逼近真實(shí)值）的目標(biāo)下也面臨日益增大的挑戰(zhàn)。算法從調(diào)研到最終上線發(fā)揮作用，需要有一系列的工程開(kāi)發(fā)和對(duì)接，由此引發(fā)了新的問(wèn)題：如何界定算法和工程的邊界，各司其職，各善其長(zhǎng)？如何提升算法迭代上線的速度和效率？如何快速準(zhǔn)確評(píng)估算法的效果？本文將為大家分享美團(tuán)配送技術(shù)團(tuán)隊(duì)在建設(shè)一站式機(jī)器學(xué)習(xí)平臺(tái)過(guò)程中的一些經(jīng)驗(yàn)和探索，希望對(duì)大家能有所幫助或者啟發(fā)。

1. 業(yè)務(wù)背景

2019年7月份，美團(tuán)外賣(mài)的日訂單量已經(jīng)突破3000萬(wàn)單，占有了相對(duì)領(lǐng)先的市場(chǎng)份額。圍繞著用戶、商戶、騎手，美團(tuán)配送構(gòu)建了全球領(lǐng)先的即時(shí)配送網(wǎng)絡(luò)，建設(shè)了行業(yè)領(lǐng)先的美團(tuán)智能配送系統(tǒng)，形成了全球規(guī)模最大的外賣(mài)配送平臺(tái)。

如何讓配送網(wǎng)絡(luò)運(yùn)行效率更高，用戶體驗(yàn)更好，是一項(xiàng)非常有難度的挑戰(zhàn)。我們需要解決大量復(fù)雜的機(jī)器學(xué)習(xí)和運(yùn)籌優(yōu)化等問(wèn)題，包括ETA預(yù)測(cè)、智能調(diào)度、地圖優(yōu)化、動(dòng)態(tài)定價(jià)、情景感知、智能運(yùn)營(yíng)等多個(gè)領(lǐng)域。同時(shí)，我們還需要在體驗(yàn)、效率和成本之間達(dá)到平衡。

2. 美團(tuán)配送機(jī)器學(xué)習(xí)平臺(tái)演進(jìn)過(guò)程

2.1 為什么建設(shè)一站式機(jī)器學(xué)習(xí)平臺(tái)

如果要解決上述的機(jī)器學(xué)習(xí)問(wèn)題，就需要有一個(gè)功能強(qiáng)大且易用的機(jī)器學(xué)習(xí)平臺(tái)來(lái)輔助算法研發(fā)人員，幫助大家脫離繁瑣的工程化開(kāi)發(fā)，把有限的精力聚焦于算法策略的迭代上面。

目前業(yè)界比較優(yōu)秀的機(jī)器學(xué)習(xí)平臺(tái)有很多，既有大公司研發(fā)的商用產(chǎn)品，如微軟的Azure、亞馬遜的SageMaker、阿里的PAI平臺(tái)、百度的PaddlePaddle以及騰訊的TI平臺(tái)，也有很多開(kāi)源的產(chǎn)品，如加州大學(xué)伯克利分校的Caffe、Google的TensorFlow、Facebook的PyTorch以及Apache的Spark MLlib等。而開(kāi)源平臺(tái)大都是機(jī)器學(xué)習(xí)或者深度學(xué)習(xí)基礎(chǔ)計(jì)算框架，聚焦于訓(xùn)練機(jī)器學(xué)習(xí)或深度學(xué)習(xí)模型；公司的商用產(chǎn)品則是基于基礎(chǔ)的機(jī)器學(xué)習(xí)和深度學(xué)習(xí)計(jì)算框架進(jìn)行二次開(kāi)發(fā)，提供一站式的生態(tài)化的服務(wù)，為用戶提供從數(shù)據(jù)預(yù)處理、模型訓(xùn)練、模型評(píng)估、模型在線預(yù)測(cè)的全流程開(kāi)發(fā)和部署支持，以期降低算法同學(xué)的使用門(mén)檻。

公司級(jí)的一站式機(jī)器學(xué)習(xí)平臺(tái)的目標(biāo)和定位，與我們對(duì)機(jī)器學(xué)習(xí)平臺(tái)的需求不謀而合：為用戶提供端到端的一站式的服務(wù)，幫助他們脫離繁瑣的工程化開(kāi)發(fā)，把有限的精力聚焦于算法策略的迭代上面。鑒于此，美團(tuán)配送的一站式機(jī)器學(xué)習(xí)平臺(tái)應(yīng)運(yùn)而生。

美團(tuán)配送機(jī)器學(xué)習(xí)平臺(tái)的演進(jìn)過(guò)程可以分為兩個(gè)階段：

• MVP階段：靈活，快速試錯(cuò)，具備快速迭代能力。

• 平臺(tái)化階段：業(yè)務(wù)成指數(shù)級(jí)增長(zhǎng)，需要機(jī)器學(xué)習(xí)算法的場(chǎng)景越來(lái)越多，如何既保證業(yè)務(wù)發(fā)展，又能解決系統(tǒng)可用性、擴(kuò)展性、研發(fā)效率等問(wèn)題。

2.2 MVP階段

初始階段，大家對(duì)機(jī)器學(xué)習(xí)平臺(tái)要發(fā)展成什么樣子并不明確，很多事情也想不清楚。但是為了支撐業(yè)務(wù)的發(fā)展，必須快速上線、快速試錯(cuò)。因此，在此階段，各個(gè)業(yè)務(wù)線獨(dú)自建設(shè)自己的機(jī)器學(xué)習(xí)工具集，按照各自業(yè)務(wù)的特殊需求進(jìn)行各自迭代，快速支持機(jī)器學(xué)習(xí)算法上線落地應(yīng)用到具體的業(yè)務(wù)場(chǎng)景，也就是我們所熟知的“煙囪模式”。此種模式各自為戰(zhàn)，非常靈活，能夠快速支持業(yè)務(wù)的個(gè)性化需求，為業(yè)務(wù)搶占市場(chǎng)贏得了先機(jī)。但隨著業(yè)務(wù)規(guī)模的逐漸擴(kuò)大，這種“煙囪模式”的缺點(diǎn)就凸顯了出來(lái)，主要表現(xiàn)在以下兩個(gè)方面：

• 重復(fù)造輪子：特征工程、模型訓(xùn)練、模型在線預(yù)測(cè)都是各自研發(fā)，從零做起，算法的迭代效率低下。

• 特征口徑混亂：各個(gè)業(yè)務(wù)方重復(fù)開(kāi)發(fā)特征，相同特征的統(tǒng)計(jì)口徑也不一致，導(dǎo)致算法之間難以協(xié)同工作。

2.3 平臺(tái)化階段

為了避免各部門(mén)重復(fù)造輪子，提升研發(fā)的效率，同時(shí)統(tǒng)一業(yè)務(wù)指標(biāo)和特征的計(jì)算口徑，標(biāo)準(zhǔn)化配送側(cè)的數(shù)據(jù)體系，美團(tuán)配送的研發(fā)團(tuán)隊(duì)組建了一個(gè)算法工程小組，專門(mén)規(guī)整各業(yè)務(wù)線的機(jī)器學(xué)習(xí)工具集，希望建設(shè)一個(gè)統(tǒng)一的機(jī)器學(xué)習(xí)平臺(tái)，其需求主要包括以下幾個(gè)方面：

• 該平臺(tái)底層依托于Hadoop/Yarn進(jìn)行資源調(diào)度管理，集成了Spark ML、XGBoost、TensorFlow三種機(jī)器學(xué)習(xí)框架，并保留了擴(kuò)展性，方便接入其它機(jī)器學(xué)習(xí)框架，如美團(tuán)自研的MLX（超大規(guī)模機(jī)器學(xué)習(xí)平臺(tái)，專為搜索、推薦、廣告等排序問(wèn)題定制，支持百億級(jí)特征和流式更新）。

• 通過(guò)對(duì)Spark ML、XGBoost、TensorFlow機(jī)器學(xué)習(xí)框架的封裝，我們實(shí)現(xiàn)了可視化離線訓(xùn)練平臺(tái)，通過(guò)拖拉拽的方式生成DAG圖，屏蔽多個(gè)訓(xùn)練框架的差異，統(tǒng)一模型訓(xùn)練和資源分配，降低了算法RD的接入門(mén)檻。

• 模型管理平臺(tái)，提供統(tǒng)一的模型注冊(cè)、發(fā)現(xiàn)、部署、切換、降級(jí)等解決方案，并為機(jī)器學(xué)習(xí)和深度學(xué)習(xí)模型實(shí)時(shí)計(jì)算提供高可用在線預(yù)測(cè)服務(wù)。

• 離線特征平臺(tái)，收集分揀線下日志，計(jì)算提煉成算法所需要的特征，并將線下的特征應(yīng)用到線上。

• 實(shí)時(shí)特征平臺(tái)，實(shí)時(shí)收集線上數(shù)據(jù)，計(jì)算提煉成算法所需要的特征，并實(shí)時(shí)推送應(yīng)用到線上。

• 版本管理平臺(tái)，管理算法的版本以及算法版本所用的模型、特征和參數(shù)。

• AB實(shí)驗(yàn)平臺(tái)，通過(guò)科學(xué)的分流和評(píng)估方法，更快更好地驗(yàn)證算法的效果。

3. 圖靈平臺(tái)

平臺(tái)化階段，我們對(duì)美團(tuán)配送機(jī)器學(xué)習(xí)平臺(tái)的目標(biāo)定位是：一站式機(jī)器學(xué)習(xí)平臺(tái)，給算法同學(xué)提供一站式服務(wù)，覆蓋算法同學(xué)調(diào)研、開(kāi)發(fā)、上線、評(píng)估算法效果的全流程，包括：數(shù)據(jù)處理、特征生產(chǎn)、樣本生成、模型訓(xùn)練、模型評(píng)估、模型發(fā)布、在線預(yù)測(cè)和效果評(píng)估。為了響應(yīng)這個(gè)目標(biāo)，大家還給平臺(tái)取了個(gè)大膽的名字——Turing，中文名稱為圖靈平臺(tái)，雖然有點(diǎn)“膽大包天”，但是也算是對(duì)我們團(tuán)隊(duì)的一種鞭策。

1）首先在獲取數(shù)據(jù)階段，支持在線和離線兩個(gè)層面的處理，分別通過(guò)采樣、過(guò)濾、歸一化、標(biāo)準(zhǔn)化等手段生產(chǎn)實(shí)時(shí)和離線特征，并推送到在線的特征庫(kù)，供線上服務(wù)使用。

2）模型訓(xùn)練階段，支持分類、回歸、聚類、深度學(xué)習(xí)等多種模型，并支持自定義Loss損失函數(shù)。

3）模型評(píng)估階段，支持多種評(píng)估指標(biāo)，如AUC、MSE、MAE、F1等。

4）模型發(fā)布階段，提供一鍵部署功能，支持本地和遠(yuǎn)程兩種模式，分別對(duì)應(yīng)將模型部署在業(yè)務(wù)服務(wù)本地和部署在專用的在線預(yù)測(cè)集群。

5）在線預(yù)測(cè)階段，支持AB實(shí)驗(yàn)，靈活的灰度發(fā)布放量，并通過(guò)統(tǒng)一埋點(diǎn)日志實(shí)現(xiàn)AB實(shí)驗(yàn)效果評(píng)估。

3.1 離線訓(xùn)練平臺(tái)

離線訓(xùn)練平臺(tái)的目標(biāo)是：搭建可視化訓(xùn)練平臺(tái)，屏蔽多個(gè)訓(xùn)練框架的差異，降低算法RD的接入門(mén)檻。

為了降低算法RD進(jìn)入機(jī)器學(xué)習(xí)領(lǐng)域的門(mén)檻，我們開(kāi)發(fā)了帶有可視化界面的離線訓(xùn)練平臺(tái)，通過(guò)各種組件的拖拉拽組合成DAG圖，從而生成一個(gè)完整的機(jī)器學(xué)習(xí)訓(xùn)練任務(wù)。

目前支持的組件大致分為：輸入、輸出、特征預(yù)處理、數(shù)據(jù)集加工、機(jī)器學(xué)習(xí)模型、深度學(xué)習(xí)模型等幾大類，每種類別都開(kāi)發(fā)了多個(gè)不同的組件，分別支持不同的應(yīng)用場(chǎng)景。同時(shí)為了不失去靈活性，我們也花費(fèi)了一番心思，提供了多種諸如自定義參數(shù)、自動(dòng)調(diào)參、自定義Loss函數(shù)等功能，盡量滿足各個(gè)不同業(yè)務(wù)方向算法同學(xué)各種靈活性的需求。

我們的離線訓(xùn)練平臺(tái)在產(chǎn)出模型時(shí)，除了產(chǎn)出模型文件之外，還產(chǎn)出了一個(gè)MLDL（Machine Learning Definition Language）文件，將各模型的所有預(yù)處理模塊信息寫(xiě)入MLDL文件中，與模型保存在同一目錄中。當(dāng)模型發(fā)布時(shí)，模型文件連帶MLDL文件作為一個(gè)整體共同發(fā)布到線上。在線計(jì)算時(shí)，先自動(dòng)執(zhí)行MLDL中的預(yù)處理邏輯，然后再執(zhí)行模型計(jì)算邏輯。通過(guò)MLDL打通了離線訓(xùn)練和在線預(yù)測(cè)，貫穿整個(gè)機(jī)器學(xué)習(xí)平臺(tái)，使得線下和線上使用同一套特征預(yù)處理框架代碼，保證了線下和線上處理的一致性。

在發(fā)布模型時(shí)，我們還提供了模型綁定特征功能，支持用戶把特征和模型的入?yún)㈥P(guān)聯(lián)起來(lái)，方便在線預(yù)測(cè)時(shí)模型自動(dòng)獲取特征，極大地簡(jiǎn)化了算法RD構(gòu)造模型輸入時(shí)獲取特征的工作量。

3.2 模型管理平臺(tái)

前面介紹了，我們的圖靈平臺(tái)集成了Spark ML、XGBoost、TensorFlow三種底層訓(xùn)練框架，基于此，我們的訓(xùn)練平臺(tái)產(chǎn)出的機(jī)器學(xué)習(xí)模型種類也非常多，簡(jiǎn)單的有LR、SVM，樹(shù)模型有GBDT、RF、XGB等，深度學(xué)習(xí)模型有RNN、DNN、LSTM、DeepFM等等。而我們的模型管理平臺(tái)的目標(biāo)就是提供統(tǒng)一的模型注冊(cè)、發(fā)現(xiàn)、部署、切換、降級(jí)等解決方案，并為機(jī)器學(xué)習(xí)和深度學(xué)習(xí)模型提供高可用的線上預(yù)測(cè)服務(wù)。

模型管理平臺(tái)支持本地和遠(yuǎn)程兩種部署模式：

• 本地：模型和MLDL統(tǒng)一推送到業(yè)務(wù)方服務(wù)節(jié)點(diǎn)上，同時(shí)圖靈平臺(tái)提供一個(gè)Java的Lib包，嵌入到業(yè)務(wù)方應(yīng)用中，業(yè)務(wù)方通過(guò)本地接口的方式調(diào)用模型計(jì)算。

• 遠(yuǎn)程：圖靈平臺(tái)維護(hù)了一個(gè)專用的在線計(jì)算集群，模型和MLDL統(tǒng)一部署到在線計(jì)算集群中，業(yè)務(wù)方應(yīng)用通過(guò)RPC接口調(diào)用在線計(jì)算服務(wù)進(jìn)行模型計(jì)算。

對(duì)于超大規(guī)模模型，單機(jī)無(wú)法裝載，需要對(duì)模型進(jìn)行Sharding。鑒于美團(tuán)配送的業(yè)務(wù)特性，可以按照配送城市/區(qū)域進(jìn)行分區(qū)訓(xùn)練，每個(gè)城市或區(qū)域產(chǎn)出一個(gè)小模型，多個(gè)分區(qū)模型分散部署到多個(gè)節(jié)點(diǎn)上，解決單節(jié)點(diǎn)無(wú)法裝載大模型的問(wèn)題。分區(qū)模型要求我們必須提供模型的路由功能，以便業(yè)務(wù)方精準(zhǔn)地找到部署相應(yīng)分區(qū)模型的節(jié)點(diǎn)。

同時(shí)，模型管理平臺(tái)還收集各個(gè)服務(wù)節(jié)點(diǎn)的心跳上報(bào)信息，維護(hù)模型的狀態(tài)和版本切換，確保所有節(jié)點(diǎn)上模型版本一致。

3.3 離線特征平臺(tái)

配送線上業(yè)務(wù)每天會(huì)記錄許多騎手、商家、用戶等維度的數(shù)據(jù)，這些數(shù)據(jù)經(jīng)過(guò)ETL處理得到所謂的離線特征，算法同學(xué)利用這些離線特征訓(xùn)練模型，并在線上利用這些特征進(jìn)行模型在線預(yù)測(cè)。離線特征平臺(tái)就是將存放在Hive表中的離線特征數(shù)據(jù)生產(chǎn)到線上，對(duì)外提供在線獲取離線特征的服務(wù)能力，支撐配送各個(gè)業(yè)務(wù)高并發(fā)及算法快速迭代。

最簡(jiǎn)單的方案，直接把離線特征存儲(chǔ)到DB中，線上服務(wù)直接讀取DB獲取特征Value。讀取DB是個(gè)很重的操作，這種方案明顯不能滿足互聯(lián)網(wǎng)大并發(fā)的場(chǎng)景，直接被Pass掉。

第二種方案，把各個(gè)離線特征作為K-V結(jié)構(gòu)存儲(chǔ)到Redis中，線上服務(wù)直接根據(jù)特征Key讀取Redis獲取特征Value。此方案利用了Redis內(nèi)存K-V數(shù)據(jù)庫(kù)的高性能，乍一看去，好像可以滿足業(yè)務(wù)的需求，但實(shí)際使用時(shí)，也存在著嚴(yán)重的性能問(wèn)題。

典型的業(yè)務(wù)場(chǎng)景：比如我們要預(yù)測(cè)20個(gè)商家的配送時(shí)長(zhǎng)，假設(shè)每個(gè)商家需要100個(gè)特征，則我們就需要20*100=2000個(gè)特征進(jìn)行模型計(jì)算，2000個(gè)KV。如果直接單個(gè)獲取，滿足不了業(yè)務(wù)方的性能需求；如果使用Redis提供的批量接口Mget，如果每次獲取100個(gè)KV，則需要20次Mget。緩存mget的耗時(shí)TP99約5ms，20次Mget，TP99接近100ms，也無(wú)法滿足業(yè)務(wù)方的性能需求（上游服務(wù)超時(shí)時(shí)間約50ms）。

因此，我們需要對(duì)離線特征從存儲(chǔ)和獲取進(jìn)行優(yōu)化。我們提出了特征組的概念，同一維度的特征，按照特征組的結(jié)構(gòu)進(jìn)行聚合成一個(gè)KV，大大減少了Key的數(shù)目；并且提供了相對(duì)完善的管理功能，支持對(duì)特征組的動(dòng)態(tài)調(diào)整（組裝、拆分等）。

3.4 實(shí)時(shí)特征平臺(tái)

相比于傳統(tǒng)配送，即時(shí)配送無(wú)論是在位置信息、騎手負(fù)載，還是在當(dāng)前路網(wǎng)情況，以及商家出餐情況等方面都是瞬息變化的，實(shí)時(shí)性要求非常高。為了讓機(jī)器學(xué)習(xí)算法能夠即時(shí)的在線上生效，我們需要實(shí)時(shí)地收集線上各種業(yè)務(wù)數(shù)據(jù)，進(jìn)行計(jì)算，提煉成算法所需要的特征，并實(shí)時(shí)更新。

3.5 AB實(shí)驗(yàn)平臺(tái)

AB實(shí)驗(yàn)并不是個(gè)新興的概念，自2000年谷歌工程師將這一方法應(yīng)用在互聯(lián)網(wǎng)產(chǎn)品以來(lái)，AB實(shí)驗(yàn)在國(guó)內(nèi)外越來(lái)越普及，已成為互聯(lián)網(wǎng)產(chǎn)品運(yùn)營(yíng)精細(xì)度的重要體現(xiàn)。簡(jiǎn)單來(lái)說(shuō)，AB實(shí)驗(yàn)在產(chǎn)品優(yōu)化中的應(yīng)用方法是：在產(chǎn)品正式迭代發(fā)版之前，為同一個(gè)目標(biāo)制定兩個(gè)（或以上）方案，將用戶流量對(duì)應(yīng)分成幾組，在保證每組用戶特征相同的前提下，讓用戶分別看到不同的方案設(shè)計(jì)，根據(jù)幾組用戶的真實(shí)數(shù)據(jù)反饋，科學(xué)的幫助產(chǎn)品進(jìn)行決策。?

互聯(lián)網(wǎng)領(lǐng)域常見(jiàn)的AB實(shí)驗(yàn)，大多是面向C端用戶進(jìn)行流量選擇，比如基于注冊(cè)用戶的UID或者用戶的設(shè)備標(biāo)識(shí)（移動(dòng)用戶IMEI號(hào)/PC用戶Cookie）進(jìn)行隨機(jī)或者哈希計(jì)算后分流。此類方案廣泛應(yīng)用于搜索、推薦、廣告等領(lǐng)域，體現(xiàn)出千人千面?zhèn)€性化的特點(diǎn)。此類方案的特點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單，假設(shè)請(qǐng)求獨(dú)立同分布，流量之間獨(dú)立決策，互不干擾。此類AB實(shí)驗(yàn)之所以能夠這樣做是因?yàn)?#xff1a;C端流量比較大，樣本足夠多，而且不同用戶之間沒(méi)有相互干擾，只要分流時(shí)足夠隨機(jī)，即基本可以保證請(qǐng)求獨(dú)立同分布。

即時(shí)配送領(lǐng)域的AB實(shí)驗(yàn)是圍繞用戶、商戶、騎手三者進(jìn)行，用戶/商戶/騎手之間不再是相互獨(dú)立的，而是相互影響相互制約的。針對(duì)此類場(chǎng)景，現(xiàn)有的分流方案會(huì)造成不同策略的互相干擾，無(wú)法有效地評(píng)估各個(gè)流量各個(gè)策略的優(yōu)劣。

鑒于上述的問(wèn)題，我們將配送側(cè)的AB實(shí)驗(yàn)分為三個(gè)階段：事前的AA分組，事中的AB分流，事后的效果評(píng)估。

• AA分組：將候選流量按照既定的規(guī)則預(yù)先分為對(duì)照組和實(shí)驗(yàn)組，基于數(shù)理統(tǒng)計(jì)的理論確保對(duì)照組和實(shí)驗(yàn)組在所關(guān)注的業(yè)務(wù)指標(biāo)上沒(méi)有顯著差異。

• AB分流：將線上請(qǐng)求實(shí)時(shí)分到對(duì)照或者實(shí)驗(yàn)版本。

• 效果評(píng)估：根據(jù)對(duì)照組和實(shí)驗(yàn)組的數(shù)據(jù)對(duì)比評(píng)估AB實(shí)驗(yàn)的效果。

由于即時(shí)配送的場(chǎng)景較為特殊，比如按照配送區(qū)域或城市進(jìn)行AB實(shí)驗(yàn)時(shí)，由于樣本空間有限，很難找到?jīng)]有差異的對(duì)照組和實(shí)驗(yàn)組，因此我們?cè)O(shè)計(jì)了一種分時(shí)間片AB對(duì)照的分流方法：支持按天、小時(shí)、分鐘進(jìn)行分片，多個(gè)時(shí)間片進(jìn)行輪轉(zhuǎn)切換，在不同區(qū)域、不同時(shí)間片之間，對(duì)不同的策略進(jìn)行交替切換進(jìn)行AB分流，最大限度減少線下因素的影響，確保實(shí)驗(yàn)科學(xué)公正。

4 總結(jié)與展望

目前圖靈平臺(tái)支撐了美團(tuán)配送、小象、LBS平臺(tái)等BU的算法離線訓(xùn)練、在線預(yù)測(cè)、AB實(shí)驗(yàn)等，使算法RD更加關(guān)注算法策略本身的迭代優(yōu)化，顯著提高了算法RD的效率。未來(lái)我們會(huì)在以下方面繼續(xù)深入探索：

1）加強(qiáng)深度學(xué)習(xí)的建設(shè)。

• 加強(qiáng)深度學(xué)習(xí)的建設(shè)，全面支持深度學(xué)習(xí)，實(shí)現(xiàn)深度學(xué)習(xí)相關(guān)組件與機(jī)器學(xué)習(xí)組件一樣，在可視化界面可以和任意組件組合使用。

• 離線訓(xùn)練支持更多常用深度學(xué)習(xí)模型。

• 支持直接寫(xiě)Python代碼自定義深度學(xué)習(xí)模型。

2）在線預(yù)測(cè)平臺(tái)化，進(jìn)一步解耦算法和工程。

• 簡(jiǎn)化圖靈平臺(tái)SDK，剝離主體計(jì)算邏輯，建設(shè)在線預(yù)測(cè)平臺(tái)。

• 在線預(yù)測(cè)平臺(tái)動(dòng)態(tài)加載算法包，實(shí)現(xiàn)算法、業(yè)務(wù)工程方、圖靈平臺(tái)的解耦。

作者簡(jiǎn)介

艷偉，美團(tuán)配送技術(shù)團(tuán)隊(duì)資深技術(shù)專家。

招聘信息

如果你想近距離感受一下圖靈平臺(tái)的魅力，歡迎加入我們。美團(tuán)配送技術(shù)團(tuán)隊(duì)誠(chéng)招調(diào)度履約方向、LBS方向、機(jī)器學(xué)習(xí)平臺(tái)、算法工程方向的技術(shù)專家和架構(gòu)師，共建全行業(yè)最大的單一即時(shí)配送網(wǎng)絡(luò)和平臺(tái)，共同面對(duì)復(fù)雜業(yè)務(wù)和高并發(fā)流量的挑戰(zhàn)，迎接配送業(yè)務(wù)全面智能化的時(shí)代。感興趣同學(xué)可投遞簡(jiǎn)歷至：tech@meituan.com（郵件標(biāo)題注明：美團(tuán)配送技術(shù)團(tuán)隊(duì)）。

總結(jié)

以上是生活随笔為你收集整理的一站式机器学习平台建设实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。