课外天地 李树青学习天地信息检索原理课件 → [转帖]领域应用 | 基于知识图谱的厨房领域问答系统构建


  共有4207人关注过本帖树形打印复制链接

主题:[转帖]领域应用 | 基于知识图谱的厨房领域问答系统构建

帅哥哟,离线,有人找我吗?
admin
  1楼 博客 | 信息 | 搜索 | 邮箱 | 主页 | UC


加好友 发短信 管理员
等级:管理员 帖子:1802 积分:23988 威望:0 精华:24 注册:2003/12/30 16:34:32
[转帖]领域应用 | 基于知识图谱的厨房领域问答系统构建  发帖心情 Post By:2017/5/23 8:48:13 [只看该作者]

Tip:索答科技已经将 50w 菜谱本体信息在 OpenKG 上开放出来,每个菜谱包含菜名,食材,味道,烹饪时间等属性。链接

http://openkg.cn/dataset/summba-recipe

 

 
第一个部分就是我们厨房这个领域的问答,到底我们有哪些问题,或者我们应该怎么去做问答;接下来就是在问答系统当中,我们有很多的方式都可以去解决一个问题,那最后我们选择目前看来比较科学的一种方式,就是知识图谱技术;之后会跟大家分享一下,我们在整个的过程当中踩过的一些坑,就是遇到的一些问题,最后也给大家探讨一下我们遇到的一些困难。
 
1 厨房领域的问答系统
 


首先我们看一下,在我们这个厨房产品当中,我们有四个部分的回答。第一个部分就是菜谱,菜谱我们分成了很多的维度,通过问答系统,你可以知道哪一道菜,比如说红烧肉怎么做等等。第二个部分就是音乐,那在厨房里面这个枯燥的时间,我们可以说:“我想听一个轻松的音乐”等等。视频也是类似的,比如说我想看《人民的名义》第九集等等。最后一块是厨电的控制,那我们的清单是把厨房的厨电部分,做了一个中控系统,就是说我可以打开油烟机,比如说打开灶具,你可以做到这样的一个联动,再比如说我想炒鸡蛋,那可能你的灶具跟你的油烟机,要同时打开来这样的。
 
那么接下来的部分,我们主要是探讨菜谱这一块的内容,就是我们如何用知识图谱这样一种方式,去处理这样的一个菜谱的问答的问题。

 

那菜谱首先是这样的,比如说我们以水煮鱼为例,它不仅仅是水煮鱼怎么做,就这样结束了对吧。它有很多很多的维度,就比如说你这个水煮鱼的食材到底是什么,你是用草鱼制作,还是用鲫鱼制作,然后你这个水煮鱼是什么样的味道?然后它有什么样的功效等等。那我们就把它形成了这样的一张图,那这个图中间的这个点就是我们菜谱的名称,然后后面有各种各样的属性,以及它的属性值,我们大体要做这样的一个原始的,一个最小化的节点就是这样的。


那下面我们有三种不同方式的可以去跟它沟通。第一个就是同意表达,就是说我就说了“水煮鱼的做法”就这样的一句话,那这个时候可能我们的用户在使用的时候,是各种各样的问法,因为你不清楚大家,你要怎么去问他。这个里面随便列了一些,就比如说我针对厨房的一款产品,就跟他说水煮鱼,那你说它应该要出来一个什么样的结果,因为它这是有一个场景的限定的。另外比如说我想知道水煮鱼的菜谱,或者是查一下水煮鱼的做法,我应该怎么做水煮鱼等等。那么只要是大家问到这样的类似的,或者是同意的一种表达,那我们应该出来的结果都是同一个,就是我要教你做这个水煮鱼,怎么去做它,然后在同一个问题当中,我们现在是统计了一下,目前的语料当中显示,我们现在有超过40种的方法,都是同一个问题是这样的,我们要解决这样的一个问题。

 

