LTR：應用於電商智慧客服領域知識庫搜尋的實踐

 

 

 

 

搜尋引擎排序（Ranking）的優化是搜尋領域中普遍遇到的問題，通常會涉及到很多的排序策略，傳統的排序方法一般通過構造相關度函式，然後按照相關度進行排序。影響相關度的因素很多，也有很多經典演算法模型來滿足這一需求，但是對於傳統的排序方法，有很多特徵資訊的情況下，單一的函式或者模型很難融合很多引數，也容易出現過擬合的現象，而機器學習方法很容易融合多種特徵，能一定程度的解決稀疏、過擬合等問題。因此，以機器學習的理論基礎來解決ranking問題便形成了Learning to Rank（學習排序、LTR）的方法。

 

Learning to Rank是在機器學習領域中有監督學習（Supervised Learning）的排序方法，如今已經被廣泛應用於搜尋場景、推薦場景、QA場景、情感分析場景中。比如傳統的web search，文字挖掘，推薦系統，QA中的結果排序，機器翻譯中排序候選翻譯結果等等。

 

本文主要介紹LTR在限定領域知識庫搜尋的優化中的簡單應用的過程。

 

 

隨著網際網路互越來越普及，作為電商平臺，如何提供給大群體的買家，賣家以最優質的服務已經成了一個重點話題，也是一直在解決的難題。常見的人工智慧（AI）客服系統，比如語聊機器人大部分智慧解決使用者QA類簡單諮詢問題。在我們的人工智慧客服系統-阿里小蜜中，機器人智慧問答是使用者接觸的第一層服務。當機器人遇到解決不了的複雜問題，比如流程性較強，個性化的問題時需要人工線上解決，此時使用者會接觸到線上人工客服，而非機器人。而本文的討論的產品方寸就是一款應用於人工客服端，輔助人工解決使用者各類問題的智慧工具，致力於解決業務問題場景複雜，客服人員人數少且服務水平良莠不齊，但是要提供給客戶統一優質的服務等一系列問題，以輔助越來越多未經過專業客服技能培訓的人員快速上崗同時不降低服務質量，來滿足越來越多的使用者服務需求。本文介紹的就是方寸中的知識搜尋功能。

 

 

在使用機器學習理論之前，方寸搜尋使用的是比較傳統的知識庫檢索的方式：使用常見的NLP演算法元件為所有知識的標題做好分詞和同義詞後使用opensearch構建索引，檢索過程中，先使用使用者query item直接recall至多不超過500條資料，再對召回結果和query詞做相似度排序。這種簡單檢索的方式慢慢無法滿足我們的客服人員對於越來越多而且越來越複雜的業務知識的搜尋。

 

一般行業內的搜尋分為：檢索、粗排、召回 （basic search），精排（advanced search）包括相關度打分，個性化特徵精排，rerank 等等。LTR理論常用於搜尋精排ranking，作為有監督的學習過程，學習資料來源最常見的還是標註，標註一般分為三級分數（相關，一般相關，不相關）或者五級分數（非常相關，相關，一般相關，不相關，非常不相關），但成本非常大。經過大量的資料分析，我們最終選擇了非人工標註的方式-日誌分析。在web search或者較複雜的搜尋場景中，日誌分析常用於basic search中召回的features，比如搜尋，瀏覽，是否點選，點選後停留時間，是否換query，點選後的操作，收藏，轉發，分享等互動行為，而個性化特徵精排會比較傾向於用使用者特徵，比如性別，年齡，收入，身份，興趣，群體甚至一些外界自然因素比如季節，天氣，時間等等作為特徵來標註資料分析。我們選擇非標註的方式除了基於大量的資料分析之外，也和業務場景有關，在一個限定領域的知識庫搜尋這個場景下，user相關的上下文的使用者資訊特徵幾乎只和身份（客服人員所屬部門，許可權等等）相關，不太具有個人特徵，而且document又是標準化的知識，因此最終決定使用日誌分析的方式獲得資料。

 

 

 

如上圖所示，應用互動層發起搜尋請求，經過opensearch的基本檢索召回500條結果，之後進入rerank階段，主要依賴LTR演算法以使用者的歷史行為為重要特徵做重排序，最終再將排序後的結果返回給使用者端。

 

Learning to Rank一般有三種常見方式：Pointwise、Pairwise 和 Listwise。Pointwise是對每一個query和document的打分排序，是比較常用的方法，優點是簡單，缺點是出現mismatch的時候是無法找到退而求其次的選擇的。於是就有了Pairwise作為現在比較流行的一種方式，Pairwise其實並不針對使用者輸入，而是比較備選誰更好，不關心絕對值的得分，能有效的縮短絕對資訊。但是標註的工作是比較多的，假如同一個query有A ，B，C三個備選目標，標註A比B好就是AB1，B不如C就是BC0，類似這樣。目前流行的Pairwise的演算法和paper還是比較多的，比如Ranking SVM，RankNet，RankBoost等等。Listwise相較於上面兩類是比較不同的，個人感覺更適合作為推薦系統中的ranking，具體過程是將每個query對應的全部搜尋結果作為一個訓練sample，根據這個sample訓練得到最優評分函式f，ranking的時候對於新的query，f對每個文件打分，然後根據得分高低排序為最終結果，本質上是學習排列組合中最高概率的方法。除了這三種主流的方式，針對不同的需求和調整，也有很多通過這三類衍生出來的方法，思路大致一致就不再一一列舉。

 

