在過去十年，機器學習在學術界取得了眾多的突破，在工業界也有很多應用落地。美團很早就開始探索不同的機器學習模型在搜尋場景下的應用，從最開始的線性模型、樹模型，再到近兩年的深度神經網路、BERT、DQN等，並在實踐中也取得了良好的效果與產出。
在美團搜尋AI化的過程中，比較核心的兩個元件是模型訓練平臺Poker和線上預估框架Augur。本文主要與大家探討Augur的設計思路、效果，以及它的優勢與不足，最後也簡單介紹了一下Poker平臺的價值。希望這些內容對大家有所幫助或者啟發。
1. 背景
搜尋優化問題，是個典型的AI應用問題，而AI應用問題首先是個系統問題。經歷近10年的技術積累和沉澱，美團搜尋系統架構從傳統檢索引擎升級轉變為AI搜尋引擎。當前，美團搜尋整體架構主要由搜尋資料平臺、線上檢索框架及雲搜平臺、線上AI服務及實驗平臺三大體系構成。在AI服務及實驗平臺中，模型訓練平臺Poker和線上預估框架Augur是搜尋AI化的核心元件，解決了模型從離線訓練到線上服務的一系列系統問題，極大地提升了整個搜尋策略迭代效率、線上模型預估的效能以及排序穩定性，並助力商戶、外賣、內容等核心搜尋場景業務指標的飛速提升。
首先，讓我們看看在美團App內的一次完整的搜尋行為主要涉及哪些技術模組。如下圖所示，從點選輸入框到最終的結果展示，從熱門推薦，到動態補全、最終的商戶列表展示、推薦理由的展示等，每一個模組都要經過若干層的模型處理或者規則干預，才會將最適合使用者（指標）的結果展示在大家的眼前。
為了保證良好的使用者體驗，技術團隊對模型預估能力的要求變得越來越高，同時模型與特徵的型別、數量及複雜度也在與日俱增。演算法團隊如何儘量少地開發和部署上線，如何快速進行模型特徵的迭代？如何確保良好的預估效能？線上預估框架Augur應運而生。經過一段時間的實踐，Augur也有效地滿足了演算法側的需求，併成為美團搜尋與NLP部通用的解決方案。下面，我們將從解讀概念開始，然後再分享一下在實施過程中我們團隊的一些經驗和思考。
2.抽象過程：什麼是模型預估
其實，模型預估的邏輯相對簡單、清晰。但是如果要整個平臺做得好用且高效，這就需要框架系統和工具建設（一般是管理平臺）兩個層面的配合，需要兼顧需求、效率與效能。
那麼，什麼是模型預估呢？如果忽略掉各種演算法的細節，我們可以認為模型是一個函式，有一批輸入和輸出，我們提供將要預估文件的相關資訊輸入模型，並根據輸出的值（即模型預估的值）對原有的文件進行排序或者其他處理。
純粹從一個工程人員視角來看： 模型可以簡化為一個公式（ 舉例：f(x1,x2)= ax1 + bx2 +c ），訓練模型是找出最合適的引數abc。所謂特徵，是其中的自變數x1與x2，而模型預估，就是將給定的自變數x1與x2代入公式，求得一個解而已。（當然實際模型輸出的結果可能會更加複雜，包括輸出矩陣、向量等等，這裡只是簡單的舉例說明。）
所以在實際業務場景中，一個模型預估的過程可以分為兩個簡單的步驟：第一步，特徵抽取（找出x1與x2）；第二步，模型預估（執行公式 ƒ，獲得最終的結果）。
模型預估很簡單，從業務工程的視角來看，無論多複雜，它只是一個計算分數的過程。對於整個運算的優化，無論是矩陣運算，還是底層的GPU卡的加速，業界和美團內部都有比較好的實踐。美團也提供了高效能的TF-Serving服務（參見《基於TensorFlow Serving的深度學習線上預估》一文）以及自研的MLX模型打分服務，都可以進行高效能的Batch打分。基於此，我們針對不同的模型，採取不同的策略：
- 深度學習模型：特徵多，計算複雜，效能要求高；我們將計算過程放到公司統一提供的TF-Serving/MLX預估服務上；
- 線性模型、樹模型：搜尋場景下使用的特徵相對較少，計算邏輯也相對簡單，我們將在構建的預估框架內部再構建起高效能的本機求解邏輯，從而減少RPC。
這一套邏輯很簡單，構建起來也不復雜，所以在建設初期，我們快速在主搜的核心業務邏輯中快速實現了這一架構，如下圖所示。這樣的一個架構使得我們可以在主搜的核心排序邏輯中，能夠使用各類線性模型的預估，同時也可以藉助公司的技術能力，進行深度模型的預估。關於特徵抽取的部分，我們也簡單實現了一套規則，方便演算法同學可以自行實現一些簡單的邏輯。
3. 預估框架思路的改變
3.1 老框架的侷限
舊架構中模型預估與業務邏輯耦合的方式，在預估文件數和特徵數量不大的時候可以提供較好的支援。但是，從2018年開始，搜尋業務瓶頸開始到來，點評事業部開始對整個搜尋系統進行升級改造，並打造基於知識圖譜的分層排序架構（詳情可以參見點評搜尋智慧中心在2019年初推出的實踐文章《大眾點評搜尋基於知識圖譜的深度學習排序實踐》）。這意味著：更多需要模型預估的文件，更多的特徵，更深層次的模型，更多的模型處理層級，以及更多的業務。在這樣的需求背景下，老框架開始出現了一些侷限性，主要包括以下三個層面：
- 效能瓶頸：核心層的模型預估的Size擴充套件到數千級別文件的時候，單機已經難以承載；近百萬個特徵值的傳輸開銷已經難以承受。
- 複用困難：模型預估能力已經成為一個通用的需求，單搜尋就有幾十個場景都需要該能力；而老邏輯的業務耦合性讓複用變得更加困難。
- 平臺缺失：快速的業務迭代下，需要有一個平臺可以幫助業務快速地進行模型和特徵的管理，包括但不限於配置、上線、灰度、驗證等等。
3.2 新框架的邊界
跟所有新系統的誕生故事一樣，老系統一定會出現問題。原有架構在少特徵以及小模型下雖有優勢，但業務耦合，無法橫向擴充套件，也難以複用。針對需求和老框架的種種問題，我們開始構建了新的高效能分散式模型預估框架Augur，該框架指導思路是：
- 業務解耦，設定框架邊界：只做特徵抽取和模型預估，對預估結果的處理等業務邏輯交給上層處理。
- 無狀態，且可以做到分散式模型預估，無壓力支援數千級別文件數的深度模型預估。
架構上的改變，讓Augur具備了複用的基礎能力，同時也擁有了分散式預估的能力。可惜，系統架構設計中沒有“銀彈”：雖然系統具有了良好的彈性，但為此我們也付出了一些代價，我們會在文末進行解釋。
4.預估平臺的構建過程
框架思路只能解決“能用”的問題，平臺則是為了“通用”與“好用”。一個優秀的預估平臺需要保證高效能，具備較為通用且介面豐富的核心預估框架，以及產品級別的業務管理系統。為了能夠真正地提升預估能力和業務迭代的效率，平臺需要回答以下幾個問題：
- 如何解決特徵和模型的高效迭代？
- 如何解決批量預估的效能和資源問題？
- 如何實現能力的快速複用並能夠保障業務的安全？
下面，我們將逐一給出答案。
4.1 構建預估核心：高效的特徵和模型迭代
4.1.1 Operator和Transformer
在搜尋場景下，特徵抽取較為難做的原因主要包括以下幾點：
- 來源多：商戶、商品、交易、使用者等數十個維度的資料，還有交叉維度。由於美團業務眾多，難以通過統一的特徵儲存去構建，交易相關資料只能通過服務來獲取。
- 業務邏輯多：大多資料在不同的業務層會有複用，但是它們對特徵的處理邏輯又有所不同。
- 模型差異：同一個特徵，在不同的模型下，會有不同的處理邏輯。比如，一個連續型特徵的分桶計算邏輯一樣，但“桶”卻因模型而各不相同；對於離散特徵的低頻過濾也是如此。
- 迭代快：特徵的快速迭代，要求特徵有快速線上上生效的能力，如果想要改動一個判斷還需要寫程式碼上線部署，無疑會拖慢了迭代的速度。模型如此，特徵也是如此。
針對特徵的處理邏輯，我們抽象出兩個概念：
Operator：通用特徵處理邏輯，根據功能的不同又可以分為兩類：
- IO OP：用處理原始特徵的獲取，如從KV裡獲取資料，或者從對應的第三方服務中獲取資料。內建批量介面，可以實現批量召回，減少RPC。
- Calc OP：用於處理對獲取到的原始特徵做與模型無關的邏輯處理，如拆分、判空、組合。業務可以結合需求實現特徵處理邏輯。
通過IO、計算分離，特徵抽取執行階段就可以進行IO非同步、自動聚合RPC、平行計算的編排優化，從而達到提升效能的目的。
Transformer：用於處理與模型相關的特徵邏輯，如分桶、低頻過濾等等。一個特徵可以配置一個或者多個Transformer。Transformer也提供介面，業務方可以根據自己的需求定製邏輯。
離線上統一邏輯：Transformer是特徵處理的模型相關邏輯，因此我們將Transformer邏輯單獨抽包，在我們樣本生產的過程中使用，保證離線樣本生產與線上特徵處理邏輯的一致性。
基於這兩個概念，Augur中特徵的處理流程如下所示： 首先，我們會進行特徵抽取 ，抽取完後，會對特徵做一些通用的處理邏輯；而後，我們會根據模型的需求進行二次變換，並將最終值輸入到模型預估服務中。如下圖所示：
4.1.2 特徵計算DSL
有了Operator的概念，為了方便業務方進行高效的特徵迭代，Augur設計了一套弱型別、易讀的特徵表示式語言，將特徵看成一系列OP與其他特徵的組合，並基於Bison&JFlex構建了高效能語法和詞法解析引擎。我們在解釋執行階段還做了一系列優化，包括平行計算、中間特徵共享、非同步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 這種的日期是否是週末, 便可以複用 CtxDateInfo 這個特徵; IsWeekend 也是是一個 Calc 型別的 OP
IsWeekend(CtxDateInfo['date'])在上面的例子中，ParseJSON與IsWeekend都是OP， CtxDateInfo與isTodayWeekend都是由其他特徵以及OP組合而成的特徵。通過這種方式，業務方根據自己的需求編寫OP , 可以快速複用已有的OP和特徵，創造自己需要的新特徵。而在真實的場景中，IO OP的數量相對固定。所以經過一段時間的累計，OP的數量會趨於穩定，新特徵只需基於已有的OP和特徵組合即可實現，非常的高效。
4.1.3 配置化的模型表達
特徵可以用利用OP、使用表示式的方式去表現，但特徵還可能需要經過Transformer的變換。為此，我們同樣為模型構建一套可解釋的JSON表達模板，模型中每一個特徵可以通過一個JSON物件進行配置，以一個輸入到TF模型裡的特徵結構為例：
// 一個的特徵的 JSON 配置
{
"tf_input_config": {"otherconfig"},
"tf_input_name": "modulestyle",
"name": "moduleStyle",
"transforms": [ // Transfomers：模型相關的處理邏輯，可以有多個，Augur 會按照順序執行
{
"name": "BUCKETIZE", // Transfomer 的名稱：這裡是分桶
"params": {
"bins": [0,1,2,3,4] // Transfomer 的引數
}
}
],
"default_value": -1
}
通過以上配置，一個模型可以通過特徵名和Transformer的組合清晰地表達。因此，模型與特徵都只是一段純文字配置，可以儲存在外部，Augur在需要的時候可以動態的載入，進而實現模型和特徵的上線配置化，無需編寫程式碼進行上線，安全且高效。
其中，我們將輸入模型的特徵名（tf_input_name）和原始特徵名（name）做了區分。這樣的話，就可以只在外部編寫一次表示式，註冊一個公用特徵，卻能通過在模型的結構體中配置不同Transfomer創造出多個不同的模型預估特徵。這種做法相對節約資源，因為公用特徵只需抽取計算一次即可。
此外，這一套配置檔案也是離線樣本生產時使用的特徵配置檔案，結合統一的OP&Transformer程式碼邏輯，進一步保證了離線/線上處理的一致性，也簡化了上線的過程。因為只需要在離線狀態下配置一次樣本生成檔案，即可在離線樣本生產、線上模型預估兩個場景通用。
4.2 完善預估系統：效能、介面與周邊設施
4.2.1 高效的模型預估過程
OP和Transformer構建了框架處理特徵的基本能力。實際開發中，為了實現高效能的預估能力，我們採用了分片純非同步的執行緒結構，層層Call Back，最大程度將執行緒資源留給實際計算。因此，預估服務對機器的要求並不高。
為了描述清楚整個過程，這裡需要明確特徵的兩種型別：
- ContextLevel Feature：全域性維度特徵，一次模型預估請求中，此類特徵是通用的。比如時間、地理位置、距離、使用者資訊等等。這些資訊只需計算一次。
- DocLevel Feature：文件維度特徵，一次模型預估請求中每個文件的特徵不同，需要分別計算。
一個典型的模型預估請求，如下圖所示：
Augur啟動時會載入所有特徵的表示式和模型，一個模型預估請求ModelScoreRequest會帶來對應的模型名、要打分的文件id（docid）以及一些必要的全域性資訊Context。 Augur在請求命中模型之後，將模型所用特徵構建成一顆樹，並區分ContextLevel特徵和DocLevel特徵。由於DocLevel特徵會依賴ContextLevel特徵，故先將ContextLevel特徵計算完畢。對於Doc維度，由於對每一個Doc都要載入和計算對應的特徵，所以在Doc載入階段會對Doc列表進行分片，併發完成特徵的載入，並且各分片在完成特徵載入之後就進行打分階段。也就是說，打分階段本身也是分片併發進行的，各分片在最後打分完成後彙總資料，返回給呼叫方。 期間還會通過非同步介面將特徵日誌上報，方便演算法同學進一步迭代。
在這個過程中，為了使整個流程非同步非阻塞，我們要求引用的服務提供非同步介面。若部分服務未提供非同步介面，可以將其包裝成偽非同步。這一套非同步流程使得單機（16c16g）的服務容量提升超過100%，提高了資源的利用率。
4.2.2 預估的效能及表示式的開銷
框架的優勢：得益於分散式，純非同步流程，以及在特徵OP內部做的各類優化（公用特徵 、RPC聚合等），從老框架遷移到Augur後，上千份文件的深度模型預估效能提升了一倍。
至於大家關心的表示式解析對對於效能的影響其實可以忽略。因為這個模型預估的耗時瓶頸主要在於原始特徵的抽取效能（也就是特徵儲存的效能）以及預估服務的效能（也就是Serving的效能）。而 Augur 提供了表示式解析的Benchmark測試用例，可以進行解析效能的驗證。
_I(_I('xxx'))
Benchmark Mode Cnt Score Error Units
AbsBenchmarkTest.test avgt 25 1.644 ± 0.009 ms/op一個兩層巢狀的表示式解析10W次的效能是1.6ms左右。相比於整個預估的時間，以及語言化表示式對於特徵迭代效率的提升，這一耗時在當前業務場景下，基本可以忽略不計。
4.2.3 系統的其他組成部分
一個完善可靠的預估系統，除了“看得見”的高效能預估能力，還需要做好以下幾個常被忽略的點：
- 幾個常被忽略的點： 預估時產出的特徵日誌，需要通過框架上傳到公司日誌中心或者以使用者希望的方式進行儲存，方便模型的迭代。當然，必要的時候可以落入本地，方便問題的定位。
- ，方便問題的定位：系統監控不用多說，美團內部的Cat&天網，可以構建出完善的監控體系。另一方面，特徵的監控也很重要，因為特徵獲取的穩定性決定了模型預估的質量，所以我們構建了實時的特徵分佈監控系統，可以分鐘級發現特徵分佈的異常，最大限度上保證模型預估的可靠性。
- 豐富的介面：除了預估介面，還需要有特徵抽取介面、模型打分Debug 介面、特徵表示式測試介面、模型單獨測試介面、特徵模型重新整理介面、特徵依賴檢等等一系列介面，這樣才可以保證整個系統的可用性，併為後面管理平臺的建設打下基礎。
Augur在完成了以上多種能力的建設之後，就可以當做一個功能相對完善且易擴充套件的線上預估系統。由於我們在構建 Augur的時候，設立了明確的邊界，故以上能力是獨立於業務的，可以方便地進行復用。當然，Augur的功能管理，更多的業務接入，都需要管理平臺的承載。於是，我們就構建了Poker平臺，其中的線上預估管理模組是服務於Augur，可以進行模型特徵以及業務配置的高效管理。我們將在下一小節進行介紹。
4.3 建設預估平臺：快速複用與高效管理
4.3.1 能力的快速複用
Augur在設計之初，就將所有業務邏輯通過OP和Transformer承載，所以跟業務無關。考慮到美團搜尋與NLP部模型預估場景需求的多樣性，我們還為Augur賦予多種業務呼叫的方式。
- 種業務呼叫的方式。：即基於Augur構建一個完整的Service，可以實現無狀態分散式的彈性預估能力。
- 布式的彈性預估能：Java服務化版本中內建了對Thrift 的支援，使不同語言的業務都可以方便地擁有模型預估能力。
- 地擁有：Augur支援同一個服務同時提供Pigeon（美團內部的RPC框架）以及Thrift 服務，從而滿足不同業務的不同需求。
- 不同業務的不同需：Augur同樣支援以SDK的方式將能力嵌入到已有的叢集當中。但如此一來，分散式能力就無法發揮了。所以，我們一般應用在效能要求高、模型比較小、特徵基本可以存在本地的場景下。
其中服務化是被應用最多的方式，為了方便業務方的使用，除了完善的文件外，我們還構建了標準的服務模板，任何一個業務方基本上都可以在30分鐘內構建出自己的Augur服務。服務模板內建了60多個常用邏輯和計算OP , 並提供了最佳實踐文件與配置邏輯，使得業務方在沒有指導的情況下可以自行解決95%以上的問題。整個流程如下圖所示：
當然，無論使用哪一種方式去構建預估服務，都可以在美團內部的Poker平臺上進行服務、模型與特徵的管理。
4.3.2 Augur管理平臺Poker的構建
實現一個框架價值的最大化，需要一個完整的體系去支撐。而一個合格的線上預估平臺，需要一個產品級別的管理平臺輔助。於是我們構建了Poker（搜尋實驗平臺），其中的線上預估服務管理模組，也是Augur的最佳拍檔。Augur是一個可用性較高的線上預估框架，而Poker+Augur則構成了一個好用的線上預估平臺。下圖是線上預估服務管理平臺的功能架構：
首先是預估核心特徵的管理，上面說到我們構建了語言化的特徵表示式，這其實是個較為常見的思路。Poker利用Augur提供的豐富介面，結合演算法的使用習慣，構建了一套較為流暢的特徵管理工具。可以在平臺上完成新增、測試、上線、解除安裝、歷史回滾等一系列操作。同時，還可以查詢特徵被服務中的哪些模型直接或者間接引用，在修改和操作時還有風險提示，兼顧了便捷性與安全性。
模型管理也是一樣，我們在平臺上實現了模型的配置化上線、解除安裝、上線前的驗證、灰度、獨立的打分測試、Debug資訊的返回等等。同時支援在平臺上直接修改模型配置檔案，平臺可以實現模型多版本控制，一鍵回滾等。配置皆為實時生效，避免了手動上線遇到問題後因處理時間過長而導致損失的情況。
4.3.3 Poker + Augur的應用與效果
隨著Augur和Poker的成熟，美團搜尋與NLP部門內部已經有超過30個業務方已經全面接入了預估平臺，整體的概況如下圖所示：
預估框架使用遷移Augur後，效能和模型預估穩定性上均獲得了較大幅度的提升。更加重要的是，Poker平臺的線上預估服務管理和Augur預估框架，還將演算法同學從繁複且危險的上線操作中解放出來，更加專注於演算法迭代，從而取得更好的效果。以點評搜尋為例，在Poker+Augur穩定上線之後，經過短短半年的時間，點評搜尋核心KPI在高位基礎上仍然實現了大幅提升，是過去一年半漲幅的六倍之多，提前半年完成全年的目標。
4.4 進階預估操作：模型也是特徵
4.4.1 Model as a Feature，同構or異構？
在演算法的迭代中，有時會將一個模型的預估的結果當做另外一個模型輸入特徵，進而取得更好的效果。如美團搜尋與NLP中心的演算法同學使用BERT來解決長尾請求商戶的展示順序問題，此時需要BERT as a Feature。一般的做法是離線進行BERT批量計算，灌入特徵儲存供線上使用。但這種方式存在時效性較低（T+1）、覆蓋度差等缺點。最好的方式自然是可以線上實時去做BERT模型預估，並將預估輸出值作為特徵，用於最終的模型打分。這就需要Augur提供Model as a Feature的能力。
得益於Augur抽象的流程框架，我們很快超額完成了任務。Model as a feature，雖然要對一個Model做預估操作，但從更上層的模型角度看，它就是一個特徵。既然是特徵，模型預估也就是一個計算OP而已。 所以我們只需要在內部實現一個特殊的OP，ModelFeatureOpreator就可以乾淨地解決這些問題了。
我們在充分調研後，發現Model as a Feature有兩個維度的需求：同構的特徵和異構的特徵。同構指的是這個模型特徵與模型的其他特徵一樣，是與要預估的文件統一維度的特徵，那這個模型就可以配置在同一個服務下，也就是本機可以載入這個Stacking模型；而異構指的是Model Feature與當前預估的文件不是統一維度的，比如商戶下掛的商品，商戶打分需要用到商品打分的結果，這兩個模型非統一維度，屬於兩個業務。正常邏輯下需要序列處理，但是Augur可以做得更高效。為此我們設計了兩個OP來解決問題：
- LocalModelFeature： 解決同構Model Feature的需求，使用者只需像配置普通特徵表示式一樣即可實現線上的Model Stacking；當然，內部自然有優化邏輯，比如外部模型和特徵模型所需的特徵做統一整合，儘可能的減少資源消耗，提升效能。 該特徵所配置的模型特徵，將在本機執行，以減少RPC。
- RemoteModelFeature：解決異構Model Feature的需求，使用者還是隻需配置一個表示式，但是此表示式會去呼叫相應維度的Augur服務，獲取相應的模型和特徵資料供主維度的Augur服務處理。雖然多了一層 RPC，但是相對於純線性的處理流程，分片非同步後，還是有不少的效能提升。
美團搜尋內部，已經通過LocalModelFeature的方式，實現了BERT as a Feature。在幾乎沒有新的使用學習成本的前提下，同時線上上取得了明顯的指標提升。
4.4.2 Online Model Ensemble
Augur支援有單獨抽取特徵的介面，結合Model as a Feature，若需要同時為一個文件進行兩個或者多個模型的打分，再將分數做加權後使用，非常方便地實現離線Ensemble出來模型的實時線上預估。我們可以配置一個簡單的LR、Empty 型別模型（僅用於特徵抽取），或者其他任何 Augur 支援的模型，再通過LocalModelFeature配置若干的Model Feature，就可以通過特徵抽取介面得到一個文件多個模型的線性加權分數了。而這一切都被包含在一個統一的抽象邏輯中，使使用者的體驗是連續統一的，幾乎沒有增加學習成本。
除了上面的操作外，Augur還提供了打分的同時帶回部分特徵的介面，供後續的業務規則處理使用。
5. 更多思考
當然，肯定沒有完美的框架和平臺。Augur和Poker還有很大的進步空間，也有一些不可迴避的問題。主要包括以下幾個方面。
被迫“消失”的Listwise特徵
前面說到，系統架構設計中沒有“銀彈”。在採用了無狀態分散式的設計後，請求會分片。所以ListWise型別的特徵就必須在打分前算好，再通過介面傳遞給Augur使用。在權衡效能和效果之後，演算法同學放棄了這一型別的特徵。
當然，不是說Augur不能實現，只是成本有些高，所以暫時Hold 。我們也有設計過方案，在可量化的收益高於成本的時候，我們會在Augur中開放協作的介面。
單機多層打分的缺失
Augur一次可以進行多個模型的打分，模型相互依賴（下一層模型用到上一層模型的結果）也可以通過Stacking技術來解決。但如果模型相互依賴又逐層減少預估文件（比如，第一輪預估1000個，第二輪預估 500），則只能通過多次RPC的方式去解決問題，這是一個現實問題的權衡。分片打分的效能提升，能否Cover多次RPC的開銷？在實際開發中，為了保持框架的清晰簡單，我們選擇了放棄多層打分的特性。
離線能力缺失？
Poker是搜尋實驗平臺的名字。我們設計它的初衷，是解決搜尋模型實驗中，從離線到線上所有繁複的手工操作，使搜尋擁有一鍵訓練、一鍵Fork、一鍵上線的能力。與公司其他的訓練平臺不同，我們通過完善的線上預估框架倒推離線訓練的需求，進而構建了與線上無縫結合的搜尋實驗平臺，極大地提升了演算法同學的工作效。
未來，我們也會向大家介紹產品級別的一站式搜尋實驗平臺，敬請期待。
6.未來展望
在統一了搜尋的線上預估框架後，我們會進一步對Augur的效能&能力進行擴充套件。未來，我們將會在檢索粗排以及效能要求更高的預估場景中去發揮它的能力與價值。同時 ，我們正在將線上預估框架進一步融合到我們的搜尋實驗平臺Poker中，與離線訓練和AB實驗平臺做了深度的打通，為業務構建高效完整的模型實驗基礎設施。
如果你想近距離感受一下Augur的魅力，歡迎加入美團技術團隊！
7. 作者簡介
朱敏，紫順，樂欽，洪晨，喬宇，武進，孝峰，俊浩等，均來自美團搜尋與NLP部。
閱讀更多技術文章，請掃碼關注微信公眾號-美團技術團隊！
