1. 背景

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

本文將與大家探討美團(tuán)搜索與NLP部使用的統(tǒng)一在線預(yù)估框架Augur的設(shè)計(jì)思路骂倘、效果、優(yōu)勢(shì)與不足巴席，希望對(duì)大家有所幫助或者啟發(fā)历涝。

搜索優(yōu)化問(wèn)題，是個(gè)典型的AI應(yīng)用問(wèn)題漾唉，而AI應(yīng)用問(wèn)題首先是個(gè)系統(tǒng)問(wèn)題荧库。經(jīng)歷近10年的技術(shù)積累和沉淀，美團(tuán)搜索系統(tǒng)架構(gòu)從傳統(tǒng)檢索引擎升級(jí)轉(zhuǎn)變?yōu)锳I搜索引擎毡证。當(dāng)前，美團(tuán)搜索整體架構(gòu)主要由搜索數(shù)據(jù)平臺(tái)蔫仙、在線檢索框架及云搜平臺(tái)料睛、在線AI服務(wù)及實(shí)驗(yàn)平臺(tái)三大體系構(gòu)成。在AI服務(wù)及實(shí)驗(yàn)平臺(tái)中摇邦，模型訓(xùn)練平臺(tái)Poker和在線預(yù)估框架Augur是搜索AI化的核心組件恤煞，解決了模型從離線訓(xùn)練到在線服務(wù)的一系列系統(tǒng)問(wèn)題，極大地提升了整個(gè)搜索策略迭代效率施籍、在線模型預(yù)估的性能以及排序穩(wěn)定性居扒，并助力商戶、外賣丑慎、內(nèi)容等核心搜索場(chǎng)景業(yè)務(wù)指標(biāo)的飛速提升喜喂。

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

為了保證良好的用戶體驗(yàn)机打，技術(shù)團(tuán)隊(duì)對(duì)模型預(yù)估能力的要求變得越來(lái)越高矫户，同時(shí)模型與特征的類型、數(shù)量及復(fù)雜度也在與日俱增残邀。算法團(tuán)隊(duì)如何盡量少地開(kāi)發(fā)和部署上線吏垮，如何快速進(jìn)行模型特征的迭代障涯？如何確保良好的預(yù)估性能？在線預(yù)估框架Augur應(yīng)運(yùn)而生膳汪。經(jīng)過(guò)一段時(shí)間的實(shí)踐唯蝶，Augur也有效地滿足了算法側(cè)的需求，并成為美團(tuán)搜索與NLP部通用的解決方案遗嗽。下面粘我，我們將從解讀概念開(kāi)始，然后再分享一下在實(shí)施過(guò)程中我們團(tuán)隊(duì)的一些經(jīng)驗(yàn)和思考痹换。

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

其實(shí)征字，模型預(yù)估的邏輯相對(duì)簡(jiǎn)單、清晰娇豫。但是如果要整個(gè)平臺(tái)做得好用且高效匙姜，這就需要框架系統(tǒng)和工具建設(shè)（一般是管理平臺(tái)）兩個(gè)層面的配合，需要兼顧需求冯痢、效率與性能氮昧。

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

純粹從一個(gè)工程人員視角來(lái)看： 模型可以簡(jiǎn)化為一個(gè)公式（ 舉例：f(x1,x2)= ax1 + bx2 +c ）历恐，訓(xùn)練模型是找出最合適的參數(shù)abc寸癌。所謂特征，是其中的自變量x1與x2弱贼，而模型預(yù)估灵份，就是將給定的自變量x1與x2代入公式，求得一個(gè)解而已哮洽。（當(dāng)然實(shí)際模型輸出的結(jié)果可能會(huì)更加復(fù)雜填渠，包括輸出矩陣、向量等等鸟辅，這里只是簡(jiǎn)單的舉例說(shuō)明氛什。）

所以在實(shí)際業(yè)務(wù)場(chǎng)景中，一個(gè)模型預(yù)估的過(guò)程可以分為兩個(gè)簡(jiǎn)單的步驟：第一步匪凉，特征抽惹姑肌（找出x1與x2）；第二步再层，模型預(yù)估（執(zhí)行公式 ?贸铜，獲得最終的結(jié)果）堡纬。

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