第二个就是多个维度的问题。我们刚才说的这个话题,一个水煮鱼我们怎么去问它,下面就是说在这个水煮鱼,我们从第一幅图看来,它有很多很多周边的一些维度,那么比如说就像食材,那食材我可以说洋葱能做什么菜,我也可以刚才说的那个草鱼能做什么菜,可能水煮鱼只是它的一个部分是这样的,然后还有功效,比如说减肥要吃什么菜对吧,尤其是现在健康饮食也是得到大家越来越关注的一个点。比如说一个肚子比较大的人,可能问他的时候,就问减肥要吃什么菜,还有菜系,比如说粤菜、川菜等等。另外还有一种组合的问法,比如说我现在冰箱里只有土豆和牛肉,那它能做什么菜,或者是能做什么不辣的菜,这样的一些非常复杂的一些问法,然后我们目前的这个维度一共有8个,如果把这8个维度,跟我们的食材本身,让它们交叉,相互的这样去组合的话,其实它的问法是无穷无尽的,你不清楚别人到底要怎么去问,所以这样的一个问题,你是没办法罗列,或者是用规则的方式去处理这样一个问题。

 

另外一个就是页面上的一些指令。这些指令跟我们本身的页面是有关系的,右下角的这张图,就是说宫保鸡丁怎么做,怎么做之后我们就会出来一个页面,这个页面上面有三个信息,一个就是有它的视频,右边是它的食材,再下面是它的步骤。那在这个页面的时候,我可能就不会再说我想看一下宫保鸡丁的视频,那在这个页面,我可能就会跟他说看一下视频,那这个就需要这样一个看信息,那在这个页面说看一下视频,那特指就是宫保鸡丁的视频,步骤也是一样的,然后除此之外,可能到步骤页面之后,我只会跟他说下一步,我不会说第三步或者是第四步等等。所以这一个菜谱,领域范围里面所有的这样的,我们说到三个部分的一些问法。


 

那么整个的厨房领域里面,我们处理流程是这样的,首先我们的这个产品,是用语音去跟它交互的,所以第一个部分我们要进行语音的识别。语音识别它不是一直都是监听的过程,就是说首先这个就像跟人说话这样的一个交流过程是一样的,那我可能首先打个招呼,然后再去跟你说话,那这个部分我们叫做语音唤醒。然后唤醒之后,我们就可以用语音去跟它说话,说完之后,它要把这个语音变换成文字。那这个环节叫语音听写,变成了文字之后,这个文字其实有很多的,也是有错误的信息的,那么前面这个部分,目前国内应该是科大讯飞做的是最好的,另外还有思必驰都会做这一块。那目前前面这个部分,我们也是调上科大讯飞的接口,那么调完了之后,我们就得到了文本。

那这个文本我们会发现,里面有很多很多不是我们想要的,举个例子说,就像鱼香肉丝怎么做?那最后我们调到检索之后,出来的文本是“雨”香肉丝,那么这个时候你再到实体里面去做匹配的时候,就会出错。所以我首先在做语义分析之前,第一步要进行文本的纠错,那文本纠错我们这个里面,主要用到两种方式,一种方式就是一个概率模型,就在我们的语料库里面,然后我们做了一个字跟词之间,序列这样的一个概率模型,那么一句话来了之后,我就会看,这个词它出现下一个词的概率是多高,然后对它进行纠错。另外还有一些本身实体,本身的名称,我们就到实体铺里面,去给它进行纠错是这样的。那么纠完错之后,下一步我们是进行垃圾过滤,因为我们这个里面一共有四类,其实我们分类的结果,应该是五个类别,就是4+1,那这个里面的垃圾来自于我们是不是在跟机器说话,或者说我问的是不是跟它相关的问题,或者我是不是在跟别人说话,以及我们这个里面,还有一些什么其他的,就是跟它无关的这样一些垃圾,要把它过滤掉。那么过滤的这个准则,主要还是用检索这样的一种方式,就是我们有问题相关的实体库,然后你来这一句话,我会跟它进行比较是这样。第三步我们进行文本分类,这些地方的主要工作,是分本分类的技术,我们已跨过了两个台阶。首先我们做了一些问句的模板,就比如说什么怎么做,或者是什么菜怎么吃,我们把所有的跟菜谱相关的动词都拿下来了,应该是 231 个,然后再根据它的上下文,去做这样的一个事情。那么第二个步骤,我们现在应该全部把它放到 Deep Learning 里面去用 CNN 去训练。因为我们目前它的分类的文本的 training set 已经足够大了,也就是说我所有的正文本的标注是足够的.那这样的话,任何一句话来了之后,我们在每一个里面做了一个二分类这样的一个问题,现在基本上全部转换成 Deep Learning 这样一种方式。文本分类之后,我们就知道它是哪一个类别的,那这个时候我就把它里面的实体以及属性把它抽取出来,就比如说红烧肉怎么做,那我就把红烧肉拿出来,以及“做”这样的一个动词拿出来,那我就知道它们的组合方式,接下来我就会生成这个逻辑表达式,逻辑表达式我们现在生成的就是“与或非”之间的关系,比如说就像土豆、豆角它们两者其实是连着的关系,比如辣不辣是“非”的关系。然后最后我们要到知识图谱中查找的时候,我们会生成这个SPARQL查询语句,这个语句还是 Apache Jena 里面开源出来这样的一种方式,后面我们也会提到。

