王昊奋：大规模知识图谱技术

主讲嘉宾：王昊奋

主持人：阮彤

承办：中关村大数据产业联盟

嘉宾简介：

王昊奋，华东理工大学讲师，上海交通大学计算机应用专业博士，对语义搜索、图数据库以及Web挖掘与信息抽取有浓厚的兴趣。在博士就读期间发表了30余篇国际顶级会议和期刊论文，长期在WWW、ISWC等顶级会议担任程序委员会委员。作为Apex数据与知识管理实验室语义组负责人，他主持并参与了多项相关项目的研发，长期与IBM、百度等知名IT企业进行合作，在知识图谱相关的研究领域积累了丰富的经验。

 

以下为分享实景全文：

王昊奋：

近两年来，随着开放链接数据（Linked Open Data）等项目的全面展开，语义万维网数据源的数量激增，大量RDF（ResourceDescription Framework）数据被发布。互联网正从仅包含网页和网页之间超链接的文档万维网（Web of Document）转变成包含大量描述各种实体和实体之间丰富关系的数据万维网（Web of Data）。

国内外互联网搜索引擎公司纷纷以此为基础构建知识图谱，如Google知识图谱（Google KnowledgeGraph），百度“知心”和搜狗的“知立方”，以此来改进搜索质量，从而拉开了语义搜索的序幕。所以在这次介绍中将从Google KG, 知心和知立方三方面出发来介绍知识图谱，并帮助了解其面临的各种挑战以及图谱的内部技术实现。

我将从以下几个方面简述知识图谱：

1、知识图谱的表示以及在搜索中的展现形式；

2、知识图谱的构建；

3、知识图谱在搜索中的应用等；

从而了解其面临的各种挑战以及图谱的内部技术实现。

林其锋：图片搜索的内容？

王昊奋：

知识图谱不是图片，图谱是graph，不是image或computer vision研究的内容，主要研究知识的表示，实体的关联，概念实例化等，这在1中会详细说明。

1、知识图谱的表示以及在搜索中的展现形式；

先说展现形式，正如Google的辛格博士在介绍知识图谱时提到的：“The world is notmade of strings , but is made of things.”，知识图谱旨在描述真实世界中存在的各种实体或概念。其中，每个实体或概念用一个全局唯一确定的ID来标识，称为它们的标识符（identifier）。

类似于我们对于一个网页会有一个URL，对于数据库中的一条记录会有一个主键id等思想是一样的，强调去刻画thing，这里的thing是和传统web上的网页对比较的。每个属性—值对（attribute-valuepair，又称AVP）用来刻画实体的内在特性，而关系（relation）用来连接两个实体，刻画它们之间的关联。知识图谱亦可被看作是一张巨大的图，图中的节点表示实体或概念，而图中的边则由属性或关系构成。上述图模型可用W3C提出的资源描述框架RDF 或属性图（property graph）来表示。

可能说到这里有一些抽象，让我们来做一个对比：传统web是由网页组成的，网页之间通过超链接连在一起，如果我们将网页看作节点，将超链接看作是边，那么就形成了很大的web graph，在web 2.0时代，（即进入到社交网络时代），这个时候就会有人作为一个新的节点的出现，比如在微博中，人看作节点，某人关注另一个人，那么关注就是一种关系，一条微博也可以看作是节点，某人赞了某条微博，这里赞是一个关系，连接两个节点，一边是人，一边是一条微博。相比传统web中的节点，我们发现节点类型变成更丰富，有人和微博两种，而边也不仅仅是超链接（hyperlink只说明两者是connect的，但是他们之间是什么类型的边是不清晰的），所以边的类型也更丰富，语义也更明确。

基于此，facebook构建了之前大家热捧的兴趣图谱，而兴趣图谱也是知识图谱的一种，终究都是图，只是大家定义的图中的节点类型，边类型不同而已，上述图模型可用W3C提出的资源描述框架RDF 或属性图（property graph）来表示。大家有兴趣，可以看一下这些标准。

