宣云兒，攜程酒店排序算法工程師，主要負責酒店排序相關的算法邏輯方案設計實施。目前主要的興趣在于排序學習、強化學習等領域的理論與應用。

前言

目前攜程酒店絕大部分排序業務中所涉及的問題，基本可以通過應用排序學習完成。而其中模型訓練步驟中所需的訓練數據集，一般是通過線下收集數據來完成的。

然而在實際當中，往往存在業務新增或者業務變更，這就使得使用歷史數據訓練的模型，并不能很好地用于變更后的應用場景。形成該問題的主要原因，是過去所收集的數據與實際排序場景并不一致。

為了應對類似問題，我們嘗試在城市歡迎度排序場景中引入了強化學習。通過實驗發現，增加強化學習后，能夠在一定程度上提高排序的質量。

一、實際面臨的問題

在目前大部分的實踐中，我們解決排序問題所訴諸的辦法，基本都可以歸為傳統意義上的“排序學習”（learning to rank， L2R）。排序學習基本的建模過程，是通過收集數據，構建特征，選擇模型，訓練模型等步驟實現。

其中第一步收集數據，往往是以離線的方式完成。常見方法是通過埋點服務器收集用戶行為數據，再進行模型訓練數據的構建。

在收集數據的時候，一般存在一個假設要求：即我們所收集到的數據是和總體數據分布保持一致的，模型只要在這個基礎上進行訓練，所得到的結果在實際線上業務使用時是可靠的。我們暫且稱其為“分布一致假設”。

當業務體量足夠大、收集數據足夠多時，一般會認為這一假設是成立的。然而在實際當中，要滿足分布一致假設會面臨一系列的挑戰。這其中包含且不限于各種埋點服務準確性難以保證，數據處理中無法完全避免的數據損失，以及收集數據時間空間上的限制等問題。

此外，當排序應用的目標是預測現有數據集中不存在的情況時，傳統的排序學習將變得無能為力。舉一個商品排序的例子。在排序list結果展現中，我們設置業務限制：top10的item只能是1000元以上的商品。假設現在的排序目標為點擊率（CTR），從現有數據進行模型訓練后，模型很難準確地告訴我們一件10元商品出現在top10時它的CTR是多少，因為它根本沒有在這個位置出現過。

這種“預測不曾在歷史中出現的事件”的需求在實際當中并不少見：在多指標融合的排序指標中（例如排序指標是要在CTR和轉化率CVR之間做加權），如何設置不同子指標之間的權重就是一例。

由于新的權重下得到的數據分布是不存在現有的數據集當中的，因此無法充分知曉用戶在新的排序結果下的行為結果，在新權重的條件下訓練一個模型滿足業務目標也就無從談起了。

更重要的是，實際上我們很難充分收集數據：試想，對于同一個用戶，難道我們要將100種不同的權重參數所得到的排序結果，都一一展現給同一個用戶，然后收集其給出的行為結果么？答案當然是否定的。

攜程酒店排序業務中，同樣也存在這樣的問題。具體來說有兩點最為明顯：

1）對于內外網比價結果為優勢或者劣勢的酒店，我們是否應該調整該酒店的排序位置、以及應該如何調整。這個問題的答案并不是直觀的，因為對不同用戶來說，可能會存在不同的偏好，以及對于不同酒店來說，這一個問題的結果也可能是不同的。

2）對于歷史上由于業務設置的原因排名靠后的酒店，在個性化排序或者廣告業務中若將其位置提前，如何準確預測用戶對這些酒店的行為。

這兩個業務需求，都可以歸結為前面提到的無法預先收集同分布數據集的問題，傳統的L2R并不能很好地進行支持解決。

二、可能的解決方案

我們再仔細考慮下“將100個不同排序結果丟給同一個用戶”這種做法的弊端。毫無疑問，這種暴力的做法雖然似乎能夠充分收集數據，但事實上是有著極高的成本：極為傷害用戶體驗。

然而，為了能夠讓模型有機會預測那些未知的情況，又必然是需要一定的“隨機探索”，只有這樣我們才能知道實際中用戶的反饋。因此，隨機探索所帶來的短期損失是無法完全避免的，但最終的目標是在于探索所帶來的收益能夠彌補并超過其帶來的損失。

而“強化學習”的目標，恰好和我們的需求不謀而合。

三、談談RL的背景，它解決的問題

為了方便后的表述，先簡單介紹下強化學習（reinforcement learning, RL）的背景，對其概念熟悉的同學可以略過這一部分。

“強化”的概念起源于行為心理學派。行為心理學派主要的概念是說，人的復雜高級行為，例如恐懼，是可以用過“強化”進行塑造的。同巴普洛夫的條件反射不同，心理學派認為生物的行為不需要通過直接的刺激所引起，行為更多地是因為行為本身所帶來的結果，生物體自發地執行該行為。