通過以上簡單的基礎知識介紹和我們所面臨的業務場景的分析，我們嘗試了將Pointwise的思路運用到上文提到的限定領域的知識庫搜尋中。我理解的在我們應用場景中的Pointwise更像把搜尋的ranking成了使用者點選/沒點的一個分類問題。而其他重要特徵主要分為3類：1. Relevance Feature：query詞的match或者overlap簡單理解成字面相關性；2. 語義相關性； 3. 搜尋目標本身的特性，類似於web search的page rank。因此，除了基於日誌資料的是否點選，我們也做了TF-IDF的計算作為排序依據。下面舉一個非常簡單的例子來說明（非線上真實資料）： 

 

 

上圖列舉了兩組query和兩個標題為例，第一組query詞是【蘋果】按照tfidf相似度得分來看應該是問題【蘋果是水果嗎】作為ranking第一位的，但是由於訓練資料中搜尋過【蘋果】的點選了問題。所以最終的ranking順序會受到點選資料的影響，如何購買蘋果手機將排在第一位。當然這個結果也會有一些陷阱，使用者對於排在前面的搜尋結果會帶有天然好感，因此互動影響會造成資料影響，日誌又來自於上一次模型，因此引導使用者的bias的獨立分桶實驗也是十分重要的。

 

 

Learning to Rank應用於方寸搜尋場景上線後，隨著資料的積累和學習，搜尋轉化率最終提升了10%左右，因此印證了在限定領域的知識庫搜尋場景中，機器學習理論對於ranking有著非常有益的幫助。下圖為8月到12月的搜尋點選轉化率和Top5點選轉化率值，從9月底上線後的資料變化。

 

 

綜上，搜尋的本質其實就是，user的特徵（當然其中最重要的是輸入query）和目標列表中的值（也包含自身特徵）的match過程，而我們基於使用者過去的歷史行為來做ranking就是基於機器學習的理論基礎。ranking problem 目標排序，期望在過去的歷史資料建立學習系統得到排序方式。

 

這次實踐過程總結了一些解決此類問題的經驗：最重要的是分析資料，tips具體有以下幾點：

 

1.   選擇合適當前業務場景的模型，流行的演算法或者高大上的paper不見得真的合適，學習其中的理論和思路，實際落地的過程最重要的是對業務和對資料的理解基礎上找到適合自己的方法。

 

2.   Leaning中選擇合適的損失函式（Loss Function）有很多解決不平滑無法求導的方式。另外像隨機梯度下降，平行計算等可以在leaning中根據情況考慮。筆者本身是開發，所以也會在架構和實現方面會多考慮一些。

 

3.   根據業務場景科學的選擇合適的Evaluation方案，同時考慮建立標準測試集和自動迴歸測試方案。

 

 

關於機器學習在ranking的應用，本文想分享的並不是理論上的知識，是應對不同的場景的實踐過程。首先，解決此類問題最重要的日誌分析，要對自己的業務有足夠的理解。比如，在特定的搜尋場景中，轉化率的概念，如何評估滿足了使用者。比如搜尋點選轉化 、停留時間是否足夠衡量搜尋是否優秀。同時，需要注意的是點選瀏覽之後的行為鏈更為重要，但是在我們的業務場景下，受干擾的影響條件太過複雜暫時沒有使用。但在其他典型搜尋場景中，瀏覽後的分享，收藏行為也是LTR的重要特徵。比如在電商的商品搜尋中，點選後加購，下單，或者分享除了使用者特徵也可能受目標特徵影響，比如價格，甚至受環境比如大促期間等等影響。第二，學習的特徵來自與資料探勘：使用者資訊做個性化query-term資訊，轉化後點選位置，timing時序概念，時間串聯的使用者行為鏈以及使用者歷史行為的捕捉。同時不能忽略互動帶來的資料影響，最好做獨立分桶實驗。最後，本文沒有涉及的是使用者個體個性化的搜尋探索，主要原因前文也有提到，業務場景並不是剛需，不過業界很多做個性化使用者興趣來影響ranking的方法也在實踐過程中給到了很多思路。

 

本文介紹的是搜尋中query full場景，是有使用者主動輸入query的，同時未來還會將這套理論結合深度學習應用於query less場景即無使用者輸入主動推薦知識，敬請期待。