为了更好地理解知识图谱，我们先来看一下其在搜索中的展现形式——知识卡片（Knowledge Card）。知识卡片为用户查询中所包含的实体或返回的答案提供详细的结构化摘要，是特定于查询（query specific）的知识图谱。例如，当在搜索引擎中输入“姚明”作为关键词时，我们发现搜索结果页面的右侧原先用于置放广告的地方被知识卡片所取代。广告被移至左上角，而广告下面则显示的是传统的搜索结果，即匹配关键词的文档列表。这个布局上的微调也预示着各大搜索引擎在提高用户体验和直接返回答案方面的决心。

 

图从左到右依次是Google、百度和搜狗在搜索结果首页中所展现的与姚明相关的知识卡片。

 

虽说三大搜索引擎在知识卡片的排版和内容展现上略有不同，但是它们都列出了姚明的身高、体重、民族等属性信息。对应到上面的知识表示，这里姚明就是一个实体，有一个ID，是一个篮球运动员。

对于知识卡片中的一条，如身高2.29米，这样其实和实体本身就形成了一条事实：姚明，身高2.29米。这种和我们自然语言表述时用的主谓宾结构很类似，姚明是主语，身高是谓语，可以看作是边，通过身高将姚明和2.29米关联。此外，它们均包含“用户还搜索了”或“其他人还搜”的功能来展现相关的人物。该功能允许用户去浏览其他与姚明相关的人物的详细信息。

回到刚刚上传的图，大家可能发现Google在其知识卡片中也展示了很多与姚明相关的图片，以图文并茂的方式来展示姚明的方方面面。

 

百度则结合了百度风云榜的信息，列出了姚明的类别（体坛人物）及其百度指数（今日排名和今日搜索热度等信息）。在搜索结果页面的左上角（在图中未给出），百度还展示了其特有的专题搜索，包含了与姚明相关的百科、图片、微博、新闻、音乐、贴吧和视频等七大类的结果，基本涵盖了用户最基本的需求。

搜狗在列出与姚明相关的百科、图片，电影和最新相关消息等专题的同时，其知识卡片额外显示了诸如“主持电视节目”、“效力篮球队”、“人物关系”等各种细粒度的语义关系。搜索引擎当遇到含有歧义的用户查询时，知识卡片还会列出其他可能的查询目标对象，以达到去歧义的作用。一般大家会举的例子包括“李娜”，一个是网球运动员，一个是歌手。

更值得一提的是，当在搜狗知立方中输入“姚明的老婆的女儿的身高”如此复杂的查询时，其会直接返回其女儿的姓名（姚沁蕾）以及其身高（2750px），并给出推理说明“叶莉的女儿是姚沁蕾”。

如此详实的说明不仅为返回的答案提供了很好的解释，从另一个侧面也展示了知识图谱的强大，其不仅能识别出运动员姚明，也能抽取出关系“老婆”和“女儿”和属性“身高”等信息。当我们将查询修改为“姚明的妻子的女儿的身高”时，依然返回相同的结果，这也意味着知识图谱知道“妻子”和“老婆”代表相同的含义。

到目前为主，介绍了图谱的知识表示，以及在搜索中通过知识卡片来展现，通过例子希望大家可以对知识图谱有初步的了解。

2、知识图谱的构建；

接着大家一定想知道知识图谱是如何构建的，我将进一步介绍第2部分内容。在介绍知识图谱构建部分，我将先介绍知识图谱的数据来源。

 

为了提高搜索质量，特别是提供如对话搜索和复杂问答等新的搜索体验，不仅要求知识图谱包含大量高质量的常识性知识，还要能及时发现并添加新知识。在这种背景下，知识图谱通过收集来自百科类站点和各种垂直站点的结构化数据来覆盖大部分常识性知识。这些数据普遍质量较高，更新速度慢。

