自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

攜程實體鏈接技術(shù)的探索及實踐

移動開發(fā) 移動應用
本文主要介紹了旅游AI知識圖譜組在實體鏈接技術(shù)上的探索和實踐,闡述了實體鏈接的基本定義、相關(guān)技術(shù)發(fā)展路線和應用價值,并結(jié)合各子模塊詳細說明了基于旅游知識圖譜的實體鏈接系統(tǒng)的架構(gòu)和流程,最后介紹了實體鏈接系統(tǒng)的落地場景。

?作者|攜程旅游AI研發(fā)團隊致力于為攜程旅游事業(yè)部提供豐富的AI技術(shù)產(chǎn)品,其中知識圖譜組專注旅游領(lǐng)域知識圖譜的構(gòu)建及應用落地。

 一、背景介紹

隨著網(wǎng)絡應用技術(shù)的飛速發(fā)展,多元化、低密度數(shù)據(jù)的急劇膨脹對人們獲取正確信息帶來巨大挑戰(zhàn),大量冗余信息出現(xiàn)的根源在于自然語言表達的多樣性,即一詞多義和多詞同義。例如,“蘋果”在不同語境下既可以表示薔薇科蘋果屬植物又可以表示蘋果產(chǎn)品公司,“申城”和“魔都”盡管字面完全不同,卻都是上海市的別稱。實現(xiàn)對海量Web數(shù)據(jù)的高效處理,理解用戶意圖,降低信息過載,是實體鏈接的目標。

在旅游領(lǐng)域,用戶關(guān)注的實體通常是旅游目的地周邊景點、酒店和玩樂方式等,這些對象在地理信息系統(tǒng)(Geographic Information Systems, GIS)中統(tǒng)稱為興趣點(Point of Interest,POI),主要包含四個核心維度:名稱、地址、坐標和類別。隨著互聯(lián)網(wǎng)電子地圖服務與基于位置的服務(Location Based Services,LBS)的普及,POI無論從概念范疇還是信息縱深上都有了長足發(fā)展,已成長為信息空間的參天大樹,可以說目前如日中天的互聯(lián)網(wǎng)各個風口都和POI有一定關(guān)系,如電商、O2O、社交、本地生活、互聯(lián)網(wǎng)金融、共享經(jīng)濟等。

構(gòu)建以POI知識庫為基礎(chǔ)的實體鏈接服務,提升旅游搜索、智能問答、知識挖掘和信息抽取等工作的效果,對改善用戶體驗有重要意義。

二、問題分析

實體鏈接,指將文本中的表述鏈接到知識庫中相應實體來進行實體消歧、幫助計算機理解文本具體含義的任務,一般包含實體提及識別、候選實體生成和候選實體消歧三個步驟。

圖片

圖1 實體鏈接功能示例

1)實體提及識別,旨在識別出自然語言中實體提及片段的邊界,并標示其在輸入文本中的位置。以圖1例子進行說明,用戶輸入的搜索詞“武漢東湖景區(qū)”包含了“武漢”和“東湖”兩個命名實體提及,它們可能表示知識庫中某些實體的正式名稱、簡稱、俗稱或者別名。

2)候選實體生成為文本中給定的實體名稱生成可能鏈接的候選實體集合,即根據(jù)前一步識別到實體提及片段從知識庫中召回所有用戶可能感興趣的實體,該步驟生成的候選項集確定了實體消歧的范疇。例如,“武漢”這一實體提及可以從知識庫中召回作為城市的“武漢”,而“東湖”則可以召回“武漢東湖”和“紹興東湖”兩個景點。

3)實體消歧是確定一個實體指稱項所指向的真實世界中實體的過程,通過候選實體的靜態(tài)特征、或與query交互計算的動態(tài)特征輸出一個用于排序的分值。以圖1為例,結(jié)合上下文可知,用戶真正查詢的是武漢市下面的東湖,而非位于紹興市的東湖,因此“武漢東湖”相對“紹興東湖”應有更高的得分。

實體提及識別常被視作序列標注任務,經(jīng)典方法有基于詞典的方法和基于統(tǒng)計的方法。基于詞典的方法可分為前向最大匹配、后向最大匹配和雙向最大匹配;基于統(tǒng)計學習的代表方法有HMM和CRF,其表現(xiàn)通常依賴大量人工構(gòu)建和維護的特征模板。隨著算力的提升和端到端的神經(jīng)網(wǎng)絡技術(shù)的發(fā)展,CNN、RNN等結(jié)構(gòu)被廣泛用于建模序列表示,其自動組合低階特征獲得高階特征的功能擺脫了人工特征工程耗時費力的弊端,同時神經(jīng)網(wǎng)絡強大的表達能力顯著提升了傳統(tǒng)算法的效果。

