如何評價Airbnb的Real-time Personalization獲得2018 kdd最佳論文？

01-02

論文原標題：Real-time Personalization using Embeddings for Search Ranking at Airbnb
地址：
https://www.kdd.org/kdd2018/accepted-papers/view/real-time-personalization-using-embeddings-for-search-ranking-at-airbnb?
www.kdd.org

這篇論文是我最近覺得非常值得一讀的，寫了篇總結放在了專欄，但感覺還是提問的形式更有助於討論。原文如下：

Airbnb這篇論文拿了今年KDD best paper，和16年google的WD類似，並不fancy，但非常practicable，值得一讀。可喜的是，據我所知，國內一線團隊的實踐水平並不比論文中描述的差，而且就是WD，國內也有團隊在論文沒有出來之前就做出了類似的結果，可見在推薦這樣的場景，大家在一個水平線上。希望未來國內的公司，也發一些真正實用的paper，不一定非要去發聽起來fancy的。

自從Word2vec出來後，迅速應用到各個領域中，誇張一點描述，萬物皆可embedding。在NLP中，一個困難是如何描述詞，傳統有onehot、ngram等各種方式，但它們很難表達詞與詞之間的語義關係，簡單來講，即詞之間的距離遠近關係。我們把每個詞的Embedding向量理解成它在這個詞表空間的位置，即位置遠近能描述哪些詞相關，那些詞不相關。

對於互聯網場景，比如電商、新聞，同樣的，我們很難找到一個合適表達讓計算機理解這些實體的含義。傳統的方式一般是給實體打標籤，比如新聞中的娛樂、體育、八卦等等。且不說構建一個高質量標籤體系的成本，就其實際效果來講，只能算是乏善可陳。類似NLP，完全可以將商品本身或新聞本身當做一個需要embedding的實體。當我們應用embedding方案時，一般要面對下面幾個問題：

希望Embedding表達什麼，即選擇哪一種方式構建語料
如何讓Embedding向量學到東西
如何評估向量的效果
線上如何使用

下面我們結合論文的觀點來回答上面問題，水平有限，如有錯誤，歡迎指出。

希望Embedding表達什麼

前面我們提了Embedding向量最終能表達實體在某個空間裡面的距離關係，但並沒有講這個空間是什麼。在NLP領域，這個問題不需要回答，就是語義空間，由現存的各式各樣的文本語料組成。在其他場景中，以電商舉例，我們會直接對商品ID做Embedding，其訓練的語料來至於用戶的行為日誌，故這個空間是用戶的興趣點組成。行為日誌的類型不同，表達的興趣也不同，比如點擊行為、購買行為，表達的用戶興趣不同。故商品Embedding向量最終的作用，是不同商品在用戶興趣空間中的位置表達。

很多同學花很多時間在嘗試各種word2vec的變種上，其實不如花時間在語料構建的細節上。首先，語料要多，論文中提到他們用了800 million search clicks sessions，在我們嘗試Embedding的實踐中，語料至少要過了億級別才會發揮作用。其次，session的定義很重要。word2vec在計算詞向量時和它context關係非常大，用戶行為日誌不像文本語料，存在標點符合、段落等標識去區分詞的上下文。

舉個例子，假設我們用用戶的點擊行為當做語料，當我們拿到一個用戶的歷史點擊行為時，比如是list(商品A, 商品B，商品C，商品D)，很有可能商品B是用戶搜索了連衣裙後點的最後一個商品，而商品C是用戶搜索了手機後點擊的商品，如果我們不做區分，模型會認為B和C處以一個上下文。

具體的session定義要根據自身的業務訴求來，不存在標準答案，比如上面的例子，如果你要做用戶跨興趣點的變換表達，也是可以的，論文中給出了airbnb的規則：

A new session is started whenever there is a time gap of more than 30 minutes between two consecutive user clicks.

值得一提的是，論文中用點擊行為代表短期興趣和booking行為代表長期興趣，分別構建Embedding向量。關於長短期興趣，業界討論很多，我的理解是長期興趣更穩定，但直接用單個用戶行為太稀疏了，無法直接訓練，一般會先對用戶做聚類再訓練。