另一方面，知识图谱通过从各种半结构化数据（形如HTML表格）抽取相关实体的属性-值对来丰富实体的描述。此外，也可以通过搜索日志（query log）发现新的实体或新的实体属性从而不断扩展知识图谱的覆盖率。相比高质量的常识性知识，通过数据挖掘抽取得到的知识数据更大，更能反映当前用户的查询需求并能及时发现最新的实体或事实，但其质量相对较差，存在一定的错误。这些知识利用互联网的冗余性在后续的挖掘中通过投票或其他聚合算法来评估其置信度，并通过人工审核加入到知识图谱中。

接着先介绍百科类数据，百科包括维基百科，中文有互动百科，百度百科，可以通过以下方式来从维基百科中获取所需的内容：

通过文章页面（Article Page）抽取各种实体；大家可以在各种百科中查到“姚明”这个页面，而之前也说过“姚明”是一个实体，通过重定向页面（Redirect Page）获得这些实体的同义词（又称Synonym）；

 

当在wikipedia中输入USA时，会自动调转到Unitied States页面，所以我们可以将USA看作是United States的同义词，通过去歧义页面（DisambiguationPage）和内链锚文本（Internal Link Anchor Text）获得它们的同音异义词（又称Homonym）；

 

这里可以看到US是UnitedStates的一个去歧义页面，也就是说会有多个实体或概念将US作为别名，因此当说US时就有歧义。

回到之前的例子，李娜就符合这点，既是网球运动员李娜的名字，也是歌手李娜的名字。对于锚文本，这个比较好理解，通过概念页面（Category Page）获得各种概念以及其上下位（subclass）关系；

 

这里可以看到G20国家所具有的子类别，通过文章页面关联的开放分类抽取实体所对应的类别；

 

同时这里G20 nations也是UnitedStates的category，通过信息框（Infobox）抽取实体所对应的属性-值对和关系-实体对。

 

这是united states这个页面的infobox的部分，是不是觉得和知识卡片长的很像，其实，知识卡片就是仿照信息框来展现的。类似地，可以从百度百科和互动百科抽取各种中文知识来弥补维基百科中文数据不足的缺陷。

此外，Freebase 是另一个重要的百科类的数据源，其包含超过3900万个实体（其称为Topics）和18亿条事实，规模远大于维基百科。与百科知识数据源不同，Freebase则直接编辑知识，包括实体及其包含的属性和关系，以及实体所属的类型等结构化信息。

到目前为止，将知识图谱百科类来源简单介绍了一下，希望大家能理解，接着介绍结构化数据来源。

结构化数据来源

除了百科类的数据，各大搜索引擎公司在构建知识图谱时，还考虑使用其他结构化数据。LOD项目不仅包括DBpedia 和YAGO 等通用语义数据集，还包括MusicBrainz 和DrugBank 等特定领域的知识库。

其中MusicBrainz是关于唱片，歌手等方面的数据库。当然关于电影，大家一定知道IMDB。DrugBank是关于药的，有药品化学结构等。最近有各种Daas (data as aservice)公司出现，为Google和Facebook等大公司提供高质量数据。G公司还是很注重知识产权的，所以他一般会去买数据，而不是去爬数据，

此外，Web上存在大量高质量的垂直领域站点（如电商网站，点评网站等），这些站点被称为Deep Web。以静态网页和超链接构成的可以通过写网络爬虫爬取，被称为shallow web，Deep web一般页面是由服务器生成，通过form来向server请求得到，所以要获取这种页面需要填充页面，不能简单通过爬取获取，它们通过动态网页技术将保存在数据库中的各种领域相关的结构化数据以HTML表格的形式展现给用户。各大搜索引擎公司通过收购这些站点或购买其数据来进一步扩充其知识图谱在特定领域的知识。从Deep Web爬取数据并解析其中所包含的结构化信息面临很大的挑战，一方面，Web上存在大量长尾的结构化站点，这些站点提供的数据与最主流的相关领域站点所提供的内容具有很强的互补性，因此对这些长尾站点进行大规模的信息抽取（尤其是实体相关的属性-值对的抽取）对于知识图谱所含内容的扩展是非常有价值的。

