導讀:知識圖譜憑藉能夠以圖模型描述知識和世界萬物關聯關係的特性,在各行業領域大放異彩。與此同時,知識圖譜技術也為場景搜索帶來了新的挑戰與機遇,在此背景下,美團團隊進行了新一輪的技術革新,將知識圖譜技術應用於酒旅場景的認知中。本次的分享題目為《知識圖譜在美團搜索酒旅場景認知中的應用》,主要介紹:
- 酒旅業務特點
- 酒旅場景認知
- 酒旅知識圖譜
- 基於場景認知的搜索方案
01
酒旅業務特點
提起美團點評,你想到的是?外賣、美食、電影?
其實美團有的不止這些,還有同樣佔據行業TOP的酒店和旅遊業務!
酒旅業務和美團其他的本地生活服務到底有什麼區別?區別在於酒旅業務的出行半徑更大。美團大部分的服務如劇本殺、電影等只需要找到滿足用戶在當前區域或者當前城市內的商戶需求即可,而對於酒旅業務,用戶具有更大的出行半徑。以三個例子對酒旅業務的特點做更好的解釋:
1. 滑雪/看海
某北京用戶想要滑雪或者看海,用戶可能會選擇距離北京200多公里的質量更高的崇禮滑雪場;對於看海,因為北京當地沒有相應的供給,所以用戶可能前往秦皇島的北戴河。所以,對於本地沒有相應供給的服務,用戶可能會去周邊具有相應服務的城市甚至是尋找全國各地具有相應服務的城市,此時就需要美團為用戶查找和篩選出合適的場景與適配場景的商戶。
2. 酒店
以酒店為例,介紹用戶常用的幾種搜索方式:
①地標/商圈。用戶圍繞地標或者商圈尋找酒店,該模式更傾向於推薦的問題;
②商家/品牌。該類用戶目標明確,尋找某個具體酒店或對應品牌下的酒店;
③泛場景搜索。比如用戶尋找某一類的商家如青年旅社、具備某種設施的酒店又或者是具體的房型比如電競房等等。其他搜索方式主要是圍繞這三種搜索的組合進行展開的。
3. 景點
景點的搜索同樣也可以分為三類主要的方式:
①行政區/地域。用戶搜索某一區域或者行政區,則美團需要找出該區域內相關的景點;
②商家/品牌。該類用戶同樣目的明確,會直接搜索相應景點的名稱如故宮、歡樂谷等等。
③泛場景搜索。用戶查找某一類需求,比如滑雪、爬山,此時具有相同屬性、服務項目或同類型的多個景點均可滿足用戶需求,該場景下,美團需要為用戶做出更好的推薦。
--
02
酒旅場景認知
1. 什麼是場景認知
平台中存在大量不同業務類型的商家,如酒店、景點、美食等。用戶在平台上發起搜索時,我們認為其搜索行為是需求場景的顯式表達,即可以通過對用戶搜索行為場景化的理解,去識別用戶的需求場景。將用戶需求場景通過標籤的方式表達後再去進行商戶的標籤檢索,由此可以將用戶和能承載其需求的商家匹配起來。
2. 為什麼要做場景認知
為什麼要做場景認知——希望從不同場景需求出發做差異性的體驗優化。
以搜索「中山公園」為例:原來的搜索方案會從文本的角度召迴文本相關的結果,但這並不能滿足用戶的需求。我們通過對用戶行為數據的分析,發現大部分在北京發起「中山公園」搜索行為的用戶往往會圍繞北京本地的中山公園及其周圍的場景發起後續動作。
這本質上代表了一類用戶的場景需求,為了更好地滿足這一場景需求,我們採用了圖中右側所示的推薦方法。首先發現用戶查找的主點,然後圍繞主點為用戶推薦其他的服務,如相關景點、附近美食等等,更好地滿足用戶多元化的需求,並且通過該主點模版樣式為用戶提供更多能夠幫助決策的信息。
這種需求的變化為我們提供了新的解決問題的思路:
- 通過產品樣式升級的方式來滿足用戶的多元化訴求;
- 隨着產品樣式的改造,倒逼新一輪的技術升級。
3. 有哪些場景
對於酒旅業務,可大致將場景分為兩大類:精確的商家搜索、泛場景搜索。
(1)精確商家搜索
精確商家搜索可具體分為:
- 單主點搜索,如故宮、北京昆泰酒店即只有唯一對應的主點,可以圍繞該主點為用戶推薦服務和商家。
- 多主點搜索,如方特。全國有多家方特歡樂世界,此時便可用多主點的樣式為用戶提供信息。
(2)泛場景搜索
泛場景的搜索可具體分為:
- 地標+X,如「鳥巢附近的青年旅社」,此時需要為用戶推薦主點鳥巢附近的青年旅社;
- 本地+X,如在北京的城市頁面下搜索「爬山」,此時需要推薦本地以及周邊範圍內能夠滿足用戶需求場景的商戶;
- 全國+X,如搜索三山五嶽,該場景下需要幫用戶召回全國各地符合用戶場景需求的結果。
4. 場景認知難在哪裡
最基本的問題是對需求場景的理解需要依託於底層大量的領域知識。基礎的結構化數據並不會攜帶場景類表達,因此需要做額外的挖掘和理解,舉例說明:
(1)搜索和珅府。搜索和珅府應該出現恭王府這個POI,此時便需要挖掘出和珅府是恭王府的別名;
(2)搜索安靜的酒店。此類搜索為泛場景搜索,首先需要在B端對酒店做知識挖掘,挖掘酒店是否具有良好的隔音特點;其次,需要將線上的query和已有的B端知識進行準確地關聯,比如「安靜」的表達映射到的底層的知識標籤是「隔音好」。
--
03
酒旅知識圖譜
1. 酒旅知識圖譜的搭建
(1)概覽
美團酒旅知識圖譜大概覆蓋80萬的酒旅商家、1億條用戶評價、積累100萬原子概念以及組合後的150萬的需求概念、1200萬商家與概念的關聯關係。
(2)四層定義
在圖譜應用過程中,根據用戶需求應用維度,將圖譜分為四層:
- 類別體系層:結合不同業務特點,進行類目的劃分。以旅遊為例,定義了15個一級類目,在此基礎上再拆分二級和三級的具體類別體系;
- 原子概念層:從用戶評論、商戶信息中挖掘和抽取出原子概念層;
- 需求概念層:對原子概念層的數據進行篩選以及符合語義維度的組合,構建面向搜索需求的概念層數據。比如原子概念層中的爬山,在需求概念層中具有直接映射的標籤,而對於親子和溫泉兩個獨立的語義,當有真實的用戶需求場景時,便會組合出一個更準確維度的「親子溫泉」標籤。這解決了線上搜索query,如果只用最細粒度原子標籤進行召回時會出現的語義漂移問題。所以在成本允許情況下,採用基於組合的需求概念層的效果會更好。
- POI層:判斷當前的商戶是否具備需求概念層的標籤或知識所代表的屬性以及特點。
(3)挖掘流程
- 知識抽取
數據來源主要有三類:結構化數據、半結構化數據、非結構化數據。從這些數據源中進行知識抽取,初期沒有足夠的標註數據時,採用基於半監督的方法做Auto Phrase、依存句法分析等;有了知識積累後,採用NER的方法進行更好的抽取。
- 知識分類
將知識片段根據前面所提到的一二三分級的知識體系進行分類。下圖所示,將知識庫與泰山風景區相關的類目以及最底層所關聯的知識片段進行關聯。對於泰山風景區,最底層數據只有自然風光,但是我們希望能夠將其語義理解到更細粒度,比如自然風光中有峽谷、瀑布、山等等,此時需要注意泰山風景區擁有哪些自然風光類型。同樣地,泰山風景區適合哪些活動,在人群角度,比如適合情侶約會、畢業旅行;場景事件角度,適合戶外類的爬山、日出日落。這些數據可以為後續query的理解、鏈接、推薦理由的生成奠定基礎。
2. 圖譜搭建的關鍵環節的做法
(1)定義知識體系
構建垂直領域的知識圖譜時,需要結合領域知識進行業務的定義。以景點為例,大概有15個一級類目,每個一級類目下還存在二、三級類目,三級的分類體系就能較好滿足面向搜索的需求。
(2)知識抽取
業務初期,採用半監督的學習方法即Bootstrapped pattern-based learning積累知識,以挖掘動物相關實體為例,大致流程為:
- Step1: 構建種子實體詞,在該例子中為dog;
- Step2: 根據實體詞dog,從語料中挖掘出dog前述的pattern:own a、my pet;
- Step3: 用候選的pattern進一步挖掘與上述pattern相匹配的實體知識片段:house、cat;
- Step4: 評估house和cat哪一個和dog相同,屬於動物這一類型。
經過幾輪迭代後,發現對於動物相關的實體詞,my pet是更好的pattern,因此便用該pattern去挖掘擴展出更多的實體,前期用這種方式可以快速積累數據。
有了標註數據後,就可以採用NER的監督學習方法進行更好地泛化識別。最初採用BERT+CRF的模型進行抽取,但該模型容易將知識實體的語義片段切碎。如下圖所示,評論為「金頂看峨眉四大奇觀」,抽取到的是「峨眉四大奇」,但我們希望片段能夠盡量完整。後來通過引入KG相關信息的方法解決了該問題,首先將需要抽取的文本進行分詞,同時引入了Character-level粒度和Word-level粒度的兩層向量信息,輔助判定片段切分的邊界,這樣能有效解決片段被切碎的問題。
起初為了效率,對前面提到的15個一級類目中的每個類目進行單獨地抽取,後續為了提升準確率,便將相關的大類放在一起進行綜合的知識抽取,在該過程中會存在知識分類不準確的問題,進一步優化考慮的是採用多任務聯合訓練的方法,即將知識分類的任務和NER任務融合起來。
大致思路是:通過第一層編碼(採用BERT或BiLSTM編碼)之後的向量信息,再用傳統的CRF進行NER切分,之後採用casecade級聯的思路將向量信息引入分類層進行識別和處理。該工作對整體的準確率和召回率都有比較好的提升(發表於2022的DASFAA會議中)。
(3)知識分類
將知識進行一級類目的初分後,需要將知識進行更細粒度的分類,但是因為業務特點,很多知識片段會屬於多個二級或者三級類目中的節點,所以這裡採用了多標籤分類的任務對原始的文本分類片段。比如對於VR項目「飛越地平線」,將片段「飛越地平線」使用BERT進行編碼並直接進行識別時,很容易將其分類為過山車的項目,因為形如「飛越XXX」的表達詞在更多情況下指的並不是VR項目而是過山車或者其他項目。
為了更好地解決該問題,抽取到該片段後,在模型中引入該片段的上下文信息,豐富上下文表達。同時,在搜索日誌和評論日誌中進行特徵工程處理,添加人工構建的特徵,並將這些特徵融合,統一進行分類,這樣就可以解決單獨文本會產生語義偏移的問題。
(4)知識與商家關聯
抽取到知識片段並分類後,需要解決知識(標籤)與平台商家進行關聯的問題。
首先,需要明確的是上述問題不是封閉域標籤問題而是開放域標籤問題,即並不是單純進行類目體系的分類掛載問題,因為標籤會隨着業務的發展以及挖掘不斷累積和新增,我們需要對這些新標籤和知識進行分類,所以打標需要具有一定的泛化能力。
結合平台進行說明:平台主體是商戶,我們需要找到具備知識或者標籤的商戶。商戶具有很多用戶評價以及下掛商品,我們直觀能得到的是每一條評價和知識的相關性以及每個商品與知識的相關性,反饋到商戶的相關性,中間多了一層聚合的過程。
這個問題的解決思路是多人投票機制,即商戶下掛的每一條信息,都是一個用戶的反饋,判斷相關還是不相關又或者是其他觀點,將這些信息進行聚合以及投票的方式就能得到商戶具不具備這個知識或標籤。
舉個例子,判定某個景點是否可以帶寵物:
- Step1:找證據,尋找與帶寵物相關的文本表達;
- Step2:判斷抽取的短片段的真假,主要分為正相關、不相關、負相關;
- Step3:多證據融合分類,除了前面得到的證據相關性,又根據語義特徵和統計特徵抽象出很多維的特徵信息,比如POI本身信息的文本相關性,該過程主要使用BERT模型進行文本相關性的匹配。
- Step4:分佈置信度判定,將前兩步得到的相關性喂入樹模型,最終得到分類結果,即是否相關。
若是線上進行知識分類,對準確率存在要求,允許一定召回上的損失,但是需要保證結果是準確的,這樣才能在線上給用戶更好的體驗。所以在最後一步增加了分佈置信度判定的過程,即將打標結果中的商戶類目做分佈統計,過濾長尾類目的POI,比如用戶搜索爬山時,經過類目統計後,在個別判定錯誤的情況下,存在溫泉類目佔比0.3%的情況,根據閾值將這一類結果進行過濾。
(5)MT-BERT
不論是知識抽取還是知識分類,都用到了BERT模型,美團主要用自研的MT-BERT,其特點是引入了美團業務場景下的大量用戶評論信息以及商戶下掛的業務類信息,對模型進行更好的適應。
MT-BERT加入了美團UGC數據之後,在一些公開的數據、內部的query意圖分類以及成分分析任務上都有比較顯著的提升。
--
04
基於場景認知的搜索方案
1. 服務搜索五層架構
將服務搜索分為五層:
- L0層:挖掘相關的知識,構建索引;
- L1層:識別與理解用戶query,進行結構化召回;
- L2層:基於召回結果,對列表進行深度學習模型排序;
- L3層:在不同的業務場景下,進行針對性的策略調整;
- L4層:給呈現列表時,提供標籤、推薦理由、榜單等可解釋信息,強化感知。
2. 兩大類搜索意圖下的方案
(1)精確商家搜索
對問題進行建模:首先,識別主點;其次,圍繞主點推薦相關商家,包括景點以及附近的酒店等等。第二步再具體細分:當用戶處於規劃決策環節時,可以為用戶推薦可替換主點的商家;當用戶已經確定要在某主點進行消費時,可以給用戶推薦可搭配行程的商家
前文所述中存在2個技術點:
- 如何識別主點,內部叫商家鏈接或主點鏈接即實體鏈接的變種。
- 如何圍繞主點進行更好地推薦。
①技術點1:如何識別主點
採用基於上下文信息的實體鏈接方案。用該方案的原因是:美團業務中,搜索同樣的query詞,在不同的地理位置,所需要的結果可能是有所差別的。舉例說明,在上海安化路492號即龍之夢酒店附近搜索龍之夢酒店時,用戶大概率想找的就是他附近的龍之夢酒店。
具體策略中主要分為兩個分數:第一個分數為詞序列,即當前能夠鏈接到某一實體的序列片段和該實體之間的概率預測分數,基於搜索日誌以及知識圖譜對商戶的別名表達,來得到綜合評分;第二個分數為結合上下文的信息得分,結合業務特點將該得分分為兩部分,首先為文本語義本身的上下文的語義得分;其次為地理上下文得分,即根據用戶和商戶之間的距離計算分數。
②技術點2:如何更好地召回
採用兩種方法用於召回:
- 基於用戶行為序列的向量相關性
將用戶點擊過的所有POI構成序列,並基於skip-gram進行編碼得到POI向量,再跟主點的POI向量進行計算,得到跟其相似的頭部POI。值得注意的是我們根據業務特點進行了針對性調整:首先,酒旅業務是相對低頻的業務,所以我們會聚合用戶更長時間內的行為序列,重點解決低頻問題。其次,隨着季節性、不同城市行為特點的差異性,我們引入了城市、時間、品類、價格等等side-information來更好地計算向量的相關性。
- 基於GCN的向量相關性
每個POI都具有相關知識,我們構建了User-Query-POI-Item(知識)的異構圖,通過圖學習的方法得到POI的向量。
(2)泛場景搜索
對問題進行建模:首先,識別有哪些場景需求;其次,基於場景檢索商家並個性化排序;最後,解釋為什麼結果可以滿足場景需求。
舉例說明,在北京搜索「適合遛娃的公園」,則要找的區域是北京,query中不同的文本片段會鏈接到不同的標籤,而標籤之間也存在主從概念,因此可以推理出上位場景、同位場景、觸發的榜單以及需要展示的標籤,最後拼成召回語法進行後續處理。
泛場景搜索涉及到了三個主要的技術點:
①技術點1:泛場景鏈接
對query進行識別,即對場景標籤進行鏈接。該過程主要在線上進行,並且分為六個步驟:
- Step1: 觸發判定,判斷當前query是否是泛場景搜索的類型。比如故宮博物院是精確搜索而不是泛場景搜索,爬山便是泛場景搜索。同時這一步還需要識別相關意圖,比如判斷搜索意圖是景點、酒店還是餐飲等等;
- Step2: 對query做預處理的工作,包括分詞、Non-Link以及對目標區域的識別;
- Step3: 根據處理後的片段生成候選序列,進行多元組合,也會用到跳鏈的技術。比如現有A、B、C三個片段,可能會生成如下的ABC、AB_C、A_B_C、AC的序列;
- Step4: 用組合出的序列,進行倒排索引的召回,中間還包括白名單匹配、模式匹配、向量召回等等去擴展相關的標籤;
- Step5: 標籤排序,對上述召回結果進行排序。該過程有幾個重要特徵,包括當前實體和序列的相關性、query和實體的相關性、mention信息以及點擊聚合歸因後的統計特徵,把這些糅合在一起進行分類,在不同業務中分別選取topN的標籤進行應用;
- Step6: 終判環節,對識別出的多個片段鏈接的不同標籤進行消歧和推理的工作。
②技術點2:排序
該技術點考慮的是如何更好地進行基於場景類搜索的個性化的排序。泛搜索類的表達在POI名稱維度的語義上是缺少語義相關性的,所以需要在模型中補充知識維度的信息。
首先,在特徵層面,要豐富商家基於KG的語義表達向量,主要採用以下方法:
- 基於多域的結構,引入標籤的文本信息;
- 採用GCN的結構,訓練得到POI和query之間的向量,將向量引入到後續模型中。
其次,在模型結構上,對用戶興趣場景和商家場景做序列建模。該工作中的創新點:
- 當前在排的POI與跟用戶的long-time sequence以及short-time sequence的attention工作,其中,long-time sequence以及short-time sequence指的是用戶更長時間內點擊過的POI的行為列表以及更短期的行為列表所生成的序列編碼;
- 引入了tag的序列。將識別出的當前用戶要找的需求場景的標籤,與用戶之前有過行為的商戶的tag進行聚合,變成序列;POI本身掛載的tag的知識信息同樣是序列,將這兩個序列編碼後做attention工作,能夠更好地捕捉到泛場景搜索下,用戶的需求場景標籤與商戶場景序列以及用戶興趣序列之間的相關性。
③技術點3:結果可解釋性
該技術點考慮的是如何更好地向用戶解釋為何當前結果和搜索場景是相關的。該問題一部分通過推薦理由實現。推薦理由有兩種實現方法:抽取式推薦理由、生成式推薦理由。
- 抽取式推薦理由
該方法通過抽取的方式挖掘相關的推薦理由,抽取時主要分為兩大場景:
第一類,如搜索「爬山」。該類query屬於具體的場景,在該具體場景下,我們希望給用戶提供的推薦語是直接跟場景有關的,即其他用戶來該景點時,對該地適合爬山的表達。對於這一類推薦理由,採用文本匹配並結合BERT-MRC的思路對候選句子進行召回。
第二類,如搜索「上海旅遊」。該類的query的範圍比較泛,因此在該場景下,會給用戶推薦默認的特點,即景點本身的特點描述。對於這一類可以直接代表商戶特點的推薦語,採用短句的組合以及結合pointer-generator網絡抽取的思路,生成候選的句子。
當有了候選推薦語後,不論是用戶的推薦語還是商戶本身的推薦語,都會統一進入判定的模塊,對候選的句子進行一系列質量的判定,包括句子的改寫、表達通順度、表達情感等等,通過這些模塊得到多維的分數,最終作為特徵喂入樹模型中進行整體的質量判定,得到終判分數。
- 生成式推薦理由
抽取式推薦理由能解決大部分問題,但也存在一些問題:
句子表達的意思正確但偏長,而前端給用戶展示時存在句子長度限制。所以為了能夠更好地利用偏長的句子或者意思沒有問題,但表達比較生澀、沒有亮點的句子,採用基於transformer的網絡結構對部分句子進行壓縮,讓其符合句子長度的限制。
此外,很多POI下面的評論本身比較少,而且用戶的表達質量較差,並且我們對推薦語的整體把控比較嚴格,所以導致挖掘不到與場景相關的推薦語。
此時,便考慮基於商戶已有知識生成推薦語,進行數據擴展。該思路基於KG和場景關鍵詞生成的方案進行實現。存在兩個要點,舉例說明:首先,「司馬台長城」在Word embedding層中存在與POI相關的標籤;其次,對tag進行控制,控制根據「春遊」標籤產出的相關推薦語。通過這兩個維度綜合進行編碼,最後得到生成的片段,encoder後得到 「春季片花浪漫,夏季滿眼蔥翠」。基於這個句子進行前文提到的句子質量判斷。用該方法補充召回,再統一產出最終推薦語的離線候選。
上述介紹的是在離線環節生成推薦理由的相關候選,不論是抽取式還是生成式,部署到了線上後,還會涉及到具體線上流量的分發。即當列表中都是符合用戶場景需求的內容時,需要進一步考慮:首先,推薦語和query具有相關性;其次,列表中的推薦語不能過多的同質化,要穿插多樣的表達方式;最後,要保持內容新穎等等。
總體來說,從底層數據層到上游展示層,整體架構會分很多層,具體結構如下:
今天的分享就到這裡,謝謝大家。
分享嘉賓:陳騏 美團 高級算法專家
編輯整理:毛佳豪 中國平安浙江分公司(實習)
出品平台:DataFunTalk
01/分享嘉賓
陳騏|美團搜索與NLP部 高級算法專家
2015年碩士畢業於中國科學院計算技術研究所,同年加入美團,參與了酒旅搜索和推薦從0到1的搭建與技術演進過程,有很強的業務建模能力,現擔任場景搜索和旅遊搜索方向技術負責人,主要關注語義理解、知識圖譜、數據挖掘和深度學習排序等技術在業務場景下的落地與算法優化。
02/關於我們
DataFun:專註於大數據、人工智能技術應用的分享與交流。發起於2017年,在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會,已邀請超過2000位專家和學者參與分享。其公眾號 DataFunTalk 累計生產原創文章800+,百萬+閱讀,15萬+精準粉絲。