智能搜索模型預估框架Augur的建設與實踐

在過去十年,機器學習在學術界取得了衆多的突破,在工業界也有不少應用落地。美團很早就開始探索不一樣的機器學習模型在搜索場景下的應用,從最開始的線性模型、樹模型,再到近兩年的深度神經網絡、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部。

閱讀更多技術文章,請掃碼關注微信公衆號-美團技術團隊!

相關文章
相關標籤/搜索