離線指標和線上指標不一致是個常見的問題，花了很大力氣好不容易離線auc漲了不少，上線一看效果ctr和cpm反而下降。本文例舉幾種可能的原因和解決辦法。
1. 特徵/數據出現穿越
一般就是使用了和label強相關的特徵導致的數據泄漏。這種問題一般相對好查，很多時候在離線階段就能發現。明顯的表現就是訓練集和測試集差異比較大
2. 線上線下特徵不一致
我所知，這種情況是導致離線漲在線跌或者沒效果的最常見情況。
首先是代碼不一致，例如，離線對用戶特徵的加工處理採用scala/python處理，抽取用戶最近的50個行爲，在線特徵抽取用c++實現只用了30個。只要離線和在線用不同的代碼抽取就很容易存在這種代碼帶來的不一致。
另外一種線上線下不一致，是由於數據的不一致導致。這在離線拼接樣本和特徵的pipeline中比較常見。一般離線特徵都是按照天處理的，考慮各種數據pipeline的流程，處理時間一般都會有延遲，離線特徵處理完之後導到線上供線上模型預估時請求使用。
這種不一致都是怎麼產生的？例如4月15日這天，線上預估請求用的特徵是4月14號的特徵數據。到了4月16日，特徵pipeline開始處理數據，到了凌晨4點，離線特徵處理完了導到線上。那麼在4月16日0點-4點，這段時間線上請求的特徵使用的是老的特徵數據，也就是4月14日的特徵數據。4月16日4點-24點，線上特徵使用的是4月15日的數據。而在離線樣本生成過程中，到了4月17日0點，如果是按天拼接的，那麼4月16號這天的所有樣本，都會使用4月15日的特徵。
這樣，4月16日0-4日的樣本，在離線樣本拼接的階段，使用的是4月15日的特徵數據，而在線上請求特徵的時候使用的還是4月14日的特徵。特徵pipeline流程處理越長，這種不一致會越大。
要嚴格保證線上線下的特徵一致性，最根本的方法就是同一套代碼和數據源抽取特徵，業內目前通用的方法就是，在線實時請求打分的時候落地實時特徵，訓練的時候就沒有特徵拼接的流程，只需要關聯label，生成正負樣本即可
3. 數據分佈的不一致
如果仔細排查，既不存在數據泄漏，也沒有出現不一致的問題，離線auc明明就是漲了很多，線上就是下降，而且是離線漲的越多，線上下降越多，還有一種可能就是數據的不一致，也就是數據的“冰山效應”----離線訓練用的是有偏的冰山上的數據，而在線上預估的時候，需要預測的是整個冰山的數據，包括大量冰面以下的數據！
這種情況其實在推薦系統裏非常常見，但是往往非常的隱蔽，一時半會很難發現。我們看下面這張圖。左邊是我們的Baseline，綠色的表示正樣本，紅色表示負樣本，灰色部分表示線上由於推薦系統的“偏見”（預估分數較低），導致根本沒有展現過的數據。
離線階段，我們通過各種優化，新模型的離線評估表現更好了，例如圖中第二列，可以發現第4個綠色的正樣本和第7個綠色的正樣本排到了第3和第6的位置，離線的auc指標漲了。
到了真正線上的預估也就是第三列，發現對於這部分離線見過的樣本，模型的預估序並未改變。但是新模型給了灰色沒有見過的數據更高的預估分數，這部分數據一旦表現不好，很可能造成我們前面說的情況，離線（第二列）評估指標明明漲了不少，在線（第三列）評估指標ctr卻下降。
這種情況也不是必現的，在LR以特徵工程爲主要迭代的時代很少見。主要的原因是模型的前後迭代差異並不大。新模型對比老模型最主要的特點是新加入了一部分特徵，往往模型的打分差異並不大，從圖中第二列到第三列，原來那些冰山下的數據也就是舊模型預估分數偏低的部分，在新模型中能夠脫穎而出拿到很高的預估分數的概率並不高。
而在模型有較大變化的時候，例如lr->樹模型，lr->深度模型，不同網絡結構的深度模型變化，這種情況容易出現，原因就是新舊模型的變化較大，預估分數變化也較大。
舉一個簡單的例子，假設我們的baseline是熱門模型，樣本都是老的熱門模型生產出的熱門樣本，這個時候我們用簡單的lr模型去擬合，到了真正的線上預估的時候，對於大量之前沒見過的非熱門的數據，模型自然很難預估好。沒有足夠好的樣本，模型也很難學到足夠有用的信息。