本文整理自 5 月 29 日阿里云開發(fā)者大會，大數(shù)據(jù)與 AI 一體化平臺分論壇，秦江杰和劉童璇帶來的《基于實時深度學(xué)習(xí)的推薦系統(tǒng)架構(gòu)設(shè)計和技術(shù)演進(jìn)》。分享內(nèi)容如下：

1.實時推薦系統(tǒng)的原理以及什么是實時推薦系統(tǒng)

2.整體系統(tǒng)的架構(gòu)及如何在阿里云上面實現(xiàn)

3.關(guān)于深度學(xué)習(xí)的細(xì)節(jié)介紹。

一、實時推薦系統(tǒng)的原理

在介紹實時推薦系統(tǒng)的原理之前，先來看一個傳統(tǒng)、經(jīng)典的靜態(tài)推薦系統(tǒng)。

用戶的行為日志會出現(xiàn)在消息隊列里，然后被ETL到特征生成和模型訓(xùn)練中。這部分的數(shù)據(jù)是離線的，離線的模型更新和特征更新會被推到在線系統(tǒng)里面，比如特征庫和在線推理的服務(wù)中，然后去服務(wù)在線的搜索推廣應(yīng)用。這個推薦系統(tǒng)本身是一個服務(wù)，前端展示的服務(wù)推廣應(yīng)用可能有搜索推薦、廣告推薦等。那么這個靜態(tài)系統(tǒng)到底是怎么工作的？我們來看下面的例子。

1. 靜態(tài)推薦系統(tǒng)

截取現(xiàn)在用戶的行為日志，倒入離線系統(tǒng)中去做特征生成和模型訓(xùn)練，這段日志表示用戶 1 和用戶 2 同時瀏覽了 page#200 這個頁面和其他一些頁面，其中用戶 1 瀏覽了 page#100 并且點擊了 ads#2002。那么這個日志會被 ETL 到離線，然后送去做特征生成和模型訓(xùn)練。生成的特征和模型里面會看到，用戶 1 和用戶 2 都是中國男性用戶，“中國男性”是這兩個用戶的一個特征，這個學(xué)習(xí)模型最終結(jié)果是：中國男性用戶瀏覽了 page#100 的時候，需要給他推 ads#2002。這里面的邏輯就是把相似用戶的行為歸到一起，說明這類用戶應(yīng)該有同樣的行為。

用戶特征推進(jìn)特征庫建立的模型，在推送至在線服務(wù)里的時候如果有一個用戶 4 出現(xiàn)，在線推理的服務(wù)就會到特征庫里面去查這個用戶的特征，查到的特征可能是這個用戶正好是中國的男性用戶，模型之前學(xué)到了中國男性用戶訪問 page#100 時候要推 ads#2002，所以會根據(jù)學(xué)習(xí)模型給用戶 4 推薦了 ads#2002。以上就是靜態(tài)推薦系統(tǒng)的基本工作流程。

但是這個系統(tǒng)也有一些問題，比如第一天的模型訓(xùn)練完成后，發(fā)現(xiàn)用戶 4 第二天的行為其實跟用戶 3 更像，不是和用戶 1、用戶 2 類似 。但是之前模型訓(xùn)練的結(jié)果是中國男性用戶訪問 page#100 時候要推 ads#2002，并且會默認(rèn)進(jìn)行這種推薦。只有經(jīng)過第二次模型計算后才能發(fā)現(xiàn)用戶 4 和用戶 3 比較像，這時再進(jìn)行新的推薦，是有延遲的。這是因為模型和特征都是靜態(tài)的。

對于靜態(tài)推薦系統(tǒng)來講，特征和模型都是靜態(tài)生成的。比如以分類模型為例，根據(jù)用戶的相似度進(jìn)行分類，然后假設(shè)同類用戶都有相似的行為興趣和特征，一旦用戶被化成了某一類，那么他就一直在這個類別中，直到模型被重新訓(xùn)練。

