在過去十年，機(jī)器學(xué)習(xí)在學(xué)術(shù)界取得了眾多的突破，在工業(yè)界也有很多應(yīng)用落地。美團(tuán)很早就開始探索不同的機(jī)器學(xué)習(xí)模型在搜索場景下的應(yīng)用，從最開始的線性模型、樹模型，再到近兩年的深度神經(jīng)網(wǎng)絡(luò)、BERT、DQN等，并在實踐中也取得了良好的效果與產(chǎn)出。

在美團(tuán)搜索AI化的過程中，比較核心的兩個組件是模型訓(xùn)練平臺Poker和在線預(yù)估框架Augur。本文主要與大家探討Augur的設(shè)計思路、效果，以及它的優(yōu)勢與不足，最后也簡單介紹了一下Poker平臺的價值。希望這些內(nèi)容對大家有所幫助或者啟發(fā)。

1. 背景

搜索優(yōu)化問題，是個典型的AI應(yīng)用問題，而AI應(yīng)用問題首先是個系統(tǒng)問題。經(jīng)歷近10年的技術(shù)積累和沉淀，美團(tuán)搜索系統(tǒng)架構(gòu)從傳統(tǒng)檢索引擎升級轉(zhuǎn)變?yōu)锳I搜索引擎。當(dāng)前，美團(tuán)搜索整體架構(gòu)主要由搜索數(shù)據(jù)平臺、在線檢索框架及云搜平臺、在線AI服務(wù)及實驗平臺三大體系構(gòu)成。

在AI服務(wù)及實驗平臺中，模型訓(xùn)練平臺Poker和在線預(yù)估框架Augur是搜索AI化的核心組件，解決了模型從離線訓(xùn)練到在線服務(wù)的一系列系統(tǒng)問題，極大地提升了整個搜索策略迭代效率、在線模型預(yù)估的性能以及排序穩(wěn)定性，并助力商戶、外賣、內(nèi)容等核心搜索場景業(yè)務(wù)指標(biāo)的飛速提升。

首先，讓我們看看在美團(tuán)App內(nèi)的一次完整的搜索行為主要涉及哪些技術(shù)模塊。如下圖所示，從點(diǎn)擊輸入框到最終的結(jié)果展示，從熱門推薦，到動態(tài)補(bǔ)全、最終的商戶列表展示、推薦理由的展示等，每一個模塊都要經(jīng)過若干層的模型處理或者規(guī)則干預(yù)，才會將最適合用戶（指標(biāo)）的結(jié)果展示在大家的眼前。

為了保證良好的用戶體驗，技術(shù)團(tuán)隊對模型預(yù)估能力的要求變得越來越高，同時模型與特征的類型、數(shù)量及復(fù)雜度也在與日俱增。算法團(tuán)隊如何盡量少地開發(fā)和部署上線，如何快速進(jìn)行模型特征的迭代？如何確保良好的預(yù)估性能？在線預(yù)估框架Augur應(yīng)運(yùn)而生。

經(jīng)過一段時間的實踐，Augur也有效地滿足了算法側(cè)的需求，并成為美團(tuán)搜索與NLP部通用的解決方案。下面，我們將從解讀概念開始，然后再分享一下在實施過程中我們團(tuán)隊的一些經(jīng)驗和思考。

2. 抽象過程：什么是模型預(yù)估？

其實，模型預(yù)估的邏輯相對簡單、清晰。但是如果要整個平臺做得好用且高效，這就需要框架系統(tǒng)和工具建設(shè)（一般是管理平臺）兩個層面的配合，需要兼顧需求、效率與性能。

那么，什么是模型預(yù)估呢？如果忽略掉各種算法的細(xì)節(jié)，我們可以認(rèn)為模型是一個函數(shù)，有一批輸入和輸出，我們提供將要預(yù)估文檔的相關(guān)信息輸入模型，并根據(jù)輸出的值（即模型預(yù)估的值）對原有的文檔進(jìn)行排序或者其他處理。

純粹從一個工程人員視角來看：模型可以簡化為一個公式（?舉例：f(x1,x2)= ax1 + bx2 +c?），訓(xùn)練模型是找出最合適的參數(shù)abc。所謂特征，是其中的自變量x1與x2，而模型預(yù)估，就是將給定的自變量x1與x2代入公式，求得一個解而已。（當(dāng)然實際模型輸出的結(jié)果可能會更加復(fù)雜，包括輸出矩陣、向量等等，這里只是簡單的舉例說明。）