Google在2018年提出的Transformer則首次將自注意力模型帶入大眾視野,為序列表征的高效并行計算提供了可行的方案。Self-attention機制的運用使得序列中每個位置的token都能充分學習到上下文語義,自適應地接收來自不同位置token的信息流入,成為近年大熱的自監(jiān)督學習任務的基本編碼單元,啟發(fā)了眾多以此構(gòu)型為基礎(chǔ)的大型預訓練語言模型,BERT便是代表之一。

使用Transformer Encoder結(jié)構(gòu)的BERT從無標簽語料中學到了大量先驗知識,只需在特定下游任務上微調(diào)權(quán)重,便能獲得出色的結(jié)果。BERT一度霸榜GLUE,刷新了各大自然語言理解任務的SOTA,其預訓練加微調(diào)的學習范式也成為NLP界的重大里程碑。

候選實體生成是一種檢索任務,傳統(tǒng)檢索方法以詞袋模型(Bag of Words,BOW)為代表,如TF-IDF、BM25等,這類算法不考慮詞序,也忽略了詞與詞之間的前后關(guān)聯(lián),除需人工設計公式外,在統(tǒng)計詞的權(quán)重、詞頻的基礎(chǔ)上,還要引入覆蓋率、緊密度,擴展同義詞等,才能達到一個較好的效果。詞袋模型最大的缺陷是只能解決字面量的匹配問題,無法獲得query與document語義相關(guān)性,因此,以雙塔式模型和交互式模型為代表的語義向量檢索方案開始受到重視。

雙塔模型主要有DSSM、Siamese網(wǎng)絡,通常使用兩個相同或不同的編碼器來提取query和document的低維句向量表示,然后設計一個相關(guān)性函數(shù),如cosine、內(nèi)積等,計算兩者間的相似得分;交互式模型則在低階特征組合階段就開始建模query與document之間的相關(guān)性,其關(guān)鍵思想在于交互矩陣的構(gòu)造,如ESIM、MatchPyramid等,這類模型最終獲得的是query-document對的整體表示,因此能避免獨立編碼兩部分造成的精度丟失,實踐中往往有更好的表現(xiàn)。

實體消歧是在更精細的粒度上對候選實體進行排序,常見的學習排序算法包括單點法(pointwise)、配對法(pairwise)和列表法(listwise)三類。pointwise的思想是使用回歸或分類模型獨立地為每個候選實體進行打分;pairwise考慮的是候選實體兩兩之間的相對排序而非各自的絕對分值,因此損失的計算依賴于成對樣本;listwise則將一個query的所有候選實體集當作一個樣例,輸出為各候選實體的得分。在特征構(gòu)造與表示學習方面,可以使用query的特征、候選實體自身的特征或兩者的交互特征,相關(guān)方法與前文提到的語義匹配類似。

三、旅游知識圖譜

知識圖譜(Knowledge Graph, KG)是一種大規(guī)模語義網(wǎng)絡,由節(jié)點和節(jié)點之間相互連接的邊構(gòu)成,可以表征實體之間結(jié)構(gòu)化的關(guān)系,被認為是通往認知智能的基石。其中,節(jié)點表示概念或?qū)ο?,邊表示概念與概念、概念與對象或?qū)ο笈c對象之間的關(guān)系。在知識圖譜中,每條知識都可以表示成一個SPO(Subject-Predicate-Object)三元組,例如長寧區(qū)屬于上海市,在旅游知識圖譜中表示為(長寧區(qū),upperClass,上海市)。正因為高度結(jié)構(gòu)化的知識表示易于計算機理解,知識圖譜在信息檢索、智能推薦、金融風控上都有廣闊應用場景。

我們團隊打造的旅游知識圖譜以Neo4j和Nebula圖數(shù)據(jù)庫作為儲存方案,圖譜Schema涉及18種實體類型和12種關(guān)系類型,目前已有約1千萬實體、3千7百萬條三元組,知識數(shù)量初具規(guī)模。同時在數(shù)據(jù)治理層面建立了完備的自動更新機制和監(jiān)控體系,確保每日新增知識入庫,過期知識移除,提升了知識圖譜的可靠性。

