背景

針對美團90%的交易發生在移動端的業務特點，我們實現了一套適用於O2O業務的搜索排序技術方案，已在許多產品和子行業中得到應用。在之前的線上篇中，我們已經介紹了服務的框架、排序算法等。本文爲線下篇，主要講述數據清洗、特徵矩陣、監控系統、模型訓練和效果評估等模塊。

數據清洗

數據清洗的主要工作是爲離線模型訓練準備標註數據，同時洗掉不合法數據。數據清洗的數據源主要有團購的曝光、點擊和下單。
整個數據清洗的流程如下：

序列化
曝光、點擊和下單數據從Hive表中讀取，採用schema的處理方式，可以直接根據日誌字段名來抽取相應的字段，不受日誌字段增加或者減少的影響。
曝光日誌存儲了一次用戶行爲的詳細信息，包括城市、地理位置、篩選條件及一些行爲特徵；點擊日誌主要記錄了用戶點擊的POIID、點擊時間；下單日誌記錄了用戶下單的POIID、下單時間和下單的金額。數據清洗模塊根據配置文件從數據源中抽取需要的字段，進行序列化（Serialization）之後存儲在HDFS上。
序列化的過程中，如果日誌字段不合法或者單一用戶曝光、點擊或下單超出設定的閾值，相關日誌都會被清洗掉，避免數據對模型訓練造成影響。
數據標註
數據序列化之後在HDFS上保存三份文本文件，分別是曝光（Impression）、點擊（Click）和下單（Order）。數據標註模塊根據globalid（一次搜索的全局唯一標示，類似於sessionid）和相應的團購id爲key，將曝光、點擊和下單關聯起來，最終生成一份標註好是否被點擊、下單、支付的標註數據。同時這份標註數據攜帶了本次展現的詳細特徵信息。
數據標註通過一次Map/Reduce來完成。
Map階段：Map的輸入爲曝光、點擊和下單三種HDFS數據。用三個Mapper分別處理三種日誌。數據分發的key爲globalid。其中，如果點擊和下單數據中的globalid字段爲空（""），則丟棄該條日誌（因爲globalid爲空無法和曝光日誌join，會出現誤標註）。
Reduce階段：Reduce接收的key爲globalid, values爲具有相同globalid的曝光、點擊、下單數據List，遍歷該List, 如果
日誌類型爲曝光日誌，則標記該globalid對應的曝光日誌存在（imp_exist=true）。
日誌類型爲點擊日誌，則將曝光日誌的clicked字段置爲1。
日誌類型爲下單日誌，則將曝光日誌的ordered字段置爲1。
日誌類型爲下單日誌，如果pay_account字段>0，則將曝光日誌的paid字段置爲1。
遍歷List之後，如果imp_exist == true, 則將標註好的數據寫入HDFS，否則丟棄。
數據標註的流程圖如下：

特徵矩陣

特徵矩陣的作用是提供豐富的特徵集合，以方便在線和離線特徵調研使用。

特徵矩陣的生成

特徵矩陣的生成框架爲：

下面我們來詳細說明一下流程。
基礎特徵按來源可分爲三部分：
1、Hive表：有一些基礎特徵存儲在Hive標註，如POI的名字、品類、團購數等。
2、離線計算：一些特徵需要積累一段時間才能統計，如POI的點擊率、銷量等，這部分通過積累歷史數據，然後經過Map/Reduce處理得到。
3、HDFS：特徵矩陣可能融合第三方服務的特徵，一般第三方服務將產生的特徵按照約定的格式存儲在HDFS上。
數據源統一格式爲： poiid/dealid/bizareaid '\t' name1:value1'\t' name2:value2...
特徵合併模塊，將所有來源合併爲一個大文件，通過feature conf配置的特徵和特徵順序，將特徵序列化，然後寫入Hive表。
特徵監控模塊每天監控特徵的分佈等是否異常。特徵矩陣的特徵每日更新。
添加新的特徵來源，只需要按照約定的格式生成數據源，配置路徑，可自動添加。
添加新特徵，在feature conf文件末尾添加相應的特徵名，特徵名字和數據源中的特徵name保持一致，最後修改相應的特徵Hive表結構。

特徵矩陣的使用

特徵矩陣的使用框架爲：

我們來詳細說明一下流程。
其中特徵矩陣既提供在線的特徵倉庫，又可提供離線的特徵調研。線上服務需要大量的特徵來對POI/DEAL質量打分，特徵分散會造成服務取用特徵很耗時，特徵矩陣將特徵整合，很好的解決了特徵耗時的問題。一般調研一個新特徵需要積累一段時間的數據，將特徵放入特徵矩陣，
然後和已有的數據進行融合，可方便的構造包含新特徵的訓練數據。下面我們分別來看一下在線、離線和特徵融合的流程。

在線使用
在線方面的使用主要是方便特徵的獲取，將線上需要的特徵納入特徵矩陣統一管理，通過配置文件讀取特徵矩陣的特徵，封裝成Proto Buffers寫入Medis（美團自主構建的Redis集羣，支持分佈式和容錯），通過Medis key批量讀取該key對應的特徵，減少讀取Medis的次數，從而縮減特徵獲取的時間，提高系統的性能。
特徵矩陣在線使用框架如下：

流程說明：

序列化模塊通過特徵配置文件從特徵矩陣抽取需要的特徵，調用protoBuffer Lib將特徵封裝成protoBuffer的格式，寫入Medis。
線上通過featureLoader服務從Medis讀取數據，然後通過protoBufferLib反序列化數據，取到相應的特徵值。