做好了语义分析的这一步之后,我们就可以得到我们想要的答案了,那这个答案我们是分在三个地方的,一个就是数据库,比如说我们有一些图片的 ID,或者是实体的 ID,这些就在数据库里面根据 ID 把它拿出来。另外一个部分,有一些实体,我们是放在 Elasticsearch 里面的,这样的话我们从里面检索出来就好了。但我们有一些语义跟实体之间的推理关系的时候,那我们就把它放在知识图谱里,然后从知识图谱里面出答案。在这个的这个流程当中,是我们目前的一个基本的流程。

 

之前的话,我们也曾经尝试用 Elasticsearch 去做过这样一件事情。那也就是说 ES 其实它只是个检索的功能,就是在 Lucene 存储的基础之上然后做的一个分布式的一个框架。那在这个里面,它主要是基于关键字这样的一个搜索方式来做的,是否包含着这个关键字。但是知识图谱,它会有关键词的上下位这样的一层关系,就是说它具有推理的功能。那下面举个例子,比如我们说萝卜能做什么菜,会发现有胡萝卜什么炒肉,或者是白萝卜什么炖汤,那这样的就找不出来了。就是说在一个仅仅是从词匹配的角度上来说,那只能做到这一步,那这个时候如果我们有上下位的关系,那我知道这个萝卜下面它是包含着红萝卜或者是白萝卜,并且它们都是食材的这样一个分类。大家如果是一直跟着 CCKS 这样的一个规律,就会发现这个图其实跟 CCKS 第二届的时候,漆桂林教授讲的一个知识图谱分类的那一张特别像,当时写的是疾病的那样的一张图,其实我们把它运用到这样的一个食材当中来了。那这个就是我们目前所做的这一个领域问答里面的相关问题。
 
2 知识图谱技术的运用

 

 

下一个话题我们来说一说我们的知识图谱,在我们刚刚说的这样的一些问题当中,是怎么得到解答的。首先我们看一看,目前这样的一个整体框架。

2.1 整体框架

2.1.1 数据存储
我们从下往上看,首先数据我们要把它存在什么地方。我们要把它的基础数据,目前是用这样的一个分布式框架,那么基础数据,我们会放在 Hbase 里面,就比如说我们菜谱的图片数据,那这样的数据它是很大的一个数据集,那就会放在 Hbase 里面。然后我们需要处理的一些数据,一些原始数据,我们也会放在 Hbase 里面,然后我们通过 MapReduce 的程序去得到我们想要的一个结果,我们想要这个结果的时候,我们就会把它同步到Mongodb里面去。因为 Hbase 跟 Mongodb 它们各有优势,Hbase 写入的速度,如果跟 Mongodb 比起来的,它要快了更多,但是它读取的速度,是不如 Mongodb。那也就是说我最后呈现的数据,要从 Mongodb 里面呈现出来,那么 Hbase 主要是做基础数据的存储是这样的。然后还有一些关系性特别强的数据,我们会放在 Mysql 里面,但是这一块基本上已经非常弱化了。

