关于美团:美团知识图谱问答技术实践与探索

常识图谱问答（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 评论中抽取出有价值的信息，从而晋升用户征询的满意度，咱们将在下文进行具体介绍。

对于 KBQA 模型，目前的支流解决方案有两种，如下图 2 所示：

• 基于语义解析（Semantic Parsing-based）：对问句进行深度句法解析，并将解析后果组合成可执行的逻辑表达式（如 SparQL），间接从图数据库中查问答案。
• 基于信息抽取（Information Retrieval）：先解析出问句的主实体，再从 KG 中查问出主实体关联的多个三元组，组成子图门路（也称多跳子图），之后别离对问句和子图门路编码、排序，返回分数最高的门路作为答案。

基于语义解析的办法可解释性更强，但这种办法须要标注大量的自然语言逻辑表达式，而信息抽取式的办法更偏差端到端的计划，在简单问题、少样本状况下体现更好，但若子图过大，会显著升高计算的速度。

因而，思考到两者的劣势，咱们采纳将两者联合的计划。如下图 3 所示，整体的流程分为四大步骤，以“故宫周末有学生票吗”为例：

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 所示：

依存剖析是句法分析的一种，它的目标是辨认句子中词与词的非对称摆布关系，在输入的后果中用有向弧示意，该弧线由隶属词（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 的后果，通常业界通用的办法次要归类为以下两种：

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 所示：

问题的跳数依据实体数量决定，单跳问题通常只波及商户的根本信息，比方问商户的地址、电话、营业时间、政策等，在常识图谱中都能够通过一组 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 所示：

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 所示：

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 的更多可能性！简历投递地址：wangsirui@meituan.com。

作者简介

如寐、梁迪、思睿、鸿志、明洋、武威，均来自搜寻与 NLP 部 NLP 核心常识图谱组。

浏览美团技术团队更多技术文章合集

前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试

| 在公众号菜单栏对话框回复【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词，可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至 tech@meituan.com 申请受权。