旅行場景的搜尋起初是為了滿足使用者某種特定的強需求而出現的，如機票、火車票、酒店等搜尋。這些需求有著各自不同的特點，傳統的旅行搜尋往往會對不同業務進行定製化搜尋策略。隨著人工智慧技術的不斷髮展，使用者對產品的易用性提出了更高的要求。旅行場景的搜尋逐漸發展為一個擁有旅行定製搜尋策略的全文檢索引擎。本文將為大家介紹阿里飛豬在旅行場景下搜尋技術的應用與創新，主要內容包括：

豬搜背景基礎建設召回策略思考總結

01

豬搜背景

1. 飛豬搜尋

飛豬搜尋業務分為兩大部分：一是全域性搜尋，二是行業小搜。右邊飛豬介面的全域性搜尋就是最上方的輸入框。直接對應飛豬內部所有內容的搜尋入口，都可以從全域性搜尋獲得。右圖中間部分就是產業小搜的垂直入口。比如搜尋酒店機票和旅遊度假產品，一般使用者會使用行業小搜，垂直搜尋需求。隨著飛豬業務的發展，以及使用者需求的變化，流量會從行業小搜逐漸遷移到飛豬的全域性搜尋上。主要是因為：

旅遊行業是一個跨類目的需求。使用者天然的需要定機票、酒店以及一些網路的門票，如果全部透過垂直搜尋，需要進行多次點選，對使用者來說不是很方便。飛豬很多流量是由手淘引流過來的，手淘是一個全域性的搜尋。所以使用者會習慣性的使用全域性搜尋來滿足他的需求。對使用者來說，用全域性搜尋的操作是最方便的，路徑最短。

2. 豬搜框架

豬搜框架如圖所示，首先透過呼叫QP來獲得當前的Query理解，以及需要召回的Query生成，然後透過SP分頁服務呼叫HA3倒排索引來獲取召回的結果。透過粗排序和加權排序將結果透過LTP服務做重排序，最後將得到的結果展示給使用者。這裡主要介紹下QP的工作。

3. QP

QP即Query理解與召回生成服務。在這個服務中，我們面臨的挑戰主要有：

效能限制：在業界，通常QP階段只佔用整個線上響應時間的1/10。所以，對效能要求比較高，響應時間不能過長，需要提供良好的線上服務體驗。文字理解：我們的QP和其他的全域性搜尋QP一樣，也需要做傳統的文字理解，提供文字相關性的能力。獨有挑戰：在旅行場景下，會有一些特殊的要求。比如LBS與POI的理解能力，能夠提供空間上的相關性。特徵理解：從業務發展角度，我們還需要使用者特徵的理解，可以提供個性化的相關性，來滿足使用者的需求。

02

基礎建設

接下來，為大家介紹下飛豬在具體基礎建設上的一些工作。

1. Query tagging

Tagging是QP中的一個基礎任務。負責的功能是把一個query 打出目的地和意圖。舉個例子，“北京自由行”中“北京”就是使用者的目的地，“自由行”是使用者的意圖需求，可以看出使用者希望的是一個自由行的商品，而不是跟團遊這類的產品，可能會更希望獲得一些機票+酒店或者是無購物的產品。

這裡的工作，主要分為以下幾層：

資料層：透過離線挖掘出tagging詞庫。演算法層：透過Tag消歧、CRF等演算法進行線上打標工作。應用層：在tagging上的一些應用，如query丟詞和query改寫。

由於線上效能的限制，我們主要依賴於離線的挖掘。這裡以我們內部比較重要的商品POI挖掘為例，來介紹下我們離線挖掘tagging 的工作。

2. 商品POI挖掘

① QueryTagging

POI的挖掘除了商品title 可能會有一些景點資訊外，詳情也會包含大量的資訊。因此，我們需要從這些內容中挖掘出有價值的資訊，來擴充詞表。例如圖中的景點POI，可以用作索引參與召回，但是詳情是非結構化的HTML文字，要挖掘POI實體，會有比較大的難度。

② 建模方式