如何讓Embedding向量學到東西

模型細節

一般情況下，我們直接用Word2vec，效果就挺好。論文作者根據Airbnb的業務特點，做了點改造，主要集中在目標函數的細節上，比較出彩。先來看一張圖：

主要idea是增加一個global context，普通的word2vec在訓練過程中，詞的context是隨著窗口滑動而變化，這個global context是不變的，原文描述如下：

Both are useful from the standpoint of capturing contextual similarity, however booked sessions can be used to adapt the optimization such that at each step we predict not only the neighboring clicked listings but the eventually booked listing as well. This adaptation can be achieved by adding booked listing as global context, such that it will always be predicted no matter if it is within the context window or not

再看下它的公式，更容易理解：

注意到公式的最後一項和前面兩項的區別，在累加符號的下面，沒有變D限制。我的理解是，word2vec的演算法畢竟是非監督的，而Airbnb的業務最終是希望用戶Booking，加入一個約束，能夠將學到的Embedding向量更好的和業務目標靠近。後面還有一個公式，思路是類似的，不再贅述。

這個思路也可以理解成另一種簡單的多目標融合策略，另一篇阿里的論文也值得一讀，提出了完整空間多任務模型（Entire Space Multi-Task Model，ESMM）來解決。

數據稀疏是核心困難

Word2vec的演算法並不神奇，還是依賴實體出現的頻次，巧婦難為無米之炊，如果實體本身在語料中出現很少，也很好學到好的表達。曾經和阿里的同學聊過一次Embedding上線效果分析，認為其效果來源於中部商品的表達，並不是大家理解的長尾商品。頭部商品由於數據量豐富，類似i2i的演算法也能學的不錯，而尾部由於數據太稀疏，一般也學不好，所以embedding技術要想拿到不錯的收益，必須存在一批中部的商品。

論文中也提到，他們會對entity做個頻次過濾，過濾條件在5-10 occurrences。有意思的是，以前和頭條的同學聊過這個事情，他們那邊也是類似這樣的頻次，我們這邊會大一點。目前沒有做的很細緻，還未深究這個值的變化對效果的影響，如果有這方面經驗的同學，歡迎指出。

另一個方法，也是非常常見，即對稀疏的id做個聚類處理，論文提了一個規則，但和Airbnb的業務耦合太深了，其他業務很難直接應用，但可以借鑒思想。阿里以前提過一種sixhot編碼，來緩解這個問題，不知道效果如何。也可以直接hash，個人覺得這個會有損，但tensorflow的官網教程上，feature columns部分關於Hashed Column有一段話說是無損的：

At this point, you might rightfully think: "This is crazy!" After all, we are forcing the different input values to a smaller set of categories. This means that two probably unrelated inputs will be mapped to the same category, and consequently mean the same thing to the neural network. The following figure illustrates this dilemma, showing that kitchenware and sports both get assigned to category (hash bucket) 12:

As with many counterintuitive phenomena in machine learning, it turns out that hashing often works well in practice. Thats because hash categories provide the model with some separation. The model can use additional features to further separate kitchenware from sports.

離線如何評估效果

向量評估的方式，主要用一些聚類、高維可視化tnse之類的方法，論文中描述的思路和我的另一篇文章https://zhuanlan.zhihu.com/p/35491904比較像。當Airbnb的工具做的比較好，直接實現了個系統來幫助評估。

值得一提的是，論文還提出一種評估方法，用embedding向量做排序，去和真實的用戶反饋數據比較，直接引用airbnb知乎官方賬號描述：

更具體地說，假設我們獲得了最近點擊的房源和需要排序的房源候選列表，其中包括用戶最終預訂的房源；通過計算點擊房源和候選房源在嵌入空間的餘弦相似度，我們可以對候選房源進行排序，並觀察最終被預訂的房源在排序中的位置。

上圖可以看出，d32 book+neg的效果最好。

線上如何用

