博文

【新智元沙龙笔记：谈不完的知识图谱】

已有 4613 次阅读 2015-12-1 09:14 |个人分类:立委科普|系统分类:科研笔记| 知识图谱, 抽取

我: 一觉醒来，才看到这个新组，白老师招呼，里面很多认识的或久闻大名的老师，先给各位拜个山头。

下面就是担待了，如果胡喷离谱的话。因为关于知识图谱，还是有话要说。

白: 伟哥，期待你的专场

我: 首先，知识图谱与60年代的语义网络没啥直接联系。

昊: 板凳坐好等听专场

我: 它就是来源于 20 几年前 MUC （Message Understanding Conferences）开创的信息抽取 IE，痕迹很明显，是水到渠成的传承。IE 与知识图谱没有两样，是一回事儿。不过是谷歌吸取了IE研究成果，工业上 scale up，然后换了个名字，搞得天下趋之若鹜。概念上没有两样，方法上也应该是相通，细节不论。这是其一。

其二，知识图谱与各种 ontology 不同，根本不同在于知识图谱是 data-driven，不管这个 data 是 text，speech 还是其他 meta data，也可以说知识图谱是大数据的语义计算，着重于建立 entity 之间的关系，用的就是 IE 中预先定义填坑的 templates。

ontology 不同，ontology 是语义知识的表达，反映的是固定的长远的本质的语义联系，包括专业知识和常识都可以。但不包括大数据挖掘的动态关系和事件。换句话说，一方是人类积累的静态知识，一方是动态的信息，带有新闻的性质。ontology 可以用来支持 IE 和知识图谱。template 是各家的设计，是根据各自需要预先定义的语义目标，而不是人类的知识积累。这个很重要，因为在 pre-IE 时代，NLP 和 NLU 已经进行了多年，成效不大，原因就是以前的NLU没有预先定义 templates，所以是一种漫无目的的理解。结果就是 NLU 不能走出实验室，不能以大数据为依托去应用。DARPA 支持和启动的MUC 改变了这一切，在 NLP 历史上，这是一个怎么夸赞都不过分的 program。因为除了机器翻译，它定义了又一个从实际需要出发的NLP领域，一个可以广泛应用，开花结果的方向。

白: 这里有一个又是细节又涉及方法论的问题：究竟（大）数据直接驱动的是templete本身，还是它的坑，抑或兼而有之？比如说“西瓜三块钱一斤”直接驱动的是“价格”这个坑，还是“商品”这个通用模版？这个问题要反过来说，系统的规模还是一样的规模，用于理解，就是玩具；用于IE，就成了香饽饽。

昊: 对于其一，我觉得是受了启发，但也参考了其他分支包括bottom up的知识表示还有Graph建模本身的优势和愈发成熟的数据管理。

对于其二，和ontology的对比大致没有问题，但就目前图谱的发展，其实纯粹开放域IE质量并不好，所以还是Ontology based，所以两者其实结合；更何况现在基本上很多知识还是静态的或基于如schema.org的。@wei 您这里提到第一次Scale up，我们都更希望Scale out，您觉得如何做到。另一个问题是，现在Ontology的概念也不局限原有的，如Palantir推出的Dynamic ontology，用来适应特定领域的变化等。

我: @白老师说，究竟是开放的general domain 还是 domain specific 对于 IE 或知识图谱更有利？

IE 的历史就是从 domain 开始的。MUC 最初定义的 IE 是非常狭窄的 domain 中的事件。这样才可以把注意力集中到NL的一个子集。而且 domain 里的 ontology 才好派上用场，作为支持。

关于这个 domain 的事儿，可以对比一下 Framenet 和 IE 里面的 templates。Framenet 是NLU里面的general domain 的语义研究的自然延伸，它是从当初的深层格（deep case）框架自然发展而来，开始走到语用层，但又舍不得原来的语义的架构，于是一直在语义到语用之间尴尬着。而 IE 的 templates 则不管语义的框架，就是根据 domain 和语用的需求，临时定义，是典型的实用主义主导。不管什么人，不管哪个产品经理，都可以根据需要来定义。它不要求完备，也不需要在一个统一的框架里。Framenet 里面的框架本身是有 hierarchy 的，而 IE 则缺乏。从长远来看，Framenet 不断细化，IE 不断的从一个个 domains 里面升华，二者会在中间相遇，理论上是这样。但在可预见的将来，Framenet 没有大的起色和前景，而 IE 或知识图谱会遍地开花。前者是研究性质，后者是解决问题（信息需求的问题）。

