携程实体链接技术的探索及实践

移动开发 移动应用
本文主要介绍了旅游AI知识图谱组在实体链接技术上的探索和实践,阐述了实体链接的基本定义、相关技术发展路线和应用价值,并结合各子模块详细说明了基于旅游知识图谱的实体链接系统的架构和流程,最后介绍了实体链接系统的落地场景。

​作者|携程旅游AI研发团队致力于为携程旅游事业部提供丰富的AI技术产品,其中知识图谱组专注旅游领域知识图谱的构建及应用落地。

 一、背景介绍

随着网络应用技术的飞速发展,多元化、低密度数据的急剧膨胀对人们获取正确信息带来巨大挑战,大量冗余信息出现的根源在于自然语言表达的多样性,即一词多义和多词同义。例如,“苹果”在不同语境下既可以表示蔷薇科苹果属植物又可以表示苹果产品公司,“申城”和“魔都”尽管字面完全不同,却都是上海市的别称。实现对海量Web数据的高效处理,理解用户意图,降低信息过载,是实体链接的目标。

在旅游领域,用户关注的实体通常是旅游目的地周边景点、酒店和玩乐方式等,这些对象在地理信息系统(Geographic Information Systems, GIS)中统称为兴趣点(Point of Interest,POI),主要包含四个核心维度:名称、地址、坐标和类别。随着互联网电子地图服务与基于位置的服务(Location Based Services,LBS)的普及,POI无论从概念范畴还是信息纵深上都有了长足发展,已成长为信息空间的参天大树,可以说目前如日中天的互联网各个风口都和POI有一定关系,如电商、O2O、社交、本地生活、互联网金融、共享经济等。

构建以POI知识库为基础的实体链接服务,提升旅游搜索、智能问答、知识挖掘和信息抽取等工作的效果,对改善用户体验有重要意义。

二、问题分析

实体链接,指将文本中的表述链接到知识库中相应实体来进行实体消歧、帮助计算机理解文本具体含义的任务,一般包含实体提及识别、候选实体生成和候选实体消歧三个步骤。

图片

图1 实体链接功能示例

1)实体提及识别,旨在识别出自然语言中实体提及片段的边界,并标示其在输入文本中的位置。以图1例子进行说明,用户输入的搜索词“武汉东湖景区”包含了“武汉”和“东湖”两个命名实体提及,它们可能表示知识库中某些实体的正式名称、简称、俗称或者别名。

2)候选实体生成为文本中给定的实体名称生成可能链接的候选实体集合,即根据前一步识别到实体提及片段从知识库中召回所有用户可能感兴趣的实体,该步骤生成的候选项集确定了实体消歧的范畴。例如,“武汉”这一实体提及可以从知识库中召回作为城市的“武汉”,而“东湖”则可以召回“武汉东湖”和“绍兴东湖”两个景点。

3)实体消歧是确定一个实体指称项所指向的真实世界中实体的过程,通过候选实体的静态特征、或与query交互计算的动态特征输出一个用于排序的分值。以图1为例,结合上下文可知,用户真正查询的是武汉市下面的东湖,而非位于绍兴市的东湖,因此“武汉东湖”相对“绍兴东湖”应有更高的得分。

实体提及识别常被视作序列标注任务,经典方法有基于词典的方法和基于统计的方法。基于词典的方法可分为前向最大匹配、后向最大匹配和双向最大匹配;基于统计学习的代表方法有HMM和CRF,其表现通常依赖大量人工构建和维护的特征模板。随着算力的提升和端到端的神经网络技术的发展,CNN、RNN等结构被广泛用于建模序列表示,其自动组合低阶特征获得高阶特征的功能摆脱了人工特征工程耗时费力的弊端,同时神经网络强大的表达能力显著提升了传统算法的效果。

Google在2018年提出的Transformer则首次将自注意力模型带入大众视野,为序列表征的高效并行计算提供了可行的方案。Self-attention机制的运用使得序列中每个位置的token都能充分学习到上下文语义,自适应地接收来自不同位置token的信息流入,成为近年大热的自监督学习任务的基本编码单元,启发了众多以此构型为基础的大型预训练语言模型,BERT便是代表之一。

使用Transformer Encoder结构的BERT从无标签语料中学到了大量先验知识,只需在特定下游任务上微调权重,便能获得出色的结果。BERT一度霸榜GLUE,刷新了各大自然语言理解任务的SOTA,其预训练加微调的学习范式也成为NLP界的重大里程碑。

