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

美團技術團隊發表於2021-11-05

知識圖譜問答（Knowledge-based Question Answering, KBQA）是指給定自然語言問題，通過對問題進行語義理解和解析，進而利用知識庫進行查詢、推理得出答案。美團在平臺服務的售前、售中、售後全鏈路的多個場景中都存在大量的諮詢問題。我們基於問答系統，以自動智慧回覆或推薦回覆的方式，來幫助商家提升回答使用者問題的效率，同時更快地解決使用者問題。本文結合KBQA在美團場景中的具體實踐，以及發表在EMNLP 2021上的論文，介紹了KBQA系統整體設計、難點突破以及端到端問答的探索，希望能對從事相關研究的同學有所幫助或者啟發。

1 背景與挑戰

問答系統（Question Answering System, QA）是人工智慧和自然語言處理領域中一個倍受關注並具有廣泛發展前景的方向，它是資訊檢索系統的一種高階形式，可以用準確、簡潔的自然語言回答使用者用自然語言提出的問題。這項研究興起的主要原因是人們對快速、準確地獲取資訊的需求，因此被廣泛應用於工業界的各種業務場景中。美團在平臺服務的售前、售中、售後全鏈路的多個場景中，使用者都有大量的問題需要諮詢商家。因此我們基於問答系統，以自動智慧回覆或推薦回覆的方式，來幫助商家提升回答使用者問題的效率，更快地解決使用者的問題。

針對不同問題，美團的智慧問答系統包含多路解決方案：

  1. PairQA：採用資訊檢索技術，從社群已有回答的問題中返回與當前問題最接近的問題答案。
  2. DocQA：基於閱讀理解技術，從商家非結構化資訊、使用者評論中抽取出答案片段。
  3. KBQA（Knowledge-based Question Answering）：基於知識圖譜問答技術，從商家、商品的結構化資訊中對答案進行推理。

本文主要分享在KBQA技術落地中的實踐與探索。

在使用者的問題中，包括著大量關於商品、商家、景區、酒店等相關基礎資訊及政策等資訊諮詢，基於KBQA技術能有效地利用商品、商家詳情頁中的資訊，來解決此類資訊諮詢問題。使用者輸入問題後，KBQA系統基於機器學習演算法對使用者查詢的問題進行解析、理解，並對知識庫中的結構化資訊進行查詢、推理，最終將查詢到的精確答案返回給使用者。相比於PairQA和DocQA，KBQA的答案來源大多是商家資料，可信度更高。同時，它可以進行多跳查詢、約束過濾，更好地處理線上的複雜問題。

實際落地應用時，KBQA系統面臨著多方面的挑戰，例如：

  1. 繁多的業務場景：美團平臺業務場景眾多，包涵了酒店、旅遊、美食以及十多類生活服務業務，而不同場景中的使用者意圖都存在著差別，比如“早餐大概多少錢”，對於美食類商家需要回答人均價格，而對於酒店類商家則需要回答酒店內餐廳的價格明細。
  2. 帶約束問題：使用者的問題中通常帶有眾多條件，例如“故宮學生有優惠嗎”，需要我們對故宮所關聯的優惠政策進行篩選，而不是把所有的優惠政策都回答給使用者。
  3. 多跳問題：使用者的問題涉及到知識圖譜中多個節點組成的路徑，例如“XX酒店的游泳池幾點開”，需要我們在圖譜中先後找到酒店、游泳池、營業時間。

下面將詳細講述我們是如何設計高準確、低延時的KBQA系統，處理場景、上下文語境等資訊，準確理解使用者、捕捉使用者意圖，從而應對上述的挑戰。

2 解決方案

KBQA系統的輸入為使用者Query，輸出為答案。總體架構如下圖1所示。最上層為應用層，包括對話以及搜尋等多個入口。在獲取到使用者Query後，KBQA線上服務通過Query理解和召回排序模組進行結果計算，最終返回答案文字。除了線上服務之外，知識圖譜的構建、儲存也十分重要。使用者不僅會關心商戶的基本資訊，也會詢問觀點類、設施資訊類問題，比如景點好不好玩、酒店停車是否方便等。針對上述無官方供給的問題，我們構建了一套資訊與觀點抽取的流程，可以從商家非結構化介紹以及UGC評論中抽取出有價值的資訊，從而提升使用者諮詢的滿意度，我們將在下文進行詳細介紹。

