美團(tuán)網(wǎng)站的數(shù)據(jù)搜索排序解決方案精華分享

         一、線上篇

　　隨著業(yè)務(wù)的發(fā)展，美團(tuán)的商家和團(tuán)購數(shù)正在飛速增長。這一背景下，搜索排序的重要性顯得更加突出：排序的優(yōu)化能幫助用戶更便捷地找到滿足其需求的商家和團(tuán)購，改進(jìn)用戶體驗(yàn)，提升轉(zhuǎn)化效果。

　　和傳統(tǒng)網(wǎng)頁搜索問題相比，美團(tuán)的搜索排序有自身的特點(diǎn)——90%的交易發(fā)生在移動(dòng)端。一方面，這對排序的個(gè)性化提出了更高的要求，例如在“火鍋”查詢下，北京五道口的火鍋店A，對在五道口的用戶U1來說是好的結(jié)果，對在望京的用戶U2來講不一定是好的結(jié)果;另一方面，我們由此積累了用戶在客戶端上豐富準(zhǔn)確的行為，經(jīng)分析獲得用戶的地理位置、品類和價(jià)格等偏好，進(jìn)而指導(dǎo)個(gè)性化排序。

　　針對美團(tuán)的O2O業(yè)務(wù)特點(diǎn)，我們實(shí)現(xiàn)了一套搜索排序技術(shù)方案，相比規(guī)則排序有百分之幾十的提升�；�于這一方案，我們又抽象了一套通用的O2O排序解決方案，只需1-2天就可以快速地部署到其他產(chǎn)品和子行業(yè)中，目前在熱詞、Suggestion、酒店、KTV等多個(gè)產(chǎn)品和子行業(yè)中應(yīng)用。

　　我們將按線上和線下兩部分分別介紹這一通用O2O排序解決方案，本文是線上篇，主要介紹在線服務(wù)框架、特征加載、在線預(yù)估等模塊，下篇將會(huì)著重介紹離線流程。

　　排序系統(tǒng)

　　為了快速有效的進(jìn)行搜索算法的迭代，排序系統(tǒng)設(shè)計(jì)上支持靈活的A/B測試，滿足準(zhǔn)確效果追蹤的需求。

　　美團(tuán)搜索排序系統(tǒng)如上圖所示，主要包括離線數(shù)據(jù)處理、線上服務(wù)和在線數(shù)據(jù)處理三個(gè)模塊。

　　離線數(shù)據(jù)處理

　　HDFS/Hive上存儲(chǔ)了搜索展示、點(diǎn)擊、下單和支付等日志。離線數(shù)據(jù)流程按天調(diào)度多個(gè)Map Reduce任務(wù)分析日志，相關(guān)任務(wù)包括：

　　離線特征挖掘

　　產(chǎn)出Deal(團(tuán)購單)/POI(商家)、用戶和Query等維度的特征供排序模型使用。

　　數(shù)據(jù)清洗標(biāo)注 & 模型訓(xùn)練

　　數(shù)據(jù)清洗去掉爬蟲、作弊等引入的臟數(shù)據(jù);清洗完的數(shù)據(jù)經(jīng)過標(biāo)注后用作模型訓(xùn)練。

　　效果報(bào)表生成

　　統(tǒng)計(jì)生成算法效果指標(biāo)，指導(dǎo)排序改進(jìn)。

　　特征監(jiān)控

　　特征作為排序模型的輸入是排序系統(tǒng)的基礎(chǔ)。特征的錯(cuò)誤異常變動(dòng)會(huì)直接影響排序的效果。特征監(jiān)控主要監(jiān)控特征覆蓋率和取值分布，幫我們及時(shí)發(fā)現(xiàn)相關(guān)問題。

　　在線數(shù)據(jù)處理

　　和離線流程相對應(yīng)，在線流程通過Storm/Spark Streaming等工具對實(shí)時(shí)日志流進(jìn)行分析處理，產(chǎn)出實(shí)時(shí)特征、實(shí)時(shí)報(bào)表和監(jiān)控?cái)?shù)據(jù)，更新在線排序模型。

　　在線服務(wù)(Rank Service)

