1. <strong id="7actg"></strong>
    2. <table id="7actg"></table>

    3. <address id="7actg"></address>
      <address id="7actg"></address>
      1. <object id="7actg"><tt id="7actg"></tt></object>

        美團知識圖譜問答技術實踐與探索

        共 9893字,需瀏覽 20分鐘

         ·

        2021-12-23 00:19

        知識圖譜問答(Knowledge-based Question Answering, KBQA)是指給定自然語言問題,通過對問題進行語義理解和解析,進而利用知識庫進行查詢、推理得出答案。美團在平臺服務的售前、售中、售后全鏈路的多個場景中都存在大量的咨詢問題。我們基于問答系統(tǒng),以自動智能回復或推薦回復的方式,來幫助商家提升回答用戶問題的效率,同時更快地解決用戶問題。

        本文結合KBQA在美團場景中的具體實踐,以及發(fā)表在EMNLP 2021上的論文,介紹了KBQA系統(tǒng)整體設計、難點突破以及端到端問答的探索,希望能對從事相關研究的同學有所幫助或者啟發(fā)。
        • 1 背景與挑戰(zhàn)

        • 2 解決方案

          • 2.1 Query理解

          • 2.2 關系識別

          • 2.3 復雜問題理解

          • 2.4 觀點問答

          • 2.5 端到端方案的探索

        • 3 應用實踐

          • 3.1 酒店問一問

          • 3.2 門票地推

          • 3.3 商家推薦回復

        • 4 總結與展望

        1 背景與挑戰(zhàn)

        問答系統(tǒng)(Question Answering System, QA)是人工智能和自然語言處理領域中一個倍受關注并具有廣泛發(fā)展前景的方向,它是信息檢索系統(tǒng)的一種高級形式,可以用準確、簡潔的自然語言回答用戶用自然語言提出的問題。這項研究興起的主要原因是人們對快速、準確地獲取信息的需求,因此被廣泛應用于工業(yè)界的各種業(yè)務場景中。美團在平臺服務的售前、售中、售后全鏈路的多個場景中,用戶都有大量的問題需要咨詢商家。因此我們基于問答系統(tǒng),以自動智能回復或推薦回復的方式,來幫助商家提升回答用戶問題的效率,更快地解決用戶的問題。
        針對不同問題,美團的智能問答系統(tǒng)包含多路解決方案:
        1. PairQA:采用信息檢索技術,從社區(qū)已有回答的問題中返回與當前問題最接近的問題答案。
        2. DocQA:基于閱讀理解技術,從商家非結構化信息、用戶評論中抽取出答案片段。
        3. KBQA(Knowledge-based Question Answering):基于知識圖譜問答技術,從商家、商品的結構化信息中對答案進行推理。
        本文主要分享在KBQA技術落地中的實踐與探索。
        在用戶的問題中,包括著大量關于商品、商家、景區(qū)、酒店等相關基礎信息及政策等信息咨詢,基于KBQA技術能有效地利用商品、商家詳情頁中的信息,來解決此類信息咨詢問題。用戶輸入問題后,KBQA系統(tǒng)基于機器學習算法對用戶查詢的問題進行解析、理解,并對知識庫中的結構化信息進行查詢、推理,最終將查詢到的精確答案返回給用戶。相比于PairQA和DocQA,KBQA的答案來源大多是商家數(shù)據(jù),可信度更高。同時,它可以進行多跳查詢、約束過濾,更好地處理線上的復雜問題。
        實際落地應用時,KBQA系統(tǒng)面臨著多方面的挑戰(zhàn),例如:
        1. 繁多的業(yè)務場景:美團平臺業(yè)務場景眾多,包涵了酒店、旅游、美食以及十多類生活服務業(yè)務,而不同場景中的用戶意圖都存在著差別,比如“早餐大概多少錢”,對于美食類商家需要回答人均價格,而對于酒店類商家則需要回答酒店內(nèi)餐廳的價格明細。
        2. 帶約束問題:用戶的問題中通常帶有眾多條件,例如“故宮學生有優(yōu)惠嗎”,需要我們對故宮所關聯(lián)的優(yōu)惠政策進行篩選,而不是把所有的優(yōu)惠政策都回答給用戶。
        3. 多跳問題:用戶的問題涉及到知識圖譜中多個節(jié)點組成的路徑,例如“XX酒店的游泳池幾點開”,需要我們在圖譜中先后找到酒店、游泳池、營業(yè)時間。
        下面將詳細講述我們是如何設計高準確、低延時的KBQA系統(tǒng),處理場景、上下文語境等信息,準確理解用戶、捕捉用戶意圖,從而應對上述的挑戰(zhàn)。

        2 解決方案

        KBQA系統(tǒng)的輸入為用戶Query,輸出為答案??傮w架構如下圖1所示。最上層為應用層,包括對話以及搜索等多個入口。在獲取到用戶Query后,KBQA線上服務通過Query理解和召回排序模塊進行結果計算,最終返回答案文本。除了在線服務之外,知識圖譜的構建、存儲也十分重要。用戶不僅會關心商戶的基本信息,也會詢問觀點類、設施信息類問題,比如景點好不好玩、酒店停車是否方便等。針對上述無官方供給的問題,我們構建了一套信息與觀點抽取的流程,可以從商家非結構化介紹以及UGC評論中抽取出有價值的信息,從而提升用戶咨詢的滿意度,我們將在下文進行詳細介紹。
        圖1 KBQA系統(tǒng)架構圖
        對于KBQA模型,目前的主流解決方案有兩種,如下圖2所示:
        圖2 KBQA解決方案分類
        • 基于語義解析(Semantic Parsing-based):對問句進行深度句法解析,并將解析結果組合成可執(zhí)行的邏輯表達式(如SparQL),直接從圖數(shù)據(jù)庫中查詢答案。
        • 基于信息抽取(Information Retrieval):先解析出問句的主實體,再從KG中查詢出主實體關聯(lián)的多個三元組,組成子圖路徑(也稱多跳子圖),之后分別對問句和子圖路徑編碼、排序,返回分數(shù)最高的路徑作為答案。
        基于語義解析的方法可解釋性更強,但這種方法需要標注大量的自然語言邏輯表達式,而信息抽取式的方法更偏向端到端的方案,在復雜問題、少樣本情況下表現(xiàn)更好,但若子圖過大,會顯著降低計算的速度。
        因此,考慮到兩者的優(yōu)勢,我們采用將兩者結合的方案。如下圖3所示,整體的流程分為四大步驟,以“故宮周末有學生票嗎”為例:
        圖3 美團KBQA解決方案
        1. Query理解:輸入原始Query,輸出Query理解結果。其中會對對Query進行句法分析,識別出用戶查詢的主實體是“故宮” 、業(yè)務領域為“旅游”、問題類型為一跳(One-hop)。
        2. 關系識別:輸入Query、領域、句法解析結果、候選關系,輸出每個候選的分數(shù)。在這個模塊中,我們借助依存分析強化Query的問題主干,召回旅游領域的相關關系,進行匹配排序,識別出Query中的關系為“門票”。
        3. 子圖召回:輸入前兩個模塊中解析的主實體和關系,輸出圖譜中的子圖(多個三元組)。對于上述例子,會召回旅游業(yè)務數(shù)據(jù)下主實體為“故宮”、關系為“門票”的所有子圖。
        4. 答案排序:輸入Query和子圖候選,輸出子圖候選的分數(shù),如果Top1滿足一定閾值,則輸出作為答案?;诰浞ǚ治鼋Y果,識別出約束條件為“學生票”,基于此條件最終對Query-Answer對進行排序,輸出滿足的答案。
        下面將介紹我們對于重點模塊的建設和探索。

        2.1 Query理解

        Query理解是KBQA的第一個核心模塊,負責對句子的各個成分進行細粒度語義理解,其中兩個最重要的模塊是:
        • 實體識別和實體鏈接,輸出問句中有意義的業(yè)務相關實體和類型,如商家名稱、項目、設施、人群、時間等。
        • 依存分析:以分詞和詞性識別結果為輸入,識別問句的主實體、被提問信息、約束等。
        實體識別是句法分析的重要步驟,我們先基于序列標注模型識別實體,再鏈接到數(shù)據(jù)庫中的節(jié)點。對于該模塊我們主要做了以下優(yōu)化:
        • 為了提升OOV(Out-of-Vocabulary)詞的識別能力,我們對實體識別的序列標注模型進行了知識注入,利用已知的先驗知識輔助新知識的發(fā)現(xiàn)。
        • 考慮到實體嵌套的問題,我們的實體識別模塊會同時輸出粗粒度和細粒度的結果,保證后續(xù)模塊對于Query的充分理解。
        • 在問答的長Query場景下,利用上下文信息進行實體的鏈接,得到節(jié)點id。
        最終,該模塊會輸出句子中各個重要成分的類型,如下圖4所示:
        圖4 Query理解流程及結果
        依存分析是句法分析的一種,它的目的是識別句子中詞與詞的非對稱支配關系,在輸出的結果中用有向弧表示,該弧線由從屬詞(dep)指向支配詞(head)。對于KBQA任務,我們定義了五種關系,如下圖5所示:
        圖5 依存類型定義
        依存分析主要有兩種方案:基于轉移的(Transition-based)和基于圖的(Graph-based)?;谵D移的依存分析將依存句法樹的構建建模為一系列操作,由模型預測每一步的動作(shift、left_arc、right_arc),不斷將未處理的節(jié)點入棧并賦予關系,最終構成句法樹?;趫D的方法則致力于在圖中找出一棵最大生成樹,也就是句子整體依存關系的全局最優(yōu)解。考慮到基于圖的方法是對全局進行搜索,準確率更高,我們采用較為經(jīng)典的“Deep Biaffine Attention for Neural Dependency Parsing”模型,它的結構如下圖6所示:
        圖6 依存分析模型結構
        該模型先通過BiLSTM對詞與詞性的拼接向量進行編碼,之后采用對用兩個MLP頭分別編碼出h(arc-head)和h(arc-dep)向量,去除冗余信息。最終將各個時刻的向量拼接起來得到H(arc-head)和H(arc-dep),且在H(arc-dep)上拼接了一個單位向量,加入中間矩陣U(arc)進行仿射變換,得到dep與head的點積分數(shù)矩陣S(arc),找到每個詞依存的head。
        有了依存分析的結果,我們可以更好地識別關系、復雜問題,具體的特征使用方法將在下文進行介紹。

        2.2 關系識別

        關系識別是KBQA中另一個核心模塊,目的是識別出用戶Query所問的關系(Predicate),從而與主實體(Subject)聯(lián)合確定唯一子圖,得到答案(Object)。
        在實踐中,考慮到圖譜中邊關系的數(shù)量會不斷增加,我們將關系識別建模為文本匹配任務,輸入用戶Query、Query特征和候選關系,輸出關系匹配的分數(shù)。為了解決開頭提到的多領域問題,我們在輸入的特征中加入了領域信息,從而在領域表示中存儲一定的領域相關知識,讓模型更好地判斷。同時,為了提升復雜Query的理解,我們在輸入中還融入了句法信息,讓模型可以更好地理解帶約束、多跳的問題。
        圖7 關系識別模型結構
        隨著大規(guī)模預訓練語言模型的出現(xiàn),BERT等大模型在匹配任務上取得了SOTA的結果,通常業(yè)界通用的方法主要歸類為以下兩種:
        1. 表示型:也稱“雙塔模型”,它的主要思想是將兩段文本轉換成一個語義向量,然后在向量空間計算兩向量的相似度,更側重對語義向量表示層的構建。
        2. 交互型:該方法側重于學習句子中短語之間的對齊,并學習比較他們之間的對齊關系,最終將對齊整合后的信息聚合到預測層。由于交互型模型可以利用到文本之前的對齊信息,因而精度更高、效果更好,所以在本項目中我們采用交互型模型來解決匹配問題。
        為了充分利用BERT的語義建模能力,同時考慮實際業(yè)務的線上延時要求,我們在推理加速、數(shù)據(jù)增強、知識增強方面做了以下三點優(yōu)化:
        1. 層次剪枝:BERT每層都會學到不同的知識,靠近輸入側會學到較為通用的句法知識,而靠近輸出則會學習更多任務相關的知識,因此我們參考DistillBERT,采取Skip等間隔式層次剪枝,只保留對任務效果最好的3層,比單純保留前三層的剪枝在F1-score上提升了4%,同時,實驗發(fā)現(xiàn)不同剪枝方法效果差距可達7%。
        2. 領域任務數(shù)據(jù)預精調(diào):剪枝后,由于訓練數(shù)據(jù)有限,3層模型的效果有不小的下降。通過對業(yè)務的了解,我們發(fā)現(xiàn)美團的“問大家”模塊數(shù)據(jù)與線上數(shù)據(jù)的一致性很高,并對數(shù)據(jù)進行清洗,將問題標題和相關問題作為正例,隨機選取字面相似度0.5-0.8之間的句子作為負例,生成了大量弱監(jiān)督文本對,預精調(diào)后3層模型在準確率上提升超過4%,甚至超過了12層模型的效果。
        3. 知識增強:由于用戶的表達方式多種多樣,準確識別用戶的意圖,需要深入語意并結合語法信息。為了進一步提升效果,同時解決部分Case,我們在輸入中加入了領域與句法信息,將顯式的先驗知識融入BERT,在注意力機制的作用下,同時結合句法依存樹結構,準確建模詞與詞之間的依賴關系,我們在業(yè)務數(shù)據(jù)以及五個大型公開數(shù)據(jù)集上做驗證,對比BERT Base模型在準確率上平均提升1.5%。
        經(jīng)過上述一系列迭代后,模型的速度、準確率都有了大幅的提升。

        2.3 復雜問題理解

        在真實場景中,大部分問題可以歸為以下四類(綠色為答案節(jié)點),如下圖8所示:
        圖8 復雜問題分類
        問題的跳數(shù)根據(jù)實體數(shù)量決定,單跳問題通常只涉及商戶的基本信息,比如問商戶的地址、電話、營業(yè)時間、政策等,在知識圖譜中都可以通過一組SPO(三元組)解答;兩跳問題主要是針對商戶中某些設施、服務的信息提問,比如酒店的健身房在幾層、早餐幾點開始、以及接送機服務的價格等,需要先找到商戶->主實體(設施/服務/商品等)的路徑,再找到主實體的基本信息三元組,也就是SPX、XPO兩個三元組。約束問題指主實體或答案節(jié)點上的約束條件,一般為時間、人群或是定語。
        下面介紹針對不同類型的復雜問題,我們所進行的一些改進。

        2.3.1 帶約束問題

        通過對線上日志的挖掘,我們將約束分為以下幾類,如下圖9所示:
        圖9 約束問題分類
        對于帶約束問題的回答涉及兩個關鍵步驟:約束識別答案排序。
        通過KBQA系統(tǒng)中的依存分析模塊,我們可以識別出用戶在實體或關系信息上所加的約束限制,但約束的說法較多,且不同節(jié)點的約束類型也不一樣,因此我們在構造數(shù)據(jù)庫查詢SQL時先保證召回率,盡量召回實體和關系路徑下的所有候選節(jié)點,并在最終排序模塊對答案約束進行打分排序。
        為了提升效率,我們首先在知識存儲層上進行了優(yōu)化。在復合屬性值的存儲方面,F(xiàn)reebase提出Compound Value Type (CVT) 類型,如下圖10所示,來解決這類復合結構化的數(shù)據(jù)的存儲與查詢問題。比如歡樂谷的營業(yè)時間,對于不同的場次是不一樣的。這種復合的屬性值可以用CVT的形式去承接。
        圖10 CVT類型示例
        但是,CVT存儲方式增加查詢復雜度、耗費數(shù)據(jù)庫存儲。以圖“歡樂谷營業(yè)時間CVT”為例:
        • 該信息以通常成對CVT形式存儲,一個CVT涉及3個三元組存儲。
        • 對于“歡樂谷夏季夜場幾點開始”這樣的問題,在查詢的時候,涉及四跳,分別為,<實體 -> 營業(yè)時間CVT>, <營業(yè)時間CVT -> 季節(jié)=夏季>, <營業(yè)時間CVT -> 時段=夜場>,<營業(yè)時間CVT -> 時間>。對業(yè)界查詢快速的圖數(shù)據(jù)庫比如Nebula來說,三跳以上的一般查詢時間約為幾十毫秒,在實際上線使用中耗時較長。
        • 一旦屬性名稱、屬性值有不同的但是同意的表達方式,還需要多做一步同義詞合并,從而保證查詢時能匹配上,沒有召回損失。
        為了解決上述問題,我們采用Key-Value的結構化形式承載屬性信息。其中Key為答案的約束信息,如人群、時間等可以作為該屬性值的約束的信息,都可以放在Key中,Value即為要查的答案。對于上文的例子,我們將所有可能的約束維度的信息組成Key,如下圖11所示:
        圖11 約束問題解決方案
        之后,為了解決約束值說法過多的問題,在實際查詢過程中,在找不到完全匹配的情況下,我們用屬性值的Key和問題中的約束信息進行匹配計算相關度,相關度最高的Key,對應的Value即為答案。因此,Key的表示方法可以為多種形式:
        • 字符串形式:用文本相似度的方法去計算和約束文本的相關性。
        • 文本Embedding:如對Key的文本形式做Embedding形式,與約束信息做相似計算,在訓練數(shù)據(jù)合理的情況下,效果優(yōu)于字符串形式。
        • 其他Embedding算法:如對虛擬節(jié)點做Graph Embedding,約束文本與對應的虛擬節(jié)點做聯(lián)合訓練等等。
        這種形式的存儲方式,相當于只存儲一個三元組,即<實體->營業(yè)時間KV>,查詢過程壓縮成了一跳+文本匹配排序?;谡Z義模型的文本匹配可以在一定程度上解決文本表達不同造成的不能完全匹配的問題。對語義模型進行優(yōu)化后,可以盡量壓縮匹配時間,達到十幾毫秒。
        進行復雜條件優(yōu)化后,先通過前置模塊識別到實體、關系和約束,組成約束文本,再與當前召回子圖的Key值候選進行匹配,得到最終的答案。

        2.3.2 多跳問題

        多跳問題是天然適合KBQA的一類問題,當用戶詢問商戶中的設施、服務、商品等實體的信息時,我們只需要先在圖譜中找到商戶,再找到商戶下的實體,接著找到下面的基本信息。如果使用FAQ問答的解法,就需要為每個復雜問題都設置一個標準問,比如“健身房的位置”、“游泳館的位置”等。而在KBQA中,我們可以很好地對這類問題進行壓縮,不管問什么實體的位置,都問的是“位置”這條邊關系,只是起始實體不同。
        在KBQA系統(tǒng)中,我們先依賴依存分析模塊對句子成分間的依賴關系進行識別,之后再通過關系識別模塊判斷句子所詢問的關系跳數(shù)以及關系,具體流程如下圖12所示:
        圖12 多跳問題解決方案
        借助實體識別的類型,我們可以將句子中的重要成分進行替換,從而壓縮候選關系配置的個數(shù)、提升關系識別準確率。在對句子進行了充分理解后,系統(tǒng)會基于主實體、關系、跳數(shù)對子圖進行查詢,并輸入給答案排序模塊進行更細粒度的約束識別和打分。

        2.4 觀點問答

        除了上述基本信息類的查詢Query外,用戶還會詢問觀點類的問題,比如“迪士尼停車方便嗎?”、“XX酒店隔音好嗎?”等。對于主觀觀點類問題,可以基于FAQ或閱讀理解技術,從用戶評論中找出對應的評論,但這種方法往往只能給出一條或幾條評論,可能會太過主觀,無法匯總群體的觀點。因此我們提出了觀點問答方案,給出一個觀點的正反支持人數(shù),同時考慮到可解釋性,也會給出多數(shù)觀點的評論證據(jù),在App中的實際展示如下圖13所示:
        圖13 觀點問答截圖
        為了自動化地批量挖掘用戶觀點,我們拆解了兩步方案:觀點發(fā)現(xiàn)和Evidence挖掘,如下圖14所示。
        圖14 觀點挖掘步驟
        第一步,先通過觀點發(fā)現(xiàn)在用戶評論中挖掘出多種觀點。我們采用基于序列標注的模型發(fā)掘句子中的實體和觀點描述,并使用依存分析模型對實體-觀點的關系進行判斷。
        第二步,在挖掘到一定數(shù)量的觀點后,再深入挖掘評論中的證據(jù)(Evidence),如下圖15所示。雖然在第一步觀點發(fā)現(xiàn)時也能找到部分觀點的出處,但還有很多用戶評論的觀點是隱式的。比如對于“是否可以帶寵物”,用戶不一定在評論中直接指明,而是說“狗子在這里玩的很開心”。這就需要我們對評論語句進行深度語義理解,從而歸納其中的觀點。在方案的落地過程中,最初我們使用了分類模型對觀點進行分類,輸入用戶評論,用編碼器對句子進行理解,之后各個觀點的分類頭判斷觀點正向程度。但隨著自動化挖掘的觀點增多,為了減少人工標注分類任務的成本,我們將其轉換成了匹配任務,即輸入觀點標簽(Tag)和用戶評論,判斷評論語句對該觀點的支撐程度。最后,為了優(yōu)化速度,我們對12層Transformer進行了裁剪,在速度提升3倍的情況下效果只降了0.8%,實現(xiàn)了大批量的觀點離線挖掘。
        圖15 觀點證據(jù)挖掘步驟

        2.5 端到端方案的探索

        在上文中,我們針對多跳、帶約束等復雜問題設計了不同的方案,雖然可以在一定程度上解決問題,但系統(tǒng)的復雜度也隨之提高?;陉P系識別模塊的預訓練思路,我們對通用的、端到端的解決方案進行了更多的探索,并在今年的EMNLP發(fā)表了《Large-Scale Relation Learning for Question Answering over Knowledge Bases with Pre-trained Language Models》論文。
        對于KBQA,目前學術界有很多研究專注于圖學習方法,希望用圖學習來更好地表示子圖,但卻忽略了圖譜節(jié)點本身的語義。同時,BERT類的預訓練模型是在非結構化文本上訓練的,而沒接觸過圖譜的結構化數(shù)據(jù)。我們期望通過任務相關的數(shù)據(jù)來消除兩者的不一致性,從而提出了三種預訓練任務,如下圖16所示:
        圖16 關系識別預訓練任務
        1. Relation Extraction:基于大規(guī)模關系抽取開源數(shù)據(jù)集,生成了大量一跳( [CLS]s[SEP]h, r, t[SEP] )與兩跳( [CLS]s1 , s2 [SEP]h1 , r1 , t1 (h2 ), r2 , t2 [SEP] )的文本對訓練數(shù)據(jù),讓模型學習自然語言與結構化文本間的關系。
        2. Relation Matching:為了讓模型更好的捕捉到關系語義,我們基于關系抽取數(shù)據(jù)生成了大量文本對,擁有相同關系的文本互為正例,否則為負例。
        3. Relation Reasoning:為了讓模型具備一定的知識推理能力,我們假設圖譜中的(h, r, t)缺失,并利用其他間接關系來推理(h, r, t)是否成立,輸入格式為:[CLS]h, r, t[SEP]p1 [SEP] . . . pn [SEP]。
        經(jīng)過上述任務預訓練后,BERT模型對于Query和結構化文本的推理能力顯著提升,并且在非完全KB的情況下有更好的表現(xiàn),如下圖17所示:
        圖17 模型效果

        3 應用實踐

        經(jīng)過一年多的建設,當前KBQA服務已經(jīng)接入美團的旅游、酒店、到綜等多個業(yè)務,輔助商家及時回答用戶問題,并提升了用戶的滿意度和轉化率。

        3.1 酒店問一問

        酒店是用戶出行的必備需求之一,但一些中小商家沒有開通人工客服入口,無法及時回答用戶信息。為滿足用戶對詳情頁內(nèi)信息的快速查找,智能助理輔助未開通客服功能的酒店商家進行自動回復,提升用戶下單轉化率。用戶可詢問酒店以及房型頁的各類信息,如下圖18所示:
        圖18 酒店問一問產(chǎn)品示例

        3.2 門票地推

        門票地推致力于幫助旅游商家解決主要的賣票業(yè)務,在景區(qū)高峰時段,線上購票相比于排隊更加便捷,然而仍有很多用戶保持著線下購票的習慣。美團通過提過二維碼以及簡單的交互,提升了商戶賣票以及用戶購票的便捷程度。同時,我們通過在購票頁內(nèi)置「智能購票助手」,解決用戶購票過程中的問題,幫用戶更快捷地買到合適的門票,如下圖19所示:
        圖19 門票地推產(chǎn)品示例

        3.3 商家推薦回復

        除了出行場景外,用戶在瀏覽其他本地服務商家時也會有很多問題,比如“理發(fā)店是否需要預約?”、“店家最晚幾點關門?”,這些都可以通過商家客服進行咨詢。但商家本身的人力有限,難免在高峰時期迎接不暇。為了降低用戶的等待時間,我們的問答服務會為商家提供話術推薦功能,如下圖20所示。其中KBQA主要負責解答商家、團購相關的信息類問題。
        圖20 商家推薦回復產(chǎn)品示例

        4 總結與展望

        KBQA不僅是一個熱門的研究方向,更是一個復雜的系統(tǒng),其中涉及到實體識別、句法分析、關系識別等眾多算法,不僅要關注整體準確率,更要控制延時,對算法和工程都提出了很大的挑戰(zhàn)。經(jīng)過一年多的技術的探索,我們團隊不僅在美團落地多個應用,并在2020年獲得了CCKS KBQA測評的A榜第一、B榜第二和技術創(chuàng)新獎。同時我們開放出了部分美團數(shù)據(jù),與北大合作舉辦了2021年的CCKS KBQA測評。
        回到技術本身,雖然目前我們的KBQA已能解決大部分頭部問題,但長尾、復雜問題才是更大的挑戰(zhàn),接下來還有很多前沿技術值得探索,我們希望探索以下方向:
        • 無監(jiān)督領域遷移:由于KBQA覆蓋美團酒店、旅游到綜等多個業(yè)務場景,其中到綜包含十多個小領域,我們希望提升模型的Few-Shot、Zero-Shot能力,降低標注數(shù)據(jù)會造成的人力成本。
        • 業(yè)務知識增強:關系識別場景下,模型核心詞聚焦到不相關的詞將對模型帶來嚴重的干擾,我們將研究如何利用先驗知識注入預訓練語言模型,指導修正Attention過程來提升模型表現(xiàn)。
        • 更多類型的復雜問題:除了上述提到的帶約束和多跳問題,用戶還會問比較類、多關系類問題,未來我們會對圖譜構建和Query理解模塊進行更多優(yōu)化,解決用戶的長尾問題。
        • 端到端KBQA:不管對工業(yè)界還是學術界,KBQA都是一個復雜的流程,如何利用預訓練模型以及其本身的知識,簡化整體流程、甚至端到端方案,是我們要持續(xù)探索的方向。
        也歡迎對KBQA感興趣的同學加入我們團隊,一起探索KBQA的更多可能性!文末附招聘信息,歡迎大家積極投遞簡歷。

        作者簡介

        如寐、梁迪、思睿、鴻志、明洋、武威,均來自美團搜索與NLP部NLP中心知識圖譜組。


        推薦閱讀:

        世界的真實格局分析,地球人類社會底層運行原理

        不是你需要中臺,而是一名合格的架構師(附各大廠中臺建設PPT)

        企業(yè)IT技術架構規(guī)劃方案

        論數(shù)字化轉型——轉什么,如何轉?

        華為干部與人才發(fā)展手冊(附PPT)

        企業(yè)10大管理流程圖,數(shù)字化轉型從業(yè)者必備!

        【中臺實踐】華為大數(shù)據(jù)中臺架構分享.pdf

        華為的數(shù)字化轉型方法論

        華為如何實施數(shù)字化轉型(附PPT)

        超詳細280頁Docker實戰(zhàn)文檔!開放下載

        華為大數(shù)據(jù)解決方案(PPT)

        瀏覽 66
        點贊
        評論
        收藏
        分享

        手機掃一掃分享

        分享
        舉報
        評論
        圖片
        表情
        推薦
        點贊
        評論
        收藏
        分享

        手機掃一掃分享

        分享
        舉報
        1. <strong id="7actg"></strong>
        2. <table id="7actg"></table>

        3. <address id="7actg"></address>
          <address id="7actg"></address>
          1. <object id="7actg"><tt id="7actg"></tt></object>
            国产午夜精品av一区二区麻豆 | 啊啊啊啊不要啊视频 | 一区二区乱伦视频 | 乱伦有码 | 国产免费观看一区 | 蜜桃AV网站 | AV毛片基地 | 少妇高潮久久久久 | 草比视频网 | 麻豆成人影视在线观看 |