另一方面，中文百科类的站点（如百度百科等）的结构化程度远不如维基百科，能通过信息框获得AVP的实体非常稀少，大量属性-值对隐含在一些列表或表格中，一个切实可行的做法是构建面向站点的包装器（Site-specificWrapper）。这里涉及到一个在数据挖掘中被广泛研究的内容，wrapper induction。具体的技术细节在这里就不展开了，有兴趣可以会后聊，结构化数据说了，总结一下，数据量大，但是结构化程度和抽取难度远不如百科类，当然购买数据（直接绕开deep web）购买deep web某个站点背后的数据库是另一件事情，比如阿里收购高德地图，那么就可以获得各种地理知识库。

接着介绍搜索日志，是搜索引擎公司积累的宝贵财富，也可以作为知识图谱构建的重要资源。一条搜索日志形如<查询，点击的页面链接，时间戳>。通过挖掘搜索日志，我们往往可以发现最新出现的各种实体及其属性，从而保证知识图谱的实时性。这里侧重于从查询的关键词短语和点击的页面所对应的标题中抽取实体及其属性。选择查询作为抽取目标的意义在于其反映了用户最新最广泛的需求，从中能挖掘出用户感兴趣的实体以及实体对应的属性。而选择页面的标题作为抽取目标的意义在于标题往往是对整个页面的摘要，包含最重要的信息。这一块被证明是很靠谱的，Google也有多份研究发表，证明了其可行性。

上述说的这些都不能直接用来构成知识图谱。上述所介绍的方法仅仅是从各种类型的数据源抽取构建知识图谱所需的各种候选实体（概念）及其属性关联，形成了一个个孤立的抽取图谱（Extraction Graphs）。为了形成一个真正的知识图谱，我们需要将这些信息孤岛集成在一起。

实体对齐（ObjectAlignment）：旨在发现具有不同标识实体但却代表真实世界中同一对象的那些实体，并将这些实体归并为一个具有全局唯一标识的实体对象添加到知识图谱中。虽然实体对齐在数据库领域被广泛研究，但面对如此多异构数据源上的Web规模的实体对齐，这还是第一次尝试，目前多采用聚类的方法。聚类的关键在于定义合适的相似度度量。

这些相似度度量遵循如下观察：具有相同描述的实体可能代表同一实体（字符相似）；具有相同属性-值的实体可能代表相同对象（属性相似）；具有相同邻居的实体可能指向同一个对象（结构相似）。

另外利用来自如LOD (linked open data)中已有的人工对齐标注数据（使用owl:sameAs关联两个实体）可以作为训练数据学习发现更多相同的实体对。无论何种自动化方法都无法保证100%的准确率，这些方法的产出结果将作为候选供人工进一步审核和过滤。

知识图谱schema构建：在之前介绍中，大部分篇幅均在介绍知识图谱中数据层（Data Level）的构建，没有涉及模式层（Schema Level）。事实上，模式是对知识的提炼，遵循预先给定的schema有助于知识的标准化，更利于知识查询等后续处理。

为知识图谱构建schema相当于为其建立本体（Ontology）。最基本的本体包括概念、概念层次、属性、属性值类型、关系、关系定义域（Domain）概念集以及关系值域（Range）概念集。在此基础上，我们可以额外添加规则（Rules）或公理（Axioms）来表示模式层更复杂的约束关系。面对如此庞大且领域无关的知识库，即使是构建最基本的本体，也是非常有挑战的。

