知識圖譜問答（Knowledge-based Question Answering, KBQA）是指給定自然語言問題，通過對問題進行語義理解和解析，進而利用知識庫進行查詢、推理得出答案。美團在平臺服務的售前、售中、售後全鏈路的多個場景中都存在大量的諮詢問題。我們基於問答系統，以自動智能回覆或推薦回覆的方式，來幫助商家提升回答用戶問題的效率，同時更快地解決用戶問題。本文結合KBQA在美團場景中的具體實踐，以及發表在EMNLP 2021上的論文，介紹了KBQA系統整體設計、難點突破以及端到端問答的探索，希望能對從事相關研究的同學有所幫助或者啓發。
1 背景與挑戰
問答系統（Question Answering System, QA）是人工智能和自然語言處理領域中一個倍受關注並具有廣泛發展前景的方向，它是信息檢索系統的一種高級形式，可以用準確、簡潔的自然語言回答用戶用自然語言提出的問題。這項研究興起的主要原因是人們對快速、準確地獲取信息的需求，因此被廣泛應用於工業界的各種業務場景中。美團在平臺服務的售前、售中、售後全鏈路的多個場景中，用戶都有大量的問題需要諮詢商家。因此我們基於問答系統，以自動智能回覆或推薦回覆的方式，來幫助商家提升回答用戶問題的效率，更快地解決用戶的問題。
針對不同問題，美團的智能問答系統包含多路解決方案：
- PairQA：採用信息檢索技術，從社區已有回答的問題中返回與當前問題最接近的問題答案。
- DocQA：基於閱讀理解技術，從商家非結構化信息、用戶評論中抽取出答案片段。
- KBQA（Knowledge-based Question Answering）：基於知識圖譜問答技術，從商家、商品的結構化信息中對答案進行推理。
本文主要分享在KBQA技術落地中的實踐與探索。
在用戶的問題中，包括着大量關於商品、商家、景區、酒店等相關基礎信息及政策等信息諮詢，基於KBQA技術能有效地利用商品、商家詳情頁中的信息，來解決此類信息諮詢問題。用戶輸入問題後，KBQA系統基於機器學習算法對用戶查詢的問題進行解析、理解，並對知識庫中的結構化信息進行查詢、推理，最終將查詢到的精確答案返回給用戶。相比於PairQA和DocQA，KBQA的答案來源大多是商家數據，可信度更高。同時，它可以進行多跳查詢、約束過濾，更好地處理線上的複雜問題。
實際落地應用時，KBQA系統面臨着多方面的挑戰，例如：
- 繁多的業務場景：美團平臺業務場景衆多，包涵了酒店、旅遊、美食以及十多類生活服務業務，而不同場景中的用戶意圖都存在着差別，比如“早餐大概多少錢”，對於美食類商家需要回答人均價格，而對於酒店類商家則需要回答酒店內餐廳的價格明細。
- 帶約束問題：用戶的問題中通常帶有衆多條件，例如“故宮學生有優惠嗎”，需要我們對故宮所關聯的優惠政策進行篩選，而不是把所有的優惠政策都回答給用戶。
- 多跳問題：用戶的問題涉及到知識圖譜中多個節點組成的路徑，例如“XX酒店的游泳池幾點開”，需要我們在圖譜中先後找到酒店、游泳池、營業時間。
下面將詳細講述我們是如何設計高準確、低延時的KBQA系統，處理場景、上下文語境等信息，準確理解用戶、捕捉用戶意圖，從而應對上述的挑戰。
2 解決方案
KBQA系統的輸入爲用戶Query，輸出爲答案。總體架構如下圖1所示。最上層爲應用層，包括對話以及搜索等多個入口。在獲取到用戶Query後，KBQA線上服務通過Query理解和召回排序模塊進行結果計算，最終返回答案文本。除了在線服務之外，知識圖譜的構建、存儲也十分重要。用戶不僅會關心商戶的基本信息，也會詢問觀點類、設施信息類問題，比如景點好不好玩、酒店停車是否方便等。針對上述無官方供給的問題，我們構建了一套信息與觀點抽取的流程，可以從商家非結構化介紹以及UGC評論中抽取出有價值的信息，從而提升用戶諮詢的滿意度，我們將在下文進行詳細介紹。
對於KBQA模型，目前的主流解決方案有兩種，如下圖2所示：
- 基於語義解析（Semantic Parsing-based）：對問句進行深度句法解析，並將解析結果組合成可執行的邏輯表達式（如SparQL），直接從圖數據庫中查詢答案。
- 基於信息抽取（Information Retrieval）：先解析出問句的主實體，再從KG中查詢出主實體關聯的多個三元組，組成子圖路徑（也稱多跳子圖），之後分別對問句和子圖路徑編碼、排序，返回分數最高的路徑作爲答案。
基於語義解析的方法可解釋性更強，但這種方法需要標註大量的自然語言邏輯表達式，而信息抽取式的方法更偏向端到端的方案，在複雜問題、少樣本情況下表現更好，但若子圖過大，會顯著降低計算的速度。
因此，考慮到兩者的優勢，我們採用將兩者結合的方案。如下圖3所示，整體的流程分爲四大步驟，以“故宮週末有學生票嗎”爲例：
- Query理解：輸入原始Query，輸出Query理解結果。其中會對對Query進行句法分析，識別出用戶查詢的主實體是“故宮” 、業務領域爲“旅遊”、問題類型爲一跳（One-hop）。
- 關係識別：輸入Query、領域、句法解析結果、候選關係，輸出每個候選的分數。在這個模塊中，我們藉助依存分析強化Query的問題主幹，召回旅遊領域的相關關係，進行匹配排序，識別出Query中的關係爲“門票”。
- 子圖召回：輸入前兩個模塊中解析的主實體和關係，輸出圖譜中的子圖（多個三元組）。對於上述例子，會召回旅遊業務數據下主實體爲“故宮”、關係爲“門票”的所有子圖。
- 答案排序：輸入Query和子圖候選，輸出子圖候選的分數，如果Top1滿足一定閾值，則輸出作爲答案。基於句法分析結果，識別出約束條件爲“學生票”，基於此條件最終對Query-Answer對進行排序，輸出滿足的答案。
下面將介紹我們對於重點模塊的建設和探索。
2.1 Query理解
Query理解是KBQA的第一個核心模塊，負責對句子的各個成分進行細粒度語義理解，其中兩個最重要的模塊是：
- 實體識別和實體鏈接，輸出問句中有意義的業務相關實體和類型，如商家名稱、項目、設施、人羣、時間等。
- 依存分析：以分詞和詞性識別結果爲輸入，識別問句的主實體、被提問信息、約束等。
實體識別是句法分析的重要步驟，我們先基於序列標註模型識別實體，再鏈接到數據庫中的節點。對於該模塊我們主要做了以下優化：
- 爲了提升OOV（Out-of-Vocabulary）詞的識別能力，我們對實體識別的序列標註模型進行了知識注入，利用已知的先驗知識輔助新知識的發現。
- 考慮到實體嵌套的問題，我們的實體識別模塊會同時輸出粗粒度和細粒度的結果，保證後續模塊對於Query的充分理解。
- 在問答的長Query場景下，利用上下文信息進行實體的鏈接，得到節點id。
最終，該模塊會輸出句子中各個重要成分的類型，如下圖4所示：
依存分析是句法分析的一種，它的目的是識別句子中詞與詞的非對稱支配關係，在輸出的結果中用有向弧表示，該弧線由從屬詞（dep）指向支配詞（head）。對於KBQA任務，我們定義了五種關係，如下圖5所示：
依存分析主要有兩種方案：基於轉移的（Transition-based）和基於圖的（Graph-based）。基於轉移的依存分析將依存句法樹的構建建模爲一系列操作，由模型預測每一步的動作（shift、left_arc、right_arc），不斷將未處理的節點入棧並賦予關係，最終構成句法樹。基於圖的方法則致力於在圖中找出一棵最大生成樹，也就是句子整體依存關係的全局最優解。考慮到基於圖的方法是對全局進行搜索，準確率更高，我們採用較爲經典的“Deep Biaffine Attention for Neural Dependency Parsing”模型，它的結構如下圖6所示：
該模型先通過BiLSTM對詞與詞性的拼接向量進行編碼，之後採用對用兩個MLP頭分別編碼出h(arc-head)和h(arc-dep)向量，去除冗餘信息。最終將各個時刻的向量拼接起來得到H(arc-head)和H(arc-dep)，且在H(arc-dep)上拼接了一個單位向量，加入中間矩陣U(arc)進行仿射變換，得到dep與head的點積分數矩陣S(arc)，找到每個詞依存的head。
有了依存分析的結果，我們可以更好地識別關係、複雜問題，具體的特徵使用方法將在下文進行介紹。
2.2 關係識別
關係識別是KBQA中另一個核心模塊，目的是識別出用戶Query所問的關係（Predicate），從而與主實體（Subject）聯合確定唯一子圖，得到答案（Object）。
在實踐中，考慮到圖譜中邊關係的數量會不斷增加，我們將關係識別建模爲文本匹配任務，輸入用戶Query、Query特徵和候選關係，輸出關係匹配的分數。爲了解決開頭提到的多領域問題，我們在輸入的特徵中加入了領域信息，從而在領域表示中存儲一定的領域相關知識，讓模型更好地判斷。同時，爲了提升複雜Query的理解，我們在輸入中還融入了句法信息，讓模型可以更好地理解帶約束、多跳的問題。
隨着大規模預訓練語言模型的出現，BERT等大模型在匹配任務上取得了SOTA的結果，通常業界通用的方法主要歸類爲以下兩種：
- 表示型：也稱“雙塔模型”，它的主要思想是將兩段文本轉換成一個語義向量，然後在向量空間計算兩向量的相似度，更側重對語義向量表示層的構建。
- 交互型：該方法側重於學習句子中短語之間的對齊，並學習比較他們之間的對齊關係，最終將對齊整合後的信息聚合到預測層。由於交互型模型可以利用到文本之前的對齊信息，因而精度更高、效果更好，所以在本項目中我們採用交互型模型來解決匹配問題。
爲了充分利用BERT的語義建模能力，同時考慮實際業務的線上延時要求，我們在推理加速、數據增強、知識增強方面做了以下三點優化：
- 層次剪枝：BERT每層都會學到不同的知識，靠近輸入側會學到較爲通用的句法知識，而靠近輸出則會學習更多任務相關的知識，因此我們參考DistillBERT，採取Skip等間隔式層次剪枝，只保留對任務效果最好的3層，比單純保留前三層的剪枝在F1-score上提升了4%，同時，實驗發現不同剪枝方法效果差距可達7%。
- 領域任務數據預精調：剪枝後，由於訓練數據有限，3層模型的效果有不小的下降。通過對業務的瞭解，我們發現美團的“問大家”模塊數據與線上數據的一致性很高，並對數據進行清洗，將問題標題和相關問題作爲正例，隨機選取字面相似度0.5-0.8之間的句子作爲負例，生成了大量弱監督文本對，預精調後3層模型在準確率上提升超過4%，甚至超過了12層模型的效果。
- 知識增強：由於用戶的表達方式多種多樣，準確識別用戶的意圖，需要深入語意並結合語法信息。爲了進一步提升效果，同時解決部分Case，我們在輸入中加入了領域與句法信息，將顯式的先驗知識融入BERT，在注意力機制的作用下，同時結合句法依存樹結構，準確建模詞與詞之間的依賴關係，我們在業務數據以及五個大型公開數據集上做驗證，對比BERT Base模型在準確率上平均提升1.5%。
經過上述一系列迭代後，模型的速度、準確率都有了大幅的提升。
2.3 複雜問題理解
在真實場景中，大部分問題可以歸爲以下四類（綠色爲答案節點），如下圖8所示：
問題的跳數根據實體數量決定，單跳問題通常只涉及商戶的基本信息，比如問商戶的地址、電話、營業時間、政策等，在知識圖譜中都可以通過一組SPO（三元組）解答；兩跳問題主要是針對商戶中某些設施、服務的信息提問，比如酒店的健身房在幾層、早餐幾點開始、以及接送機服務的價格等，需要先找到商戶->主實體（設施/服務/商品等）的路徑，再找到主實體的基本信息三元組，也就是SPX、XPO兩個三元組。約束問題指主實體或答案節點上的約束條件，一般爲時間、人羣或是定語。
下面介紹針對不同類型的複雜問題，我們所進行的一些改進。
2.3.1 帶約束問題
通過對線上日誌的挖掘，我們將約束分爲以下幾類，如下圖9所示：
對於帶約束問題的回答涉及兩個關鍵步驟：約束識別和答案排序。
通過KBQA系統中的依存分析模塊，我們可以識別出用戶在實體或關係信息上所加的約束限制，但約束的說法較多，且不同節點的約束類型也不一樣，因此我們在構造數據庫查詢SQL時先保證召回率，儘量召回實體和關係路徑下的所有候選節點，並在最終排序模塊對答案約束進行打分排序。
爲了提升效率，我們首先在知識存儲層上進行了優化。在複合屬性值的存儲方面，Freebase提出Compound Value Type (CVT) 類型，如下圖10所示，來解決這類複合結構化的數據的存儲與查詢問題。比如歡樂谷的營業時間，對於不同的場次是不一樣的。這種複合的屬性值可以用CVT的形式去承接。
但是，CVT存儲方式增加查詢複雜度、耗費數據庫存儲。以圖“歡樂谷營業時間CVT”爲例：
- 該信息以通常成對CVT形式存儲，一個CVT涉及3個三元組存儲。
- 對於“歡樂谷夏季夜場幾點開始”這樣的問題，在查詢的時候，涉及四跳，分別爲，<實體 -> 營業時間CVT>, <營業時間CVT -> 季節=夏季>, <營業時間CVT -> 時段=夜場>,<營業時間CVT -> 時間>。對業界查詢快速的圖數據庫比如Nebula來說，三跳以上的一般查詢時間約爲幾十毫秒，在實際上線使用中耗時較長。
- 一旦屬性名稱、屬性值有不同的但是同意的表達方式，還需要多做一步同義詞合併，從而保證查詢時能匹配上，沒有召回損失。
爲了解決上述問題，我們採用Key-Value的結構化形式承載屬性信息。其中Key爲答案的約束信息，如人羣、時間等可以作爲該屬性值的約束的信息，都可以放在Key中，Value即爲要查的答案。對於上文的例子，我們將所有可能的約束維度的信息組成Key，如下圖11所示：
之後，爲了解決約束值說法過多的問題，在實際查詢過程中，在找不到完全匹配的情況下，我們用屬性值的Key和問題中的約束信息進行匹配計算相關度，相關度最高的Key，對應的Value即爲答案。因此，Key的表示方法可以爲多種形式：
- 字符串形式：用文本相似度的方法去計算和約束文本的相關性。
- 文本Embedding：如對Key的文本形式做Embedding形式，與約束信息做相似計算，在訓練數據合理的情況下，效果優於字符串形式。
- 其他Embedding算法：如對虛擬節點做Graph Embedding，約束文本與對應的虛擬節點做聯合訓練等等。
這種形式的存儲方式，相當於只存儲一個三元組，即<實體->營業時間KV>，查詢過程壓縮成了一跳+文本匹配排序。基於語義模型的文本匹配可以在一定程度上解決文本表達不同造成的不能完全匹配的問題。對語義模型進行優化後，可以儘量壓縮匹配時間，達到十幾毫秒。
進行復雜條件優化後，先通過前置模塊識別到實體、關係和約束，組成約束文本，再與當前召回子圖的Key值候選進行匹配，得到最終的答案。
2.3.2 多跳問題
多跳問題是天然適合KBQA的一類問題，當用戶詢問商戶中的設施、服務、商品等實體的信息時，我們只需要先在圖譜中找到商戶，再找到商戶下的實體，接着找到下面的基本信息。如果使用FAQ問答的解法，就需要爲每個複雜問題都設置一個標準問，比如“健身房的位置”、“游泳館的位置”等。而在KBQA中，我們可以很好地對這類問題進行壓縮，不管問什麼實體的位置，都問的是“位置”這條邊關係，只是起始實體不同。
在KBQA系統中，我們先依賴依存分析模塊對句子成分間的依賴關係進行識別，之後再通過關係識別模塊判斷句子所詢問的關係跳數以及關係，具體流程如下圖12所示：
藉助實體識別的類型，我們可以將句子中的重要成分進行替換，從而壓縮候選關係配置的個數、提升關係識別準確率。在對句子進行了充分理解後，系統會基於主實體、關係、跳數對子圖進行查詢，並輸入給答案排序模塊進行更細粒度的約束識別和打分。
2.4 觀點問答
除了上述基本信息類的查詢Query外，用戶還會詢問觀點類的問題，比如“迪士尼停車方便嗎？”、“XX酒店隔音好嗎？”等。對於主觀觀點類問題，可以基於FAQ或閱讀理解技術，從用戶評論中找出對應的評論，但這種方法往往只能給出一條或幾條評論，可能會太過主觀，無法彙總羣體的觀點。因此我們提出了觀點問答方案，給出一個觀點的正反支持人數，同時考慮到可解釋性，也會給出多數觀點的評論證據，在App中的實際展示如下圖13所示：
爲了自動化地批量挖掘用戶觀點，我們拆解了兩步方案：觀點發現和Evidence挖掘，如下圖14所示。
第一步，先通過觀點發現在用戶評論中挖掘出多種觀點。我們採用基於序列標註的模型發掘句子中的實體和觀點描述，並使用依存分析模型對實體-觀點的關係進行判斷。
第二步，在挖掘到一定數量的觀點後，再深入挖掘評論中的證據（Evidence），如下圖15所示。雖然在第一步觀點發現時也能找到部分觀點的出處，但還有很多用戶評論的觀點是隱式的。比如對於“是否可以帶寵物”，用戶不一定在評論中直接指明，而是說“狗子在這裏玩的很開心”。這就需要我們對評論語句進行深度語義理解，從而歸納其中的觀點。在方案的落地過程中，最初我們使用了分類模型對觀點進行分類，輸入用戶評論，用編碼器對句子進行理解，之後各個觀點的分類頭判斷觀點正向程度。但隨着自動化挖掘的觀點增多，爲了減少人工標註分類任務的成本，我們將其轉換成了匹配任務，即輸入觀點標籤（Tag）和用戶評論，判斷評論語句對該觀點的支撐程度。最後，爲了優化速度，我們對12層Transformer進行了裁剪，在速度提升3倍的情況下效果只降了0.8%，實現了大批量的觀點離線挖掘。
2.5 端到端方案的探索
在上文中，我們針對多跳、帶約束等複雜問題設計了不同的方案，雖然可以在一定程度上解決問題，但系統的複雜度也隨之提高。基於關係識別模塊的預訓練思路，我們對通用的、端到端的解決方案進行了更多的探索，並在今年的EMNLP發表了《Large-Scale Relation Learning for Question Answering over Knowledge Bases with Pre-trained Language Models》論文。
對於KBQA，目前學術界有很多研究專注於圖學習方法，希望用圖學習來更好地表示子圖，但卻忽略了圖譜節點本身的語義。同時，BERT類的預訓練模型是在非結構化文本上訓練的，而沒接觸過圖譜的結構化數據。我們期望通過任務相關的數據來消除兩者的不一致性，從而提出了三種預訓練任務，如下圖16所示：
- Relation Extraction：基於大規模關係抽取開源數據集，生成了大量一跳（ [CLS]s[SEP]h, r, t[SEP] ）與兩跳（ [CLS]s1 , s2 [SEP]h1 , r1 , t1 (h2 ), r2 , t2 [SEP] ）的文本對訓練數據，讓模型學習自然語言與結構化文本間的關係。
- Relation Matching：爲了讓模型更好的捕捉到關係語義，我們基於關係抽取數據生成了大量文本對，擁有相同關係的文本互爲正例，否則爲負例。
- Relation Reasoning：爲了讓模型具備一定的知識推理能力，我們假設圖譜中的(h, r, t)缺失，並利用其他間接關係來推理(h, r, t)是否成立，輸入格式爲：[CLS]h, r, t[SEP]p1 [SEP] . . . pn [SEP]。
經過上述任務預訓練後，BERT模型對於Query和結構化文本的推理能力顯著提升，並且在非完全KB的情況下有更好的表現，如下圖17所示：
3 應用實踐
經過一年多的建設，當前KBQA服務已經接入美團的旅遊、酒店、到綜等多個業務，輔助商家及時回答用戶問題，並提升了用戶的滿意度和轉化率。
3.1 酒店問一問
酒店是用戶出行的必備需求之一，但一些中小商家沒有開通人工客服入口，無法及時回答用戶信息。爲滿足用戶對詳情頁內信息的快速查找，智能助理輔助未開通客服功能的酒店商家進行自動回覆，提升用戶下單轉化率。用戶可詢問酒店以及房型頁的各類信息，如下圖18所示：
3.2 門票地推
門票地推致力於幫助旅遊商家解決主要的賣票業務，在景區高峯時段，線上購票相比於排隊更加便捷，然而仍有很多用戶保持着線下購票的習慣。美團通過提過二維碼以及簡單的交互，提升了商戶賣票以及用戶購票的便捷程度。同時，我們通過在購票頁內置「智能購票助手」，解決用戶購票過程中的問題，幫用戶更快捷地買到合適的門票，如下圖19所示：
3.3 商家推薦回覆
除了出行場景外，用戶在瀏覽其他本地服務商家時也會有很多問題，比如“理髮店是否需要預約？”、“店家最晚幾點關門？”，這些都可以通過商家客服進行諮詢。但商家本身的人力有限，難免在高峯時期迎接不暇。爲了降低用戶的等待時間，我們的問答服務會爲商家提供話術推薦功能，如下圖20所示。其中KBQA主要負責解答商家、團購相關的信息類問題。
4 總結與展望
KBQA不僅是一個熱門的研究方向，更是一個複雜的系統，其中涉及到實體識別、句法分析、關係識別等衆多算法，不僅要關注整體準確率，更要控制延時，對算法和工程都提出了很大的挑戰。經過一年多的技術的探索，我們團隊不僅在美團落地多個應用，並在2020年獲得了CCKS KBQA測評的A榜第一、B榜第二和技術創新獎。同時我們開放出了部分美團數據，與北大合作舉辦了2021年的CCKS KBQA測評。
回到技術本身，雖然目前我們的KBQA已能解決大部分頭部問題，但長尾、複雜問題纔是更大的挑戰，接下來還有很多前沿技術值得探索，我們希望探索以下方向：
- 無監督領域遷移：由於KBQA覆蓋美團酒店、旅遊到綜等多個業務場景，其中到綜包含十多個小領域，我們希望提升模型的Few-Shot、Zero-Shot能力，降低標註數據會造成的人力成本。
- 業務知識增強：關係識別場景下，模型核心詞聚焦到不相關的詞將對模型帶來嚴重的干擾，我們將研究如何利用先驗知識注入預訓練語言模型，指導修正Attention過程來提升模型表現。
- 更多類型的複雜問題：除了上述提到的帶約束和多跳問題，用戶還會問比較類、多關係類問題，未來我們會對圖譜構建和Query理解模塊進行更多優化，解決用戶的長尾問題。
- 端到端KBQA：不管對工業界還是學術界，KBQA都是一個複雜的流程，如何利用預訓練模型以及其本身的知識，簡化整體流程、甚至端到端方案，是我們要持續探索的方向。
也歡迎對KBQA感興趣的同學加入我們團隊，一起探索KBQA的更多可能性！簡歷投遞地址：[email protected]。
作者簡介
如寐、梁迪、思睿、鴻志、明洋、武威，均來自搜索與NLP部NLP中心知識圖譜組。
閱讀美團技術團隊更多技術文章合集
前端 | 算法 | 後端 | 數據 | 安全 | 運維 | iOS | Android | 測試
| 在公衆號菜單欄對話框回覆【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可查看美團技術團隊歷年技術文章合集。