那么第二个部分就是图数据,那么图的数据,就是我们刚才讲的那个三元组的这样一种方式,那么三元组它会一个实体、个数跟三元组,三元组的个数会是实体个数的好多倍这样的一种关系。因为它们之间要不同的组合,那这个时候,我们采用的是网络本体语言就是 OWL 这样的一种表示方式,但是这个除此之外,前面应该还有 RDF 这样一种方式,其实我们是直接伴随了 RDF,因为现在有参考了很多的论文之后,OW L其实是比 RDF 更先进的一种方式,那我们才开始采用的是这样一种方式。

然后对于大量的数据存储,那我们就必须要找一个持久化的工具,因为 OWL 它是一个文件格式的一种方式,Neo4j 我们做了,但是最后我们线上的系统并没有采用它,原因是什么呢?因为 Neo4j 首先它是个收费的,它那个节点的个数是有限定的。那我们现在采用的是 TDB 的方式,TDB 也是 Apache 基金会里面出来的 TDB,后来我们也会讲它。

另外我们有一些索引的数据,比如说我们有小的指令级的,就像我们刚刚说的上一页、下一页、翻页、换页这样的生成并不多,并且它匹配的准确率又非常高,就是它在一模一样的情况下,我才会让它去做,这个地方,可能就不需要做泛化,所以我就会把它放到 Trie 树里面去。然后有一些实体会放到 Elasticsearch 里面去查询,还有一些小的数据集也要索引,那我就会放到 Lucene 里面,然后之后的缓存数据,还是用的 Redis 这样的一个分布式的缓存处理。

2.1.2 数据采集

那么下面一层就是数据采集,那么我们要想达到这样的一些数据把它存储起来,所以我们要采集 8 万个数据。首先我们做菜厨,所以一些垂直网站,就比如说掌厨,下厨房,还有豆果网一些数据,另外我们人工编辑了很多的数据,比如说问句。因为这个问句人工也是不可能一步把它收集完了,但这个里面我们也有一个算法去做这种大量的问句,我们说了刚才的问句,同一个问题的问句是非常非常多的,那这个时候往往大致过程是这样的,首先把这个问句进行分析,首先找种子问句,种子问句拿到了之后,我们会对它进行分词,然后把每一个词到 word2vec 里面去训练,就是找它相关的词出来,相关的词把它们的位置序列记好,然后做笛卡尔积。这样的做完了,我就会生成大规模这样问句的数据,当然里面有一些是不正确的句子,那这个时候我们也会用我们文本纠错的马尔可夫链的方式,做它的概率模型去纠正它,那这样的话,我会生成大量的这样一些问句,然后人工也会筛选一些是这样的。其实我们也申请了一个专利,就是我们怎么进行问句生成的。然后动词的收集,就是跟领域相关的这些动词,我们觉得它是有穷尽的,就是它是能够拿的到,虽然我们的问句是无穷无尽的,那我们收集了200多个跟菜谱相关的动词,以及同义词的收集。比如说番茄炒蛋怎么做你能够出来,然后西红柿炒鸡蛋你就出不来了,这样是不对的,所以我们这个里面也做了大量的同义词的专门的训练。

之后还有一些开放的知识库,比如说同义词词林出来的,刚才漆教授给大家分析的这个 OpenKG,OpenKG 其实有很多的这种开放的数据源,而且是免费的。我们接下来在做音乐的领域的时候,清华大学就在 OpenKG 里面贡献了音乐的数据,全部是三元组的方式,也希望大家能够去打开 OpenKG,去看一下里面有很多免费的数据源是非常不错的,然后还有 WordNet 一个开放的数据。另外我还抓了很多的百科数据是这样。

2.1.3 知识库构建

之后我们在知识库构建的时候,首先就是分成两个步骤去做它,一个就是我们知识的融合。首先我们要做时序融合,就是你之前做的实体,它的实体链接是不是根据时间的推理,而它换掉了它本身的这样一个含义,进而做本体的扩充。还有一个就是多源融合,我们会看到我们的菜谱,不止来自于一家网站,这样就会形成同一道菜,但是它的菜名不同,那我们要做这样的一个多源的融合,把它做一个实体的匹配和概念的对齐。做后了之后,我们就要做知识计算,就是把这一些知识融合起来之后,我们哪一些是它的属性,哪一些是它的实体,以及它们两者之间的关系到底是什么?