目前大部分知识图谱建立的方法是自顶向下（Top-Down）和自底向上（Bottom-Up）相结合的方式。自顶向下的方式是指通过本体编辑器（Ontology Editor）预先构建本体。当然这里的本体构建不是从无到有的过程，而是依赖于从百科类和结构化数据得到的高质量知识中所提取的模式信息。

图谱模式定义了Domain（领域），Type（类别）和Topic（主题，即实体）。每个Domain有若干Types，每个Type包含多个Topics且和多个Properties关联，这些Properties规定了属于当前Type的那些Topics需要包含的属性和关系。另一方面，自底向上的方式则通过上面介绍的各种抽取技术，特别是通过搜索日志和Web Table抽取发现的类别、属性和关系，并将这些置信度高的模式合并到知识图谱中。自顶向下的方法有利于抽取新的实例，保证抽取质量，而自底向上的方法则能发现新的模式。

当融合来自不同数据源构成知识图谱时，有一些实体会同时属于两个互斥的类别（如男女）或某个实体所对应的一个Property （如性别）对应多个值。这样就会出现不一致性。由于不一致性的检测要面对大规模的实体及相关事实，纯手工的方法将不再可行。一个简单有效的方法充分考虑数据源的可靠性以及不同信息在各个数据源中出现的频度等因素来决定最终选用哪个类别或哪个属性值。

下面介绍一下知识图谱上的挖掘：

通过各种信息抽取和数据集成技术已经可以构建Web规模的知识图谱。为了进一步增加图谱的知识覆盖率，需要进一步在知识图谱上进行挖掘。主要技术包括推理、实体重要性排序和相关实体挖掘。

一、推理（Reasoning或Inference）：被广泛用于发现隐含知识。推理功能一般通过可扩展的规则引擎来完成。知识图谱上的规则一般涉及两大类。一类是针对属性的，即通过数值计算来获取其属性值。例如：知识图谱中包含某人的出生年月，我们可以通过当前日期减去其出生年月获取其年龄。这类规则对于那些属性值随时间或其他因素发生改变的情况特别有用。另一类是针对关系的，即通过（链式）规则发现实体间的隐含关系。例如，我们可以定义规定：岳父是妻子的父亲。利用这条规则，当已知姚明的妻子（叶莉）和叶莉的父亲（叶发）时，可以推出姚明的岳父是叶发。

二、实体重要性排序：是指当用户查询涉及多个实体时，搜索引擎将选择与查询更相关且更重要的实体来展示。实体的相关性度量需在查询时在线计算，而实体重要性与查询无关可离线计算。和传统的网页链接组成的图相比，知识图谱中的节点是各种类型的实体，而图中的边是各种语义关系。由于不同的实体和语义关系的流行程度以及抽取的置信度不同，这些因素将影响实体重要性的最终计算结果。

三、相关实体挖掘：是指在相同查询中共现的实体，或在同一个查询会话（Session）中被提到的其他实体称为相关实体。一个常用的做法是将这些查询或会话看作是虚拟文档，将其中出现的实体看作是文档中的词条，使用主题模型（如LDA）发现虚拟文档集中的主题分布。当用户输入查询时，搜索引擎分析查询的主题分布并选出最相关的主题。同时，搜索引擎将给出该主题中与知识卡片所展现的实体最相关的那些实体作为“其他人还搜了”的推荐结果。

知识图谱的构建还需要考虑知识图谱的更新和维护

知识图谱的schema更新：为了保证其质量，由专业团队审核和维护。以Google知识图谱为例，目前定义的Type数在103-104的数量级。为了提高知识图谱的覆盖率，搜索引擎公司还通过自动化算法从各种数据源抽取新的类型信息（也包含关联的Property信息），它们不是马上被加入到知识图谱schema中，如果某一种类型能够长期的保留，发展到一定程度后，由专业的人员进行决策和命名并最终成为一种新的类型。