昊: 还有一个是：如何看待大家现在做的事件图谱，如刘挺老师在做的@刘挺

我: 至于事件，这个也有很多话说。知识图谱是连接entity的，所以一开始事件不是重要的抽取目标，而关系才是核心。实体关系和事件是怎样定义和区分的呢？在 IE 领域，有一个基本的共识：关系是一种相对稳定的关联，而事件是瞬间的发生，大体如此。譬如，雇主与雇员的雇佣是一种关系，而招员则是事件。这样一来，为了把实体连成图谱，最重要的是先把关系找出来，这样这个图谱就转起来了。这就是 entity profile 这个知识图谱中的核心概念的本质，每个profile 都与其他的 profile 处于链接，而链接的主体是关系。事件当然也牵涉entity 之间的关联，但是事件是随机的、动态的、多样的，相对较难把握和掌控，所以应该作为知识图谱的第二步目标。

白: 我刚才关于坑和模版的问题，倒无关论域的宽窄，只是说若干个模版可能共享一个坑，即使论域再窄，也是有可能的。比如某文章先说“尸体”，再说“子弹”，最后说“闹市区”。前两个词既可以提示“恐怖活动”也可以提示“战争”只有第三个“闹市区”才拉大了恐怖活动的概率。只要两个模版预制在同一个系统中，这个就是要解决的问题。中间环节“死者”“作案工具”的作用……

我: 另一点是，关系的自然支点是实体，object-oriented，事件的本质是 action-oriented，知识图谱目前还是 object-oriented 的语义表达、展示和应用的方式。所以关系是核心。

白老师说的是当几个语义模板在同一个系统中的时候，如何协调。Framenet 是针对从 argument structure （10个左右的槽）做起始点，不断语用化，如今定义了的几百上千的自上而下（而不是数据driven 的自下而上）的模板，试图建立其中的 hierarchy，找出共性和可以share的部分。IE 到目前为止，在实际应用中，多个模板并存的情况大体是非常有限的几个，一般就是内部协调。还没什么章法，也没多大的迫切性。

昊: 事件是触发器来更新图谱中的关系或其中关系的状态

白: 现在问题是，跨出IE，知识图谱还能走多远？比如客服，比如教育？

昊: 客服现在其实大家尝试的很多

我: 知识图谱就是一个力气活。有了大数据，只要产品经理是称职的，就可以定义很多 templates 作为不同产品的目标，然后就是不断处理更新数据，提供信息服务，包括客服、搜索等

白: 我一本期权教材，用来培训，一共多少知识点，特定学员知识点掌握如何，这绝不是窄领域，可能与多个模版纠缠的情况是家常便饭。难道不做了？

我: 但是每一个实际产品和用场，所需要的 templates 是相当有限的。@白老师有点多虑了，因为实际情况是，产品经理定义方向，app 在应用中实现这个，里面所花费的精力和时间，比做出这个知识图谱要长。几个 tenmplates 纠缠在一个产品的情况是高级阶段的问题，现在还提不到日程上来。定义一个 template，找到合适的产品适用对象和范围，在 app 中以用户友好的方式展示出来，这个是瓶颈。而 IE 的开发这个本来认为是瓶颈的过程在 NLP 平台搭建以后却不是瓶颈。

白: 这样搞不了教育的

我: 这个体会太深了。有很多非常好的主意，结果产品化过程中就是找不到那个合适的点来满足用户。本来想骂产品经理是笨蛋的，可看他们那么辛苦，觉得自己站着说话不腰疼。换句话说，很多时候，技术是ready的，成熟的，但找到那个应用的口却很难，盲人摸象的成分居多。

昊: 其实靠多个Template来搞的做法和Wolfram alpha挺类似的，还可以众包呢。

白: 不是先有IE这个锤子再满世界找钉子，而是先有应用场景和领域知识图谱，找一种靠谱的数据驱动机制。是不是IE，无所谓。具体到教育，大概就是这个样子。可domain specific并不必然IE。