論文中反覆提到的實時個性化並不難，只要支持一個用戶實時行為採集的系統，就有很多種方案去實現實時個性化，最簡單就是將用戶最近的點擊序列中的實體Embedding向量做加權平均，再和候選集中的實體做cosine距離計算，用於排序。線上使用的細節比較多，論文中比較出彩的點有兩個：

多實體embedding向量空間一致性問題

這是一個很容易被忽視的問題，當需要多個實體embedding時，要在意是否在一個空間，否則計算距離會變得很奇怪。airbnb在構建long-term興趣是，對用戶和list做了聚類，原文如此描述：

To learn user_type and listinд_type embeddings in the same vector space we incorporate the user_type into the booking sessions.

即直接將二者放在一個語料裡面訓練，保證在一個空間。如此，計算的cosine距離具有實際的意義。

Negative反饋

無論是點擊行為還是成交行為，都是用戶的positive反饋，需要用戶付出較大的成本，而另一種隱式的負反饋，我們很少用到（主要是噪音太強）。當前主流的個性化被人詬病最多的就是相似內容扎堆。給用戶推相似內容，已經是被廣泛驗證有效的策略，但我們無法及時有效的感知到用戶的興趣是否已經發生變化，導致損壞了用戶體驗。因此，負反饋是一個很好的思路，airbnb給出了skipped listing_ids的策略。

比較可惜的是，我們目前沒有在蘑菇街的場景拿到這個負反饋的收益，如果有同學在相關方面有經驗，歡迎來指導。

推薦系統的兩大任務「記憶」與「擴展」。在我看來，擴展性就來源於將大量的id/categorical類特徵進行embedding。原來的id/categorical特徵只能進行精確匹配（如：商品有標籤A，用戶也有標籤A），而embedding使id/categorical特徵向量化，向量之間就可以計算夾角，變原來的「精確匹配」為「模糊查找」（比如論文中的K近鄰）。

以上回答了為什麼要在推薦系統中引入embedding。接下來，如何計算這一embedding，在我看來，就分為兩大流派：

有監督學習，end-to-end。embedding作為優化變數，隨機初始化，在優化最終logloss的過程中，得到有意義的embedding作為「副產品」。個人感覺，這一流派是主流，Youtube對video_id、WideDeep對app_id、Deep Interest Network對商品id的embedding都是這一思路。
無監督學習，兩步走。以Item2vec: Neural Item Embedding for Collaborative Filtering為代表。

第一步，就是簡單套用word2vec的思路，在電商場景，就將word2vec中的句子換成購物車，將單詞換成商品；新聞推薦場景中，將句子換成session，將單詞換成文章。再直接調word2vec演算法，就得到商品、文章的embedding向量。
第二步，這些embedding向量，可以用於召回，可以用於第一類方法的embedding矩陣的初值，也可以當特徵喂入其他模型。原諒我讀書少，感覺這類方法近年來遇冷，不怎麼受關注。

從這個角度來看，Airbnb的這篇文章算是對第二類方法的一次復興。第一次讀此文的印象，感覺平淡無奇，就是套用word2vec演算法，再稍做修改；第二篇再讀此文，才感覺到作者的匠心獨具，初讀時認為的「小改動」，使「無監督學習embedding」方法擺脫了簡單套用word2vec的老套路。儘管本質上還是「無監督學習」，但是作者巧妙將「成功預訂」、「host拒絕」這些重要的反饋融入演算法，以達到「有監督」的效果。

這一將「業務邏輯」融入「機器學習演算法」的過程，反映了作者對「業務邏輯」與「演算法」兩方面的深刻理解。這種基於對業務邏輯的深度理解，再把業務目標反映到演算法中的能力，才是目前浮躁的數據科學行業最缺乏的，也是這篇文章的精華所在，也是我們讀者應該從這篇文章中學到並舉一反三的。

所以，整篇文章讀下來，給我留下深刻印象的就是以下這些「業務邏輯」與「演算法」的結合點

業務邏輯：Airbnb是一個雙方市場，推薦listing給user時，不僅要考慮user的喜好，還要考慮到host拒絕的因素，才能提升「預訂成功率」。
解決方案：將host「明確拒絕」也作為一個「negative word」加入word2vec訓練集中