2.1.4 数据访问

之后我们到数据的访问,我们用 SPARQL 的访问,还有自然语言查询。自然语言查询就是说红烧肉怎么做,那我就给你出来结果,你也可以自己能够写到SPARQL的时候,那我的系统也是支持你能够出结果的,但是我们还有SDK的方式,放在你的系统里面可以用。当然我现在也把逻辑表达式的那个查询放出来了,如果你用过逻辑表达式,我也会自己把它转化成SPARQL语句然后给你出结果是这样的。

2.1.5 知识运用

那在运用这一层,我们主要是把它运用在语义搜索,目前我们可能是在厨房领域这样的一个知识问答当中。

 


下面我们就把前面那一幅图抽象成这样的一个图谱,然后它旁边有很多很多的属性,之后我们一共抽出来 19 个菜谱的属性,那这个里面所有的跟它相关的东西,我们都可以,应该能问的出来,比如说就像人群,还有功效、菜系等等。

2.2 知识图谱的构建

 

接下来我们说一说知识图谱的整个构建过程,就是我们刚刚看到了,我们整个的一个图,抽象出来是这个样子的,那我们怎么把它构建出来呢?首先我们应该有菜谱的本体的模板,那这个模板里面,我会定义好,我有哪一些菜,有哪一些属性是这样的,然后下面我们有一个菜谱的数据集,那这个数据集我们是放在 Mongodb 里面,就是我们已有这样的一个数据把它放好。之后把这两者结合,我们就成了一个本体语言这样的实例数据,再加上我们本体语言的一个头文件,之后我们就变成了菜谱的OWL文件。那这个文件到底展开什么样子的,我们下面看一下,这四个部分到底展开什么样子?

 

我们菜谱本体的模板就是我们自己去定义的,其实这个里面哪一些是食材名称,还是菜系还是什么等等。第二个就是我们菜谱的数据集了,就是把所有的东西放进去,第三个部分就是它的实例数据,比如说水煮鱼是你定义的是菜谱的名称,然后下面我们把菜谱的数据集放到这个里面去,然后加上 OWL 的头文件,这个头文件是有模板的,其实这样是写的,那唯一不同的地方,就是我们一个 reboot 下面是不一样。有了这几步之后,我们把它放在哪里?就放在这个 TDB 当中,这个 TDB 当中,整个的流程是这样的。

 

从本体的构建,那这个本体是我们本身有的这样的一个菜谱数据的本身,然后我有两条线。我们首先不看那个黄色的,看下面的这样的一个部分,通常的做法是这样的,我们把它放到这个本体文件当中,我们刚刚看到 OWL 到底是什么东西,其实你可以放到 RDF 里面这个没所谓的,之后我们会有一个 URI 的一个映射文件,ttl这样的一种映射方式,然后来同时解析,然后在 TDB 里面,我们会根据 Jena 的 TDB 写一个 TDB 的增删改查,通常的这样一条线,这样它就能走完。

另外我们公司就想做一个红色的一条线,中间我是不是可以不生成一个 OWL 文件,我只要把我的文件,原始数据能够放到 TDB 里面这种格式就好了,因为它支撑这种查询就好了。这一部分研究我们应该也就结束了,就是我们可以直接把一个数据库里面的菜谱文件,然后直接把它放到 Jena TDB 这样的一个存储系统当中,然后这样的话,我们文件把它放上去了,然后我们怎么把它查出来呢?查的时候也有两种方式,一种方式根据我们自己的 CRUD 读出来,读到我们的数据集段中,然后通过 URI 把它映射成我们的一个本体模型,这样通过 SPARQL 就可以把它读出来。

另外 Apache 还提供了一个 Fuseki 的 SPARQL 服务器,我们直接 Load 进来,Load 进来之后我们通过 HTTP 往外读是这样的。但下面是一个推理规则的时候,我们也是这样,我们要有 rules 文件跟推理器,那整个的流程就是这样去做的。

 

2.3 搜索流程