　　Rank Service接到搜索請求后，會(huì)調(diào)用召回服務(wù)獲取候選POI/Deal集合，根據(jù)A/B測試配置為用戶分配排序策略/模型，應(yīng)用策略/模型對候選集合進(jìn)行排序。

　　下圖是Rank Service內(nèi)部的排序流程。

　　L1 粗粒度排序(快速)

　　使用較少的特征、簡單的模型或規(guī)則對候選集進(jìn)行粗粒度排序。

　　L2 細(xì)粒度排序(較慢)

　　對L1排序結(jié)果的前N個(gè)進(jìn)行細(xì)粒度排序。這一層會(huì)從特征庫加載特征(通過FeatureLoader)，應(yīng)用模型(A/B測試配置分配)進(jìn)行排序。

　　L3 業(yè)務(wù)規(guī)則干預(yù)

　　在L2排序的基礎(chǔ)上，應(yīng)用業(yè)務(wù)規(guī)則/人工干預(yù)對排序進(jìn)行適當(dāng)調(diào)整。

　　Rank Service會(huì)將展示日志記錄到日志收集系統(tǒng)，供在線/離線處理。

　　A/B測試

　　A/B測試的流量切分是在Rank Server端完成的。我們根據(jù)UUID(用戶標(biāo)識(shí))將流量切分為多個(gè)桶(Bucket)，每個(gè)桶對應(yīng)一種排序策略，桶內(nèi)流量將使用相應(yīng)的策略進(jìn)行排序。使用UUID進(jìn)行流量切分，是為了保證用戶體驗(yàn)的一致性。

　　下面是A/B測試配置的一個(gè)簡單示例。

　　代碼如下:

　　{

　　"search": {

　　"NumberOfBuckets": 100,

　　"DefaultStrategy": "Base",

　　"Segments": [

　　{

　　"BeginBucket": 0,

　　"EndBucket": 24,

　　"WhiteList": [123],

　　"Strategy": "Algo-1"

　　},

　　{

　　"BeginBucket": 25,

　　"EndBucket": 49,

　　"WhiteList": [],

　　"Strategy": "Algo-2"

　　}

　　]

　　}

　　}

　　對于不合法的UUID，每次請求會(huì)隨機(jī)分配一個(gè)桶，以保證效果對比不受影響。白名單(White List)機(jī)制能保證配置用戶使用給定的策略，以輔助相關(guān)的測試。

　　除了A/B測試之外，我們還應(yīng)用了Interleaving[7]方法，用于比較兩種排序算法。相較于A/B測試，Interleaving方法對排序算法更靈敏，能通過更少的樣本來比較兩種排序算法之間的優(yōu)劣。Interleaving方法使用較小流量幫助我們快速淘汰較差算法，提高策略迭代效率。

　　特征加載

　　搜索排序服務(wù)涉及多種類型的特征，特征獲取和計(jì)算是Rank Service響應(yīng)速度的瓶頸。我們設(shè)計(jì)了FeatureLoader模塊，根據(jù)特征依賴關(guān)系，并行地獲取和計(jì)算特征，有效地減少了特征加載時(shí)間。實(shí)際業(yè)務(wù)中，并行特征加載平均響應(yīng)時(shí)間比串行特征加載快約20毫秒。

　　FeatureLoader的實(shí)現(xiàn)中我們使用了Akka[8]。如上圖所示，特征獲取和計(jì)算的被抽象和封裝為了若干個(gè)Akka actor，由Akka調(diào)度、并行執(zhí)行。

　　特征和模型

　　美團(tuán)從2013年9月開始在搜索排序上應(yīng)用機(jī)器學(xué)習(xí)方法(Learning to Rank)，并且取得很大的收益。這得益于準(zhǔn)確的數(shù)據(jù)標(biāo)注：用戶的點(diǎn)擊下單支付等行為能有效地反映其偏好。通過在特征挖掘和模型優(yōu)化兩方面的工作，我們不斷地優(yōu)化搜索排序。下面將介紹我們在特征使用、數(shù)據(jù)標(biāo)注、排序算法、Position Bias處理和冷啟動(dòng)問題緩解等方面的工作。