2. 靜態(tài)推薦系統(tǒng)問題

第一，用戶行為其實是非常多元化的，沒有辦法用一個靜態(tài)的事情去描述這個用戶的行為。
第二，某一類用戶的行為可能比較相似，但是行為本身發(fā)生了變化。例如中國男性用戶訪問page#100時候要推ads#2002，這是昨天的行為規(guī)律；但是到了第二天的時候發(fā)現(xiàn)不是所有的中國男性用戶看到page#100時候都會點擊ads#2002。

3. 解決方案

3.1 加入實時特征工程后能夠靈活推薦

在推薦系統(tǒng)中加入實時特征工程，把消息隊列里面的消息讀一份出來，然后去做近線的特征生成。舉個例子，中國男性用戶最近訪問 page#100 的時候點擊最多的 10 個廣告，這件事情是實時去追蹤的。就是說中國男性用戶最近 10 分鐘或者半個小時之內(nèi)訪問 page#100 的時候點的最多 10 個廣告，個事情不是從昨天的歷史數(shù)據(jù)里面得到的信息，而是今天的用戶實時行為的數(shù)據(jù)，這就是實時特征。

有了這個實時特征以后，就能解決剛才那個隨大流的問題。同樣的，如果這里的特征是對某一個用戶最近 3 分鐘或者 5 分鐘的行為采集的，就能夠更加準(zhǔn)確的追蹤到這個用戶當(dāng)時當(dāng)刻的意圖，并且給這個用戶去做更準(zhǔn)確的推薦。

所以說，在推薦系統(tǒng)中加入實時特征后能精準(zhǔn)推薦。比如剛才的例子，如果用戶 4 在這個情況下訪問 page#100，新的學(xué)習(xí)內(nèi)容為：中國男性用戶最近訪問 page#100 的時候，點的最多的是 ads#2001。那我們會直接推薦 ads#2001，而不是按照昨天的信息給他推 ads#2002。

3.2 實時特征推薦體系的局限性

之前的用戶 1 和用戶 2 的行為是非常相似的，加了實時特征就能知道它當(dāng)前的意圖。但是，如果用戶 1 和用戶 2 在做相同的特征時，他們的行為產(chǎn)生了不一致；也就是說在模型里面被認(rèn)為是同一類的用戶，他們的行為產(chǎn)生分化了，變成了兩類用戶。如果是靜態(tài)的模型，即使加入了實時特征，也無法發(fā)現(xiàn)這一類新的用戶；需要對模型進(jìn)行重新訓(xùn)練以后，才能夠產(chǎn)生一個新的分類。

加入實施特征工程推薦系統(tǒng)后，可以追蹤某一類用戶的行為，貼合一個大流的變化；也可以實時追蹤用戶的表現(xiàn)，了解用戶當(dāng)時的意圖。但是當(dāng)模型本身的分類方式發(fā)生變化的時候，就沒有辦法找到最合適的分類了，需要重新對訓(xùn)練模型進(jìn)行分類，這種情況會遇到很多。

比如說當(dāng)有很多新產(chǎn)品上線時，業(yè)務(wù)在高速增長，每天都會產(chǎn)生很多的新用戶，或者說用戶行為分布變化得比較快。這種情況下即使使用了實時特征系統(tǒng)，由于模型本身是一個逐漸退化的過程，也會導(dǎo)致昨天訓(xùn)練的模型今天再放到線上去，不一定能夠 work 的很好。

3.3 解決方案

在推薦系統(tǒng)中新增兩個部分：近線訓(xùn)練和近線樣本生成。

假設(shè)有用戶 1 和用戶 2 分別是上海和北京的用戶，這個時候會發(fā)現(xiàn)之前的模型不知道上海和北京的用戶是有區(qū)別的，它認(rèn)為都是中國男性用戶。而在加入實時訓(xùn)練這個模型后，就會逐漸的學(xué)習(xí)北京的用戶和上海的用戶，兩者的行為是有區(qū)別的，確認(rèn)這一點后再進(jìn)行推薦就會有不一樣的效果。