我: 不过谷歌那种做法，则比较单纯就是满足人们 search entity 的需求。你 search 一个 entity 我把尽可能多的关于此 entity 的关联信息展示出来，然后让你随意去顺藤摸瓜。在那种知识图谱的应用场景，这个工作基本就是一个力气活。好处是总是越做信息越丰富，越做越好。从这个角度看，谷歌的知识图谱倒有点有了 IE 再找钉子的意味，每个钉子都可能对不同的用户是一个额外的惊喜，总体上符合增进用户体验和信息需求的大目标。但更多的产品和应用不是这样的，而是白老师说的，应该先从 domain 出发。研究清楚信息需求是什么，然后定义 IE Templates，等大数据填充了足够大的 Templates 形成一个动态的库以后，产品去调用它，这个过程基本就是产品经理必经的过程，最终他要给一个定义和定义的诠释。定义就是 AVM （Attribute Value Matrix），就是所谓 IE Template，诠释就是给出input（data）和output（filled template）的标注。然后才到技术开发这一步。不管你用什么办法，反正这样的 input 我就需要这样的 output。Input 通常含有很多语义，但是我只对其中的一个子集感兴趣。而且这个子集的表达方式必须是 Template 中的那样，我才好在产品中用。换句话说，知识图谱的定义实际上是带着眼镜看语义，每一个 Template 就是对语义的一个角度的表达，而这个角度是根据实际信息需求而来。boiling the sea 的 NLU 于是转变成了一个个实际任务，善莫大焉。因为我们不再为语言现象的繁难和多样而发愁，也不用为理解技术的不完善而过分苦恼，所有的焦点都在那个定义的目标，凡是与目标关系不大的 NLU 任务一概可以不理（至少暂时可以放在一边），没有完备性的需求。当然，如果想满足不同的需求，建立多样的产品，作为引擎开发者，自然还是想多做技术储备，NLU 的深度广度有一定的保障，平台比较完备，这样好以不变应万变。但观念上，落脚点还是一个一个具体的任务。

IE 本来的含义就是立足于两点：1 predefined， 2 domain specific。后来的发展过程中，有开始从这两点往外扩展的趋向，譬如提出了open domain 的 Simple Event 或 General Event 的概念，就是把 IE 向更具有普遍性的方向拉，与传统的 NLU 也更加接近了。

白: 能做云IE的，其实早已打破domain边界了。

我: 白老师纠结domain的根子在哪里？一般而言，domain 越窄越容易出效果，这个在历史上有很多案例。

白: 今天先开个头，小议知识图谱。热度有了，还希望大家踊跃贡献原创精品，新智元有强大的推手，会把诸位的思想传播得更远更广。

我: 新智元是什么？白老师和杨静创办的新媒体？

白: 是一家聚焦AI的专业新媒体，我只是敲敲边鼓，这个群算是新智元一个分舵……

我不是纠结domain，而是提醒大家伟哥拿了一把巨顺手的锤子，你们手里的锯子刨子什么的如果不想下岗的话，都拿出来遛遛，否则嘿嘿......都被当成钉子了。

白: 这边一点了……先休息

我: 国内半夜了，白老师开始了知识图谱的话头，新来的等着看这个大题目的发酵。

悟: 爬楼捡梆子完毕，减熵

白: 群名是统一制式，是新智元在AI领域布局的组成部分，大家不要修改。感谢钱学弟的整理。

我: 多谢整理，等我把错别字改一下发到个人博客上如何？如果这种即兴的对话【新智元】也会整理登载的话，我就不发博客了，需要的话可以引用。否则留下博客，也不枉对话一场。博客控，谁说的。。。博客控和【人来疯不一定是贬义】，解剖和自我解剖。

白: 老夫聊发少年狂，左拉人，右帮腔。表义知图，何故变良方？却道新辞是马甲，承本体，用为王。智元分号庆开张，人来疯，又何妨？荟萃英豪，解语更痴狂。只为求真增识见，高起点，盼辉煌。

吉: 谢谢白老师邀请我参加专业讨论！这里老师、学者居多，高手如云，一时插不上话，先潜水学习会！

很喜欢白老师前面的诗。感觉底蕴深厚！很符合当前场景，讨论氛围一下子就调动起来了。“换句话说，很多时候，技术是ready的，成熟的，但找到那个应用的口却很难，盲人摸象的成分居多。”。对伟哥的这句话我体会也比较深。google的人没有那么深的理论储备，他们是在已有搜索引擎工作的基础上，发现有需求，就去定义知识图谱产品并编程实现，其中要用到n种技术，需要什么技术就用什么技术，无论这种技术是什么年代谁提出的。由于满足了特定用户群体的某种需求，产品火了，产品背后的技术也焕发了青春。产品研发应首先由需求牵引，靠技术驱动。是否抓住了用户需求本质决定了了产品的正确与否，技术只是实现产品的驱动因素。作为象我这种掌握了某种技术的工程师，最好在“如何抓住用户本质需求上”再下点功夫！

【相关】

《知识图谱的先行：从 Julian Hill 说起》