圖1 KBQA系統架構圖

對於KBQA模型，目前的主流解決方案有兩種，如下圖2所示：

圖2 KBQA解決方案分類

  • 基於語義解析（Semantic Parsing-based）：對問句進行深度句法解析，並將解析結果組合成可執行的邏輯表示式（如SparQL），直接從圖資料庫中查詢答案。
  • 基於資訊抽取（Information Retrieval）：先解析出問句的主實體，再從KG中查詢出主實體關聯的多個三元組，組成子圖路徑（也稱多跳子圖），之後分別對問句和子圖路徑編碼、排序，返回分數最高的路徑作為答案。

基於語義解析的方法可解釋性更強，但這種方法需要標註大量的自然語言邏輯表示式，而資訊抽取式的方法更偏向端到端的方案，在複雜問題、少樣本情況下表現更好，但若子圖過大，會顯著降低計算的速度。

因此，考慮到兩者的優勢，我們採用將兩者結合的方案。如下圖3所示，整體的流程分為四大步驟，以“故宮週末有學生票嗎”為例：

圖3 美團KBQA解決方案

  1. Query理解：輸入原始Query，輸出Query理解結果。其中會對對Query進行句法分析，識別出使用者查詢的主實體是“故宮” 、業務領域為“旅遊”、問題型別為一跳（One-hop）。
  2. 關係識別：輸入Query、領域、句法解析結果、候選關係，輸出每個候選的分數。在這個模組中，我們藉助依存分析強化Query的問題主幹，召回旅遊領域的相關關係，進行匹配排序，識別出Query中的關係為“門票”。
  3. 子圖召回：輸入前兩個模組中解析的主實體和關係，輸出圖譜中的子圖（多個三元組）。對於上述例子，會召回旅遊業務資料下主實體為“故宮”、關係為“門票”的所有子圖。
  4. 答案排序：輸入Query和子圖候選，輸出子圖候選的分數，如果Top1滿足一定閾值，則輸出作為答案。基於句法分析結果，識別出約束條件為“學生票”，基於此條件最終對Query-Answer對進行排序，輸出滿足的答案。

下面將介紹我們對於重點模組的建設和探索。

2.1 Query理解

Query理解是KBQA的第一個核心模組，負責對句子的各個成分進行細粒度語義理解，其中兩個最重要的模組是：

  • 實體識別和實體連結，輸出問句中有意義的業務相關實體和型別，如商家名稱、專案、設施、人群、時間等。
  • 依存分析：以分詞和詞性識別結果為輸入，識別問句的主實體、被提問資訊、約束等。

實體識別是句法分析的重要步驟，我們先基於序列標註模型識別實體，再連結到資料庫中的節點。對於該模組我們主要做了以下優化：

  • 為了提升OOV（Out-of-Vocabulary）詞的識別能力，我們對實體識別的序列標註模型進行了知識注入，利用已知的先驗知識輔助新知識的發現。
  • 考慮到實體巢狀的問題，我們的實體識別模組會同時輸出粗粒度和細粒度的結果，保證後續模組對於Query的充分理解。
  • 在問答的長Query場景下，利用上下文資訊進行實體的連結，得到節點id。

最終，該模組會輸出句子中各個重要成分的型別，如下圖4所示：

圖4 Query理解流程及結果

依存分析是句法分析的一種，它的目的是識別句子中詞與詞的非對稱支配關係，在輸出的結果中用有向弧表示，該弧線由從屬詞（dep）指向支配詞（head）。對於KBQA任務，我們定義了五種關係，如下圖5所示：

圖5 依存型別定義

依存分析主要有兩種方案：基於轉移的（Transition-based）和基於圖的（Graph-based）。基於轉移的依存分析將依存句法樹的構建建模為一系列操作，由模型預測每一步的動作（shift、left_arc、right_arc），不斷將未處理的節點入棧並賦予關係，最終構成句法樹。基於圖的方法則致力於在圖中找出一棵最大生成樹，也就是句子整體依存關係的全域性最優解。考慮到基於圖的方法是對全域性進行搜尋，準確率更高，我們採用較為經典的“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的點積分數矩陣S(arc)，找到每個詞依存的head。