所以在實際業(yè)務(wù)場景中，一個模型預(yù)估的過程可以分為兩個簡單的步驟：第一步，特征抽取（找出x1與x2）；第二步，模型預(yù)估（執(zhí)行公式 ?，獲得最終的結(jié)果）。

模型預(yù)估很簡單，從業(yè)務(wù)工程的視角來看，無論多復(fù)雜，它只是一個計算分?jǐn)?shù)的過程。對于整個運(yùn)算的優(yōu)化，無論是矩陣運(yùn)算，還是底層的GPU卡的加速，業(yè)界和美團(tuán)內(nèi)部都有比較好的實踐。美團(tuán)也提供了高性能的TF-Serving服務(wù)（參見《基于TensorFlow Serving的深度學(xué)習(xí)在線預(yù)估》一文）以及自研的MLX模型打分服務(wù)，都可以進(jìn)行高性能的Batch打分。基于此，我們針對不同的模型，采取不同的策略：

• 深度學(xué)習(xí)模型：特征多，計算復(fù)雜，性能要求高；我們將計算過程放到公司統(tǒng)一提供的TF-Serving/MLX預(yù)估服務(wù)上。

• 線性模型、樹模型：搜索場景下使用的特征相對較少，計算邏輯也相對簡單，我們將在構(gòu)建的預(yù)估框架內(nèi)部再構(gòu)建起高性能的本機(jī)求解邏輯，從而減少RPC。

這一套邏輯很簡單，構(gòu)建起來也不復(fù)雜，所以在建設(shè)初期，我們快速在主搜的核心業(yè)務(wù)邏輯中快速實現(xiàn)了這一架構(gòu)，如下圖所示。這樣的一個架構(gòu)使得我們可以在主搜的核心排序邏輯中，能夠使用各類線性模型的預(yù)估，同時也可以借助公司的技術(shù)能力，進(jìn)行深度模型的預(yù)估。關(guān)于特征抽取的部分，我們也簡單實現(xiàn)了一套規(guī)則，方便算法同學(xué)可以自行實現(xiàn)一些簡單的邏輯。

3. 預(yù)估框架思路的改變

3.1 老框架的局限

舊架構(gòu)中模型預(yù)估與業(yè)務(wù)邏輯耦合的方式，在預(yù)估文檔數(shù)和特征數(shù)量不大的時候可以提供較好的支持。

