腾讯音乐知识图谱搜索实践

Posted 2022-02-05 DataFunTalk

分享嘉宾：Elvin 腾讯音乐 高级工程师

编辑整理：李一 中科雨辰

出品平台：DataFunTalk

导读：近几年来，图数据在计算机领域得到了广泛的应用。互联网数据量指数级增长，大数据技术、图数据方面的应用增长很快，各家互联网大厂都在图数据分析和应用方面大量投入。为了让我们的搜索更加智能化，腾讯音乐也借助了知识图谱。今天和大家分享下腾讯音乐在图谱检索与业务实践方面的探索，主要包括以下几大部分：

音乐知识图谱介绍

图数据库选型

项目架构介绍

知识图谱搜索功能应用举例

总结与展望

01

音乐知识图谱介绍

首先和大家介绍下音乐知识图谱的相关知识。

1. 音乐数据分类

图状数据广泛存在，其中与音乐相关的业务数据主要有以下三类：

内容方面有歌曲、综艺、影视、专辑等；

歌手方面有歌手信息、歌手之间的关系，包括组合、相似等；

歌手和歌手内容之间的关系有演唱、作词、作曲等。

2. 音乐知识图谱的应用场景

(1) 复杂搜索需求实现

音乐知识图谱不仅可以做简单的搜索，还可以实现复杂搜索需求。例如要查询周杰伦的男女对唱的歌曲有哪些，如果要实现这个查询，需要对周杰伦的歌曲进行一定的过滤，歌手的数量要等于2，另一位歌手的性别是女性，还要考虑基于播放量、歌手权重等等的排序。在传统关系型数据要实现这个功能很复杂。利用知识图谱就比较简单了，先找到歌手周杰伦，查找周杰伦的所有歌曲中满足2人合唱，另一个歌手性别是女性的，只要两跳就可以实现复杂的搜索查询。

(2) 搜索结果的相关推荐

可以根据搜索的关键词，查询图谱中的实体节点，根据实体节点查询出关联的节点，用关联的节点给出推荐的结果。例如用户搜索周华健，可以通过关联信息推荐出李宗盛。如果通过搜索引擎，很难推荐出李宗盛，而用知识图谱，只要两跳，周华健歌手到对应组合（纵贯线），从组合再到另一歌手李宗盛，只要两跳。

(3) 基于知识计算给出答案

可以根据知识图谱的计算来给出一些答案，通过图谱的关联信息，实体上下位信息，实体属性信息，查询出相应的答案。例如用户搜索刘德华90年年代的歌曲，用知识图谱的话，只要歌手刘德华，时间90年代歌曲，两个联合起来就可以得到结果。

3. 搜索召回和知识图谱召回优缺点

搜索召回，是基于文本匹配的，召回之后会涉及相关性排序，相对来说比较复杂，精准度不足，可能过度召回。搜索召回的流程比较复杂，排序策略也相对复杂。

知识图谱召回，是基于实体之间的关系进行查询，可以做到精准召回，也没有过召回，召回的流程可以很短，也就是几条图查询的语句。另外，知识图谱还具备一定的推理能力。

02

图数据库选型

要实现图查询，首先得做图数据库的选型。

图数据库的选型，需要考虑以下几点因素：

开源非付费，考虑到成本及源码可控性，选择拥抱开源；

分布式框架可扩展，随着数据的增加和减少，后台必须是可扩展的；

高性能毫秒级多跳查询，要做到毫秒级的在线响应；

支持千亿级规模数据量；

支持数据批量导入导出。

我们对比了8个数据库，对优缺点进行了分析，对这些数据库进行了分类：

第一类，以Neo4j为代表的，只有单机版本，性能比较优秀，但是不满足分布式可扩展性要求。Neo4j的商业版本支持分布式，但是却是收费的。

第二类，JanusGraph、HugeGraph这类数据库，支持分布式可扩展的，他们的共同特点是在现有的图谱上增加了通用的图语义解释层，受到存储层架构的限制，存储层是外部数据库实现，不支持计算下推的功能，导致性能较差。

第三类，以NebulaGraph为代表，这一类数据库都实现了自己的存储层，支持计算下推，做了效率上的优化，性能提升很多。

