知识图谱的应用(一)-搜索与推荐

之前从产品经理角度写了三篇有关知识图谱的基础知识，这篇文章和以后的文章会更贴近业务层面来写一些知识图谱的商业应用。为什么要把搜索与推荐放一起，是因为这俩兄弟绑定的太深了。

1. 如何理解搜索与推荐

1.1 搜索

从需求角度来分析，可以还原成下面的这一段话，

1.A是一个用户；

2.A想要找一个"thing"；

3.A有"thing"的某些信息，或者知道"thing"的名称等等；

4.A用他个人的知识表达方式描述了"thing"；

5.帮A找出"thing"。

再讲通俗一点，就是帮A通过他的描述找到他最想要的"thing"。

1.2 推荐

从需求角度来分析，可以还原成下面的这一段话，

1.A是一个用户

2.A已经通过他的描述告诉你他想要的"thing"或A曾经告诉过你他想要的"thing"

3.A不知道他还想要其他的哪些"thing"或者A下一步需要哪些"thing"

4.帮A找出"thing"

再讲通俗点，我也不一定知道我喜欢什么，你来猜我想要什么吧，并且在合适的时间与地点出现。

1.3 推荐对比搜索来说有一定区别

推荐不仅要站在用户的角度思考问题，而且还需要站在系统的角度去思考问题

一个好的推荐系统不仅需要满足用户的需求，也要满足内容生产者的需求，还要满足系统自我进化的需求。

通俗的讲就是

1.帮助用户找到他想要的东西

2.帮助更多的内容生产者推送给他的目标用户

3.有一个比较好的反馈机制帮助优化推荐系统

4.尽量避免马太效应，让弱势的内容生产者生产出来的优质内容有机会能够推荐到目标用户那里

2. 现行的搜索系统

图1是笔者归纳的一部分自然语言处理流，笔者需要尽量避免出现原公司的内容，所以在技术层面上的知识会写的比较少。

语言层：主要用于剔除语言中的噪音，杂质，以及时间、数值识别、描述一致性等问题。处理成计算机能识别的语言。

语义层：主要处理自然语言中的语义问题，这一块决定了整个自然语言处理流的描述能力。

执行层：执行语义层的输出结果。

图1 自然语言处理流

以百度为例，搜索贯彻着一个思路。即从海量URL中找到标题和正文经过NLP语言层处理后匹配度最高的一个URL group。可以这么理解，语言层将语言处理成了标准形式，然后使用一个排序算法，得到各种URL的得分，根据得分高低将URL展示给用户。这一过程中，语义层起到的作用甚微，可能就仅仅只在于将语言归一化上（后面在知识图谱应用篇（二）-问答系统中会详细讲解语义层的作用）。

图2 百度搜索结果1

从图2中看出，百度在加装了DNN之后，发现了（车头，前），（如何放置，放在那里）的语义关系，在做的事情还是在更好的搜索url集合。

3. 基于知识图谱的搜索

注：下面所描述的schema构建方案均为笔者自己从外面进行研究然后自己思考得出的结论，如果有该公司的大神们看到并且实际有比较大的出入，请高抬贵手。

上面描述了传统的搜索其实是在搜索url集合，然后通过DNN等深度学习技术发现了不同词汇间的语义关系，通过RNN发现了语言的序列关系。然后通过排序算法（BM25是目前最常用且成功的）将url展现给用户去筛选。请注意，这一整套流程下来，作为搜索引擎的机器是不知道用户到底讲的什么的，因为最后机器得到的参数就是(url,rank值)，所以在互联网内容充足的情况下，这类方法虽然能够解决用户去找"thing"的问题，但是系统的描述能力会比较差。这一点是基于知识图谱的搜索与传统url搜索本质的区别。

3.1 百度的case

图3是百度的人物知识图谱进行搜索的结果，可以明显对比知识图谱和URL搜索的区别，主要就在于"知识"的概念，吴亦凡的身高，本身就是一个“知识”，通过URL搜索能否找出吴亦凡的身高呢？当然是可以的，但是URL搜索本身是没有“知识”的概念，基于知识图谱的搜索，需要的就是将自然语言转换成图查询语言，把知识展现出来即可。所以在“知识”这一块的问答，毫无疑问，知识图谱会比URL搜索精准的多。

图3 百度搜索结果2

来聊聊这个图谱的schema构建吧，这个图谱应该算比较容易构建的schema，只需要导入人物的基本信息，例如：身高，体重，出生年月等等。例如：（吴亦凡（entity），身高（relation），187cm（value））。然后再就是实体间的关系搭建，参考图4，一个比较鬼畜的问答

双向边构建方式：（姚明（entity），夫妻（relation），叶莉（entity））；（姚明（entity），父女（relation），姚沁蕾（entity））；（叶莉（entity），母女（relation），姚沁蕾（entity））。

单项边构建方式：（姚明（entity），妻子（relation），叶莉（entity））；（叶莉（entity），丈夫（relation），姚明（entity））；（姚明（entity），女儿（relation），姚沁蕾（entity））；（姚沁蕾（entity），爸爸（relation），姚明（entity））；（叶莉（entity），女儿（relation），姚沁蕾（entity））；（姚沁蕾（entity），妈妈（relation），叶莉（entity））；