有了依存分析的結果，我們可以更好地識別關係、複雜問題，具體的特徵使用方法將在下文進行介紹。

2.2 關係識別

關係識別是KBQA中另一個核心模組，目的是識別出使用者Query所問的關係（Predicate），從而與主實體（Subject）聯合確定唯一子圖，得到答案（Object）。

在實踐中，考慮到圖譜中邊關係的數量會不斷增加，我們將關係識別建模為文字匹配任務，輸入使用者Query、Query特徵和候選關係，輸出關係匹配的分數。為了解決開頭提到的多領域問題，我們在輸入的特徵中加入了領域資訊，從而在領域表示中儲存一定的領域相關知識，讓模型更好地判斷。同時，為了提升複雜Query的理解，我們在輸入中還融入了句法資訊，讓模型可以更好地理解帶約束、多跳的問題。

圖7 關係識別模型結構

隨著大規模預訓練語言模型的出現，BERT等大模型在匹配任務上取得了SO他的結果，通常業界通用的方法主要歸類為以下兩種：

  1. 表示型：也稱“雙塔模型”，它的主要思想是將兩段文字轉換成一個語義向量，然後在向量空間計算兩向量的相似度，更側重對語義向量表示層的構建。
  2. 互動型：該方法側重於學習句子中短語之間的對齊，並學習比較他們之間的對齊關係，最終將對齊整合後的資訊聚合到預測層。由於互動型模型可以利用到文字之前的對齊資訊，因而精度更高、效果更好，所以在本專案中我們採用互動型模型來解決匹配問題。

為了充分利用BERT的語義建模能力，同時考慮實際業務的線上延時要求，我們在推理加速、資料增強、知識增強方面做了以下三點優化：

  1. 層次剪枝：BERT每層都會學到不同的知識，靠近輸入側會學到較為通用的句法知識，而靠近輸出則會學習更多工相關的知識，因此我們參考DistillBERT，採取Skip等間隔式層次剪枝，只保留對任務效果最好的3層，比單純保留前三層的剪枝在F1-score上提升了4%，同時，實驗發現不同剪枝方法效果差距可達7%。
  2. 領域任務資料預精調：剪枝後，由於訓練資料有限，3層模型的效果有不小的下降。通過對業務的瞭解，我們發現美團的“問大家”模組資料與線上資料的一致性很高，並對資料進行清洗，將問題標題和相關問題作為正例，隨機選取字面相似度0.5-0.8之間的句子作為負例，生成了大量弱監督文字對，預精調後3層模型在準確率上提升超過4%，甚至超過了12層模型的效果。
  3. 知識增強：由於使用者的表達方式多種多樣，準確識別使用者的意圖，需要深入語意並結合語法資訊。為了進一步提升效果，同時解決部分Case，我們在輸入中加入了領域與句法資訊，將顯式的先驗知識融入BERT，在注意力機制的作用下，同時結合句法依存樹結構，準確建模詞與詞之間的依賴關係，我們在業務資料以及五個大型公開資料集上做驗證，對比BERT Base模型在準確率上平均提升1.5%。

經過上述一系列迭代後，模型的速度、準確率都有了大幅的提升。

2.3 複雜問題理解

在真實場景中，大部分問題可以歸為以下四類（綠色為答案節點），如下圖8所示：

圖8 複雜問題分類

問題的跳數根據實體數量決定，單跳問題通常只涉及商戶的基本資訊，比如問商戶的地址、電話、營業時間、政策等，在知識圖譜中都可以通過一組SPO（三元組）解答；兩跳問題主要是針對商戶中某些設施、服務的資訊提問，比如酒店的健身房在幾層、早餐幾點開始、以及接送機服務的價格等，需要先找到商戶->主實體（設施/服務/商品等）的路徑，再找到主實體的基本資訊三元組，也就是SPX、XPO兩個三元組。約束問題指主實體或答案節點上的約束條件，一般為時間、人群或是定語。

下面介紹針對不同型別的複雜問題，我們所進行的一些改進。

2.3.1 帶約束問題