舉個例子來說，迷信行為的出現，主要的原因是人們認為迷信行為會為自己帶來好運，而不是真的會直接讓我們的彩票中獎。

機器學習（machinelearning，ML）領域的RL，就好比是利用這種行為生成理論，訓練一個機器人（agent），讓它能出現我們所期望的行為，以實現我們的目標。

簡單來說，RL組成要素包括執行動作（action）的agent，agent所在環境（environment），以及環境給與agent的反饋（reward）。Agent根據對環境的觀察（observation）通過給出action到environment，得到environment對該action的reward，由此agent判斷自己action是否有利并由此進行迭代修正，再發出新的action。

那么它和傳統ML方法有什么差別呢？在我的理解來看，RL之所以能夠處理一些傳統ML無法做到的事情，主要是在于其具有探索（exploration）能力，以及其長期累計收益最大化（maximize long term cumulative reward）的學習目標。

我們耳熟能詳的RL應用例子Alpha Go為例，之所以它能夠擊敗人類職業棋手，依靠的就是RL可以通過探索獲得更好的長期收益，而不是完全地從人類歷史棋譜中進行監督學習，從而實現對人類的超越。

對于我們前面提到的L2R無法處理的問題，也同樣可以訴諸RL途徑。例如前面提到電商排序問題，通過RL的exploration機制，讓排序在后面的商品有機會以一定的概率在靠前位置曝光，并且在長期收益最大化的目標保證下，能夠讓我們隨機探索的收益大于其帶來的代價。

四、RL和業務結合應用的思考過程，詳述實踐內容和碰到的問題，分步驟的實踐方案

再回到前面提及的酒店排序中遇到的兩個問題。我們認為RL是解決這兩個問題的不二途徑。成功實施RL的關鍵點在于如何設計RL中各要素以滿足業務的需求。為此我們預先設計了幾套循序漸進的方案。

第一個方案，我們就姑且稱其為“方案A”吧。方案A我們主要將其作為一個小規模探索，摸清流程和潛在的問題。在這個方案里，我們將不會花過多的時間在特征構建等問題上，主要是將RL的流程實現，并觀察其帶來的結果。

具體來說，我們計劃在主排序的線性模型基礎之上，對線性模型的若干維度進行權重調整，以實現對排序結果的調整。而RL的目標，就是學習這些對權重做出調整的“超參”，從而能夠依照不同的輸入數據，得到更優的排序序列。在粒度控制上，我們以城市為單位進行action輸出，這樣做的主要考量是數據部分的工程復雜性。

算法選擇上，我們選擇使用DQN。DQN作為value base的RL算法，無法給出連續區間的控制輸出，這就意味著我們給出的權重調整需要預先定義一些固定的區間，但其易用性是我們在方案A中選擇它的理由之一。

在工程實現上，RL最大的挑戰在于action發出與reward回收的環節對實時性的要求較高。在方案A我們打算利用現有Kafka環境，通過消息同步的方式連接前后端，進行action與reward數據匹配。這樣的額外工程量最小。

但問題也很明顯：Kafka當時是對全業務埋點進行統一定時處理，勢必存在更新緩慢延遲過大的問題，且發出action后與實際權重更新發送到前端存在不可控的時間差，由此帶來的缺陷便是RL模型update頻率被明顯拖慢，agent可能需要上線很久才能達到可用的狀態。

在第二步，我們稱為“方案B”，將主要改造action與reward數據的發送回收環節。方案A中的Kafka環境實時性不高，在方案B中，我們將采用storm實現流式處理，從而實現較為實時的action發送。在獲取reward數據時，我們也能夠更便捷地匹配到其對應的action。

這樣一來便能夠顯著提升agent學習頻次。此外，由于避免了復雜前后端消息同步，算法的調整粒度也能夠從城市粒度進一步提升為酒店粒度至用戶粒度，從而提升RL的潛在效能。

在方案B中，我們也將對數據維度做進一步的豐富化。我們當前正在進行對酒店以及用戶的embedding表征學習，在現有模型的線下測試中取得了一定效果。這些embedding維度也將在第二步方案中融合成為RL模型的輸入維度。

第三步方案C，我們則會將精力集中在算法的調優上。在解決了數據同步以及粒度問題后，我們打算在方案C中嘗試不同的RL模型，目標是保證效果的前提下，能夠用更少的參數量、更少的算法訓練時間，以優化整個RL部分。

首先考慮可以改進替換的算法為DDPG。DDPG為基于value的actor-critic RL算法。首先來說，由于開銷限制，即使使用了流式處理，模型在線更新頻次也不能做得非常高，那么同樣具有experience replay機制的DDPG能夠更好地實現較高的數據訓練效率。此外，DDPG的actor部分可以實現連續值輸出，從而能夠讓控制更為平滑。