離線使用
離線方面的使用主要是方便調研新特徵。如果從線上獲取新特徵，由於需要積累訓練數據，特徵調研的週期會變長；而如果將待調研的特徵納入特徵矩陣中，可以很方便地通過離線的方法調研特徵的有效性，極大的縮短了特徵調研的週期，提高開發效率和模型迭代的速度。
特徵矩陣離線使用框架如下：

其中，從特徵矩陣取出待調研的新特徵，格式化爲 joinKey '\t' FeatureName:FeatureValue，例如 12345 '\t' CTR:0.123，joinkey爲poiid, 新特徵爲CTR，特徵值爲0.123。格式化後的新特徵文件和標註好的rerank日誌作爲輸入，經過Map/Reduce處理生成新的標註日誌，用於模型訓練。

特徵融合
特徵融合作用於離線特徵調研，上篇我們提到數據標準會輸出擁有豐富特徵的標註日誌，特徵融合的目的在於將待調研的新特徵通過某一個joinkey 合併到在線特徵列表中，從而在模型訓練中使用該特徵。
特徵融合的框架：

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

監控系統

監控系統的目的是確保在線和離線任務的正常運行。監控系統按照作用範圍的不同又分爲線上監控和離線監控。

線上監控
線上監控主要是監測收集的在線特徵日誌是否正常，線上特徵監控主要檢測特徵的覆蓋度、閾值範圍、分佈異常三方面。
三方面的監控主要分以下幾個場景：
覆蓋度：監控特徵的數據源是否存在或者有數據丟失。
閾值範圍：監控特徵的閾值是否符合預期，防止因爲生成特徵的算法改變或者在線計算方法的不同等因素造成特徵的最大值或者最小值發生比較明顯的變化，導致特徵不可用。
分佈異常：監控特徵值的分佈是否符合預期，主要防止因爲獲取不到特徵，使得特徵都使用了默認值，而又沒有及時發現，導致線上模型預估出現偏差。分佈異常主要用到了卡方距離[3]。
特徵覆蓋度監控效果圖：
下圖是用戶到POI距離的覆蓋度監控。從圖中可以直觀的看出，該特徵的覆蓋度約爲75%，也即只有75%的用戶能得到距離特徵，另外25%可能沒有開手機定位服務或者得不到POI的座標。75%的覆蓋度是一個比較穩定的指標，如果覆蓋度變的很高或者很低都說明我們的系統出現了問題，而我們的監控系統能及時發現這種問題。
離線監控
離線監控主要檢測兩方面：1、離線任務是否按時完成及生成的數據是否正確。 2、特徵矩陣特徵的有效性。
當離線定時任務多達數十個的時候，很難每天去逐個檢查每個任務是否如期完成，這時候離線任務監控的重要性就凸顯出來。當前離線監控可以根據配置文件，監控需要關注的任務，以及這些任務生成的數據是否正常。如果不正常則發出報警給任務負責人，達到任務失敗能夠及時處理的目的。
特徵矩陣監控的目的與在線特徵的監控目的一樣，監控指標也相同，所不同的是因爲監控數據的獲取不同，監控實現也不盡相同，這裏不再贅述。

模型調研

模型訓練

模型訓練框架支持多種模型的訓練，將訓練數據格式化爲模型需要的輸入格式。修改模型訓練的配置文件，就可以使用該框架訓練模型了。
模型訓練框架：

其中，頂層是訓練數據和測試數據的輸入層，該層是原始訓練和測試數據。
中間是模型訓練的框架，框架支持多個配置項，包括配置模型算法、相應的參數、數據源的輸入及模型的輸出等。
底層是多種模型的實現，算法之前相互獨立，每種算法封裝成獨立的jar，提供給模型訓練框架使用，目前支持的算法包括GBDT[4]、FTRL[5]。
爲了實現模型的快速迭代，模型訓練支持在Spark上運行。

效果評估

模型的效果評估主要是對比新模型和老模型的效果，以評估結果來決定是否更新線上模型。
我們的系統支持兩種效果指標的評估，一種是AUC[1]，另一種是MAP。

MAP(Mean Average Precision)[2]是一種對搜索排序結果好壞評估的指標。

Prec@K 的定義：設定閾值K，計算排序結果topK的相關度。

注：綠色表示搜索結果與搜索詞相關，紅色表示不相關。
AP（Average Precision）的定義： Average Precision = average of Prec@K
AP作爲排序好壞的直觀理解

灰色表示與搜索相關的結果，在團購中表示被點擊的DEAL，從召回結果看Ranking#1要好於Ranking#2，反映在MAP指標上，Ranking#1的MAP值大於Ranking#2的MAP值。
所以可以簡單地使用AP值來衡量模型排序的好壞。
MAP的計算

對於多個query的搜索結果，MAP爲這些搜索結果AP的均值。
實驗結果表明MAP作爲排序指標，對模型好壞的評估起到很好的指導作用。
在AUC的近似計算方法中，主要考慮有多少對正負樣本組合中正樣本的得分大於負樣本的得分，與正樣本在排序中的具體位置沒有絕對的關係。當正負樣本的分佈變化，如某一小部分正樣本得分變大，大部分正樣本得分變小，那麼最終計算的AUC值可能沒有發生變化，但排序的結果卻發生了很大變化（大部分用戶感興趣的單子排在了後邊）。
因此AUC指標沒法直觀評估人對排序好壞的感受。