我們採用了典型的序列標註問題來解決這個問題。我們透過一些特徵，如詞特徵、數字特徵、類目特徵，進行篩選，透過人工標註來訓練我們的CRF++模型。後續我們還升級成了Template下的模型來訓練NER模型，使我們可以在離線，對接了大量的文字資料，進行序列標註。最終，我們達到了99%以上的準確率，召回率也超過95%。擴充了大量的沒有挖掘出POI商品/POI特徵的度假商品，使它們產生了POI的特徵，可以更好地為後續的POI及檢索做出服務。

3. 同義詞挖掘

在旅行行業，存在四種類型的同義詞：

翻譯類：如“迪斯尼”，可能有不同的中文描述方式中英文詞：有的使用者用英文來描述，而有的使用者用中文來表述，但是商家描述的title是英文包含關係：比如“普吉”和“普吉島”，可能“普吉”這個POI是“普吉島”這個大POI下的子POI錯別字：比如“國色天香”，在圖中應該是“國色天鄉”

我們希望可以用一個通用的模型來解決這種同義詞關係。

另外，在特徵工程上，我們會利用中英文的編輯距離、共現數目以及是否包含關係、餘弦相似度等來構建特徵。

然後，我們透過人工標註來構建正樣本，負樣本按照編輯距離倒排隨機取樣，使用LR模型和XGBoost對標註好的樣本進行二分類。

最後，我們還會經過一層人工稽核，因為同義詞的影響面積比較大，如果直接透過演算法挖掘，在線上的效果可能不會特別好。所以我們沒有采用複雜的模型，只是夠用就可以了。這樣在萬級別的人工標註上，我們的準確率可以達到94%。

4. 糾錯

① 背景

對於糾錯，剛才提到了詞級別的錯誤，事實上，整個Query中也會出現一些錯誤。只用詞級別的糾錯，不能滿足使用者需求，需要一個全query糾錯邏輯。

由於QP階段對效能要求很高，現在業界常用的seq2seq方法，雖然效果很好，但整體效能不達標。我們可以在離線利用seq2seq來挖掘高頻的資訊，但在線上很難應用seq2seq的方法來做糾錯。

② 方案

我們的方案是採用傳統的隱馬爾科夫模型，基於統計的方式來做，能夠達到線上的效能要求。將錯誤分為同音字與形近字，可以獲得比較強的可解釋性。

同音字：因為漢字都可以查到拼音碼錶，我們可以很容易的構建一個同音字的集合，然後透過一些統計的方式，就能獲得同音詞生成機率。形近字：比較難獲得，因為很難判斷兩個字是否有些相似。我們這裡，透過字型影象和字型結構來解決的。

說到基於影象的方式，最直接的方式就是基於CNN影象網路的匹配演算法。但是出於效能方面的考慮，這種方法的效果往往達不到我們的效能要求，所以我們採用了一個比較簡單且有效的方法，就是我們直接對兩個可能形近的字的影象進行計算。對形近字而言，我們在標準的字型庫中，發現它有兩個特點：

如鳥和烏兩個字，在字型庫裡的圖直接對比，它們的重合度是非常高的，由於字型庫裡的字，它的標準化程度是很高的，可以透過這種方式來進行計算。我們這裡基於影象的方式，就是採用我們對字型庫裡的兩個字來進行每個點的一個具體的計算。

另外，對於鳥和烏這個字，鳥這個字的每一個點在烏字上找到和它最近的一個點，作為這兩個點相似度，那對於每一個點，我們都可以找到一個距離，然後透過求和的均值計算，我們就可以得到這個兩個字距離的相似度。

透過離線對兩個字以各自的影象進行計算，那就可以獲得比較相似的一些字。

④ 基於字型結構

另外，我們還會透過字型結構的方式來進行計算。像倉頡、鄭碼、四角號碼的編碼，是基於這個字的情況來做的編碼。對於倆個形近字，它們的倉頡碼、鄭碼、四角號碼往往也會比較相似。所以，我們透過序列的相似計算，可以獲得這兩個形近字的相似度，然後透過相似度進行閾值計算，就可以得到字形相似的集合。