　　特征

　　從美團(tuán)業(yè)務(wù)出發(fā)，特征選取著眼于用戶、Query、Deal/POI和搜索上下文四個(gè)維度。

　　用戶維度

　　包括挖掘得到的品類偏好、消費(fèi)水平和地理位置等。

　　Query維度

　　包括Query長度、歷史點(diǎn)擊率、轉(zhuǎn)化率和類型(商家詞/品類詞/地標(biāo)詞)等。

　　Deal/POI維度

　　包括Deal/POI銷量、價(jià)格、評(píng)價(jià)、折扣率、品類和歷史轉(zhuǎn)化率等。

　　上下文維度

　　包括時(shí)間、搜索入口等。

　　此外，有的特征來自于幾個(gè)維度之間的相互關(guān)系：用戶對Deal/POI的點(diǎn)擊和下單等行為、用戶與POI的距離等是決定排序的重要因素;Query和Deal/POI的文本相關(guān)性和語義相關(guān)性是模型的關(guān)鍵特征。

　　模型

　　Learning to Rank應(yīng)用中，我們主要采用了Pointwise方法。采用用戶的點(diǎn)擊、下單和支付等行為來進(jìn)行正樣本的標(biāo)注。從統(tǒng)計(jì)上看，點(diǎn)擊、下單和支付等行為分別對應(yīng)了該樣本對用戶需求的不同的匹配程度，因此對應(yīng)的樣本會(huì)被當(dāng)做正樣本，且賦予不斷增大的權(quán)重。

　　線上運(yùn)行著多種不同類型模型，主要包括：

　　Gradient boosting decision/regression tree(GBDT/GBRT)

　　GBDT是LTR中應(yīng)用較多的非線性模型。我們開發(fā)了基于Spark的GBDT工具，樹擬合梯度的時(shí)候運(yùn)用了并行方法，縮短訓(xùn)練時(shí)間。GBDT的樹被設(shè)計(jì)為三叉樹，作為一種處理特征缺失的方法。

　　選擇不同的損失函數(shù)，boosting tree方法可以處理回歸問題和分類問題。應(yīng)用中，我們選用了效果更好的logistic likelihood loss，將問題建模為二分類問題。

　　Logistic Regression(LR)

　　參考Facebook的paper[3]，我們利用GBDT進(jìn)行部分LR特征的構(gòu)建。用FTRL算法來在線訓(xùn)練LR模型。

　　對模型的評(píng)估分為離線和線上兩部分。離線部分我們通過AUC(Area Under the ROC Curve)和MAP(Mean Average Precision)來評(píng)價(jià)模型，線上則通過A/B測試來檢驗(yàn)?zāi)Ｐ偷膶?shí)際效果，兩項(xiàng)手段支撐著算法不斷的迭代優(yōu)化。

　　冷啟動(dòng)

　　在我們的搜索排序系統(tǒng)中，冷啟動(dòng)問題表現(xiàn)為當(dāng)新的商家、新的團(tuán)購單錄入或新的用戶使用美團(tuán)時(shí)，我們沒有足夠的數(shù)據(jù)用來推測用戶對產(chǎn)品的喜好。商家冷啟動(dòng)是主要問題，我們通過兩方面手段來進(jìn)行緩解。一方面，在模型中引入了文本相關(guān)性、品類相似度、距離和品類屬性等特征，確保在沒有足夠展示和反饋的前提下能較為準(zhǔn)確地預(yù)測;另一方面，我們引入了Explore&Exploit機(jī)制，對新商家和團(tuán)單給予適度的曝光機(jī)會(huì)，以收集反饋數(shù)據(jù)并改善預(yù)測。

　　Position Bias

　　在手機(jī)端，搜索結(jié)果的展現(xiàn)形式是列表頁，結(jié)果的展示位置會(huì)對用戶行為產(chǎn)生很大的影響。在特征挖掘和訓(xùn)練數(shù)據(jù)標(biāo)注當(dāng)中，我們考慮了展示位置因素引入的偏差。例如CTR(click-through-rate)的統(tǒng)計(jì)中，我們基于Examination Model，去除展示位置帶來的影響。