从上图看到综合性能测试数据。我们通过1度邻居（跟点直接相连的点），2度邻居，共同邻居，这三个方面来对数据库性能进行测试，可以看到Nebula不管是单机性能，还是集群性能，都要远超于其他竞品。考虑到性能，社区活跃度，版本迭代速度，语言上的通用性，我们最终选择了Nebula数据库做为我们项目的图数据库。

03

项目架构介绍

1. 在线层

包含以下模块：

Storaged负责具体数据的存储，包括点数据、边数据，以及相关的索引；

Metad负责存储图数据的meta信息，例如数据库的schema、addition等；

Nebula graphd负责数据计算的逻辑层，是无状态的，可以进行平行扩展，内部执行计算引擎来完成查询的整个过程。

Nebula proxy是我们新增的模块，作为整个nebula模块的代理层，可以接受外部的命令，并对图数据进行操作，包括图的查询，更新，删除。另外，nebula proxy也负责协议的转换，集群的心跳和路由注册。

由于单集群有重建数据的需求，也为了防止机房故障，我们选择双集群来支撑整个服务的可用性。

在线层请求处理的流程为，cgi在接收到用户请求后，将用户请求传给broker模块，broker请求模版匹配生成相应的图查询语句，从Zookeeper中提取可用的集群，将查询语句发给nebula proxy进行图谱召回，nebula proxy将具体的查询语句传递给nebula graphd, nebula graphd负责执行最终的语句，然后把结果返回给broker层，broker层补充一些前端显示摘要后，将数据返回给前端做展示。

2. 离线层

音乐数据有实时的新增数据，例如新增发行的唱片，还有全量数据的更新，所以我们选择了全量加增量的数据层方案。

(1) 全量数据生成方案

音乐很多数据存在数据库中，先将数据从DB中dump出来后，由IndexBuilder模块将数据格式转换为所需的格式后形成一个全量的源数据，将全量的源数据上传到HDFS后，通过运行spark任务，把数据转为Nebula底层所需的数据文件，IndexMgr发现有新的常量数据生成后，将数据文件下载下来，将全量数据加载到NebulaProxy，这样全量数据就生成好了。

(2) 实时数据的生成

每隔一段时间，通常是几分钟，将几分钟之内的业务修改数据dump出来后，转为特定的格式，形成一个增量的源数据，增量的源数据存入到Kafka里面，可以用于数据的重发和恢复，DataSender从Kafka队列里面拉取到最新的数据，通过NebulaProxy发送到集群，这样增量数据就生效了。

这里涉及到了一个增量补发的问题，因为存量过程dump过程中要耗费很长时间，可能要花几个小时，在全量数据dump过程中也有新的增量数据，这期间的增量数据可能并没有进入到全量的数据当中。所以这里需要进行一个历史增量的补发，从T0后（全量同步开始时间）的新增数据，不在全量数据中，需要将T0之后的数据全部进行补发。

04

知识图谱搜索功能应用举例

1. 配置化召回

常规召回方式为：根据Query生成查询语句，获取召回结果，根据策略混排，召回结果展示。

这样做的问题是，每做一次，每增加一种新的召回策略，以上四步都要重复，所以召回不够灵活，业务改动大。

我们增加了一种新的基于Query模板的召回方式，就是根据模板生成对应的查询语句，同时预先设置了一些常用的混排策略。比如我们配置一个学校加校歌的模板，当查询校歌的时候，我们把学校的名字提取出来，填到查询语句里面，形成一个完整的图查询语句。同时也预置了一些混排插入策略，填入对应的混排参数，就可以做到上线。这样做的优点就是召回比较灵活，和搜索相比，召回上线的代价比较小。

2. 业务应用

我们最终上线了上图这些业务，支持各类搜索场景。

校歌搜索：当用户搜索大学校名和校歌组合时，召回对应的学校的校歌；

歌手场景：当用户搜索歌手名字的时候，返回歌手所在组合，以及合唱过知名歌曲的合作歌手等；

影视场景：当用户搜索影视主题曲、片尾曲、插曲等等的时候，返回对应的影视的歌曲。

05

总结与展望

今天的讨论从图数据的选型开始，到schema分类定义，项目架构层设计，再到知识图谱的搜索。结论是采用图数据，可以很好的把专家经验智能融入图谱。通过图数据技术实现的知识库，增强了检索、推荐、可视化等功能，腾讯音乐很好的对知识图谱技术进行了应用，大大提高了客户的搜索体验感，增强了客户黏度。让我们拥抱AI技术，让其更好地服务于生活。