结构化站点包装器的维护：站点的更新常常会导致原有模式失效。搜索引擎会定期检查站点是否存在更新。当检测到现有页面（原先已爬取）发生了变化，搜索引擎会检查这些页面的变化量，同时使用最新的站点包装器进行AVP抽取。如果变化量超过事先设定的阈值且抽取结果与原先标注的答案差别较大，则表明现有的站点包装器失效了。在这种情况下，需要对最新的页面进行重新标注并学习新的模式，从而构建更新的包装器。

知识图谱的更新频率：加入到知识图谱中的数据不是一成不变的。知识类型对应的实例往往动态变化。例如，美国总统，随着时间的推移，可能对应不同的人。由于数据层的规模和更新频度都远超schema层，搜索引擎公司利用其强大的计算保证图谱每天的更新都能在3个小时内完成，而实时的热点也能保证在事件发生6个小时内在搜索结果中反映出来。

众包（Crowdsourcing）反馈机制：除了搜索引擎公司内部的专业团队对构建的知识图谱进行审核和维护，它们还依赖用户来帮助改善图谱。具体来说，用户可以对搜索结果中展现的知识卡片所列出的实体相关的事实进行纠错。当很多用户都指出某个错误时，搜索引擎将采纳并修正。这种利用群体智慧的协同式知识编辑是对专业团队集中式管理的互补。

知识图谱在搜索中的应用：

知识图谱一经推出，就为语义搜索带来了新的活力，毋容置疑，知识图谱已经在搜索的查询理解和基于知识的问题回答上初显出其强大的威力。

搜索引擎借助知识图谱来识别查询中涉及到的实体（概念）及其属性等，并根据实体的重要性展现相应的知识卡片。搜索引擎并非展现实体的全部属性，而是根据当前输入的查询自动选择最相关的属性及属性值来显示。此外，搜索引擎仅当知识卡片所涉及的知识的正确性很高（通常超过95%，甚至达到99%）时，才会展现。当要展现的实体被选中之后，利用相关实体挖掘来推荐其他用户可能感兴趣的实体供进一步浏览。

问题回答：除了展现与查询相关的知识卡片，知识图谱对于搜索所带来的另一个革新是：直接返回答案，而不仅仅是排序的文档列表。要实现自动问答系统，搜索引擎不仅要理解查询中涉及到的实体及其属性，更需要理解查询所对应的语义信息。搜索引擎通过高效的图搜索，在知识图谱中查找连接这些实体及属性的子图并转换为相应的图查询（如SPARQL ）。这些翻译过的图查询被进一步提交给图数据库进行回答返回相应的答案。

在搜索中的两个应用已经介绍完

回顾一下，我刚刚介绍了知识图谱的表示、构建、挖掘以及在搜索中的应用。

通过上述介绍可以看出：

1）目前知识图谱还处于初期阶段；

2）人工干预很重要；

3）结构化数据在知识图谱的构建中起到决定性作用；

4）各大搜索引擎公司为了保证知识图谱的质量多半采用成熟的算法；

5）知识卡片的给出相对比较谨慎；

6）更复杂的自然语言查询将崭露头角（如Google的蜂鸟算法）。

此外，知识图谱的构建是多学科的结合，需要知识库、自然语言处理，机器学习和数据挖掘等多方面知识的融合。有很多开放性问题需要学术界和业界一起解决。我们有理由相信学术界在上述方面的突破将会极大地促进知识图谱的发展。

互动环节

放小狼：

我用protege做过城市规划的领域本体，规模不大，才几百个概念，并且基于它做了局域网的搜索引擎，进行知识管理，但是protege的中文支持差。进行语义分析效率低，有关开源的开发包也不好用，现在我是否还应该继续在它上面深化，还是有更好，更方便的方案取代它。

王昊奋：

protege等是ontology editor，属于知识工程的范，first schema,then data。而现在知识图谱的构建一般采用bottom up的方式，先有data，再从data归纳出schema，当然也会复用一些已经成型的schema，如freebase的，以及各种搜索引擎全力去推广的schema.org。