通過對線上日誌的挖掘，我們將約束分為以下幾類，如下圖9所示：

圖9 約束問題分類

對於帶約束問題的回答涉及兩個關鍵步驟：約束識別和答案排序。

通過KBQA系統中的依存分析模組，我們可以識別出使用者在實體或關係資訊上所加的約束限制，但約束的說法較多，且不同節點的約束型別也不一樣，因此我們在構造資料庫查詢SQL時先保證召回率，儘量召回實體和關係路徑下的所有候選節點，並在最終排序模組對答案約束進行打分排序。

為了提升效率，我們首先在知識儲存層上進行了優化。在複合屬性值的儲存方面，Freebase提出Compound Value Type (CVT) 型別，如下圖10所示，來解決這類複合結構化的資料的儲存與查詢問題。比如歡樂谷的營業時間，對於不同的場次是不一樣的。這種複合的屬性值可以用CVT的形式去承接。

圖10 CVT型別示例

但是，CVT儲存方式增加查詢複雜度、耗費資料庫儲存。以圖“歡樂谷營業時間CVT”為例：

  • 該資訊以通常成對CVT形式儲存，一個CVT涉及3個三元組儲存。
  • 對於“歡樂谷夏季夜場幾點開始”這樣的問題，在查詢的時候，涉及四跳，分別為，<實體 -> 營業時間CVT>, <營業時間CVT -> 季節=夏季>, <營業時間CVT -> 時段=夜場>,<營業時間CVT -> 時間>。對業界查詢快速的圖資料庫比如Nebula來說，三跳以上的一般查詢時間約為幾十毫秒，在實際上線使用中耗時較長。
  • 一旦屬性名稱、屬性值有不同的但是同意的表達方式，還需要多做一步同義詞合併，從而保證查詢時能匹配上，沒有召回損失。

為了解決上述問題，我們採用Key-Value的結構化形式承載屬性資訊。其中Key為答案的約束資訊，如人群、時間等可以作為該屬性值的約束的資訊，都可以放在Key中，Value即為要查的答案。對於上文的例子，我們將所有可能的約束維度的資訊組成Key，如下圖11所示：

圖11 約束問題解決方案

之後，為了解決約束值說法過多的問題，在實際查詢過程中，在找不到完全匹配的情況下，我們用屬性值的Key和問題中的約束資訊進行匹配計算相關度，相關度最高的Key，對應的Value即為答案。因此，Key的表示方法可以為多種形式：

  • 字串形式：用文字相似度的方法去計算和約束文字的相關性。
  • 文字Embedding：如對Key的文字形式做Embedding形式，與約束資訊做相似計算，在訓練資料合理的情況下，效果優於字串形式。
  • 其他Embedding演算法：如對虛擬節點做Graph Embedding，約束文字與對應的虛擬節點做聯合訓練等等。

這種形式的儲存方式，相當於只儲存一個三元組，即<實體->營業時間KV>，查詢過程壓縮成了一跳+文字匹配排序。基於語義模型的文字匹配可以在一定程度上解決文字表達不同造成的不能完全匹配的問題。對語義模型進行優化後，可以儘量壓縮匹配時間，達到十幾毫秒。

進行復雜條件優化後，先通過前置模組識別到實體、關係和約束，組成約束文字，再與當前召回子圖的Key值候選進行匹配，得到最終的答案。

2.3.2 多跳問題

多跳問題是天然適合KBQA的一類問題，當使用者詢問商戶中的設施、服務、商品等實體的資訊時，我們只需要先在圖譜中找到商戶，再找到商戶下的實體，接著找到下面的基本資訊。如果使用FAQ問答的解法，就需要為每個複雜問題都設定一個標準問，比如“健身房的位置”、“游泳館的位置”等。而在KBQA中，我們可以很好地對這類問題進行壓縮，不管問什麼實體的位置，都問的是“位置”這條邊關係，只是起始實體不同。

在KBQA系統中，我們先依賴依存分析模組對句子成分間的依賴關係進行識別，之後再通過關係識別模組判斷句子所詢問的關係跳數以及關係，具體流程如下圖12所示：

圖12 多跳問題解決方案