06

精彩问答

Q：在搜索过程中有考虑音频信息吗？

A：这个是有考虑的，我们可以通过音频识别技术，首先去识别歌曲的一个大的分类流派，比如说像民谣摇滚流行这些流派，然后在线检索的时候，我们会通过这种语音搜索去召回。另外，我们跟QQ音乐天津实验室也有合作，比如像听目前的金科视曲，后台走的也是走我们的限量搜索，也是通过对音频信息进行的召回。

Q：语义检索结果排在第几位？是怎么和关键词检索一起排序的？

A：首先我们会通过算法去挖掘某一个语义标签跟某一首歌曲的相似度，语意搜索的话就可以通过语音标签进行召回，优先把语义相似度高的结果排到前面。当然也会有一些奇异的情况，比如说像赵雷有一首歌叫民谣，民谣这首歌就是一个歌曲，它同时也是一个语义，我们排序的时候也会兼顾这种混排的效果，最下层排序，首先会把民谣的歌曲放在前面，因为它毕竟是一个比较知名歌手的歌曲，下面会把对应的语义的结构放在后面，然后我们在更上层会有基于算法的排序模型去给用户推荐点击量高的调前。

Q：全量索引版本切换双buffer内存是否会翻倍？

A：实际上我们索引切换的过程中是没有双buffer的，是按每一个分片下的每一个副本进行逐个切换，切换的时候会进行动态的卸载，所以并没有占用额外的内存。

Q：跨越截断，是在index截断好，还是在线选择截断？

A：是在线选择截断，如果离线截断会导致数据丢失，这样是没办法回溯的。截断也是分片的，向量检索也是可以分片之后，做并行检索。

今天的分享就到这里，谢谢大家。

---

在文末分享、点赞、在看，给个3连击呗~

---

分享嘉宾：

活动推荐：

2022年02月19日，由英伟达、中电港联合举办的《深度学习推理优化与部署实践》技术分享，邀请英伟达、京东科技、vivo技术大咖，围绕“如何给深度学习加速？”为大家带来系列分享，感兴趣的小伙伴可识别下方海报二维码进行报名。

关于我们：

DataFun：专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会，已邀请近1000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章500+，百万+阅读，12万+精准粉丝。

大厂技术实现 | 爱奇艺文娱知识图谱的构建与应用实践 @自然语言处理系列

知识图谱是一种用图模型来描述知识和建模世界万物之间关联关系的技术方法。本文研究的是爱奇艺奇搜知识图谱的构建流程与应用场景，了解这一文娱行业知识图谱是如何帮助用户精确找到想要的内容、回答用户问题、以及理解用户搜索意图的。

知识图谱是一种用图模型来描述知识和建模世界万物之间关联关系的技术方法。本文研究的是爱奇艺奇搜知识图谱的构建流程与应用场景，了解这一文娱行业知识图谱是如何帮助用户精确找到想要的内容、回答用户问题、以及理解用户搜索意图的。

一图看懂全文

获取『自然语言处理』行业解决方案

『推荐与计算广告』系列包括爱奇艺、美团、小米、百度等公司的业务分析和技术解读。项目实现代码、项目数据集、论文合辑、文章合辑等，已整理为大厂行业解决方案。扫码前往公众号（AI算法研究所） 后台回复关键字『自然语言处理』获取。

相关代码实现参考

ShowMeAI社区的技术专家小伙伴们也对知识图谱的典型算法做了实现。对『知识图谱构建与落地实践』细节感兴趣的话，请前往我们的GitHub项目（https://github.com/ShowMeAI-Hub） 查看实现代码。感谢ShowMeAI社区参与此项目的所有技术专家小伙伴,也欢迎大家 PR 和 Star！

推荐阅读 | 点击查看『自然语言处理』系列教程（http://www.showmeai.tech/tutorials/knowledge-graph）

• 大厂技术实现 | 爱奇艺文娱知识图谱的构建与应用实践

---

2012年5月，Google发布了知识图谱(Knowledge Graph)，以提升搜索引擎返回的答案质量和用户查询的效率。有了知识图谱作为辅助，搜索引擎能够洞察用户查询背后的语义信息，返回更为精准、结构化的信息，更大可能地满足用户的查询需求。