再比如說，今天北京突然下暴雨了或者上海天氣特別熱，這個時候都會導(dǎo)致兩邊用戶的行為不太一樣。這時再有一個用戶 4 過來，模型就會分辨這個用戶是上海還是北京的用戶。如果他是上海的用戶，可能就會推薦上海用戶所對應(yīng)的內(nèi)容；如果不是的話，可以繼續(xù)推薦別的。

加入實時模型訓(xùn)練，最主要的目的是在動態(tài)特征的基礎(chǔ)上，希望模型本身能夠盡可能的貼合此時此刻用戶行為的分布，同時希望能夠緩解模型的退化。

二、 阿里巴巴實時推薦方案

首先了解下阿里內(nèi)部實施完這套方案之后有什么好處：

第一個是時效性。目前阿里大促開始常態(tài)化，在大促期間整個模型的時效性得到了很好的提升；
第二個是靈活性?？梢愿鶕?jù)需求隨時調(diào)整特征和模型；
第三個是可靠性。大家在使用整個實時推薦系統(tǒng)的時候會覺得不放心，沒有經(jīng)過離線當(dāng)天晚上大規(guī)模的計算驗證，直接推上線，會覺得不夠可靠，其實已經(jīng)有一套完整的流程去保證這件事情的穩(wěn)定性和可靠性；

這個推薦模型從圖上看，從特征到樣本到模型，再到在線預(yù)測這個過程，和離線其實沒有區(qū)別。主要的區(qū)別就是整個的流程實時化，用這套實時化的流程去服務(wù)在線的搜索推廣應(yīng)用。

1. 如何實施

根據(jù)經(jīng)典離線架構(gòu)進(jìn)行演變。

首先，用戶群行為會從消息隊列來走離線存儲，然后這個離線存儲會存儲所有的歷史用戶行為；然后在這個離線存儲上面，通過靜態(tài)特征計算樣本；接下來把樣本存到樣本存儲里，去做離線模型訓(xùn)練；之后把離線的這個模型發(fā)布到模型中心，去做模型驗證；最后把模型驗證過的模型推到推理服務(wù)去服務(wù)在線業(yè)務(wù)。這個就是完整的離線體系。

我們將通過三件事情進(jìn)行實時化改造：

第一是特征計算；
第二是樣本生成；
第三是模型訓(xùn)練。

相比之前，消息隊列不僅僅存入離線存儲，還要分出來兩鏈路：

第一鏈路會做實時的特征計算，比如說最近幾分鐘之內(nèi)中國男性用戶看 page#100 的時候點了什么廣告，這個是實時計算算出來的，即最近一段時間的一些用戶可能產(chǎn)生的一些行為特征等。
另外一條鏈路是消息隊列，可以進(jìn)行實時樣本拼接，就是說不需要手動去打標(biāo)簽，因為用戶自己會告訴我們標(biāo)簽。比如我們做了一個推薦，如果用戶點擊了，那么它一定是個正樣本；如果過了一段時間用戶沒有點擊，那我們認(rèn)為它就是個負(fù)樣本。所以不用人工去打標(biāo)簽，用戶會幫我們打標(biāo)簽，這個時候很容易就能夠得到樣本，然后這部分樣本會放到樣本存儲里面去，這個跟之前是一樣的。區(qū)別在于這個樣本存儲不僅服務(wù)離線的模型訓(xùn)練，還會去做實時的模型訓(xùn)練。
離線模型訓(xùn)練通常還是天級的 T+1 的，會訓(xùn)練出一個 base model ，交給實時模型訓(xùn)練去做增量的訓(xùn)練。增量模型訓(xùn)練的模型產(chǎn)出就可能是 10 分鐘、15 分鐘這樣的級別，然后會送到模型存儲做模型驗證，最后上線。

架構(gòu)圖中綠色的部分都是實時的，這部分有一些是新加出來的，有一些則是由原本的離線變成實時的。