候选实体生成是一种检索任务,传统检索方法以词袋模型(Bag of Words,BOW)为代表,如TF-IDF、BM25等,这类算法不考虑词序,也忽略了词与词之间的前后关联,除需人工设计公式外,在统计词的权重、词频的基础上,还要引入覆盖率、紧密度,扩展同义词等,才能达到一个较好的效果。词袋模型最大的缺陷是只能解决字面量的匹配问题,无法获得query与document语义相关性,因此,以双塔式模型和交互式模型为代表的语义向量检索方案开始受到重视。

双塔模型主要有DSSM、Siamese网络,通常使用两个相同或不同的编码器来提取query和document的低维句向量表示,然后设计一个相关性函数,如cosine、内积等,计算两者间的相似得分;交互式模型则在低阶特征组合阶段就开始建模query与document之间的相关性,其关键思想在于交互矩阵的构造,如ESIM、MatchPyramid等,这类模型最终获得的是query-document对的整体表示,因此能避免独立编码两部分造成的精度丢失,实践中往往有更好的表现。

实体消歧是在更精细的粒度上对候选实体进行排序,常见的学习排序算法包括单点法(pointwise)、配对法(pairwise)和列表法(listwise)三类。pointwise的思想是使用回归或分类模型独立地为每个候选实体进行打分;pairwise考虑的是候选实体两两之间的相对排序而非各自的绝对分值,因此损失的计算依赖于成对样本;listwise则将一个query的所有候选实体集当作一个样例,输出为各候选实体的得分。在特征构造与表示学习方面,可以使用query的特征、候选实体自身的特征或两者的交互特征,相关方法与前文提到的语义匹配类似。

三、旅游知识图谱

知识图谱(Knowledge Graph, KG)是一种大规模语义网络,由节点和节点之间相互连接的边构成,可以表征实体之间结构化的关系,被认为是通往认知智能的基石。其中,节点表示概念或对象,边表示概念与概念、概念与对象或对象与对象之间的关系。在知识图谱中,每条知识都可以表示成一个SPO(Subject-Predicate-Object)三元组,例如长宁区属于上海市,在旅游知识图谱中表示为(长宁区,upperClass,上海市)。正因为高度结构化的知识表示易于计算机理解,知识图谱在信息检索、智能推荐、金融风控上都有广阔应用场景。

我们团队打造的旅游知识图谱以Neo4j和Nebula图数据库作为储存方案,图谱Schema涉及18种实体类型和12种关系类型,目前已有约1千万实体、3千7百万条三元组,知识数量初具规模。同时在数据治理层面建立了完备的自动更新机制和监控体系,确保每日新增知识入库,过期知识移除,提升了知识图谱的可靠性。

图片

图2 旅游知识图谱数据探索

四、技术方案

在实体链接系统的技术选型上,我们遵循三阶段流程,即实体提及识别、候选实体生成、候选实体消歧三个串行的子模块协同完成对自然语言的分析。

图片

图片

图3 实体链接系统流程

此外,我们在工程上做了一些优化,使用Redis缓存别名到候选实体id的映射关系以及实体id到实体属性的映射关系,避免频繁查询Neo4j或Nebula图数据库带来高延时。

五、功能模块

5.1实体提及识别

这一步骤结合了神经网络模型和别名前缀树进行多路检测,以扩大候选实体召回范围。

5.1.1 实体别名前缀树

我们将知识库中所有实体别名字符串插入到一棵前缀树结构,该前缀树除根节点不包含字符、叶节点包含终止符外,每个中间节点都只包含一个字符。从根节点出发到某一节点,经过的字符连接起来表示该节点对应的字符串,因此树中每个节点的后继节点都拥有相同的前缀。

图片

图4 实体别名前缀树示例从根节点到叶节点的路径闭合了一个位于知识库中的实体别名,在实际检索时通常采用前向最大匹配策略:

1)维护两个指针:前缀树指针和query指针,前缀树指针初始化时位于ROOT节点,query指针位于query文本首字符。

2)如果query指针指向的待匹配字符在前缀树指针对应节点的后继节点中,则移动前缀树指针至该子节点,同时query指针后移一位。