業務邏輯：數據稀疏性，大量用戶只預訂過一次，大量listing被預訂小於5次
解決方案：根據業務邏輯，將user_id聚合成user_type，將listing_id聚合成listing_type。

業務邏輯：word2vec畢竟是非監督的，怎樣融入提升「預訂率」這一業務目標
解決方案：在booked session中，將最終預訂的listing增加為global context，無論是否在滑窗中都要參與學習。這樣一來，兩個listing_id相似，不僅因為所處的點擊序列相似，而且還會因為導致預訂相同listing而相似。而預訂相同listing比點擊是一個更強、更有意義的信號，訓練得到的embedding對提升「預訂率」也更有意義。

業務邏輯：word2vec中的negative sampling是隨機的，而點擊序列中的context都來自同一城市，導致數據集有bias
解決方案：專門增加一個與central listing來自同一個城市的負樣本集

將整篇文章讀完後，還有兩個小疑問：

第一，如前所述，本文的embedding方法屬於「無監督學習」。通過加入「預訂成功」、「host拒絕」這樣的強反饋信號來指導無監督學習，本文方法顯然比以往簡單套用word2vec的方法更具備優勢，在Related Work一節也有論述。但是，與第一類「將embedding作為優化變數，有監督學習」的方法相比，Airbnb的這套演算法有何優勢，文中卻沒有涉及。

以我這樣的局外人的揣度，以Airbnb的數據量、計算能力，實現第一類演算法，應該也能獲得不錯的embedding向量。這些「副產品」也同樣可以用於召回相似listing。至於稀疏問題，也同樣可以由聚合成listing_type/user_type來解決。而且，如果用第一類演算法，加入host perference, host rejection這樣的強反饋信號，也更加方便。

我很想知道Airbnb團隊當初選擇技術路線的思路，為什麼會選擇了「無監督學習」的思路，而沒有隨大流地選擇「有監督學習」的思路。

第二，本文的思路還是基於word2vec。word2vec之所以能夠成立，是因為人類語言本身就有語序問題，相同的三個字「我吃飯」就有意義，「我飯吃」就沒有意義。但是clicked session, booked session中，順序有那麼重要嗎？

如果兩個listing同處一個clicked session，但是間隔超過了滑窗的範圍，難道就沒有相關性了嗎？顯然相關性還是存在的。在我看來，增加booked listing作為global context參加每個滑窗的學習，就是為了彌補套用word2vec而不得不強調「相鄰」而帶來的信息損失。

另外，推薦系統天生就有兩個bias，一個是position bias，另一個是向用戶展示的商品列表是由上一版本的推薦系統決定的。如果「點擊順序」那麼重要，那麼演算法又該如何克服這兩個bias。

如果有可能，以上兩個問題，還希望得到Airbnb官方團隊的解答。再次感謝Airbnb團隊的分享，Good Job !!!

------------------------- 分割線 --------------------------

關於第一個問題，我在Airbnb的新文&中找到了官方答案。簡單來說，就是：有監督學習的經典思路，Airbnb嘗試了，但是效果不好。

在&中的3.1節，描述了Airbnb用「有監督學習」思路訓練list embedding。結果是比較容易過擬合。Airbnb在文中的解釋是，數據太稀疏，有些embedding在訓練集中出現的次數太少。感覺這個解釋不是很充分，word2vec也同樣面臨著「罕見詞」訓練不好的問題。而且，在「有監督學習」中，同樣可以將user/listing合併成user_type/listing_type來降低「稀疏性」。

另外，Airbnb還嘗試了阿里的Entire Space Multi-Task Model的多任務模型，即共享底層embedding，同時預測booking和long click。為了減輕click bait的影響，對於long click樣本，還用「頁面停留時長」對樣本做了加權。實驗結果是大幅增加用戶頁面停留時長，而對於booking沒有太大的影響。