2. 阿里云企業(yè)級實時推薦解決方案

在阿里云企業(yè)級實時推薦解決方案中，如何使用阿里云產(chǎn)品搭建？

消息隊列會用 DataHub；實時的特征和樣本使用實時計算 Flink 版；離線的特征存儲和靜態(tài)特征計算都會用 MaxCompute；特征存儲和樣本中心使用 MaxCompute 交互式分析（Hologres）；消息隊列的部分都是 DataHub；模型訓(xùn)練的部分會用到 PAI，模型存儲和驗證，還有在線推理服務(wù)這一套流程都是 PAI 里面的。

2.1 實時特征計算及推理

特征和推理就是把用戶日志實時采集過來，導(dǎo)入實時計算 Flink 版里面去做實時特征計算。然后會送到 Hologres 里面去，利用 Hologres 流式的能力，拿它做特征中心。在這里，PAI 可以去直接查詢 Hologres 里面的這些用戶特征，也就是點查的能力。

在實時計算 Flink 版計算特征的時候，比如說用戶最近 5 分鐘的瀏覽記錄，包括商品、文章、視頻等，根據(jù)不同的業(yè)務(wù)屬性，實時特征是不一樣的。也可能包括比如最近 10 分鐘每個品類點擊率最高的 50 個商品，最近 30 分鐘瀏覽量最高的文章、視頻、商品，最近 30 分鐘搜索量最高的是 100 個詞等。在這不同的場景，比如搜索推薦，有廣告、有視頻、有文本、有新聞等。這些數(shù)據(jù)拿來做實時特征計算的和推理的這一條鏈路，然后在這個鏈路基礎(chǔ)之上，有的時候也是需要靜態(tài)特征回填的。

2.2 靜態(tài)特征回填

比如新上線一個特征，這個新的特征在實時鏈路上線了之后，如果需要最近 30 天用戶的行為，不可能等 30 天之后再計算。于是需要找到離線數(shù)據(jù)，然后把最近 30 天的這個特征給它補(bǔ)上。這就叫特征回填，也就是 backfill 。通過 MaxCompute 去算這個特征回填一樣也是寫到 Hologres，同時實施起來也會把新的特征給加上，這是一個新特征的場景。

當(dāng)然還有一些其他場景，比如算一些靜態(tài)特征；再比如可能線上特征有一個 bug 算錯了，但是數(shù)據(jù)已經(jīng)落到離線去了，這時候?qū)﹄x線特征要做一個糾錯，也會用到 backfill 的過程。

2.3 實時樣本拼接

實時樣本拼接本質(zhì)上對于推薦場景來講，就是展示點擊流之后，樣本獲得一個正樣本或者負(fù)樣本。但是這個 label 顯然是不夠的，還需要有特征，才能夠做訓(xùn)練。特征可以從 DataHub 中來，在加入了實時特征以后，樣本的特征是時時刻刻在發(fā)生變化的。

舉一個例子，做出某一個商品的推薦行為的時候，是早上 10:00，用戶的實時特征是他 9:55 到 10:00 的瀏覽記錄。但是當(dāng)看到這個樣本流回來的時候，有可能是 10:15 的時候了。如果說這個樣本是一個正樣本，當(dāng)給到用戶推薦的商品且他產(chǎn)生了購買行為，這段時間我們是無法看到用戶實時特征的。

因為那個時候的特征已經(jīng)變成了用戶從 10:10 瀏覽到 10:15 的時候的瀏覽記錄了。但是在做預(yù)測的時候，并不是根據(jù)這個 5 分鐘內(nèi)的瀏覽記錄來推薦的這個商品，所以需要把當(dāng)時做推薦的時候所采用的那些特征給它保存下來，在這個樣本生成的時候給它加上，這就是 DataHub 在這里的作用。

當(dāng)使用 ES 做實時推薦的時候，需要把當(dāng)時用來做推薦的這些特征保存下來，拿去做這個樣本的生成。樣本生成后，可以存儲到 Hologres 和 MaxCompute 里面去，把實時樣本存儲到 DataHub 里面。