圖片

圖2 旅游知識圖譜數(shù)據(jù)探索

四、技術(shù)方案

在實體鏈接系統(tǒng)的技術(shù)選型上,我們遵循三階段流程,即實體提及識別、候選實體生成、候選實體消歧三個串行的子模塊協(xié)同完成對自然語言的分析。

圖片

圖片

圖3 實體鏈接系統(tǒng)流程

此外,我們在工程上做了一些優(yōu)化,使用Redis緩存別名到候選實體id的映射關(guān)系以及實體id到實體屬性的映射關(guān)系,避免頻繁查詢Neo4j或Nebula圖數(shù)據(jù)庫帶來高延時。

五、功能模塊

5.1實體提及識別

這一步驟結(jié)合了神經(jīng)網(wǎng)絡模型和別名前綴樹進行多路檢測,以擴大候選實體召回范圍。

5.1.1 實體別名前綴樹

我們將知識庫中所有實體別名字符串插入到一棵前綴樹結(jié)構(gòu),該前綴樹除根節(jié)點不包含字符、葉節(jié)點包含終止符外,每個中間節(jié)點都只包含一個字符。從根節(jié)點出發(fā)到某一節(jié)點,經(jīng)過的字符連接起來表示該節(jié)點對應的字符串,因此樹中每個節(jié)點的后繼節(jié)點都擁有相同的前綴。

圖片

圖4 實體別名前綴樹示例從根節(jié)點到葉節(jié)點的路徑閉合了一個位于知識庫中的實體別名,在實際檢索時通常采用前向最大匹配策略:

1)維護兩個指針:前綴樹指針和query指針,前綴樹指針初始化時位于ROOT節(jié)點,query指針位于query文本首字符。

2)如果query指針指向的待匹配字符在前綴樹指針對應節(jié)點的后繼節(jié)點中,則移動前綴樹指針至該子節(jié)點,同時query指針后移一位。

3)如果query指針指向的待匹配字符不在前綴樹指針對應節(jié)點的后繼節(jié)點中,若后繼節(jié)點包含了end,則閉合實體提及字符串,前綴樹指針回到ROOT;否則前綴樹指針遞歸地回退至上級節(jié)點(query指針同步前移),直至上級節(jié)點的后繼節(jié)點中包含end節(jié)點,然后閉合實體提及字符串,前綴樹指針回到ROOT;若前綴樹指針回退至ROOT的過程中沒有閉合任何實體提及,則query指針后移一位。

前綴樹可以最大程度減少對用戶query中無效字符串的匹配,且最壞情況的時間復雜度仍優(yōu)于哈希表,提供了一種十分高效的字符串搜索方案。

5.1.2 命名實體識別模型

這里我們使用以BERT為骨架的指針網(wǎng)絡標注命名實體的邊界,圖5展示了模型框架、前向傳播過程以及標簽解碼方式。

圖片

圖5 命名實體識別模型結(jié)構(gòu)

在推理階段,根據(jù)頭、尾指針預測結(jié)果閉合相同實體標簽對應的token位置獲得實體提及邊界。

5.2 候選實體生成

在旅游知識圖譜中,“別名”是一種特殊的節(jié)點類型,我們在圖譜構(gòu)建階段會為每個新加入的POI、目的地、產(chǎn)品以及標簽類型的實體與其各別名(實體名稱也是一種別名)之間建立hasAlias類型的關(guān)系。因此,POI、產(chǎn)品、標簽實體都至少關(guān)聯(lián)到一個別名實體。

以圖6為例,輸入文本為“武漢 江西 東湖”時,假設識別到的實體提及為“武漢”、“江西”和“東湖”,將這三個提及作為“別名”節(jié)點的name屬性值進行條件查詢可得到三個別名節(jié)點(圖中標記為黃色),這三個別名節(jié)點通過類型為hasAlias的入邊又可以查到若干POI節(jié)點,這些POI節(jié)點便是該文本召回的候選實體。

圖片

圖6 文本為“武漢 江西 東湖”時的候選實體子圖

我們在候選實體生成階段并未采用向量檢索方案,因為實體提及一般是非常短的字符串,基于相似度的檢索不確定性高,難以保證召回結(jié)果的可靠性,維護高質(zhì)量的別名詞表更適合當下場景。