目前，随着智能信息服务应用的不断发展，知识图谱已广泛应用于智能搜索、智能问答、个性化推荐、聊天机器人、大数据风控、证券投资、智能医疗、自适应教育等领域。知识图谱做AI技术的重要垂直分支，其在技术领域的热度也逐年上升。

本篇是『知识图谱构建与落地实践』的实践篇，我们与来自爱奇艺的NLP工程师奇异果，一起研究学习爱奇艺搜索团队2015年开始搭建的 奇搜知识图谱库 (https://so.iqiyi.com/) ，了解奇搜知识图谱的构建过程，及其在爱奇艺搜索、NLP服务中的具体应用。

一、知识图谱介绍

本质上，知识图谱是一种揭示实体之间关系的语义网络，对现实世界的事物及其相互关系进行形式化地描述。

A knowledge graph consists of a set of interconnected typed entities and their attributes.

——《Exploiting Linked Data and Knowledge Graphs in Large Organisations》

知识图谱是由一些相互连接的实体和他们的属性构成的。换句话说，知识图谱由一系列的（实体，关系，实体）三元组构成，用以表达现实世界中的诸多场景。

• 实体（Entity）指的是现实世界中的事物，是图里的节点。
• 关系（Relation）指的是不同实体之间的某种联系，是图里的“边”。

图示为一个社交网络知识图谱： 实体有『人』『物品』『建筑』『城市』等。『人与人之间的关系』可以是朋友或粉丝，『人与物品的关系』可以是创作或喜欢。

二、奇搜知识图谱构建方法与流程

爱奇艺搜索（奇搜，https://so.iqiyi.com/） 是国内最大的视频搜索引擎之一，涵盖全网海量视频资源,为用户提供优质的全网视频&娱乐领域的搜索服务。

奇搜团队努力完善对视频内容和用户意图的理解，并在过程中构建了以视频领域为主的知识图谱库。

当前，奇搜知识图谱的构建流程主要分为几个步骤：

• 知识表示与建模
• 知识获取
• 知识融合
• 知识存储
• 知识应用（知识查询与推理）

2.1 知识表示与建模

我们在确认知识的建模表示方式之后，再构建知识图谱。目前主要的知识建模方式有两种，爱奇艺奇搜知识图谱的构建采用的是自顶向下的建模方式。

（1）自顶向下的数据建模方法。先为知识图谱设计数据模式（ Schema ），再依据设计好的数据模式进行有针对性的数据抽取；

（2）自底向上的数据建模方法。先进行数据的收集和整理，再根据数据内容总结、归纳其特点，提炼框架，逐步形成确定的数据模式。

2.1.1 RDF三元组

RDF（Resource Description Framework），即资源描述框架，实际上是一种数据模型，用来链接资源的各种描述。

• Resource：页面、图片、视频等任何具有URI标识符。
• Description：属性、特征和资源之间的关系。
• Framework：模型、语言和这些描述的语法。

RDF由一系列三元组（triple）模型组成，即每一份知识可以被分解为 (Subject(主)，Predicate(谓)，Object(宾))。

• 主语（Subject）：声明被描述的对象
• 谓语（Predicate）：这个对象的属性
• 宾语（Object）：这个属性的值

所以，RDF三元组可以被描述成 (对象，属性，值)，即上文提到的 (节点，边，节点) 这样的图。

2.1.2 RDFS (RDF Schema)

一个三元组就是一个关系。在RDF里可以声明一些规则，从一些关系推导出另一些关系。这些规则称为“Schema”，所以有了 RDFS（RDF Schema）。规则可以用一些词汇表示，如Class、subClassOf、type、Property、subPropertyOf、Domain、Rnage等。

『爱奇艺是一家人工智能公司』 和『一家人工智能公司是一家高科技公司』，可以推导出『爱奇艺是一家高科技公司』。

2.1.3 奇搜知识图谱Schema

奇搜基于RDF/RDFS定义了图谱的实体类型、关系（属性）类型、以及实体本身的 Schema 定义。每一层定义在 Schema 的表示语法上都是一致的。

• Rules层（规则层）。一些基础概念的定义（包括RDF/RDFS已有的定义，以及基于RDF / RDFS定义的、供实体类型/属性定义使用的规则定义），该层规则的定义一般在确定后是不可变的。
• Ontology层（本体定义层）。包括可实例化的实体类型（Class，可继承）和属性（Property，可继承）的定义，如Thing，Person，wife，name等。
• Entities层（实体层）。保存在实体库中的具体实体。

为了帮助定义和使用图谱 Schema（主要上图中的本体定义层），爱奇艺搜索团队开发了一套 Schema 系统来负责管理和解析奇搜知识图谱的 Schema 定义：

最终定义的实体类型的继承关系片段示例如下图：

2.2 知识获取

知识图谱的构建是后续应用的基础，而且构建的前提是需要把数据从不同的数据源中抽取出来。知识获取是构建知识图谱的前提条件，也是自动构建知识图谱的影响核心要素。

数据是知识图谱的根基，直接关系到知识图谱构建的效率和质量。比如，从结构化的数据中构建知识图谱比从非结构化的数据中构建，效率和准确率要高；数据越复杂，噪音越大，构建成本就越高。

目前奇搜知识图谱的数据来源除去人工创建的数据外，主要有站内数据、垂直网站数据与百度百科数据三种数据来源。

2.2.1 实体分类

实体分类主要用于处理百度百科的数据。因为百度百科的数据没有类别信息，需要先对词条进行实体类型的识别。具体实现是为每种实体类型训练一个实体分类器，准确率可衡量，并且互不影响，可以快速拓展。

实体分类器模型示意图，整体采用启发式方法。

• 构建基于规则池的分类器，生成训练数据，训练DNN模型（self-attention）文本分类模型；
• DNN分类器与规则分类器互相扩充迭代（一到两轮），最终线上使用规则分类器。
• 生成过程中会用上百科词条中的描述文本、infobox字段、超链接词条、词条标签等信息作为特征。

2.2.2 实体抽取

实体抽取，是指从数据中识别和抽取实体的属性与关系信息。对不同类型、不同数据源的数据，分别开发属性/关系抽取脚本。

由易到难，主要包括以下三类抽取方式：

（1）结构化数据抽取：大部分站内/垂直网站的信息，以及部分百度百科的信息，是结构化的数据，比较易于抽取。源数据结构和实体类型定义（即目标数据结构）多种多样。为了提高开发效率，将结构化数据的抽取流程进行抽象，并写成统一的框架，利用策略模式将抽取的具体规则用groovy脚本来实现。当扩展新的来源和目标实体类型时，只需实现新的抽取脚本。

（2）半结构化数据抽取：百度百科中存在很多表格、列表等格式不完全规则的半结构化信息，抽取有一定难度。比如，半结构化信息中存在一些质量较高的统计性的数据。对于这类数据，采用基于有监督学习的包装器归纳方法进行抽取。

（3）非结构化数据挖掘：百度百科以及站内的描述等大量文本中，也存在有很多宝贵的信息。对于这类数据的实体挖掘，需要借助自然语言处理的手段（主要是实体识别等服务）。

• 一方面，通过实体链接服务把从文本中抽取得到的实体对象，链接到实体库中对应的正确实体对象，以挖掘文本中关系。
• 另一方面，利用NER（name entity recognition/实体识别）技术来识别来挖掘文本中的实体。

2.3 知识融合

知识融合主要解决实体对齐（Object Alignment） 的问题。完成实体抽取后，存在实体ID不同但代表真实世界中同一对象的情况。知识融合即是将这些实体合并成一个具有全局唯一标识的实体对象，添加到知识图谱中。

下图是实体对齐的流程图。

所有来源的实体数据都会进入原始实体库，并对原始表中的数据建立索引。当一个原始实体 rawEntity 进入最终实体库之前，要在原始实体库中寻找是否有其它原始实体和rawEntity实际上是同一个实体。

• 首先，在索引中根据名字、别名等字段查询出若干个可能是相同实体的候选列表，这个步骤的目的是减少接下来流程的计算量。
• 然后，经过实体判别模型，根据模型得分识别出待合并对齐的原始实体。
• 最后，经过属性融合模型，将各原始实体的属性字段进行融合，生成最终的实体。

这个流程中的合并判断模型实际上是通过机器学习训练生成的二分类器。

2.4 知识存储

线上使用的图数据库引擎选择了JanusGraph。JanusGraph需要外部的存储系统与外部索引系统的支持。所以，爱奇艺搜索团队借助爱奇艺云平台的Hbase和ES集群，搭建了自己的JanusGraph分布式图数据库引擎，支持在线游走查询服务。

三、奇搜图谱的业务应用

3.1 问答式搜索服务

基于图数据库引擎提供的查询服务，以及NLP技术对用户query的意图理解，提供了多种类型的问答式搜索结果服务。包括：

• 明星、剧集的属性类的查询：如生日、剧的播出时间等。
• 实体的关系类的查询：明星的关系、剧集与明星/角色的关系、剧集间的关系、以及各种关系的组合等等。

3.1.1 智能问答

◉ 吴京学校

3.1.3 关系查询

◉ 《甄嬛传》演员表

3.1.3 剧集周边

◉ 《请回答1988》主题曲

3.1.4 关系组合

◉ 刘培强的演员还演过

3.2 基础数据服务

奇搜知识图谱的实体库作为基础数据，被用于NLP团队提供的分词和实体识别、意图识别等服务，也在明星图谱等业务场景下直接展示。

3.2.1 分词实体识别

◉ 于和伟在《觉醒年代》里饰演陈独秀

3.2.2 明星图谱展示

◉ 吴京

3.3 标签挖掘与标签体系完善

知识图谱的数据，可以帮助建立和完善标签体系，以及挖掘视频数据上的标签；同时，标签体系也可以反过来丰富知识图谱。

3.3.1 标签挖掘

利用推理等技术，对知识图谱进行挖掘。推理功能一般通过可扩展的规则引擎来完成：

• 属性的推理：如根据出生年月推理出年龄、星座等。
• 关系的推理：如根据已有的『妻子关系』推理出反向『丈夫关系』，根据『儿子的儿子』链式关系推理出『孙子』关系等。

3.3.2 标签体系完善

视频标签体系完善可以采用同样的方法：视频上的标签与图谱实体进行映射之后，应用和上面一样的推理规则（这里主要用到实体的上下位词、属于、包含等关系）来进行标签拓展。其他的拓展方法还包括Graph Embedding等技术（扩展同类型的关联性强的实体）。

下面是一些标签挖掘的线上应用实例：

◉ 广场舞：广场舞实体、舞队实体、舞曲实体、视频实体

◉ 科幻电影：科幻电影实体、类型实体、明星实体、视频实体

四、总结

上文介绍了奇搜知识图谱的构建以及在搜索中应用。

传统的视频搜索，通过为整段视频添加文字标签，并将其与用户搜索的信息进行匹配，来完成搜索过程，其搜索原理与传统文字搜索相同。

基于爱奇艺的核心视频业务，奇搜知识图谱全新的娱乐搜索功能，可以帮助用户找到想要的内容、回答用户的问题、以及理解用户的搜索意图，给用户带来更佳的搜索体验。随着视频内容理解和视频知识图谱库的不断完善，未来用户观看视频将像使用文字一样轻松便捷，对于视频搜索、互动的想象空间也在不断清晰。

五、知识图谱构建与应用代码参考

获取『自然语言处理』行业解决方案

『推荐与计算广告』系列包括爱奇艺、美团、小米、百度等公司的业务分析和技术解读。项目实现代码、项目数据集、论文合辑、文章合辑等，已整理为大厂行业解决方案。前往公众号（AI算法研究所） 后台回复关键字『自然语言处理』获取。

相关代码实现参考

ShowMeAI社区的技术专家小伙伴们也对知识图谱的典型算法做了实现。对『知识图谱构建与落地实践』细节感兴趣的话，请前往我们的GitHub项目（https://github.com/ShowMeAI-Hub） 查看实现代码。感谢ShowMeAI社区参与此项目的所有技术专家小伙伴,也欢迎大家 PR 和 Star！

推荐阅读 | 点击查看『自然语言处理』系列教程（http://www.showmeai.tech/tutorials/knowledge-graph）

• 大厂技术实现 | 爱奇艺文娱知识图谱的构建与应用实践

---

作者：韩信子@ShowMeAI，奇异果@爱奇艺
地址：http://www.showmeai.tech/article-detail/iqiyi-knowledge-graph
声明：版权所有，转载请联系平台与作者并注明出处

![showmeai]