藉助實體識別的型別，我們可以將句子中的重要成分進行替換，從而壓縮候選關係配置的個數、提升關係識別準確率。在對句子進行了充分理解後，系統會基於主實體、關係、跳數對子圖進行查詢，並輸入給答案排序模組進行更細粒度的約束識別和打分。

2.4 觀點問答

除了上述基本資訊類的查詢Query外，使用者還會詢問觀點類的問題，比如“迪士尼停車方便嗎？”、“XX酒店隔音好嗎？”等。對於主觀觀點類問題，可以基於FAQ或閱讀理解技術，從使用者評論中找出對應的評論，但這種方法往往只能給出一條或幾條評論，可能會太過主觀，無法彙總群體的觀點。因此我們提出了觀點問答方案，給出一個觀點的正反支援人數，同時考慮到可解釋性，也會給出多數觀點的評論證據，在App中的實際展示如下圖13所示：

圖13 觀點問答截圖

為了自動化地批量挖掘使用者觀點，我們拆解了兩步方案：觀點發現和Evidence挖掘，如下圖14所示。

圖14 觀點挖掘步驟

第一步，先通過觀點發現在使用者評論中挖掘出多種觀點。我們採用基於序列標註的模型發掘句子中的實體和觀點描述，並使用依存分析模型對實體-觀點的關係進行判斷。

第二步，在挖掘到一定數量的觀點後，再深入挖掘評論中的證據（Evidence），如下圖15所示。雖然在第一步觀點發現時也能找到部分觀點的出處，但還有很多使用者評論的觀點是隱式的。比如對於“是否可以帶寵物”，使用者不一定在評論中直接指明，而是說“狗子在這裡玩的很開心”。這就需要我們對評論語句進行深度語義理解，從而歸納其中的觀點。在方案的落地過程中，最初我們使用了分類模型對觀點進行分類，輸入使用者評論，用編碼器對句子進行理解，之後各個觀點的分類頭判斷觀點正向程度。但隨著自動化挖掘的觀點增多，為了減少人工標註分類任務的成本，我們將其轉換成了匹配任務，即輸入觀點標籤（Tag）和使用者評論，判斷評論語句對該觀點的支撐程度。最後，為了優化速度，我們對12層Transformer進行了裁剪，在速度提升3倍的情況下效果只降了0.8%，實現了大批量的觀點離線挖掘。

圖15 觀點證據挖掘步驟

2.5 端到端方案的探索

在上文中，我們針對多跳、帶約束等複雜問題設計了不同的方案，雖然可以在一定程度上解決問題，但系統的複雜度也隨之提高。基於關係識別模組的預訓練思路，我們對通用的、端到端的解決方案進行了更多的探索，並在今年的EMNLP發表了《Large-Scale Relation Learning for Question Answering over Knowledge Bases with Pre-trained Language Models》論文。

對於KBQA，目前學術界有很多研究專注於圖學習方法，希望用圖學習來更好地表示子圖，但卻忽略了圖譜節點本身的語義。同時，BERT類的預訓練模型是在非結構化文字上訓練的，而沒接觸過圖譜的結構化資料。我們期望通過任務相關的資料來消除兩者的不一致性，從而提出了三種預訓練任務，如下圖16所示：

圖16 關係識別預訓練任務

  1. Relation Extraction：基於大規模關係抽取開源資料集，生成了大量一跳（ [CLS]s[SEP]h, r, t[SEP] ）與兩跳（ [CLS]s1 , s2 [SEP]h1 , r1 , t1 (h2 ), r2 , t2 [SEP] ）的文字對訓練資料，讓模型學習自然語言與結構化文字間的關係。
  2. Relation Matching：為了讓模型更好的捕捉到關係語義，我們基於關係抽取資料生成了大量文字對，擁有相同關係的文字互為正例，否則為負例。
  3. Relation Reasoning：為了讓模型具備一定的知識推理能力，我們假設圖譜中的(h, r, t)缺失，並利用其他間接關係來推理(h, r, t)是否成立，輸入格式為：[CLS]h, r, t[SEP]p1 [SEP] . . . pn [SEP]。

經過上述任務預訓練後，BERT模型對於Query和結構化文字的推理能力顯著提升，並且在非完全KB的情況下有更好的表現，如下圖17所示：