候選實體生成模塊還包括基于路徑的預過濾邏輯。以圖6為例,檢測到不同實體提及召回的候選實體之間可能存在路徑聯(lián)系,如“武漢市”到“東湖”、“江西省”到“蘆林湖”,那么與路徑中節(jié)點有相同別名但又不在路徑上的POI節(jié)點,比如紹興東湖,則不會作為候選實體返回。實踐中為了避免路徑假定過強而誤丟一些重要的節(jié)點,會施加一些約束條件,這些方法多與規(guī)則相關(guān),不再贅述。

5.3 候選實體消歧

該模塊用于對候選實體計算排序得分,我們使用基于BERT的交互式語義匹配模型。

首先拼接query字符串與候選實體的描述文本,經(jīng)分詞和數(shù)值化處理后,輸入到BERT提取高階交互特征。

在BERT輸出層選擇輸入序列中[CLS]位置上的特征向量hCLS與該候選實體在query中的實體提及片段的首、尾位置token對應的特征向量hhead、htail進行拼接,通過一個仿射變換,使用sigmoid激活函數(shù)獲得該候選實體為鏈接對象的概率值:

其中,w和b為線性層參數(shù)。

圖片

圖7 實體消歧模型結(jié)構(gòu)

模型訓練階段的損失函數(shù)為二分類交叉熵損失。

這里y為候選實體的0-1真實標簽。

推理階段,為query召回的各候選實體計算概率得分并按從高到低排序,根據(jù)預設閾值截斷候選實體序列,得到鏈接結(jié)果。

六、實踐場景

6.1 攜程旅游搜索

攜程旅游搜索詞義解析服務通過后端配置詞典進行分詞及詞性標注,返回所有匹配到的POI詞項,對重名POI不具備拒識或排序功能,常常會引入與query無關(guān)的搜索結(jié)果。

在接入實體鏈接系統(tǒng)后,能夠結(jié)合上下文信息對重名POI消歧,即便遇到上下文缺失的情況,也可以利用出發(fā)站城市輔助候選實體排序。

Case1 搜索詞為“武漢東湖”,接口原先返回“武漢市”和所有名為“東湖”的景點,調(diào)用實體鏈接服務,返回結(jié)果中只有位于“武漢市”的東湖景區(qū)(id:1xxx6)。

圖片

Case2 搜索詞為“深圳迪士尼”,接口原先返回“深圳市”和所有迪士尼度假區(qū)。盡管深圳市下面確實沒有迪士樂園,但常識會讓人聯(lián)想到用戶實際意圖可能是位于香港的迪士尼樂園(id:1xxx9),這正好是經(jīng)實體鏈接后的返回結(jié)果。

圖片

Case3 搜索詞為“白云山”,出發(fā)站設置為東莞市,接口原先返回所有名為“白云山”的景點,且不存在排序,無法推斷用戶對各POI感興趣的程度。調(diào)用實體鏈接服務后,返回結(jié)果中廣州市的白云山(id:7xxx4)被排在top1位置,說明實體消歧階段系統(tǒng)捕獲到了“廣州白云山”與定位站“東莞市”之間的關(guān)聯(lián)。

圖片

6.2 攜程旅游智能客服

在人機對話系統(tǒng)中,語義槽填充通常與意圖識別聯(lián)合進行,以確定追問話術(shù)、歧義澄清話術(shù),或完成對用戶自然語言的理解,從知識庫中搜索并返回答案。

例如,用戶詢問“從上海到成都的航班”,其意圖為“查詢航班”,但僅對用戶意圖分類還不足以給出準確回答,因為缺失了兩個關(guān)鍵信息:航班的出發(fā)站和到達站,這便是與“查詢航班”相關(guān)的語義槽,只有完成意圖識別和語義槽填充,才具備搜索答案的條件。這里出發(fā)站和到達站分別指上海和成都,正好是旅游知識圖譜中的兩個POI,借助實體鏈接可以很方便地找到這兩個POI的id信息。

攜程旅游智能客服在引入實體鏈接服務后,詞槽抽取F1 Score較原先提升了超過12個百分點,反映了實體鏈接在客服場景下的巨大潛能。

6.3 攜程POI關(guān)鍵信息更新