但是，從2018年開始，搜索業(yè)務(wù)瓶頸開始到來，點(diǎn)評事業(yè)部開始對整個搜索系統(tǒng)進(jìn)行升級改造，并打造基于知識圖譜的分層排序架構(gòu)（詳情可以參見點(diǎn)評搜索智能中心在2019年初推出的實踐文章《大眾點(diǎn)評搜索基于知識圖譜的深度學(xué)習(xí)排序?qū)嵺`》）。這也意味著：更多需要模型預(yù)估的文檔，更多的特征，更深層次的模型，更多的模型處理層級，以及更多的業(yè)務(wù)。

在這樣的需求背景下，老框架開始出現(xiàn)了一些局限性，主要包括以下三個層面：

• 性能瓶頸：核心層的模型預(yù)估的Size擴(kuò)展到數(shù)千級別文檔的時候，單機(jī)已經(jīng)難以承載；近百萬個特征值的傳輸開銷已經(jīng)難以承受。

• 復(fù)用困難：模型預(yù)估能力已經(jīng)成為一個通用的需求，單搜索就有幾十個場景都需要該能力；而老邏輯的業(yè)務(wù)耦合性讓復(fù)用變得更加困難。

• 平臺缺失：快速的業(yè)務(wù)迭代下，需要有一個平臺可以幫助業(yè)務(wù)快速地進(jìn)行模型和特征的管理，包括但不限于配置、上線、灰度、驗證等等。

3.2 新框架的邊界

跟所有新系統(tǒng)的誕生故事一樣，老系統(tǒng)一定會出現(xiàn)問題。原有架構(gòu)在少特征以及小模型下雖有優(yōu)勢，但業(yè)務(wù)耦合，無法橫向擴(kuò)展，也難以復(fù)用。針對需求和老框架的種種問題，我們開始構(gòu)建了新的高性能分布式模型預(yù)估框架Augur，該框架指導(dǎo)思路是：

• 業(yè)務(wù)解耦，設(shè)定框架邊界：只做特征抽取和模型預(yù)估，對預(yù)估結(jié)果的處理等業(yè)務(wù)邏輯交給上層處理。

• 無狀態(tài)，且可以做到分布式模型預(yù)估，無壓力支持?jǐn)?shù)千級別文檔數(shù)的深度模型預(yù)估。

架構(gòu)上的改變，讓Augur具備了復(fù)用的基礎(chǔ)能力，同時也擁有了分布式預(yù)估的能力?？上?#xff0c;系統(tǒng)架構(gòu)設(shè)計中沒有“銀彈”：雖然系統(tǒng)具有了良好的彈性，但為此我們也付出了一些代價，我們會在文末進(jìn)行解釋。

4. 預(yù)估平臺的構(gòu)建過程

框架思路只能解決“能用”的問題，平臺則是為了“通用”與“好用”。一個優(yōu)秀的預(yù)估平臺需要保證高性能，具備較為通用且接口豐富的核心預(yù)估框架，以及產(chǎn)品級別的業(yè)務(wù)管理系統(tǒng)。為了能夠真正地提升預(yù)估能力和業(yè)務(wù)迭代的效率，平臺需要回答以下幾個問題：

• 如何解決特征和模型的高效迭代？

• 如何解決批量預(yù)估的性能和資源問題？

• 如何實現(xiàn)能力的快速復(fù)用并能夠保障業(yè)務(wù)的安全？

下面，我們將逐一給出答案。

4.1 構(gòu)建預(yù)估內(nèi)核：高效的特征和模型迭代

4.1.1 Operator和Transformer

在搜索場景下，特征抽取較為難做的原因主要包括以下幾點(diǎn)：

• 來源多：商戶、商品、交易、用戶等數(shù)十個維度的數(shù)據(jù)，還有交叉維度。由于美團(tuán)業(yè)務(wù)眾多，難以通過統(tǒng)一的特征存儲去構(gòu)建，交易相關(guān)數(shù)據(jù)只能通過服務(wù)來獲取。

• 業(yè)務(wù)邏輯多：大多數(shù)據(jù)在不同的業(yè)務(wù)層會有復(fù)用，但是它們對特征的處理邏輯又有所不同。

• 模型差異：同一個特征，在不同的模型下，會有不同的處理邏輯。比如，一個連續(xù)型特征的分桶計算邏輯一樣，但“桶”卻因模型而各不相同；對于離散特征的低頻過濾也是如此。

• 迭代快：特征的快速迭代，要求特征有快速在線上生效的能力，如果想要改動一個判斷還需要寫代碼上線部署，無疑會拖慢了迭代的速度。模型如此，特征也是如此。

針對特征的處理邏輯，我們抽象出兩個概念：

Operator：通用特征處理邏輯，根據(jù)功能的不同又可以分為兩類：

• IO OP：用處理原始特征的獲取，如從KV里獲取數(shù)據(jù)，或者從對應(yīng)的第三方服務(wù)中獲取數(shù)據(jù)。內(nèi)置批量接口，可以實現(xiàn)批量召回，減少RPC。

• Calc OP：用于處理對獲取到的原始特征做與模型無關(guān)的邏輯處理，如拆分、判空、組合。業(yè)務(wù)可以結(jié)合需求實現(xiàn)特征處理邏輯。

通過IO、計算分離，特征抽取執(zhí)行階段就可以進(jìn)行IO異步、自動聚合RPC、并行計算的編排優(yōu)化，從而達(dá)到提升性能的目的。

Transformer：用于處理與模型相關(guān)的特征邏輯，如分桶、低頻過濾等等。一個特征可以配置一個或者多個Transformer。Transformer也提供接口，業(yè)務(wù)方可以根據(jù)自己的需求定制邏輯。

• 離在線統(tǒng)一邏輯：Transformer是特征處理的模型相關(guān)邏輯，因此我們將Transformer邏輯單獨(dú)抽包，在我們樣本生產(chǎn)的過程中使用，保證離線樣本生產(chǎn)與線上特征處理邏輯的一致性。

基于這兩個概念，Augur中特征的處理流程如下所示：首先，我們會進(jìn)行特征抽取 ，抽取完后，會對特征做一些通用的處理邏輯；而后，我們會根據(jù)模型的需求進(jìn)行二次變換，并將最終值輸入到模型預(yù)估服務(wù)中。如下圖所示：

4.1.2 特征計算DSL

有了Operator的概念，為了方便業(yè)務(wù)方進(jìn)行高效的特征迭代，Augur設(shè)計了一套弱類型、易讀的特征表達(dá)式語言，將特征看成一系列OP與其他特征的組合，并基于Bison&JFlex構(gòu)建了高性能語法和詞法解析引擎。我們在解釋執(zhí)行階段還做了一系列優(yōu)化，包括并行計算、中間特征共享、異步IO，以及自動RPC聚合等等。

舉個例子：

//?IO?Feature:?binaryBusinessTime;??ReadKV?是一個?IO?類型的?OP ReadKV('mtptpoionlinefeatureexp','_id',_id,'ba_search.platform_poi_business_hour_new.binarybusinesstime','STRING') //?FeatureA?:?CtxDateInfo;???ParseJSON?是一個?Calc?類型的?OP ParseJSON(_ctx['dateInfo']); //?FeatureB?:?isTodayWeekend?需要看?Json?這種的日期是否是周末,?便可以復(fù)用??CtxDateInfo??這個特征;?IsWeekend?也是是一個?Calc?類型的?OP IsWeekend(CtxDateInfo['date'])

在上面的例子中，ParseJSON與IsWeekend都是OP， CtxDateInfo與isTodayWeekend都是由其他特征以及OP組合而成的特征。通過這種方式，業(yè)務(wù)方根據(jù)自己的需求編寫OP , 可以快速復(fù)用已有的OP和特征，創(chuàng)造自己需要的新特征。而在真實的場景中，IO OP的數(shù)量相對固定。所以經(jīng)過一段時間的累計，OP的數(shù)量會趨于穩(wěn)定，新特征只需基于已有的OP和特征組合即可實現(xiàn)，非常的高效。

4.1.3 配置化的模型表達(dá)

特征可以用利用OP、使用表達(dá)式的方式去表現(xiàn)，但特征還可能需要經(jīng)過Transformer的變換。為此，我們同樣為模型構(gòu)建一套可解釋的JSON表達(dá)模板，模型中每一個特征可以通過一個JSON對象進(jìn)行配置，以一個輸入到TF模型里的特征結(jié)構(gòu)為例：

//?一個的特征的?JSON?配置 {"tf_input_config":?{"otherconfig"},"tf_input_name":?"modulestyle","name":?"moduleStyle","transforms":?[??????????????????????// Transfomers：模型相關(guān)的處理邏輯，可以有多個，Augur 會按照順序執(zhí)行{"name":?"BUCKETIZE", ????????????// Transfomer 的名稱：這里是分桶"params":?{"bins":?[0,1,2,3,4]???????????//?Transfomer?的參數(shù)}}],"default_value":?-1 }

通過以上配置，一個模型可以通過特征名和Transformer的組合清晰地表達(dá)。因此，模型與特征都只是一段純文本配置，可以保存在外部，Augur在需要的時候可以動態(tài)的加載，進(jìn)而實現(xiàn)模型和特征的上線配置化，無需編寫代碼進(jìn)行上線，安全且高效。

其中，我們將輸入模型的特征名（tf_input_name）和原始特征名（name）做了區(qū)分。這樣的話，就可以只在外部編寫一次表達(dá)式，注冊一個公用特征，卻能通過在模型的結(jié)構(gòu)體中配置不同Transfomer創(chuàng)造出多個不同的模型預(yù)估特征。這種做法相對節(jié)約資源，因為公用特征只需抽取計算一次即可。

此外，這一套配置文件也是離線樣本生產(chǎn)時使用的特征配置文件，結(jié)合統(tǒng)一的OP&Transformer代碼邏輯，進(jìn)一步保證了離線/在線處理的一致性，也簡化了上線的過程。因為只需要在離線狀態(tài)下配置一次樣本生成文件，即可在離線樣本生產(chǎn)、在線模型預(yù)估兩個場景通用。

4.2 完善預(yù)估系統(tǒng)：性能、接口與周邊設(shè)施

4.2.1 高效的模型預(yù)估過程

OP和Transformer構(gòu)建了框架處理特征的基本能力。實際開發(fā)中，為了實現(xiàn)高性能的預(yù)估能力，我們采用了分片純異步的線程結(jié)構(gòu)，層層Call Back，最大程度將線程資源留給實際計算。因此，預(yù)估服務(wù)對機(jī)器的要求并不高。

為了描述清楚整個過程，這里需要明確特征的兩種類型：

ContextLevel Feature：全局維度特征，一次模型預(yù)估請求中，此類特征是通用的。比如時間、地理位置、距離、用戶信息等等。這些信息只需計算一次。

DocLevel Feature：文檔維度特征，一次模型預(yù)估請求中每個文檔的特征不同，需要分別計算。

一個典型的模型預(yù)估請求，如下圖所示：

Augur啟動時會加載所有特征的表達(dá)式和模型，一個模型預(yù)估請求ModelScoreRequest會帶來對應(yīng)的模型名、要打分的文檔id（docid）以及一些必要的全局信息Context。Augur在請求命中模型之后，將模型所用特征構(gòu)建成一顆樹，并區(qū)分ContextLevel特征和DocLevel特征。由于DocLevel特征會依賴ContextLevel特征，故先將ContextLevel特征計算完畢。

對于Doc維度，由于對每一個Doc都要加載和計算對應(yīng)的特征，所以在Doc加載階段會對Doc列表進(jìn)行分片，并發(fā)完成特征的加載，并且各分片在完成特征加載之后就進(jìn)行打分階段。也就是說，打分階段本身也是分片并發(fā)進(jìn)行的，各分片在最后打分完成后匯總數(shù)據(jù)，返回給調(diào)用方。期間還會通過異步接口將特征日志上報，方便算法同學(xué)進(jìn)一步迭代。

在這個過程中，為了使整個流程異步非阻塞，我們要求引用的服務(wù)提供異步接口。若部分服務(wù)未提供異步接口，可以將其包裝成偽異步。這一套異步流程使得單機(jī)（16c16g）的服務(wù)容量提升超過100%，提高了資源的利用率。

4.2.2 預(yù)估的性能及表達(dá)式的開銷

框架的優(yōu)勢：得益于分布式，純異步流程，以及在特征OP內(nèi)部做的各類優(yōu)化（公用特征 、RPC聚合等），從老框架遷移到Augur后，上千份文檔的深度模型預(yù)估性能提升了一倍。

至于大家關(guān)心的表達(dá)式解析對對于性能的影響其實可以忽略。因為這個模型預(yù)估的耗時瓶頸主要在于原始特征的抽取性能（也就是特征存儲的性能）以及預(yù)估服務(wù)的性能（也就是Serving的性能）。而 Augur 提供了表達(dá)式解析的Benchmark測試用例，可以進(jìn)行解析性能的驗證。

_I(_I('xxx')) Benchmark??????????????Mode??Cnt??Score???Error??Units AbsBenchmarkTest.test??avgt???25??1.644?±?0.009??ms/op

一個兩層嵌套的表達(dá)式解析10W次的性能是1.6ms左右。相比于整個預(yù)估的時間，以及語言化表達(dá)式對于特征迭代效率的提升，這一耗時在當(dāng)前業(yè)務(wù)場景下，基本可以忽略不計。

4.2.3 系統(tǒng)的其他組成部分

一個完善可靠的預(yù)估系統(tǒng)，除了“看得見”的高性能預(yù)估能力，還需要做好以下幾個常被忽略的點(diǎn)：

• 特征日志處理流程：預(yù)估時產(chǎn)出的特征日志，需要通過框架上傳到公司日志中心或者以用戶希望的方式進(jìn)行存儲，方便模型的迭代。當(dāng)然，必要的時候可以落入本地，方便問題的定位。

• 監(jiān)控，系統(tǒng)&特征：系統(tǒng)監(jiān)控不用多說，美團(tuán)內(nèi)部的Cat&天網(wǎng)，可以構(gòu)建出完善的監(jiān)控體系。另一方面，特征的監(jiān)控也很重要，因為特征獲取的穩(wěn)定性決定了模型預(yù)估的質(zhì)量，所以我們構(gòu)建了實時的特征分布監(jiān)控系統(tǒng)，可以分鐘級發(fā)現(xiàn)特征分布的異常，最大限度上保證模型預(yù)估的可靠性。

• 豐富的接口：除了預(yù)估接口，還需要有特征抽取接口、模型打分Debug 接口、特征表達(dá)式測試接口、模型單獨(dú)測試接口、特征模型刷新接口、特征依賴檢等等一系列接口，這樣才可以保證整個系統(tǒng)的可用性，并為后面管理平臺的建設(shè)打下基礎(chǔ)。

Augur在完成了以上多種能力的建設(shè)之后，就可以當(dāng)做一個功能相對完善且易擴(kuò)展的在線預(yù)估系統(tǒng)。由于我們在構(gòu)建 Augur的時候，設(shè)立了明確的邊界，故以上能力是獨(dú)立于業(yè)務(wù)的，可以方便地進(jìn)行復(fù)用。當(dāng)然，Augur的功能管理，更多的業(yè)務(wù)接入，都需要管理平臺的承載。于是，我們就構(gòu)建了Poker平臺，其中的在線預(yù)估管理模塊是服務(wù)于Augur，可以進(jìn)行模型特征以及業(yè)務(wù)配置的高效管理。我們將在下一小節(jié)進(jìn)行介紹。

4.3 建設(shè)預(yù)估平臺：快速復(fù)用與高效管理

4.3.1 能力的快速復(fù)用

Augur在設(shè)計之初，就將所有業(yè)務(wù)邏輯通過OP和Transformer承載，所以跟業(yè)務(wù)無關(guān)?？紤]到美團(tuán)搜索與NLP部模型預(yù)估場景需求的多樣性，我們還為Augur賦予多種業(yè)務(wù)調(diào)用的方式。

• Java服務(wù)化調(diào)用：即基于Augur構(gòu)建一個完整的Service，可以實現(xiàn)無狀態(tài)分布式的彈性預(yù)估能力。

• Thrift調(diào)用：Java服務(wù)化版本中內(nèi)置了對Thrift 的支持，使不同語言的業(yè)務(wù)都可以方便地?fù)碛心Ｐ皖A(yù)估能力。

• 雙框架：Augur支持同一個服務(wù)同時提供Pigeon（美團(tuán)內(nèi)部的RPC框架）以及Thrift 服務(wù)，從而滿足不同業(yè)務(wù)的不同需求。

• Java SDK：Augur同樣支持以SDK的方式將能力嵌入到已有的集群當(dāng)中。但如此一來，分布式能力就無法發(fā)揮了。所以，我們一般應(yīng)用在性能要求高、模型比較小、特征基本可以存在本地的場景下。

其中服務(wù)化是被應(yīng)用最多的方式，為了方便業(yè)務(wù)方的使用，除了完善的文檔外，我們還構(gòu)建了標(biāo)準(zhǔn)的服務(wù)模板，任何一個業(yè)務(wù)方基本上都可以在30分鐘內(nèi)構(gòu)建出自己的Augur服務(wù)。服務(wù)模板內(nèi)置了60多個常用邏輯和計算OP , 并提供了最佳實踐文檔與配置邏輯，使得業(yè)務(wù)方在沒有指導(dǎo)的情況下可以自行解決95%以上的問題。整個流程如下圖所示：

當(dāng)然，無論使用哪一種方式去構(gòu)建預(yù)估服務(wù)，都可以在美團(tuán)內(nèi)部的Poker平臺上進(jìn)行服務(wù)、模型與特征的管理。

4.3.2 Augur管理平臺Poker的構(gòu)建

實現(xiàn)一個框架價值的最大化，需要一個完整的體系去支撐。而一個合格的在線預(yù)估平臺，需要一個產(chǎn)品級別的管理平臺輔助。于是我們構(gòu)建了Poker（搜索實驗平臺），其中的在線預(yù)估服務(wù)管理模塊，也是Augur的最佳拍檔。Augur是一個可用性較高的在線預(yù)估框架，而Poker+Augur則構(gòu)成了一個好用的在線預(yù)估平臺。下圖是在線預(yù)估服務(wù)管理平臺的功能架構(gòu)：

首先是預(yù)估核心特征的管理，上面說到我們構(gòu)建了語言化的特征表達(dá)式，這其實是個較為常見的思路。Poker利用Augur提供的豐富接口，結(jié)合算法的使用習(xí)慣，構(gòu)建了一套較為流暢的特征管理工具?？梢栽谄脚_上完成新增、測試、上線、卸載、歷史回滾等一系列操作。同時，還可以查詢特征被服務(wù)中的哪些模型直接或者間接引用，在修改和操作時還有風(fēng)險提示，兼顧了便捷性與安全性。

模型管理也是一樣，我們在平臺上實現(xiàn)了模型的配置化上線、卸載、上線前的驗證、灰度、獨(dú)立的打分測試、Debug信息的返回等等。同時支持在平臺上直接修改模型配置文件，平臺可以實現(xiàn)模型多版本控制，一鍵回滾等。配置皆為實時生效，避免了手動上線遇到問題后因處理時間過長而導(dǎo)致?lián)p失的情況。

4.3.3 Poker + Augur的應(yīng)用與效果

隨著Augur和Poker的成熟，美團(tuán)搜索與NLP部門內(nèi)部已經(jīng)有超過30個業(yè)務(wù)方已經(jīng)全面接入了預(yù)估平臺，整體的概況如下圖所示：

預(yù)估框架使用遷移Augur后，性能和模型預(yù)估穩(wěn)定性上均獲得了較大幅度的提升。更加重要的是，Poker平臺的在線預(yù)估服務(wù)管理和Augur預(yù)估框架，還將算法同學(xué)從繁復(fù)且危險的上線操作中解放出來，更加專注于算法迭代，從而取得更好的效果。以點(diǎn)評搜索為例，在Poker+Augur穩(wěn)定上線之后，經(jīng)過短短半年的時間，點(diǎn)評搜索核心KPI在高位基礎(chǔ)上仍然實現(xiàn)了大幅提升，是過去一年半漲幅的六倍之多，提前半年完成全年的目標(biāo)。

4.4 進(jìn)階預(yù)估操作：模型也是特征

4.4.1 Model as a Feature，同構(gòu)or異構(gòu)？

在算法的迭代中，有時會將一個模型的預(yù)估的結(jié)果當(dāng)做另外一個模型輸入特征，進(jìn)而取得更好的效果。如美團(tuán)搜索與NLP中心的算法同學(xué)使用BERT來解決長尾請求商戶的展示順序問題，此時需要BERT as a Feature。一般的做法是離線進(jìn)行BERT批量計算，灌入特征存儲供線上使用。但這種方式存在時效性較低（T+1）、覆蓋度差等缺點(diǎn)。最好的方式自然是可以在線實時去做BERT模型預(yù)估，并將預(yù)估輸出值作為特征，用于最終的模型打分。這就需要Augur提供Model as a Feature的能力。

得益于Augur抽象的流程框架，我們很快超額完成了任務(wù)。Model as a feature，雖然要對一個Model做預(yù)估操作，但從更上層的模型角度看，它就是一個特征。既然是特征，模型預(yù)估也就是一個計算OP而已。所以我們只需要在內(nèi)部實現(xiàn)一個特殊的OP，ModelFeatureOpreator就可以干凈地解決這些問題了。

我們在充分調(diào)研后，發(fā)現(xiàn)Model as a Feature有兩個維度的需求：同構(gòu)的特征和異構(gòu)的特征。同構(gòu)指的是這個模型特征與模型的其他特征一樣，是與要預(yù)估的文檔統(tǒng)一維度的特征，那這個模型就可以配置在同一個服務(wù)下，也就是本機(jī)可以加載這個Stacking模型；而異構(gòu)指的是Model Feature與當(dāng)前預(yù)估的文檔不是統(tǒng)一維度的，比如商戶下掛的商品，商戶打分需要用到商品打分的結(jié)果，這兩個模型非統(tǒng)一維度，屬于兩個業(yè)務(wù)。正常邏輯下需要串行處理，但是Augur可以做得更高效。為此我們設(shè)計了兩個OP來解決問題：

• LocalModelFeature：解決同構(gòu)Model Feature的需求，用戶只需像配置普通特征表達(dá)式一樣即可實現(xiàn)在線的Model Stacking；當(dāng)然，內(nèi)部自然有優(yōu)化邏輯，比如外部模型和特征模型所需的特征做統(tǒng)一整合，盡可能的減少資源消耗，提升性能。該特征所配置的模型特征，將在本機(jī)執(zhí)行，以減少RPC。

• RemoteModelFeature：解決異構(gòu)Model Feature的需求，用戶還是只需配置一個表達(dá)式，但是此表達(dá)式會去調(diào)用相應(yīng)維度的Augur服務(wù)，獲取相應(yīng)的模型和特征數(shù)據(jù)供主維度的Augur服務(wù)處理。雖然多了一層 RPC，但是相對于純線性的處理流程，分片異步后，還是有不少的性能提升。

美團(tuán)搜索內(nèi)部，已經(jīng)通過LocalModelFeature的方式，實現(xiàn)了BERT as a Feature。在幾乎沒有新的使用學(xué)習(xí)成本的前提下，同時在線上取得了明顯的指標(biāo)提升。

4.4.2 Online Model Ensemble

Augur支持有單獨(dú)抽取特征的接口，結(jié)合Model as a Feature，若需要同時為一個文檔進(jìn)行兩個或者多個模型的打分，再將分?jǐn)?shù)做加權(quán)后使用，非常方便地實現(xiàn)離線Ensemble出來模型的實時在線預(yù)估。我們可以配置一個簡單的LR、Empty 類型模型（僅用于特征抽取），或者其他任何Augur支持的模型，再通過LocalModelFeature配置若干的Model Feature，就可以通過特征抽取接口得到一個文檔多個模型的線性加權(quán)分?jǐn)?shù)了。而這一切都被包含在一個統(tǒng)一的抽象邏輯中，使用戶的體驗是連續(xù)統(tǒng)一的，幾乎沒有增加學(xué)習(xí)成本。

除了上面的操作外，Augur還提供了打分的同時帶回部分特征的接口，供后續(xù)的業(yè)務(wù)規(guī)則處理使用。

5. 更多思考

當(dāng)然，肯定沒有完美的框架和平臺。Augur和Poker還有很大的進(jìn)步空間，也有一些不可回避的問題。主要包括以下幾個方面。

被迫“消失”的Listwise特征

前面說到，系統(tǒng)架構(gòu)設(shè)計中沒有“銀彈”。在采用了無狀態(tài)分布式的設(shè)計后，請求會分片。所以ListWise類型的特征就必須在打分前算好，再通過接口傳遞給Augur使用。在權(quán)衡性能和效果之后，算法同學(xué)放棄了這一類型的特征。

當(dāng)然，不是說Augur不能實現(xiàn)，只是成本有些高，所以暫時Hold 。我們也有設(shè)計過方案，在可量化的收益高于成本的時候，我們會在Augur中開放協(xié)作的接口。

單機(jī)多層打分的缺失

Augur一次可以進(jìn)行多個模型的打分，模型相互依賴（下一層模型用到上一層模型的結(jié)果）也可以通過Stacking技術(shù)來解決。但如果模型相互依賴又逐層減少預(yù)估文檔（比如，第一輪預(yù)估1000個，第二輪預(yù)估500），則只能通過多次RPC的方式去解決問題，這是一個現(xiàn)實問題的權(quán)衡。分片打分的性能提升，能否Cover多次RPC的開銷？在實際開發(fā)中，為了保持框架的清晰簡單，我們選擇了放棄多層打分的特性。

離線能力缺失？

Poker是搜索實驗平臺的名字。我們設(shè)計它的初衷，是解決搜索模型實驗中，從離線到在線所有繁復(fù)的手工操作，使搜索擁有一鍵訓(xùn)練、一鍵Fork、一鍵上線的能力。與公司其他的訓(xùn)練平臺不同，我們通過完善的在線預(yù)估框架倒推離線訓(xùn)練的需求，進(jìn)而構(gòu)建了與在線無縫結(jié)合的搜索實驗平臺，極大地提升了算法同學(xué)的工作效。

未來，我們也會向大家介紹產(chǎn)品級別的一站式搜索實驗平臺，敬請期待。

6. 未來展望

在統(tǒng)一了搜索的在線預(yù)估框架后，我們會進(jìn)一步對Augur的性能&能力進(jìn)行擴(kuò)展。未來，我們將會在檢索粗排以及性能要求更高的預(yù)估場景中去發(fā)揮它的能力與價值。同時 ，我們正在將在線預(yù)估框架進(jìn)一步融合到我們的搜索實驗平臺Poker中，與離線訓(xùn)練和AB實驗平臺做了深度的打通，為業(yè)務(wù)構(gòu)建高效完整的模型實驗基礎(chǔ)設(shè)施。

如果你想近距離感受一下Augur的魅力，歡迎關(guān)注文末的招聘信息，加入美團(tuán)技術(shù)團(tuán)隊！

7. 作者簡介

朱敏，紫順，樂欽，洪晨，喬宇，武進(jìn)，孝峰，俊浩等，均來自美團(tuán)搜索與NLP部。

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的智能搜索模型预估框架的建设与实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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