3)如果query指针指向的待匹配字符不在前缀树指针对应节点的后继节点中,若后继节点包含了end,则闭合实体提及字符串,前缀树指针回到ROOT;否则前缀树指针递归地回退至上级节点(query指针同步前移),直至上级节点的后继节点中包含end节点,然后闭合实体提及字符串,前缀树指针回到ROOT;若前缀树指针回退至ROOT的过程中没有闭合任何实体提及,则query指针后移一位。

前缀树可以最大程度减少对用户query中无效字符串的匹配,且最坏情况的时间复杂度仍优于哈希表,提供了一种十分高效的字符串搜索方案。

5.1.2 命名实体识别模型

这里我们使用以BERT为骨架的指针网络标注命名实体的边界,图5展示了模型框架、前向传播过程以及标签解码方式。

图片

图5 命名实体识别模型结构

在推理阶段,根据头、尾指针预测结果闭合相同实体标签对应的token位置获得实体提及边界。

5.2 候选实体生成

在旅游知识图谱中,“别名”是一种特殊的节点类型,我们在图谱构建阶段会为每个新加入的POI、目的地、产品以及标签类型的实体与其各别名(实体名称也是一种别名)之间建立hasAlias类型的关系。因此,POI、产品、标签实体都至少关联到一个别名实体。

以图6为例,输入文本为“武汉 江西 东湖”时,假设识别到的实体提及为“武汉”、“江西”和“东湖”,将这三个提及作为“别名”节点的name属性值进行条件查询可得到三个别名节点(图中标记为黄色),这三个别名节点通过类型为hasAlias的入边又可以查到若干POI节点,这些POI节点便是该文本召回的候选实体。

图片

图6 文本为“武汉 江西 东湖”时的候选实体子图

我们在候选实体生成阶段并未采用向量检索方案,因为实体提及一般是非常短的字符串,基于相似度的检索不确定性高,难以保证召回结果的可靠性,维护高质量的别名词表更适合当下场景。

候选实体生成模块还包括基于路径的预过滤逻辑。以图6为例,检测到不同实体提及召回的候选实体之间可能存在路径联系,如“武汉市”到“东湖”、“江西省”到“芦林湖”,那么与路径中节点有相同别名但又不在路径上的POI节点,比如绍兴东湖,则不会作为候选实体返回。实践中为了避免路径假定过强而误丢一些重要的节点,会施加一些约束条件,这些方法多与规则相关,不再赘述。

5.3 候选实体消歧

该模块用于对候选实体计算排序得分,我们使用基于BERT的交互式语义匹配模型。

首先拼接query字符串与候选实体的描述文本,经分词和数值化处理后,输入到BERT提取高阶交互特征。

在BERT输出层选择输入序列中[CLS]位置上的特征向量hCLS与该候选实体在query中的实体提及片段的首、尾位置token对应的特征向量hhead、htail进行拼接,通过一个仿射变换,使用sigmoid激活函数获得该候选实体为链接对象的概率值:

其中,w和b为线性层参数。

图片

图7 实体消歧模型结构

模型训练阶段的损失函数为二分类交叉熵损失。

这里y为候选实体的0-1真实标签。

推理阶段,为query召回的各候选实体计算概率得分并按从高到低排序,根据预设阈值截断候选实体序列,得到链接结果。

六、实践场景

6.1 携程旅游搜索

携程旅游搜索词义解析服务通过后端配置词典进行分词及词性标注,返回所有匹配到的POI词项,对重名POI不具备拒识或排序功能,常常会引入与query无关的搜索结果。

在接入实体链接系统后,能够结合上下文信息对重名POI消歧,即便遇到上下文缺失的情况,也可以利用出发站城市辅助候选实体排序。

Case1 搜索词为“武汉东湖”,接口原先返回“武汉市”和所有名为“东湖”的景点,调用实体链接服务,返回结果中只有位于“武汉市”的东湖景区(id:1xxx6)。

图片

Case2 搜索词为“深圳迪士尼”,接口原先返回“深圳市”和所有迪士尼度假区。尽管深圳市下面确实没有迪士乐园,但常识会让人联想到用户实际意图可能是位于香港的迪士尼乐园(id:1xxx9),这正好是经实体链接后的返回结果。

图片

Case3 搜索词为“白云山”,出发站设置为东莞市,接口原先返回所有名为“白云山”的景点,且不存在排序,无法推断用户对各POI感兴趣的程度。调用实体链接服务后,返回结果中广州市的白云山(id:7xxx4)被排在top1位置,说明实体消歧阶段系统捕获到了“广州白云山”与定位站“东莞市”之间的关联。