2.4 實時深度學(xué)習(xí)和 Flink AI Flow

這個部分會有離線訓(xùn)練是以 “天“ 為級別的；也會有在線的實時訓(xùn)練是 “分鐘級” 的；有的可以做的比較極致，是按 “秒” 級的。不管是哪邊出來的模型，最后都會送到這個模型中去，進(jìn)行模型的驗證以及上線。

這個其實是一個非常復(fù)雜的工作流。首先，靜態(tài)特征計算是周期性的，也可能是手動的。當(dāng)需要做 backfill 的時候，有手動觸發(fā)的一個過程。根據(jù)這個模型圖能看出它是批的訓(xùn)練，當(dāng)它訓(xùn)練完了之后，需要到線上去做一個實時模型驗證。這個模型驗證可能是一個流作業(yè)，所以這里是從批到流的一個觸發(fā)過程，模型是從流作業(yè)里面出來的，它是一個 long running 的作業(yè)，每 5 分鐘產(chǎn)生一個模型，這每 5 分鐘的模型也需要送進(jìn)去做這個模型驗證，所以這是一個流觸發(fā)流動作的過程。

再比如說這個實時樣本拼接，大家都知道 Flink 有一個 watermark 的概念，比如說到某一個時刻往前的數(shù)據(jù)都到收集齊了，可以去觸發(fā)一個批的訓(xùn)練，這個時候就會存在一個流作業(yè)。當(dāng)他到了某一個時刻，需要去觸發(fā)批訓(xùn)練的時候，這個工作流在傳統(tǒng)的工作流調(diào)度里面是做不到的，因為傳統(tǒng)的工作流調(diào)度是基于一個叫做 job status change 的過程來做的，也就是作業(yè)狀態(tài)發(fā)生變化。

假設(shè)說如果一個作業(yè)跑完了并且沒有出錯，那么這個作業(yè)所產(chǎn)生的數(shù)據(jù)就已經(jīng) ready 了，下游對這些數(shù)據(jù)有依賴的作業(yè)就可以跑了。所以簡單來說，一個作業(yè)跑完了下一個作業(yè)延續(xù)上繼續(xù)跑，但是當(dāng)整個工作流里面只要有一個流作業(yè)的存在，那么這整個工作流就跑不了了，因為流作業(yè)是跑不完的。

比如說這個例子的實時計算，數(shù)據(jù)是不斷變化的跑動，但是也會存在隨時可能 ready 的，也就是說可能跑到某一個程度的時候數(shù)據(jù)就 ready 了，但其實作業(yè)根本沒有跑完。所以需要引入一個工作流，這個工作流我們把它叫做 Flink AI Flow，去解決剛才那個圖里面各個作業(yè)之間的協(xié)同關(guān)系這個問題。

Flink AI Flow 本質(zhì)上是說節(jié)點都是一個 logical 的 processing unit，是一個邏輯處理節(jié)點，節(jié)點和節(jié)點之間，不再是上一個作業(yè)跑完跑下一個作業(yè)的關(guān)系了，而是一個 event driven 的 conditions，是一個事件觸發(fā)的一個概念。

同樣在工作流執(zhí)行層面，調(diào)度器也不再基于作業(yè)狀態(tài)發(fā)生變化去做調(diào)度動作，而是基于事件的調(diào)度。比方說事件調(diào)度這個例子，當(dāng)一個流作業(yè)的 water mark 到了的時候，就是說這個時間點之前的所有數(shù)據(jù)都到全了，可以去觸發(fā)批作業(yè)去跑，并不需要流作業(yè)跑完。