Airbnb給出的解釋是：新聞、視頻網站中，用戶點擊後長時間停留，代表用戶真心喜歡被推薦的物品；但是在Airbnb中，用戶長時間停留，可能是由於被高大上的listing吸引，點擊過後長時間瀏覽來羨慕人家的生活；也有可能是listing的描述寫得太長、太幽默而讓用戶多讀幾遍；......，長停留並不意味著預訂。總之，Airbnb認為在他們獨特的市場中，long click與booking肯定是相互信賴的，但是如何用模型來解決click bait，仍然是他們尚未解決的問題。

目前在推薦上比較流行的方案，主要是基於google的widedeep開啟的end to end的模型，uid，itemid作為embedding輸入加上其他各種特徵，並著重在wide部分進行優化，比如以deepFM為首的模型。我們自己也是在這個方向上實踐的。

而這篇論文是先單獨訓練embedding，然後在把embedding當特徵輸入到rank model中去。整體來說這個思路其實並沒有什麼出奇的，很多帶預訓練的任務都是這個邏輯，常見的就是NLP中先訓練詞語的embeddings，然後將其作為特徵，接神經網路去解決各種問題。

這篇paper的我認為主要有兩大優點：

1. embedding方面使用了user_type和listing_type級別，同時統一在一個向量空間，其實也是和業務結合的緊，通過many to one的方式解決稀疏性，不過真正有意思的是將user_type 和listing_type做到了一個向量空間中，原先常見邏輯是各自做序列然後word2vec，兩種embedding不在一個空間，不適合進行相互運算，現在則支持了餘弦相似度之類的運算。

2. 另外就是具體的細節講的比較多，業務場景，不同的目標函數優化解決了什麼，數據集如何構造，超參的選擇，離線效果的評估等等。文章很實在，也很友好，相對於很多無法復現的論文來說，這篇可信度要高很多。

下文主要是對論文的重點部分進行翻譯性地解讀，同時穿插著我自己對各部分理解和想法。如有問題，歡迎指正。

Introduction

搜索演算法的目標就是為了提升網站的收益，在airbnb需要同時優化客人和房主兩方，即給定地點和日期後，將位置、價格、風格和評價等方面對用戶有吸引力的房子排前。也要考慮房主的偏好，將可能會拒絕客人的排名名降低，比如用戶評價差，有寵物，人數等等原因。

在一個search session中會有多次點擊和聯繫房主，這些都是in-session signals。實時個性化推薦的目標是在搜索會話期間為客人展現更多類似於我們認為他會喜歡的房間，同時，可以用負面信號，如跳過高排名的listings，去減少與之相似的我們認為不喜歡的。

引入listing embeddings,利用這些相似性去為Search Ranking Model創建個性化特徵,驅動相似listing推薦

由於一般人一年旅行一到兩次，在Airbnb的場景中，booking是很稀疏的，其中大量用戶只訂過一次。為此，訓練listing_type級別的embeddings。同樣,也學習與 listing _type embeddings 同一向量空間的user_type embeddings.這裡邊的一個亮點就是user_type embeddings 和 list_type embeddings是同一空間下的。

歷史工作：

Real-time Personalization
Adapting Training for Congregated Search
Leveraging Conversions as Global Context
User Type Embeddings
Rejections as Explicit Negatives

效果：

CTR相對於現有的模型提升20%

如上文所說，接下來介紹Listing Embeddings、Listing_type Embeddings 和 User_type Embeddings

Listing Embeddings

首先定義session，用戶的點擊序列就是session，兩個點擊間超過30min就是一個新的session，或者預訂了房間也算是結束了一個session。根據此數據集去學習,使用skip-gram model最大化如下目標函數:

$mathcal { L } = sum _ { s in mathcal { S } } sum _ { l _ { i } in s } left( sum _ { - m geq j leq m , i eq 0 } log mathbb { P } left( l _ { i + j } | l _ { i } ight) ight)$ $mathcal { L } = sum _ { s in mathcal { S } } sum _ { l _ { i } in s } left( sum _ { - m geq j leq m , i eq 0 } log mathbb { P } left( l _ { i + j } | l _ { i } ight) ight)$