后面我们看一下搜索的流程,那么整个搜索,我们有一个语义逻辑的表达式,我们把它放进来了,举了个例子就是马铃薯能做什么不辣的菜?那我们现在就可以把它搜索出来,怎么搜索?第一步这个语义分析结束之后,我就知道这个马铃薯它是一个实体,并且我要找的不辣的。那么下面我们就开始分析,马铃薯是 MUST,就是它一定要也,这个辣就是 MUST NOT,就是一定没有这样的一层关系。再下来我就要做同义表达,同义处理,就马铃薯它也是土豆,所有土豆也是 MUST。之后我在做这种实体属性,它们的映射关系,然后来生成这个 SPARQL 语句。跟我们的数据库查询有一点像,但是也不完全一样的这样的一种方式。那最后我们查询的结果是菜谱里面的ID值是这样的,那有了ID值的话,我就可以从数据库,通过ID的方式把它拿出来,这样的话就会非常快。
下面我们举几个例子来说一说我们语义搜索的一些结果,现在针对于这种单属性值这样的一种表现方式,我们是怎么去做的呢?你比如说土豆和豆角可以做什么菜?这两者之间是“和”的关系,就是它们两个都要有,就是土豆跟豆角,那这样的话,我们查询出它的结果就会是这个样子。

2.4 语义搜索

 

下面我们继续看一个比较复杂的一个查询,土豆“和”西红柿“或者”豆角可以做什么不辣的菜谱,这个首先我们是从属性基础角度上面去分析这一句话,就是说这个里面土豆,这个里面可以加豆角也可以不加,西红柿可以加豆角也可以不加,是这样的一种方式,是这样的一种或。然后最后它们出的菜,都应该是不辣的一个菜,所以我出来的结果是比如说西红柿炒土豆片,就是它们两个有吗,西红柿土豆炖牛肉是这样的。然后后面就是土豆跟豆角,它们两者之间的出现,因为它们是或,不是限定的,那这样的它们就出来了,那这个语句其实还是比较复杂的一个语言现象的处理方式。

2.5 查询性能

 

后面我们看一下,我们知识图谱的一个性能问题。其实我们搭建知识图谱本身的时候,就刚刚开始用OWL这样的一种方式把它放起来,然后发现这个文件越来越大,然后它的效率会越来越低是这样的。但后来的话我们采用了TDB的方式去处理了这个事情,这边是我们的一个测试,那么我们每一个测试是100次,然后各个属性,这个属性有一点小,比如说第一个是土豆,或者是土豆怎么烧,然后不辣等等,基本上我们所有的查询,都应该是在50毫秒之内能够完成它的结果。然后有一个特别的不正常,就是那个不辣,比如说我想做一个土豆不辣的菜,然后我们会发现这个查询,它的耗时超过了150,就是跨了好几倍这样的一种方式,那么这个原因是什么?就是说我们上面的标签没有不辣,我们要么就是甜,要么就是酸,要么就是辣,你如果要查它不辣怎么去做呢?那我就要查这个属性它是甜的,等于要把所有其他的属性都查了一遍,所以这个时候它就特别慢,那我们现在后来的这种处理方式是怎么去处理它呢?就是离线去处理,我们整个库当中的数据,比如说它是甜的,那它一定不是辣的,不是这样的,那这样的话这一个查询的结果,它的信息就会同步提高。
 
3 曾经踩过的一些坑
   
后面一个部分我们看一下,我们在这个过程当中遇到的一些问题,以及我们的解决方法。

 

首先就是相关性查询的问题,那么我们会遇到的第一个问题,比如说土豆可以做什么菜,然后我们就出现了一个结果叫紫苏炒三丁。因为我们的这个结果是从哪里找的,我们是从食材里面去找的,只要这道菜当中,包含着这个食材当中有土豆,那我们就会把它拿出来,那么就会发现它本身的这个菜的名称当中不包含,就查出来好像是错一样,就这种体验非常不好。后来我们就是处理它,怎么处理呢?我们首先离线去处理所有菜谱的名称,把菜谱名称当中含有食材的部分,单独拿一个列表,列出来,把这个字放进去,然后我们再查询的时候,就首先到这个里面去查,是不是跟它有相同的,然后再出这样一个结果,如果没有的话,那你只能从食材当中去查,然后我查完了之后跟百度比了一下,就是跟到百度的属性去找的时候,我们会发现有很多我们出来的结果跟它是重复的。

 