从单项边的角度来说，做搜索查询非常容易，常规的查询几乎不需要做语言处理，例如：姚明的女儿是谁？，只需要识别姚明是一个entity，女儿是一个relation，然后调取（姚明（entity），女儿（relation），姚沁蕾（entity））即可。

 

图4 百度搜索结果3

3.2 神马搜索的case

神马搜索是一款基于移动端的搜索产品，笔者发现神马搜索里面图谱用的比较多，而且比较6，下面会单独抽出几个案例来讲讲神马搜索，因为神马的schema有点复杂了，里面会涉及到一些进阶的内容。

图5是神马搜索中“阿里巴巴”的搜索结果。

页卡：公司概述、组织关系、招聘信息

下方：创始人、联系电话、地址

首先，阿里巴巴是一个entity，上述都是阿里巴巴的relation，页卡部分比较复杂，是属于复合型的属性，常规的构建方法容纳不了这么多信息量。创始人（property）相当于构建了（企业）-{创始人}-（人物）的关系。是关系型属性。联系电话和地址都是值类型的属性。

图5 神马搜索结果1

图6是组织结构内的长截图，里面所有的内容都是可以点击的，并且可以精确找到对应的目标，因为人物有重名现象，如果使用关系型数据库，想要精确找到目标是有一定实现成本的。可以看到，组织结构里面包含了高管、子公司两块内容，如果熟悉三元组构建模式的话，会发现中间构建会有一定问题。图6展示的数据结构是 阿里巴巴-组织关系-高管-马云，阿里巴巴-组织关系-子公司-蚂蚁金服，这已经超出三元组的构建范围了，所以笔者推测神马创造了一种复合类型的构建方案。

首先，基于常识构建知识，构建如下

（阿里巴巴（entity），高管（relation），马云（entity））

（阿里巴巴（entity），子公司（relation），蚂蚁金服（entity））

然后创造一种复合类型的property，叫“组织关系”，组织关系包含了“高管”，“子公司”两种property，用组织结构指代2种property，使用图查询拉出结果。

图6 神马搜索结果2

 

神马搜索的第二个case是关于学校的搜索，搜索学校的时候，用户会关心学校的很多详细且复杂的信息，例如分数线，院校专业，这个时候，常规的url搜索在某种意义上就不能满足用户的需求了。精准搜素，信息关联正是知识图谱的强项。

图7是使用神马搜索关于“北京大学”的搜索结果，可以看到搜索北京大学后，页面展示相当丰富，概览、资讯、分数线、院校专业、校园生活等等。

图7 神马搜索结果3

图8是分数线页卡里面的内容，可以看出，里面的内容相当丰富，录取分数线具有地理位置、文理科划分，还有批次划分，还有年份等等。专业分数线具有地理位置划分，文理科划分，年份划分。总之，信息量相当的大，用常规的三元组构建彻底无法构建，因为三元组无法容纳这么多的信息量，即使容纳了，也相当难查询，如果查询困难，知识图谱就失去了他本身的意义了。

图8 神马搜索结果4

如果仔细观察，你会发现分数线这个类目里面没有entity，也就意味着该页面可能都是value。我们可以做一个假设，这是另一种复合类型的schema构建，构建方案是（阿里巴巴（entity），分数线（relation），table1（？））。让relation直接连接表格，理论上就可以完成图8的效果，不太能理解的话参考图9

图9 分数线复合类型schema的构建

图10是院校专业的内容，这部分有别于分数线的内容，里面的的内容主要集中在专业类别，全国排名，专业名称。看似比上面的分数线简单，实际是应该比上面的分数线schema复杂一些，因为专业名称这一栏全部都是entity，就意味着这个schema必须连到图谱本身，不能像分数线那样外接table去构建了。

图10 神马搜索结果5

笔者认为有2种方案可以构建该图谱schema

第一种是直接用（北京大学（entity）,专业（relation），物理学（entity）），然后在该relation上添加属性：全国排名，专业类别，是否是重点。该方案有一个风险就是把信息存在relation_property里面风险比较大，原因如下，relation_property只能存string，无法存entity了，万一以后需要添加entity了，这个schema会因为这个原因直接挂掉。还有一个风险是relation_property非常不适合查询，如果想用全国排名去查询的话，会有一定的实现成本。

第二种是使用复合构建方案，创建一个复合属性：专业概览，连接一张表格，这张表格里面可以兼容导入图谱的数据。具体参考图11，这种构建方法能够更好的管理维护知识，查询也会比较方便。

图11 专业概览的复合类型schema构建

4. 基于知识图谱的推荐

知识图谱的推荐主要是通过实体与实体之间的关系，将用户搜索实体的相关内容根据一定的逻辑推荐给用户，以北京大学为例，搜索北京大学后，神马搜索会出现“知名校友”，“相关院校”的推荐栏目，通过知识图谱，能够准确的知道哪些人从北京大学毕业的，然后通过一系列的热点排序算法，将用户最关心的毕业生选出来，知名校友这一栏，就可以得出以下结果。

相关院校这一块，可以采用对比学校的property相似度，相似度高的排前面，例如：清华、复旦、浙大、北大都是985院校，其他属性相似度越高。

图12 神马搜索结果6

图谱可以在不同的实体之间构建可以描述性强的关系，产品经理可以根据需求的不同去挑选不同的关系展示。例如用户问企业，可以根据一定逻辑返回相关的企业。