　　線上篇總結(jié)

　　線上篇主要介紹了美團(tuán)搜索排序系統(tǒng)線上部分的結(jié)構(gòu)、算法和主要模塊。在后續(xù)文章里，我們會(huì)著重介紹排序系統(tǒng)離線部分的工作。

　　一個(gè)完善的線上線下系統(tǒng)是排序優(yōu)化得以持續(xù)進(jìn)行的基礎(chǔ)�；�于業(yè)務(wù)對數(shù)據(jù)和模型上的不斷挖掘是排序持續(xù)改善的動(dòng)力。我們?nèi)栽谔剿鳌?/p>

　　二、線下篇

　　針對美團(tuán)90%的交易發(fā)生在移動(dòng)端的業(yè)務(wù)特點(diǎn)，我們實(shí)現(xiàn)了一套適用于O2O業(yè)務(wù)的搜索排序技術(shù)方案，已在許多產(chǎn)品和子行業(yè)中得到應(yīng)用。在之前的線上篇中，我們已經(jīng)介紹了服務(wù)的框架、排序算法等。本文為線下篇，主要講述數(shù)據(jù)清洗、特征矩陣、監(jiān)控系統(tǒng)、模型訓(xùn)練和效果評(píng)估等模塊。

　　數(shù)據(jù)清洗

　　數(shù)據(jù)清洗的主要工作是為離線模型訓(xùn)練準(zhǔn)備標(biāo)注數(shù)據(jù)，同時(shí)洗掉不合法數(shù)據(jù)。數(shù)據(jù)清洗的數(shù)據(jù)源主要有團(tuán)購的曝光、點(diǎn)擊和下單。

　　整個(gè)數(shù)據(jù)清洗的流程如下：

　　序列化

　　曝光、點(diǎn)擊和下單數(shù)據(jù)從Hive表中讀取，采用schema的處理方式，可以直接根據(jù)日志字段名來抽取相應(yīng)的字段，不受日志字段增加或者減少的影響。

　　曝光日志存儲(chǔ)了一次用戶行為的詳細(xì)信息，包括城市、地理位置、篩選條件及一些行為特征;點(diǎn)擊日志主要記錄了用戶點(diǎn)擊的POIID、點(diǎn)擊時(shí)間;下單日志記錄了用戶下單的POIID、下單時(shí)間和下單的金額。數(shù)據(jù)清洗模塊根據(jù)配置文件從數(shù)據(jù)源中抽取需要的字段，進(jìn)行序列化(Serialization)之后存儲(chǔ)在HDFS上。

　　序列化的過程中，如果日志字段不合法或者單一用戶曝光、點(diǎn)擊或下單超出設(shè)定的閾值，相關(guān)日志都會(huì)被清洗掉，避免數(shù)據(jù)對模型訓(xùn)練造成影響。

　　數(shù)據(jù)標(biāo)注

　　數(shù)據(jù)序列化之后在HDFS上保存三份文本文件，分別是曝光(Impression)、點(diǎn)擊(Click)和下單(Order)。數(shù)據(jù)標(biāo)注模塊根據(jù)globalid(一次搜索的全局唯一標(biāo)示，類似于sessionid)和相應(yīng)的團(tuán)購id為key，將曝光、點(diǎn)擊和下單關(guān)聯(lián)起來，最終生成一份標(biāo)注好是否被點(diǎn)擊、下單、支付的標(biāo)注數(shù)據(jù)。同時(shí)這份標(biāo)注數(shù)據(jù)攜帶了本次展現(xiàn)的詳細(xì)特征信息。

　　數(shù)據(jù)標(biāo)注通過一次Map/Reduce來完成。

　　Map階段：Map的輸入為曝光、點(diǎn)擊和下單三種HDFS數(shù)據(jù)。 用三個(gè)Mapper分別處理三種日志。數(shù)據(jù)分發(fā)的key為globalid。其中，如果點(diǎn)擊和下單數(shù)據(jù)中的globalid字段為空("")，則丟棄該條日志(因?yàn)間lobalid為空無法和曝光日志join，會(huì)出現(xiàn)誤標(biāo)注)。