03

召回策略

接下來為大家介紹下飛豬在召回策略上的一些技術：

航旅召回跟常用的搜尋召回有相似的地方，也有不同，面臨的挑戰主要有：

使用者query和商品描述之間存在GAP航旅商品僅百萬級，而且城市分割，很容易造成無結果召回最佳化時，很容易導致誤召回旅行是低頻行為，使用者行為稀疏，演算法樣本較少

鑑於這種情況，我們對使用者的召回分成了以下四種召回方式：經典召回（同義詞挖掘、相似query改寫、商品POI挖掘）、LBS召回、向量召回、個性化召回（I2I&U2I以及向量模型），來滿足使用者的需求。

1. 經典召回

剛剛已經介紹過同義詞挖掘和商品POI挖掘，這裡主要介紹下相似query改寫。以“上海迪士尼樂園門票”為例，其實標準的商品是“上海迪士尼度假區”，而“黃山風景區”的標準商品其實是“黃山”。在這樣的情況下，如果我們直接建立搜尋，可能召回的效果比較差。因而，我們會進行一些相似query挖掘，來滿足這種query和title GAP的情況。

Learning To Rewrite：

我們思路是使用多路改寫產生候選集合，然後用learning to Rank 選取top K結果。

首先假設使用者在篩選中輸入了query，這個query是比較相似的。因為使用者在篩選中是想要獲得他想要的結果。如果使用者第一個query，沒有得到想要的結果，使用者會進行一些改寫。就相當於使用者幫助我們完成了一次改寫，我們從中可以學到使用者改寫的資訊。這裡我們是用類似word2vec的模型實現的。

另外，從query相似度來看，我從文字上也可以獲得一個相似的query文字。這裡我們採用的是doc2vec模型，來獲得文字相似性。

透過這三種方式，我們可以獲得想要的相似query改寫的候選。

對於候選，透過一些人工標註及線上的埋點資訊，來獲得原query和候選query相似的標註。這樣我們就可以訓練一個模型來進行相似query的排序工作。

最終，我們線上使用的模型是PS-SMART 模型。加上規則過濾之後，準確率可以達到99%。可以影響線上36%的PV，對一次UV的無結果率可以相對降低18%。

2. 航旅特色召回：LBS召回

由於使用者是在旅行場景下搜尋，使用者天然會需要LBS 相關的資訊。如果是差旅使用者，可能會定阿里巴巴園區附近的酒店，如果是旅遊使用者，可能會定黃山風景區附近的酒店。這就需要識別使用者想要的商品大概在什麼樣的LBS範圍內。解決的方法是透過對query中使用者POI的識別，獲取使用者的經緯度，進行召回上的限制。

建模過程：

首先會對query進行常規的分詞，然後在POI專用的倒排索引庫進行檢索，獲得候選POI。接下來對候選POI query進行特徵計算，計算出文字相似性、embedding相似距離，以及使用者當前位置輸入後，與歷史點選的商品地點的距離做特徵。然後用特徵構建模型算出一個分數，透過一定的閾值得到結果。

最後，我們的準確率可以達到95%，GMV和成交都得到了一定的提升。

3. 深度召回：向量召回

① 背景

前面提到的都是一些簡單的文字召回，以及LBS召回等偏傳統的方法。前面說過，我們的商品按照目的地切換後，還是很稀疏，還會存在無召回的情況。對於這種情況，我們想到引入向量召回的方式進行補充召回。可以覆蓋改寫沒有的情況，可以召回一些原來不能召回的產品。

② 向量召回整體架構

向量召回架構如上圖。線上透過對query 進行embedding。離線透過HA3引擎，把所有的item embedding儲存到HA3引擎中。最後，SP透過從QP獲得query embedding，進行HA3檢索，獲得需要的商品。

模型結構，如上所示：

query側：透過對query的文字，進行卷積層特徵抽取。商品側：我們主要的工作在這裡，除了文字上對使用者目的地的需求，對商品類目的需求也是比較關注的。所以在商品特徵上，使用了商品title文字的卷積特徵，以及目的地類目id 的特徵。