$mathbb { P } left( l _ { i + j } | l _ { i } ight)$ 是在臨近點擊 $l _ { i }$ 情況下，應用soft-max後 $l _ { i + j }$ 被點擊的概率:

$mathbb { P } left( l _ { i + j } | l _ { i } ight) = frac { exp left( mathbf { v } _ { l _ { i } } ^ { op } mathbf { v } _ { l + j } ^ { prime } ight) } { sum _ { l = 1 } ^ { | mathcal { V } | } exp left( mathbf { v } _ { l _ { i } } ^ { op } mathbf { v } _ { l } ^ { prime } ight) }$

變數的定義很好理解，l就是listing（paper中的listing我理解就是房子），u就是user，v代指vector，像 $v_ { l _ { i } }$ 就是指listing i的embedding， $v_ { l _ { i } }$ 代指所有listings集合。

隨機採樣當做負例和傳統的skip-gram相同，於是優化目標函數轉變為：

$underset { heta } { operatorname { argmax } } sum _ { ( l , c ) in mathcal { D } _ { p } } log frac { 1 } { 1 + e ^ { - mathbf { v } _ { c } ^ { prime } mathbf { v } _ { l } } } + sum _ { ( l , c ) in mathcal { D } _ { n } } log frac { 1 } { 1 + e ^ { mathbf { v } _ { c } ^ { prime } mathbf { v } _ { l } } } （3）$

$mathcal { D }$ 指數據集， p為positive，n就是negative了。

Booked Listing as Global context:

session被分為兩種:

booked sessions ( i.e. click sessions that end with user booking a listing to stay at
exploratory sessions (i.e. click sessions that do not end with booking, i.e. users were just browsing

引入最終預訂的listing作為全局上下文，無論其是否在窗口內，幫助優化臨近點擊listing到預訂listing的先關關係。於是booked sessions的embedding更新規則變成：

$underset { heta } { operatorname { argmax } } sum _ { ( l , c ) in mathcal { D } _ { p } } log frac { 1 } { 1 + e ^ { - v _ { c } ^ { prime } v _ { l } } } + sum _ { ( l , c ) in mathcal { D } _ { n } } log frac { 1 } { 1 + e ^ { v _ { c } ^ { prime } v _ { l } } } + log frac { 1 } { 1 + e ^ { - v _ { l _ { b } } ^ { prime } v _ { l } } } （4）$

Adapting Training for Congregated Search:

在線預定一般都是在一個market里去選擇，比如你想去London，那麼你會在London這個market里去選擇。而負樣本是全局隨機採樣的，很可能與正例不在同一個market里，導致同market內學習到的相似性不夠好，為此引入同market的隨機樣本作為額外的負樣本。

cold start listing embedding

新房子的embedding，用10英里內最相似的三個房子（類型、價格範圍）的embedding均值來代替

Examining Listing Embeddings

在8億的click sessions上訓練32維embeddings,進行K-means聚類，可以發現位置相近的聚集在一起，可知學習到了地理位置的相似性。也可以看到相同類型和價格的listing比不同的更相似,如下圖：

User-type Listing-type Embeddings

用用戶預訂序列來訓練Embedding，可以捕獲cross-market的相似度

不過這樣學習有以下挑戰：

預訂是個低頻事件，booking sessions數據相較於click sessions少很多。
許多用戶只預訂一次，session長度為1是無法被學習的
對於任何一個實體，要學到有意義的embedding需要實體出現在數據中至少5-10次
用戶兩次預訂間隔時間很長的話，用戶自身偏好可能會改變比如因為職業的改變而對價格敏感度改變

解決方案，引入Listing_type embeddings

listing Embeddings 比較適合short-term, in session場景, peronalization還需要基於長期歷史的個性化，用戶曾經在紐約和倫敦預訂過，現在在搜索洛杉磯。這就需要去找到不同market之間的相似性，通過用戶的booked list可以捕獲此信息。

給定一個listing_id，根據它的位置，價格，類型，容量，床數等進行規則映射用數據驅動的方式最大化每個listing_type 桶的覆蓋範圍

使用Listing_type embeddings來解決這個問題。給定一個listing_id，根據它的位置，價格，類型，容量，床數等進行規則映射，用數據驅動的方式最大化每個listing_type 桶的覆蓋範圍。Airbnb的映射table如下：

Training Procedure

此處我覺得是一個比較有想法的點，就是學習在同一向量空間下的user_type和listing_type embedding

$s _ { b } = left( u _ { t y p e _ { 1 } } l _ { t y p e _ { 1 } } , ldots , u _ { t y p e _ { M } } l _ { t y p e _ { M } } ight) in mathcal { S } _ { b }$ 是用戶預訂序列數據集，將user_type, list_type組合在一起，再拼成一個序列即相當於把他們確定到了一個空間中。於是在skip-gram中， $user\_type ( u _ { t } )$ 為中心項時，目標函數為：

$listing\_type ( l _ { t } )$ 為中心項時，目標函數為：

Explicit Negatives for Rejections

不像一般的場景里只考慮用戶偏好，Airbnb的這個場景既要考慮用戶偏好也要考慮主人的偏好。引入房主拒絕行為，作為房主方的顯示反饋。某種層面上會使對用戶不敏感的房主和評分一般的客人聚攏，減少客人被拒絕幾率，提高預定概率。對於被拒絕的序列，我們優化的目標函數分別變為：

$underset { heta } { operatorname { argmax } } sum _ { left( u _ { t } , c ight) in mathcal { D } _ { b o o k } } log frac { 1 } { 1 + e ^ { - v _ { c } ^ { prime } mathbf { v }{ u _ { t }} } } + sum _ { left( u _ { t } , c ight) in mathcal { D } _ { n e g } } log frac { 1 } { 1 + e ^ { mathbf { v } _ { c } ^ { prime } mathbf { v } _ { u{t}} } } + sum _ { left( u _ { t } , l_{t} ight) in mathcal { D } _ { reject } } log frac { 1 } { 1 + e ^ { mathbf { v } _ { l_{t} } ^ { prime } mathbf { v } _ { u_{t}} } }$

and

$underset { heta } { operatorname { argmax } } sum _ { left( l_ { t } , c ight) in mathcal { D } _ { b o o k } } log frac { 1 } { 1 + e ^ { - v _ { c } ^ { prime } mathbf { v }{ l _ { t }} } } + sum _ { left( u _ { t } , c ight) in mathcal { D } _ { n e g } } log frac { 1 } { 1 + e ^ { mathbf { v } _ { c } ^ { prime } mathbf { v } _ { l{t}} } } + sum _ { left( l _ { t } , u_{t} ight) in mathcal { D } _ { reject } } log frac { 1 } { 1 + e ^ { mathbf { v } _ { u_{t} } ^ { prime } mathbf { v } _ { u_{t}} } }$

EXPERIMENTS

這段主要介紹了下訓練和離線評估的細節，和listing Embeddings在房間相似推薦中的應用，以及如何將embedding處理為特徵提供給Search Ranking Model。

Training Listing Embeddings

30分鐘不活躍原則
移除偶發和短點擊（如停留少於30s）
只保留&>=2 的sessions
匿名session，移除userid

點擊會話分為 exploratory sessions booked sessions。訓練數據中booked sessions過採樣5倍達到最好效果.

Setting up Daily Training

over multiple months
每天引入新一天，去掉最早一天的數據
重新訓練是要比增量訓練現有的vector效果好。

模型中，day-to-day vector的變化不會導致矛盾，因為最終使用的是embeddings間的相似度而非具體的vector

超參 - dimensionality 32 - window size 5 - iterations 10.

Offline Evaluation of Listing Embeddings

從預訂房間開始回溯17個點擊，統計預訂房間在對應點擊時刻的平均位置，比較了如下三個版本： 1. d32: trained using (3), 2. d32 book: trained with bookings as global context (4) 3. d32 book + neg: trained with bookings as global context and explicit negatives from same market (5)

最終可以發現d32 book + neg效果最好，具體如下圖：

Similar Listings using Embeddings

Airbnb home listing page有相似房源，會展示相同可用日期下類似的房源,用餘弦相似度，最近鄰，取top K。

AB Test顯示，CTR整體提升21%（有入住日期的提升23%，無日期提升20%），在相似房源處進行最終預定的提升4.9%

Real time personalization in Search Ranking using Embeddings

訓練數據 $D_{s} = (x_{i} ,y_{i}), i = 1...K$ ， K是搜索後返回listing的序號， $x$ 特徵vector， $y$ 是label

y = 1 booked
y = 0.25 contacted but no booked
y = -0.4 host rejected
y = 0.01 clicked
y = 0 just viewed

每次使用最近30天的數據訓練新的ranking model

特徵具體如下：

Feature vector xi for the i-th listing result consists of listing features, user features, query features and cross-features. Listing features are features associated with the listing itself, such as price per night, listing type, number of rooms, rejection rate, etc. Query features are features associated with the issued query, such as number of guests, length of stay, lead days, etc. User features are features associated with the user who is conducting the search, such as average booked price, guest rating, etc. Cross-features are features derived from two or more of these feature sources: listing, user, query. Examples of such features are query listing distance: distance between query location and listing location, capacity fit: difference between query number of guests and listing capacity, price difference: difference between listing price and average price of user』s historical bookings, rejection probability: probability that host will reject these query parameters, click percentage: real-time memorization feature that tracks what percentage of user』s clicks were on that particular listing, etc. The model uses approximately 100 features. For conciseness we will not list all of them.

他們使用了pairwise regression的思路去訓練了一個GBDTmodel,使用的支持Lambda Rank的gbdt,用NDCG評估。

Embedding Features for Search Ranking

| Feature Name | Feature Name |

|----------|:-------------:|

|EmbClickSim| similarity to clicked listings in Hc

|EmbSkipSim| similarity to skipped listings Hs

|EmbLongClickSim| similarity to long clicked listings Hlc

|EmbWishlistSim| similarity to wishlisted listings Hw

|EmbInqSim| similarity to contacted listings Hi

|EmbBookSim| similarity to booked listing Hb

|EmbLastLongClickSim| similarity to last long clicked listing

|UserTypeListingTypeSim| user type and listing type similarity

User-type Listing-type Embedding Features

500K user types
500K listing type
50 million user booking sessions

Embedding Features Coverage and Importances

|Feature Name |Coverage |Feature Importance

|----------|:-------------:|---|

|EmbClickSim| 76.16%| 5/104|

|EmbSkipSim| 78.64%| 8/104

|EmbLongClickSim| 51.05%| 20/104

|EmbWishlistSim| 36.50%| 47/104

|EmbInqSim| 20.61%| 12/104

|EmbBookSim| 8.06%| 46/104

|EmbLastLongClickSim| 48.28%| 11/104

|UserTypeListingTypeSim| 86.11%| 22/104

Online Experiment Results Summary

引入 embedding features後，NDCU提升2.27%，booking DCU增長2.58%

印象中淘寶很早就開始I2I了，其他廠商最近也是都在ALL in Vector。。。Embeddeding Everything.

Airbnb這個確實是在細節上有一些優化，但是這些優化是和業務、工程非常強相關的，在"演算法"層面顯然沒有太大的革新。

國內其他廠的效果其實都很好，但是沒有上線的原因一個是受限於業務，一個就是工程實現吧。業務方面整個推薦系統已經很複雜了，各種東西堆了太多，要想改變成I2I或者其他Embeddeding，太浪費時間了，確實很難動。、

單純看推薦的話，頭條系的應該最有實踐經驗解釋一下，坐等。

這篇論文給出如何在具體的應用場景下，有針對性的利用演算法

其實word2vec估計很多公司都嘗試過，但是真正出效果的確不多，其中原因之一也就是沒有效的利用，只是簡單的模仿

？？？邀請我是因為在airbnb就職嗎？

我只是最底層的基層民工啊。。。。

好高端的說

我的困惑：這種已經應用落地的方法，為什麼airbnb會願意發表呢？難道不擔心競爭對手直接拿去用嗎？（我是傳統行業出身，一般這種情況都會申請patent或者不公開）