　　Reduce階段：Reduce接收的key為globalid, values為具有相同globalid的曝光、點(diǎn)擊、下單數(shù)據(jù)List，遍歷該List, 如果

　　日志類型為曝光日志，則標(biāo)記該globalid對應(yīng)的曝光日志存在(imp_exist=true)。

　　日志類型為點(diǎn)擊日志，則將曝光日志的clicked字段置為1。

　　日志類型為下單日志，則將曝光日志的ordered字段置為1。

　　日志類型為下單日志，如果pay_account字段>0， 則將曝光日志的paid字段置為1。

　　遍歷List之后，如果imp_exist == true, 則將標(biāo)注好的數(shù)據(jù)寫入HDFS， 否則丟棄。

　　數(shù)據(jù)標(biāo)注的流程圖如下：

　　特征矩陣

　　特征矩陣的作用是提供豐富的特征集合，以方便在線和離線特征調(diào)研使用。

　　特征矩陣的生成

　　特征矩陣的生成框架為：

　　下面我們來詳細(xì)說明一下流程。

　　基礎(chǔ)特征按來源可分為三部分：

　　1、Hive表：有一些基礎(chǔ)特征存儲(chǔ)在Hive標(biāo)注，如POI的名字、品類、團(tuán)購數(shù)等。

　　2、離線計(jì)算：一些特征需要積累一段時(shí)間才能統(tǒng)計(jì)，如POI的點(diǎn)擊率、銷量等，這部分通過積累歷史數(shù)據(jù)，然后經(jīng)過Map/Reduce處理得到。

　　3、HDFS：特征矩陣可能融合第三方服務(wù)的特征，一般第三方服務(wù)將產(chǎn)生的特征按照約定的格式存儲(chǔ)在HDFS上。

　　數(shù)據(jù)源統(tǒng)一格式為： poiid/dealid/bizareaid 't' name1:value1't' name2:value2...

　　特征合并模塊，將所有來源合并為一個(gè)大文件，通過feature conf配置的特征和特征順序，將特征序列化，然后寫入Hive表。

　　特征監(jiān)控模塊每天監(jiān)控特征的分布等是否異常。 特征矩陣的特征每日更新。

　　添加新的特征來源，只需要按照約定的格式生成數(shù)據(jù)源，配置路徑，可自動(dòng)添加。

　　添加新特征，在feature conf文件末尾添加相應(yīng)的特征名，特征名字和數(shù)據(jù)源中的特征name保持一致，最后修改相應(yīng)的特征Hive表結(jié)構(gòu)。

　　特征矩陣的使用

　　特征矩陣的使用框架為：

　　我們來詳細(xì)說明一下流程。

　　其中特征矩陣既提供在線的特征倉庫，又可提供離線的特征調(diào)研。線上服務(wù)需要大量的特征來對POI/DEAL質(zhì)量打分，特征分散會(huì)造成服務(wù)取用特征很耗時(shí)，特征矩陣將特征整合，很好的解決了特征耗時(shí)的問題。一般調(diào)研一個(gè)新特征需要積累一段時(shí)間的數(shù)據(jù)，將特征放入特征矩陣，

　　然后和已有的數(shù)據(jù)進(jìn)行融合，可方便的構(gòu)造包含新特征的訓(xùn)練數(shù)據(jù)。下面我們分別來看一下在線、離線和特征融合的流程。

　　在線使用

　　在線方面的使用主要是方便特征的獲取，將線上需要的特征納入特征矩陣統(tǒng)一管理，通過配置文件讀取特征矩陣的特征，封裝成Proto Buffers寫入Medis(美團(tuán)自主構(gòu)建的Redis集群，支持分布式和容錯(cuò))，通過Medis key批量讀取該key對應(yīng)的特征，減少讀取Medis的次數(shù)，從而縮減特征獲取的時(shí)間，提高系統(tǒng)的性能。

　　特征矩陣在線使用框架如下：

　　流程說明：