第二个就是知识图谱的同步的问题。我们生成了这样中间的 OWL 文件,我们的实体库每天都在不断地更新,不断地更新,那你线上的 OWL 文件,因为你是从数据库里读出来,读成这个三元组的这种方式,那么我们怎么才能够把我们最新的,最实时的做好的这个数据,能够在我们线下系统去使用?后来我们生成了两份文件,就是 OWL1—ready,还有一个是 OWL2 是这样的,然后每次来读取的时候,我就搁一个小时一次,去看一看这个文件夹里面,到底谁是 Ready,就把它读走,然后读走了之后,这一份就把它删掉是这样的。然后它在更新的时候,更新完了之后,它会变成 Ready,这样两份的交替使用,那线上它就会做这样一个无缝的切换。

 

知识图谱里面的搜索是有一个问题的,就像我们经常用 ElasticSearch 的人就会发现,检索里面的排序其实是非常容易去做的,本身底层就写了一个排序打分的 TF-IDF,这样的一个模型。然后你会发现你用知识图谱的时候,你非常不习惯,因为它附近的这些节点的权重都是一样的。比如说我们土豆能做什么菜,那你所有出来的这些菜的话,在我们知识图谱里面,映射的本身其实它是扁平的,就是这个土豆它是一个节点,能够到哪一些菜谱上面,都可能拿出来。那这个时候你就会发现,如果是在产品当中的使用,你就会发现你所列出来的那些菜大家都不认识,我都没有见过,这个体验也是很不好的。后来我们又在知识图谱的这个属性当中,去加了一个热度的一个值,这个热度到底是多大,这个热度我们主要是通过点击次数去计算,就是哪一道菜,就是把它们查出来之后,它们哪一道菜的点击量会更大,它们更热,然后就会把它调制的参数把它往前排是这样的。

 

最后一个看一下三元组的一个存储问题,刚才也提到了,就是我们实际在使用,全部用 OWL 这样的一种方式存储的话,那这个文件会越来越大,越来越大。其实它的查询是以加载到内存当中的这样一种方式,那这种太大的时候,就会非常影响你的速度,并且你的整个机器都会被拖垮。如果你是分析实验的话,你可以这样去做,但真正的你的这个数据量开始越来越大,那现在我们的菜谱的节点,已经超过了 80 多万,所以三元组的个数会更大,这样的一种方式。然后我们采用的就是 TDB 的这样的存储方式,刚刚也说过了。下面是 TDB 的一个页面,左边这一幅图是 TDB 存储完了之后,它里面的目录文件,右边是它提供的一个页面,我们可以看的到,用 STDB 的方式我们直接可以读到它。
 
4 遇到的一些挑战与困难
 


最后说一下我们遇到的一些问题,跟大家探讨一下。我们现在是在做菜谱的整个的这样一个方式,那在这个里面,我们还是花了很多的时间,花了很多的人力去做这样一件事情。然后我们刚刚 PPT 的开头,跟大家说到我们做厨房领域,是有四个方面的这样一个问答,接下来我们一个月视频怎么办,那我们同样也要用这样的一种方式去做,我们在菜谱里面下了更多的工夫,我们做了这么多的实体,三元组它的查询方式,那我们现在做音乐,我们怎么能够把它移植过去?就是我们一个跨领域的问题,那你会发现,音乐的时候其实它的那个属性是不一样的,它比如说有劲爆的,有小清新的等等,你在做这个,除了那个基础工作是一样的,就是这一套理论,这一套分布式,或者查询这样的一种方式是相同的,但是这种属性和属性值,好像我们要重新来过一次。
   