回到你的问题，我不建议你继续用protege，因为他对Unicode的支持以及IRI(international resource identifer)支持不好，算是owl编辑器，因为构建于局域网，针对的是网内档案资料库的几十万个文档，目前本领域找不到可用的知识库，也很难基于这些文档自下而上形成，如果你这里构建的是一个垂直领域或一个小的知识库，那么可以选用topbraidcomposer+triple store (RDF graph database)来管理，已经编写的推理规则可以通用吗？在ontology editor里面编写的都是ontology axioms，而不是rule，所以需要额外的rule editor以及rule engine来提供，这些推理规则可以通用，就像你用数据库，可以支持各种import/export以及用SQL查询。

放小狼：

多谢，按您说的关键词找文档学习一下。

王昊奋：

不知道这么解释是否清楚，有兴趣可以看一下topbraid composer+ allegrograph，

如果你还有各种数据库存储在RDB中，可以采用D2R或Sentient suite做各种数据的集成，当然我刚刚回答的只适合企业级应用，之前介绍的知识图谱属于互联网级别，需要设计新的工具

放小狼：

有没有像我这种在企业内部做类似应用做的很好，形成了完善的专业知识图谱的？

王昊奋：

大家都在做，对于企业，建议的做法是internal data +linked data = insights。

阮彤：

我们正在商量和企业合作，把实验室做的编辑器放到互联网上，形成社区。不知感兴趣否？

放小狼：

是ontology互联的意思吗？我是非专业人员，有兴趣参与社区学习。

皇上：

非常专业，获益匪浅，或许应用在企业客服支持系统中会有良好的表现，现在是否有企业在基于知识图谱做这类应用呢？

王昊奋：

这里internal data其实是各种企业服务的行业数据，存储在包括RDB等内部数据库中，而linked data代表外部互联的数据（可以是公开的知识库或知识图谱），内部数据是企业的关键，也是互联网企业不能进入的门槛，对于互联网企业来说，他们外部数据很强，没有企业数据，或者企业数据或行业理解比较弱，而相反，做企业应用的公司在外部数据积累和处理外部数据的技术上略显不足，但是优势是内部数据，所以在知识图谱方面，大家是公平的，就看谁两方面都比较匀衡就可以胜出，是传统行业互联网化的时代，就看重新洗牌最后谁是赢家了。

Roger Hsu：

原来在推广xml语言时，就有一块说是可以更好的描述实体，不知这块的实际发展对于知识图谱带来了多少帮助？

王昊奋：

XML没有明确的语义，现在主要是用于各种配置和数据交换。具有更好语义的包括RDF和OWL，当然这些都可以json化，大家也在进行各种简化，让语言更简洁的同时保证语义，知识图谱的数据表示基本是参考这些数据模型，做了一定的简化。现在paypal正在结合这两块做（内部+外部）做paypal支付欺诈检测等方面的工作

周洲：

没数据知识图谱也没戏，paypal早就做了。hbase的项目案例就是ebay。

王昊奋：

没有数据就没有知识图谱这个是真理数据包括内部数据和外部公开数据内部数据不是大家都有的，外部数据大家都可以获取，怎么构建图谱就看大家的能耐了。

周洲：

先有数吧。百度文库技术不是最先进，百科已经是国内翘楚了。

王昊奋：

支付欺诈是很早paypal就做了，他有很庞大的BU部门制定各种规则和metrics。

周洲：

那都太远。

王昊奋：

但是我这里说的是内部和外部数据的整合，之前他们都主要考虑内部数据，基于各种transaction log和user profile来做的，但是有些规则会block被临时盗号的人（而这些人自己并不知情，特别对于很多大V) 。另一方面，现在有各种聪明的团队合伙来做欺诈，有明确的分工，这些是原来无法检测的，hbase是一种数据库，针对的是schemaless（如big table）的应用，可用来管理知识图谱，但是先要有知识图谱。