　　序列化模塊通過特征配置文件從特征矩陣抽取需要的特征，調(diào)用protoBuffer Lib將特征封裝成protoBuffer的格式，寫入Medis。

　　線上通過featureLoader服務(wù)從Medis讀取數(shù)據(jù)，然后通過protoBufferLib反序列化數(shù)據(jù)，取到相應(yīng)的特征值。

　　離線使用

　　離線方面的使用主要是方便調(diào)研新特征。如果從線上獲取新特征，由于需要積累訓(xùn)練數(shù)據(jù)，特征調(diào)研的周期會(huì)變長;而如果將待調(diào)研的特征納入特征矩陣中，可以很方便地通過離線的方法調(diào)研特征的有效性，極大的縮短了特征調(diào)研的周期，提高開發(fā)效率和模型迭代的速度。

　　特征矩陣離線使用框架如下：

　　其中，從特征矩陣取出待調(diào)研的新特征，格式化為 joinKey 't' FeatureName:FeatureValue， 例如 12345 't' CTR:0.123，joinkey為poiid, 新特征為CTR，特征值為0.123。格式化后的新特征文件和標(biāo)注好的rerank日志作為輸入，經(jīng)過Map/Reduce處理生成新的標(biāo)注日志，用于模型訓(xùn)練。

　　特征融合

　　特征融合作用于離線特征調(diào)研，上篇我們提到數(shù)據(jù)標(biāo)準(zhǔn)會(huì)輸出擁有豐富特征的標(biāo)注日志，特征融合的目的在于將待調(diào)研的新特征通過某一個(gè)joinkey 合并到在線特征列表中，從而在模型訓(xùn)練中使用該特征。

　　特征融合的框架：

　　流程說明： 特征融合模塊可以指定任意一個(gè)或者多個(gè)join key，將離線特征加入在線特征列表。

　　監(jiān)控系統(tǒng)

　　監(jiān)控系統(tǒng)的目的是確保在線和離線任務(wù)的正常運(yùn)行。監(jiān)控系統(tǒng)按照作用范圍的不同又分為線上監(jiān)控和離線監(jiān)控。

　　線上監(jiān)控

　　線上監(jiān)控主要是監(jiān)測收集的在線特征日志是否正常，線上特征監(jiān)控主要檢測特征的覆蓋度、閾值范圍、分布異常三方面。

　　三方面的監(jiān)控主要分以下幾個(gè)場景：

　　覆蓋度：監(jiān)控特征的數(shù)據(jù)源是否存在或者有數(shù)據(jù)丟失。

　　閾值范圍：監(jiān)控特征的閾值是否符合預(yù)期，防止因?yàn)樯�成特征的算法改變或者在線計(jì)算方法的不同等因素造成特征的最大值或者最小值發(fā)生比較明顯的變化，導(dǎo)致特征不可用。

　　分布異常：監(jiān)控特征值的分布是否符合預(yù)期，主要防止因?yàn)楂@取不到特征，使得特征都使用了默認(rèn)值，而又沒有及時(shí)發(fā)現(xiàn)，導(dǎo)致線上模型預(yù)估出現(xiàn)偏差。分布異常主要用到了卡方距離[3]。

　　特征覆蓋度監(jiān)控效果圖：

　　下圖是用戶到POI距離的覆蓋度監(jiān)控。從圖中可以直觀的看出，該特征的覆蓋度約為75%，也即只有75%的用戶能得到距離特征，另外25%可能沒有開手機(jī)定位服務(wù)或者得不到POI的坐標(biāo)。75%的覆蓋度是一個(gè)比較穩(wěn)定的指標(biāo)，如果覆蓋度變的很高或者很低都說明我們的系統(tǒng)出現(xiàn)了問題，而我們的監(jiān)控系統(tǒng)能及時(shí)發(fā)現(xiàn)這種問題。

　　離線監(jiān)控

　　離線監(jiān)控主要檢測兩方面：1、離線任務(wù)是否按時(shí)完成及生成的數(shù)據(jù)是否正確。 2、特征矩陣特征的有效性。