• 深度學(xué)習(xí)模型：特征多醇份，計(jì)算復(fù)雜稼锅，性能要求高；我們將計(jì)算過(guò)程放到公司統(tǒng)一提供的TF-Serving/MLX預(yù)估服務(wù)上被芳；
• 線性模型缰贝、樹(shù)模型：搜索場(chǎng)景下使用的特征相對(duì)較少馍悟，計(jì)算邏輯也相對(duì)簡(jiǎn)單畔濒，我們將在構(gòu)建的預(yù)估框架內(nèi)部再構(gòu)建起高性能的本機(jī)求解邏輯，從而減少RPC锣咒。

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

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

3.1 老框架的局限

舊架構(gòu)中模型預(yù)估與業(yè)務(wù)邏輯耦合的方式鳍寂，在預(yù)估文檔數(shù)和特征數(shù)量不大的時(shí)候可以提供較好的支持。但是情龄，從2018年開(kāi)始迄汛，搜索業(yè)務(wù)瓶頸開(kāi)始到來(lái)捍壤，點(diǎn)評(píng)事業(yè)部開(kāi)始對(duì)整個(gè)搜索系統(tǒng)進(jìn)行升級(jí)改造，并打造基于知識(shí)圖譜的分層排序架構(gòu)（詳情可以參見(jiàn)點(diǎn)評(píng)搜索智能中心在2019年初推出的實(shí)踐文章《大眾點(diǎn)評(píng)搜索基于知識(shí)圖譜的深度學(xué)習(xí)排序?qū)嵺`》）鞍爱。這意味著：更多需要模型預(yù)估的文檔鹃觉，更多的特征，更深層次的模型硬霍，更多的模型處理層級(jí)帜慢，以及更多的業(yè)務(wù)。在這樣的需求背景下唯卖，老框架開(kāi)始出現(xiàn)了一些局限性粱玲，主要包括以下三個(gè)層面：

• 性能瓶頸：核心層的模型預(yù)估的Size擴(kuò)展到數(shù)千級(jí)別文檔的時(shí)候，單機(jī)已經(jīng)難以承載拜轨；近百萬(wàn)個(gè)特征值的傳輸開(kāi)銷已經(jīng)難以承受抽减。
• 復(fù)用困難：模型預(yù)估能力已經(jīng)成為一個(gè)通用的需求，單搜索就有幾十個(gè)場(chǎng)景都需要該能力橄碾；而老邏輯的業(yè)務(wù)耦合性讓復(fù)用變得更加困難卵沉。
• 平臺(tái)缺失：快速的業(yè)務(wù)迭代下，需要有一個(gè)平臺(tái)可以幫助業(yè)務(wù)快速地進(jìn)行模型和特征的管理法牲，包括但不限于配置史汗、上線、灰度拒垃、驗(yàn)證等等停撞。

3.2 新框架的邊界

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

• 業(yè)務(wù)解耦道宅，設(shè)定框架邊界：只做特征抽取和模型預(yù)估，對(duì)預(yù)估結(jié)果的處理等業(yè)務(wù)邏輯交給上層處理胸蛛。
• 無(wú)狀態(tài)污茵，且可以做到分布式模型預(yù)估，無(wú)壓力支持?jǐn)?shù)千級(jí)別文檔數(shù)的深度模型預(yù)估胚泌。

架構(gòu)上的改變省咨，讓Augur具備了復(fù)用的基礎(chǔ)能力，同時(shí)也擁有了分布式預(yù)估的能力玷室×闳兀可惜笤受，系統(tǒng)架構(gòu)設(shè)計(jì)中沒(méi)有“銀彈”：雖然系統(tǒng)具有了良好的彈性，但為此我們也付出了一些代價(jià)敌蜂，我們會(huì)在文末進(jìn)行解釋箩兽。

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

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

如何解決特征和模型的高效迭代？
如何解決批量預(yù)估的性能和資源問(wèn)題摊唇？
如何實(shí)現(xiàn)能力的快速?gòu)?fù)用并能夠保障業(yè)務(wù)的安全咐蝇？
下面，我們將逐一給出答案巷查。

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

4.1.1 Operator和Transformer

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

• 來(lái)源多：商戶、商品岛请、交易旭寿、用戶等數(shù)十個(gè)維度的數(shù)據(jù)，還有交叉維度崇败。由于美團(tuán)業(yè)務(wù)眾多盅称，難以通過(guò)統(tǒng)一的特征存儲(chǔ)去構(gòu)建，交易相關(guān)數(shù)據(jù)只能通過(guò)服務(wù)來(lái)獲取僚匆。
• 業(yè)務(wù)邏輯多：大多數(shù)據(jù)在不同的業(yè)務(wù)層會(huì)有復(fù)用微渠，但是它們對(duì)特征的處理邏輯又有所不同搭幻。
• 模型差異：同一個(gè)特征咧擂，在不同的模型下，會(huì)有不同的處理邏輯檀蹋。比如松申，一個(gè)連續(xù)型特征的分桶計(jì)算邏輯一樣，但“桶”卻因模型而各不相同俯逾；對(duì)于離散特征的低頻過(guò)濾也是如此贸桶。
• 迭代快：特征的快速迭代，要求特征有快速在線上生效的能力桌肴，如果想要改動(dòng)一個(gè)判斷還需要寫(xiě)代碼上線部署皇筛，無(wú)疑會(huì)拖慢了迭代的速度。模型如此坠七，特征也是如此水醋。

針對(duì)特征的處理邏輯旗笔，我們抽象出兩個(gè)概念：

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

• IO OP：用處理原始特征的獲取拄踪，如從KV里獲取數(shù)據(jù)蝇恶，或者從對(duì)應(yīng)的第三方服務(wù)中獲取數(shù)據(jù)。內(nèi)置批量接口惶桐，可以實(shí)現(xiàn)批量召回撮弧，減少RPC。
• Calc OP：用于處理對(duì)獲取到的原始特征做與模型無(wú)關(guān)的邏輯處理姚糊，如拆分贿衍、判空、組合救恨。業(yè)務(wù)可以結(jié)合需求實(shí)現(xiàn)特征處理邏輯舌厨。
  通過(guò)IO、計(jì)算分離忿薇，特征抽取執(zhí)行階段就可以進(jìn)行IO異步裙椭、自動(dòng)聚合RPC、并行計(jì)算的編排優(yōu)化署浩，從而達(dá)到提升性能的目的揉燃。

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

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

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

4.1.2 特征計(jì)算DSL

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

舉個(gè)例子：

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

在上面的例子中鉴嗤，ParseJSON與IsWeekend都是OP斩启， CtxDateInfo與isTodayWeekend都是由其他特征以及OP組合而成的特征。通過(guò)這種方式醉锅，業(yè)務(wù)方根據(jù)自己的需求編寫(xiě)OP , 可以快速?gòu)?fù)用已有的OP和特征兔簇，創(chuàng)造自己需要的新特征。而在真實(shí)的場(chǎng)景中硬耍，IO OP的數(shù)量相對(duì)固定垄琐。所以經(jīng)過(guò)一段時(shí)間的累計(jì)，OP的數(shù)量會(huì)趨于穩(wěn)定经柴，新特征只需基于已有的OP和特征組合即可實(shí)現(xiàn)狸窘，非常的高效。

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

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

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

通過(guò)以上配置，一個(gè)模型可以通過(guò)特征名和Transformer的組合清晰地表達(dá)椰拒。因此晶渠，模型與特征都只是一段純文本配置凰荚，可以保存在外部燃观，Augur在需要的時(shí)候可以動(dòng)態(tài)的加載，進(jìn)而實(shí)現(xiàn)模型和特征的上線配置化便瑟，無(wú)需編寫(xiě)代碼進(jìn)行上線缆毁，安全且高效。

其中到涂，我們將輸入模型的特征名（tf_input_name）和原始特征名（name）做了區(qū)分脊框。這樣的話颁督，就可以只在外部編寫(xiě)一次表達(dá)式，注冊(cè)一個(gè)公用特征浇雹，卻能通過(guò)在模型的結(jié)構(gòu)體中配置不同Transfomer創(chuàng)造出多個(gè)不同的模型預(yù)估特征沉御。這種做法相對(duì)節(jié)約資源，因?yàn)楣锰卣髦恍璩槿∮?jì)算一次即可昭灵。

此外吠裆，這一套配置文件也是離線樣本生產(chǎn)時(shí)使用的特征配置文件，結(jié)合統(tǒng)一的OP&Transformer代碼邏輯烂完，進(jìn)一步保證了離線/在線處理的一致性试疙，也簡(jiǎn)化了上線的過(guò)程。因?yàn)橹恍枰陔x線狀態(tài)下配置一次樣本生成文件抠蚣，即可在離線樣本生產(chǎn)祝旷、在線模型預(yù)估兩個(gè)場(chǎng)景通用。

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

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

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

為了描述清楚整個(gè)過(guò)程长赞，這里需要明確特征的兩種類型：

• ContextLevel Feature：全局維度特征晦攒，一次模型預(yù)估請(qǐng)求中，此類特征是通用的得哆。比如時(shí)間脯颜、地理位置、距離贩据、用戶信息等等栋操。這些信息只需計(jì)算一次。
• DocLevel Feature：文檔維度特征饱亮，一次模型預(yù)估請(qǐng)求中每個(gè)文檔的特征不同矾芙，需要分別計(jì)算。

一個(gè)典型的模型預(yù)估請(qǐng)求近上，如下圖所示：

Augur啟動(dòng)時(shí)會(huì)加載所有特征的表達(dá)式和模型剔宪，一個(gè)模型預(yù)估請(qǐng)求ModelScoreRequest會(huì)帶來(lái)對(duì)應(yīng)的模型名、要打分的文檔id（docid）以及一些必要的全局信息Context。 Augur在請(qǐng)求命中模型之后葱绒，將模型所用特征構(gòu)建成一顆樹(shù)感帅，并區(qū)分ContextLevel特征和DocLevel特征。由于DocLevel特征會(huì)依賴ContextLevel特征地淀，故先將ContextLevel特征計(jì)算完畢失球。對(duì)于Doc維度，由于對(duì)每一個(gè)Doc都要加載和計(jì)算對(duì)應(yīng)的特征帮毁，所以在Doc加載階段會(huì)對(duì)Doc列表進(jìn)行分片她倘，并發(fā)完成特征的加載，并且各分片在完成特征加載之后就進(jìn)行打分階段作箍。也就是說(shuō)硬梁，打分階段本身也是分片并發(fā)進(jìn)行的，各分片在最后打分完成后匯總數(shù)據(jù)胞得，返回給調(diào)用方荧止。 期間還會(huì)通過(guò)異步接口將特征日志上報(bào)，方便算法同學(xué)進(jìn)一步迭代阶剑。

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

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

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

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

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

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

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

• 幾個(gè)常被忽略的點(diǎn)： 預(yù)估時(shí)產(chǎn)出的特征日志熊响，需要通過(guò)框架上傳到公司日志中心或者以用戶希望的方式進(jìn)行存儲(chǔ)，方便模型的迭代诗赌。當(dāng)然汗茄，必要的時(shí)候可以落入本地，方便問(wèn)題的定位铭若。

• 方便問(wèn)題的定位：系統(tǒng)監(jiān)控不用多說(shuō)洪碳，美團(tuán)內(nèi)部的Cat&天網(wǎng)匹表，可以構(gòu)建出完善的監(jiān)控體系缰犁。另一方面表牢，特征的監(jiān)控也很重要师坎，因?yàn)樘卣鳙@取的穩(wěn)定性決定了模型預(yù)估的質(zhì)量锦茁，所以我們構(gòu)建了實(shí)時(shí)的特征分布監(jiān)控系統(tǒng)侥啤，可以分鐘級(jí)發(fā)現(xiàn)特征分布的異常沾谓，最大限度上保證模型預(yù)估的可靠性漏设。

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

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

4.3 建設(shè)預(yù)估平臺(tái)：快速?gòu)?fù)用與高效管理

4.3.1 能力的快速?gòu)?fù)用

Augur在設(shè)計(jì)之初，就將所有業(yè)務(wù)邏輯通過(guò)OP和Transformer承載偷遗，所以跟業(yè)務(wù)無(wú)關(guān)墩瞳。考慮到美團(tuán)搜索與NLP部模型預(yù)估場(chǎng)景需求的多樣性氏豌，我們還為Augur賦予多種業(yè)務(wù)調(diào)用的方式喉酌。

• 種業(yè)務(wù)調(diào)用的方式。：即基于Augur構(gòu)建一個(gè)完整的Service泵喘，可以實(shí)現(xiàn)無(wú)狀態(tài)分布式的彈性預(yù)估能力泪电。
• 布式的彈性預(yù)估能：Java服務(wù)化版本中內(nèi)置了對(duì)Thrift 的支持，使不同語(yǔ)言的業(yè)務(wù)都可以方便地?fù)碛心Ｐ皖A(yù)估能力纪铺。
• 地?fù)碛?/strong>：Augur支持同一個(gè)服務(wù)同時(shí)提供Pigeon（美團(tuán)內(nèi)部的RPC框架）以及Thrift 服務(wù)相速，從而滿足不同業(yè)務(wù)的不同需求。
• 不同業(yè)務(wù)的不同需：Augur同樣支持以SDK的方式將能力嵌入到已有的集群當(dāng)中鲜锚。但如此一來(lái)突诬，分布式能力就無(wú)法發(fā)揮了。所以烹棉，我們一般應(yīng)用在性能要求高攒霹、模型比較小、特征基本可以存在本地的場(chǎng)景下浆洗。

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

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

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

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

首先是預(yù)估核心特征的管理，上面說(shuō)到我們構(gòu)建了語(yǔ)言化的特征表達(dá)式柱蟀，這其實(shí)是個(gè)較為常見(jiàn)的思路川蒙。Poker利用Augur提供的豐富接口，結(jié)合算法的使用習(xí)慣产弹，構(gòu)建了一套較為流暢的特征管理工具派歌⊥淠遥可以在平臺(tái)上完成新增痰哨、測(cè)試、上線匾嘱、卸載斤斧、歷史回滾等一系列操作。同時(shí)霎烙，還可以查詢特征被服務(wù)中的哪些模型直接或者間接引用撬讽，在修改和操作時(shí)還有風(fēng)險(xiǎn)提示，兼顧了便捷性與安全性悬垃。

模型管理也是一樣游昼，我們?cè)谄脚_(tái)上實(shí)現(xiàn)了模型的配置化上線、卸載尝蠕、上線前的驗(yàn)證烘豌、灰度、獨(dú)立的打分測(cè)試看彼、Debug信息的返回等等廊佩。同時(shí)支持在平臺(tái)上直接修改模型配置文件，平臺(tái)可以實(shí)現(xiàn)模型多版本控制靖榕，一鍵回滾等标锄。配置皆為實(shí)時(shí)生效，避免了手動(dòng)上線遇到問(wèn)題后因處理時(shí)間過(guò)長(zhǎng)而導(dǎo)致?lián)p失的情況茁计。

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

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

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

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

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

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

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

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

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

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

4.4.2 Online Model Ensemble

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

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

5. 更多思考

當(dāng)然，肯定沒(méi)有完美的框架和平臺(tái)膛檀。Augur和Poker還有很大的進(jìn)步空間锰镀，也有一些不可回避的問(wèn)題。主要包括以下幾個(gè)方面咖刃。

被迫“消失”的Listwise特征

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

當(dāng)然箩帚，不是說(shuō)Augur不能實(shí)現(xiàn)真友，只是成本有些高，所以暫時(shí)Hold 紧帕。我們也有設(shè)計(jì)過(guò)方案盔然，在可量化的收益高于成本的時(shí)候，我們會(huì)在Augur中開(kāi)放協(xié)作的接口是嗜。

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

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

離線能力缺失眯漩？

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

未來(lái)赵辕，我們也會(huì)向大家介紹產(chǎn)品級(jí)別的一站式搜索實(shí)驗(yàn)平臺(tái)既绩，敬請(qǐng)期待。

6.未來(lái)展望

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

如果你想近距離感受一下Augur的魅力，歡迎加入美團(tuán)技術(shù)團(tuán)隊(duì)嫉晶！

7. 作者簡(jiǎn)介

朱敏，紫順田篇，樂(lè)欽替废，洪晨，喬宇泊柬，武進(jìn)椎镣，孝峰，俊浩等兽赁，均來(lái)自美團(tuán)搜索與NLP部状答。

轉(zhuǎn)載：https://tech.meituan.com/2020/07/16/augur-in-meituan-nlp.html