門票相關(guān)部門需要保證一些POI關(guān)鍵信息頻繁更新的準確性,如景區(qū)開閉園時間,這對于產(chǎn)品銷售及用戶體驗有至關(guān)重要的意義。

開閉園信息更新的主要依據(jù)為每日從景區(qū)官方渠道獲取的公告和資訊,通過解析這些文章內(nèi)容提取POI名稱及對應的開放或關(guān)閉時間。在疫情反復的當下,該信息面臨更加頻繁的變動,因此對準確性和時效性提出較高要求。

原始文本解析完成寫入數(shù)據(jù)庫時會掛靠到發(fā)布資訊的景點下,但這個信息不一定正確,實際中存在很多從文本抽取景點與發(fā)布資訊景點不一致的情況,比如某景區(qū)發(fā)文公告的是下級某個子景點閉園,這時需要通過實體鏈接將抽取的景點名映射到知識圖譜中的實體從而獲取真正的POI id,此功能可以提高信息的準確性,同時進行POI消歧。

景區(qū)開閉園抽取項目在引入實體鏈接后,準確率提升近六個百分點,極大改善了原抽取流程的效果。

6.4 攜程重復POI和上下級POI關(guān)系識別

門票活動相關(guān)部門維護的POI數(shù)據(jù)來源十分復雜,包括內(nèi)部和官方等多個平臺。POI數(shù)據(jù)批量導入時未全部識別出重復的POI以及POI之間的上下級關(guān)系,會導致系統(tǒng)內(nèi)存在較多重復的POI,產(chǎn)生分流;或者導致系統(tǒng)內(nèi)存在游離在外的POI,導致展示不全,用戶無法全面了解景區(qū)情況。因此需要及時獲取這些信息并修復,以提升信息覆蓋全面性,提升平臺的信息可靠性。

POI的地址或介紹中可能隱含了該POI的父級節(jié)點。例如,地址為“xxx路xxx號xxx景區(qū)內(nèi)”的POI,其上級節(jié)點可能是某個景區(qū),如果使用實體鏈接技術(shù)能獲取到該景區(qū)的id,并且這兩個POI在當前圖譜中不存在上下級關(guān)系,則可以作為一個重要特征加入關(guān)系識別系統(tǒng)中。該項目自上線起,上下級關(guān)系識別的平均正確率達到90%以上,已累計改善了近千條POI信息的準確性。

七、總結(jié)與展望

本文主要介紹了旅游AI知識圖譜組在實體鏈接技術(shù)上的探索和實踐,闡述了實體鏈接的基本定義、相關(guān)技術(shù)發(fā)展路線和應用價值,并結(jié)合各子模塊詳細說明了基于旅游知識圖譜的實體鏈接系統(tǒng)的架構(gòu)和流程,最后介紹了實體鏈接系統(tǒng)的落地場景。

未來我們將緊跟前沿技術(shù)發(fā)展,促使知識圖譜同實體召回、精排任務更緊密地結(jié)合,充分運用圖的結(jié)構(gòu)提升現(xiàn)有模型的效果和可解釋性,探索更加高效、輕量化的模型,同時也會兼顧技術(shù)落地,今后賦能更多的旅游場景。

責任編輯:未麗燕 來源: 攜程技術(shù)
相關(guān)推薦

2024-11-05 09:56:30

2023-08-18 10:49:14

開發(fā)攜程

2022-05-27 09:52:36

攜程TS運營AI

2024-04-18 09:41:53

2024-03-22 15:09:32

2023-11-13 11:27:58

攜程可視化

2022-05-13 09:27:55

Widget機票業(yè)務App

2024-12-26 09:27:51

2024-12-18 10:03:30

2023-12-29 09:42:28

攜程開發(fā)

2022-07-15 12:58:02

鴻蒙攜程華為

2016-12-15 21:41:15

大數(shù)據(jù)

2022-08-20 07:46:03

Dynamo攜程數(shù)據(jù)庫

2023-07-07 12:26:39

攜程開發(fā)

2022-07-15 09:20:17

性能優(yōu)化方案

2022-08-12 08:34:32

攜程數(shù)據(jù)庫上云

2023-02-08 16:34:05

數(shù)據(jù)庫工具

2022-07-08 09:38:27

攜程酒店Flutter技術(shù)跨平臺整合

2023-03-14 14:01:00

內(nèi)存優(yōu)化

2024-07-05 15:05:00

點贊
收藏

51CTO技術(shù)棧公眾號