　　當(dāng)離線定時(shí)任務(wù)多達(dá)數(shù)十個(gè)的時(shí)候，很難每天去逐個(gè)檢查每個(gè)任務(wù)是否如期完成，這時(shí)候離線任務(wù)監(jiān)控的重要性就凸顯出來。當(dāng)前離線監(jiān)控可以根據(jù)配置文件，監(jiān)控需要關(guān)注的任務(wù)，以及這些任務(wù)生成的數(shù)據(jù)是否正常。如果不正常則發(fā)出報(bào)警給任務(wù)負(fù)責(zé)人，達(dá)到任務(wù)失敗能夠及時(shí)處理的目的。

　　特征矩陣監(jiān)控的目的與在線特征的監(jiān)控目的一樣，監(jiān)控指標(biāo)也相同，所不同的是因?yàn)楸O(jiān)控?cái)?shù)據(jù)的獲取不同，監(jiān)控實(shí)現(xiàn)也不盡相同，這里不再贅述。

　　模型調(diào)研

　　模型訓(xùn)練

　　模型訓(xùn)練框架支持多種模型的訓(xùn)練，將訓(xùn)練數(shù)據(jù)格式化為模型需要的輸入格式。修改模型訓(xùn)練的配置文件，就可以使用該框架訓(xùn)練模型了。

　　模型訓(xùn)練框架：

　　其中，頂層是訓(xùn)練數(shù)據(jù)和測試數(shù)據(jù)的輸入層，該層是原始訓(xùn)練和測試數(shù)據(jù)。

　　中間是模型訓(xùn)練的框架，框架支持多個(gè)配置項(xiàng)，包括配置模型算法、相應(yīng)的參數(shù)、數(shù)據(jù)源的輸入及模型的輸出等。

　　底層是多種模型的實(shí)現(xiàn)，算法之前相互獨(dú)立，每種算法封裝成獨(dú)立的jar，提供給模型訓(xùn)練框架使用，目前支持的算法包括GBDT[4]、FTRL[5]。

　　為了實(shí)現(xiàn)模型的快速迭代，模型訓(xùn)練支持在Spark上運(yùn)行。

　　效果評(píng)估

　　模型的效果評(píng)估主要是對比新模型和老模型的效果，以評(píng)估結(jié)果來決定是否更新線上模型。

　　我們的系統(tǒng)支持兩種效果指標(biāo)的評(píng)估，一種是AUC[1]，另一種是MAP。

　　MAP(Mean Average Precision)[2]是一種對搜索排序結(jié)果好壞評(píng)估的指標(biāo)。

　　Prec@K 的定義： 設(shè)定閾值K，計(jì)算排序結(jié)果topK的相關(guān)度。

　　注：綠色表示搜索結(jié)果與搜索詞相關(guān)，紅色表示不相關(guān)。

　　AP(Average Precision)的定義： Average Precision = average of Prec@K

　　AP作為排序好壞的直觀理解

　　灰色表示與搜索相關(guān)的結(jié)果，在團(tuán)購中表示被點(diǎn)擊的DEAL，從召回結(jié)果看Ranking#1要好于Ranking#2，反映在MAP指標(biāo)上，Ranking#1的MAP值大于Ranking#2的MAP值。

　　所以可以簡單地使用AP值來衡量模型排序的好壞。

　　MAP的計(jì)算

　　對于多個(gè)query的搜索結(jié)果，MAP為這些搜索結(jié)果AP的均值。

　　實(shí)驗(yàn)結(jié)果表明MAP作為排序指標(biāo)，對模型好壞的評(píng)估起到很好的指導(dǎo)作用。

　　在AUC的近似計(jì)算方法中，主要考慮有多少對正負(fù)樣本組合中正樣本的得分大于負(fù)樣本的得分，與正樣本在排序中的具體位置沒有絕對的關(guān)系。當(dāng)正負(fù)樣本的分布變化，如某一小部分正樣本得分變大，大部分正樣本得分變小，那么最終計(jì)算的AUC值可能沒有發(fā)生變化，但排序的結(jié)果卻發(fā)生了很大變化(大部分用戶感興趣的單子排在了后邊)。

　　因此AUC指標(biāo)沒法直觀評(píng)估人對排序好壞的感受。