對于每一個作業(yè)來講，通過調(diào)度器提作業(yè)或者停作業(yè)是需要條件的。當(dāng)這些事件滿足一個條件的時候，才會進(jìn)行調(diào)度動作。比如說有一個模型，當(dāng)模型生成的時候，會滿足一個條件，要求調(diào)度器把一個 validation 的作業(yè)模型驗證的作業(yè)給拉起來，那這個就是由一個 event 產(chǎn)生了一個 condition，要求 schedule 去做一件事情的過程。

除此之外，F(xiàn)link AI Flow 除了調(diào)度的服務(wù)之外，還提供了三個額外的支持服務(wù)來滿足整個 AI 工作流語義，分別是元數(shù)據(jù)服務(wù)、通知服務(wù)和模型中心。

元數(shù)據(jù)服，是幫大家管理數(shù)據(jù)集和整個工作流里面的一些狀態(tài)；
通知服務(wù)，是為了滿足基于事件調(diào)度語義；
模型中心，是去管理這個模型當(dāng)中的一些生命周期。

三、實時深度學(xué)習(xí)訓(xùn)練 PAI-ODL

Flink 生成實時樣本之后，在 ODL 系統(tǒng)有兩個流。

第一個流是實時流，生成的實時樣本送到 stream data source 上面比如像 kafka，在 kafka 中的這個樣本會有兩個流向，一個是流到 online training 中，另一個是流到 online evaluation 。
第二個流是離線訓(xùn)練的數(shù)據(jù)流，拿離線的數(shù)據(jù)流向數(shù)倉來做這種 offline T+1 的 training 。
在 online training 中支持用戶可配置生成模型的頻率，比如說用戶配置 30 秒或者 1 分鐘生成一次模型更新到線上。這個滿足在實時推薦場景中，特別是時效性要求高的場景。

ODL 支持用戶設(shè)定一些指標(biāo)來自動判斷生成的模型是否部署線上，當(dāng) evaluation 這邊達(dá)到這些指標(biāo)要求之后，這個模型會自動推上線。因為模型生成的頻率非常高，通過人工去干預(yù)不太現(xiàn)實。所以需要用戶來設(shè)定指標(biāo)，系統(tǒng)自動去判斷當(dāng)指標(biāo)達(dá)到要求，模型自動回推到線上。

離線流這邊有一條線叫 model calibration，也就是模型的校正。離線訓(xùn)練生成 T+1 的模型會對在線訓(xùn)練進(jìn)行模型的校正。

PAI-ODL 技術(shù)點分析

1. 超大稀疏模型訓(xùn)練

超大稀疏模型的訓(xùn)練，是推薦搜索廣告這類稀疏場景里常用的一個功能。這里實際上是一個典型、傳統(tǒng)的深度學(xué)習(xí)引擎，比如像 TensorFlow，它原生的內(nèi)部實現(xiàn)的就是 fix size 這種固定 size variable，在稀疏場景使用中會有一些常見問題。

就像 static shape，比如在通常的場景里邊，像手機(jī) APP 這種，每天都會有新用戶來加入，每天也會有新的商品，新聞和新的視頻等更新。如果是一個固定大小的 shape 的話，其實是無法表達(dá)稀疏場景中這種變化的語義的。而且這個 static shape 會限制模型本身長期的增量訓(xùn)練。如果說一個模型可增量訓(xùn)練時長是一兩年，那很可能之前設(shè)定的這個大小已經(jīng)遠(yuǎn)遠(yuǎn)不能滿足業(yè)務(wù)需求，有可能帶來嚴(yán)重的特征沖突，影響模型的效果。

如果在實際的模型中設(shè)置的 static shape 比較大，但是利用率很低，就會造成內(nèi)存的浪費，還有一些無效的 IO。包括生成全量模型的時候，造成磁盤的浪費。

在 PAI-ODL 中基于 PAI-TF 引擎，PAI-TF 提供了 embedding variable 功能。這個功能提供動態(tài)的彈性特征的能力。每個新的特征會新增加一個 slot。并支持特征淘汰，比如說下架一個商品，對應(yīng)的特征就會被刪掉。