對這三個特徵，我們沒有使用簡單的concat，而是使用了tensor fusion進行三個向量的外積，可以讓特徵更好的融合。

最後，透過全連結層進行特徵抽取，計算向量內積。

對於損失函式，我們使用的large margin loss。對於學的足夠充分的case ，就丟棄掉，不再進行學習，讓模型更快的達到我們想要的效果。

④ 樣本選擇

在樣本選擇上，我們對正負樣本也做了一些探索。

集團內通用的方法：

正樣本：query下使用者點選的商品負樣本：未點選的商品

這樣的方法更適合在排序上使用，而不太適合召回。以左圖為例，使用者點選了“上海迪士尼度假區”，未點選的是下面的商品，雖然可能是由於商品的標題標準化比較低，使用者未點選，但不能說它是不相關的商品。

我們的方法：

正樣本：和集團一樣，使用點選的商品負樣本：隨機選取的樣本作為負樣本

使用隨機選擇有兩方面：一是在全量商品中，進行隨機選擇；二是在一個類目或者目的地下，進行隨機選擇。這樣可以提升訓練的難度，達到我們想要的效果。

⑤ 模型產出與使用方式

最終產出的分數，也給排序使用了，作為排序的一個特徵，取得了不錯的效果，可以排在第4位。另外，線上召回可以讓無結果率降低32.7%。同時，擴充了1.7倍的相似query。

4. 個性化召回

為什麼做個性化召回？

因為在旅行場景下，會存在一些泛需求搜尋。比如搜杭州，我們會對杭州所有的商品和酒店進行召回。這樣大量的召回會給後面的排序造成很大的壓力，沒辦法根據使用者的query排出一個使用者想要的item。

我們的方案有兩種方式：

引入推薦的召回結果，在此基礎上進行相關性粗排，得到個性化召回構建了個性化專用的向量召回模型，來得到更好的個性化召回結果

整體的方式是將召回池分為個性化召回和文字召回兩路：

個性化召回：透過推薦的重定向、i2i 、lbs2i以及屬性2i等方式，來獲得推薦召回結果。文字相關性過濾：透過文字相關性的過濾（如關鍵詞命中和向量cos相似度），把推薦召回和當前使用者搜尋query很不相關的item過濾掉，展現給使用者比較相關，也是透過使用者i2i擴充套件的結果。

個性化召回模型：

在使用者側，透過使用者畫像屬性和使用者的query，進行特徵抽取。另外，我們引入了使用者操作序列，來達到個性化目的。比如使用者最近搜尋時，檢視的商品、點選的商品、加購的商品以及成交的商品，這些操作的商品序列，引入到模型中。然後透過使用者畫像和使用者query特徵向量，對使用者歷史操作序列做attention，就能夠從使用者操作序列中取出跟使用者當前搜尋最相關的商品特徵，來滿足使用者當前搜尋的需求。在商品側，也會引入商品特徵。如商品title、商品目的地、商品類目等特徵，作為商品的優選，然後獲得一個向量。在上層，我們採用剛剛提到的tensor fusion來進行特徵融合，讓不同的特徵更好的融合。

模型最佳化：

在深度向量召回上，對文字的特徵採用卷積模型進行抽取。這裡並沒有採用卷積，而是採用了簡單的詞向量concat 方式。這是因為透過實驗驗證，使用卷積學到的文字特徵比較強，整體的個性化效果比較弱，這不是我們希望見到的。所以我們採用了減弱文字特徵的限制，突出個性化特徵帶來的額外檢索效果。

04

總結思考

最後，是我們對工作的思考總結：

1. Query & User Planer

現在我們還是叫QP，後續我們希望升級成Query & User Planer，能夠更多的融合使用者特徵，增加更多的個性化搜尋能力。

2. 可解釋性升級

我們希望對搜尋的可解釋性進行升級，不是簡單的用文字或者深度向量直接進行召回。我們希望對使用者的意圖，進行更多維度、更細力度的理解，能夠直接理解成人類可讀的意圖。