图片

6.2 携程旅游智能客服

在人机对话系统中,语义槽填充通常与意图识别联合进行,以确定追问话术、歧义澄清话术,或完成对用户自然语言的理解,从知识库中搜索并返回答案。

例如,用户询问“从上海到成都的航班”,其意图为“查询航班”,但仅对用户意图分类还不足以给出准确回答,因为缺失了两个关键信息:航班的出发站和到达站,这便是与“查询航班”相关的语义槽,只有完成意图识别和语义槽填充,才具备搜索答案的条件。这里出发站和到达站分别指上海和成都,正好是旅游知识图谱中的两个POI,借助实体链接可以很方便地找到这两个POI的id信息。

携程旅游智能客服在引入实体链接服务后,词槽抽取F1 Score较原先提升了超过12个百分点,反映了实体链接在客服场景下的巨大潜能。

6.3 携程POI关键信息更新

门票相关部门需要保证一些POI关键信息频繁更新的准确性,如景区开闭园时间,这对于产品销售及用户体验有至关重要的意义。

开闭园信息更新的主要依据为每日从景区官方渠道获取的公告和资讯,通过解析这些文章内容提取POI名称及对应的开放或关闭时间。在疫情反复的当下,该信息面临更加频繁的变动,因此对准确性和时效性提出较高要求。

原始文本解析完成写入数据库时会挂靠到发布资讯的景点下,但这个信息不一定正确,实际中存在很多从文本抽取景点与发布资讯景点不一致的情况,比如某景区发文公告的是下级某个子景点闭园,这时需要通过实体链接将抽取的景点名映射到知识图谱中的实体从而获取真正的POI id,此功能可以提高信息的准确性,同时进行POI消歧。

景区开闭园抽取项目在引入实体链接后,准确率提升近六个百分点,极大改善了原抽取流程的效果。

6.4 携程重复POI和上下级POI关系识别

门票活动相关部门维护的POI数据来源十分复杂,包括内部和官方等多个平台。POI数据批量导入时未全部识别出重复的POI以及POI之间的上下级关系,会导致系统内存在较多重复的POI,产生分流;或者导致系统内存在游离在外的POI,导致展示不全,用户无法全面了解景区情况。因此需要及时获取这些信息并修复,以提升信息覆盖全面性,提升平台的信息可靠性。

POI的地址或介绍中可能隐含了该POI的父级节点。例如,地址为“xxx路xxx号xxx景区内”的POI,其上级节点可能是某个景区,如果使用实体链接技术能获取到该景区的id,并且这两个POI在当前图谱中不存在上下级关系,则可以作为一个重要特征加入关系识别系统中。该项目自上线起,上下级关系识别的平均正确率达到90%以上,已累计改善了近千条POI信息的准确性。

七、总结与展望

本文主要介绍了旅游AI知识图谱组在实体链接技术上的探索和实践,阐述了实体链接的基本定义、相关技术发展路线和应用价值,并结合各子模块详细说明了基于旅游知识图谱的实体链接系统的架构和流程,最后介绍了实体链接系统的落地场景。

未来我们将紧跟前沿技术发展,促使知识图谱同实体召回、精排任务更紧密地结合,充分运用图的结构提升现有模型的效果和可解释性,探索更加高效、轻量化的模型,同时也会兼顾技术落地,今后赋能更多的旅游场景。

责任编辑:未丽燕 来源: 携程技术
相关推荐

2023-08-18 10:49:14

开发携程

2024-11-05 09:56:30

2022-05-27 09:52:36

携程TS运营AI

2024-03-22 15:09:32

2024-04-18 09:41:53

2023-11-13 11:27:58

携程可视化

2022-07-15 12:58:02

鸿蒙携程华为

2022-05-13 09:27:55

Widget机票业务App

2024-12-18 10:03:30

2016-12-15 21:41:15

大数据

2023-12-29 09:42:28

携程开发

2023-07-07 12:26:39

携程开发

2022-08-20 07:46:03

Dynamo携程数据库

2022-07-08 09:38:27

携程酒店Flutter技术跨平台整合

2022-08-12 08:34:32

携程数据库上云

2022-07-15 09:20:17

性能优化方案

2023-02-08 16:34:05

数据库工具

2023-03-14 14:01:00

内存优化

2024-07-05 15:05:00

2022-06-03 09:21:47

Svelte前端携程
点赞
收藏

51CTO技术栈公众号