增量模型是說可以把一分鐘內(nèi)稀疏特征變化的部分記錄下來，產(chǎn)生到這個增量模型中。增量模型記錄了稀疏的變化的特征和全量 Dense 的參數(shù)。

基于增量模型的導(dǎo)出，就可以實現(xiàn) ODL 場景下模型的快速更新。快速更新的增量模型是非常小的，可以做到頻繁的模型上線。

2. 支持秒級的模型熱更新

通常在我們接觸的用戶中，通常是關(guān)注的主要是三點：

第一點就是模型的效果，我上線之后效果好不好？
第二點就是成本，我到底花多少錢。
第三點就是性能，能不能達(dá)到我對RT的要求。
embedding store 多級的混合存儲支持用戶可配置不同的存儲方式?？梢栽跐M足用戶性能的前提下，更大程度的降低用戶的成本。

embedding 場景是非常有自己場景特點的，比如說我們的特征存在很明顯的冷熱區(qū)別。有些商品或者視頻本身特別熱；有些則是用戶的點擊行為特別多，也會造成它特別熱。有些冷門的商品或者視頻就沒人點，這是很明顯的冷熱分離，也是符合這種二八原則的。

EmbeddingStore 會把這些熱的特征存儲到 DRAM 上面，然后冷的特征存放在 PMEM 或者是 SSD 上。

3. 超大稀疏模型預(yù)測

此外，EmbeddingStore 支持分布式存儲 Service。在 serving 的時候，每個 serving 的節(jié)點其實都需要去做一個全量的模型的加載。如果使用 EmbeddingStore 的分布式 service，就可以避免每個 serving 節(jié)點加載全量模型。

EmbeddingStore 支持用戶可配置這種分布式的 embedding， 獨立的 isolated 這種 embedding store service。每個 serving 節(jié)點查詢稀疏特征時從 EmbeddingStore Service 查詢。

EmbeddingStore 的設(shè)計充分的考慮了稀疏特征的數(shù)據(jù)格式和訪問特點。舉個簡單的例子：稀疏特征的 key 和 value ，key 是 int64 ， value 就是一個 float 數(shù)組。無論是在 serving 還是在 training，訪問都是大批量的訪問。此外 Inference 階段對稀疏特征的訪問是無鎖化的只讀訪問。這些都是促使我們設(shè)計基于 embedding 場景的稀疏特征存儲的原因。

4. 實時訓(xùn)練模型校正

為什么 PAI-ODL 會支持離線訓(xùn)練模型對 online training 有一個模型校正？

通常在實時訓(xùn)練過程中，會存在這種 label 不準(zhǔn)以及樣本分布的問題。因此使用天級別的模型會自動校正到 online training，增強(qiáng)模型的穩(wěn)定性。PAI-ODL 提供的模型校正用戶是無干預(yù)的，用戶基于自己業(yè)務(wù)特點配置相關(guān)配置后，每天自動根據(jù)新產(chǎn)生的全量模型進(jìn)行 online training 端的 base 模型校正。當(dāng)離線訓(xùn)練生成 base 模型，online training 會自動發(fā)現(xiàn) base model，并且在 data stream source 會自動跳轉(zhuǎn)到對應(yīng)的樣本，基于最新的 base 模型和新的 online training 的訓(xùn)練樣本點開始 online training。

5. 模型回退及樣本回放

雖然有樣本的異常樣本檢測以及異常樣本處理，仍然無法避免線上的更新模型會有效果問題。

當(dāng)用戶收到報警，線上的指標(biāo)下降。需要提供給用戶一個能力，可以回滾這個模型。

但是在 online training 的場景中，從發(fā)現(xiàn)問題到去干預(yù)可能經(jīng)過了好幾個模型的迭代，產(chǎn)出了若干模型了。此時的回滾包含：

1）線上 serving 的模型回滾到問題時間點的前一個模型；

2）同時 online training 需要回跳到問題模型的前一個模型；

3）樣本也要回跳到那個時間點來重新開始進(jìn)行訓(xùn)練。