圖17 模型效果

3 應用實踐

經過一年多的建設，當前KBQA服務已經接入美團的旅遊、酒店、到綜等多個業務，輔助商家及時回答使用者問題，並提升了使用者的滿意度和轉化率。

3.1 酒店問一問

酒店是使用者出行的必備需求之一，但一些中小商家沒有開通人工客服入口，無法及時回答使用者資訊。為滿足使用者對詳情頁內資訊的快速查詢，智慧助理輔助未開通客服功能的酒店商家進行自動回覆，提升使用者下單轉化率。使用者可詢問酒店以及房型頁的各類資訊，如下圖18所示：

圖18 酒店問一問產品示例

3.2 門票地推

門票地推致力於幫助旅遊商家解決主要的賣票業務，在景區高峰時段，線上購票相比於排隊更加便捷，然而仍有很多使用者保持著線下購票的習慣。美團通過提過二維碼以及簡單的互動，提升了商戶賣票以及使用者購票的便捷程度。同時，我們通過在購票頁內建「智慧購票助手」，解決使用者購票過程中的問題，幫使用者更快捷地買到合適的門票，如下圖19所示：

圖19 門票地推產品示例

3.3 商家推薦回覆

除了出行場景外，使用者在瀏覽其他本地服務商家時也會有很多問題，比如“理髮店是否需要預約？”、“店家最晚幾點關門？”，這些都可以通過商家客服進行諮詢。但商家本身的人力有限，難免在高峰時期迎接不暇。為了降低使用者的等待時間，我們的問答服務會為商家提供話術推薦功能，如下圖20所示。其中KBQA主要負責解答商家、團購相關的資訊類問題。

圖20 商家推薦回覆產品示例

4 總結與展望

KBQA不僅是一個熱門的研究方向，更是一個複雜的系統，其中涉及到實體識別、句法分析、關係識別等眾多演算法，不僅要關注整體準確率，更要控制延時，對演算法和工程都提出了很大的挑戰。經過一年多的技術的探索，我們團隊不僅在美團落地多個應用，並在2020年獲得了CCKS KBQA測評的A榜第一、B榜第二和技術創新獎。同時我們開放出了部分美團資料，與北大合作舉辦了2021年的CCKS KBQA測評。

回到技術本身，雖然目前我們的KBQA已能解決大部分頭部問題，但長尾、複雜問題才是更大的挑戰，接下來還有很多前沿技術值得探索，我們希望探索以下方向：

  • 無監督領域遷移：由於KBQA覆蓋美團酒店、旅遊到綜等多個業務場景，其中到綜包含十多個小領域，我們希望提升模型的Few-Shot、Zero-Shot能力，降低標註資料會造成的人力成本。
  • 業務知識增強：關係識別場景下，模型核心詞聚焦到不相關的詞將對模型帶來嚴重的干擾，我們將研究如何利用先驗知識注入預訓練語言模型，指導修正Attention過程來提升模型表現。
  • 更多型別的複雜問題：除了上述提到的帶約束和多跳問題，使用者還會問比較類、多關係類問題，未來我們會對圖譜構建和Query理解模組進行更多優化，解決使用者的長尾問題。
  • 端到端KBQA：不管對工業界還是學術界，KBQA都是一個複雜的流程，如何利用預訓練模型以及其本身的知識，簡化整體流程、甚至端到端方案，是我們要持續探索的方向。

也歡迎對KBQA感興趣的同學加入我們團隊，一起探索KBQA的更多可能性！簡歷投遞地址：wangsirui@meituan.com。

作者簡介

如寐、樑迪、思睿、鴻志、明洋、武威，均來自搜尋與NLP部NLP中心知識圖譜組。

閱讀美團技術團隊更多技術文章合集

前端 | 演算法 | 後端 | 資料 | 安全 | 運維 | iOS | Android | 測試

| 在公眾號選單欄對話方塊回覆【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可檢視美團技術團隊歷年技術文章合集。

| 本文系美團技術團隊出品，著作權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容，敬請註明“內容轉載自美團技術團隊”。本文未經許可，不得進行商業性轉載或者使用。任何商用行為，請傳送郵件至tech@meituan.com申請授權。

相關文章