黄明峰：

从实践角度，对于传统行业大数据应用，如何去构建这种数据的图谱关系？现在成熟的大数据的应用多在互联网和商业领域，因为他们已建立了相对的数据采集，但对其他行业，如何去建立数据的图谱关系来实现数据的价值，一般有哪些途径？

王昊奋：

首先先要理解你的需求，那些地方需要用到图谱，不能按照互联网公司的做法。

首先，大家的应用需求不同。其次，互联网公司的主要应用场景是搜索，且他们构建的是通用知识图谱，在存储管理等方面的要求和企业的要求不同，在明确需求之后，就可以考虑现有解决方案（不用知识图谱）存在什么问题，在确定之后可以分析哪些点是可以通过知识图谱来改进的，在这之后就是知识图谱的表示，构建，和应用，一般的途径是要统一知识表示，从ER模型到知识图谱表示，然后通过图谱表示之后，考虑图谱构建的来源和上层支持的服务，表达能力等。

黄明峰：

也就是说，建立应用场景是第一位的，其次是传统数据的大数据化和新数据采集的实时性，然后再建立数据图谱关系？

王昊奋：

是的，需要data driven或applicationdriven来设计。

黄明峰：

建立数据的图谱关系，是数据建立关联价值的第一步。

徐元区：

请教这个体系的基本原则对于语音和图片知识适用吗？

王昊奋：

适用，其实更适合对多媒体表示，因为多媒体的表示和处理大家都还不是那么清晰。所以处理很红火的深度学习，通过知识图谱来弄是另一条途径。有兴趣的可以看一下欧盟的一个项目叫linked TV。另外，百度新成立了webdata部门，目前有100+人，其中20人在构建图片知识库，另外，有20+人做推理等，百度正在整合各种部门中对知识的需求，形成webdata基础部门来为全公司提供服务，且完善知心，并推广垂直知识图谱。

黄明峰：

需要消化一下。推荐一下数据图谱和知识图谱的书。

王昊奋：

目前还没有知识图谱方面的书，有空打算和阮老师一起写一本。关于知识图谱在企业的应用，我可以说一下在国外的情况，目前各种医药公司都借助语义技术构建知识图谱，在drug discovery等方面做各种探索。而大家知道的IBM Watson系统，其实也是构建了知识图谱的，为QA服务。

黄明峰：

我觉得这个研究很有价值，我的思维链里面，对如何建立一套合适的方法来帮助传统行业进行大数据应用。

王昊奋：

恩，所以我前面提到有各种data as a service部门、公司。另外，还会出现各种为知识图谱提供各种基础服务和咨询培训的startup，类似cloudera或databricks之于大数据一样。为了做到这一点，从学术界产生这样的startup或业界和学术界的结合可能性很大，一方面学术界在知识图谱相关的学科有比较多的积累，而业界特别是各种企业对行业比较了解，也更清楚企业应用的痛点以及使用知识图谱的各种困惑。

黄明峰：

今天的分享解决了我思考传统行业大数据应用的一个大问题，首先就是数据如何建立有效的灵活的关系。

王昊奋：

你的理解是对的，当然这里还需要考虑数据模型。

黄明峰：

数据模型得根据行业去制定，估计以后会有一堆新的元数据出现。

王昊奋：

我说的数据模型是指更基本的，如原来大家用RDB都会用ER模型。用XML就会用XML，现在要用图谱，那么就需要用RDF或相关的知识表示和数据模型。

阮彤：

感谢王老师专业、细致和丰富，兼顾学术性与应用性报告。今天就到这里。

王昊奋：

好的，客气，也很感谢阮老师给我这个机会和大家分享知识图谱这个话题。

原文地址：http://www.china-cloud.com/zhongyunxy/20140612_38070.html