第二个问题,我们看到我们语义理解过程当中,其实我们主要还是在做文本的分类,说明分完类之后,我们去做它的属性抽取,然后生成一个逻辑表达式,我们就知道这一句话到底在说什么,或者说它想查询什么,其实在干这样的一件事情。其实知识图谱的运用,还没有把它运用到自然语言理解这样的一个事情当中来。我们用多少数据的一个知识图谱的时候,我们就不需要再做这样的一个事情,那我们讲的一句话,就把它直接应用到我的知识图谱的应用里面去,如果它在我的每个节点上面都有体现,并且这个节点之间是有关系,那我就知道你就在说什么,我就不需要再做前面大量的这些工作,包括这种分类,是不是也就不需要了。因为我都知道你在说什么了,那我一定知道你的类别是什么,但是这一块可能要慢慢去积累,去做这样的一件事情。总之目前这样的一种方式,应该是还不能够达到语义理解的这样一个层面。

后面一个话题是这样的,比如是我们现在做的一些事情,其实我们用了大量的数据量,去训练一个模型。其实这个模型怎么形成的,就是一个规律。在这个过程当中,其实表达的意思是这样,就像我们用一个二元一次方程,如果我们用深度学习的方式怎么去解二元一次方程,那我本身这样的一个表达式,可能就是 ax^2 + bx + c = 0,这样的一个式子,最后我解出 x_1 跟 x_2 等于多少就行了.如果我们用这方面的方式去做,我会怎么做?我会把 a,比如说从 1 到多大的一个数据集,去取这样一个数据,并且 b 也是这样去取,c 也是这样去取。取完了之后如果我标注,比如说 x^2+x+1 = 0,那 x 等于多少,这样去标注,然后我标注的数据越大,我的方法就会越强,我就一定能够把 x 就解出来。那这样的话,我们用了这么大量的数据,其实我们解决的一个问题是什么?我们其实就是找了求根公式是不是就可以了。如果知道这样的一个公式就可以了,所以我们大量的工作需要放在,找这种大量的数据集,并且去做标注,还是我们应该去找的求根公式,当然这个找大量的数据集,肯定是找求根公式的一种方法,这个是毋庸置疑的,但是我们是不是还有一种方式,直接有另外的一种方式,能够找到这样的求根公式,能够去处理我们这样的一个问题。那这个就是我们也在尝试着去做一些事情,尤其是这个部分,我们想去做一些中文汉字和词,它们本身这样的一层关系,就比如说我们的汉字常见的有 3000 多个,你把那个大的词典拿出来,可能是 7000 多个,然后我们的汉语当中所有的词,大词典当中的词,现在收录的是 58000 多个,这样的加起来的话应该不到 7 万。那如果把它们之间的关系,以及它们之间的含义内容表示清楚,用某种方式表示清楚,那我们是不是就可以能够映射本身的一个图谱,或者是帮助我们的语义理解,那这个也是我们研究的一个话题。
 
5 总结

 

最后总结一下,首先我们觉得这个问答系统,一定是未来的一个发展趋势,并且它在处理这样的具体的领域问题的时候,我觉得它还是能够带来一些实际的价值。因为未来这样的一个,我们所有使用的这样一个工具,它是有很多的历史变迁,就比如说我们以前用电脑的时候,用鼠标用键盘这样的输入方式,后来我们再用手机的时候,跟你的键盘、鼠标的输入方式已经完全不同了对不对,你不可能拿着手机在手里,拿着一个鼠标去点它,或者是键盘去敲它,你都是手去触碰它。然后未来的这种发展,它应该是两极分化的一种方式,要么就是没有屏幕,就比如说一些音响的出现,它是没有屏幕的,那么你怎么去跟它交流,你不可能用鼠标,手滑这种趋势是不可能的,你一定是用语音的方式去跟它交互。

另外一种就是屏幕会越来越大,比如说这个屏幕大到这个样子的,或者说整面墙都是这样子的,那你可能去鼠标或者手滑,你一定是语音这样的一种方式,那我们觉得语音的问答这样的一种方式,是未来的一个趋势。第二个在问答系统当中,知识图谱在目前看应该还是比较科学的一种方法。第三个其实知识图谱的它的使用价值,应该是很多很多的,但是终将能够把它转换成运用的,这个你们应该还有很多很多的挑战,那我们觉得也是一个值得深入和广泛研究的一个领域,也希望大家能够更多的研究和探讨,谢谢大家。

- end -


 


 回到顶部