方案A的DQN模型，其輸出值是離散的，因而需要人為將參數調整范圍進行分段，分段的多少以及每一段區間設置需要人為指定。DDPG還有其改進算法TD3，能夠進一步穩定Q網絡輸出，緩解TD error的大幅度波動。

另一方面，我們可以使用policy gradient的算法，例如A2C，TRPO等，與前面value base的算法進行對比選優。在有一些工作中，提到相比DDPG，TRPO等能夠減低由于Q-value估計的波動帶來的不穩定性。但在我們看來，這些policy base方法由于其action輸出存在隨機性，對訓練數據量的要求可能會更高。

最后，我們也將會考慮嘗試基于高斯過程(Gaussian process, GP)的湯普森采樣（Thompsonsampling）的算法方案。領英在它的首頁混排排序問題中，就應用了這樣的構架。

前面提到的一系列RL算法都是需要構建深度神經網絡（DNN），需要依賴TensorFlow或者PyTorch來實現。而基于GP的方案基本只涉及相對簡單的數值計算。當然，作為非參數模型，需要額外空間來存放樣本數據。

總結一下我們的RL實施規劃，主要包含了前期的流程探索，打通流式數據處理并豐富數據維度，以及后期的各種算法嘗試及調優這樣三個階段。

五、最后的實踐說明，初步探索

現在我們已經完成了方案A的實施，通過結果初步說明了RL起到了一定的作用。接下來將詳細介紹下我們的做法，以及過程中遇到的問題。

整體上RL模型將會依據輸入數據，調整現有模型的某些重要的權重值。RL模型的輸入值包括了全網比價結果，以及城市粒度的默認排序相關統計維度。

首先，我們定義agent 的action用于調整現有線性排序模型的參數WBase_model。

其中，alpha即為agent輸出值。

接下來，我們構造reward函數為：

即我們的優化目標為增加了RL模型的流量分桶，能夠比原模型流量分桶的轉化率（CR）更高，也就是最大化CR優勢。

模型選擇及參數設置。在方案A中，我們沒有對算法選擇和參數設置上做太多的調整。值得說明的一點是，我們將DQN中Bellman Equation更新部分的衰減參數γ設置為0，意味這我們的優化的目標是一步達成更優的CR，而不考慮多步馬爾科夫決策過程（MDP）。

顯然這是一個簡化操作，但我們認為在城市粒度上，追求多步MDP意義不大，設置γ=0能夠簡化模型。當粒度細化到單獨一個用戶時，考慮MDP將更為有價值。

模型調整的粒度。我們前面講到，方案A是按照城市粒度進行參數調整的。當agent對某個城市給出一個action后，經過一個時間片回收reward結果，作為模型的訓練依據。考慮城市粒度，主要是為了平衡數據量和同步難度：如果將整個默認排序進行調整，RL作用的價值有限；而若以更細粒度進行，數據實時同步又會比較困難。

更新時間片長度的設置。模型所需的reward反饋依賴于由Kafka給出的埋點記錄數據，而當時是全業務埋點統一定時處理的，造成reward收集存在很大的時間間隔。此外，在模型給出action到最終在前端權重更新也存在較大延遲。

為了應對這個問題，我們增加了前端的消息同步，以確保action與回收的reward能夠一一對應。但這并不能改善模型更新頻次少、更新延遲的問題。我們原計劃是每一個小時進行數據更新，但在極端情況下，模型更新間隔被拉長到了3個小時，對模型的效果形成了較大的影響。

最后，我們來看下線上實驗的效果。我們選擇了北上廣深四個城市觀察，發現這四個城市的累積reward雖有上下波動，但總趨勢為正向增長。但同時也應注意，累積reward值絕對數值較小，對其評估還需要更多的實驗。

六、總結

我們從傳統L2R應對探索問題能力不足談起，介紹了RL的背景以及其對這類平衡探索與收益問題的適應性。在此基礎上，我們結合排序業務出發，制定了循序漸進的若干RL應用方案，以期能夠利用RL的優點，滿足排序業務的需求。

此外，對初步探索中我們的實踐與碰到的問題做了詳細的討論，并在最后通過對線上結果實驗的分析，說明了RL能夠起到一定的作用，但還需要更進一步的應用和實驗，以加強RL能夠帶來正向作用的結論。

接下來我們將首先對數據處理構架方面進行改進，利用流式處理構架，并嘗試探索更為適合算法的以進一步釋放RL的效能，從而實現更優的排序結果，進一步降低用戶費力度、提升用戶使用體驗。

總結

以上是生活随笔為你收集整理的干货 | 强化学习在携程酒店推荐排序中的应用探索的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。